Cosa l'IA non puo fare per te

In sintesi: L’IA gestisce la produzione; gli umani gestiscono la direzione. Otto cose non possono essere delegate — chiarezza, giudizio, responsabilita, gusto, architettura, contesto, relazioni e dire di no. Il collo di bottiglia si e spostato dall’esecuzione alla presa di decisioni.

Un founder solitario con Claude puo lanciare in un weekend cio che prima richiedeva tre mesi a un team. Non e esagerazione — io gestisco un SaaS a sette cifre con cinque persone e l’IA fa il lavoro pesante che prima richiedeva headcount.

Ma ecco cosa mi hanno insegnato alcuni mesi a costruire in questo modo: L’IA non ha eliminato le parti difficili della gestione di un business. Ha rivelato quali fossero davvero le parti difficili.

Quando l’esecuzione era costosa, confondavamo lo sforzo con il valore. Scrivere codice era difficile, quindi assumevamo che scrivere codice fosse la parte di valore. Redigere contenuti richiedeva ore, quindi assumevamo che la redazione fosse la competenza. Gestire un codebase richiedeva un team, quindi assumevamo che il team fosse il moat.

Niente di questo era vero. Semplicemente non potevamo vederlo perche lo strato di produzione era cosi costoso da oscurare tutto cio che c’era sotto.

Ora lo strato di produzione e quasi gratuito. E cio che resta — quello che l’IA non puo toccare — si rivela essere tutto cio che conta davvero.

Punti chiave:

• L’IA gestisce la produzione. Gli umani gestiscono la direzione. Confondere le due cose e come le aziende costruiscono velocemente e rompono tutto.
• Otto cose non delegabili: chiarezza, giudizio, responsabilita, gusto, architettura, contesto, relazioni e dire di no.
• Il collo di bottiglia non e scomparso — si e spostato dall’esecuzione alla presa di decisioni.
• I founder che automatizzano tutto, inclusa la direzione, lanceranno di piu e costruiranno di meno.
• La competenza piu preziosa nel 2026 non e il prompting. E sapere quando non costruire.

Le otto cose che non puoi delegare

1. Chiarezza

Sapere cosa stai costruendo e perche.

Un agente implementera qualsiasi cosa tu descriva. Non ti dira mai che la funzionalita e inutile. Chiedigli di costruire una dashboard che nessuno controllera e otterrai una bellissima dashboard che nessuno controlla. Chiedigli di aggiungere una pagina di impostazioni con 40 opzioni e otterrai 40 opzioni che confondono ogni utente.

L’agente ottimizza per il completamento, non per lo scopo. Tratta ogni task come ugualmente meritevole. E l’opposto di come pensa un buon founder. Meta del lavoro e decidere cosa non costruire — e quella decisione richiede chiarezza su cosa sia realmente il prodotto, chi serve e quale problema risolve.

Prima dell’IA, questo era implicito. Non potevi costruire tutto, quindi eri costretto a dare priorita. I vincoli creavano chiarezza. Ora i vincoli sono spariti, e la chiarezza deve essere intenzionale. Se non sai esattamente a cosa serve il tuo prodotto, l’agente ti aiutera allegramente a costruire un ammasso gonfio che fa tutto e niente.

2. Giudizio

Quale richiesta del cliente e segnale e quale e rumore. Quale bug richiede un hotfix e quale aspetta il prossimo sprint. Quale funzionalita guidera la retention e quale guidera la confusione.

L’IA puo riassumere 500 ticket di supporto. Puo categorizzarli, ordinarli per frequenza, persino suggerire soluzioni. Quello che non puo fare e guardare quei ticket e dire: “Queste 50 lamentele sono in realta lo stesso problema sottostante, e la soluzione non e la funzionalita che chiedono — e semplificare il flusso di onboarding.”

Quel riconoscimento di pattern viene dal vivere dentro al business per anni. Dal sapere che i merchant che cancellano al terzo mese condividono tutti lo stesso errore di configurazione. Dal ricordare che hai provato la soluzione ovvia due anni fa e ha peggiorato le cose. Il giudizio e riconoscimento di pattern su contesto proprietario. L’IA non ha il tuo contesto. Questo e anche il motivo per cui valutare le idee di business non puo essere completamente automatizzato — il framework di valutazione aiuta, ma la decisione finale e sempre umana.

3. Responsabilita

La persona che fa commit del codice e proprietaria del codice. La persona che preme “invia” sulla campagna Klaviyo e proprietaria dell’email. La persona che fa deploy e proprietaria del deploy. Indipendentemente da chi — o cosa — l’ha scritto.

Questo non e un punto filosofico. E operativo. Quando qualcosa si rompe in produzione alle 2 di notte, l’agente non riceve l’allarme. Quando un cliente risponde alla tua campagna email con una lamentela, l’agente non gestisce la conversazione. Quando una vulnerabilita di sicurezza viene rilasciata perche nessuno ha rivisto il PR, l’agente non ne subisce le conseguenze.

