Adevărata valoare a unui profesionist al codului

01De ce să plătești pe cineva care scrie cod, dacă și o mașină scrie cod?

Este întrebarea pe care și-o pune azi oricine are de comandat un site, un portal sau un program de gestiune, și e o întrebare legitimă. Instrumentele de inteligență artificială scriu în câteva secunde pagini de cod ordonat și comentat. Page builderele promit un site profesional trăgând blocuri cu mouse-ul. Magazinele online oferă teme gata făcute la câteva zeci de euro. Totul e adevărat.

Și totuși, site-urile lente, portalurile sparte și programele de gestiune pe care nimeni nu le mai poate modifica nu s-au împuținat: s-au înmulțit. Motivul e simplu de spus și mai puțin simplu de acceptat. Scrierea codului nu a fost niciodată partea grea a meseriei. Partea grea este să decizi ce cod trebuie, să înțelegi ce există deja, să prevezi ce se va întâmpla când utilizatorii vor fi o mie în loc de zece și să răspunzi pentru ce ajunge online.

În acest capitol desfac comparația bucată cu bucată: ce face cu adevărat bine inteligența artificială, unde greșește fără să te anunțe, de ce un site asamblat cu page builder și pluginuri costă mai mult decât pare și cum recunoști o lucrare făcută ca la carte. Nu ca să apăr o categorie, ci ca să-ți dau instrumentele cu care să alegi.

02Inteligența artificială: un asistent formidabil

Să pornim de la ce trebuie spus cinstit: asistenții de programare bazați pe inteligență artificială sunt instrumente extraordinare, iar cine scrie software ca meserie îi folosește astăzi. Economisesc ore la lucrările repetitive, propun soluții la care nu te gândiseși, explică în cuvinte simple o bucată de cod scrisă de altcineva acum zece ani.

Iată unde dau cel mai mult:

• munca de rutină: structuri repetitive, conversii de format, liste de câmpuri, teste de bază;
• prima ciornă: un punct de plecare din care cine știe să programeze taie, corectează și completează;
• explicația: «ce face funcția asta?», «de ce apare eroarea asta?», întrebări la care răspunde adesea bine;
• căutarea: să găsești numele unui concept, o funcție dintr-o bibliotecă, o alternativă;
• revizia: o a doua pereche de ochi care semnalează ceva de verificat din nou.

În toate aceste cazuri există un element comun: cineva care știe să judece rezultatul. Asistentul propune; cine cunoaște meseria alege, elimină, verifică. Scoate acea persoană din ecuație și instrumentul rămâne același, dar rezultatul își schimbă natura.

03Unde greșește IA fără să spună

Un model lingvistic generează textul cel mai probabil pentru ce i-ai cerut. Nu știe dacă codul pe care îl scrie e sigur: știe că seamănă cu cod pe care l-a văzut. De aceea cea mai periculoasă greșeală a lui nu e codul care nu merge, care se observă imediat, ci codul care merge și mai face și altceva.

OWASP, fundația internațională care de douăzeci de ani publică standardele de referință pentru securitatea aplicațiilor web, enumeră printre riscurile modelelor lingvistice tocmai generarea de cod nesigur și încrederea excesivă: cine se bazează pe conținutul generat fără să-l verifice. Iată cum arată, concret.

Imaginează-ți așa: un nepot binevoitor îți pregătește într-o după-amiază, cu ajutorul inteligenței artificiale, formularul pentru rezervări. Se deschide, trimite, sosesc e-mailurile. Totul perfect, luni de zile. Apoi, într-o zi, cineva scrie în câmpul «nume de familie» ceva ce nu e un nume, iar lista clienților tăi ajunge unde nu ar trebui. Formularul mergea: mai făcea și altceva.

1. Interogarea care deschide baza de date oricui

Ceri «o pagină care caută clienții după numele de familie» și primești ceva ce merge. Dar dacă numele scris de utilizator este lipit direct în întrebarea către baza de date, oricine poate scrie în locul numelui o bucată de comandă și poate primi înapoi tot tabelul, sau îl poate șterge. Este SQL injection, unul dintre cele mai vechi atacuri și încă printre cele mai răspândite.

