Software

Rolul programatorului a evoluat de la simplu executant la arhitect de sistem, care deleaga scrierea codului catre agentii de inteligenta artificiala (IA). Prin dezvoltarea bazata pe specificatii (spec-driven development), procese de proiectare de cateva saptamani sunt comprimate in discutii de doar 15 minute, iar numarul de lansari in productie al echipelor a crescut de 4,5 ori, a declarat McLaren Stanley, Senior Principal Engineer Amazon, intr-un interviu exclusiv acordat Go4it.ro. Echipa sa utilizeaza solutii precum Kiro, un IDE (Integrated Development Environment) de programare bazat pe IA de tip agentic, pentru a moderniza bazele de cod iOS si Android ale aplicatiilor mobile ale Amazon, scrise in trecut in limbaje de programare care nu mai corespund cerintelor de astazi.

Stanley a spus ca, prin aceasta noua abordare, a scris anul trecut mai mult cod decat in intreaga cariera. "Eu unul am scris mult mai mult cod. Anul trecut am scris mai mult cod decat in tot restul carierei mele la Amazon la un loc", a declarat inginerul, specializat in dezvoltarea de software bazat pe IA si arhitectura aplicatiilor mobile. El a lucrat in trecut pentru Microsoft, Uber si Twitter.

S-a vorbit mult despre faptul ca inteligenta artificiala elimina oportunitatile pentru dezvoltatorii software juniori. Totusi, Stanley crede ca acestia inca mai sunt doriti in companii si ca viitorul apartine inginerilor tineri curiosi si orientati spre actiune. Juniorii sunt cautati de companie deoarece vin fara prejudecati si adopta uneltele noi mult mai nativ, potrivit reprezentantului Amazon.

Stanley avertizeaza, in interviu, impotriva "antropomorfizarii IA", viziunea SF legata de tehnologie. Exista doua tipuri de utilizatori: cei care folosesc IA ca asistent pentru a colecta date si a gandi mai repede si cei care isi "externalizeaza gandirea". Doar primii vor avea succes, deoarece discernamantul uman la nivel inalt ramane de neinlocuit.

Adrian Popa: Daca inteligenta artificiala scrie acum cea mai mare parte din cod, ce mai face de fapt programatorul astazi? Putem spune ca rolul s-a mutat de la un "muncitor de pe santier" la un "arhitect" care supravegheaza proiectul pentru un angajat digital?

McLaren Stanley: Cred ca aceasta este, de fapt, o modalitate destul de buna de a caracteriza situatia in multe cazuri. Daca agentul este cel care scrie codul, calitatea codului sau a acelui rezultat depinde de cat de bine proiectezi sistemul pe care incerci sa-l determini sa-l construiasca, corect? De aceea, folosim in special dezvoltarea bazata pe specificatii (spec-driven development), care este o tehnica pe care am utilizat-o pe scara larga.

Ne petrecem cea mai mare parte a timpului in avans gandindu-ne la ce ar trebui sa construim, cum ar trebui sa functioneze pe diferitele platforme si apoi construind si proiectand cerintele. Specificatiile si sarcinile efective pe care agentul le va executa ulterior - acolo ne petrecem cea mai mare parte a timpului acum.

Si, stiti, disciplina ingineriei software este inca foarte implicata pentru ca oamenii asigura calitatea rezultatului, se ocupa de orchestrarea necesara si au in continuare un rol foarte puternic, atat din punct de vedere operational, cat si in situatii care necesita un discernamant critic ridicat. Din aceasta perspectiva, ingineria a devenit... este aproape ca o forma interesanta de eliberare, asa imi place sa-i spun, pentru ca ajungem sa ne petrecem mai mult timp facand partile creative ale muncii noastre si mai putin timp luptandu-ne cu imbinarea codului (merging), gestionarea conflictelor de pe parcurs sau cu lucrurile mai banale din ingineria software in sensul unei companii moderne.

Astfel, am petrecut considerabil mai mult timp anul acesta construind si proiectand efectiv sisteme decat as fi facut-o altfel fara IA, pur si simplu pentru ca elimina o mare parte din efortul administrativ din proces.

