Acum câțiva ani răspunsul la întrebarea "cine a scris acest cod?" era relativ simplu. Putiai indica un programator, o echipă sau un software house responsabil pentru un modul concret.
Astăzi situația arată complet diferit.
O parte din cod poate fi scrisă manual. O parte poate fi generată de Copilot. Un alt fragment poate fi creat de un agent programator. Altul va fi descărcat dintr-o bibliotecă open source. Mai sunt dependențe din pachete externe. La toate acestea se adaugă API-uri, servicii cloud, componente gata făcute, framework-uri și unelte furnizate de diverse companii.
Sistemul funcționează. Dar știi cu adevărat din ce a fost construit?
Codul generat de AI nu apare într-un vid
Dezvoltarea uneltelor AI pentru programare schimbă nu doar modul în care se scrie software. Schimbă și structura responsabilităților pentru cod.
Un programator poate azi descrie o sarcină unui agent și apoi primi o funcție gata făcută, un modul, teste, configurație sau chiar propuneri de modificări arhitecturale. Este o accelerare enormă a muncii.
Problema începe când tratăm codul generat ca pe "cod dispărut".
AI nu creează cod izolat față de întregul ecosistem de dezvoltare. Modelele sunt antrenate pe seturi vaste de date, iar fragmentul generat poate semăna cu soluții existente, tipare sau cod public disponibil. Tocmai de aceea problema originii codului, a licențelor și a responsabilității devine tot mai importantă.
Asta nu înseamnă automat că fiecare fragment generat de AI încalcă o licență. Înseamnă însă că organizația care folosește AI în procesul de dezvoltare ar trebui să trateze proveniența și verificarea codului ca pe un element al procesului de inginerie, nu ca pe o curiozitate juridică.
Asta nu mai e doar teorie
16 septembrie 2026. Curtea de Apel a celui de-al 9-lea Circuit a decis parțial în cauza Doe v. GitHub, în care programatori au acuzat GitHub, Microsoft și entități OpenAI, printre altele, de folosirea codului public de pe GitHub pentru crearea și antrenarea uneltelor precum Copilot și Codex.
Una dintre revendicări privea DMCA și informațiile despre drepturile de autor. Instanța a susținut respingerea acelui capăt de acuzare. În același timp, cazul include și alte chestiuni legate de drepturi de autor și licențe open source.
Este important nu pentru că o hotărâre oferă un răspuns simplu la întrebarea "se poate folosi codul de la AI".
Nu oferă.
Mai important e că disputa arată o problemă mai largă: în lumea AI limita dintre cod scris de om, cod generat de model și cod provenit din ecosisteme software existente devine tot mai greu de urmărit.
Iar pentru companiile care construiesc software asta înseamnă necesitatea unei gestionări mai bune a procesului.
Software supply chain: sistemul tău are mult mai mulți "autori"
În securitatea software există de ani conceptul de software supply chain – lanțul de livrare al software-ului.
Sunt toate componentele, uneltele, bibliotecile, dependențele și procesele care contribuie la produsul final.
NIST subliniază aici, printre altele, necesitatea gestionării provenienței componentelor, controlul dependențelor open source, monitorizarea vulnerabilităților și utilizarea SBOM, adică Software Bill of Materials.
SBOM poate fi, pe scurt, comparat cu lista de ingrediente a unui produs.
Nu spune doar „avem o aplicație”. Arată ce componente se află în interior.
De exemplu:
- framework-ul aplicației,
- biblioteci externe,
- versiunile pachetelor individuale,
- componente open source,
- dependențe indirecte,
- elemente furnizate de furnizori externi.
Astfel, când apare o vulnerabilitate într-o bibliotecă concretă, poți verifica mai rapid ce sisteme o folosesc.
NIST atrage atenția și asupra provenienței, adică posibilitatea de a urmări originea elementelor software.
Și aici AI adaugă un nou nivel de complexitate.
Pentru că în lanțul existent apare un alt mod de a genera cod.
Imaginează-ți un sistem tipic de business
40% din cod a fost scris de echipă.
20% a fost creat cu ajutorul AI.
Alte fragmente au fost generate de un agent.
Câteva biblioteci provin din open source.
O parte din dependențe au venit din framework.
Sistemul folosește API-uri ale unui furnizor extern.
Un component provine dintr-un pachet care nu a fost actualizat de doi ani.
I documentația dependențelor?
Este undeva în repository.
Sau nu există.
Sistemul funcționează...
Și tocmai de aceea problema este invizibilă. Până când se întâmplă ceva.
Iar apoi apare o vulnerabilitate
Să presupunem că într-una din biblioteci se descoperă o vulnerabilitate serioasă.
Întrebarea este: Știi dacă sistemul tău o folosește?
Dacă ai un registru ordonat al dependențelor, răspunsul poate fi o chestiune de minute.
Dacă nu ai – începe căutarea manuală în repo-uri, contactarea programatorilor, verificarea mediilor, versiunilor pachetelor și a dependențelor indirecte.
Acum adaugă la asta codul generat de AI.
Se știe ce fragment a fost creat cu ce unealtă?
S-a făcut code review?
Este codul acoperit de teste?
S-au verificat dependențele?
Cineva a verificat licența componentului?
Se poate reconstrui procesul prin care a apărut un fragment concret?
Acestea nu mai sunt întrebări doar pentru programator.
Sunt întrebări despre gestionarea riscului tehnologic a companiei.
Cea mai mare problemă nu e AI. E lipsa unui proces
Ar fi ușor să transformi acest articol într-un avertisment împotriva inteligenței artificiale.
Ar fi însă o concluzie prea simplă.
AI poate îmbunătăți foarte mult productivitatea unei echipe de dezvoltare.
Problema apare atunci când o companie crește ritmul de producție a codului, dar nu mărește în același timp controlul asupra acelui cod.
E puțin ca și cum o fabrică ar produce brusc de zece ori mai multe componente, dar n-ar crește controlul calității, inventarul materialelor sau controlul furnizorilor.
Într-un software house echivalentul unui astfel de sistem de control sunt, printre altele:
- code review
- teste automate
- scanare a dependențelor
- SBOM
- monitorizarea vulnerabilităților
- controlul licențelor open source
- CI/CD cu controale de securitate
- gestionarea repository-urilor
- documentarea arhitecturii
- urmărirea provenienței componentelor
- reguli clare pentru utilizarea AI în dezvoltare
NIST semnalează și posibilitatea integrării mecanismelor de securitate ale lanțului de livrare direct în pipeline-urile CI/CD.
Aceasta e o schimbare importantă de gândire.
Securitatea nu trebuie să fie o verificare făcută abia înainte de lansare.
Trebuie să fie parte din procesul de dezvoltare al software-ului.
"Cine a scris acest cod?" încetează să mai fie întrebarea corectă
În lumea development-ului tradițional se putea întreba despre autor.
În lumea development-ului asistat de AI devin mult mai importante întrebările:
- De unde provine acest component?
- Ce licență are?
- Cine l-a verificat?
- Ce versiune folosim?
- Ce dependențe are?
- Este încă întreținut?
- Știm ce vulnerabilități are?
- Putem reconstrui istoricul modificărilor?
- Știm unde a intervenit AI în crearea lui?
Și, mai presus de toate:
- Poate compania demonstra că are control asupra întregului proces?
Pentru că clientul nu cumpără "cod de la AI". Cumpără un sistem funcțional. Și responsabilitatea pentru acel sistem o poartă în continuare organizația care îl livrează și îl menține.
Codul poate fi automat. Responsabilitatea nu
Aceasta este probabil una dintre cele mai importante schimbări pe care AI le aduce pentru software house-uri.
Programatorul nu dispare. Rolul său se schimbă.
Tot mai des nu mai e vorba doar de a scrie un anumit număr de linii de cod. E vorba de a proiecta soluția, a controla elementele generate, a evalua riscul, a testa, a integra, a securiza și a menține întregul sistem.
La fel, o companie nu se poate limita la întrebarea dacă programatorii ei folosesc AI.
Ar trebui să știe cum îl folosesc, în ce proces, cu ce controale și cum afectează asta ciclul de viață al software-ului.
Pentru că peste câțiva ani întrebarea nu va fi: "Cine a scris acest sistem?"
ci: "Poți reconstrui din ce și în ce mod a fost construit?"
Dacă răspunsul este "nu complet", problema nu e lipsa unei alte unelte AI.
Problema e lipsa controlului asupra software supply chain.
