Codice generato dall’AI: quando e perché può distruggere il tuo progetto

Nel mondo dello sviluppo software, osservare un programmatore al lavoro spesso significa vederlo fissare il vuoto più del monitor. Gran parte del lavoro avviene nella mente, non nella tastiera. Scrivere codice (il cosiddetto coding) è infatti solo la fase finale di un processo molto più complesso che include la comprensione del problema che il software deve risolvere, la definizione dei requisiti, la progettazione di astrazioni rilevanti, la valutazione di effetti collaterali, i test incrementali e la correzione di bug.

Come ricorda Leslie Lamport, coding e programmazione sono due cose molte diverse: prima è quindi necessario pensare astrattamente ai programmi prima di svilupparli.

L’impatto dell’AI sul coding

Con l’avvento degli agenti AI basati su LLM (Large Language Model), come Claude Code, GitHub Copilot o Google Jules, la dinamica cambia radicalmente: ora il codice può essere generato a velocità impressionante. Tuttavia, la maggior parte dei software complessi vive all’interno di sistemi articolati, e i LLM non sono ancora in grado di gestire l’intero contesto di un’applicazione in memoria. Ciò significa che la revisione umana, l’integrazione e i test rimangono imprescindibili.

Il risultato è che, per i software complessi, gran parte del tempo è spesso impegnato a comprendere a posteriori il codice prodotto dall’AI, invertendo la tradizionale sequenza mentale: coding prima, comprensione in un secondo momento. Non vorrete certo eseguire codice prodotto da terzi senza prima averlo esaminato con attenzione?

Questa dinamica spiega perché le promesse di un coding “10 volte più veloce” spesso si traducono nella realtà in un miglioramento marginale della produttività, intorno al 10%. Inoltre, mentre i LLM gestiscono rapidamente i compiti richiesti, agli sviluppatori rimane il lavoro meno gratificante: testare, documentare, rimuovere codice duplicato, gestire deployment e infrastrutture.

LLM come “ingegneri junior” ultra-veloci

Oggi, molti sviluppatori si trovano a gestire LLM come se fossero dei “talenti junior“: incredibilmente veloci, ma privi di vera capacità di apprendere. Gli agenti AI migliorano solo attraverso l’engineering del contesto (strutturare in modo intelligente le informazioni che l’AI riceve prima di generare codice o rispondere: fornire dettagli chiari sul progetto, snippet di codice rilevanti, regole di stile, limiti da rispettare o esempi di output desiderato) o l’arrivo di nuovi modelli di base (i LLM migliorano anche quando vengono rilasciate versioni più avanzate del modello stesso, addestrate su dataset più grandi o con tecniche più sofisticate).

In pratica, la produttività dei LLM può essere sfruttata in due modi:

• AI-driven engineering: applicare best practice, privilegiare la comprensione umana, sviluppare in maniera sostenibile.
• Vibe coding: massimizzare la velocità potenzialmente sacrificando comprensione e qualità, con inevitabile accumulo di codice difficile da mantenere.

I due approcci a confronto

L’AI-driven engineering è un approccio strutturato e sostenibile all’uso degli agenti AI nel coding. In questo caso l’AI scrive codice attenendosi a regole e standard definiti dal team (es. naming coerente, modularità, test-driven development). Inoltre, ogni pezzo di codice generato dall’AI deve essere comprensibile e manutenibile dai programmatori.

L’approccio mira i questo caso a uno sviluppo sostenibile: il lavoro con l’AI è integrato nei processi del team, riducendo il rischio di dover rifare tutto da capo o di introdurre bug difficili da individuare.

Esempio pratico: un agente AI genera una funzione, ma prima il team definisce specifiche chiare, crea test automatici e verifica che la funzione sia modulare e documentata. Così si sfrutta la velocità dell’IA senza compromettere qualità e manutenzione.

Del vibe coding abbiamo parlato ampiamente: a nostro avviso non è né una tecnica da bocciare senza appello né da abbracciare a tutto tondo. Essenziale è mantenere piena consapevolezza su ciò che si sta facendo. Perché, di base, con il vibe coding, l’AI può scrivere codice “al volo”, senza vincoli o regole di stile.

Il codice risultante può essere difficile da leggere o modificare da altri sviluppatori. Il progetto può diventare presto fragile, con bug nascosti e funzionalità incoerenti, rendendo la manutenzione complessa e costosa.

Usare il vibe coding con consapevolezza

Come abbiamo spiegato nell’articolo citato in precedenza, non è questione di demonizzare il vibe coding. La stessa AMD spiega come usare hardware Radeon per il vibe coding in locale: il punto è usarlo con consapevolezza e disciplina, riconoscendo i suoi limiti e inserendolo in un contesto strutturato. Il vibe coding può accelerare prototipi o compiti ripetitivi, ma senza supervisione umana rischia di generare codice difficile da mantenere, incoerente con le architetture esistenti e pieno di errori nascosti.

Uno sviluppatore esperto che affida all’AI compiti specifici, conoscendo obiettivi e vincoli, utilizza una “dose di vibing” molto più sicura rispetto a chi chiede genericamente all’AI di creare un’app completa.

Il rischio principale è affidare progetti complessi e a lungo termine a un processo totalmente vibe-based: inizialmente tutto sembra funzionare, ma emergono presto bug, strutture caotiche e difficoltà di manutenzione, creando una dipendenza pericolosa dall’AI. Il codice generato può funzionare, ma spesso risulta “alieno”: ignora convenzioni del team, reinventa soluzioni già disponibili e non si integra armonicamente nel sistema.

L’approccio corretto è usare l’AI come uno stagista iper-competente: rapido e creativo, ma che necessita di una continua supervisione. Lo sviluppatore deve controllare, correggere e guidare, sfruttando l’AI per accelerare compiti ripetitivi senza perdere il controllo delle scelte architetturali.

In pratica, il vibe coding funziona bene se si applicano principi consolidati di buona ingegneria: fornire esempi chiari, specificare librerie e stili architetturali, suddividere il codice in moduli, scrivere prompt dettagliati e revisionare sempre l’output con occhio critico.