Non stai scrivendo codice, stai gestendo un “team di AI”

La maggior parte delle persone usa i Coding Agent comportandosi ancora da tech lead: architettura controllata di persona, code review riga per riga, ogni riga scritta dall’AI ispezionata prima del commit. La qualità regge, certo. Ma il prezzo? Sei diventato il collo di bottiglia di tutta la linea di produzione. Ogni decisione aspetta te, ogni dettaglio passa da te, e la produttività dell’Agent resta incatenata alla tua attenzione e al tuo tempo.

Gli sviluppatori indipendenti che fatturano davvero hanno fatto un salto di ruolo preciso: da TL a EM. Tradotto: il TL fissa ogni riga di codice, l’EM guarda solo se il risultato funziona. Il TL chiede “questo codice è scritto bene?”, l’EM chiede “questa funzionalità ha superato l’accettazione?”. Sembra una sfumatura. In realtà è la differenza tra “l’output di una persona” e “l’output di un team”.

Perché ora puoi mollare la presa: i modelli hanno superato il punto di svolta

Per lasciare andare serve che la qualità regga. E quest’anno regge: i benchmark pubblici più noti mostrano che i modelli top superano l’80% di accuratezza nel coding, con un distacco netto sulla generazione precedente (punteggi e classifiche variano a seconda della metodologia: vai a vedere i dati aggiornati su Artificial Analysis e SWE-Bench, non fidarti di nessun riassunto di seconda mano, nemmeno del mio).

Cosa significa? Che il codice dell’AI, con una verifica minima, non sbanda. Il beneficio marginale della tua review riga per riga è crollato sotto il punto di convenienza. Continuare a fare il TL significa usare le tue ore più costose per il controllo qualità meno redditizio. Il mercato non paga la tua “tranquillità”. Il cliente paga il risultato consegnato.

Percorso 1: “conferma del piano + obiettivo chiaro” al posto della sorveglianza riga per riga

Come si mette in pratica? Primo passo: cambiare il workflow. Quando hai chiaro cosa costruire, rivedi prima il piano tecnico insieme all’Agent. Piano approvato? Gli consegni obiettivo e piano, e lui esegue: scrive il codice, lancia i test automatici, tutto da solo. Tu fai una cosa sola: al termine, verifichi la funzionalità, non i dettagli del codice.

Ecco un template di prompt per il piano, pronto da copiare:

1
2
3
4

Devo realizzare [descrizione della funzionalità].
Vincoli: [stack tecnico / piattaforma / ambienti da supportare].
Prima produci il piano tecnico: 1) suddivisione in moduli; 2) flusso dei dati; 3) possibili insidie.
Scrivi il codice solo dopo la mia approvazione. Finito, esegui i test e incollami i risultati.

Per l’accettazione usa una checklist che blocca la qualità senza aprire il codice:

• Esegui a mano il flusso principale: nessun errore sul percorso critico
• Prova un caso limite per tipo (input vuoto, input lunghissimo, rete assente)
• I test automatici scritti dall’Agent passano tutti
• Bug? Non aprire il codice. Descrivi il sintomo all’Agent, fallo riprodurre, correggere e coprire con un test. Poi riverifichi tu

Il punto chiave è spostare la verifica a monte. In modalità TL verifichi a livello di codice: costosissimo. In modalità EM verifichi a livello di funzione: qualche click, un giro di prova, pochi minuti. In tutto il ciclo, il tuo tempo va solo su due cose: decidere cosa fare, confermare che è stato fatto bene.

Percorso 2: la scelta tecnologica passa da “cosa so fare” a “cosa serve davvero”

Il cambio di ruolo ha un bonus nascosto: lo stack non è più prigioniero dei tuoi limiti. Da TL scegli istintivamente le tecnologie che conosci, perché se qualcosa si rompe sai ripararlo. Da EM valuti solo quale tecnologia è la migliore per quel progetto. Al resto pensa l’Agent.