Prima apărare recomandată de OWASP sunt tocmai interogările parametrizate (prepared statement). Un asistent le folosește des, dar nu întotdeauna; iar cine nu știe să recunoască diferența nu observă nimic până când cineva nu profită.

2. Cheile secrete scrise în cod

Ca să te conectezi la un serviciu de plăți, la e-mail sau la baza de date ai nevoie de parole și chei. Codul generat tinde să le scrie direct în fișier, pentru că așa exemplul merge imediat. Dar un fișier ajunge într-o arhivă, într-o copie de backup, într-un depozit de cod comun: și cheia odată cu el. Ghidurile OWASP despre gestionarea secretelor spun contrariul: cheile stau în afara codului, în fișiere de configurare protejate sau în servicii dedicate, și se pot schimba fără să atingi programul.

3. Bibliotecile care nu există

Se întâmplă și asta: asistentul îți sugerează să instalezi un pachet cu un nume plauzibil care nu a existat niciodată. OWASP descrie scenariul în care cineva observă ce nume inventate sunt sugerate cel mai des, publică pachete malițioase cu acele nume și așteaptă să fie instalate. Cine nu verifică de unde vine fiecare bibliotecă aduce în casă, cu o singură comandă, cod scris de necunoscuți.

4. Cazul fericit și toate celelalte

Codul generat acoperă bine drumul prevăzut: utilizatorul completează tot, rețeaua merge, plata reușește. Software-ul adevărat trăiește în celelalte cazuri: dublul clic pe butonul «Plătește», conexiunea care cade la jumătate, două persoane care rezervă aceeași masă în aceeași secundă, câmpul lăsat gol, numele cu apostrof. Gestionarea excepțiilor e jumătate din muncă, iar asistentul nu o face dacă nu i-o ceri, și nu știi să i-o ceri dacă nu știi.

5. Contextul pe care nu i l-a dat nimeni

Asistentul nu-ți cunoaște baza de date, traficul pe care îl vei avea, regulile domeniului tău, normele privind datele personale, programul de gestiune cu care site-ul trebuie să comunice. Produce o soluție generică pentru o problemă care generică nu e. Cine cunoaște proiectul știe ce să ceară, ce să elimine și ce lipsește.

04Page builder și pluginuri: site-ul care cântărește mai mult decât arată

Un page builder este un program care îți permite să construiești paginile trăgând blocuri: titluri, coloane, galerii, butoane. E comod și dă rezultate imediate. Prețul se plătește mai târziu, și îl plătește cine vizitează site-ul.

Greutatea ascunsă a fiecărui bloc

Ca să-ți permită să tragi orice oriunde, page builderul trebuie să prevadă totul. Fiecare element e învelit în mai multe containere, fiecare cu clasele și stilurile lui. Rezultatul este o pagină cu un număr enorm de elemente HTML (așa-numitul DOM) și foi de stil și scripturi mari, încărcate integral chiar și când pagina folosește doar o mică parte din ele.

Lighthouse, instrumentul de analiză Google integrat în Chrome, dă un avertisment când corpul paginii depășește circa 800 de elemente și o eroare peste circa 1.400. Mai multe elemente înseamnă mai multă memorie, mai multe calcule de stil și de așezare în pagină, răspunsuri mai lente la atingeri: tot ce trebuie să facă browserul înainte să-ți arate pagina și cât timp o folosești.

Codul care se încarcă și nu se folosește

Pe lângă elemente, contează și greutatea fișierelor. Un page builder își încarcă foile de stil și scripturile pentru toate blocurile pe care le oferă, chiar și pentru cele pe care pagina nu le folosește: sliderul care nu există, caruselul, animația. Chrome însuși, în analizele lui, indică CSS-ul și JavaScriptul nefolosite ca printre primele lucruri de eliminat pentru a accelera o pagină. Fișiere mai multe și mai mari înseamnă mai multă așteptare până când pagina devine lizibilă, mai ales pe un telefon cu o conexiune obișnuită. Cum se măsoară aceste așteptări explic în capitolul despre Core Web Vitals.

Pluginul pentru orice

