Il vibe coding ha cambiato chi può produrre un'applicazione dall'aspetto funzionante. Un prompt può generare schermate, collegare un'API e assemblare un flusso di lavoro plausibile prima che un team di ingegneria tradizionale abbia completato la sua prima revisione del design.

Questa velocità crea un nuovo problema di assunzione e distribuzione: una demo non è più una prova forte del fatto che il software sia valido. I datori di lavoro porranno sempre più spesso una domanda più difficile: questo sistema costruito dall'IA può comportarsi correttamente quando gli input sono disordinati, le dipendenze falliscono, gli utenti ripetono le azioni e il modello sottostante cambia?

La risposta arriverà da un'asticella della qualità che assomiglia meno alla rifinitura visiva e più a una verifica disciplinata del software. Le persone che si distingueranno non si limiteranno a mostrare ciò che ha prodotto uno strumento di coding basato sull'IA. Mostreranno come l'hanno testato, che cosa non può fare in sicurezza e come sanno che una modifica non ha rotto qualcos'altro.

Un benchmark è una prova, non un punteggio in classifica

I benchmark open source per gli agenti di coding offrono utili punti di partenza, ma misurano capacità diverse. SWE-bench usa problemi reali di GitHub e snapshot di repository, risultando quindi pertinente per il lavoro di manutenzione. Terminal-Bench verifica l'interazione con la riga di comando. Altri benchmark elencati, tra cui SlopCodeBench e ProgramBench, si concentrano su aspetti diversi del codice generato e del comportamento degli agenti.

Questi benchmark possono aiutare a confrontare gli strumenti o a stabilire una baseline, ma i datori di lavoro dovrebbero essere cauti nel considerare un singolo punteggio come prova della preparazione alla produzione. Un modello che risolve problemi di repository può comunque produrre una logica di autorizzazione non sicura. Un agente che completa attività da terminale può non riuscire a preservare lo stato durante un flusso di lavoro lungo. Un'applicazione web rifinita può superare una demo sul percorso felice gestendo però male i tentativi e i pagamenti duplicati.

Un portfolio credibile o una revisione interna dovrebbe quindi includere un insieme di valutazione specifico per l'attività. L'insieme potrebbe contenere segnalazioni di bug rappresentative, percorsi utente normali, input malformati, limiti di autorizzazione, guasti delle dipendenze e regressioni precedentemente corrette. Ogni caso dovrebbe avere un risultato atteso esplicito, non soltanto uno screenshot dall'aspetto corretto.

Il pacchetto minimo di test per il software costruito dall'IA

Per una piccola applicazione, è possibile creare un utile pacchetto di qualità senza un elaborato laboratorio di ricerca:

  • Test di accettazione: verificano il comportamento visibile all'utente per i flussi di lavoro più importanti, inclusi gli esiti positivi e negativi.
  • Test unitari e di integrazione: verificano le regole di business in isolamento e confermano che database, API, code e autenticazione funzionino insieme come previsto.
  • Test negativi: inviano input mancanti, malformati, eccessivamente grandi, duplicati e non autorizzati. Il codice generato dall'IA spesso dà il meglio di sé nel percorso mostrato nel prompt, quindi i percorsi non richiesti sono importanti.
  • Test di regressione: trasformano ogni difetto scoperto in un test permanente. Una demo superata dopo una correzione non basta se lo stesso errore può ripresentarsi nella modifica generata successiva.
  • Controlli di sicurezza: verificano il controllo degli accessi, la gestione dei segreti, le difese contro le iniezioni, le vulnerabilità delle dipendenze e la possibilità che contenuti non attendibili influenzino le chiamate agli strumenti o le azioni privilegiate.
  • Controlli operativi: verificano timeout, tentativi, idempotenza, registri, avvisi e comportamenti sicuri quando una dipendenza non è disponibile.

Questo è vicino alla mentalità dell'ingegneria della qualità descritta nel resoconto di Stack Overflow sul ciclo di vita agentico dello sviluppo software. Il cambiamento importante è culturale: la garanzia della qualità non è un'ispezione finale dopo che un'IA ha scritto il codice. È la struttura che rende la generazione rapida abbastanza sicura da poter essere utilizzata.

Testare l'orchestrazione, non soltanto l'output

Quando il software include un agente di IA, i normali test applicativi sono necessari ma insufficienti. Il sistema può fallire perché il modello ha frainteso una richiesta, ma può anche fallire perché l'orchestrazione circostante ha perso il contesto, ha chiamato due volte uno strumento, ha accettato un output strutturato malformato o non è mai terminata.

Le aree di regressione pre-distribuzione raccomandate dal digest costituiscono una checklist pratica: perdita del contesto, idempotenza degli strumenti, prompt injection, output strutturato, mancata terminazione, grounding del recupero e reidratazione dello stato. Si tratta di proprietà ingegneristiche verificabili.

Per esempio, un test può eseguire due volte la stessa richiesta e confermare che il secondo tentativo non crei un ordine duplicato. Un altro può interrompere un agente a metà di un flusso di lavoro, riavviarlo e verificare che riprenda da uno stato valido invece di ripetere un'azione irreversibile. Un test di recupero può richiedere al sistema di citare o restituire soltanto informazioni provenienti da un insieme di fonti approvate. Un test dell'output strutturato può fornire una risposta non valida e confermare che l'applicazione la rifiuti in modo sicuro invece di trattarla silenziosamente come dati validi.

