La nostra AI policy per il software: perché non crediamo nel Vibe Coding

Negli ultimi mesi si è parlato moltissimo di AI generativa applicata allo sviluppo software. Spesso, però, il dibattito si è polarizzato in modo quasi caricaturale: da una parte c’è chi la presenta come una rivoluzione inevitabile, capace di scrivere software quasi da sola; dall’altra c’è chi la liquida come una scorciatoia pericolosa, buona soltanto a produrre codice mediocre.

La nostra posizione, qui in Ryadel, è più concreta e meno ideologica. Non siamo contrari all’uso dell’AI nel software; al contrario, la riteniamo spesso utile. La utilizziamo, la testiamo, la valutiamo e, in alcuni casi, ci fa risparmiare tempo reale. Proprio perché la usiamo, però, abbiamo maturato una convinzione piuttosto netta: un conto è usare l’AI come assistente, un altro è usarla come surrogato dell’autorialità, del giudizio ingegneristico e della responsabilità tecnica.

Per questo motivo abbiamo iniziato a inserire una AI policy in tutti i nostri progetti GitHub. Non come gesto simbolico, e nemmeno per fare retorica anti-AI, ma per mettere nero su bianco una linea per noi importante: il software che pubblichiamo non è un prodotto di “vibe coding”. È software pensato, progettato, scritto e mantenuto da esseri umani, eventualmente con l’aiuto di strumenti automatici, ma senza delegare a questi strumenti la responsabilità finale.

Non facciamo "vibe coding"

La formula può suonare polemica, ma non ci interessa fare la guerra a una buzzword. Ci interessa chiarire un principio. Quando diciamo che i nostri progetti non sono frutto di "vibe coding", intendiamo prendere le distanze da un’idea di sviluppo software in cui si accettano output generati quasi automaticamente solo perché sembrano plausibili, compilano o danno l’impressione di funzionare.

Chi sviluppa software da abbastanza tempo sa bene che la plausibilità non basta. Un blocco di codice sorgente può sembrare corretto e invece introdurre bug sottili, regressioni, vulnerabilità, scelte architetturali discutibili o costi manutentivi altissimi. E questo vale già per il codice scritto da esseri umani. Quando nel processo entra un sistema generativo, che per definizione produce testo credibile ma non necessariamente corretto, il rischio aumenta inevitabilmente.

È qui che, secondo noi, passa la differenza tra un uso serio dell’AI e un uso superficiale: non è un problema il fatto che un modello generi codice; il problema nasce quando quel codice viene trattato come se fosse in qualche modo garantito dallo strumento che lo ha prodotto. Non lo è.

AI come assistente, non autore

Questo è il principio centrale della nostra policy, ed è anche la sintesi più onesta del nostro approccio. L’AI generativa può aiutare in molti modi: può accelerare la ricerca, produrre una prima bozza di documentazione, suggerire refactoring, creare scaffolding per i test, evidenziare possibili punti deboli, confrontare approcci alternativi o segnalare vulnerabilità e criticità architetturali che meritano attenzione.

Fin qui, nulla di scandaloso. Anzi, sarebbe poco intelligente rifiutare a priori uno strumento che, se usato bene, può alleggerire parte del lavoro ripetitivo e velocizzare alcune fasi esplorative.

Quello che non accettiamo è il passaggio successivo, cioè l’idea che l’assistenza possa trasformarsi in sostituzione. Non crediamo che l’AI possa essere considerata autrice del software, almeno non nel senso serio del termine. Il motivo è semplice: l’AI generativa non progetta nel significato pieno della parola, non risponde delle conseguenze delle sue scelte, non si assume i compromessi che introduce e, soprattutto, non è in grado di intervenire quando qualcosa va storto, magari nel momento peggiore possibile.

Per dirla in una frase: non è in grado di assumersi la responsabilità di ciò che produce, sia che si tratti di una decisione architetturale sbagliata, di una fuga di dati o di una migrazione distruttiva.

Per questo continuiamo a ritenere che l’autorialità del software debba restare umana. E con questo non intendiamo aver scritto materialmente ogni singola riga, ma averne compreso il senso, valutato l’impatto e saperne difendere le scelte.

Dove l’AI ci sembra davvero utile

Una delle ragioni per cui non ci interessa fare discorsi apocalittici è che sarebbe disonesto. L’AI, in alcuni contesti, aiuta davvero. Negarlo sarebbe poco serio. Il tema, per noi, è usarla nei punti in cui aumenta la produttività senza ridurre il livello di controllo.

Ad esempio, la troviamo utile quando dobbiamo:

• fare ricerca preliminare su una libreria, una feature o un pattern;
• ottenere una prima bozza di documentazione o di testo tecnico da rifinire;
• valutare possibili refactoring o alternative implementative;
• generare scaffolding iniziale per test unitari o di integrazione;
• fare una revisione ragionata di codice già scritto;
• cercare potenziali vulnerabilità, code smell o edge case trascurati;
• mettere in discussione una soluzione che stiamo considerando, per capire se stiamo ignorando qualche rischio.

In tutti questi casi, il valore non sta nel premere un pulsante e prendere per buono il risultato, ma nel creare un confronto tecnico utile. A volte l’AI conferma una strada, altre volte suggerisce un’idea sensata; molto spesso, però, dice cose banali, mescola intuizioni corrette a dettagli imprecisi oppure prende una direzione del tutto sbagliata. Anche per questo, ai nostri occhi, resta uno strumento di supporto, non una fonte di verità.

