Da scrittori di codice ad architetti di specifiche

Riflessioni su un mestiere che si trasforma sotto le nostre mani

Oggi ho passato la mattina a rivedere il materiale per un corso di formazione interno. Ventisei pagine dense, piene di workflow, comandi, checklist. A un certo punto mi sono fermato e ho guardato fuori dalla finestra. Mi sono chiesto: ma quando è successo tutto questo?

Un anno fa stavamo ancora discutendo se usare o meno Copilot per l’autocompletamento. Oggi scriviamo documenti chiamati “Constitution” che governano il comportamento di agenti ai che generano intere feature. Il salto non è stato graduale. È stato come svegliarsi una mattina e scoprire che il pavimento si è spostato di qualche centimetro durante la notte.

Il vibe coding e la sua seduzione

C’è un termine che mi ha colpito mentre preparavo il materiale: vibe coding. Descrivere vagamente cosa vuoi e lasciare che l’ai produca qualcosa. Lo abbiamo fatto tutti, nei primi mesi. C’era qualcosa di quasi magico nel vedere codice apparire dal nulla partendo da una descrizione approssimativa. Funzionava? A volte sì, spesso no. Ma la sensazione di velocità era inebriante.

Il problema è che quella velocità era un’illusione. Il codice generato così, senza specifiche precise, senza un’architettura pensata, accumulava debito tecnico a una velocità impressionante. Ogni funzionalità aggiunta era una scommessa. Forse oggi funziona, forse domani si rompe tutto quando qualcuno tocca qualcos’altro.

Ho visto POC partire come razzi e schiantarsi nel giro di poche settimane. Non perché l’ai avesse sbagliato, ma perché nessuno aveva pensato a cosa stavamo costruendo. Stavamo improvvisando con uno strumento potentissimo senza avere una partitura.

La specifica come nuova forma di espressione

La risposta che stiamo esplorando, e che cerchiamo di insegnare nel corso, ribalta completamente l’approccio. Si chiama spec-driven development e l’idea di fondo è semplice, quasi banale: prima scrivi cosa vuoi con precisione maniacale, poi lasci che qualcun altro (in questo caso un agente ai) lo implementi.

Ma c’è un aspetto che mi affascina e insieme mi inquieta. Scrivere specifiche precise è tremendamente difficile. Richiede di pensare a ogni edge case, ogni scenario di errore, ogni possibile ambiguità. Richiede di sapere esattamente cosa vuoi prima di averlo visto funzionare.

In un certo senso, è l’opposto del modo in cui molti di noi hanno imparato a programmare. Io ho imparato sperimentando, provando, sbagliando, correggendo. Un ciclo continuo di tentativi ed errori che alla fine produceva qualcosa che funzionava. Ora ci viene chiesto di pensare tutto in anticipo, di essere precisi prima di scrivere una singola riga di codice.

Non sono sicuro che sia un cambiamento solo positivo. Probabilmente perdiamo qualcosa nella sperimentazione, nella scoperta casuale di soluzioni eleganti che emergono mentre scrivi. Ma forse guadagniamo qualcos’altro: la possibilità di costruire sistemi più grandi e complessi di quanto avremmo mai potuto fare da soli.

Il paradosso delle competenze

Una cosa che mi ha fatto riflettere molto è il paradosso delle competenze che emerge da questo nuovo modo di lavorare. Nel documento che ho preparato c’è una frase che ho sottolineato più volte:

Questo non significa che le competenze tecniche diventino obsolete. Al contrario, servono competenze ancora più solide.

Sembra controintuitivo. Se l’ai scrive il codice, perché dovrei sapere programmare? La risposta è che devi sapere programmare meglio di prima per capire se quello che l’ai ha prodotto ha senso. Per validare l’architettura. Per identificare problemi di sicurezza. Per sapere quando qualcosa è un workaround fragile mascherato da soluzione elegante.

Ho visto junior entusiasmarsi per il codice generato dall’ai senza rendersi conto che conteneva vulnerabilità gravi. Query non parametrizzate, validazioni mancanti, secret hardcodati. L’ai aveva copiato pattern insicuri visti nel suo training data. Serviva qualcuno con esperienza per accorgersene.

In un certo senso, stiamo diventando reviewer a tempo pieno. Il nostro lavoro si sta spostando dalla produzione alla supervisione, dalla scrittura alla lettura critica. Non so se sia una perdita o un guadagno. Forse entrambe le cose.

La Constitution e l’illusione del controllo

Nel framework che stiamo adottando c’è un concetto centrale: la Constitution. È un documento che definisce i principi immutabili del progetto. Cose come “nessun any type permesso” o “coverage minimo 80%” o “ogni PR richiede code review umana”. L’idea è che l’ai debba rispettare questi principi in ogni decisione.

