Cum folosești un asistent AI ca să scrii cod mai repede (fără să te faci de râs)

AI-ul a schimbat destul de mult felul în care scriem software. Astăzi poți descrie o funcție în câteva propoziții și să primești cod funcțional în câteva secunde. Poți trimite un stack trace și să primești posibile cauze. Poți cere unui asistent să explice un controller, să scrie un test sau să refactorizeze o bucată de cod.

Problema apare atunci când viteza începe să fie confundată cu competența.

Un developer care acceptă orice cod generat de AI fără să îl înțeleagă poate ajunge foarte repede cu un proiect care „merge”, dar pe care nimeni nu mai știe să îl întrețină.

În schimb, folosit corect, un asistent AI poate elimina foarte mult din munca repetitivă și îți poate permite să te concentrezi mai mult pe arhitectură, logică și produs.

Diferența nu este dacă folosești AI sau nu. Diferența este cum îl folosești.

Pe scurt

• Nu cere AI-ului să construiască tot proiectul dintr-un singur prompt.
• Dă-i context real despre proiect, framework și convențiile existente.
• Folosește-l foarte bine pentru debugging, explicații și refactorizare.
• Lasă AI-ul să scrie cod repetitiv, dar verifică întotdeauna rezultatul.
• Nu accepta biblioteci, API-uri sau metode pe care nu le-ai verificat.
• Rulează teste, linting și verificări de securitate după modificări.
• Folosește AI-ul ca un coleg tehnic foarte rapid, nu ca pe un programator căruia îi dai parola de la producție.

1. Nu începe cu „fă-mi aplicația”

Probabil unul dintre cele mai proaste moduri de a folosi un coding assistant este să îi dai o cerință enormă și să aștepți să construiască singur tot proiectul.

De exemplu:

„Fă-mi un marketplace în Laravel cu autentificare, plăți, produse, comenzi, administrare și notificări.”

Tehnic, AI-ul poate genera foarte mult cod pornind de aici. Problema este că nu știe suficiente lucruri despre proiectul tău.

Nu știe exact arhitectura pe care o vrei, ce pachete folosești, cum sunt organizate modelele, ce reguli de business există sau ce părți ale aplicației sunt deja implementate.

Rezultatul poate arăta impresionant într-o demonstrație, dar poate fi foarte greu de integrat într-un proiect real.

O abordare mai bună este să împarți problema:

• analiza structurii existente;
• definirea arhitecturii pentru funcționalitatea nouă;
• implementarea unei prime componente;
• scrierea testelor;
• verificarea rezultatului;
• implementarea următoarei componente.

GitHub recomandă exact această abordare de lucru cu AI: contextul proiectului și obiectivul schimbării trebuie înțelese înainte de a accepta codul generat.

2. Dă-i contextul proiectului

Un coding assistant este mult mai util atunci când știe în ce proiect lucrează.

Nu este suficient să îi spui:

„Scrie un controller Laravel pentru produse.”

Poți să îi spui:

„Proiectul este Laravel 11, PHP 8.3, folosește PostgreSQL și Filament pentru admin. Produsele au deja modelul Product și relațiile existente trebuie păstrate. Nu introduce un repository pattern nou. Respectă structura controllerelor existente și folosește Form Requests pentru validare.”

Acum AI-ul are niște limite reale în care trebuie să lucreze.

Cu cât contextul este mai relevant, cu atât rezultatul este mai bun

Nu înseamnă însă că trebuie să îi trimiți întregul repository la fiecare întrebare.

Dacă repari un bug într-un serviciu Laravel, cele mai utile informații pot fi:

• fișierul afectat;
• modelul relevant;
• eroarea exactă;
• request-ul care produce problema;
• relațiile importante;
• ce comportament ar trebui să existe.

Contextul inutil poate face conversația mai greu de urmărit. GitHub recomandă selectarea informațiilor relevante și păstrarea contextului actualizat, nu încărcarea asistentului cu informații fără legătură.

