Building an AI Native Company

Una guida pratica su come costruire un’azienda AI-native basata sull’esperienza di Every: 15 persone, 4 prodotti software, 99% del codice scritto da AI agents.

Introduzione

“C’è una differenza 10x tra un’organizzazione dove il 90% degli ingegneri usa AI e una dove il 100% usa AI.”

Dan Shipper, CEO di Every, ha condiviso questa dichiarazione durante un talk a New York. La sua azienda rappresenta un esperimento reale di cosa significa operare come un’azienda veramente AI-native.

Every gestisce 6 business units e 4 prodotti software con appena 15 persone. Questi non sono progetti toy: l’azienda è cresciuta del doppio cifre ogni mese negli ultimi 6 mesi, ha oltre 7.000 abbonati paganti e 100.000 utenti free. Il tutto con appena un milione di dollari raccolti.

La Differenza tra 90% e 100%

Quando Dan parla di una “differenza 10x”, non sta esagerando. La differenza tra adozione quasi-totale e adozione totale dell’AI è fondamentale.

Il Problema del 10%

Se anche solo il 10% del team usa ancora metodi di sviluppo tradizionali (scrivere codice manualmente in un editor), l’intera organizzazione deve adattarsi a quel 10%.

90% AI + 10% tradizionale = Tutti devono tornare al metodo tradizionale

Questo perché:

• I processi devono supportare entrambi i modi di lavorare
• Le assunzioni su quanto tempo serve per fare le cose rimangono ancorate al metodo più lento
• Non si possono sfruttare appieno i vantaggi dell’AI

Il Salto al 100%

Quando tutti usano AI agents per scrivere codice, l’organizzazione può trasformarsi completamente:

• Nuovi workflow che sarebbero impossibili con metodi tradizionali
• Nuovi processi ottimizzati per delegazione agli agent
• Nuove aspettative su velocità e output

Cosa Diventa Possibile

Con il 100% di adozione AI, Every ha sbloccato capacità che sembravano impossibili.

1. Parallelismo Estremo

Gli sviluppatori di Every lavorano regolarmente su multiple features e bug in parallelo.

# Scenario comune: 4 pane di coding agent aperti contemporaneamente
┌─────────────────┬─────────────────┐
│ Pane 1:         │ Pane 2:         │
│ Feature A       │ Bug fix B       │
│ (delegato)      │ (in esecuzione) │
├─────────────────┼─────────────────┤
│ Pane 3:         │ Pane 4:         │
│ Refactor C      │ Research D      │
│ (review)        │ (pianificazione)│
└─────────────────┴─────────────────┘

Dan sottolinea che questo non è solo un meme (il “vibe coder” con 4 pane che non fa nulla). Ci sono sviluppatori in Every che usano produttivamente 4 istanze di coding agent contemporaneamente.

2. Prototyping a Costo Zero

Il codice è economico. Questo cambia radicalmente l’approccio all’innovazione.

# Prima:
Idea → Memo → Meeting → Approvazione → Settimane di sviluppo

# Ora:
Idea → "Claude, prototipa questo" → Demo in ore

Quando il costo di testare un’idea rischiosa è sceso a quasi zero, si possono fare più esperimenti di quanti se ne facessero prima. Questo porta a più innovazione e più progressi.

3. Demo Culture

Every si sta spostando verso una demo culture invece di una memo/deck culture.

Prima:

• Scrivere un documento che spiega l’idea
• Creare una presentazione
• Convincere stakeholder che vale la pena investire tempo
• Solo dopo: iniziare a costruire

Ora:

• Vibe-code un prototipo in poche ore
• Mostrarlo al team
• La demo parla da sé

Dan nota che ci sono idee strane che funzionano solo quando puoi sentirle, non quando le leggi in un memo. La demo culture permette di esplorare questi concetti che altrimenti non verrebbero mai approvati.

Compounding Engineering

Il vero breakthrough organizzativo di Every è quello che Dan chiama Compounding Engineering.

Il Problema dell’Ingegneria Tradizionale

