Viteza AI, susținută de ingineria necesară unei livrări sigure.

Fiecare proiect are un fișier CLAUDE.md sau AGENTS.md: regulile pe care agentul nu are voie să le încalce, comenzile care dovedesc că o modificare funcționează și deciziile deja luate. Un fișier NEXT-SESSION.md transferă starea reală către sesiunea următoare: ce este publicat, ce rămâne blocat și ce nu a fost încă testat. Un agent care pornește fără context citește aceste instrucțiuni înainte de a modifica ceva.

Unde se vede: Timber Logistic păstrează lista pentru ziua lansării separat de backlog, deoarece mai multe puncte pot părea rezolvate fără să fie verificate în realitate.

Fiecare repository are o comandă de verificare: tipuri, lint, teste, build și auditul dependențelor. CI o rulează la fiecare push. Pentru proiectele cu bază de date, testele includ chiar proprietatea de securitate: două conturi reale confirmă că niciunul nu poate citi datele celuilalt, iar contul demo apelează funcția de ștergere și așteaptă un refuz. Dacă o garanție contează, există un test care eșuează clar atunci când ea nu mai este valabilă.

Unde se vede: FoodBoard: 193 de teste. Kinetiq: 34, inclusiv afirmațiile de accesibilitate din README. Timber Logistic: CI decodează fiecare JWT din bundle și eșuează dacă găsește o cheie de serviciu.

Agenții scriu rapid cod pentru client, iar un filtru după proprietar poate dispărea prin omiterea unei singure condiții. De aceea autorizarea se află în politicile RLS din Postgres și în regulile Firestore. Clientul nu poate formula o interogare care traversează limitele dintre utilizatori. Această arhitectură permite agentului să se miște rapid în interfață: efectul unei greșeli rămâne o pagină defectă, nu un incident de securitate.

Unde se vede: Timber Logistic: RLS pe toate cele 20 de tabele, fiecare schimbare de stare prin proceduri SECURITY DEFINER și nicio politică UPDATE generică.

Două exemple recente: procesul de prerandare pentru previzualizarea meniurilor serializa descrierea restaurantului într-un bloc JSON-LD inline, iar testul a arătat că textul literal </script> putea închide blocul prea devreme. În alt caz, butonul de ștergere al contului demo era ascuns în antet, ceea ce ținea doar de prezentare, până când un test care a apelat efectiv funcția RPC a impus protecția în baza de date. Ambele probleme au fost descoperite prin scrierea unei aserțiuni, nu doar prin citirea codului.

Unde se vede: Ambele remedieri apar ca modificări separate în istoricul public FoodBoard, cu explicația deciziei în mesajul commit-ului.

Fiecare README are o secțiune Known limitations scrisă direct, deoarece tocmai acele puncte merită discutate într-o evaluare. Un flux de plată a fost prezentat ca blocat până în ziua în care a devenit activ. Fereastra de actualizare a unui demo este exprimată în ore. Orice număr de pe acest site are o dată. Viteza oferită de AI are valoare numai dacă persoana care primește produsul poate avea încredere în descrierea lui.

Unde se vede: README-ul FoodBoard explică decizia arhitecturală pe care aș schimba-o dacă aș reconstrui proiectul și motivul acestei alegeri.

Fiecare proiect destinat publicului primește o optimizare tehnică SEO și GEO adaptată arhitecturii sale. Aceasta include HTML indexabil atunci când o aplicație randată doar pe client nu este suficientă, titluri și descrieri specifice fiecărei rute, URL-uri canonice, sitemap-uri, reguli pentru roboți, date structurate și previzualizări pentru linkuri. Conținutul este organizat astfel încât motoarele de căutare și cele de răspuns să poată identifica produsul, publicul, capabilitățile și dovezile fără să ghicească dintr-un bundle JavaScript.

Unde se vede: FoodBoard prerandează câte o pagină distribuibilă pentru fiecare meniu, cu JSON-LD și sitemap. Clinica Naturell prerandează rutele serviciilor. Acest portofoliu publică metadate canonice și hreflang pentru engleză, română și rusă.