3. Folosește AI-ul pentru debugging

Aici un asistent AI poate deveni extrem de util.

În loc să copiezi doar:

„Nu merge.”

trimite eroarea completă și contextul în care apare.

De exemplu:

„În Laravel 11 primesc această eroare când trimit formularul de checkout. Funcționează pentru utilizatorii autentificați, dar apare doar pentru guest checkout. Acesta este stack trace-ul. Analizează cauza probabilă, indică fișierul care trebuie verificat și propune cea mai mică modificare necesară.”

Această ultimă parte este importantă: „cea mai mică modificare necesară”.

Altfel, AI-ul poate transforma o eroare de trei rânduri într-un refactor de 15 fișiere.

Un workflow bun pentru debugging

1. Descrii comportamentul așteptat.
2. Descrii comportamentul actual.
3. Trimiți eroarea exactă.
4. Arăți codul relevant.
5. Ceri mai întâi analiza cauzei.
6. Abia apoi ceri modificarea.
7. Rulezi testul care reproduce problema.

AI-ul poate fi foarte bun la identificarea unor ipoteze, dar faptul că a oferit o explicație convingătoare nu înseamnă că explicația este automat corectă.

4. Cere-i să explice codul înainte să îl modifici

O altă utilizare foarte bună este să folosești AI-ul ca instrument de înțelegere.

Dacă ai un serviciu vechi de 500 de linii și nu înțelegi exact de ce există, nu trebuie să îi spui imediat:

„Refactorizează-l.”

Mai întâi:

„Explică-mi ce face această clasă. Identifică responsabilitățile ei, dependențele, punctele în care se fac query-uri și locurile în care există logică de business. Nu modifica nimic.”

Apoi poți continua:

„Acum identifică problemele de maintainability și propune trei variante de refactorizare, fără să scrii încă implementarea.”

Abia după ce alegi direcția:

„Implementează varianta 2 fără să schimbi comportamentul existent.”

Această abordare te ajută să rămâi tu cel care ia decizia tehnică.

5. Lasă AI-ul să scrie cod repetitiv

Nu are foarte mult sens să pierzi timp scriind manual sute de linii de cod repetitiv dacă un asistent le poate genera rapid.

De exemplu:

• CRUD-uri;
• validări repetitive;
• DTO-uri;
• teste de bază;
• tipuri TypeScript;
• documentație;
• transformări de date;
• query-uri simple;
• componente UI repetitive;
• migrări și seedere;
• cod boilerplate.

Aici câștigul de timp poate fi foarte mare.

Dar faptul că AI-ul a generat codul în cinci secunde nu înseamnă că acel cod nu trebuie verificat.

GitHub recomandă explicit verificarea codului generat prin teste și analiză statică și atrage atenția asupra unor probleme precum API-uri inexistente, logică incorectă, dependențe suspecte și constrângeri ignorate.

6. Nu accepta automat orice bibliotecă recomandată de AI

Aici mulți developeri se pot trezi cu probleme.

Îi ceri AI-ului:

„Am nevoie de o librărie Laravel pentru X.”

AI-ul îți recomandă un pachet care pare perfect.

Îl instalezi.

Două săptămâni mai târziu descoperi că proiectul nu mai este întreținut.

Sau că API-ul recomandat nu există în versiunea actuală.

Sau că pachetul are o licență nepotrivită pentru proiectul tău.

GitHub avertizează explicit asupra dependențelor sugerate de AI și recomandă verificarea existenței, mentenanței, reputației și licenței acestora.

Înainte să instalezi un pachet, verifică:

• repository-ul oficial;
• ultima versiune;
• compatibilitatea cu framework-ul tău;
• numărul și frecvența actualizărilor;
• issues și pull requests;
• licența;
• documentația;
• dependențele proprii.

7. Cere teste, nu doar implementarea

Un prompt precum:

„Implementează funcția.”

este incomplet pentru un proiect serios.

O variantă mai bună:

„Implementează funcția și scrie teste pentru comportamentul normal, input invalid, utilizator neautorizat și cazul în care resursa nu există.”

Acum AI-ul nu mai este folosit doar pentru a produce cod, ci și pentru a verifica ipotezele din jurul acelui cod.

Poți chiar să continui cu:

„Acum încearcă să găsești cazuri limită pe care testele actuale nu le acoperă.”

Acesta este un mod mult mai sănătos de a folosi un coding assistant.

8. Folosește AI-ul și pentru code review

După ce ai terminat o funcționalitate, poți să îi dai diff-ul și să îi ceri să îl trateze ca pe un review.

De exemplu:

„Fă un code review pentru această modificare. Nu rescrie codul încă. Identifică problemele de securitate, logică, performanță, maintainability și compatibilitate cu arhitectura existentă. Pentru fiecare problemă indică severitatea și explică de ce este o problemă.”

Este important să separi review-ul de implementare. Dacă îi spui simultan „găsește problemele și repară tot”, riști să nu mai vezi clar ce a identificat și ce a schimbat.

GitHub recomandă exact acest tip de verificare: code review-ul AI poate ajuta la identificarea problemelor, dar feedback-ul trebuie validat de developer și nu trebuie tratat ca o garanție că toate problemele au fost găsite.

9. Nu lăsa AI-ul să șteargă testul doar pentru că testul eșuează

Acesta este unul dintre cele mai periculoase obiceiuri.

AI-ul modifică ceva, testul începe să eșueze și apare tentația:

„Fă testele să treacă.”

Un model prea agresiv poate ajunge să schimbe testul, să îl dezactiveze sau să modifice comportamentul așteptat.

Promptul corect este mai degrabă:

„Testul a început să eșueze după această modificare. Nu modifica și nu șterge testul. Identifică de ce a apărut regresia și propune o soluție care păstrează comportamentul așteptat.”

GitHub indică explicit ștergerea sau dezactivarea testelor în locul reparării problemei drept unul dintre lucrurile la care trebuie să fii atent când verifici cod generat de AI.

10. Creează instrucțiuni permanente pentru proiect

Dacă folosești frecvent AI într-un proiect, nu are sens să repeți la fiecare conversație aceleași reguli.

Poți documenta lucruri precum:

• versiunea framework-ului;
• structura proiectului;
• convențiile de naming;
• standardele de cod;
• regulile de securitate;
• comenzile pentru teste;
• ce pachete sunt aprobate;
• ce zone nu trebuie modificate;
• cum este organizată arhitectura.

GitHub suportă în prezent instrucțiuni de repository și fișiere precum AGENTS.md, CLAUDE.md și GEMINI.md pentru a oferi asistenților AI context și reguli specifice proiectului.

Este una dintre cele mai bune metode de a transforma un coding assistant dintr-un chatbot generic într-un instrument adaptat proiectului tău.

11. AI-ul nu trebuie să decidă singur arhitectura

Aici este probabil cea mai importantă diferență dintre un developer experimentat și cineva care doar copiază cod generat.

AI-ul poate propune:

• un design pattern;
• o structură de directoare;
• o strategie de caching;
• o soluție pentru autentificare;
• o metodă de optimizare;
• o bibliotecă;
• o arhitectură pentru un feature.

Dar propunerea trebuie evaluată.

Nu există nicio regulă conform căreia cea mai lungă sau cea mai sofisticată soluție este și cea mai bună.

Dacă pentru o problemă simplă AI-ul îți propune șapte servicii, trei repository-uri, un event bus și două abstracții suplimentare, este perfect legitim să întrebi:

„Care este cea mai simplă soluție care respectă arhitectura actuală?”

Uneori răspunsul corect este chiar mai puțin cod.

12. Un workflow AI bun pentru un developer

Un workflow practic poate arăta astfel:

Acest model te ține în control și reduce riscul ca AI-ul să construiască rapid ceva ce apoi trebuie să repari și mai rapid.

Un prompt bun pentru coding assistant