Adrian Popa: Cum i-ati explica cuiva fara un background tehnic cum arata o zi tipica intr-un scenariu de dezvoltare bazata pe specificatii? Cum functioneaza aceasta interactiune in practica, unde o persoana defineste regulile, iar IA construieste aplicatia in sine? Cum este o astfel de zi pentru un programator care lucreaza asa?

McLaren Stanley: O zi de lucru... o mare parte din toate astea este destul de interesanta. Dezvoltarea bazata pe specificatii a fost extrem de colaborativa pentru noi. Inainte sa apara IA, dura destul de mult sa scrii manual planurile de proiectare, sa iti dai seama exact cum vom construi o functionalitate pentru iOS sau Android. Apoi, cineva petrecea mult timp scriind acel document de proiectare, iar dupa cateva zile, cateva iteratii sau chiar saptamani, il revizuiam. Faceam modificari, spuneam: "Nu e grozav, acum mergi inapoi la tabla sau incepe lucrul" si asa mai departe. Deci se consuma mult timp cu acest tip de munca asincrona in avans pentru investigatii si proiectare.

Acum, de cand o mare parte din acea munca de proiectare a fost compactata, constatam ca procesul este extrem de colaborativ. In loc ca oamenii sa plece si sa lucreze separat, de multe ori adunam in aceeasi camera un designer, un manager de produs si inginerul de Android/iOS, ne asezam cu agentul Kiro si pur si simplu descriem ceea ce incercam sa incepem sa construim. Devine un fel de exercitiu de lucru in pereche.

Iar acel interval care dura cateva saptamani este acum comprimat intr-o discutie rapida de 15 minute sau o ora. Decidem ce sa construim, iar apoi punem agentii sa treaca la treaba. Deoarece procesul este atat de comprimat, devine extrem de iterativ. Mergem, construim, obtinem poate un prototip, ajungem la jumatatea implementarii si spunem: "Ah, poate nu asta ne doream, hai sa ne intoarcem la planul initial si sa o facem din nou".

Pentru ca investitia de timp in producerea acelor artefacte intermediare este mult mai mica, a fost cu adevarat grozav, deoarece oamenii se ataseaza mai putin de ideile proaste. Poti pur si simplu sa iterezi mai repede. Vezi ca o idee nu a functionat prea bine? Nicio problema, o arunci si incerci alta. Ne place foarte mult acest mediu extrem de colaborativ care se creeaza si rapiditatea cu care poti transforma ideile in realitate.

Adrian Popa: Poate, pentru un context complet, ne puteti spune despre echipa dumneavoastra si ce face mai exact, ca sa intelegem ce inseamna rescrierea codului. Care sunt lucrurile care stau la baza acestei IA?

McLaren Stanley: Ceea ce face echipa mea... ca profesie, eu sunt inginer iOS. Sunt inginer pe zona de mobile de mult timp, iar aplicatiile principale de cumparaturi Amazon exista si ele de multa vreme. Ceea ce am facut noi cu Kiro a fost sa modernizam agresiv baza de cod. Exista cateva efecte interesante in dezvoltarea bazata pe agenti: limbajele moderne de programare - cele care sunt type-safe, thread-safe si memory-safe - sunt mult mai sigure si mai bune de utilizat cu agentii de codare.

Daca compilatorul poate impune aceste constrangeri, agentul primeste un raspuns mai clar daca solutia generata de el functioneaza sau nu. De fiecare data cand primesti un feedback mai bun de la compilator, obtii iteratii mai bune si rezultate remarcabil de sigure, foarte similare cu modul in care ai fi facut-o manual ca dezvoltator uman.

Prin urmare, am demarat un efort de modernizare a bazelor de cod pentru Android si iOS cu aceste limbaje mai moderne, deoarece in prezent ele sunt scrise in limbaje mai vechi. Objective-C, de exemplu, nu era thread-safe, memory-safe sau type-safe la momentul compilarii; folosea verificari in timpul rularii (runtime) pentru toate acestea. Asa ca am depus un efort mare pentru a le moderniza.

Un alt lucru care a fost foarte eficient pentru noi este ca, atunci cand definim specificatiile functionalitatilor pe care le construim - fie ca le facem prin inginerie inversa din functionalitati mai vechi, fie ca adaugam unele noi -, putem lua cerintele de business ale aplicatiei (ceea ce face ea, capabilitatile dorite, chiar si schite de pe tabla sau fisiere de design), le punem cap la cap si generam o specificatie care spune: "Iata cum se vor comporta aceste functionalitati".

