Dopo che l'Agente ha assunto l'incarico, la prima cosa da stringere è l'unità di lavoro.

Recentemente ho letto molte discussioni su Agent e alla fine torno sempre alla stessa domanda: a chi dovrebbe dare un lavoro, come dovrebbe essere imballato prima di consegnarlo e come verrà accettato dopo essere stato restituito. Una volta che si verifica questo problema in un progetto, la prima cosa che aumenta spesso non è il costo del modello, ma la complessità dell’unità di lavoro. Se il compito è troppo grande, il modello apparirà “come se fosse possibile farlo”; i veri problemi di solito risiedono nel rollback, nella riproduzione e nell’accettazione.

L’unità di lavoro deve prima poter essere accettata

Nei giorni scorsi, dopo aver messo insieme gli appunti frammentati di Martin Fowler e diverse discussioni al Thoughtworks Future of Software Development Retreat, la sensazione più ovvia è che la conversazione durante l’incontro fosse superficialmente frammentaria, ma in realtà ruotava attorno a una sola cosa: consegnare una grossa fetta di lavoro all’Agente.

La finitura di Kief Morris è la più semplice. Diverse sessioni hanno discusso la revisione del codice, gli incidenti di produzione, la divisione del lavoro in team e il routing dei modelli. Sembravano parlare di cose diverse, ma la conclusione si è rivelata la stessa: le persone hanno adattato la dimensione delle “unità di lavoro”. Più grande è l’unità, più facile sarà consegnarla; più grande è l’unità, più difficile sarà accettarla dopo il suo ritorno. Non è che il modello non possa farlo, è che il successivo link di conferma non può reggere prima.

Questo è il motivo per cui l’imbracatura viene menzionata ancora e ancora. Gestione del contesto, sensori computazionali, test basati sulle proprietà, metodi formali, queste cose sembrano strumenti aggiuntivi, ma in realtà raccolgono unità di lavoro. Alcune persone controllano agents.md a meno di 200 righe, non per perseguire la pulizia della forma, ma per forzare il sistema a ricevere solo quella parte delle informazioni che è veramente utile e può davvero essere controllata. Il contesto è troppo vago, ovviamente l’Agente può essere eseguito; ma dopo aver corso, nessuno sa quale strato di vincoli ha inghiottito.

Il self-hosting attiva la superficie di controllo

Anche le discussioni sui modelli self-hosted puntano alla stessa cosa. Quando i token diventeranno più costosi, i requisiti di conformità diventeranno più severi e i dati non potranno più essere divulgati, i modelli open source e locali diventeranno naturalmente più attraenti. Ma una volta che porti tu stesso il modello, hai anche problemi: GPU, sala di inferenza, routing, rollback, messa a punto e selezione del modello. Queste non sono le capacità del modello in sé, ma determineranno se il sistema sarà in definitiva stabile.

Tali costi sono spesso sottovalutati. Molti team inizialmente si sono concentrati su “se il modello fosse più forte”, ma in seguito hanno scoperto che ciò che realmente richiede tempo è il trasferimento stabile di unità di lavoro tra più modelli. Quando utilizzare un modello grande, quando utilizzare un modello leggero e quando utilizzare semplicemente un modello locale, non dipende dalle preferenze verbali, ma da uno strato di superficie di controllo che può essere utilizzato per diversivo e insabbiamento. Senza questo livello di cose, il self-hosting passerà dal “prendere l’iniziativa” all’“assumersi personalmente la complessità delle operazioni e della manutenzione”.

Simon Willison ha accennato al fatto che i modelli più forti scelgano modelli più piccoli per svolgere il lavoro. Questa idea è anche molto simile a ciò che sta facendo il piano di controllo. Il modello in sé non conosce necessariamente i limiti di costo del team, ma il sistema sì. Trattare il modello come un intermediario e utilizzarlo per allocare i compiti è più vicino alla consegna reale che perseguire ciecamente un unico modello per una consegna tutto compreso.

L’accettazione e gli obiettivi non possono essere esternalizzati

“Bring me a Rock” di Sam Ruby ha portato alla luce un altro problema. Affidare l’opera al modello equivale ad aggiungere un esecutore; la responsabilità non scompare. I manager possono utilizzare LLM per l’esplorazione e possono prima lasciare che sputi una serie di soluzioni candidate, ma i criteri di accettazione finali devono ancora cadere nelle mani dell’uomo. Gli obiettivi nascosti sono i più problematici. Autorizzazioni, privacy, azioni distruttive e fuga di contesto spesso non sono incluse nei requisiti originali.

Pertanto i test di conformità sono spesso più utili delle specifiche. Le specifiche sono efficaci nel descrivere “ciò che è richiesto” e i test sono più efficaci nell’esporre “ciò che non può accadere”. Ciò è particolarmente vero nei sistemi ad agenti. Il modello può compensare molto bene gli obiettivi espliciti, ma i confini impliciti devono essere verificati attraverso verifiche più severe. Finché le condizioni di accettazione rimangono vaghe, più l’Agente fa, più il sistema sembrerà scommettere sulla probabilità.

Pertanto, la revisione del codice, la gestione degli incidenti e l’assegnazione delle attività, che in passato erano attività molto umane, stanno ora iniziando ad assumere altre forme. I manager utilizzano direttamente il modello. In superficie sembra che si stia migliorando l’efficienza, ma al livello più basso stanno effettivamente cambiando un metodo di gestione: dalla gestione dei metodi alla gestione degli obiettivi. Se l’obiettivo è scritto chiaramente, il modello avrà la possibilità di funzionare; se l’obiettivo non è chiaro, il modello non farà altro che amplificare l’ambiguità per gli altri.

L’esperienza e le capacità di lettura stanno ancora migliorando

Anche la competenza interazionale e la competenza contributiva menzionate da Dan Davies sono molto rilevanti per questo cambiamento. Il modello può leggere molti materiali ed esprimere un giudizio decente, ma affinché il sistema sia stabile, è necessario che ci sia ancora qualcuno che possa leggere le specifiche, vedere i risultati e sapere cosa c’è che non va. La chiave qui non è che le persone debbano competere con il modello per vedere chi è più intelligente, ma che le persone continuino a restare in una posizione che definisce i confini.

La questione è più semplice quando si tratta della consegna del software. Una volta che l’agente prende il sopravvento, il lavoro umano ricadrà meno sull’esecuzione manuale e più sulla segmentazione delle attività, sulla definizione dei limiti, sulla progettazione dell’accettazione e sulla gestione delle eccezioni. La possibilità di trasferire i compiti determina chiaramente se vale la pena di eseguire la successiva gestione del contesto, l’instradamento del modello e l’orchestrazione degli strumenti. Se l’unità non è chiara, non importa quanti strati ci siano, non farà altro che respingere il problema.

Dopo aver letto questi frammenti nei giorni scorsi, quello che mi è rimasto in mente non è un certo nome di modello, né un nuovo framework, ma un giudizio più semplice: la prima cosa che il sistema Agent deve rafforzare non è la capacità del modello, ma l’unità di lavoro. Se l’unità è più piccola, l’accettazione è più rigorosa e i permessi sono più severi, il sistema avrà l’opportunità di mantenere la complessità entro un intervallo controllabile.