I sistemi di lunga durata e multi-agente hanno bisogno di registrazioni dei guasti particolarmente chiare. I ricercatori stanno lavorando sull'attribuzione automatizzata dei guasti, perché può essere difficile identificare quale agente abbia causato un errore e in quale punto di una lunga catena di interazioni. In termini pratici, i team dovrebbero conservare chiamate agli strumenti, input, output, versioni dei modelli, timestamp, transizioni di stato e decisioni finali in una traccia di audit attenta alla privacy. Senza queste prove, un test rosso indica che qualcosa è fallito, ma non da dove iniziare a correggerlo.

La riproducibilità diventerà un vantaggio professionale

Il codice generato dall'IA è variabile. Una nuova esecuzione può produrre un'implementazione diversa; un aggiornamento del modello può cambiare il comportamento; un'interruzione del servizio di un provider può alterare il routing o la latenza. I datori di lavoro apprezzeranno quindi i candidati capaci di rendere ripetibili le valutazioni.

Ciò significa fissare, ove possibile, gli snapshot dei modelli, registrare prompt e configurazione, controllare la casualità quando la piattaforma lo consente ed eseguire più prove per le attività i cui risultati variano. Il digest indica specificamente gli snapshot fissati, una temperatura bassa o pari a zero quando disponibile e i gate CI/CD con limiti di confidenza come utili misure di salvaguardia.

Un report pratico dovrebbe distinguere almeno tre risultati:

  1. Tasso di superamento: quanti casi hanno avuto successo.
  2. Coerenza: con quale frequenza lo stesso caso ha successo in esecuzioni ripetute.
  3. Gravità: se i fallimenti sono estetici, scomodi, dannosi per i dati, rilevanti per la sicurezza o in grado di causare un’azione esterna non sicura.

Un sistema che supera 19 verifiche di formattazione a basso rischio su 20 non è necessariamente migliore di uno che supera 18 casi su 20 ma non oltrepassa mai un confine di autorizzazione. Il livello qualitativo deve ponderare i fallimenti in base alle conseguenze.

La revisione umana dovrebbe concentrarsi sul rischio, non su ogni riga

Lo scopo di una migliore automazione non è costringere una persona a rileggere ogni token prodotto da un’IA. È indirizzare l’attenzione umana verso le decisioni che i test non possono determinare pienamente.

I revisori dovrebbero concentrarsi su autenticazione e autorizzazione, conservazione dei dati, azioni finanziarie o contrattuali, privacy, migrazioni, recupero dagli errori, autorizzazioni di terze parti e modifiche che influiscono sul sistema stesso di valutazione. Per un agente, dovrebbero inoltre verificare quali strumenti può chiamare, a quali dati può accedere ciascuno strumento e se è necessaria un’approvazione prima di un’azione irreversibile.

Diff visibili, flussi di approvazione, conversazioni archiviate e log di audit—funzionalità evidenziate nella descrizione di Slack Code della programmazione collaborativa con l’IA—indicano un’aspettativa più ampia: la cronologia di come è stato realizzato il software sarà importante. Un revisore dovrebbe poter comprendere la richiesta, esaminare la modifica generata, vedere le prove dei test e identificare chi ha approvato il rilascio.

Questa documentazione non è burocrazia fine a se stessa. Permette di distinguere una demo impressionante da una modifica controllata che un’altra persona può mantenere.

Cosa inserire in un portfolio o in un colloquio

Per i candidati, la dimostrazione più efficace è un piccolo sistema con una storia della qualità deliberatamente trasparente. Includete il repository, le istruzioni per la configurazione, note sull’architettura, i comandi dei test, casi di test rappresentativi, limitazioni note e un breve rapporto sui fallimenti. Mostrate uno o due bug individuati e trasformati in test di regressione. Spiegate quale modello o agente di programmazione è stato utilizzato, senza presentare lo strumento come autore delle decisioni ingegneristiche.

Se l’applicazione usa un agente, documentate le autorizzazioni degli strumenti, il modello dello stato, la politica dei nuovi tentativi, la condizione di terminazione e i punti di approvazione umana. Se usa il recupero di informazioni, mostrate come vengono selezionate le fonti e cosa accade quando mancano prove. Se chiama servizi esterni, dimostrate il comportamento in caso di timeout e di richieste duplicate.

Non dichiarate l’affidabilità sulla base di una singola registrazione riuscita. Un’affermazione verificabile suona più così: “In 30 esecuzioni registrate di questi 12 scenari, il sistema ha soddisfatto i criteri di accettazione in 28; i due fallimenti riguardavano un input di data ambiguo ed entrambi sono documentati.” Il numero in sé è meno importante del metodo, dei confini e dell’onestà riguardo a ciò che non è ancora stato testato.

La nuova definizione di velocità

L’IA riduce il costo di produrre una prima versione. Non elimina il costo di sapere se quella versione merita fiducia. Anzi, una generazione più rapida può rendere la valutazione ancora più importante, perché tra un rilascio e l’altro possono accumularsi più modifiche non revisionate.

Il professionista dell’era post-vibe-coding sarà valutato in base al ciclo: definire il comportamento, generare o modificare il codice, testare casi realistici e avversariali, esaminare le decisioni ad alto rischio, registrare i fallimenti e migliorare il sistema senza perdere le prove. I benchmark possono aiutare a confrontare le capacità. Le pratiche di QA determinano se tali capacità si trasformano in software affidabile.

Il livello qualitativo, quindi, non è “Sai creare un’app con l’IA?”. È “Sai dimostrare cosa fa l’app, rilevare quando smette di farlo e progettare i limiti che impediscono a un fallimento di trasformarsi in un incidente?”