Apoi generam concomitent codul pentru iOS si Android. Acest lucru este excelent pentru noi deoarece, atunci cand oamenii construiau separat pe ambele platforme, ne chinuiam mereu sa le mentinem sincronizate. In functie de piata pe care activai, echipa care construia functionalitatea putea fi mai interesata de versiunea de Android sau de cea de iOS, in functie de unde se aflau clientii lor. De multe ori construiau o functionalitate pentru Android si poate nu o mai faceau pentru iPhone. Am avut aceasta problema de-a lungul anilor, cea de a mentine functionalitatile sincronizate.

De aceea, mizam foarte mult pe aceasta metodologie. Acest proces va face dezvoltarea pe mobile mult mai consecventa si mai usoara, deoarece imi pot transpune expertiza de iOS in directivele pe care agentul le foloseste pentru a construi functionalitatea. Inginerul de Android poate face acelasi lucru. Iar alti ingineri, care nu sunt la fel de familiarizati cu subtilitatile platformei, isi pot lua cerintele de business si pot dezvolta cod de o calitate la fel de buna pe fiecare platforma, deoarece am reusit sa instruim, sa ghidam si sa configuram procesul astfel incat sa produca raspunsuri bune pe ambele parti.

Adrian Popa: Ati mentionat obtinerea unor castiguri semnificative de productivitate prin aceasta metoda, unele echipe lucrand mult mai rapid. Mai exact, ce inseamna aceasta economie de timp pentru clientii care au aplicatia Amazon pe telefoanele lor?

McLaren Stanley: Voi vorbi in sens mai larg despre productivitatea magazinelor in general, deoarece proiectul pentru aplicatie este inca in desfasurare si vom vedea rezultatele finale in viitor. Insa am realizat un proiect pilot in cadrul magazinelor noastre, pe o multime de tehnologii diferite, si am evaluat acele echipe comparativ cu propria lor rata de lansare in productie.

Motivul pentru care am facut asta este ca la Amazon exista foarte multe echipe de inginerie diferite, cu stiluri, tehnici si platforme diferite pentru care construiesc. Le-am configurat sistemul si apoi am masurat cat de des trimiteau codul in productie. Am constatat ca, in medie, in randul echipelor din proiectul pilot care au incercat aceasta abordare de dezvoltare nativa cu IA, numarul de lansari in productie a crescut de 4,5 ori in acea perioada de testare.

Acest lucru creeaza un ciclu de inovare extraordinar, deoarece putem testa idei considerabil mai rapid. In proiectul nostru de modernizare, acest lucru ajuta la stabilitate si la adoptarea mai rapida a noilor functionalitati. In plus, simplul fapt de a reduce durata ciclului de dezvoltare si de a avea capacitatea de a itera conteaza enorm. Exista atat de multe idei, iar multe dintre aceste echipe au liste uriase de sarcini (backlogs) de care nu s-au putut atinge niciodata din cauza timpului, a prioritatilor sau a volumului de munca. Acum, rentabilitatea investitiei (ROI) pentru rezolvarea acelor probleme s-a schimbat atat de mult incat pot realiza mult mai multe lucruri.

Asta inseamna o securitate mai buna si o functionalitate superioara. Un exemplu excelent este accesibilitatea pentru persoanele care folosesc un cititor de ecran. Inginerul meu de accesibilitate poate introduce expertiza profunda de Android, iOS si web in acest proces. Echipele obisnuite - din sutele de echipe si mii de ingineri care construiesc functionalitati pentru experienta de retail a magazinelor - nu au neaparat aceste abilitati extrem de specializate pe fiecare platforma in parte. Sunt echipe mici. Insa odata ce am integrat acea expertiza in sistem, acum putem gestiona nevoile clientilor nostri care folosesc cititoare de ecran sau alte functii de accesibilitate mult mai consecvent si mai rapid, la nivelul intregii companii.

Adrian Popa: Si afecteaza acest lucru in vreun fel preturile produselor vandute in aplicatie? Ma refer pe termen lung, daca sunteti mai eficienti si aveti un produs mai bun.

