Planul pe care îl sari e pana pe care o depanezi mai târziu
Fiecare cadru din ingineria software îți spune să te miști rapid, să livrezi devreme, să iterezi în producție. Pentru site-uri generate de AI, e exact invers. Builder-ul de aici refuză să scrie cod direct din prompt-ul tău — se oprește, scrie un plan și așteaptă să te uiți la el — iar acest refuz e singura decizie pe care se bazează tot restul acestui pipeline. Mai lent la început, mai ieftin peste tot după. Aleg acest compromis de fiecare dată, și cred că majoritatea celor care argumentează pentru varianta opusă nu au văzut de fapt cât costă o presupunere greșită mai jos pe traseu.
Iată modul de eșec pe care planul există să-l prevină. Scrii „un site de rezervări pentru studioul meu” și apeși pe go. Sistemul trebuie să ghicească ce înseamnă „rezervare” — un widget de calendar, un embed de la terți, un sistem real de rezervări cu verificare de conflicte — și trebuie să ghicească înainte să fi scris ceva, pentru că nu există altă ordine în care să se facă asta. Ghicești greșit într-un plan, iar remedierea e o propoziție, cinci secunde, gata. Ghicești greșit în codul deja generat și nu mai editezi o propoziție, ci desfaci zece fișiere care depind deja de presupunerea greșită. Am văzut ambele variante întâmplându-se. Corecția la etapa de plan e un schimb de mesaje. Schimbarea de direcție după generare, pe aceeași ambiguitate identică, înseamnă aruncat totul și reconstruit.
Planul nu e doar o listă de sarcini, și asta e partea pe care oamenii o ratează. E un contract, iar sistemul se ține de el: un verificator de conformitate, unul dintre agenții care trebuie să aprobe înainte ca un build să fie livrat, compară site-ul finalizat cu planul pe care l-ai aprobat. S-a construit fiecare pagină planificată? Lista de funcționalități corespunde cu ce a fost livrat? „Gata” nu e o senzație aici — e relativ la o promisiune scrisă, verificabilă linie cu linie. E o garanție mai puternică decât „codul rulează”, și o obții doar pentru că există un document față de care poți verifica. Elimină planul și elimini metrul de măsurat.
Unde chiar dă roade
Influența ta ca persoană care conduce build-ul e concentrată la început, fie că o exerciți, fie că nu. Dacă îți pasă de arhitectura informației, de structura paginilor, de ce funcționalități ajung în v1 versus v2 — acea meticulozitate valorează de zece ori mai mult la revizuirea planului decât după prima trecere de generare. Patru minute în plus recitind un plan bat un du-te-vino pentru repararea unui build care deja a luat-o razna.
Cel mai clar exemplu e tipul de produs — site static simplu, aplicație instalabilă, build pe framework, aplicație cu backend cu persistență reală. Arată ca un meniu drop-down. Nu este. E cea mai structurală alegere din tot procesul, pentru că decide în tăcere o duzină de lucruri care nu au nimic de-a face cu aspectul site-ului.
| Tip de produs | Previzualizare | Publică | Conturi / bază de date |
|---|---|---|---|
| Site static simplu | Instant, pentru că sunt doar fișiere statice | Output-ul static se copiază curat | Nu e posibil — a cere autentificare înseamnă a cere ceva ce tipul respectiv nu poate face structural |
| Build pe framework | Se compilează întâi; un build eșuat apare ca „fără previzualizare”, nu ca „pagină stricată” | Aceeași cale curată de copiere statică, odată compilat | Nu e posibil |
| Aplicație cu backend | — | Are nevoie de un loc unde să ruleze efectiv un proces, ceea ce eșuează diferit — un proces căzut, nu un fișier lipsă | Singurul tip în care conturile și bazele de date există în mod real |
Și nu poți face upgrade la tip mai târziu, la modul superficial. A trece de la site simplu la aplicație cu backend nu e un comutator de setări — e aproape un al doilea build, pentru că jumătate din presupunerile planului (cum se încarcă paginile, unde stau datele, ce înseamnă „publicare”) au fost făcute pentru tipul vechi. Deci spune asta la momentul planificării, chiar dacă doar pe jumătate sigur: „e posibil să am nevoie de conturi”. A planifica pentru o aplicație cu backend și a folosi doar părțile statice nu costă nimic. A descoperi că aveai nevoie de una după fapt costă o reconstrucție.
Unde criticii au dreptate
Nimic din toate astea nu e gratis și nu voi pretinde că este. Spațiile de lucru izolate per execuție înseamnă că fișierele tale de cunoaștere sunt copiate proaspăt, nimic nu ajunge înapoi pe mașina ta — bine pentru tine dacă laptopul îți moare în timpul unui build, rău pentru latență, pentru că a provizionarea unui spațiu de lucru și, pentru build-urile pe framework, rularea unei instalări reale de dependințe într-un container izolat durează timp real. Acel container izolat există pentru că un build pe framework rulează `npm install` și scripturi de build arbitrare — cod pe care nu l-ai scris tu, executat cu privilegii de build — iar a face asta pe un host partajat fără izolare e la un atac de dependency-confusion distanță de a atinge datele altui client. Rapid-dar-nesigur era o opțiune. Pur și simplu nu era un compromis care merita făcut.
Aceeași poveste cu verificarea. Un build finalizat nu părăsește pipeline-ul când se oprește generarea; părăsește atunci când un set de verificatori independenți încetează să mai găsească lucruri care merită blocate:
- Revizuire de cod
- Securitate
- Linkuri și SEO
- Accesibilitate
- Conformitate
- O rulare reală în browser
Nu e o singură trecere, e semnalare-reparare-reverificare, în buclă până nimeni nu mai are nimic de spus, pentru că o singură trecere de linter poate rata o regresie introdusă chiar de propria reparare. Repararea unui link stricat și stricarea accidentală a ierarhiei de titluri pe aceeași pagină e exact genul de lucru pe care o verificare unică îl ratează, iar o reverificare îl prinde. Costul onest al acestei bucle e câte un build ocazional care durează un minut în plus chiar la final, fără motiv vizibil. Oamenii observă acel minut. Nu observă cei șase agenți care tocmai au terminat de dezbătut site-ul lor. E o plângere justă despre experiență — pur și simplu nu cred că e un argument bun pentru a livra fără ca dezbaterea să fi avut loc deloc.
