Adesso il codice lo scrivono gli agenti. Ecco cosa è diventato il mestiere dello sviluppatore.

La domanda torna a ogni tavolata in cui qualcuno ha uno sviluppatore in famiglia: se il codice lo scrive la macchina, cosa resta?

La risposta onesta è che la domanda punta alla parte sbagliata del mestiere. Scrivere codice non è mai stato tutto il mestiere. Era la parte visibile, quella che assomigliava a un lavoro per chiunque passasse dietro la scrivania. Ed era anche, quasi tutte le settimane, la più piccola.

Quello che è stato automatizzato non è mai stato tutto il mestiere

Tutto quello che arriva in produzione attraversa sei anelli:

1. Qualcuno vuole qualcosa, e lo dice male.
2. Qualcuno decide che vale la pena farlo, e quando.
3. Qualcuno lo trasforma in una descrizione abbastanza precisa da poterci lavorare.
4. Qualcuno lo costruisce.
5. Qualcuno verifica che non abbia rotto qualcos'altro.
6. Qualcuno lo rilascia e avvisa chi aveva chiesto.

Gli agenti hanno preso l'anello quattro. Lo hanno preso in modo convincente, e continueranno a migliorare. Quello che quasi nessuno dice ad alta voce è l'effetto sugli altri cinque: si appesantiscono, non si alleggeriscono.

Il motivo sta nel ritmo di produzione. Quando costruire richiedeva due settimane, i cinque anelli intorno avevano due settimane per svolgersi. Erano lenti perché era lento il centro, e nessuno si accorgeva che fossero lenti. Quando costruire richiede un pomeriggio, tutto il resto diventa il collo di bottiglia, e ci diventa tutto insieme.

Un anello è crollato. Gli altri cinque portano adesso il peso che quell'anello nascondeva.

È tutta qui la storia, e il resto di questo articolo racconta a cosa somiglia ognuno dei cinque quando ti tocca davvero occupartene ogni giorno.

Anello 1: ascoltare cosa costruire, senza perderne metà

Il nuovo modo di fallire è preciso ed è caro: puoi costruire qualsiasi cosa, quindi costruisci la cosa sbagliata più in fretta.

Le richieste arrivano da ogni parte. Un messaggio in un thread di supporto. Una frase alla fine di una call. Una lamentela sui social. Una segnalazione di bug che in realtà è una richiesta di funzionalità travestita. Storicamente non aveva grandi conseguenze, perché tanto potevi costruire una cosa sola ogni due settimane, e quella ovvia di solito era anche quella giusta. Adesso che puoi costruirne cinque a settimana, la differenza tra le cinque giuste e le cinque sbagliate è la maggior parte del tuo anno.

Devono succedere due cose, e sono due cose diverse.

Primo, raccogliere deve costare poco a chi chiede. Se un utente deve aprire un account, trovare un modulo e descrivere il problema due volte, la maggior parte lascerà perdere, e quelli che restano non sono un campione rappresentativo. Una bacheca di feedback pubblica dove chiunque può depositare una richiesta, allegare uno screenshot e seguire che fine fa toglie di mezzo quell'attrito. Le persone che usano il prodotto scrivono le richieste da sé, con parole loro, con il contesto attaccato.

Secondo, lo smistamento deve essere automatico, perché il feedback grezzo non resta utile a lungo. Venti messaggi che dicono più o meno la stessa cosa sembrano venti problemi finché qualcuno non li legge tutti e venti e si accorge che sono uno solo. È esattamente il lavoro per cui nessuno ha tempo. Idea Radar è la nostra risposta: i segnali grezzi atterrano intatti, si raggruppano da soli in temi, i quasi doppioni vengono accostati prima di diventare due lavori, e ogni idea porta con sé il numero di persone distinte che l'hanno chiesta. Il verbatim non viene mai riscritto, perché le parole esatte che qualcuno ha usato sono il dato.

Quello che esce da questo anello non è un backlog. È un corpus che puoi leggere.

Anello 2: decidere, la risorsa diventata scarsa

Una bacheca di idee non è un piano. Trasformare l'una nell'altro è il giudizio che una volta era spalmato su un trimestre e che adesso deve avvenire ogni settimana.