McLaren Stanley: In mod general vorbind, da. Intregul model de afaceri al Amazon este de a transfera eficienta noastra catre clienti sub forma unor preturi mai bune. Dar, dincolo de asta, a ramas o multime de lucruri uimitoare de facut care acum pot fi realizate, oferind mai multa valoare clientilor nostri pe toate nivelurile sistemului.

Adrian Popa: Care este procesul de rezolvare a erorilor majore atunci cand codul generat esueaza?

McLaren Stanley: Va referiti la o eroare, la o greseala? Cheia pentru ca dezvoltarea cu IA sa functioneze cu succes este sa iti configurezi intregul flux de lucru si tot ciclul de viata al dezvoltarii software pentru a profita de ea. Nu este vorba doar de scrierea codului, ci de cat de sigur imbinam si testam acel cod.

Inainte, cand aveai o echipa mica ce scria cod manual, membrii ei puteau sa isi automatizeze o parte din teste sau sa ruleze un test de control al calitatii (QA) pentru a se asigura ca functionalitatea e in regula. Acum, din cauza volumului si a vitezei cu care se lucreaza, trebuie sa acordam mai multa atentie asigurarii unei testari foarte solide. Adica sa ai suite de teste automate cu acoperire completa care ruleaza la fiecare salvare, pentru a te asigura ca agentul nu introduce cod care sa sparga sistemul. Inainte puteai folosi oameni si echipe de QA care sa monitorizeze asta in timp; acum am descoperit ca avem nevoie de o infrastructura de testare mult mai robusta.

De asemenea, avem nevoie de o modalitate de a implementa aceste modificari mai in siguranta, deoarece vin mult mai multe schimbari si exista riscul de a aparea conflicte daca foarte multi agenti lucreaza in aceeasi baza de cod. Acest lucru ne-a obligat cu adevarat sa regandim modul in care codul circula de la computerul dezvoltatorului pana la utilizatorul final si sa adaugam masuri de siguranta suplimentare, testare si instrumente de verificare a calitatii codului. Folosim aceste bariere pentru a ne asigura ca agentul face ceea ce trebuie si nu poate face ceva ce nu ar trebui.

Pe de alta parte, cand apare o problema, poti folosi tot agentul pentru a o analiza. De cele mai multe ori, deoarece agentii sunt foarte buni la recunoasterea tiparelor, daca exista o eroare, o prabusire a aplicatiei sau o urma a stivei de executie, o trimiti agentului si acesta poate depista cauza initiala si diagnostica problema considerabil mai rapid decat oamenii. Poate analiza rapid un index urias al tuturor segmentelor de cod care ar putea avea o problema si o poate localiza imediat. Inainte de a avea acesti agenti era nevoie ca cineva sa reproduca problema, ca un inginer sa citeasca tot codul sau sa analizeze fisierele de jurnal pentru a descoperi unde s-a gresit. Acum, avand agentii ca instrumente, acestia pot analiza volume mari de date extrem de repede si pot identifica sursa problemei mult mai repede.

Adrian Popa: Cand IA scrie cod la scara Amazon, nu se pierde memoria tehnica institutionala? Daca un sistem complex generat de IA se strica peste cinci ani, iar inginerii care au ghidat acele comenzi au plecat din companie, cat de greu ii va fi unui inginer uman sa faca inginerie inversa pe tehnologia generata de IA?

McLaren Stanley: Aceasta este o intrebare excelenta. Aici intervine frumusetea dezvoltarii bazate pe specificatii. Exista multe tehnici diferite in prezent prin care oamenii construiesc software cu ajutorul agentilor, dar ceea ce diferentiaza Kiro este structura modului in care construiesti lucrurile. Aceasta creeaza un istoric al deciziilor tale de business prin intermediul specificatiilor: "Iata cerintele pentru care am construit aceasta functionalitate si iata designul software propriu-zis". Sistemul coreleaza cerintele cu faza de proiectare si testare, explicand in limbaj natural decizia de business care a fost luata acolo.

