Il costo non sparisce, migra: lo sviluppo nell'era degli agenti

Scrivere codice sta diventando economico. Specificarlo e verificarlo, no. È tutta qui la tesi: con gli agenti il costo dello sviluppo non sparisce, migra. Si sposta da dove stava — produrre righe di codice — a dove conta davvero: dire con precisione cosa va costruito e dimostrare che quello che è stato costruito è giusto.

Quello che segue sono note di lavoro: dove penso si stia spostando il baricentro, e cosa ho visto provandoci sul campo.

Il ciclo di sviluppo come lo conosciamo

Per anni le fasi a monte sono state compresse e il costo si è concentrato nello sviluppo, a scapito di test e validazione. L’arrivo degli agenti ribalta i pesi.

Fase	Oggi	Con lo sviluppo agentico
1. Requisiti funzionali e di prodotto	Compressa	Investimento principale: spec e DoD stringenti
2. Analisi tecnica e decomposizione	Compressa	Rafforzata: vincoli architetturali espliciti
3. Sviluppo	Lunga e costosa	Delegata agli agenti
4. Unit test / test statico	Erosa dallo sviluppo	Agente tester separato, mutation testing
5. Review	Effort elevato	Spostata a monte e basata sul rischio
6. Integrazione / e2e	Invasiva o assente	Snella, guidata dalla spec
7. Validazione e release	Debole	Shift-right: flag, canary, osservabilità

Un punto di onestà: la compressione delle fasi 1 e 2 non è stata solo una scelta di business. Spesso i requisiti emergono usando il prodotto, ed è anche per questo che l’agile le ha accorciate.

La tesi: il collo di bottiglia si sposta

Produrre codice diventa economico; il valore si concentra a monte (specificare) e a valle (verificare).

La pipeline diventa: spec iterativa, test di accettazione indipendenti, implementazione agentica, gate automatici, review mirata sul design, progressive delivery.

Non è un ritorno al waterfall: la spec è un artefatto vivo, raffinato in cicli brevi. E prototipare con gli agenti costa poco, quindi si può usare anche per scoprire la spec, non solo per implementarla.

Spec piccole, vincoli forti

Una spec per singola feature o fix, ben definita e con DoD stringenti; i vincoli architetturali vivono fuori dalla singola spec e sono eseguibili.

• Scope piccolo: niente documenti globali, una spec per ogni feature o correzione.
• Rischio: spec locali solide possono sommarsi in un sistema incoerente.
• Contesto condiviso: ADR e file di contesto per gli agenti (AGENTS.md o simili) che ogni spec richiama.
• Vincoli eseguibili: lint custom, architecture test (ArchUnit, dependency-cruiser).

Un vincolo scritto in prosa, prima o poi, l’agente lo viola. Uno che fa fallire la pipeline, no.

Chi scrive la spec

Il PM scrive la user story, lo sviluppatore la traduce in spec, il PM ne valida i criteri comportamentali.

1. PM: user story e criteri di accettazione in termini di business.
2. Sviluppatore: spec con vincoli tecnici, DoD e test di accettazione.
3. PM: valida la parte comportamentale della spec, così lo sviluppatore non chiude il cerchio su se stesso — scrive la spec e poi valida l’output contro la propria interpretazione.

È di fatto un “three amigos” in cui il ruolo QA diventa supervisione dell’agente tester. Implica sviluppatori con sempre più competenze da PM: un cambio di profilo non banale.

Implementazione con agenti contrapposti

TDD con due agenti separati: uno scrive i test più probanti a partire dalla spec, l’altro scrive il codice per farli passare.

I riferimenti sono il ping-pong pairing del TDD classico e AgentCoder (agente programmatore e agente test designer distinti).

Rischi e mitigazioni

Rischio	Cosa succede	Mitigazione
Goodhart / overfitting	Il coder ottimizza per i test, fino a gestirne i casi in modo speciale	Il coder vede la spec, non il codice dei test; set di test nascosti
Errori correlati	Due agenti dello stesso modello condividono i punti ciechi	Modelli diversi per tester e coder
Test deboli	Molti test, pochi davvero probanti	Mutation testing come metro del tester

