Da sviluppatore a AI-directed engineer: cosa cambia nel lavoro di tutti i giorni

Fino a poco tempo fa passavo gran parte della giornata a scrivere codice. Oggi la passo a scrivere task per agenti di coding, a leggere quello che producono e a decidere cosa entra in main. Sono Senior AI Engineer in Mokka Studios, sono CTO di IGEA e nella prima metà del 2026 sono stato tech lead del backend AI di Estyl. In tutti e tre i casi il codice deve funzionare e la responsabilità resta mia. È cambiato dove vanno le ore.

Racconto questo passaggio con il setup che uso davvero, così uno sviluppatore può capire se lavorare in questo modo e un CTO può capire cosa chiedere al proprio team.

Cos'è un AI-directed engineer?

Un AI-directed engineer è uno sviluppatore che delega quasi tutta la scrittura del codice agli agenti di coding e tiene per sé il lavoro di ingegneria: decidere cosa costruire, spezzarlo in task che un agente può portare a termine, fissare le regole che gli agenti devono seguire e rivedere ogni diff prima del rilascio. L'agente scrive la prima bozza. Design, test e merge restano all'ingegnere.

Gli strumenti ormai li usano quasi tutti. Nello Stack Overflow Developer Survey 2025, l'84% di chi ha risposto dice di usare o di voler usare strumenti AI nello sviluppo, e il 46% dice di non fidarsi dell'accuratezza di quegli strumenti (Stack Overflow Developer Survey, luglio 2025). I due numeri insieme spiegano il mestiere: si usano tanto e ci si fida poco, quindi il lavoro si sposta su specifica e revisione.

Com'è la giornata tipo di un AI-directed engineer?

La mia giornata si divide in quattro attività, e nessuna è scrivere codice per ore di fila.

• Scrivere task: un brief breve per ogni modifica, con obiettivo, file coinvolti, criteri di accettazione e cosa non va toccato.
• Far girare agenti in parallelo, ognuno nel proprio git worktree, così due agenti non modificano mai la stessa copia del repo.
• Rivedere: leggere i diff, lanciare i test, rimandare indietro il lavoro con una nota precisa.
• Decidere: cosa va in merge, cosa si taglia, quale task viene dopo.

Il parallelo si regge su due strumenti open source. herdr è un multiplexer da terminale pensato per gli agenti di coding: ogni workspace ospita un agente e vedo a colpo d'occhio chi lavora, chi è bloccato e chi ha finito. treehouse gestisce un pool di git worktree riutilizzabili e ne assegna uno in prestito a ogni agente, che lo restituisce a lavoro finito. Le mie istruzioni globali per gli agenti lo dicono in modo secco: se devi modificare file in un repo, apri prima un worktree. La sessione principale fa da orchestratore e non tocca il codice; ogni sessione figlia ha un branch, un task, e segnala quando ha finito o quando aspetta una risposta.

Il mio lavoro sta tutto lì: smistare i task, rispondere alle domande dei worker, rivedere i risultati.

Quali regole tengono in carreggiata gli agenti di coding?

Gli agenti seguono le regole che possono leggere. Quelle che restano nella mia testa vengono violate a ogni task, quindi le regole devono stare in file dentro il repo. Su questo sito, che gira su Next.js e Sanity, il setup è piccolo e funziona:

• Un CLAUDE.md nella root con le regole non negoziabili: TDD (prima un test che fallisce, poi il codice), solo pnpm, mai aprire pull request, ogni nuova stringa tradotta va aggiunta sia in italiano sia in inglese.
• Un CODING_STANDARDS.md contro cui viene rivisto ogni diff.
• Skill: file di istruzioni brevi per i lavori che si ripetono. Ce n'è una per il TDD, una per i test e una per gli articoli del blog, che fissa struttura, limiti SEO e regole sulle fonti seguite anche da questo articolo.
• Un flusso di rilascio che lancia agenti di review in parallelo sul diff (uno controlla solo la qualità dei test), poi lint, typecheck e test, e fa il merge solo se passa tutto.
• Git hook che reinstallano le dipendenze dopo un checkout o un rebase se il lockfile è cambiato, così un agente non prova a "sistemare" un errore causato da pacchetti vecchi.

La regola che lavora di più è scrivere i test prima. Un test che fallisce è la descrizione più precisa che posso dare a un agente: dice cosa vuol dire "fatto" e non lascia margine di interpretazione. Senza test finisco a rivedere intenzioni invece di comportamenti.

Quali competenze contano davvero per un AI-directed engineer?

Sono cinque le competenze che decidono se questo modo di lavorare conviene.