Noi salvam acele fisiere in sistem; ele raman alaturi de codul generat. Echipa mea face asta - desi unele echipe au fluxuri de lucru diferite -, salvam aceste date pentru a avea o evidenta a deciziei. Acest lucru este excelent din nou pentru problema Android/iOS: daca creez ceva pentru o platforma, am dovada scrisa a motivului pentru care am facut-o in acel mod specific, iar apoi o pot rula pe cealalta platforma. Pe termen lung, avem o evidenta a acelei decizii.

Pe de alta parte, am realizat rapid ca cea mai mare parte a codului nostru actual provine dintr-o perioada in care a fost scris de oameni si se confrunta exact cu aceeasi problema: persoana respectiva a plecat, codul a fost scris acum 10 ani si nimeni nu stie exact ce face. De aceea, am construit un instrument folosind agenti din Amazon Bedrock numit Spec Studio. Acesta scaneaza bazele de cod existente si extrage prin inginerie inversa cerintele de business din codul actual. Analizeaza un pachet sau un grup de pachete de cod si explica ce face acea logica de programare. Ba mai mult, daca acel pachet nu avea documentatie (pentru ca inginerul respectiv a considerat ca nu are nevoie sau a uitat sa o scrie), instrumentul va genera documentatia pentru dezvoltatori.

Si face acest lucru cu o acuratete destul de buna. In timp, folosim acel agent pentru a genera documentatia si a inregistra deciziile luate. Poate nu iti va spune de ce au fost luate acele decizii, dar macar iti spune ce decizie s-a luat. Iar asta le permite oamenilor sa inteleaga mult mai usor ce se intampla in sistemele complexe la scara Enterprise. La o scara precum cea a Amazon, chiar daca stii ce faci, poate fi foarte greu sa intelegi exact ce s-a intamplat pe o portiune mare din baza de cod. Mi se intampla chiar si mie, cu codul scris de mine: "De ce am facut asta? Nu imi mai aduc aminte, unde era linia asta sau ce fisier cu simboluri trebuie sa caut?". Faptul ca agentul construieste acea evidenta structurala le usureaza tuturor intelegerea sistemului.

Adrian Popa: Ce limbaje de programare folosesc agentii dumneavoastra?

McLaren Stanley: In cazul nostru, am trecut in intregime la Swift pentru iOS si Kotlin pentru Android. Am facut asta special datorita caracteristicilor lor de siguranta (type-safe, thread-safe, memory-safe). Swift este un limbaj extrem de sigur din acest punct de vedere; Apple l-a dezvoltat acum mai bine de un deceniu si a devenit standardul pentru dezvoltarea iOS in prezent, ajutandu-ne in acest efort de modernizare.

Exista si alte tipare pe care agentul le preia foarte bine, dar in general, Swift are o comunitate open-source activa. Asta inseamna ca modelul a avut acces si a fost antrenat pe volume uriase de date despre Swift. Modelele vor sti nativ cum sa gestioneze foarte bine limbajele care sunt deschise, disponibile si utilizate pe scara larga. Daca ai un limbaj intern proprietar, modelele nu se vor descurca nici pe departe la fel de bine ca in cazul celor open-source care au o multime de exemple de cod pe internet. Astfel, cu masurile de siguranta adecvate, agentii se descurca mult mai bine cu limbajele utilizate pe scara larga si care au un volum mare de cod open-source disponibil.

Adrian Popa: In unele domenii, cum ar fi apararea, dar si in meseria mea, cum ar fi scrierea de articole jurnalistice sau texte literare, utilizarea IA ramane controversata. De ce nu este cazul si in programare, unde utilizarea ei este incurajata activ?

McLaren Stanley: Conceptul de open-source este un raspuns bun si pentru aceasta intrebare. Ingineria software isi are multe dintre radacini in aceasta idee de open-source, unde construim pe baza a ceea ce s-a realizat deja. Linux si toate celelalte platforme open-source majore isi partajeaza codul pentru ca oamenii sa il poata construi, schimba si modifica. Acea comunitate open-source a creat deja un efect de colaborare.

IA a putut profita de acest lucru. Dar, in plus, creativitatea in ingineria software vine din capacitatea de a aduna acele tipare existente in solutii unice pentru a rezolva problemele clientilor, chiar daca altcineva a scris acea librarie initiala. Cred ca ingineria software a fost perfecta pentru asta deoarece noi deja impartaseam, reutilizam si contribuiam la eforturi colective de acest gen. Ca disciplina, am fost mai deschisi la acest tip de partajare.

