Site-uri generate de AI: ce primești de fapt.

Uneltele prompt-to-app produc acum în minute ceva care arată ca un site terminat, iar să le desconsideri ar fi o prostie — folosim intens AI noi înșine, inclusiv pe acest site. Ce merită atenție e distanța dintre „pare terminat” și „e sigur să-ți pui afacerea pe el”, pentru că cercetarea independentă de securitate publicată în 2025 și 2026 a măsurat acum acea distanță, în loc să o dezbată.

Ce a măsurat cercetarea

Veracode a testat peste 100 de modele de limbaj pe Java, JavaScript, Python și C#; Java a eșuat peste 70%. Cifrele Apiiro, USENIX și Snyk sunt așa cum au fost compilate în nota de research a Cloud Security Alliance de la Surse. Compară ultimul rând cu primul: diferența de încredere e probabil rezultatul care contează cel mai mult.

La ce sunt cu adevărat bune aceste unelte

Pentru validarea unei idei înainte să cheltui bani reali sunt excelente și le recomandăm. Un prototip pe care poți da click și care dovedește că oamenii vor lucrul respectiv, o unealtă internă folosită de trei colegi, o pagină de campanie care se termină în șase săptămâni — profilul de risc e mic și viteza e imbatabilă. Nimeni nu ar trebui să plătească o agenție ca să afle dacă o idee are picioare.

Sunt și o primă versiune legitimă pe proiecte reale. Un schelet de componentă generat, pe care un developer apoi îl citește, îl restructurează și îl testează, e mai rapid decât pornirea de la un fișier gol. Distincția nu e AI versus om, e revizuit versus nerevizuit.

Cum arată de obicei codul dedesubt

Apar repetat două pattern-uri. Primul, insecuritatea plauzibilă: codul rulează, funcționalitatea merge, iar input-ul nu e validat niciodată. Eșecurile de cross-site scripting și injection domină rezultatele Veracode fiindcă versiunea vulnerabilă și cea sigură arată la fel de rezonabil pentru cineva care nu poate citi diferența — iar unealta îți va spune încrezătoare că e gata.

Al doilea, autorizare care nu a fost niciodată implementată real. Controlul accesului e lucrul pe care construcțiile prin prompt îl sar cel mai des, pentru că nu se sparge nimic vizibil când lipsește: aplicația funcționează perfect pentru cel care o testează, iar baza de date va da orice înregistrare oricui întreabă. Acel eșec e invizibil într-un demo și total în producție.

Costurile care sosesc mai târziu

Dependențele halucinate sunt cea subestimată. Cam o cincime din mostrele generate importă pachete care nu există, și fiindcă numele inventate se repetă predictibil, atacatorii le înregistrează — deci un build care funcționa în aprilie poate trage cod ostil în iulie fără să se schimbe o linie. Credențialele hardcodate sunt celălalt lucru găsit constant, comise direct în repository pentru că modelul avea nevoie să pună ceva acolo.

Apoi e factura structurală. Un codebase asamblat prin prompt-uri repetate până dispare eroarea acumulează logică duplicată și nicio arhitectură coerentă, ceea ce face fiecare modificare următoare mai scumpă decât cea de dinainte. Acolo se blochează proiectele: nu la lansare, ci la a treia cerere de funcționalitate.

Cum folosim noi AI pe lucrul pe care vrem să-l păstrăm

Scrie primele versiuni, generează boilerplate, sugerează cazuri de test și accelerează refactorizarea, iar fiecare linie e citită de cineva care ar fi putut-o scrie. Input-urile sunt validate deliberat, autorizarea e proiectată și nu generată, dependențele sunt verificate în registrul real, iar secretele stau în configurația de environment și niciodată într-un commit. Nimic din asta nu e practică exotică — e practica pe care output-ul asistat de AI o are cel mai des lipsă, și e exact ce descrie cifra de 45%.

Formularea incomodă e că AI ridică plafonul cât cod livrează un inginer bun și ridică pragul de cât rău face un proces nerevizuit. Elimină tastarea, nu judecata.

Ce să întrebi înainte să cumperi un site construit cu AI

Cinci întrebări te duc aproape până la capăt. Deții și poți exporta codul sursă, sau rulează doar pe platforma furnizorului? A revizuit un om părțile relevante pentru securitate, mai exact tratarea input-ului și controlul accesului? Există autentificare pe orice atinge date de client, aplicată în baza de date și nu doar ascunsă în interfață? Sunt dependențele reale, actuale și patch-uibile? Și cine repară la ora 9 dimineața când se strică?

Dacă răspunsul la oricare e neclar, site-ul e un prototip, indiferent cât de terminat arată. Poate fi exact ce ai nevoie — doar prețuiește-l și planifică-l ca prototip, și pune-l la verificat înainte să țină ceva ce te-ar jena să se scurgă.

Surse

Cifrele de mai sus vin din aceste studii publicate, verificate în iulie 2026.

• Veracode — 2025 GenAI Code Security Report ↗

  Peste 100 de LLM-uri testate pe Java, JavaScript, Python și C#: 45% din mostrele generate au introdus o vulnerabilitate OWASP Top 10, de 2,74x rata echivalentelor scrise de oameni, cu rate de eșec de 86% și 88% pe XSS și log injection. Modelele mai mari nu au performat semnificativ mai bine.

• Cloud Security Alliance — Vibe Coding's Security Debt: The AI-Generated CVE Surge ↗

  Notă de research care compilează datele Apiiro pe commit-uri și probleme (+322% escaladare de privilegii, +153% defecte arhitecturale), rezultatul USENIX Security 2025 pe pachete halucinate (~20%, cu 43% din numele inventate reproduse consistent), sondajul Snyk pe încrederea developerilor și urmărirea CVE-urilor de la Georgia Tech.