A doua problemă vine cu pluginurile: unul pentru formularul de contact, unul pentru cache, unul pentru securitate, unul pentru SEO, unul pentru cookie, unul pentru galerie, unul pentru traduceri. Douăzeci, treizeci, uneori mai multe. Fiecare este:

• cod scris de alții, care rulează pe serverul tău cu aceleași permisiuni ca site-ul;
• încă un lucru de actualizat, adesea cu un abonament anual pentru versiunile comerciale;
• o posibilă incompatibilitate cu celelalte, care apare în ziua în care unul se actualizează și altul nu;
• o ușă în plus: orice vulnerabilitate descoperită într-un plugin răspândit privește toate site-urile care îl folosesc, până când sunt actualizate.

Cifrele o confirmă. Potrivit raportului anual Patchstack, firmă specializată în securitatea WordPress, în 2025 au fost descoperite 11.334 de vulnerabilități noi în ecosistemul WordPress: 91% în pluginuri, 9% în teme și doar 6 în core, toate de gravitate scăzută. Nucleul sistemului, îngrijit de o comunitate foarte mare, este solid; riscul stă în ce i se adaugă. Fiecare plugin instalat «pentru că e comod» e un pariu pe seriozitatea celui care îl întreține.

05WordPress făcut bine: core-ul nu se atinge

WordPress nu este problema. Este un sistem solid, folosit de o parte enormă a webului, cu o comunitate care îl actualizează cu regularitate. Problema este cum e folosit. Și aici există o regulă care desparte profesionistul de amator mai mult decât oricare alta.

Core-ul WordPress, adică fișierele sistemului, nu se modifică niciodată. Documentația oficială o spune explicit: nu e recomandat să modifici fișierele core, cu excepția fișierului de configurare. Motivul e practic: la fiecare actualizare fișierele sistemului sunt înlocuite, iar orice modificare făcută acolo dispare sau, mai rău, te împiedică să actualizezi și lasă site-ul expus breșelor pe care actualizarea le-ar fi închis.

Unde lucrează atunci un profesionist

WordPress este proiectat să fie extins fără să fie atins, în straturi:

• Tema copil moștenește totul de la tema principală și conține doar diferențele. Documentația WordPress o spune clar: îți permite să actualizezi tema părinte fără să pierzi modificările.
• Pluginurile la comandă conțin funcțiile specifice afacerii, scrise pentru acel proiect, fără miile de opțiuni ale unui produs comercial gândit pentru toată lumea.
• Hookurile (acțiuni și filtre) sunt punctele de agățare prevăzute de sistem: îți permit să schimbi un comportament fără să rescrii fișierul care îl conține.

Așa site-ul se actualizează cu un clic, rămâne sigur, iar personalizările rămân. Cine îți propune să «aranjeze direct în core» îți propune, fără să ți-o spună, un site care nu va mai putea fi actualizat.

Când WordPress e alegerea potrivită, și când nu

WordPress e foarte bun când trebuie să publici conținut des, cu mai multe persoane care scriu, iar funcțiile sunt cele tipice unui site editorial. Devine o forțare când e folosit ca bază pentru un program de gestiune, un sistem de rezervări complex sau un portal cu logică proprie: acolo ajungi să lupți cu instrumentul, adăugând plugin peste plugin. În aceste cazuri, o aplicație scrisă la comandă costă mai puțin în timp.

06Ce cumperi cu adevărat cu un cod curat

«Cod curat» pare o expresie pentru oamenii din meserie. În realitate înseamnă trei avantaje foarte concrete pentru cine deține site-ul sau software-ul: securitate, capacitatea de a crește și vizibilitate pe Google.

Securitate: mai puțin cod, mai puține breșe

Fiecare rând de cod este un loc unde se poate ascunde o greșeală. Un proiect esențial, care conține doar ce trebuie, are mai puține puncte slabe decât unul umflat cu componente generice. Un cod ordonat este și un cod care poate fi verificat: dacă nimeni nu reușește să-l citească, nimeni nu poate spune dacă e sigur.

Creștere: adaugi fără să rescrii