Mutation testing in breve: lo strumento introduce piccole modifiche al codice (> diventa >=, && diventa ||, un return diventa null) e verifica che almeno un test fallisca. Il mutation score (mutanti uccisi / totali) misura la qualità dei test meglio della coverage. Strumenti: Stryker (JS/TS, C#), PIT (Java), Infection (PHP), mutmut (Python). In CI va eseguito solo sul diff della PR, leggendo i sopravvissuti prima del punteggio (vedi il caso sotto).

Un caso concreto. Ho provato questo schema su due feature di Taita, il mio side project in FastAPI: spec scritta a mano, un agente che scrive i test senza vedere il codice, un altro che scrive il codice senza poter scrivere test, poi coverage e mutmut.

	Funzione pura	DB + mock
Coverage branch	100%	97%
Mutation score (1° giro)	93,5%	85,6%
Buchi reali rispetto alla spec (1° → 2° giro)	1 → 0	0 → 0

Tre cose che cambiano il modo di leggere questa sezione:

• La coverage al 100% nascondeva un test cieco. Un test chiamato test_default_max_length_is_one, verde e coperto, usava dati in cui un default sbagliato dava lo stesso risultato. L’ha rivelato solo un mutante; con il report dei sopravvissuti l’agente l’ha chiuso in un giro.
• Il punteggio grezzo non è un buon gate. Il calo da 93,5% a 85,6% era tutto rumore: testi dei log, mutanti equivalenti, codice non richiesto. Una soglia fissa avrebbe bocciato una suite senza buchi. Il numero va letto dopo aver classificato i sopravvissuti.
• Il rischio più grande è il codice che nessuno ha chiesto. L’agente implementatore ha aggiunto gestione “difensiva” fuori spec, che i test scritti dalla spec non coprono. È un problema di processo, non di test.

I limiti sono seri: due feature piccole, spec precise, e lo stesso modello per entrambi gli agenti, cioè senza la mitigazione della tabella sopra. Ho poi portato avanti l’esperimento in modo più sistematico, e le conclusioni sono più sfumate di così: la separazione degli agenti, da sola, non basta a dimostrare la tesi, e il segnale più grosso è arrivato da tutt’altra parte. Dati completi, protocollo e limiti in Test scritti dagli agenti e mutation testing: una tesi non (ancora) dimostrata.

La review che cambia forma

La review non sparisce: si sposta a monte e si concentra dove c’è rischio.

1. Review di spec e test di accettazione prima che esista il codice: è la più preziosa.
2. Gate automatici: type check, lint, SAST, architecture test, mutation score sul diff, controllo dipendenze.
3. Agente reviewer diverso da chi ha scritto il codice, con checklist derivata dalla spec.
4. PR autodocumentante: ogni punto della DoD mappato al test che lo copre, scelte non ovvie motivate.
5. Review umana per rischio: CODEOWNERS su auth, migrazioni DB, API pubbliche, pagamenti; il resto a campione.
6. Ownership: chi firma la spec deve saper spiegare cosa va in produzione.

Il rischio da nominare: più codice generato significa più codice da capire. Senza review si accumula comprehension debt.

Validazione e rilascio: shift-right

Dopo test stringenti contro la DoD, la vera rete di sicurezza è in produzione: feature flag, canary, osservabilità e rollback rapido.

Il punto che chiude il cerchio: la spec non definisce solo i test, ma anche i segnali di produzione. Se la DoD dice “latenza p95 sotto 300 ms” o “nessun aumento di errori 5xx”, quei criteri diventano gli allarmi che governano il rollback. La spec scritta all’inizio decide anche cosa fa tornare indietro alla fine.

Lo shift-right non sostituisce lo shift-left: usato come scusa per testare meno prima, diventa testare sugli utenti.

Come farlo in pratica su AWS — canary ECS e rollout per tenant — l’ho messo nel secondo articolo: Shift-right su AWS: canary per revisione e per tenant.

Cosa significa per le persone

La riluttanza verso gli agenti non è un blocco unico, e la seniority si sposta dal codice al giudizio su spec, vincoli ed evidenze.

Tre tipi di riluttanza

• Resistenza al cambiamento: un tema di gestione.
• Scetticismo fondato: nel 2025 METR ha misurato sviluppatori esperti il 19% più lenti con l’AI, mentre si percepivano più veloci. Nel 2026 il follow-up indicava invece un’accelerazione, ma METR lo ha giudicato inaffidabile perché molti rifiutavano di lavorare senza AI. Il gap tra percepito e misurato resta.
• Identità professionale: molti hanno scelto il mestiere per scrivere codice, non spec.

Il senior di domani

• Comprendere il codice al 100% diventa molto meno importante; la comprensione profonda si concentra su confini (API, dati, auth, integrazioni) e percorsi critici.
• Giudica evidenze più che codice: spec, test, osservabilità, tracce.
• Conosce l’architettura meglio del senior di oggi.

Il costo dell’attesa si accumula

• Conoscenza effimera: prompt e tool del momento, scade in fretta.
• Conoscenza strutturale: come falliscono gli LLM, come si valuta un sistema stocastico, come si progetta il contesto di un agente. Chi aspetta perde soprattutto questa, insieme alla memoria storica che evita di ripetere errori già fatti.
• Contrappeso: la memoria storica può diventare zavorra se ancorata a giudizi non più veri (“nel 2024 gli agenti non funzionavano”).

Chiusura: i senior di domani

Resta una domanda scomoda: se i junior non passano più dalla scrittura e dal debug del codice, come diventeranno senior?

Una possibilità, che personalmente trovo plausibile, è che il percorso stesso cambi. Il senior di domani potrebbe non costruirsi più scrivendo migliaia di righe, ma imparando a trasformare una user story in un risultato sicuro, testabile e coerente con un’architettura che ha deciso lui. La comprensione profonda del codice non sparirebbe, ma si concentrerebbe dove conta: confini, dati, percorsi critici.

Non è una certezza, ed è difficile dire oggi se questo giudizio si possa formare senza passare dal codice. Ma se andrà così, la seniority si misurerà su quanto bene sai specificare, vincolare e verificare — e chi oggi non si aggiorna rischia di scoprirsi meno senior di quanto pensi.

---

Riferimenti

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089)
• METR, We are Changing our Developer Productivity Experiment Design (via Conffab)
• Capital & Compute: AI Programming in 2026
• Reuters via Yahoo, AI slows down some experienced software developers