La responsabilita e il motivo per cui esiste la revisione. Non come burocrazia — come la funzione che rende possibile la qualita. Il momento in cui smetti di revisionare cio che produce l’agente e il momento in cui smetti di essere responsabile di cio che viene rilasciato. E il divario tra “nessuno ha revisionato questo” e “il codebase e irrecuperabile” e piu breve di quanto pensi.

4. Gusto

I contenuti generati dall’IA sono competenti. Il codice generato dall’IA e funzionale. I design generati dall’IA sono ragionevoli. Competente, funzionale e ragionevole non bastano.

La differenza tra un articolo che viene condiviso e uno che viene ignorato non e la grammatica. E la prospettiva. La specificita. La frase che fa fermare lo scrolling perche non l’hai mai sentita formulata cosi. Questo viene dall’esperienza, dalle opinioni e dalla volonta di dire qualcosa che la maggior parte non dira. (Questo e anche il motivo per cui l’ottimizzazione per i motori di risposta premia i contenuti esperienziali — i LLM citano la specificita, non la rifinitura.)

La differenza tra un prodotto che le persone tollerano e uno che raccomandano non e il numero di funzionalita. E il flusso. La sensazione che qualcuno che capisce il problema l’abbia costruito. Le cento piccole decisioni su cosa mostrare, cosa nascondere, cosa rendere facile e cosa rendere impossibile. Il gusto e l’accumulo di ogni decisione opinionata che un agente avrebbe lasciato alla mediana.

L’IA tira verso la media. Il gusto e cio che rende il tuo prodotto non mediocre.

5. Architettura

Un agente prende decisioni localmente. Vede il file che sta editando, forse qualche file correlato, forse una ricerca nel codebase. Non tiene l’intero sistema in testa. Non sa come la decisione di oggi vincola le opzioni di domani.

L’architettura e l’opposto: decisioni globali che plasmano tutto a valle. Quale database. Quale pattern di API. Come comunicano i servizi. Dove vive lo stato. Quali sono i confini tra i moduli.

Quando deleghi l’architettura a un agente, ottieni un amalgama di pattern estratti dai dati di training — alcuni buoni, alcuni cargo cult, nessuno scelto per i tuoi vincoli specifici. Abbiamo visto il risultato a RevenueHunt: utility duplicate, pattern di gestione errori in conflitto, astrazioni che esistono perche l’agente non ha trovato quella esistente. Ogni decisione aveva senso isolatamente. Insieme, hanno creato un pasticcio che solo un umano che capiva l’intero sistema poteva districare.

L’architettura e dove la tua esperienza e i tuoi vincoli si incrociano. Nessun agente ha ne l’una ne gli altri.

6. Contesto

L’IA non sa che questo merchant e con te dal 2020 e genera $50K/anno. Non sa che il concorrente che ha appena lanciato una nuova funzionalita la eliminera silenziosamente in tre mesi — perche lo fanno sempre. Non sa che l’ultima volta che hai provato a semplificare i prezzi, tre clienti enterprise hanno minacciato di andarsene.

Il contesto e memoria istituzionale che vive nelle persone, non nei sistemi. La responsabile del supporto che ricorda che un cliente specifico ha avuto un problema di fatturazione sei mesi fa e adegua il suo tono di conseguenza. Il cofondatore che sa che l’architettura attuale e stata scelta specificamente per evitare un problema di scalabilita incontrato nel 2022.

Puoi documentare parte di tutto questo. Puoi iniettare contesto nei prompt. Ma il contesto profondo, disordinato, che plasma l’intuizione e informa le migliori decisioni? Si accumula nel corso degli anni e vale piu di qualsiasi modello.

7. Relazioni

I tuoi migliori clienti non restano per le tue funzionalita. Restano perche qualcuno nella tua azienda si e preso il tempo di fare una chiamata, capire il loro problema e aiutarli a risolverlo — anche quando la soluzione non era il tuo prodotto.

Siamo l’app di quiz piu recensita sullo Shopify App Store. Ognuna di quelle recensioni e arrivata da un merchant che si e sentito ascoltato. L’IA non ha scritto quelle recensioni. Le relazioni umane l’hanno fatto.

Il video Loom che registri per un cliente confuso. La chiamata di supporto in cui guidi qualcuno attraverso una migrazione. La comunita dove i founder condividono numeri reali e si tengono reciprocamente responsabili. Niente di questo scala attraverso l’automazione. Tutto si compone attraverso la fiducia.

L’IA puo redigere la prima risposta. Puo fare triage dei ticket. Puo tradurre i messaggi. Ma nel momento in cui una conversazione richiede empatia, sfumatura o il semplice atto di preoccuparsi del problema di qualcuno — un umano deve esserci. Gli strumenti che usiamo sono moltiplicatori di forza per gli umani, non sostituti.

