Skip to main content
Înapoi la blog

Cum folosim AI în munca noastră și de ce un senior verifică în continuare totul

Valentin Zsigmond
Valentin Zsigmond10 septembrie 20265 min de citit

Inteligența artificială a devenit parte din felul în care lucrează multe echipe de software, iar a noastră nu face excepție. În loc să ne dăm din colț în colț, preferăm să spunem lucrurilor pe nume: iată unde ne ajută AI, unde nu, și de ce, în fond, felul în care lucrăm nu s-a schimbat.

Pe scurt, AI e un instrument util, cu limite clare. Se pricepe să pună o primă schiță pe pagină, să ne ajute să ne documentăm rapid despre o problemă și să producă scheletul repetitiv de care are nevoie orice proiect. Nu se pricepe să decidă ce e corect, ce e sigur sau ce i se potrivește unui anumit client. Deciziile astea rămân ale unui om, și în munca noastră așa vor rămâne mereu.

Pentru un client, concluzia e simplă. Primești viteza pe care instrumentele astea chiar o aduc, fără riscul de a te bizui prea mult pe ele.

La ce folosim AI, de fapt

În munca de zi cu zi, folosim AI mai ales în trei zone. Prima e schițarea. O funcție, un fișier de configurare, o primă variantă de documentație, o schiță pentru un articol ca ăsta: drumul de la pagina goală la ceva la care putem reacționa e adesea partea lentă, iar AI îl scurtează. E mai rapid să reacționezi la o schiță decât să o scrii, iar schița e un punct de plecare, niciodată lucrarea finită.

A doua e documentarea. Când cântărim o abordare, verificăm cum se comportă o anumită interfață din Drupal sau ne orientăm într-un colț necunoscut al unei baze de cod, AI poate strânge rapid contextul relevant și ne poate trimite la documentația potrivită, ca să confirmăm. Ce ne spune o tratăm ca pe o pistă de verificat, nu ca pe un răspuns de luat de bun, pentru că instrumentele astea pot greși cu o siguranță dezarmantă.

A treia e codul-șablon. Orice proiect are cod repetitiv și previzibil: forma standard a unui modul, un set de teste asemănătoare, o structură de date care urmează un tipar consacrat. Exact aici un instrument care a văzut tiparul de multe ori poate economisi timp cu adevărat, iar un om își dă seama repede dacă rezultatul e corect. Timpul câștigat la rutină îl putem pune în părțile care nu sunt rutină, adică exact acolo unde îi e locul.

În toate trei, tiparul e același. AI face partea mecanică sau ușor de verificat, iar un om face partea care cere înțelegere. Nu are niciodată ultimul cuvânt și nu sare nicio etapă; doar ne duce mai repede la unele dintre ele.

La ce nu folosim AI

Nu lăsăm AI să ia deciziile care contează. Nu îți alege arhitectura, nu decide cum îți modelăm datele și nu stabilește cum tratăm ceva sensibil. Nu dă undă verde pe securitate. Nu decide când ceva e gata. Judecățile astea cer să înțelegi afacerea, compromisurile și ce se întâmplă dacă greșești, iar înțelegerea asta e răspunderea noastră.

Suntem atenți și la ce ajung să vadă instrumentele astea. Datele clienților, datele de autentificare și tot ce e privat rămân în afara lor. Ajutorul pe care îl acceptăm ține de forma codului și de raționamentul din jurul lui, nu de ceva confidențial care ne-a fost încredințat.

Fiecare modificare trece prin același filtru

Aici e partea care contează cel mai mult. Indiferent cine sau ce a ajutat la scrierea unei modificări, ea trece prin exact aceeași verificare ca tot ce scriem. Un om o citește, rând cu rând, și răspunde pentru ea. Trebuie să respecte aceleași standarde de cod, să urmeze aceleași convenții Drupal și să se potrivească cu tiparele deja existente în codul tău. Trebuie să treacă aceleași teste automate înainte de lansare și intră live prin același proces de lansare urmărit și reversibil pe care îl folosim pentru orice modificare.

Nimic nu primește o scurtătură doar pentru că a fost un instrument la mijloc. O schiță la care a ajutat AI și una scrisă de mână de un dezvoltator trebuie să treacă de aceeași ștachetă înainte ca oricare dintre ele să devină parte din site-ul tău. Din afară, și chiar în cod, nu poți spune care e care, pentru că până la lansare a fost șlefuită și verificată după același standard, indiferent cum a început.

De ce verificarea e tot rostul, nu o formalitate

Ar fi ușor să tratăm verificarea asta ca pe o ștampilă, și exact greșeala asta o evităm. Instrumentele astea produc rezultate care par plauzibile, și tocmai de aceea verificarea atentă e obligatorie, nu opțională. Un cod care se citește bine poate fi totuși subtil greșit, poate rata un caz-limită sau poate rezolva elegant problema greșită. Ca să prinzi așa ceva îți trebuie cineva care înțelege tot sistemul și răspunde de rezultat.

Așa că verificarea făcută de un senior nu e acolo ca să prindă câte o greșeală din când în când. E etapa în care se face judecata inginerească propriu-zisă: codul ăsta are ce căuta aici, rezistă în cazurile care contează, o să mai aibă sens pentru următorul om care îl citește peste doi ani. Un instrument poate grăbi tastatul. Nu poate lua răspunderea, și nici nu îi cerem asta.

Ce înseamnă asta pentru site-ul tău

Practic, o parte din muncă ajunge la tine mai repede decât acum câțiva ani, iar părțile unui proiect care erau lente fără niciun motiv bun, scheletul și primele schițe, iau mai puțin timp. Așa ne rămâne mai multă atenție pentru părțile care chiar au nevoie de ea: deciziile de design, logica delicată, verificarea atentă.

Ce nu se schimbă e ștacheta pentru lucrarea finită. Codul de pe site-ul tău, fie că e o funcționalitate nouă sau mentenanță curentă, e cod pe care un om l-a înțeles, l-a verificat și pe care își pune semnătura. Tu ai partea bună a vitezei, noi păstrăm răspunderea pentru calitate. Echilibrul ăsta, instrumente noi fără să coborâm ștacheta, e toată poziția noastră, și credem că e cea cinstită.

Încotro credem că se îndreaptă lucrurile

Instrumentele astea vor fi tot mai bune, iar noi vom ajusta felul în care le folosim pe măsură ce evoluează. Nu suntem nici extaziați, nici speriați. E un asistent priceput care a grăbit părți din munca noastră și, ca orice instrument, e exact atât de bun pe cât e judecata celui care îl mânuiește.

Angajamentul nostru e simplu: oricum s-ar schimba instrumentele noastre, munca pe care ți-o predăm va fi întotdeauna verificată, testată și înțeleasă de un om care răspunde pentru ea. Așa era și înainte să apară toate astea, și așa va rămâne. Ba chiar, cu cât pot face mai mult instrumentele astea, cu atât mai mult judecata omului din jurul lor e ceea ce plătești de fapt.

Distribuie articolul
Valentin Zsigmond
Scris de
Valentin Zsigmond
Fondator și inginer principal

Arhitect Drupal full-stack cu aproape două decenii de experiență în conducerea unor echipe mari în medii enterprise. A fondat Tilizy Digital pentru a aduce expertiză de nivel senior direct organizațiilor care au nevoie de ea. Mentor pentru zeci de dezvoltatori Drupal și creatorul SDX, o extensie Drupal pentru construirea de interfețe moderne cu React și Vue.

Ți-a plăcut articolul?

Dacă te-ai regăsit în articol, imaginează-ți ce am putea face împreună pe site-ul tău Drupal.