Il piano che salti è l'incidente che debuggerai più tardi
Ogni metodologia dell'ingegneria del software ti dice di muoverti velocemente, rilasciare presto, iterare in produzione. Per i siti web generati dall'AI, è il contrario. Il builder qui si rifiuta di generare codice direttamente dal tuo prompt in streaming — si ferma, scrive un piano e aspetta che tu lo guardi — e quel rifiuto è l'unica decisione su cui è costruito tutto il resto della pipeline. Più lento all'inizio, più economico dopo, in ogni fase. Accetto quel compromesso ogni volta, e credo che la maggior parte delle persone che sostiene il contrario non abbia mai visto davvero quanto costi a valle un'ipotesi sbagliata.
Ecco la modalità di fallimento che il piano esiste per prevenire. Scrivi "un sito di prenotazioni per il mio studio" e premi invio. Il sistema deve indovinare cosa significa "prenotazioni" — un widget calendario, un embed di terze parti, un vero sistema di prenotazione con controllo dei conflitti — e deve indovinarlo prima di aver scritto qualcosa, perché non c'è altro ordine possibile. Sbagliare l'ipotesi all'interno di un piano significa una correzione di una frase, cinque secondi, fatto. Sbagliare l'ipotesi dentro codice già generato non significa più modificare una frase, significa smontare dieci file che già dipendono dall'assunzione sbagliata. Ho visto entrambi gli scenari. La correzione in fase di pianificazione è un solo scambio. Il cambio di rotta post-generazione sulla stessa identica ambiguità è uno scarta-e-ricostruisci.
Il piano non è solo una lista di cose da fare, e questo è il punto che molti non colgono. È un contratto, e il sistema si attiene ad esso: un verificatore di conformità, uno degli agenti che deve dare l'ok prima che una build venga rilasciata, confronta il sito finito con il piano che hai approvato. Ogni pagina prevista è stata costruita? L'elenco delle funzionalità corrisponde a quello che è stato rilasciato? "Fatto" qui non è una sensazione — è relativo a una promessa scritta, verificabile riga per riga. È una garanzia più solida di "il codice funziona", e l'ottieni solo perché esiste un documento con cui confrontarsi. Togli il piano e togli il metro di misura.
Dove questo ripaga davvero
La tua influenza come persona che guida la build è anticipata all'inizio, che tu la sfrutti o no. Se ti interessa l'architettura delle informazioni, la struttura delle pagine, quali funzionalità entrano nella v1 rispetto alla v2 — quella meticolosità vale dieci volte più in fase di revisione del piano che dopo il primo passaggio di generazione. Quattro minuti in più a rileggere un piano battono un andirivieni per correggere una build già andata fuori strada.
L'esempio più chiaro è il tipo di prodotto — sito statico semplice, app installabile, build su framework, app con backend e persistenza reale. Sembra un menu a tendina. Non lo è. È la scelta più strutturale di tutto il processo, perché decide silenziosamente una dozzina di cose che non hanno nulla a che fare con l'aspetto del sito.
| Tipo di prodotto | Anteprima | Pubblica | Account / database |
|---|---|---|---|
| Sito statico semplice | Istantaneo, essendo solo file statici | L'output statico si copia in modo pulito | Non possibile — richiedere un login significa chiedere qualcosa che il tipo non può fare per costruzione |
| Build su framework | Viene compilata prima; una build rotta si manifesta come "nessuna anteprima", non come "pagina rotta" | Stesso percorso di copia statica pulita, una volta compilata | Non possibile |
| App con backend | — | Ha bisogno di un posto dove eseguire davvero un processo, e fallisce in modo diverso — un processo che si blocca, non un file mancante | L'unico tipo in cui esistono davvero account e database |
E non puoi passare disinvoltamente a un tipo superiore in un secondo momento. Passare da un sito statico a un'app basata su server non è un semplice interruttore nelle impostazioni: è quasi una seconda build, perché metà delle assunzioni del piano (come si caricano le pagine, dove risiedono i dati, cosa significa "pubblicare") sono state fatte sulla base del vecchio tipo. Quindi dillo in fase di pianificazione, anche se sei solo a metà sicuro: "potrei aver bisogno di account". Pianificare un'app basata su server e usare solo le parti statiche non costa nulla. Scoprire a posteriori che ne avevi bisogno costa una ricostruzione.
Dove i critici hanno ragione
Niente di tutto questo è gratuito, e non fingerò che lo sia. Gli spazi di lavoro isolati per ogni esecuzione significano che i tuoi file di conoscenza vengono copiati da zero, senza che nulla torni indietro sul tuo computer — un bene per te se il tuo laptop si guasta a metà build, ma un male per la latenza, perché provisionare uno spazio di lavoro e, per le build basate su framework, eseguire una vera installazione delle dipendenze dentro un confine di container richiede tempo reale. Quel confine di container esiste perché una build basata su framework esegue `npm install` e script di build arbitrari — codice che non hai scritto tu, eseguito con privilegi a livello di build — e farlo su un host condiviso senza isolamento è a un solo attacco di dependency-confusion di distanza dal toccare i dati di un altro tenant. L'opzione veloce-ma-insicura era disponibile. Semplicemente non era un compromesso che valesse la pena fare.
Stessa storia per la verifica. Una build finita non esce dalla pipeline quando finisce la generazione; esce quando un insieme di verificatori indipendenti smette di trovare qualcosa che valga la pena bloccare:
- Revisione del codice
- Sicurezza
- Link e SEO
- Accessibilità
- Conformità
- Un'esecuzione reale nel browser
Non è un singolo passaggio, è un ciclo di segnala-correggi-ricontrolla, che continua finché nessuno ha più nulla da dire, perché un singolo passaggio di linting può non accorgersi di una regressione introdotta dalla sua stessa correzione. Riparare un link rotto e rompere accidentalmente la gerarchia dei titoli sulla stessa pagina è esattamente il tipo di cosa che un controllo singolo si lascia sfuggire e un ricontrollo intercetta. Il costo onesto di questo ciclo è occasionalmente una build che impiega un minuto in più proprio alla fine senza motivo apparente. Le persone notano quel minuto. Non notano i sei agenti che hanno appena finito di discutere sul loro sito. È una lamentela legittima sull'esperienza — semplicemente non credo sia un buon argomento per pubblicare senza che quella discussione sia mai avvenuta.
