Agentic engineering: perché il mid-market DACH è fermo al primo passo

Cos'è l'agentic engineering e in cosa si distingue dal vibe coding?

L'agentic engineering è un ciclo di sviluppo software definito, in più fasi, eseguito da agenti AI su un prodotto esistente, con integrazioni, dati reali, guardrail di sicurezza e test. Il vibe coding è prototipazione veloce per chi non programma, partendo da zero. Stessi modelli di base. Disciplina completamente diversa.

La confusione tra i due sta facendo danni veri. I team provano il vibe coding su una codebase di vent'anni, la vedono rompersi e concludono che l'AI non è pronta. Il tool non è mai stato pensato per quel lavoro.

Uno schema utile: costruisci il front end su Lovable, collegalo al core di Shopify via API. È la giusta divisione del lavoro. Vibe coding per la superficie, agentic engineering per il sistema sotto.

Perché il mid-market DACH è fermo al passo uno

Le scuse sono prevedibili. Noi siamo speciali. La nostra codebase è troppo complessa. Ho provato una volta e non ha funzionato.

La versione onesta è un'altra. Il team ha paura di perdere il controllo, paura che l'agente faccia meglio di quanto abbiano fatto loro, paura di dover imparare un tool nuovo da zero. Non sono problemi tecnici. Sono problemi di leadership.

Stiamo costruendo lo studio benchmark AI Monitor 2026 con l'ETH di Zurigo e l'Università di San Gallo proprio perché "stiamo facendo AI" non è un livello di maturità. In tutto il mid-market DACH il pattern è lo stesso: la readiness AI segue leadership e cultura, non la regolamentazione.

Perché il collo di bottiglia si è spostato dall'engineering alla leadership?

Per due decenni il team engineering è stato il vincolo di ogni software company. Non più. A trasformazione completata, il tuo unico limite reale è il budget di token. Prima che sia completata, il vincolo sono leadership e product management.

Gli sviluppatori restano avversi al rischio per buone ragioni. Per anni si sono presi la colpa di ritardi e complessità sottostimate. Chiedi loro una feature costruita nel modo classico e sanno stimarla: uno sprint, due settimane. Chiedila costruita con gli agenti e quel numero non te lo possono dare, perché non sanno ancora come si comporta l'agente. Così ripiegano sui tool di cui si fidano.

L'unica cosa che rompe il default è un CEO o un responsabile R&D che dice, esplicitamente: potete provare e potete fallire, purché impariate qualcosa. Senza quel permesso dall'alto non si muove niente.

Come porti l'agentic engineering sul P&L di un CFO?

Due casi, e un CFO li riconosce entrambi. Il caso costi: stesso output con meno persone, o il doppio dell'output con lo stesso headcount, dopo un periodo di trasformazione. Il caso sopravvivenza: le software company quotate costruite su un solo caso d'uso ristretto sono state punite con tagli di valutazione tra il 40 e il 50 percento, perché non hanno una risposta su come sarà il valore in un futuro agentico.

Il caso sopravvivenza è il più forte. Sposta la spesa da "budget per l'innovazione" a "restare sul mercato".

Quando abbiamo scalato Aioma a 30 persone in sei mesi, la matematica era semplice: ogni ingegnere in più era un costo lineare. Con uno stack agentico quella linea si piega. Ed è la parte che al CFO interessa davvero.

La costruzione in tre passi dopo il buy-in della leadership

Quando la leadership si è impegnata, inizia il lavoro vero. Tre passi prima di mettere in campo un solo agente.

Estrai la conoscenza. Il tuo prodotto è cresciuto per decenni. L'AI è già brava a leggersi tutto: il codice, ogni dipendenza, la documentazione, lo storico Slack, i ticket Jira e del supporto. Una parte della conoscenza vive solo nella testa dei senior developer: falli raccontare il sistema, trascrivi tutto e dallo in pasto. L'output è un hub di contesto strutturato, e deve crescere di continuo. Senza, l'agente è un junior brillante con amnesia ogni mattina.

Mappa il rischio di sicurezza. Anche i malintenzionati hanno l'AI. I nuovi modelli stanno diventando bravi a trovare vulnerabilità zero-day mai scoperte prima. Prima di lasciare che gli agenti cambino qualcosa, ti serve un quadro chiaro della sicurezza, per sapere cosa sistemare per primo.

Costruisci la suite di test. Cinquanta unit test al cinque percento di coverage non bastano. Ti serve una suite end-to-end completa, idealmente migliaia di scenari basati su dati d'uso reali, magari un digital twin del sistema. Gli agenti cambiano molto, in fretta. I test sono quello che ti dice che tutto funziona ancora.

Solo dopo questi tre passi metti in campo il primo agente, e parti in sequenza: un modulo, una API, un front end. Non ovunque in una volta.

