Possiedi l'harness, cambia il modello. Cosa devi possedere davvero

All'inizio mi chiedevo quando smette di convenire possedere l'harness, cioè quando un prodotto nativo sa già abbastanza del tuo ambiente. Per i coding agent la risposta è: adesso. Claude Code e Codex sanno modificare codice, isolare l'esecuzione e agganciare check meglio di quanto farei io. Rifarli sarebbe lavoro buttato.

Quindi lo strato che possiedo è salito di un livello. Sono regole mie, versionate: quale modello fa quale lavoro, dove finisce ogni risultato, cosa può fare un worker, cosa controllo io prima di accettare. Gli strumenti sotto si possono cambiare. Nei prodotti vale lo stesso ragionamento: individua le regole che devi controllare tu e usa sotto quello che esiste già.

Gli autori di DeepSWE hanno controllato i verifier ereditati dai benchmark precedenti, e hanno trovato parecchi test che rifiutano implementazioni corrette o accettano lavoro incompleto. Un «passa» sembra oggettivo, e dipende tutto da chi ha scritto il check.

E un punteggio vale per la coppia modello più harness: il prodotto nativo di ogni vendor è un altro sistema. Per le tue eval: valuta il comportamento che si vede, guarda a mano un campione dei disaccordi, controlla che il verifier accetti modi diversi di fare la cosa giusta. Se usi un modello come judge, dichiara quanto è incerto.

Nell'agente WhatsApp che ho costruito per CVing, piattaforma di recruiting, l'agente può collegare un numero di telefono a un account e inviare candidature. Due azioni con conseguenze vere, per persone vere. Ho deciso di spostare i security check fuori dal prompt e dentro il codice che esegue ogni azione. Il modello può chiedere di collegare un account quanto vuole, anche col tono più convincente del mondo: se in quella conversazione la verifica non c'è, l'azione non parte. Il prompt spiega il comportamento voluto, il codice decide se l'effetto è permesso. Un prompt scritto benissimo resta un'istruzione, e un'istruzione si può aggirare. Lo stesso ordine lo seguo quando un agente ripete un errore nella codebase: prima fixo il codice, poi aggiungo un check, e le istruzioni le scrivo per ultime (perché).

Stessa logica per l'identità. Chi scrive su WhatsApp lo dice il canale, e se il modello prova a usare un numero diverso, vince il canale. Nel Company Brain di Yempik l'azienda su cui agisce un assistente la decide il login della persona. Quello che arriva dal modello è una richiesta da autorizzare.

E i dati già salvati restano non fidati quando tornano davanti al modello: in CVing anche i nomi dei file caricati dai candidati vengono ricontrollati quando si rileggono, perché salvare un dato non lo rende più affidabile. Nessuno di questi passaggi rende immuni dalla prompt injection. Riducono la superficie, e basta.

In CVing una candidatura parte da un link legato a un'offerta di lavoro precisa. Nelle conversazioni lunghe, con tanti dati da raccogliere, il modello a un certo punto perdeva di vista il primo messaggio e si inventava l'offerta. Ho allargato la memoria della conversazione, ma la correzione vera è stata salvare l'offerta attiva come un fatto del sistema, che le azioni usano al posto di quello che ricorda il modello. Una memoria più lunga aiuta a interpretare la conversazione, e la verità di business va scritta da un'altra parte.

Un'altra volta un candidato è rimasto bloccato. La sua verifica era scaduta a metà conversazione, ma l'agente continuava a credere che fosse valida, non chiedeva un nuovo codice e gli ripeteva di controllare l'email, dove non arrivava niente. Da allora una verifica vale per un tempo preciso e decade appena il sistema che la rilascia la rifiuta.

Nello stesso lavoro ho classificato ogni scrittura con una domanda: se la ripeto, faccio danni? Se no, in caso di errore si fa retry. Se l'azione importante è già riuscita e fallisce solo la registrazione, il candidato va avanti e il sistema annota cosa è andato storto. «Blocca tutto a ogni errore» e «retry sempre» suonano rigorosi, e tutti e due rompono il percorso dell'utente.

Mi è capitato con il mio stesso agente. Nel mio second brain le sue ingestioni sono profonde: legge tutta la fonte, tiene numeri, attribuzioni e contraddizioni. In una piattaforma usata da un'intera azienda, scrivendo in una memoria simile da un'altra porta, produceva schede magre. Stesso modello, stessa memoria sotto. Cambiavano le istruzioni che riceveva: da una parte profondità, motivazioni, provenienza e un'idea chiara di quando il lavoro è finito; dall'altra un invito a spezzare tutto in fatti piccoli.

La correzione è stata portare le stesse regole di sostanza su ogni porta d'ingresso, con un check finale, e quanto significato si conservi davvero resta da misurare. Se esponi la stessa memoria da più punti, confronta su ognuno le istruzioni e il criterio di «finito».

Un ranking produce sempre un vincitore, anche quando tutti i candidati sono sbagliati. Nel Company Brain la keyword search era così severa che le domande scritte in modo naturale non trovavano quasi niente. Senza quel riscontro, le domande che col Brain non c'entravano niente tornavano comunque con delle decisioni approvate in cima, solo perché erano le meno lontane.

Abbiamo reso la keyword search più tollerante e deciso che essere primi non basta: un risultato deve superare una soglia di pertinenza misurata sui dati veri, e «non ho niente» è una risposta valida. Quella soglia va rifatta ogni volta che cambia il modo in cui il sistema misura la somiglianza. Il rifiuto va valutato con la stessa cura della ricerca.

L'obiezione più forte all'investire nello strato intorno al modello: i modelli migliorano così in fretta che quello strato diventerà inutile. Il modello che usi oggi però è congelato. In una sessione può arrivare a una scoperta vera, e quella scoperta poi non resta da nessuna parte. In una call con un altro builder l'ho detto così: «una volta che hai avuto una sorta di epifania, non esiste un modo per metterlo in qualche maniera nei suoi pesi».

Per questo investo nel contesto, e chiamo le cose con il loro nome. Quando dico che un company brain diventa più utile, parlo di conoscenza approvata, procedure, esempi ed eval che si accumulano. Il modello resta quello. E anche oggi cambiare modello non si fa in un pomeriggio: va ricontrollato tutto quello che gli sta intorno.

• Elenca le regole che devi controllare tu e usa sotto gli strumenti nativi.
• Metti i check di ogni azione con conseguenze dentro il codice che la esegue.
• Prendi identità e azienda dal login. Quello che chiede il modello va autorizzato.
• Salva i fatti di business fuori dalla conversazione, e dai a ogni verifica una scadenza.
• Testa la capacità della ricerca di dire «niente».
• Costruisci eval sul tuo lavoro e controlla a mano il verifier.

// due delle domande fuori tema che ora tornano a mani vuote: acquisto di snack e cibo per criceti.