Vibe coding o software engineering? Come l'AI sta ridefinendo il valore nei progetti software

La generazione di codice tramite AI è una realtà ormai affermata. E sta cambiando qualcosa di più profondo del semplice modo in cui si scrive codice: sta ridefinendo dove si crea valore in un progetto software. In Nephila stiamo ripensando il flusso di lavoro dall'analisi alla consegna, e quello che stiamo imparando merita di essere condiviso.

***

Non tutti gli usi dell'AI nel development si equivalgono. C'è una distinzione che stiamo trovando sempre più utile, e che si può riassumere in due parole: vibe coding e software engineering.

Il vibe coding è lavorare a martellate contro il problema, prompt dopo prompt, output dopo output, sperando che il sistema converga verso qualcosa di funzionante. Funziona, a volte, ma non scala e non accumula valore nel tempo.

Il software engineering, anche nell'era dell'AI, è costruire il progetto nella propria testa, e poi farlo realizzare. Sembra una distinzione sottile, ma le implicazioni non lo sono.

Se il codice perde centralità, cosa la acquista?

Abbiamo sempre sostenuto che il codice è lo strumento con cui consegniamo valore, non lo scopo del nostro lavoro. Il valore non sta nelle righe di codice: tre righe in Rust e un milione di righe in Python possono dare lo stesso risultato all'utente finale.

Con l'AI generativa, questa verità diventa ancora più evidente: un LLM può scrivere React, Django, FastAPI o qualunque altro stack con efficienza paragonabile. Le scelte di framework rimangono rilevanti (non si può validare codice in un linguaggio che non si conosce) ma lo stack diventa meno determinante di quanto lo fosse prima.

Quello che acquista centralità è il patrimonio informativo che costituisce un progetto: tutto il processo di elaborazione che porta dall'idea a qualcosa che un utente può usare. Questo processo serve in due step del processo di sviluppo:

• durante la fase progettuale, permette alle persone coinvolte di allinearsi su cosa deve essere fatto e perché;
• durante la fase implementativa, costituisce il contesto che viene passato all'AI per generare il codice.

Per chi lavora come partner tecnologico, progettando e sviluppando software su misura per i propri clienti, spesso in continuità nel tempo, c'è un'implicazione in più: il codice finisce al cliente. Il patrimonio informativo costruito per realizzarlo rimane in azienda trasformandosi in un asset strategico che si accumula nel tempo, progetto dopo progetto.

Cosa non si può delegare all'AI: l'architettura

Un LLM lasciato a sé stesso può fare scelte tecniche intelligenti su un progetto e scelte completamente diverse su un altro, semplicemente perché riparte da zero ogni volta. Nessuna coerenza tra progetti, nessuna capitalizzazione di esperienza.

Le decisioni architetturali (che tipo di API esporre, come distribuire le responsabilità tra frontend e backend, come strutturare il modello dei dati, quali pattern adottare) non si possono delegare. La responsabilità si sposta sul definire i binari: un perimetro chiaro, senza vincoli eccessivi, entro cui l'LLM possa muoversi in modo determinista e coerente su tutti i progetti.

In modo analogo allo spec-driven development, pensiamo "il prompt è il nuovo codice" sia una semplificazione eccessiva: serve qualcosa di più strutturato, costruire una visione complessiva del progetto in linguaggio naturale, con il livello di dettaglio necessario a garantire coerenza, e poi demandare la scrittura del codice a un insieme di agenti guidati da quella specifica.

La documentazione come pratica operativa, non come overhead

Cambia anche dove vive la conoscenza. La conoscenza orale è deleteria: la sa chi la sa, non è condivisibile in modo trasparente e, aspetto ancora più rilevante, non è accessibile a un LLM.

Se la documentazione di un sistema esiste in forma strutturata e centralizzata, un agente AI può attingervi: sapere già come è configurato il deployment, dove sono le dipendenze critiche, quali scelte architetturali sono state prese e perché. La qualità del contesto disponibile diventa direttamente proporzionale alla qualità dell'output generato.

Questo cambia il rapporto con la scrittura dei documenti. Scrivere più documentazione è spostare il tempo dalla produzione alla progettazione, con due vantaggi diretti:

• meno lavoro implementativo: il codice generato a partire da una specifica ben scritta richiede meno iterazioni e meno correzioni;
• valore nel tempo: tra sei mesi, tornare su una funzionalità significa rileggere la documentazione, non ricostruire il ragionamento dal codice.

La sfida reale è di disciplina, non tecnica. Codice e documentazione tendono a divergere, e mantenere la coerenza richiede un sistema e una revisione continua.

Accountability: il codice generato è responsabilità umana

Un punto su cui non c'è ambiguità: non importa se il codice lo ha scritto un LLM o un essere umano, chi ne è responsabile è la persona che lo ha usato.

L'infrastruttura di regole e skill che stiamo costruendo serve a rendere questa responsabilità esercitabile concretamente, come pratica verificabile. Un engineer che usa l'AI deve essere in grado di capire e validare l'output. Se non lo capisce, non può firmarlo.

Funziona già oggi

Queste non sono considerazioni teoriche. Su alcuni progetti recenti, lavorare prima sul documento di progetto, anche in situazioni di caos informativo iniziale, ha ridotto drasticamente il ciclo di feedback e il lavoro implementativo. In altri casi, avere la documentazione strutturata ha permesso al team di testare e approvare funzionalità senza riallineamenti continui.

I vantaggi sono già visibili ora, nei progetti in cui questo approccio è stato applicato con disciplina.

Vale la pena sottolinearlo: questo vale anche quando l'AI non è nel mezzo. Una documentazione strutturata aiuta gli sviluppatori umani a lavorare in modo più efficace e più fluido, secondo le pratiche di sviluppo tradizionali, prima ancora che in un flusso AI-centrico. Il patrimonio informativo ben costruito è un vantaggio in sé, indipendentemente da chi, o cosa, lo usa per scrivere il codice.

***

Stiamo ancora costruendo questo flusso: alcune parti sono consolidate, altre in sperimentazione. Quello che è chiaro è la direzione: il valore si sposta dalla scrittura del codice alla costruzione del contesto. Chi inizia a lavorarci adesso avrà un vantaggio concreto su chi aspetta che il tema si stabilizzi.

Se vuoi sapere di più su come stiamo strutturando questo approccio, o confrontarti su come sta evolvendo il tuo flusso di sviluppo, scrivici. Altre riflessioni su AI e workflow sono in arrivo su questo blog.

***

Abbiamo scritto questo articolo con il supporto dell'AI. Se vuoi saperne di più su come usiamo questi strumenti per la scrittura, ecco la spiegazione.