Funziona? In larga misura sì. L’ai segue le regole quando gliele dai in modo chiaro. Ma c’è qualcosa di leggermente ironico in tutto questo. Stiamo scrivendo costituzioni per macchine. Definendo leggi che algoritmi devono seguire. È un’inversione interessante del rapporto tra umani e strumenti.

Quello che mi chiedo, e non ho ancora una risposta, è fino a che punto queste regole scritte possano catturare ciò che intendiamo davvero. Posso scrivere “nessun workaround o hack nel codice” ma come faccio a definire esattamente cos’è un hack? A volte la distinzione tra una soluzione pragmatica e un hack è sfumata, contestuale, richiede giudizio. Quel giudizio, per ora, rimane umano.

Il tempo che non c’è più

Una cosa che è cambiata in modo sottile ma profondo è il rapporto con il tempo. Prima, quando stimavo quanto ci voleva per implementare una feature, pensavo in termini di ore o giorni di lavoro. Ora penso in termini di quanto tempo mi serve per scrivere una specifica abbastanza precisa e per validare l’output.

Paradossalmente, a volte ci vuole più tempo. Scrivere una specifica completa, chiarire tutte le ambiguità, definire ogni edge case può richiedere lo stesso tempo che avrei impiegato a scrivere il codice. Ma il tipo di lavoro è diverso. È più mentale, più astratto. Meno ore a fissare un debugger, più ore a pensare.

Non tutti nel team si trovano a loro agio con questo cambiamento. Alcuni colleghi amavano proprio quella sensazione di flow quando il codice scorre dalle dita, quando sei immerso nel problema e le soluzioni emergono quasi da sole. Quello stato mentale è più raro ora. Il lavoro è diventato più frammentato, più fatto di review e validazioni che di creazione continua.

La sicurezza come ossessione necessaria

C’è un aspetto del codice ai-generated ovviamente mi rende irrequieto: la sicurezza. Nel materiale del corso ho dedicato un’intera sezione ai rischi specifici. Pattern insicuri, dipendenze vulnerabili, query non parametrizzate. L’ai non ha malizia, ma non ha neanche prudenza. Riproduce quello che ha visto, inclusi gli errori.

La cosa che mi preoccupa è che molti di questi problemi non sono evidenti a prima vista. Il codice compila, i test passano, l’applicazione funziona. La vulnerabilità è nascosta, silente, in attesa che qualcuno la trovi e la sfrutti. Serve un occhio esperto per individuarla. Serve tempo per revisioni meticolose.

Abbiamo aggiunto tool automatici nella pipeline: audit delle dipendenze, scansione dei secret, analisi statica del codice. Aiutano, ma non bastano. Alla fine, qualcuno deve sedersi e leggere il codice riga per riga chiedendosi: cosa potrebbe andare storto qui? Ed ho imparato (di nuovo) l’importanza dei test e2e.

Cosa resta di noi

A volte mi chiedo cosa resterà del nostro mestiere tra cinque anni. Non nel senso apocalittico di “i programmatori saranno sostituiti”, che mi sembra una semplificazione. Ma nel senso di cosa faremo davvero, giorno per giorno.

Probabilmente scriveremo meno codice e più specifiche. Leggeremo più codice di quanto ne scriviamo. Passeremo più tempo a pensare all’architettura, alla sicurezza, alle implicazioni di ogni scelta. Saremo meno artigiani e più architetti, meno costruttori e più supervisori.

Non so se a qualcuno piacerà. A molti piaceva scrivere codice. A molti piaceva quella sensazione di costruire qualcosa con le proprie mani, anche se le mani erano solo metaforiche. Forse quella sensazione si trasformerà in qualcos’altro. O forse la si cercherà altrove, in progetti personali dove nessuno ti obbliga a essere efficiente.

Un mestiere in transizione

Quello che sto cercando di trasmettere nel corso, al di là dei comandi e delle checklist, è la consapevolezza che siamo in un momento di transizione. Non sappiamo ancora dove stiamo andando, ma sappiamo che non torneremo indietro.

Il vibe coding è stato un esperimento, una fase adolescenziale nell’uso di questi strumenti. Ora stiamo cercando di diventare adulti, di costruire processi e discipline che ci permettano di usare questa potenza senza farci male. È un lavoro in corso, ovviamente.

Tra qualche mese probabilmente rivedrò questo materiale e lo troverò già obsoleto. Qualcosa sarà cambiato di nuovo. Gli strumenti saranno diversi, i workflow si saranno evoluti. È il bello e il brutto di lavorare in un campo che si muove così velocemente.

Per ora, quello che posso fare è documentare quello che impariamo, condividerlo con il team, cercare di costruire competenze che vadano oltre lo strumento specifico. La capacità di pensare in modo strutturato, di scrivere specifiche precise, di validare criticamente l’output di qualcun altro: queste mi sembrano abilità che resteranno utili qualunque cosa succeda e che daranno valore alle persone.

O, almeno, è quello che mi ripeto ultimamente.