Dacă vrei un punct de plecare reutilizabil, poți folosi ceva de genul:

„Lucrează în proiectul existent și respectă arhitectura și convențiile deja folosite. Înainte să modifici codul, analizează fișierele relevante și explică pe scurt ce ai înțeles. Implementează doar funcționalitatea cerută, fără refactorizări inutile. Nu introduce dependențe noi fără să explici motivul. Păstrează comportamentul existent în afara zonei afectate. După implementare, adaugă sau actualizează testele relevante și verifică eventualele probleme de securitate, validare și edge cases. Dacă există mai multe soluții, alege varianta simplă și compatibilă cu arhitectura actuală.”

Observă că promptul nu îi spune AI-ului fiecare linie pe care trebuie să o scrie. Îi definește modul de lucru.

Ce înseamnă, de fapt, să fii bun la programare cu AI

Înainte de AI, un developer care nu înțelegea codul putea copia un snippet de pe internet.

Astăzi poate genera sute de linii cu un singur prompt.

Asta nu schimbă problema fundamentală.

Trebuie în continuare să știi dacă soluția este corectă.

De fapt, într-un anumit sens, AI-ul face această abilitate și mai importantă. Dacă poți genera cod foarte repede, dar nu îl poți evalua, viteza nu te ajută prea mult.

Un developer bun cu AI nu este cel care scrie cele mai multe linii pe minut.

Este cel care știe ce să ceară, ce să accepte, ce să verifice și ce să refuze.

Concluzie

Un asistent AI poate reduce enorm timpul petrecut pe programare, mai ales la cod repetitiv, debugging, documentație, teste și explorarea unor soluții.

Dar cel mai bun workflow nu este:

„AI scrie → eu copiez → deploy.”

Este:

„Eu definesc problema → AI analizează → AI propune → eu decid → AI implementează → testăm → verificăm → abia apoi livrăm.”

Diferența pare mică, dar este enormă în proiectele reale.

Folosește AI-ul pentru a elimina munca repetitivă, pentru a accelera investigațiile și pentru a avea un al doilea punct de vedere tehnic. Dar păstrează la tine deciziile importante: arhitectura, securitatea, business logic-ul și responsabilitatea pentru codul care ajunge în producție.

În felul acesta, AI-ul nu te face un developer mai slab. Te poate face un developer mult mai rapid.

Întrebări frecvente

Poate AI-ul să scrie singur o aplicație completă?

Poate genera o cantitate foarte mare de cod și poate lucra pe task-uri complexe, dar asta nu înseamnă că rezultatul trebuie acceptat fără review. Pentru aplicații reale, arhitectura, securitatea, testarea și business logic-ul trebuie verificate.

Este ChatGPT bun pentru programare?

Da. Poate fi folosit pentru generare de cod, debugging, explicații, refactorizare, teste și analiză. Rezultatul depinde foarte mult de contextul pe care îl primește și de modul în care este verificat codul.

Este Claude mai bun decât ChatGPT pentru programare?

Nu există un câștigător universal. Modelele și produsele se schimbă rapid, iar rezultatul depinde de limbaj, proiect, context și workflow. Cel mai util este să compari modelele pe task-urile reale pe care le faci.

Ar trebui să verific codul generat de AI?

Da. Codul generat trebuie tratat ca orice alt cod primit de la un contributor: verifică funcționalitatea, testele, securitatea, dependențele, performanța și compatibilitatea cu arhitectura proiectului.

Pot folosi AI pentru un proiect Laravel existent?

Da, iar proiectele existente pot beneficia foarte mult de AI dacă îi oferi contextul corect. Este important să îi explici versiunea Laravel, structura proiectului, convențiile existente și zonele care nu trebuie modificate.

Care este cea mai mare greșeală când programezi cu AI?

Să accepți codul doar pentru că „arată bine” și compilarea sau testele trec. Codul trebuie să rezolve problema corectă, să respecte arhitectura proiectului și să nu introducă probleme de securitate sau mentenanță.