Feature 1 → Feature 2 → Feature 3 → Feature 4
  ↓           ↓           ↓           ↓
Ogni feature rende la prossima PIÙ DIFFICILE da costruire

Nella software engineering tradizionale, ogni feature aggiunge complessità:

• Più codice da capire
• Più edge cases da considerare
• Più test da mantenere
• Più tech debt accumulato

La Promessa del Compounding

Compounding Engineering inverte questa dinamica:

Feature 1 → Feature 2 → Feature 3 → Feature 4
  ↓           ↓           ↓           ↓
Ogni feature rende la prossima PIÙ FACILE da costruire

Come? Attraverso un loop in 4 step che cattura e codifica le lezioni apprese.

Il Loop in 4 Step

┌──────────────┐      ┌──────────────┐
│   1. PLAN    │  →   │  2. DELEGATE │
└──────────────┘      └──────────────┘
       ↑                      ↓
       │                      ↓
┌──────────────┐      ┌──────────────┐
│  4. CODIFY   │  ←   │  3. ASSESS   │
└──────────────┘      └──────────────┘

Step 1: Plan

Creare un piano molto dettagliato del lavoro da fare.

Chi lavora con coding agent sa quanto è importante la pianificazione. A Every questo è un principio fondamentale.

# Esempio di planning
"Claude, prima di iniziare a scrivere codice, esplora la codebase
e crea un piano dettagliato per implementare il sistema di team.
Include:
- File da modificare
- Pattern esistenti da seguire
- Come testare ogni cambiamento"

Step 2: Delegate

Delegare il lavoro all’agent.

# Delega semplice
"Segui il piano in plan.md e implementa step by step"

Questo è il passo che tutti conoscono - dire all’AI di fare qualcosa.

Step 3: Assess

Valutare la qualità del lavoro. Every usa molteplici tecniche:

• Test automatici - eseguire test suite
• Manual testing - provare la feature
• Agent review - far analizzare il codice a un altro agent
• Human code review - review tradizionale
• Type checking - verificare TypeScript/linting
• Demo - vedere se funziona end-to-end

Step 4: Codify

Questo è lo step chiave - quello che crea il compounding.

Prendere tutte le lezioni apprese dalle fasi precedenti e codificarle in:

CLAUDE.md                    # Istruzioni per il progetto
.claude/prompts/             # Prompt riutilizzabili
slash-commands/              # Comandi custom
sub-agents/                  # Agent specializzati

Esempio pratico:

# CLAUDE.md

## Testing
Dopo ogni modifica al codice, esegui:
```bash
npm test
npm run type-check

Code Style

• Preferire componenti funzionali in React
• Usare 2 spazi per indentazione
• Aggiungere JSDoc per tutte le funzioni pubbliche

Team Feature Pattern

Quando aggiungi features multi-tenant:

1. Aggiornare modello Team in src/models/Team.ts
2. Aggiungere migration in migrations/
3. Aggiornare middleware auth per includere team context
4. Test in tests/teams/

Man mano che il team lavora, queste istruzioni si **accumulano**. Ogni problema risolto diventa conoscenza codificata che l'agent userà automaticamente la prossima volta.

> [!NOTE]
> Il nome "Compounding Engineering" viene da questo effetto composto: ogni feature alimenta le istruzioni, che rendono la prossima feature più facile, che alimenta nuove istruzioni, in un loop virtuoso.

## Effetti di Secondo Ordine

Quando si costruisce un'organizzazione intorno al Compounding Engineering, emergono benefici non ovvi.

### 1. Condivisione Tacita del Codice

Every ha 4 prodotti diversi, spesso con stack tecnologici diversi. Nella software engineering tradizionale, condividere codice tra progetti richiede:

- Estrarre logica comune in una libreria
- Pubblicare su package manager interno
- Documentare l'API
- Manutenzione continua

**Con AI agents**, la condivisione diventa banale:

```bash
"Claude, guarda come abbiamo implementato OAuth nel progetto Kora
(repo: github.com/every/kora) e implementalo nel progetto Spiral
usando il nostro stack (diverso ma simile approccio)."

