Economia dello Sviluppo AI
Analisi economica e guida operativa d'adozione delineate da Addy Osmani, Shubham Saboo e Sokratis Kartakis nel whitepaper Google The New SDLC With Vibe Coding (maggio 2026): per i leader tecnici la metrica decisiva non è la velocità grezza di scrittura del codice (developer velocity), ma il Total Cost of Ownership (TCO), ovvero il modo in cui i diversi flussi di lavoro spostano i costi tra Capital Expenditure (CapEx, investimento iniziale) e Operational Expenditure (OpEx, costo continuo di esecuzione, correzione e manutenzione) all'interno dell'economia dei token. 1
Il debito nascosto del Vibe Coding (Low CapEx, High OpEx) vs l'investimento dell'Agentic Engineering (High CapEx, Low OpEx)
A prima vista il vibe coding appare economicissimo: il CapEx è quasi nullo (basta un abbonamento mensile standard e qualche prompt informale, senza investire tempo nel system design). Tuttavia nasconde un OpEx massiccio e composto lungo tre voci: 1
- Token Burn Rate (e i loop di prompting): ogni interazione con un LLM ha un costo basato sui token di input e output; nel vibe coding gli sviluppatori scaricano file enormi e non strutturati nella context window e chiedono ripetutamente al modello di correggere i propri errori non verificati, innescando un costoso "prompting loop" che brucia token API con bassi tassi di successo al primo colpo (first-pass success rates). 1
- Maintenance Tax (tassa di manutenzione): il codice prodotto con prompt ad hoc manca di coerenza strutturale; quando sei mesi dopo emerge un bug, gli ingegneri umani spendono giorni a fare reverse-engineering di codice "spaghetti" generato dall'AI (vedi anche Programmazione Strategica, Osservabilità e Ruolo del Giardiniere). 1
- Security Remediation (bonifica di sicurezza): senza un harness di valutazione automatizzato, generare rapidamente codice significa generare rapidamente vulnerabilità, e correggere una falla di sicurezza in produzione costa esponenzialmente di più che intercettarla in fase di design (vedi Shift Left Security). 1
L'agentic engineering ribalta il modello (High CapEx, Low OpEx): richiede un investimento iniziale deliberato prima che venga generata una sola riga di codice di produzione — progettare schemi API, costruire suite di test deterministiche e strutturare il contesto dell'agente — ma abbatte drasticamente il costo marginale di rilascio e manutenzione, poiché l'AI lavora dentro una "fabbrica" governata che produce output strutturalmente solido, pre-testato e allineato agli standard aziendali (vedi Spettro Vibe Coding e Agentic Engineering e Modello Fabbrica, Conduttori e Orchestratori). 1
Context engineering come leva finanziaria e Intelligent Model Routing
Nell'economia dei token, il Context Engineering non è solo una competenza tecnica ma una strategia finanziaria: poiché gli LLM fanno pagare ogni informazione inviata, passare un intero repository da 100.000 token in ogni prompt è finanziariamente insostenibile su scala. Fornire un payload denso e ad alto segnale (un AGENTS.md preciso e guardrail architetturali), abbinato al contesto dinamico tramite skill e server MCP, innalza drasticamente il first-pass success rate ed elimina i costosi cicli per tentativi ed errori. 1
A questo si affianca l'Intelligent Model Routing: mentre nel vibe coding si usa tipicamente un unico modello frontier massiccio per qualsiasi interazione — pagando prezzi premium anche per correggere un refuso o generare un unit test elementare — un modello fabbrica ben progettato usa i modelli grandi e avanzati per i task ad alta complessità (Requirements, Architecture e prima Implementation) e instrada automaticamente i task deterministici e a minore complessità (Test Generation, Code Review e monitoraggio CI/CD) verso modelli più piccoli, veloci e significativamente più economici. 1
Da dove cominciare: raccomandazioni per sviluppatori, leader e organizzazioni
Poiché l'AI amplifica la cultura ingegneristica in cui atterra, il whitepaper chiude con una roadmap pratica su tre livelli: 1
- Per gli sviluppatori individuali (6 mosse): (1) creare un
AGENTS.md(o equivalente) partendo da dieci righe (stack, convenzioni, regole dure, workflow) e aggiungendo una regola ogni volta che l'agente commette un errore che non deve ripetere; (2) installare un set di skill (come Agents CLI); (3) scegliere un workflow ripetitivo (ricerca, code review, report ricorrente) e farne il primo agente end-to-end dal prototipo alla produzione; (4) scrivere test ed eval prima di generare il codice, perché insieme costituiscono il contratto con l'AI; (5) revisionare ogni riga destinata alla produzione, diffidando di tutto ciò che appare "furbo" (clever), controllando che gli import corrispondano a pacchetti reali e che la gestione degli errori copra failure mode realistici; (6) mantenere affilate le proprie competenze fondamentali (debugging complesso, system design, intuito per performance e correttezza), usando l'AI per applicare l'expertise su scala maggiore e non per sostituirla. 1 - Per gli engineering leader (5 mosse): (1) rendere il context engineering una pratica di prima classe, trattando
AGENTS.md, system prompt, eval suite e librerie di skill come codice (rivisti in pull request, versionati e con owner); (2) fissare l'asticella sull'eval e non sulla demo, esigendo come precondizione di rilascio una copertura eval dotata di rubriche esplicite su cinque dimensioni: task success, tool use quality, trajectory compliance, hallucination e response quality; (3) ridisegnare la code review per il codice generato dall'AI, addestrando i revisori su dipendenze allucinate, gestione errori inadeguata e lacune sottili di correttezza che sembrano giuste a colpo d'occhio; (4) distinguere nelle norme del team il lavoro di prototipazione (vibe coding) da quello di produzione (agentic engineering) su progetti, branch e ambienti, perché i team che lasciano sfumato questo confine producono prototipi che finiscono in produzione per sbaglio (vedi Cerimonia Proporzionata al Rischio); (5) investire nei componenti dell'harness come asset condiviso e infrastruttura che si costruisce una volta e si affina molte volte. 1 - Per le organizzazioni (5 mosse): (1) trattare lo sviluppo assistito da AI come un investimento ingegneristico e non come una feature di produttività; (2) investire nel substrato di produzione prima di scalare (eval di traiettoria e risposta finale in CI, tracce di ogni run, permessi scoped per agente e security review tarata sul codice generato); (3) adottare gli standard aperti MCP e A2A per mantenere aperta l'opzione multi-vendor ed evitare futuri re-platforming; (4) pianificare team ibridi di umani e agenti con chiari protocolli di handoff, aggiornando code review, turni di reperibilità (on-call rotations) e strutture organizzative; (5) riorientare assunzioni e sviluppo delle competenze attorno al giudizio (specifica, valutazione, giudizio architetturale e review) anziché alla sola velocità di implementazione. 1
Conclusione: l'intento come nuova interfaccia e i tre principi durevoli
Nella sintesi conclusiva (Intent as the new Interface), gli autori fissano tre principi destinati a durare oltre l'evoluzione dei singoli strumenti: 1
- La struttura scala, le vibes no (Structure scales, vibes don't): nello scarto tra "sembra funzionare" e "funziona correttamente in tutte le condizioni" si annidano i disservizi in produzione, le vulnerabilità di sicurezza e gli incubi di manutenzione. 1
- L'AI amplifica la cultura ingegneristica (AI amplifies your engineering culture): è un moltiplicatore di forza che amplifica tanto i punti di forza (test, standard architetturali, code review sane) quanto le debolezze di un'organizzazione. 1
- Il ruolo umano evolve, non svanisce (The human role is evolving, not diminishing): "La generazione è risolta. Verifica, giudizio e direzione sono il nuovo mestiere" (Generation is solved. Verification, judgment, and direction are the new craft). 1
Vedi anche: Harness Engineering, Context Engineering, Cerimonia Proporzionata al Rischio, Spettro Vibe Coding e Agentic Engineering, Modello Fabbrica, Conduttori e Orchestratori, Addy Osmani