La prima è la scomposizione. Un task che un agente porta a termine bene tocca pochi file, ha un obiettivo solo e si verifica con un test. "Rifai il backend" non funziona. "Sposta il log dei costi nel client condiviso e aggiungi un test che verifichi che ogni chiamata scriva una riga di costo" funziona.

La seconda è scrivere task chiari. Un buon brief indica i file, il comportamento atteso, i vincoli e cosa resta fuori. Gli agenti riempiono i vuoti con ipotesi plausibili, e ogni ipotesi è qualcosa che devo intercettare in review.

La terza è leggere i diff in fretta, ed è quella che vedo sottovalutare di più. Quando più agenti consegnano nella stessa giornata, la velocità di review decide quanto produce il team. Io leggo prima i test, poi le interfacce, poi l'implementazione.

La quarta sono i test. Chi non sa scrivere un buon test non sa dare a un agente una buona specifica.

La quinta è dire di no all'over-engineering. Gli agenti aggiungono astrazioni, opzioni di configurazione e livelli di helper che nessuno ha chiesto. Gran parte delle mie note di review sono cancellazioni. Quando ho riscritto le pipeline AI di una piattaforma consumer di finanza, il taglio dei costi AI di circa l'80% è arrivato togliendo chiamate al modello ridondanti e contesto inutile. È lo stesso istinto che uso sul codice degli agenti: togliere.

Cosa non cambia quando il codice lo scrivono gli agenti?

La responsabilità resta dov'era. Se un agente scrive un bug e io lo porto in produzione, il bug è mio. Nei settori regolamentati questo pesa di più: in Sprint Reply ho costruito un agente LLM che smista oltre un milione di ticket l'anno per l'help desk di una banca italiana, e nessuno in banca accetterebbe "l'ha scritto il modello" come spiegazione per un reclamo finito nella coda sbagliata. Lo stesso vale per l'agente vocale di IGEA che risponde alle chiamate dei pazienti di una clinica, dove in più ci sono dati sanitari e GDPR.

Anche la comprensione del sistema resta all'ingegnere. Per rivedere un diff devo sapere come funziona il sistema: da dove arrivano i dati, come si rompe, quali parti sono fragili. Chi smette di capire il sistema diventa un timbro, e gli agenti producono codice plausibile più in fretta di quanto un timbro riesca a trovarne gli errori.

Il design resta umano. Gli agenti sono bravi a riempire una struttura. Scegliere la struttura, decidere quale modulo fa cosa e dove passano i confini, è ancora una decisione di chi progetta, e gli agenti la rispettano meglio quando è scritta.

Come introduce un CTO il lavoro AI-directed nel team?

Si parte dalle regole, prima di comprare altre licenze. Un team che mette per iscritto standard di codice, regole sui test e convenzioni del repo ottiene dagli agenti un output coerente. Un team che salta questo passaggio si ritrova uno stile diverso in ogni pull request.

Poi si sceglie un repo e si mettono le basi: un file di istruzioni nella root, test veloci, un controllo di lint e typecheck, un passaggio di review obbligatorio per ogni modifica. Si misura cosa arriva in produzione e cosa viene annullato. Le righe di codice prodotte qui non dicono nulla, perché gli agenti ne producono quante se ne vuole.

Infine si cambia cosa si chiede ai senior. Il loro valore si sposta su specifiche, review e capacità di dire di no. Se vengono ancora valutati su quanto codice scrivono, gli incentivi vanno nella direzione sbagliata. Per le aziende italiane che lavorano con banche o sanità c'è un motivo in più: quando un cliente o un auditor chiede chi ha approvato una modifica, la risposta deve essere una persona.

Quali sono gli errori più comuni nel passaggio al lavoro AI-directed?

• Far lavorare più agenti nella stessa copia del repo. Due agenti nella stessa cartella producono conflitti e diff mescolati. Un worktree per agente risolve il problema.
• Saltare i test perché l'agente è veloce. Senza test la velocità serve solo ad avere prima codice non verificato.
• Approvare diff lunghi senza leggerli. Se un diff è troppo lungo da rivedere, il task era troppo grande: va spezzato e rifatto.
• Dare le regole in chat invece che in un file. Una correzione scritta in una sessione si perde nella successiva. Va messa nel CLAUDE.md o in una skill.
• Accettare astrazioni in più perché sembrano professionali. Ogni livello aggiunto da un agente è codice che qualcuno dovrà mantenere.
• Lanciare più agenti di quanti se ne riescano a rivedere. Il limite è la review: oltre quella soglia cresce solo la coda.

Se oltre a usare l'AI per sviluppare costruite prodotti basati sull'AI, qui trovate come lavoro sullo sviluppo di agenti AI per aziende regolamentate.