L’agent:

1. Legge il codice del progetto Kora
2. Capisce il pattern
3. Lo adatta al contesto di Spiral
4. Implementa nella tecnologia appropriata

Non serve astrarre, non serve libreria condivisa. Il codice è documentazione, e l’AI sa leggerlo.

2. Onboarding Immediato

I nuovi assunti sono produttivi dal primo giorno.

Come? Tutte le lezioni codificate nei file CLAUDE.md, prompt, e slash commands sono immediatamente disponibili.

# Primo giorno, nuovo developer:
git clone repo
cd repo
claude-code

# L'agent sa già:
✓ Come eseguire i test
✓ Quali sono le convenzioni di codice
✓ Come è strutturato il progetto
✓ Come scrivere un buon commit message
✓ Dove trovare cosa

Dan nota che questo è particolarmente utile per expert freelancer: persone molto competenti in un’area specifica possono fare “drop-in” contributi anche senza conoscere tutta la codebase.

3. Cross-Product Contributions

Tutti in Every usano tutti i prodotti internamente. Quando qualcuno trova un bug o vuole una piccola quality-of-life feature in un’app che non mantiene, può semplicemente fixarlo.

# Developer che lavora su Kora trova un bug in Spiral:

git clone spiral-repo
claude-code

"C'è un bug nel bottone di esportazione. Quando clicco non scarica
il file. Puoi investigare e fixare?"

# L'agent:
# - Esplora la codebase (anche se il dev non la conosce)
# - Trova il bug
# - Lo fixa
# - Esegue i test
# - Crea PR per il maintainer di Spiral

Questo era impraticabile prima. Il costo di contestualizzarsi su una codebase non familiare era troppo alto per un piccolo fix.

4. Stack Flessibile

Every non ha standardizzato su un particolare stack tecnologico.

Ogni team/prodotto può scegliere:

• Il linguaggio che preferisce
• Il framework che conosce meglio
• Le librerie che trova più adatte

Perché questo è possibile?

L’AI rende molto più facile:

• Tradurre pattern tra stack diversi
• Onboardare su linguaggi/framework non familiari
• Muoversi fluidamente tra progetti

# Developer competente in React, deve fixare qualcosa in un'app Vue:

"Claude, aiutami a capire come funziona questo componente Vue.
Non conosco Vue ma conosco bene React."

# L'agent spiega i concetti Vue in termini React-friendly

5. Manager Che Committano Codice

Questo è il preferito di Dan, anche se ammette che può essere “l’orrore” di alcuni developer.

Manager tecnici, incluso il CEO, committano codice production.

Dan stesso ha committato codice negli ultimi mesi, nonostante:

• Gestire 15 persone
• Coordinare 6 business units
• Crescita rapida dell’azienda
• Mille altre responsabilità

Come è possibile?

AI permette di lavorare con attenzione frammentata:

# Scenario reale:
10:00 - Esce da meeting
10:05 - "Claude, investiga questo bug nel sistema di pagamenti"
10:10 - Va a un altro meeting

11:00 - Esce dal meeting
11:05 - Legge l'analisi di Claude, approva il fix
11:10 - "Claude, crea la PR"
11:15 - Altro meeting

12:00 - La PR è merged

Prima servivano blocchi di 3-4 ore di focus time per essere produttivi. Ora è possibile delegare, contestualizzare, e completare task in finestre di 5-10 minuti tra meeting.

Esempi Pratici

Vediamo i 4 prodotti che Every costruisce e mantiene con questo approccio.

Kora: Email Management

Kora è un assistente AI per la gestione email.

Features:

• Riassunto automatico di tutte le email in arrivo (pannello sinistro)
• Assistente conversazionale che risponde a domande sulla tua inbox (pannello destro)
• Integrazione profonda con Gmail/Outlook

Team: Un ingegnere (più 1-2 contractor occasionali per aree specifiche)

Monologue: Speech-to-Text

Monologue è un’app di trascrizione speech-to-text.

