Gli agenti AI e il vibe coding permettono davvero di costruire più in fretta. Ma c’è una cosa che non permettono di saltare: la competenza umana di chi conosce software, infrastrutture, architetture, sicurezza e processi reali. Un prompt può descrivere una funzionalità. Non può, da solo, decidere come un sistema debba reggere il traffico, proteggere i dati, integrare un ERP, degradare senza fermare l’azienda, riprendersi da un errore o lasciare una traccia verificabile delle proprie azioni.
Questa è la tesi, e va detta subito perché il rumore di questi mesi la sta seppellendo sotto una pioggia di demo: l’AI accelera l’esecuzione; l’essere umano competente governa il sistema. Chi confonde le due cose non sta democratizzando l’ingegneria del software. Sta producendo un mercato di prototipi travestiti da prodotti e, quando quei prototipi vengono innestati in processi aziendali veri, sta preparando debito tecnico automatizzato, vulnerabilità sistemiche e danni che arrivano sempre dopo gli screenshot celebrativi.
È così che nasce il tecnopiteco del codice: fino a ieri faticava a configurare una stampante di rete, oggi si presenta come «AI Developer» perché ha chiesto a un modello di generare uno script che sul suo laptop sembra funzionare. Nulla di personale: il tecnopiteco è una categoria mentale, non un’anagrafe. È chi scambia la produzione di output per progettazione, l’assenza di errori in console per qualità, una chat con un LLM per una competenza ingegneristica.
La tesi cardinale: un prompt non è un’architettura
Un’architettura non è una lista di schermate né una sequenza di funzionalità da affidare a un chatbot. È l’insieme delle decisioni che rendono un sistema coerente nel tempo: confini tra domini applicativi, modello dei dati, contratti tra servizi, gestione delle identità, segreti, permessi, code, cache, rollback, osservabilità, backup, continuità operativa, costi e responsabilità.
Per capirci: chiedere «fammi una piattaforma che riceva richieste, le assegni a un agente e aggiorni il CRM» è il punto di partenza di una conversazione. Non è un progetto. Chi garantisce l’idempotenza quando la richiesta viene ritentata? Dove vengono conservati i dati personali? Quale identità usa l’agente per leggere e scrivere? Cosa accade se l’API esterna rallenta? Quale evento è auditabile, chi approva le azioni irreversibili, qual è la procedura di rollback, chi viene avvisato se il costo del modello esplode? Sono domande da architetto e da team di piattaforma, non dettagli che si risolvono sperando di trovare il prompt giusto.
Un LLM può proporre risposte plausibili a queste domande. Può anche produrre componenti utili. Ma non conosce l’organizzazione per cui state lavorando, non possiede una vera responsabilità sul risultato e non può decidere quali compromessi siano accettabili tra velocità, costo, rischio e sostenibilità. Se non c’è un umano competente a porre i vincoli e valutare le alternative, l’agente ottimizza soltanto il percorso locale suggerito dal contesto che gli avete dato. E il contesto, in un’impresa, è quasi sempre più complesso di un prompt ben scritto.
Vibe coding: utile per esplorare, pericoloso se diventa processo
Il vibe coding non è il nemico. Il termine è stato reso popolare da Andrej Karpathy nel 2025 per descrivere un modo di programmare conversazionale: si dichiara un’intenzione, l’AI genera il codice, si itera finché qualcosa prende forma. Riduce l’attrito iniziale e rende accessibile l’esplorazione a chi, altrimenti, non toccherebbe mai un editor di codice.
Per una demo, un prototipo, un esperimento creativo, un piccolo strumento personale o una fase di discovery, può essere straordinario. Vedere un’idea muoversi in poche ore cambia il modo in cui un team discute una soluzione. La velocità di prototipazione è un vantaggio competitivo quando viene trattata per ciò che è: un modo per imparare prima, non un certificato di prontezza per la produzione.
Il problema comincia quando la demo viene promossa a sistema senza cambiare metodo. Lì compare il classico incantesimo aziendale: «funziona sul mio computer, quindi mettiamolo nel flusso dei clienti». È il punto in cui il tecnopiteco scopre che un sistema reale non vive isolato. Vive dentro reti, database, directory aziendali, policy GDPR, budget cloud, dipendenze di terze parti, SLA e persone che lavorano il lunedì mattina senza voler scoprire che il loro processo è stato trasformato in una roulette russa con API.
Dal prompt al processo: il salto che quasi tutti fingono di non vedere
La differenza tra una funzionalità richiesta in chat e un sistema pronto per un processo aziendale è abissale. La prima descrive cosa si vorrebbe ottenere. Il secondo deve dimostrare come lo fa in modo ripetibile, controllato e recuperabile. Non basta che l’output sia corretto una volta: serve che rimanga corretto quando aumentano i volumi, cambiano i dati, cade un servizio dipendente, entra un nuovo utente o arriva un input ostile.
Un professionista che conosce infrastrutture e software ragiona prima sui requisiti non funzionali: disponibilità, prestazioni, sicurezza, osservabilità, manutenibilità, portabilità, costi. Sa che un database mal modellato non si aggiusta con una nuova schermata; che un endpoint senza limiti può diventare un costo ingestibile; che un’integrazione sincrona con un sistema fragile può bloccare una catena operativa; che una chiave API infilata nel repository non è una scorciatoia, è una futura telefonata alle tre di notte.
Sa anche distinguere la soluzione che sembra più elegante nel playground da quella che l’azienda può mantenere tra due anni. Questa competenza non è nostalgia del codice scritto a mano. È progettazione. Ed è esattamente ciò che diventa più importante quando un agente può modificare decine di file in pochi minuti: la velocità senza direzione non è produttività, è una macchina per produrre entropia.
Quello che un’architettura solida decide prima di generare codice
- Quali dati entrano, dove risiedono, chi può vederli e per quanto tempo vengono conservati.
- Quali componenti possono parlare tra loro, con quali contratti e con quali limiti di errore e latenza.
- Quali azioni sono reversibili, quali richiedono approvazione e come si ricostruisce la sequenza dei fatti.
- Come si testano cambiamenti, migrazioni, carichi anomali e fallimenti deliberati prima che li provochi un cliente.
- Quali segreti, ruoli, ambienti e confini di rete impediscono al sistema di fare più di ciò che deve fare.
È tutta roba meno fotogenica di un video in cui un agente genera un’app in tre minuti. Ma è la roba che separa una build da un prodotto. E quando il prodotto entra in un’azienda, è la roba che separa l’innovazione da un incidente.
Agentic coding: non un mago, un esecutore dentro un perimetro
L’agentic coding alza ulteriormente l’asticella. Qui non chiediamo più al modello un frammento di codice: gli affidiamo una sequenza di lavoro. Un agente può leggere un repository, formulare un piano, selezionare strumenti, modificare file, eseguire test, rivedere gli errori e proporre un cambiamento. La documentazione di GitHub Copilot cloud agent descrive proprio un flusso che passa attraverso repository, piano, branch, commit e pull request.
Questa è una notizia eccellente per gli ingegneri. A un team competente, l’agente toglie lavoro meccanico: ricognizione, scaffolding, test ripetitivi, modifiche distribuite, documentazione iniziale, refactoring circoscritti. Il tecnico del suono non diventa inutile perché ha un banco digitale; diventa più capace di governare un palco complesso. Ma il banco digitale non decide per lui se il cablaggio è sicuro, se il palco regge il carico o se quel concerto va eseguito davanti a diecimila persone.
Senza un architetto, un coding agent può rendere più rapida anche la produzione di errori. Potrà applicare coerentemente una decisione sbagliata su più moduli. Potrà introdurre una dipendenza incoerente con lo stack. Potrà replicare un’antipattern in dieci servizi. Potrà trasformare una richiesta vaga in un diff enorme che nessuno sa davvero revisionare, perché nessuno ha prima definito il perimetro, il rischio e i criteri di accettazione.
Il ciclo sano non è «chiedi, esegui, spera»
Il ciclo sano è: umano competente definisce il problema e il confine; agente esegue una parte ben delimitata; pipeline automatizzata testa; umano competente legge il diff, controlla gli impatti e approva; l’osservabilità verifica il comportamento in ambiente controllato; solo allora il cambiamento entra in produzione. Non è lentezza. È l’unico modo razionale per sfruttare la velocità della macchina senza consegnarle il volante bendati.
Sicurezza: il prompt non è un controllo di sicurezza
Nel mondo agentico, il rischio non è solo che l’AI scriva una funzione sbagliata. È che un agente con accesso a file, rete, tool, segreti o sistemi operativi faccia troppo, nel posto sbagliato, al momento sbagliato. «Non fare danni» è un’ottima intenzione etica e un pessimo controllo tecnico. Le policy devono vivere in runtime, nei permessi, nelle identità, nella segmentazione di rete, nei limiti dei tool e nelle procedure di approvazione.
Le linee guida di Claude Code mettono in evidenza il valore dei permessi granulari; la documentazione tecnica di Anthropic sul sandboxing spiega perché un ambiente per coding agent debba contenere sia l’accesso al filesystem sia la rete. Il concetto è banalmente sano: se un agente non deve poter leggere un segreto o chiamare un endpoint esterno, non deve poterlo fare. Non gli si deve semplicemente chiedere con gentilezza di non farlo.
A questo si aggiunge la prompt injection, che OWASP indica come un rischio prioritario per le applicazioni LLM. Se un input ostile riesce a deviare il comportamento di un agente con strumenti e dati aziendali, il problema non resta confinato nella chat: può diventare esfiltrazione, uso improprio di un tool, contaminazione di una decisione o alterazione di un processo. Chi non comprende il modello di minaccia non può progettare la difesa stratificata necessaria.
Ecco perché l’azienda che mette un agente dentro un processo non sta «installando AI». Sta modificando la propria superficie di attacco. E se non ha persone capaci di leggere quell’impatto, di fare threat modeling, di definire ruoli e di monitorare i log, non sta risparmiando competenza: sta spostando il costo nel futuro, dove sarà più alto e con più avvocati al tavolo.
Scalabilità, integrazione e il mondo fuori dalla demo
Il software aziendale non deve soltanto funzionare: deve convivere. Con sistemi legacy, protocolli opachi, utenti imperfetti, audit, anagrafiche incoerenti, picchi di carico, contratti, budget e persone che chiedono «perché questa pratica è stata rifiutata?» quando l’agente ha già eseguito tre passaggi a cascata. La risposta non può essere: «boh, l’AI lo ha deciso».
Scalare significa sapere quando un processo deve diventare asincrono, come evitare doppie esecuzioni, quando introdurre una coda, quali dati cacheare, quali non cacheare mai, come limitare il costo di una chiamata a un modello, quale degradazione offrire se il fornitore LLM non risponde. Integrare significa capire chi è la fonte autorevole di un dato, come gestire conflitti, versioni e consensi. Non è un catalogo di prompt; è esperienza sedimentata in progetti, incidenti, post-mortem e revisioni.
Per questo il mantra «chiunque ora può costruire qualsiasi cosa» è tecnicamente sbagliato. Chiunque può generare una prima versione di molte cose. Costruire qualcosa che resti in piedi, che protegga l’IP, che non consegni dati a chi non deve vederli e che si possa manutenere quando cambiano le condizioni è un altro mestiere. E questo mestiere non muore con gli agenti: cambia forma, diventa più strategico e richiede ancora più capacità di astrazione.
Il framework umano: responsabilità, revisione, evidenze
Il NIST Secure Software Development Framework ricorda una verità poco glamour: lo sviluppo sicuro non è una fase finale di controllo qualità. È un approccio che attraversa preparazione dell’organizzazione, protezione del software, produzione di componenti affidabili e risposta alle vulnerabilità. Un agente può aiutare in ciascuna di queste attività. Non può sostituire chi deve decidere il livello di rischio accettabile o assumersi la responsabilità di un incidente.
Un’azienda che usa agenti bene crea un sistema in cui il comportamento dell’agente è osservabile e contestabile. Ogni azione importante ha una traccia. Ogni privilegio è motivato. Ogni modifica è revisionabile. Ogni rilascio può essere fermato. Ogni incidente può essere ricostruito. Questo non limita l’autonomia utile: la rende sostenibile.
Sette domande da fare prima di innestare un agente in un processo
- Quale decisione o azione deleghiamo esattamente e quale umano ne resta responsabile?
- Quali dati, file, strumenti e ambienti può vedere o modificare l’agente?
- Quali azioni richiedono approvazione esplicita prima dell’esecuzione?
- Come limitiamo rete, credenziali, costi, chiamate e durata dell’esecuzione?
- Come testiamo il cambiamento contro dati rappresentativi e input ostili?
- Quali log, metriche e alert ci dicono che l’agente sta uscendo dal perimetro?
- Come fermiamo, ripristiniamo e spieghiamo una decisione errata?
Se nessuno nel team sa rispondere con precisione, non avete un progetto agentico pronto per la produzione. Avete un esperimento. Gli esperimenti sono legittimi, ma vanno dichiarati, isolati e trattati come tali. È il modo più maturo per non trasformare l’entusiasmo in un danno operativo.
Non spegnete il palco. Metteteci un architetto.
Il punto non è difendere un’élite che scrive codice a mano per nostalgia. È difendere il valore della competenza nell’epoca in cui produrre codice diventa facile. Il vibe coding può allargare l’accesso alla creatività software. L’agentic coding può rendere i team esperti molto più veloci. Entrambi possono liberare tempo e aumentare qualità, se inseriti dentro un metodo progettato da chi sa leggere le conseguenze tecniche e organizzative delle scelte.
Il problema sono i tecnopitechi che vendono come prodotto finito il primo output che soddisfa una demo. Fanno danno al mercato perché abbassano la percezione del mestiere, producono sistemi fragili e lasciano alle aziende l’idea sbagliata che software, sicurezza e infrastruttura siano optional da attivare dopo il go-live. Non lo sono. Sono il prodotto, anche quando non si vedono.
L’AI accelera. L’umano progetta, delimita, verifica e risponde. Tutto il resto è un prompt con una data di scadenza.
Non spegnete il palco. Non rinunciate agli agenti. Ma prima di affidargli il mixer, assicuratevi di avere in sala qualcuno che sappia progettare l’impianto, leggere i log, limitare i volumi e staccare la corrente quando serve. Il dato è proprietà, non una commodity. Il software è ingegneria. E un agente utile è sempre un agente governato.
Fonti e approfondimenti
- Andrej Karpathy, post sull’origine del vibe coding, 2 febbraio 2025.
- Advait Sarkar e Ian Drosos, “Vibe coding: programming through conversation with artificial intelligence”.
- Google Cloud, “What is agentic coding”.
- GitHub Docs, “About GitHub Copilot cloud agent”.
- Claude Code Docs, “Configure permissions”.
- OWASP GenAI Security Project, “LLM01: Prompt Injection”.
- NIST, “Secure Software Development Framework”.