O afacere se schimbă: un serviciu nou, un al doilea sediu, încă o limbă, o legătură cu programul de gestiune sau cu contabilul. Cu un software proiectat bine, a adăuga un lucru nu te obligă să rescrii altul: există un punct prevăzut unde să-l prinzi. Cu un software crescut din straturi de petice, fiecare modificare strică alta, iar la un moment dat merită să o iei de la zero. Acolo economia de la început se transformă în costul cel mai mare.

SEO tehnic: să te citească bine Google

Google citește codul paginii înainte să-ți citească textele. Un cod curat îl ajută să înțeleagă:

• structura: un singur titlu principal, titluri de secțiune în ordine, liste adevărate în loc de rânduri formatate de mână;
• sensul: date structurate care spun «acesta e un articol», «acestea sunt întrebări frecvente», «aceasta e adresa afacerii»;
• viteza: pagini ușoare care răspund repede, pe server și în browser (vorbesc despre asta în capitolul despre infrastructură și în cel despre viteză);
• limbile: paginile traduse declarate corect, ca cine caută în altă limbă să găsească pagina potrivită. Vorbesc despre asta în capitolul despre site-ul multilingv.

07Costul real: socoteala pe trei ani

Comparația dintre un profesionist și «fă-ți singur» se face aproape mereu pe prețul inițial. E comparația greșită. Costul unui site sau al unui software se măsoară pe anii în care îl folosești, adunând lucruri care la început nu se văd.

08Cum recunoști un profesionist al codului

Nu trebuie să știi să programezi ca să înțelegi dacă cel din fața ta lucrează bine. Ajung câteva întrebări și atenția la răspunsuri: un profesionist răspunde concret, recunoaște limitele instrumentelor și vorbește despre problema ta înainte de tehnologia lui preferată.

1. «Ce se întâmplă când va trebui să adaug o funcție?» Răspunsul bun arată unde se va prinde, fără să rescrie restul.
2. «Cum protejezi datele clienților mei?» Trebuie să auzi cuvinte precise: conexiune criptată, interogări parametrizate, parole niciodată salvate în clar, backupuri în afara serverului.
3. «Câte componente de la terți vei folosi și cine le actualizează?» Mai bine puține, alese și cu un responsabil.
4. «Ale cui sunt codul și domeniul?» Ale tale, scris negru pe alb.
5. «Folosești inteligența artificială?» Nu e nimic rău dacă răspunsul e da: contează să spună cine verifică ce produce.
6. «Îmi arăți o lucrare și cum e făcută pe dinăuntru?» Cine lucrează bine nu se teme să arate codul.

Valoarea unui cod scris la comandă se vede mai ales când site-ul trebuie să facă mai mult decât să arate pagini: când trebuie să primească rezervări, să-i lase pe clienți să intre în zona lor, să se sincronizeze cu un program de gestiune, să meargă și pe telefon ca o aplicație. Acolo un cod la comandă permite integrarea în siguranță a unui portal de rezervări și a unui PWA, fără să te sprijini pe un teanc de pluginuri care își dispută aceleași date. Este subiectul capitolului următor: portaluri integrate, rezervări directe și PWA.

Întrebări frecvente

Surse

1. OWASP GenAI Security Project, «LLM09:2025 Misinformation»: generarea de cod nesigur, biblioteci inexistente sugerate de modele, încrederea excesivă.
2. OWASP, «SQL Injection Prevention Cheat Sheet»: interogările parametrizate ca primă apărare.
3. OWASP, «Secrets Management Cheat Sheet»: de ce cheile și parolele nu stau în cod.
4. Chrome for Developers, «Avoid an excessive DOM size»: pragurile de circa 800 și 1.400 de elemente folosite de Lighthouse.
5. Chrome for Developers, «Remove unused CSS»: costul foilor de stil încărcate și nefolosite.
6. Patchstack, «State of WordPress Security in 2026»: vulnerabilitățile descoperite în 2025, împărțite între pluginuri, teme și core.
7. WordPress Developer Resources, «Child Themes»: actualizarea temei părinte fără pierderea modificărilor.
8. WordPress Developer Resources, «Editing Files»: nu e recomandată modificarea fișierelor core în afară de wp-config.php.

Capitol actualizat în octombrie 2026. Exemplele de cod și de structură din planșe sunt simplificate ca să arate principiul; pragurile și recomandările citate provin din documentația oficială indicată.