In plus, codul este un mijloc de a atinge un scop. Actul creativ este ceea ce construiesti cu el, nu neaparat limbajul sau codul in sine, corect?

Adrian Popa: Da, si nu este considerat chiar o arta... poate de aceea nu este atat de controversat. Este informatica, este o stiinta.

McLaren Stanley: Corect, este informatica. Este o stiinta. Exista o creativitate in modul in care pui totul cap la cap, si sunt multi indivizi care au opinii foarte stricte legate de stilul si modul in care ar trebui sa construiesti. Insa, in cele din urma, noi rezolvam probleme pentru oameni. Acesta este rezultatul final pe care il urmarim.

Adrian Popa: Multi oameni, inclusiv eu, folosesc instrumentele de IA ca asistenti pentru redactarea de texte sau generarea de idei. Care este diferenta dintre a fi asistat de IA si a construi ceva de la zero folosind IA?

McLaren Stanley: Am observat mult acest aspect la inceput, cand instrumentele au devenit disponibile si le-am pus la dispozitia tuturor inginerilor nostri: "Mergeti si testati-le!". Am identificat un tipar foarte devreme. Oamenii care au inceput proiecte de la zero au avut o oportunitate mai buna de a-si configura intregul proces pentru a profita de IA. Acele echipe s-au descurcat considerabil mai bine decat cei care au incercat doar sa o ataseze la fluxul lor normal de lucru.

Tendinta naturala a oamenilor atunci cand primesc un instrument nou este sa inceapa sa construiasca software asa cum ar fi facut-o in mod normal si doar sa adauge IA pe alocuri pentru a vedea daca ii ajuta sa mearga mai repede. Si da, ii ajuta sa fie mai rapizi cu un anumit procent. Insa echipele care si-au facut timp sa isi regandeasca procesele si sa le reorganizeze au mers mult mai repede. Ei s-au intrebat: "Daca primesc un volum mai mare de modificari de cod intr-un timp mai scurt, cum schimba asta modul in care imi proiectez sistemul sau cum gestionez schimbarile de cod?".

Noi am numit asta "sa pornesti incet ca sa mergi repede". Echipele au avut nevoie de timp sa puna o scurta pauza pe sarcinile zilnice, sa inteleaga instrumentele si sa isi regandeasca modul de lucru. Echipele care au facut un pas inapoi si au adoptat o noua perspectiva au depasit rapid echipele care doar au continuat sa lucreze mecanic la lista lor veche de probleme, incercand doar sa obtina un ajutor iterativ de la IA. Cand am vazut acest tipar, ne-am intrebat cum putem extinde aceasta abordare: sa iti iei timp, sa regandesti sistemul, sa petreci o luna sau doua cunoscand uneltele si abia apoi sa aplici asta la modul de operare al echipei. Rezultatele sunt semnificativ mai bune.

Adrian Popa: Daca sunt inginer software si am castiguri atat de uriase de productivitate folosind IA, ce fac cu timpul meu la birou? Beau mai multe cafele? Fumez mai multe tigari?

McLaren Stanley: Multi dintre ei ajung sa faca mai multe lucruri in paralel. Ingineria software este o disciplina a blocajelor; adica astepti dupa compilator, faci o anumita modificare, o compilezi, vezi cum functioneaza. Cand termini un segment destul de mare dintr-o functionalitate, o trimiti altcuiva pentru revizuire. Intotdeauna au existat aceste blocaje in proces unde trebuia sa astepti ca acea persoana sa iti verifice codul, timp in care ea poate facea altceva. Asa ca asteptai putin, iar dupa ce iti dadea acordul, uneai codul si asteptai ca sistemul CI/CD sa ruleze si sa il lanseze. Procesul avea mereu un caracter asincron.

Acum ca am reusit sa acceleram procesul de scriere, programatorii pot paraleliza munca. Termini o unitate de lucru, trimiti revizuirea si te apuci de altceva. Ceea ce vedem mult acum este ca inginerii software pot gestiona mai multe sarcini concomitent. Daca lucrez la o anumita specificatie sau design, definitivez acea parte, pun agentii sa o construiasca si pot incepe deja sa lucrez la urmatoarea.