Pensa a “Super Whisper” o “Whisper Flow” - un’interfaccia desktop per modelli di trascrizione con features avanzate.

Features:

• Trascrizione in tempo reale
• Multiple lingue
• Editing e export
• Integrazione con workflow

Team: Un ingegnere

Dan lo descrive come “un’app bellissima e complessa, non è semplice”.

Spiral: Note-Taking

Spiral è un’app complessa per note-taking.

Guardando gli screenshot condivisi nel talk, è evidente che è un’applicazione grande con molte features.

Team: Un ingegnere

Come È Possibile?

Questi non sono MVP o progetti side. Sono prodotti production con:

• Migliaia di utenti
• Revenue reale
• Feature complete
• Alta qualità

La chiave è il Compounding Engineering:

1. Il primo developer costruisce la base
2. Codifica i pattern in CLAUDE.md e prompts
3. Ogni feature successiva sfrutta quel knowledge
4. Il knowledge si accumula
5. Nuove feature diventano progressivamente più veloci

Dopo 6 mesi di questo processo, un singolo developer può muoversi molto velocemente su una codebase complessa.

I Numeri di Every

Per contestualizzare quanto è efficace questo approccio:

Team:

• 15 persone totali
• 6 business units
• 4 prodotti software

Crescita:

• MRR cresciuto a doppio cifre ogni mese per 6 mesi
• 7,000+ abbonati paganti
• 100,000+ utenti free

Capital Efficiency:

• ~$1M raccolto totale
• Operazione molto lean

Il Playbook (Che Non Esiste)

Dan inizia il talk ammettendo:

“Sono qui per parlare di come costruire un’azienda AI-native… e in realtà non ho un playbook da darvi.”

La sua onestà è importante. Il playbook si sta inventando adesso.

Quello che offre sono “dispatches from the future” - note su cosa stanno scoprendo in Every mentre costruiscono questo nuovo modo di lavorare.

Principi Emergenti

Anche se non c’è un playbook completo, alcuni principi stanno emergendo:

1. Commitment al 100% - No half-measures sull’adozione AI
2. Codificare le lezioni - Catturare tacit knowledge in prompts
3. Demo > Memo - Mostrare invece di raccontare
4. Parallelismo - Sfruttare la capacità di delegare a multiple istanze
5. Stack flessibile - L’AI riduce il costo della diversità tecnologica
6. Context is king - I file CLAUDE.md e prompt sono asset fondamentali

Il Tuo Playbook

Dan incoraggia tutti a:

• Sperimentare nel proprio contesto
• Condividere le scoperte
• Collaborare sulla costruzione del playbook

Conclusione

Costruire un’azienda AI-native non significa solo “usare AI tools”. Significa ripensare completamente:

• Come si struttura il team
• Come si organizza il lavoro
• Come si cattura e condivide la conoscenza
• Cosa è possibile con risorse limitate

Key Takeaways

1. 100% > 90% - La differenza tra adozione quasi-totale e totale è enorme
2. Compounding Engineering funziona - Plan → Delegate → Assess → Codify
3. Single developer apps - Un ingegnere può costruire e mantenere app complesse
4. Demo culture - Il codice è economico, costruire prototipi è veloce
5. Knowledge codificato - CLAUDE.md e prompts sono asset strategici
6. Effetti di secondo ordine - Onboarding istantaneo, cross-product contribution, stack flessibile
7. Manager possono codare - L’AI permette contributi con attenzione frammentata

Il Futuro

Dan conclude con un invito:

Every rappresenta un laboratorio di cosa è possibile in un’azienda completamente AI-native. I risultati sono promettenti:

• Alta produttività con team piccoli
• Crescita rapida con capitale limitato
• Qualità alta senza sacrificare velocità

Ma questo è solo l’inizio. Il playbook si sta ancora scrivendo, e tutti quelli che sperimentano in questa direzione stanno contribuendo a definire il futuro dello sviluppo software.

Il futuro dello sviluppo software è AI-native. Every sta dimostrando che funziona.

Buon coding! 🚀