Qui contano due mosse.

La promozione è deliberata. Un'idea diventa un ticket del backlog quando qualcuno decide che vale la pena costruirla, non quando viene depositata. Tutto il resto resta visibile sul radar con il suo contatore di richiedenti, che è lo stato onesto delle cose: sentito, non programmato. Un backlog in cui l'ottanta per cento delle righe non verrà mai costruito non è un piano, è un archivio con un'impaginazione ingannevole.

La definizione avviene prima della costruzione, non durante. Un feedback confuso diventa un mockup validato che la persona che ha chiesto può guardare e confermare. Cinque minuti di conferma battono un pomeriggio passato a costruire lo schermo sbagliato, e quel conto è diventato nettamente più conveniente da quando quel pomeriggio di costruzione è diventato un pomeriggio di tempo di agente che avresti potuto spendere altrove.

Anello 3: definire il lavoro, il mestiere che ha sostituito la digitazione

È qui che è finita la competenza vera.

Un agente non contesta un'istruzione ambigua come farebbe un collega. Non ti dirà «aspetta, quale dei due flussi di pagamento intendi». Riempie il vuoto con un'ipotesi plausibile e ti consegna qualcosa di coerente e sbagliato. Il costo dell'ambiguità una volta era una conversazione. Adesso è un diff.

Quello che separa chi ottiene buoni risultati da chi passa la giornata a combattere con i propri agenti non è l'astuzia nel prompt. È il contesto riutilizzabile. Quattro forme, in ordine decrescente di quanto rendono.

Il contesto che gli agenti leggono prima di esplorare. I file di convenzioni versionati (CLAUDE.md, AGENTS.md) e una memoria di progetto che tiene le decisioni di architettura, le trappole già incontrate e il motivo per cui le cose stanno come stanno. Scritto una volta, letto da ogni agente su ogni macchina, per sempre. È la scrittura a più alto rendimento che uno sviluppatore produce oggi, e quasi nessuno le alloca del tempo.

Le procedure, salvate come procedure. La decima volta che spieghi la tua checklist di rilascio non stai definendo un lavoro, lo stai ribattendo a mano. Una libreria di skill trasforma una procedura ricorrente in qualcosa che un agente carica quando il compito corrisponde, e una libreria di prompt fa lo stesso con i brief.

Mostrare invece di descrivere. Un paragrafo che descrive un pulsante disallineato vale meno di un'immagine del pulsante disallineato. Manda una porzione di schermo direttamente, o disegnaci sopra per indicare la cosa di cui parli. Per una pagina web, passare all'agente il DOM dal vivo batte qualunque descrizione, ogni volta.

Parlare invece di digitare. Un brief detto in tre frasi porta più sfumature dell'unica frase che ti saresti preso la briga di scrivere. La dettatura vocale per un'istruzione rapida, la modalità voce quando vuoi il botta e risposta senza toccare la tastiera. Sembra una comodità. In pratica è banda passante: le persone dicono più di quanto scrivano, e un agente è limitato da quello che gli dici.

I primi tre si pagano a ogni compito. Il quarto si paga una volta e si incassa per sempre.

Anello 4: pilotare il lavoro, sulla macchina giusta

Un agente è uno strumento. Più agenti sono un sistema, e un sistema ha bisogno di un operatore.

Le domande pratiche non sono affascinanti, e sono il mestiere. Cosa può girare in parallelo senza che due agenti modifichino lo stesso modulo? Quale compito merita la tua attenzione mentre gira e quale no? Cosa deve girare mentre dormi?

L'ultima domanda determina dove il lavoro viene eseguito. Tutto quello che potresti dover interrompere, correggere o riorientare strada facendo resta sulla macchina che hai davanti. Il lavoro lungo, ben definito, senza zone d'ombra va altrove: un altro computer che possiedi o un server via SSH, così che un lavoro da due ore non ti tenga in ostaggio il portatile. Il lavoro ricorrente va su una pianificazione. La domanda che decide non è mai la potenza bruta, è quanto è probabile che tu debba intervenire.