Asta inseamna ca echipele pot lucra in paralel mult mai eficient. Eu insumi am scris considerabil mai mult cod. Am scris mai mult cod anul trecut decat in tot restul carierei mele la Amazon la un loc. Pentru un inginer de nivel Senior Principal sau Lead, nu este un lucru obisnuit sa scrie cod non-stop, din cauza atributiilor de leadership tehnic: discutii de arhitectura, ghidarea altor echipe, dezvoltarea unei viziuni pe termen lung. Pentru mine, a fost o modalitate excelenta de a ma reconecta cu "materia prima" a acestei discipline, de a reveni la constructia de zi cu zi. Am continuat mereu sa scriu cod, dar pur si simplu nu mai aveai atat de mult timp pentru asta cum aveai la inceput, cand singurul tau rol era sa stai acolo, sa scrii cod si sa intelegi sarcinile primite. A fost minunat pentru reconectarea cu motivul initial pentru care am intrat in acest domeniu: voiam sa construiesc lucruri grozave, iar uneori toate acele alte obligatii stau in calea magiei pe care am simtit-o cand am creat prima mea aplicatie. Capacitatea de a face mai mult a fost o experienta excelenta pentru multi oameni.

Adrian Popa: Mai au dezvoltatorii juniori oportunitati de a lucra in companii mari daca IA le preia o parte din rol? Mai merita sa inveti programare astazi daca esti tanar?

McLaren Stanley: Da, cu siguranta! Amazon a avut intotdeauna o viziune pe termen lung asupra ingineriei software. Am considerat mereu ca investitia in urmatoarea generatie de ingineri merita pe deplin. Este un efort care merita pentru a ne asigura ca avem o noua generatie, deoarece nu stii niciodata care dintre absolventii de facultate va ajunge sa schimbe disciplina in viitor. Fiecare a inceput de undeva.

Exista un principiu de leadership la Amazon numit "Invata si fii curios". Inginerii juniori, proaspat iesiti de pe bancile facultatii si noi in acest domeniu, se afla permanent in aceasta stare de curatenie si invatare. Desigur, ai studiat in facultate, ai invatat cum se construieste un limbaj pentru a scrie un program si ai invatat teoria informaticii, dar cand te lovesti de realitatile practice ale ingineriei software, inveti mereu ceva complet nou.

Aceasta atitudine de deschidere si curiozitate este incredibil de necesara in lumea IA, deoarece multe dintre tiparele si procesele stabilite care erau considerate "bune practici" atunci cand am terminat eu facultatea se schimba acum. Faptul ca avem acesti ingineri mai noi, care aduc o perspectiva proaspata, care se simt confortabil folosind instrumentele si care sunt dispusi sa exploreze lucruri noi mult mai usor decat inginerii care sunt deja blocati in obiceiurile lor, este un avantaj urias.

Am constatat ca, daca luam acea energie si curiozitate de la inginerii juniori si o combinam cu expertiza oferita de inginerii cu experienta in sisteme distribuite sau dezvoltare de aplicatii, obtinem o combinatie minunata pentru echipa, beneficiind de ambele perspective. Si cred ca acest lucru va ramane valabil si in viitor.

Adrian Popa: Cand angajati personal tineri talentati, ce calitati cautati?

McLaren Stanley: Acel principiu, "Invata si fii curios", este absolut esential. La Amazon folosim principiile de leadership ca ghid pentru angajare, ca o modalitate de a vedea daca te vei integra bine in modul in care Amazon gandeste lumea. Curiozitatea este un factor urias, mai ales in acest moment.

Un alt principiu de leadership foarte important in acest moment in industrie este "Inclinatia spre actiune". Deoarece lucrurile se schimba atat de rapid, oamenii care se implica, exploreaza noile schimbari, dezvolta modalitati noi la care nimeni nu s-a gandit inainte sau descopera un tipar nou sunt, de cele mai multe ori, cei care actioneaza primii. Cei care testeaza acea idee noua au cel mai mare succes. Pe masura ce alti oameni vin mai tarziu si finiseaza aceste idei, de obicei inovatorii timpurii sunt cei care stabilesc cum va arata noul tipar. Acest lucru a fost valabil cu dezvoltarea bazata pe specificatii si cu alte concepte care au aparut; ele au venit de la ingineri care au vazut o problema specifica in modul in care IA construieste codul si au gasit o cale mai buna de a o rezolva. Acest tip de inclinatie spre actiune este critic atunci cand industria se schimba atat de repede.

