Un modo di lavorare con l’AI, ancora in evoluzione

Quando il prompt non basta più

Per un compito piccolo e isolato basta una buona richiesta. Poi il lavoro si allunga: più file, più decisioni, più tentativi, magari più agenti. A quel punto ottenere una risposta utile non è più il problema.

Il problema è ricordare perché ho preso una decisione, capire che cosa sta per essere modificato, verificare che il risultato corrisponda a ciò che volevo davvero e impedire che la velocità mi porti fuori strada senza che me ne accorga.

La sequenza che sto usando

Nel LAB il lavoro segue oggi questa sequenza:

Sopra tutto, un principio: Human in Command. È la sequenza che oggi mi permette di vedere dove qualcosa comincia a divergere. Domani potrebbe essere diversa.

Non significa fare tutto a mano

Quando ho iniziato a usare l’AI per sviluppare, temevo soprattutto il codice sbagliato. Con il tempo ho capito che il problema più interessante era un altro.

L’AI fa moltissime cose bene, e proprio per questo diventa facile lasciarle prendere anche decisioni che non avevo deciso di delegare. Può proporre una soluzione, individuare i file da modificare, scrivere il codice, preparare i test, correggere un errore, documentare quello che ha fatto. Tutto utilissimo.

Ma c’è una differenza tra eseguire una decisione e decidere che quella sia la decisione giusta.

Human in Command, per me, è questo. L’umano continua a stabilire dove si vuole arrivare, quali parti del progetto si possono toccare, quali compromessi sono accettabili e quando un risultato è davvero valido.

Non vuol dire controllare ogni riga prodotta dall’AI: se fosse necessario, si perderebbe gran parte del vantaggio. Vuol dire avere abbastanza visibilità da intervenire nei punti che contano.

Un esempio. Un coding agent scopre che, per chiudere un task, deve modificare due file che avevo lasciato fuori dal perimetro. Può essere giusto farlo. Ma voglio essere io a decidere che quella modifica è autorizzata. Lo stesso vale se introduce una nuova dipendenza o propone di cambiare una scelta architetturale: quella decisione deve tornare visibile prima di diventare semplicemente parte del codice.

Prima capire, poi modificare

Uno degli accorgimenti che hanno cambiato di più il mio lavoro con i coding agent è semplice: prima della modifica, chiedere all’agente che cosa pensa di aver capito.

• Che cosa hai capito della richiesta?
• Quali file pensi siano coinvolti?
• Che cosa prevedi di modificare?
• Vedi dipendenze, rischi o effetti collaterali?

Sembrano domande quasi banali. Servono a scoprire una divergenza quando correggerla costa ancora poco.

Se l’agente ha letto male il perimetro, voglio saperlo prima che abbia modificato dieci file.

Non serve sempre. Ma più il progetto cresce, più è utile avere un momento in cui l’interpretazione dell’agente diventa visibile prima dell’esecuzione.

Più piccolo, più visibile, più verificabile

La velocità dei coding agent rende facile chiedere modifiche enormi. Per questo ho cominciato a fare il contrario.

Task più piccoli. Perimetri più espliciti. Modifiche più facili da osservare.

Non voglio ridurre ciò che l’AI può fare. Voglio capire meglio ciò che ha fatto.

Definire un perimetro significa stabilire quali parti del progetto si possono toccare e quali, per quell’attività, restano fuori. Conta ancora di più quando più attività vanno avanti in parallelo.

Dipendenza e interferenza non sono la stessa cosa

La regola di oggi: mai due agenti che scrivono nello stesso punto del progetto allo stesso tempo. Se un giorno smetterà di servire, la cambio.

Finito non significa accettato

Un agente può dichiarare di aver completato un’attività. Questo non vuol dire che il lavoro sia concluso.

La verifica è il momento in cui confronto ciò che è stato fatto con ciò che avevo davvero chiesto. Controllo:

• il diff, cioè il confronto riga per riga tra prima e dopo;
• i test;
• le modifiche fuori perimetro;
• le nuove dipendenze;
• i warning tecnici;
• i criteri di accettazione;
• gli eventuali effetti collaterali.

Quello che voglio evitare è la verifica circolare: “hai finito?” — “sì”.

La verifica deve produrre qualcosa di osservabile. Non per forza complesso, ma abbastanza da distinguere un risultato plausibile da un risultato verificato.

Ricordare meno, ma meglio

Lavorare con l’AI produce una quantità enorme di memoria: chat, prompt, codice, assessment, decisioni, documenti, tentativi falliti.

Salvare tutto non significa ricordare meglio. Spesso succede il contrario.

Con VIBE APP sto esplorando una domanda: che cosa vale davvero la pena conservare? Per ora gli elementi che sembrano più utili sono quattro:

L’obiettivo è il minimo contesto utile per riprendere il lavoro senza ricostruire ogni volta tutto da zero.

Non solo errori dell’AI

È facile dare la colpa all’AI. Ma molti degli errori più utili che ho incontrato non erano errori del modello. Erano una richiesta troppo ampia, un perimetro lasciato implicito, un contesto insufficiente, un task troppo grande, una regola che aveva senso un mese fa e oggi no, oppure una decisione rimasta soltanto nella mia testa.

Per questo tratto l’errore come materiale dell’esperimento: qualcosa da correggere, ma anche qualcosa che deve lasciare una traccia nel tentativo successivo.

Una regola vale finché risolve un problema reale. Quando smette, deve poter cambiare.

Lo stesso problema, osservato da lati diversi

Alcuni strumenti nati nel LAB cominciano a collegarsi fra loro. Non sono ancora una suite: sono esperimenti che guardano lo stesso problema da punti diversi.

AI locale

Un modello AI locale è un’idea affascinante: lo installo sul mio computer e gli affido alcune attività, invece di interrogare sempre un servizio cloud. Ma conoscere il linguaggio non vuol dire conoscere il mio progetto. Il modello non sa com’è fatta l’architettura, quali decisioni abbiamo già preso, quali regole sono nate dopo un errore, quali parti considero stabili.

Quindi la domanda non è se giri sul PC, ma quanto lavoro serve per renderlo utile dentro quel progetto. A volte può bastare dargli ogni volta il contesto giusto. Altre volte potrebbe servire specializzarlo, fino al fine-tuning, che non è gratuito: servono dati, preparazione e un motivo concreto.

Per questo, nel mockup di VIBE APP, l’AI locale è una domanda aperta e non una funzione pronta.

Per ora non ho una risposta. È il tipo di domanda per cui esiste il LAB.

Il metodo è ancora una domanda

La parte più interessante di questa pagina non è ciò che prova a fissare, ma ciò che continua a mettere in discussione.

Questa pagina cambierà se gli esperimenti dimostreranno che alcune delle idee raccolte qui non funzionano. È quello che mi aspetto da un metodo ancora vivo.