Ce greșeli fac dezvoltatorii când codifică cu asistenți AI?

Asistenți AI ca Copilot, Claude și modelele încorporate ale Cursor au schimbat viteza cu care se scrie codul. Nu au schimbat cât de atent trebuie să fie revizuit. Cea mai mare parte a daunelor pe care le-am văzut din codarea asistate de AI provine din o mână de obiceiuri repetabile, nu din modelele în sine.

Acceptarea sugestiilor fără a le citi

Cea mai mare problemă este acceptarea prin tab a unei completări pentru că arată plauzibilă și se compilează. Plauzibil nu înseamnă corect. Am văzut o interogare SQL sugerată care tăcea o clauză WHERE în timpul unei refactorizări, iar persoana a acceptat-o pentru că numele variabilelor se potriveau. Dacă nu citești fiecare linie pe care ți-o oferă un asistent cu aceeași viteză la care ai citi un pull request al unui coleg, vei livra ceva pe care nu-l înțelegi. Tratează fiecare sugestie ca pe un prim draft de la un dezvoltator junior care este rapid dar nu are memorie a convențiilor bazei tale de cod.

Încrederea în el cu codul sensibil la securitate

Asistenții AI sunt antrenați pe cantități uriașe de cod public, și o mare parte din acel cod are probleme de securitate înglobate. Cere rapid un handler de încărcare fișier și vei obține adesea ceva fără verificare de extensie, fără limită de dimensiune și o cale construită prin concatenare de șiruri în loc de os.path.join sau un apel de bibliotecă sigur. Aceeași poveste cu autentificare: asistenții adoră să sugereze stocarea JWT-urilor în localStorage, sau compararea secretelor cu == în loc de o comparație în timp constant. Nimic din asta nu este malițios, e doar statistic comun în datele de antrenament. Pentru orice lucru care atinge autentificarea, I/O fișier, deserializare sau SQL, scrie logica singur sau rulează ieșirea AI-ului prin aceleași întrebări de modelare a amenințărilor pe care le-ai pune oricărui cod nou: ce se întâmplă cu intrare ostilă, ce se întâmplă dacă acest apel eșuează, cine altcineva poate ajunge la acest endpoint.

Lăsând-o să inventeze dependențe și API-uri

Modelele alucinează nume de pachete și semnături de funcții cu încredere totală. Aceasta este problema "slopsquatting" — atacatorii înregistrează numele de pachete false pe care modelele le sugerează frecvent, deci o pip install sau npm install neverificată poate descărca ceva care nu este deloc biblioteca ta de logging. Înainte de a adăuga orice dependență pe care un asistent o recomandă, verifică că aceasta există cu adevărat pe PyPI sau npm, verifică numărul de descărcări și data ultimei publicări, și examinează sursa dacă este destul de mică. Aceeași precauție se aplică apelurilor API: dacă asistentul face referire la o metodă pe care nu o recunoști, verifică documentele actuale înainte de a presupune că există.

Pierderea modelului mental al codului tău propriu

Când scrii cod singur, construiești o hartă mentală a motivului pentru care există fiecare piesă. Când accepți blocuri mari de cod generat de AI pe parcursul unei sesiuni, acea hartă devine subțire rapid. Apoi un bug apare trei săptămâni mai târziu și debugezi cod pe care nu l-ai scris niciodată și nu-l amintești pe deplin. Remedia nu este să eviți codul generat de AI, ci să încetinești suficient pentru a explica fiecare chunk ție însuți, sau unui coleg, înainte de a-l fuziona. Dacă nu poți explica ce face o funcție și de ce o face în felul acela, nu o fuziona încă.

Omiterea testelor pentru că codul