Dove l’AI diventa pericolosa

Il punto critico non è l’output generato in sé, ma il modo in cui viene recepito. L’AI diventa pericolosa quando produce codice o testo tecnico che nessuno legge davvero, nessuno verifica fino in fondo e nessuno integra con consapevolezza nell’architettura esistente.

È questo l’aspetto che ci convince meno di molto entusiasmo che vediamo in giro. Si parla spesso di velocità, molto meno del debito tecnico che si accumula quando si accettano blocchi di codice sufficientemente plausibili senza una vera ownership umana. Il conto, quasi mai, arriva subito: complessità inutile, incoerenze stilistiche, regressioni difficili da diagnosticare, test che sembrano esserci ma non verificano nulla di davvero utile. Sono tutti debiti tecnici che si accumulano in silenzio per settimane o mesi e finiscono per emergere quando correggerli costa molto di più.

La responsabilità non è delegabile

Questa è probabilmente la parte a cui teniamo di più. In un progetto serio, qualcuno deve essere responsabile dell’architettura, del comportamento del codice, della sicurezza, della privacy, dell’impatto operativo, delle migrazioni, dei test, dell’infrastruttura e della documentazione. Per noi, quel qualcuno non può essere un modello generativo.

Può sembrare un’osservazione banale, ma oggi va ribadita con chiarezza, perché vediamo una tendenza crescente a confondere la capacità di produrre output con la capacità di assumersene la responsabilità. Sono due cose completamente diverse. Se pubblichiamo una modifica o approviamo una pull request, la responsabilità è nostra. Allo stesso modo, se accettiamo un refactoring suggerito da un tool AI che introduce un bug grave, la responsabilità non è del tool: è sempre di chi ha deciso di integrarlo senza comprenderlo davvero o senza valutarne le conseguenze.

Da questo punto di vista, l’AI non cambia nulla del patto implicito che sta alla base dello sviluppo software fin da quando esiste il concetto di codice sorgente condiviso: chi effettua il commit di un cambiamento è anche chi ne risponde.

Cosa chiediamo ai contributor

La nostra policy non esclude chi usa strumenti AI nel proprio workflow. Oggi sarebbe poco realistico, e probabilmente anche poco utile. Molti sviluppatori li usano in modo più o meno esteso, e non consideriamo questo un problema in sé.

Quello che chiediamo, però, è che le contribution riflettano una reale revisione umana e una reale assunzione di responsabilità. Non vogliamo pull request generate interamente dall’AI e poi riversate nel repository senza una verifica sostanziale. Non perché “si vede” sempre, ma perché anche quando non si vede subito, quasi sempre si sente dopo.

In termini pratici, ogni contributo dovrebbe essere:

• letto e compreso dalla persona che lo invia;
• controllato per correttezza, sicurezza e coerenza con il progetto;
• validato rispetto ad architettura, convenzioni e documentazione esistente;
• modificato dove necessario, invece di essere accettato passivamente da uno strumento generativo.

Per noi non è una richiesta estrema. È il minimo sindacale, il livello minimo di serietà che ci aspettiamo da chi contribuisce a un progetto software che vuole restare manutenibile.

Come intendiamo usare l’AI nei nostri progetti

La risposta, in fondo, è semplice: intendiamo usarla molto, ma con disciplina. La useremo per velocizzare attività accessorie, per farci aiutare nell’analisi, per ottenere second opinion, per migliorare testi, per esplorare alternative, per rivedere codice e per automatizzare parte del lavoro più meccanico. Non la useremo, però, come alibi per abbassare il livello di comprensione, revisione o responsabilità.

Non ci interessa pubblicare codice “prodotto rapidamente” se questo significa perdere controllo su ciò che stiamo costruendo. Preferiamo andare leggermente più piano e sapere esattamente perché una certa soluzione è finita nel progetto. Preferiamo usare l’AI per aumentare la qualità del nostro lavoro, non per anestetizzare il nostro giudizio.

Se dovessimo riassumere la nostra posizione in una frase, useremmo questa: non siamo contrari all’AI-assisted development; siamo contrari a trattare output non verificati come se fossero software engineering.

Conclusioni

Inserire una AI policy in un progetto, per noi, non significa fare una dichiarazione ideologica. Significa chiarire un metodo di lavoro. Significa dire che l’AI può stare nel processo, ma non al posto della responsabilità umana. Significa riconoscere l’utilità dello strumento senza rinunciare ai principi che rendono il software qualcosa di più di una semplice sequenza di token plausibili.

È probabile che gli strumenti generativi continuino a migliorare, e sarebbe ingenuo pensare il contrario. Ma anche ammesso che diventino molto più efficaci di oggi, resterà comunque centrale una domanda che, per noi, non scompare: chi ha capito davvero questo codice, chi ha deciso di inserirlo e chi ne risponde?

Finché la risposta a questa domanda resterà “un essere umano”, allora l’AI potrà avere un ruolo utile. Se invece la risposta inizierà a diventare vaga, automatica o deresponsabilizzata, allora non staremo più parlando di un aiuto allo sviluppo software, ma di una rinuncia progressiva a una parte essenziale del mestiere.