8. Dire di no

La competenza piu difficile nel 2026 non e costruire. E non costruire.

Quando l’esecuzione e gratuita, ogni idea viene costruita. Ogni richiesta di funzionalita viene rilasciata. Ogni strumento luccicante viene integrato. Il codebase cresce. Il prodotto cresce. La complessita cresce. E alla fine, stai annegando in funzionalita che nessuno usa, codice che nessuno capisce e un prodotto che fa tutto tranne l’unica cosa di cui i tuoi clienti hanno realmente bisogno.

Dire di no richiede chiarezza (cosa stiamo costruendo?), giudizio (vale la pena farlo?), e gusto (questo ci appartiene?). Richiede guardare una funzionalita perfettamente implementata — codice funzionante, test che passano, demo che sembra fantastica — e dire “Non rilasciamo questo. Non ci appartiene.”

Un agente non dira mai di no. Completera sempre il task. La disciplina di non rilasciare e interamente, irriducibilmente umana.

La matrice di delega

Delegare all’IA	Mantenere umano
Prime bozze di codice e contenuto	Decidere cosa costruire e scrivere
Prima passata di code review	Decisione finale di merge
Triage e categorizzazione del supporto	Chiamate di supporto ed escalation
Ricerca e analisi dei dati	Interpretare cosa significano i dati
Documentazione e SOP	Architettura e design di API
Traduzioni	Voce e giudizio editoriale
Monitoraggio dei concorrenti	Risposta strategica
Investigazione dei bug	Decidere cosa correggere e quando

La colonna di sinistra e produzione. La colonna di destra e direzione. L’IA rende la colonna di sinistra quasi gratuita. Questo rende la colonna di destra quasi inestimabile.

Perche questa e una buona notizia per i bootstrapper

Ogni azienda consolidata con 200 ingegneri ha appena visto il suo moat eroso. Un founder solitario puo ora eguagliare la loro produzione. Ma le aziende consolidate hanno ancora 200 persone che prendono decisioni — e la maggior parte di quelle decisioni viene presa in comitato, il che significa che sono lente, sicure e mediocri.

Un bootstrapper con l’IA ha la produzione di un grande team e la velocita decisionale di una sola persona. Questo e il vantaggio. Non il codice. Non le funzionalita. La capacita di vedere chiaramente, giudicare velocemente e dire di no senza dover programmare una riunione per discuterne.

I founder che faranno fatica sono quelli che hanno automatizzato tutto — comprese le cose sul lato destro di quella tabella. Rilasceranno piu funzionalita, genereranno piu contenuti e costruiranno piu codice di chiunque altro. E niente di tutto cio contera perche nessuno stava al timone.

FAQ

L’IA potra mai gestire queste otto cose?

Forse alcune, parzialmente. Ma la responsabilita non puo essere automatizzata per definizione — qualcuno deve assumersi il risultato. Il contesto e proprietario del tuo business. Le relazioni richiedono un umano dall’altra parte. Anche se l’IA migliora nel giudizio e nel gusto, il founder che comprende queste cose in profondita usera l’IA meglio di chi ha delegato tutto e ha perso il muscolo.

Non e semplicemente “humans in the loop” riformulato?

“Humans in the loop” implica che l’umano e un checkpoint nel processo della macchina. Questo e l’opposto. L’umano e il processo. L’IA e lo strumento. Il founder decide cosa costruire, l’agente lo costruisce. Il founder decide cosa dire, l’agente lo redige. La direzione va dall’umano alla macchina, non il contrario.

Come bilanci velocita e supervisione?

Stabilisci limiti rigidi. A RevenueHunt, l’architettura e il design delle API sono sempre umani. L’implementazione entro confini definiti e delegata all’IA. Ogni modifica passa per /review-staged prima del merge. Rilasciamo meno funzionalita di quante potremmo. Ogni funzionalita che rilasciamo funziona. Quel compromesso e tutto il punto.

Qual e l’errore piu comune che i founder fanno con l’IA?

Automatizzare il giudizio. Usare l’IA per decidere cosa costruire invece di come costruirlo. Nel momento in cui lasci che l’agente stabilisca la direzione — suggerendo funzionalita, scegliendo l’architettura, decidendo le priorita — hai esternalizzato l’unica cosa che rende il tuo business tuo.

---

Questo post si basa su due pezzi collegati: Come un team di 5 persone usa l’IA copre l’assetto pratico. La distribuzione e l’unico moat rimasto spiega perche la produzione non e piu il vantaggio competitivo. Per una prospettiva tagliente su cosa succede quando salti completamente la parte umana, leggi l’articolo di Mario Zechner Thoughts on slowing the fuck down.