De-a lungul vremurilor, unul dintre secretele meșterilor a fost mereu folosirea celei mai bune unelte pentru treaba pe care trebuiau să o facă. Pentru noi, una dintre aceste unelte începe să fie, din ce în ce mai mult, inteligența artificială, unealta care, folosită în modul potrivit și în contextul favorabil, poate să facă o adevărată diferență când vine vorba despre viteză și despre calitate în crearea unei "opere de artă" a unui maestru. Dar, ca toate uneltele, pentru a o putea folosi, trebuie să știm mai întâi cum să o facem și, mai ales, cum ne poate ajuta în continuul nostru proces de creație.
Urmând acest fir al întrebărilor reieșite din dorința de a utiliza mai bine noua unealtă din trusa noastră aflată în permanentă evoluție, am decis să experimentăm cu posibilele utilizări ale AI-ului în practica de zi cu zi. Pentru a avea un rezultat cât mai clar, împreună cu colegii mei, meșteri ai codului, am încercat să demarăm un experiment pe un proiect real, experiment care să fie cât mai aproape de realitate, dar care să poată totuși să ne ofere niște date concrete și cuantificabile.
Pentru a reuși să facem asta cât mai bine, am început prin definirea exactă a condițiilor pe care intenționam să le urmăm. Experimentul urma să se desfășoare chiar pe proiectul echipei, un proiect de mărime medie, cu o vechime de patru ani și cu o echipă de aproximativ 45 de oameni, timp de două săptămâni, perioada care a fost ulterior extinsă la patru, pentru a putea colecta mai multe date. Întrucât se dorea ca această inițiativă să aibă un impact minim asupra velocității echipei și să fie cât mai relevantă pentru contextul puternic bancar al proiectului, subiectului experimentului nu putea să fie altul decât dezvoltările care erau în lucru în momentul acela. Așa că, pentru a servi rolul unui grup de control, majoritatea colegilor au continuat dezvoltarea normal în timp ce câțiva colegi cu un grad crescut de senioritate au început să exploreze folosirea celor mai noi unelte.
La început, am încercat utilizarea mai multor LLM-uri, lucru care în scurt timp s-a dovedit ineficient, rămânând doar la doua dintre ele, GPT-4.1 și Claude 3.5 Sonnet (fiind schimbat la Claude 3.7 Sonnet la jumătatea perioadei, odată cu apariția lui). Inițial, pentru studiu au fost propuse câteva obiective clare, printre care se numărau:
Dezvoltarea de la zero a unei funcționalități complet noi deja estimate și compararea timpului estimat cu timpul real necesar;
Dezvoltarea într-o zonă existentă a aplicației a unei funcționalități noi deja estimate și compararea timpului estimat cu timpul real necesar;
Rescrierea unei zone mai vechi a aplicației și compararea cu timpul inițial și cu calitatea actuală;
Scrierea de teste, în special teste de unitate atât pentru cod nou scris cât și în zone deja existente;
Dezvoltarea unor noi integrări pe baza documentației tehnice furnizate;
Refactorizarea codului existent atât pe baza unui model, cât și fără un model concret;
Rezolvarea unor defecte pe baza tichetelor din Jira sau pe baza descrierii comportamentului;
Pe lângâ aceste obiective clare, scopul principal a fost și identificarea punctelor forte ale inteligenței artificiale, puncte care se puteau vedea cel mai bine prin utilizarea acesteia în contexte cât mai variate și prin spargerea celor opt obiective în diferite bucăți ușor de gestionat și de aplicat individual. În total, pe parcursul celor patru săptămâni, am atins aproximativ 40 de utilizări relativ diferite, cu varii grade de complexitate, de la crearea unui șablon pentru o clasă, la generarea unei integrări cu o metoda REST, și până la crearea unei modale complexe dintr-un singur mesaj scris.
Acum că avem întregul context al experimentului, putem să trecem la exploatarea rezultatelor la care am ajuns în aceste patru săptămâni. Pentru a rămâne mai țintiți, în continuare vom discuta într-un mod mai punctual despre cele mai bune cazuri de utilizare și despre situațiile în care AI-ul a fost mai puțin eficient și în care nu s-a dovedit a fi cea mai bună unealtă.
De departe cea mai precisă și mai eficientă utilizare, generarea de cod șablon a fost una dintre situațiile în care ne așteptam ca AI-ul să sporească viteza de dezvoltare considerabil. În urma mai multor încercări făcute, acel considerabil s-a dovedit a fi un respectabil ~90%, ducând aproape la o automatizare a acestei activități, considerate de majoritatea ca monotonă și repetitivă, extrem de ușor de făcut. Două dintre cele mai utile scenarii pe care le-am remarcat sunt generarea de clase care implementează interfețe și generarea întregii structuri de CSS pentru o componentă de Angular.
Un alt aspect în care ne așteptam ca AI-ul să performeze bine a fost maparea de obiecte, lucru care s-a văzut cu ușurință din acuratețea cu care făcea asta și din timpul salvat cu acest ajutor. Chiar dacă este o activitate ușor de făcut, este totuși monotonă și anevoioasă, motiv pentru care timpul scăzut cu ~90%, peste așteptările inițiale semnifică o mare victorie pentru inteligența artificială. Pe lângă multe alte situații în care am testat acest aspect, cea mai marcantă a fost una în care am încercat maparea unui răspuns al unei integrări care consta într-un obiect cu peste 100 de atribute la modele folosite de noi, lucru pe care nu doar ca AI-ul l-a făcut, ci pentru care a propus și niște modele adiționale, identificate pe baza contextului aplicației.
În timpul scenariilor testate am evidențiat că în ceea ce privește integrările ajutorul este proporțional cu documentația integrării, lucru care era de așteptat. Totuși, chiar și când copilotului îi este furnizată o documentație relativ completă pentru cerință, acesta tot are unele probleme cu generarea unei integrări, încercând uneori să atingă cazuri imaginare bazate pe alte integrări existente. În medie, dacă ne referim doar la integrări bine documentate și nu le luăm în calcul pe cele cu documentație mai sumară, timpul câștigat pare să fie, în medie, de ~70%.
Una dintre cele mai așteptate utilizări pentru aceasta unealta, generarea de teste unitare a fost una dintre zonele principale de interes. După mai multe teste pe diverse zone cu o variație atât a complexității de cod cât și a complexității a logicii bancare, verdictul a fost, din păcate, puțin sub așteptări, scăzând timpul cu o medie de aproximativ 60%. De ce o medie? Pentru că adevăratele procente arată cam așa: ~90% pentru cod șablon, ~80% pentru teste de tip CRUD, ~30 pentru teste cu logica complexă și cu scenarii exhaustive, cele mai importante, de altfel.
Un rezultat de-a dreptul neașteptat, această înjumătățire a timpului petrecut pe noi componente de UI de o complexitate mai mică a fost remarcată în timpul testării rescrierii, în momentul în care Github Copilot a generat un control de tip dropdown bazat de pe alte două controale de tip input și de tip multiselect. În urma mai multor teste pe subiect, mai mare partea a timpului a fost salvată prin generarea logicii și a comportamentului, necesitând în unele cazuri doar modificări vizuale.
.png)
Un alt beneficiu apărut pe parcursul testelor a fost timpul scăzut al refactorizării aflate într-un stadiu mai avansat. Chiar dacă refactorizarea fără modele existente a fost una dintre metricile la care AI-ul s-a descurcat mai puțin bine, acest număr a început să crească drastic odată cu apariția unor modele "post refactorizare" pe care AI-ul le-a putut referenția. În situația în care Github Copilot a avut contextul a ceea ce fusese deja făcut, a reușit să sporească refactorizarea unor componente chiar și cu aproximativ 40%, în medie.
Când vine vorba despre acest scenariu, ar trebui menționat că scopul spre care s-a mers a fost rezolvarea defectelor, pe cât posibil fără ajutor uman sau cu ajutor minim, doar pe baza informațiilor din tichete. Din păcate, scopul nu a fost atins, în multe cazuri nici măcar parțial, lucru datorat, în parte, și complexității logicii bancare din proiect. În majoritatea cazurilor testate, AI-ul nu ajuta în mod substanțial, chiar adăugând timp procesului de reparare. În final, am decis să nu depășim acest procent de 10% timp adăugat, finalizând testul când se ajungea la el, și să marcăm aceasta utilizare ca nerecomandată.
Generare de cod pentru versiuni specifice ale unor dependențe (aprox. +-5%)
O situație mai rar întâlnită dar cu care, din păcate, ne confruntăm uneori pe proiect, generarea de cod pentru versiuni specifice ale unor dependențe sau ale unor aplicații s-a dovedit una dintre cele mai nepredictibile utilizări. Pentru unele scenarii, Github Copilot venea cu soluții ideale, în timp ce pentru altele găsea "Soluții" nefuncționale și ducea la pierderea timpului. În medie, impactul a fost relativ mic, dar cu printre cele mai mari potențiale de variație, motiv pentru care a fost considerat un scenariu de utilizare nerecomandat.
O altă problemă cu care ne confruntăm pe proiect a fost utilizarea librăriilor mai nișate, scenariu pe care am încercat să-l testăm și pentru care am avut rezultate, din nou, variate. Media de -15% a timpului este una rezultată atât în urma testării unor scenarii de "copiere" a codului scris deja în proiect cu elemente din librăriile testate, unde AI-ul s-a descurcat bine cât și în urma încercării folosirii unor noi elemente din librăriile respective, caz în care Copilotul nu a avut așa o mare rată de succes, nici în urma furnizării documentației pentru librărie. Cu o scădere de până la 15%, cazul acesta poate, totuși să fie util, în funcție de cât de mult este deja utilizată librăria în proiect.
Spre deosebire de beneficiile menționate mai sus la punctul VI, refactorizarea aflată într-un stadiu incipient, unde nu avem încă modele pentru mai multe cazuri, s-a dovedit a fi un scenariu mai puțin eficient, timpul salvat fiind sub medie. În timpul acestui tip de refactorizare, Copilotul propune soluții funcționale în mare parte, dar cărora le lipsea direcția unitară și conformitatea spre care se dorea merge. De notat și că s-a remarcat și pierderea de scenarii pentru cazurile cu logică bancară mai complexă, situație care a fost mai evidentă în scenariul refactorizării fără modele existente, lucru datorat, în parte, încercării AI-ului de a supra simplifica implementările.
Chiar și dacă această utilizare nu a fost una testată cu unul sau mai multe scenarii specifice, ea s-a regăsit în majoritatea, "preluând greul" odată ce codul inițial era generat de către Copilot și începea ajustarea și modificarea lui. Funcționalitatea de completare automată inteligentă s-a dovedit a fi un factor decisiv în scăderea timpului, fiind folosită constant în scrierea codului, scăzând la fiecare utilizare câteva secunde importante, care, deși par puține, se adună și duc la o creștere tangibilă a productivității.
În urma studiului, am ajuns la verdictul ca Github Copilot ne-a ajutat sa scădem timpul petrecut pe developement cu 25-30% Un rezultat care nu este media aritmetica a tuturor scenariilor testate, ci, factual observat, impactul avut asupra procesului efectiv de development. De ce? Pentru că, chiar dacă unele cazuri se remarcă cu numere de -90% iar alte cu procente mai rele, de +10%, majoritatea scenariilor care nu au fost "remarcabile" gravitează în jurul acestui interval.
În medie, pe parcursul acestor patru săptămâni, acesta a fost rezultatul observat în scăderea timpului actual de pe tichetele la care colegii lucrau. În urma unei observații mai amănunțite, s-a ajuns la concluzia că, chiar dacă unele acțiuni sunt ajutate substanțial de AI, ele nu necesită un timp atât de mare în mod normal, fiind ori de durată și complexitate mică, ori mai rar întâlnite decât alte utilizări neremarcabile.
Pe lângă asta, scopul a fost și evitarea conceptului de "Vibe Coding", concept care indică scrierea de cod doar cu o înțelegere superficială, prin generarea continuă și rapidă a noilor funcționalități de către AI, practică care duce la cod greu de menținut și la o lipsă de consistență. Pentru a reuși evitarea acestei practici, soluția a fost explicarea în instrucțiuni nu doar a cerinței sau a problemei, ci și a soluției găsite de către mintea umană, soluție care trebuia apoi doar scrisă într-un mod corect și rapid de către AI.
În urma studiului, am ajuns la concluzia că această nouă unealtă este una folositoare care poate aduce un plus de valoare atunci când este folosită înțelept. Am înțeles mai bine atât punctele puternice ale AI-ului, văzând cât de bine poate automatiza sarcinile repetitive și ușor de standardizat, cât și zone mai deficitare, observând impactul și precizia scăzută pe care acesta îl are când vine vorba despre sarcini complexe care necesită o înțelegere mai profundă și care nu urmează un șablon ușor de urmărit.
Mai departe, noi vom continua să analizăm impactul pe care inteligența artificială îl are asupra modului nostru de lucru, încercând să vedem cum o putem include în activitățile de zi cu zi într-un mod cât mai puțin intruziv pentru a putea beneficia de creșterea descoperită de 25-30%. Vă încurajăm și voi să experimentați și să demarați astfel de studii interne pentru că, doar explorând noi idei și fiind informați, putem să fim niște adevărați meșteri ai codului.
Design and human touch
Joi, 19 Iunie, ora 18:00
msg systems Romania
Facebook Meetup StreamEvent YouTubede Ovidiu Mățan
de Ovidiu Mățan