Quando un lavoro ha fasi davvero diverse, un agente solo è la forma sbagliata. Una costruzione che va poi testata e poi rivista sono tre mestieri con tre competenze diverse, e i team di agenti ti permettono di disegnare quel passaggio di consegne in modo esplicito invece di rispiegare il contesto a ogni passo.

E siccome niente di tutto questo richiede che tu sia seduto lì, pilotare dal telefono smette di essere un gadget. Leggere la domanda di un agente e rispondere in venti secondi da un treno è la differenza tra un compito finito e un compito che ti ha aspettato quattro ore.

Anello 5: rivedere, dove abita la responsabilità

È l'anello che non si delega, e il motivo non è tecnico.

Gli agenti hanno già sostituito gran parte della lettura riga per riga. Quello che non possono prendersi è la firma. La responsabilità non si trasferisce a un modello. Quando una migrazione cancella una colonna in produzione, «l'ha scritto l'agente» non è una frase che qualcuno accetti, ed è giusto così.

Quello che cambia è la forma della revisione, non la sua esistenza. Leggere ogni riga non sopravvive all'incontro con cinque agenti in parallelo, e un umano che scorre un diff di novecento righe alle sei di sera produce una firma senza produrre conoscenza. La regola che regge è rivedere in proporzione al raggio d'azione: i testi e lo stile si scorrono, mentre autenticazione, pagamenti, permessi, dati personali e migrazioni si leggono riga per riga, ogni volta, da qualcuno che avrebbe saputo scriverle.

Due cose lo rendono praticabile. Poter vedere un diff per agente invece di un mucchio fuso insieme ti dice chi ha cambiato cosa quando in tre hanno lavorato nello stesso repository. E attaccare la conversazione al commit risponde alla domanda che sei mesi dopo costa davvero tempo, che non è mai «cosa è cambiato» ma «perché».

Per tutto quello che ha un'interfaccia, la verifica non si ferma al diff. Un agente che pilota un browser vero può ripercorrere il flusso che ha appena costruito e riferire quello che ha visto, il che intercetta la categoria di bug che nel codice sorgente si legge benissimo.

A dove spendere quell'attenzione abbiamo dedicato un articolo intero: dovresti ancora rivedere il codice del tuo agente IA.

Anello 6: rilasciare, e chiudere il cerchio

Rilasciare è la metà facile di questo anello. La metà che si salta è avvisare chi aveva chiesto.

Ed è anche quella che rende di più. Un utente che segnala qualcosa e più tardi viene a sapere che è stato rilasciato segnalerà anche la volta dopo. Un utente che segnala nel silenzio smette di segnalare, e tu perdi la materia che alimentava l'anello uno. Quando si chiude un ticket nato da una richiesta pubblica, chi l'ha depositata deve venirlo a sapere senza che nessuno debba ricordarsi di mandare una mail.

Prima di questo c'è di solito qualcuno che deve vedere la cosa funzionare e che non ha il tuo ambiente di sviluppo: un cliente, un designer, un collega su un altro continente. Un URL HTTPS pubblico che punta alla tua macchina locale trasforma tutto questo da un deploy in un link, e il feedback che torna indietro riparte dritto nell'anello uno.

La catena si richiude. È questo che ne fa un mestiere invece di una coda.

Cosa si è davvero ristretto e cosa è davvero cresciuto

Leggi quella tabella con onestà e l'ansia cambia forma. Le parti che si sono ristrette sono quelle per cui era più facile assumere. Le parti che sono cresciute sono quelle che richiedono qualcuno che capisca il sistema, gli utenti e le conseguenze. È un mestiere più difficile, non un mestiere più piccolo, ed è parecchio meno solitario della versione in cui si digitava tutto il giorno.

Dove si colloca AgentsRoom in tutto questo

Costruiamo lo strumento che tiene insieme l'intera catena, perché l'alternativa sono sei strumenti che non si conoscono tra loro.

In concreto: le richieste atterrano su una bacheca, si ordinano da sole in idee, vengono promosse a ticket, vengono definite in qualcosa che un agente non può fraintendere, vengono eseguite da un agente o da un team di agenti sulla tua macchina o su una remota, vengono riviste agente per agente con la conversazione attaccata, e vengono chiuse avvisando chi aveva chiesto. Una finestra sola, un solo posto in cui lo stato del lavoro è vero.

