Sviluppatori esperti frenano l'adozione degli agenti

“Built isn’t the same as working in production.” La frase è risuonata nell’open space di settembre per il Technology Radar di Thoughtworks. Ha spiegato perché molti sviluppatori esperti restano cauti sugli agenti che scrivono codice¹.

L’autrice racconta sorpresa: queste persone di solito aprono la strada. Sperimentano, creano pratiche, diffondono strumenti. In questa sessione, che rientra nel lavoro semestrale del Radar, hanno invece messo il freno e portato la discussione sul punto cruciale: costruire non basta, conta ciò che regge in produzione¹.

La voce che ha sintetizzato il tema è chiara: “built isn’t the same as working in production”¹. Un agente può assemblare componenti e passare i test locali. Il rischio emerge dopo, quando entrano in gioco carico reale, integrazioni, incidenti. Gli sviluppatori più attenti non confondono un prototipo con un sistema pronto. Chiedono prova sul campo¹.

La fonte non riporta numeri, nomi dei partecipanti o casi specifici. Indica però un orientamento condiviso nella discussione: valutare gli agenti non per la brillantezza del demo, ma per la tenuta operativa¹.

C’è anche un tratto culturale. In Thoughtworks conta costruire la cosa giusta e costruirla bene. La domanda non è “si può fare?”. La domanda è “funziona quando serve davvero?”¹. Questa abitudine sposta il giudizio dai video di presentazione ai criteri di esercizio.

Da qui la riluttanza di chi di solito innova per primo. Non nasce da avversione al nuovo, nasce dal salto tra “ha generato codice” e “regge in produzione”. È un salto fatto di cadute evitate e sistemi stabili. Finché il secondo punto resta senza risposta, l’adozione rallenta¹.

La lezione entra nel Radar. Nel valutare l’agentic development, il criterio “funziona in produzione” pesa più del “sa generare codice”¹. Questo sposta prove e metriche nella fase che segue il build. Non basta mostrare un repository o superare i test unitari. Serve osservare il comportamento del sistema quando gira davvero¹.

Takeaway operativo per chi contribuisce al Radar e per chi lo legge: chiedere evidenze su tre aree, prima di promuovere un agente. Osservabilità, per capire cosa fa l’agente in tempo reale. Affidabilità, per misurare stabilità e continuità del servizio. Recupero dagli errori, per vedere come reagisce a condizioni avverse e come ripristina lo stato corretto¹. Su questi punti si misurerà la reale maturità degli agenti nei prossimi cicli del Radar, più di qualsiasi demo brillante¹.