Come ho smesso di preoccuparmi e ho imparato ad amare (con cautela) gli agenti AI

Ti racconto il momento esatto in cui ho capito che dovevo cambiare il mio approccio agli agenti AI.

Ero bloccato da tre ore a debuggare una funzionalità "semplice" scritta da uno dei miei agenti. L'agente aveva fatto commit, push in produzione, e lasciato persino un messaggio allegro di completamento. C'era solo un piccolo dettaglio: il codice era completamente sbagliato. Non pieno di bug. Sbagliava completamente quello che doveva fare.

Quell'incidente mi ha fatto crollare un castello di carte. Pensavo agli agenti come a sviluppatori junior che avevano bisogno di guida. Ma gli sviluppatori junior non fanno push in produzione mentre dormi.

Così ho cambiato metafora.

Il modello del subappaltatore

Invece di trattare gli agenti AI come dipendenti o assistenti, li tratto come subappaltatori. Ecco cosa significa nella pratica.

Un subappaltatore non ha le chiavi del tuo edificio. Non si presenta senza invito. Completa il lavoro e ti presenta il preventivo—che tu controlli prima di pagare. Se il lavoro è scadente, lo rispedisci indietro.

Non è questione di sfiducia. È questione di allineare gli incentivi e di responsabilità. Quando un subappaltatore sa che il suo ruolo è consegnare un risultato per la tua revisione—nota, non prendere decisioni in autonomia—lavora meglio. È concentrato. È produttivo dentro limiti precisi.

La parte tecnica

Questo modello mentale ha bisogno di denti tecnici. Per i miei progetti significa questo.

I token fanno la differenza

I miei agenti operano con credenziali che fisicamente non possono toccare la produzione. Hanno accesso in lettura al codebase principale e accesso in scrittura a un repository di staging separato. Non è una policy—è un vincolo crittografico. Anche se un agente impazzisce o produce comandi git inventati, non può modificare codice di produzione. I token semplicemente non glielo permettono.

Il repository di staging è una cassetta delle lettere

Niente va in merge da staging automaticamente. Il branch principale del repository di staging è letteralmente una tomba—un branch chiamato "no-main" che contiene solo un README che dice "usa il branch principale del repository originale."

Gli agenti fanno push del loro lavoro qui. Mi avvisano quando i branch sono pronti. Poi io controllo, faccio cherry-pick di quello che funziona, e integro manualmente. Sembra tedioso finché non capisci: è esattamente come funziona il kernel Linux da vent'anni. I contributor mandano patch. I maintainer le applicano.

La revisione non è negoziabile

Nessun agente fa mai merge del proprio codice. Punto. Un branch non viene cancellato finché non ho verificato—in modo indipendente, programmaticamente—che i suoi commit siano al sicuro dentro produzione. "Fidati ma verifica" non basta quando la verifica è gratis.

Perché funziona per chi sviluppa da solo

Ecco il punto sui developer singoli o sui team piccoli: non stai solo costruendo software. Stai mantenendo un contesto che non esiste da nessuna parte nel codebase. La tua storia di incidenti. I tuoi edge case. Il cliente con una configurazione strana. Le tre cose che hai provato che non hanno funzionato.

Gli agenti hanno accesso zero a questo contesto. Leggono i file, ma non capiscono il tuo mondo. Quindi l'obiettivo non è dare loro più autonomia—è massimizzare il lavoro che possono fare in sicurezza dentro la tua banda di revisione.

È qui che "vibe coding" si guadagna una brutta reputazione. Fatto male, vibe coding significa lasciar fare agli agenti quello che vogliono e sperare che funzioni. Fatto bene, significa usare l'AI come amplificatore del tuo giudizio, non come sostituto.

Il vantaggio pratico

Quando accetti la relazione con il subappaltatore, succede qualcosa di inaspettato: inizi a rischiare di più. Sei disposto a provare quella funzionalità sperimentale perché lo svantaggio è limitato. L'agente non può rompere la produzione. Può consegnare qualcosa di sorprendente e sbagliato, o sorprendentemente buono—ma in entrambi i casi, lo prendi prima che faccia danni.

Ho iniziato più side project negli ultimi sei mesi che nei due anni precedenti. Non perché lavoro di più—perché delego aggressivamente dentro confini sicuri.

Come costruirlo nel tuo workflow

Se stai usando agenti AI per lo sviluppo, chiediti:

1. Cosa può toccare il mio agente adesso? Se la risposta è "produzione," hai un problema.
2. C'è un vincolo tecnico che impedisce azioni sbagliate, o solo una policy?
3. Chi fa merge del codice? Se non è un umano, perché?

Gli strumenti esistono. Token scoping, repository di staging separati, branch protection—non sono workflow Git esotici. Sono la differenza tra sviluppo assistito da AI e disastri accidentali da AI.

Il tuo giudizio è ancora il collo di bottiglia. Non è una limitazione—è il punto. Gli agenti esistono per amplificare quello che puoi fare, non per sostituire il giudizio che fa funzionare il software per utenti reali.

Costruisci di conseguenza.