Adrian Popa: In ce domenii ale unei companii precum Amazon este IA inca incapabila sa inlocuiasca lucratorii umani in prezent?

McLaren Stanley: In linii generale, discernamantul uman la nivel inalt este in continuare cea mai valoroasa resursa. Acesta este un aspect la care modelele de limbaj (LLM) nu sunt deloc bune, in mod masurabil. Ele sunt excelente la recunoasterea tiparelor si la sintetizarea informatiilor din seturi mari de date, asa cum discutam mai devreme. Sunt instrumente foarte bune pentru a-i ajuta pe oameni sa inteleaga deciziile care trebuie luate si pentru a aduna informatii, dar acea componenta unic umana de a putea lua decizii bazate pe un discernamant superior, odata ce informatiile sunt disponibile, este zona unde ne vom aduce valoarea in viitor. Si nu cred ca exista o cale previzibila in prezent in care acest lucru sa se schimbe.

Adrian Popa: Un pilot de avion de vanatoare a spus ceva similar acum cateva saptamani la un eveniment.

McLaren Stanley: Da, exact.

Adrian Popa: Si ultima intrebare. IA si-a dovedit clar utilitatea. Totusi, ca utilizator avansat, cu o intelegere profunda a tehnologiei, credeti ca exista o promovare excesiva in jurul IA sau predictiile despre expansiunea sa rapida sunt justificate?

McLaren Stanley: Ori de cate ori exista o schimbare industriala de o asemenea amploare, apare mereu un val de entuziasm, in special pentru una care a captivat imaginatia publicului larg. Imaginatia noastra era deja captivata de acest concept prin SF si cultura populara; ideea de IA exista cu mult inainte de aparitia modelelor generative de limbaj. Cred ca, uneori, acel element SF patrunde in discutiile tehnice sau in ciclul de promovare excesiva, alimentand ideea ca aceste tehnologii ne vor schimba complet vietile. Cu siguranta ne vor schimba vietile, dar va arata asta ca in reprezentarile SF sau ca SF-ul colectiv? Evident ca nu.

Trebuie sa privim aspectele practice a ceea ce poate face IA generativa - acest tip de potrivire complexa de tipare bazata pe tokenuri. Este aceasta calea catre AGI (Inteligenta Artificiala Generala)? Ce inseamna macar AGI? Aceste intrebari cu care ne confruntam sunt valoroase, dar cand auzi oameni spunand ca va inlocui complet mintile sclipitoare, acele descrieri fantastice nu reflecta realitatea a ceea ce pot face de fapt modelele de limbaj.

Este foarte important, din perspectiva tehnica, sa ramanem ancorati in realitate, deoarece oamenii au uneori tendinta de a le antropomorfiza (de a le da calitati umane), ceea ce nu este o abordare corecta. Daca antropomorfizezi rezultatul, pierzi controlul.

Exista doua tipuri de oameni: cei care folosesc LLM-urile pentru a-i ajuta sa gandeasca mai repede, mai bine si pentru a colecta informatii, si cei care isi externalizeaza gandirea catre LLM. Acestia din urma nu mai fac efortul de a colecta informatii si de a lua o decizie, ci doar intreaba IA: "Tu ce ai face?" si lasa totul in seama ei. Prima categorie reprezinta modul corect de a privi lucrurile: oameni care folosesc tehnologia pentru a-si imbunatati modul in care aduna informatii si pentru a lua decizii mai bune, dar care aplica in continuare discernamantul uman superior. Acestia au o intelegere mult mai realista a IA si a capacitatilor sale decat cei care adopta abordarea SF si cred ca IA va rezolva orice problema doar printr-o simpla conversatie.

Articolul EXCLUSIV | De la "muncitor pe santier" la "arhitect": Cum a transformat inteligenta artificiala rolul programatorului - interviu cu McLaren Stanley, Senior Principal Engineer la gigantul Amazon. De ce nu este tabu folosirea IA in codare? apare prima data in Go4IT.