Questa è l'architettura che Simon Scheurer e io stiamo costruendo in Teklens: un knowledge hub che ingerisce GitHub, Jira, Confluence, Slack, documenti e qualsiasi API in un unico grafo interrogabile, con un runtime di agenti ancorato al grafo via RAG, e casi d'uso (assistenti di workflow, modernizzazione SaaS, pacchetti di due diligence) costruiti sopra. Il punto del diagramma è che non parti dal caso d'uso. Parti dall'hub.

Perché l'agentic engineering è un problema di GTM, non solo di R&D

Questa è la parte che sfugge alla maggior parte degli operatori. L'agentic engineering non è solo una storia di sviluppo. È una storia di ricavi.

Se rilasci una versione all'anno, hai un tentativo all'anno per trovare il product-market fit nello strato agentico del tuo prodotto. Un concorrente che rilascia ogni mese ne ha dodici. Ti supererà a colpi di iterazioni finché non diventi irrilevante. Il senso della trasformazione è comprimere quel ciclo, per testare positioning e valore abbastanza in fretta da contare.

Anche la value proposition deve cambiare. I clienti non vogliono più un software in cui inseriscono dati e ricevono un report. Vogliono risultati e workflow completati. È un problema di riposizionamento, e il riposizionamento è un lavoro di GTM, non di engineering.

Conta anche la compressione interna. Quando il supporto passa le escalation dritte a un agente, quando il product management prioritizza 50 elementi invece di ridurli a 5, l'intero motore dei ricavi accelera. Product team agentici e snelli cambiano le tue unit economics, e le unit economics cambiano come vendi. Vedi Revenue Systems & GTM Engineering per l'argomentazione completa.

Dove si rompe l'agentic engineering?

Tre modalità di fallimento, in ordine di frequenza.

Il gap di talenti. Lo skill set è nuovo per tutti, quindi non c'è un bacino profondo da cui assumere. O porti dentro qualcuno con esperienza vera, o accetti una lunga curva di apprendimento interna. Scorciatoie non ce ne sono.

La fantasia del prompt unico. "Claude code, sistemalo" su una codebase da venti milioni di righe fallirà, e il team darà la colpa alla tecnologia invece che all'impostazione. L'aspettativa deve essere un processo in più fasi con iterazioni, non un comando magico.

La trappola del "lo compro e basta". Il fallimento più comune che vedo: aziende che vogliono acquistare l'agentic engineering come una licenza e poi dimenticarsene. Non funziona così. Si allena, non si compra. Miglioramento quotidiano, come un membro del team.

Il cambio di mentalità, dal CEO in giù

Smetti di imbullonare l'AI sul tuo prodotto come una lista di casi d'uso. Costruisci il sistema operativo sotto: contesto, sicurezza, test. Poi lascia liberi gli agenti.

Il cambio va dal CEO che deve imparare il vibe coding al responsabile R&D che deve convincersi che funziona, giù fino allo sviluppatore che adotta tool nuovi e accetta il cambiamento quotidiano. Se quel cambio non c'è, fallisce.

Il treno è partito. Il bus circola ancora.

Vuoi la versione settimanale di tutto questo? Iscriviti alla newsletter The Science of GTM per l'analisi di come prodotto, GTM e AI operano come un unico sistema. Oppure entra nella waitlist della cohort AI GTM Lab se vuoi il playbook dal vivo.

FAQ

Cos'è l'agentic engineering?

L'agentic engineering è un ciclo di sviluppo software definito, in più fasi, eseguito da agenti AI su un prodotto esistente, con integrazioni, dati reali, guardrail di sicurezza e test. Si distingue dal vibe coding, che è prototipazione veloce per chi non programma, partendo da zero.

Il GDPR è il principale ostacolo all'adozione dell'AI nel mid-market DACH?

No. L'esperienza sul campo e lo studio benchmark AI Monitor indicano entrambi leadership, comunicazione e cultura come i blocchi principali. La regolamentazione è un vincolo risolvibile. Il problema più duro è ottenere l'impegno della leadership e superare l'avversione al rischio degli sviluppatori.

Da dove parti con l'agentic engineering in una software company esistente?

Il passo uno è il buy-in della leadership, con budget per tooling e coaching e il permesso esplicito di fallire. Poi il lavoro di engineering segue tre passi: estrarre la conoscenza della codebase in un hub di contesto, mappare il rischio di sicurezza e costruire una suite di test completa. Solo allora metti in campo il primo agente, un modulo alla volta.

Perché l'agentic engineering conta per il go-to-market, non solo per l'engineering?

Perché cambia cadenza di rilascio, value proposition e unit economics. Un'iterazione più veloce ti permette di testare il positioning prima dei concorrenti. Le aspettative dei clienti si stanno spostando dal software da usare ai risultati consegnati. Product team agentici più snelli cambiano il modo in cui vendi.

Si può comprare una soluzione di agentic engineering pronta all'uso?

No. L'agentic engineering va allenato e adattato al tuo prodotto, alla tua codebase e al tuo processo, poi migliorato di continuo. Trattarlo come un acquisto una tantum è il motivo più comune per cui le trasformazioni falliscono.