I pezzi singoli esistono altrove. Erano i collegamenti tra loro quello che nessuno rilasciava, ed è nei collegamenti che il lavoro si perde.

Le domande che si fanno davvero

L'IA sostituirà gli sviluppatori?

Ha sostituito la digitazione, non il mestiere. Scrivere codice è un anello di una catena che contiene anche: ascoltare di cosa hanno bisogno gli utenti, decidere cosa vale la pena costruire, definirlo con precisione, pilotare l'esecuzione, verificare e rilasciare. Gli agenti hanno fatto crollare il costo di un anello, e questo ha reso gli altri cinque il collo di bottiglia. Meno persone verranno pagate per produrre righe di codice. Più persone vengono pagate per decidere quali righe devono esistere e per risponderne una volta che sono in produzione.

Cosa fa davvero uno sviluppatore quando il codice lo scrivono gli agenti?

Sei cose, e una sola era visibile su uno schermo pieno di codice. Raccogli quello che le persone chiedono, decidi cosa costruire e in che ordine, definisci il lavoro con abbastanza precisione perché un agente non possa fraintenderlo, mandi avanti più lavori insieme senza perderne il filo, rivedi in proporzione a quello che ogni modifica può rompere, e rilasci avvisando chi aveva chiesto. Il mestiere si è spostato dal produrre la modifica allo specificarla e al risponderne.

Serve ancora saper programmare?

Sì, e più di prima per la lettura. Non hai più bisogno di ricordare la sintassi di un linguaggio che tocchi due volte l'anno, perché la scrive l'agente. Hai bisogno di aprire un diff e capire in pochi secondi se una migrazione è reversibile, se un controllo di autenticazione si è spostato, se una query reggerà dieci volte il traffico. Chi non sa leggere il codice non può rivedere un agente, e chi non può rivedere un agente non lo sta pilotando: sta sperando.

Cosa si rompe per primo quando affidi il codice agli agenti?

La prioritizzazione. Quando costruire richiede un pomeriggio invece di due settimane, il costo di costruire la cosa sbagliata sparisce dal radar, quindi la si costruisce. I team si ritrovano con più funzionalità rilasciate e nemmeno un problema in più risolto. La seconda cosa che si rompe è il ciclo di ritorno: le richieste degli utenti arrivano più in fretta di quanto chiunque riesca a smistarle, si accumulano nei thread di chat e si perdono, e la stessa richiesta viene costruita due volte perché nessuno si è accorto che era la stessa.

Qual è la competenza più difficile in questo nuovo modo di lavorare?

Scrivere un brief che un agente non possa fraintendere. Un agente non contesta un'istruzione ambigua come farebbe un collega, quindi riempie i vuoti con un'ipotesi plausibile e consegna qualcosa di coerente e sbagliato. Chi ottiene buoni risultati non è chi ha prompt astuti, è chi tiene in piedi del contesto riutilizzabile: file di convenzioni versionati, una procedura salvata per ogni compito ricorrente, una memoria di progetto che gli agenti leggono prima di esplorare, e screenshot o schizzi al posto di paragrafi che descrivono uno schermo.

Gli agenti di codice conviene farli girare sulla tua macchina o su una remota?

Entrambe le cose, scelte compito per compito. Tutto quello che vuoi guardare, interrompere o correggere strada facendo resta sulla macchina che hai davanti. Il lavoro lungo, ben definito, senza zone d'ombra va su un'altra macchina che possiedi o su un server via SSH, così che un lavoro da due ore non ti tenga in ostaggio il portatile. La domanda che decide non è la potenza, è quanto è probabile che tu debba intervenire.

In breve

Il mestiere non è sparito. È uscito dall'editor e si è sistemato nella catena che gli sta intorno.

Se vuoi cambiare una cosa sola questo mese, prendi l'anello uno. Tutto quello che sta a valle è fatica sprecata quando punta al problema sbagliato, ed è l'unico anello in cui un'ora della tua attenzione batte ancora un'ora di tempo di agente, con un rapporto che nessuno sa misurare.