Uno sviluppatore indipendente ha raccontato questo percorso (fonte: un suo post, non verificato in modo indipendente): per un’app di traduzione sottotitoli aveva scelto Electron perché veniva dal frontend, ma le prestazioni non lo convincevano. È passato a Swift + AppKit nativo — stack che non conosceva — con l’AI a guidarlo senza intoppi. Per il prodotto multipiattaforma successivo ha puntato direttamente su Rust, mai scritto prima. Giudica tu se la storia è vera, ma la logica è testabile: stasera stesso prendi uno stack che non conosci e fatti guidare dall’Agent in un tool da 100 righe. Vedi se ti blocchi. Il punto è semplice: i tuoi limiti tecnici non sono più una scusa, si sceglie solo ciò che è ottimale.

Percorso 3: la velocità di iterazione diventa il tuo fossato — e facciamo due conti

Quando il meccanismo gira, i tempi di consegna passano da settimane a giorni. Il cliente ti manda la richiesta la mattina e il pomeriggio ha una versione da collaudare. I concorrenti rilasciano una volta a settimana, tu una volta al giorno. Su Subito, Fiverr e Upwork di gente che prende commesse di sviluppo AI ce n’è tanta, ma quasi tutti sono fermi a “l’AI mi aiuta mentre scrivo io”. Tu in modalità EM giochi un altro campionato.

Le chiacchiere stanno a zero, facciamo i conti (stime prudenti, adattale alle tue tariffe):

• Prendiamo la classica commessa “tool/gestionale su misura”: 1.000 € a progetto
• Modalità TL: 5 giorni tra scrittura e correzioni, 4 commesse al mese a pieno carico = 4.000 €/mese
• Modalità EM: piano + accettazione occupano 1,5 giorni; mentre l’Agent esegue, prendi la commessa successiva. Occupazione reale: 2 giorni a progetto, 8-10 commesse al mese = 8.000-10.000 €/mese
• Costi: abbonamento AI al massimo livello ~150 €/mese, tasso di rilavorazione circa 10% con la checklist, mezza giornata di margine per commessa

Stesso mese, differenza di oltre 4.000 €. E in modalità EM il tuo limite è il numero di commesse, non la velocità delle tue dita. Scrivi “versione funzionante in 48 ore” nella tua pagina servizi: è un vantaggio che gli altri non possono copiare.

L’unico vero collo di bottiglia: non sapere cosa costruire

Il modello ha un vincolo reale: quando serve immaginare una nuova versione importante o una nuova direzione di prodotto, l’umano torna a essere il limite. L’Agent, per quanto bravo, esegue solo obiettivi che hai definito tu. Se non sai cosa vuoi, non produce una riga utile.

Quindi la modalità EM alza l’asticella sulle persone — non sulla profondità tecnica, ma sul fiuto per il prodotto. Devi passare il tempo a studiare cosa cercano i clienti su Amazon e Subito, quali problemi urlano i post su Lemon8 e Pinterest, quali tool spopolano su TikTok. Le ore risparmiate non facendo code review vanno tutte investite nel “capire cosa costruire”. È lì che l’umano deve stare, in questo modello.

Parti oggi: tre passi per cambiare ruolo

Se non hai ancora preso una commessa, non pensare subito a raddoppiare la capacità. Ingresso soft: pubblica un annuncio “tool AI su misura” su Subito o Fiverr a 200-350 €, e chiudi il primo lavoro con questi tre passi. Avrai un workflow riutilizzabile e la sensazione reale dei prezzi.

Primo passo: prendi un piccolo progetto che hai in corso e vietati di aprire i file di codice. Solo piano, obiettivi e accettazione funzionale. Vivi un ciclo EM completo e misura i tempi: sono i tuoi dati di prima mano, valgono più di qualsiasi caso studio altrui. Secondo passo: rendi automatico il riflesso “bug → lo descrivo all’Agent per riproduzione e fix”, senza mai tuffarti nel codice. Terzo passo: per il prossimo progetto scegli di proposito uno stack che non conosci ma che è il più adatto, e verifica se l’AI ti porta dall’altra parte.

Il punto di svolta delle capacità di coding dell’AI è già passato. Il vantaggio si sta spostando da “chi sa usare l’AI per scrivere codice” a “chi sa dirigere un team di AI”. Stasera prendi un progetto e fai un giro completo in modalità EM, con il template e la checklist qui sopra.