Ho passato mesi a costruire un harness indipendente dal modello per fare vero lavoro software con agenti di coding. Alla fine, le caratteristiche tecniche hanno contato molto meno di quanto mi aspettassi. Quello che ha davvero fatto la differenza è stato un pugno di idee che hanno cambiato il mio modo di pensare a come costruire con gli agenti, invece di limitarmi a dare loro prompt.
Queste sono le idee che contano di più. Le prime tre hanno cambiato per davvero il mio modello mentale. Le altre sono cose pratiche che puoi iniziare a usare quasi subito.
1. Congela i criteri di accettazione prima che l'agente inizi
E mettili in un posto dove non possa modificarli.
Questa è probabilmente la svolta più grande per me. Sembra ovvio a posteriori, ma non avevo davvero capito quanto fosse importante finché non l'ho visto in azione.
Se i criteri di accettazione possono cambiare dopo che il lavoro esiste, lentamente si sposteranno verso ciò che è stato prodotto. L'agente non è disonesto, sta semplicemente giudicando il lavoro rispetto a un obiettivo che può ancora muoversi. Se i paletti sono mobili, alla fine si sposteranno.
Non è un problema di prompt, è un problema strutturale, quindi anche la soluzione deve essere strutturale.
Scrivi i criteri di accettazione per primi. Conservali al di fuori dello spazio di lavoro modificabile e blocca automaticamente qualsiasi tentativo di modificarli. Ora l'agente lavora verso un contratto che non può rinegoziare. Il compito non è finito perché l'agente dice che lo è. È finito perché soddisfa il contratto originale.
2. Nessuno dovrebbe valutare il proprio lavoro
Il modello che ha scritto il codice è il peggior giudice possibile per decidere se è corretto. Quando finisce, si è già convinto che la soluzione abbia senso.
Quindi dividi le responsabilità.
Lascia che script deterministici verifichino tutto ciò che è meccanico. Uno script non può inventarsi un codice di uscita di successo. Tratta il modello di coding come un ingegnere, non come un revisore. Poi passa il risultato a un revisore con contesto fresco, uno che non ha mai visto scrivere il codice, per giudicare il design, l'intento e la qualità complessiva.
Questa semplice separazione coglie molti più problemi di quanto mi aspettassi, ed è sorprendentemente economica da implementare.
3. Far rispettare le regole è facile. La calibrazione è la parte difficile.
Questa presa di coscienza ha cambiato il mio modo di pensare all'intero harness.
La maggior parte dei sistemi per agenti, incluse le versioni precedenti del mio, trattano ogni compito più o meno allo stesso modo. La correzione di un errore di battitura di una riga passa attraverso lo stesso processo di una riprogettazione architetturale importante. O è una perdita di tempo, o è troppo rischioso.
La chiave è lo sforzo proporzionale.
Prima classifica il lavoro. È un piccolo cambiamento da cui non dipende nulla, o un'infrastruttura centrale da cui dipende tutto? È logica di business o codice utility generico?
Poi lascia che quella classificazione decida quanto revisione riceve, quale modello dovrebbe gestirlo e quanta autonomia gli è concessa.
Mettere in atto il controllo è facile. Far sì che lo sforzo sia allineato è dove il valore inizia davvero a moltiplicarsi.
Il livello pratico
Una volta messe a posto quelle idee più grandi, alcune pratiche minori hanno dato frutti quasi immediatamente.
- Metti le regole nell'harness, non nel prompt. Un prompt che dice "non fare modifiche nel repo principale" è solo un consiglio. La stessa regola applicata come una chiamata a uno strumento bloccata diventa impossibile da ignorare. Le regole importanti non dovrebbero dipendere dalla scelta del modello di comportarsi bene.
- Mantieni lo stato fuori dalla conversazione e usa un worker nuovo per ogni compito. Archivia i record dei compiti esternamente, usa worktree isolati e processa le modifiche attraverso una coda di merge. Una volta che lo stato è al di fuori della chat, i limiti di contesto smettono di essere il tuo vincolo principale. I compiti diventano paralleli, riprendibili e molto più facili da ragionare.
- La revisione incrociata tra provider è meglio della revisione dello stesso provider. I modelli possono essere più indulgenti con il proprio lavoro che con quello di qualcun altro. Usare un modello di un provider diverso è un modo semplice ed efficace per ridurre quel pregiudizio.
Perché i principi funzionano
Nessuna di queste idee dipende da un modello particolare. Riguardano l'ingegneria dell'harness. Protocolli, verifica, pipeline di revisione e separazione delle responsabilità.
Il modello in cima alle classifiche continuerà a cambiare.
Ma i principi probabilmente no.
Il valore duraturo non è nel modello, e non è nelle caratteristiche tecniche. È nell'impalcatura che costruisci attorno a loro.
