EXCLUSIV | De la „muncitor pe șantier” la „arhitect”: Cum a transformat inteligența artificială rolul programatorului – interviu cu McLaren Stanley, Senior Principal Engineer la Amazon. De ce nu este tabu folosirea IA în codare?

Adaugă-ne ca sursă preferată în Google

Urmărește-ne in Discover

Rolul programatorului a evoluat de la simplu executant la arhitect de sistem, care deleagă scrierea codului către agenții de inteligență artificială (IA). Prin dezvoltarea bazată pe specificații (spec-driven development), procese de proiectare de câteva săptămâni sunt comprimate în discuții de doar 15 minute, iar numărul de lansări în producție al echipelor a crescut de 4,5 ori, a declarat McLaren Stanley, Senior Principal Engineer Amazon, într-un interviu exclusiv acordat Go4it.ro. Echipa sa utilizează soluții precum Kiro, un IDE (Integrated Development Environment) de programare bazat pe IA de tip agentic, pentru a moderniza bazele de cod iOS și Android ale aplicațiilor mobile ale Amazon, scrise în trecut în limbaje de programare care nu mai corespund cerințelor de astăzi.

Stanley a spus că, prin această nouă abordare, a scris anul trecut mai mult cod decât în întreaga carieră. „Eu unul am scris mult mai mult cod. Anul trecut am scris mai mult cod decât în tot restul carierei mele la Amazon la un loc”, a declarat inginerul, specializat în dezvoltarea de software bazat pe IA și arhitectura aplicațiilor mobile. El a lucrat în trecut pentru Microsoft, Uber și Twitter.

S-a vorbit mult despre faptul că inteligența artificială elimină oportunitățile pentru dezvoltatorii software juniori. Totuși, Stanley crede că aceștia încă mai sunt doriți în companii și că viitorul aparține inginerilor tineri curioși și orientați spre acțiune. Juniorii sunt căutați de companie deoarece vin fără prejudecăți și adoptă uneltele noi mult mai nativ, potrivit reprezentantului Amazon.

Stanley avertizează, în interviu, împotriva „antropomorfizării IA”, viziunea SF legată de tehnologie. Există două tipuri de utilizatori: cei care folosesc IA ca asistent pentru a colecta date și a gândi mai repede și cei care își „externalizează gândirea”. Doar primii vor avea succes, deoarece discernământul uman la nivel înalt rămâne de neînlocuit.

Redăm interviul integral acordat de McLaren Stanley pentru Go4it:

Adrian Popa: Dacă inteligența artificială scrie acum cea mai mare parte din cod, ce mai face de fapt programatorul astăzi? Putem spune că rolul s-a mutat de la un „muncitor de pe șantier” la un „arhitect” care supraveghează proiectul pentru un angajat digital?

McLaren Stanley: Cred că aceasta este, de fapt, o modalitate destul de bună de a caracteriza situația în multe cazuri. Dacă agentul este cel care scrie codul, calitatea codului sau a acelui rezultat depinde de cât de bine proiectezi sistemul pe care încerci să-l determini să-l construiască, corect? De aceea, folosim în special dezvoltarea bazată pe specificații (spec-driven development), care este o tehnică pe care am utilizat-o pe scară largă.

Ne petrecem cea mai mare parte a timpului în avans gândindu-ne la ce ar trebui să construim, cum ar trebui să funcționeze pe diferitele platforme și apoi construind și proiectând cerințele. Specificațiile și sarcinile efective pe care agentul le va executa ulterior — acolo ne petrecem cea mai mare parte a timpului acum.

Și, știți, disciplina ingineriei software este încă foarte implicată pentru că oamenii asigură calitatea rezultatului, se ocupă de orchestrarea necesară și au în continuare un rol foarte puternic, atât din punct de vedere operațional, cât și în situații care necesită un discernământ critic ridicat. Din această perspectivă, ingineria a devenit… este aproape ca o formă interesantă de eliberare, așa îmi place să-i spun, pentru că ajungem să ne petrecem mai mult timp făcând părțile creative ale muncii noastre și mai puțin timp luptându-ne cu îmbinarea codului (merging), gestionarea conflictelor de pe parcurs sau cu lucrurile mai banale din ingineria software în sensul unei companii moderne.

Astfel, am petrecut considerabil mai mult timp anul acesta construind și proiectând efectiv sisteme decât aș fi făcut-o altfel fără IA, pur și simplu pentru că elimină o mare parte din efortul administrativ din proces.

Adrian Popa: Cum i-ați explica cuiva fără un background tehnic cum arată o zi tipică într-un scenariu de dezvoltare bazată pe specificații? Cum funcționează această interacțiune în practică, unde o persoană definește regulile, iar IA construiește aplicația în sine? Cum este o astfel de zi pentru un programator care lucrează așa?

McLaren Stanley: O zi de lucru… o mare parte din toate astea este destul de interesantă. Dezvoltarea bazată pe specificații a fost extrem de colaborativă pentru noi. Înainte să apară IA, dura destul de mult să scrii manual planurile de proiectare, să îți dai seama exact cum vom construi o funcționalitate pentru iOS sau Android. Apoi, cineva petrecea mult timp scriind acel document de proiectare, iar după câteva zile, câteva iterații sau chiar săptămâni, îl revizuiam. Făceam modificări, spuneam: „Nu e grozav, acum mergi înapoi la tablă sau începe lucrul” și așa mai departe. Deci se consuma mult timp cu acest tip de muncă asincronă în avans pentru investigații și proiectare.

Acum, de când o mare parte din acea muncă de proiectare a fost compactată, constatăm că procesul este extrem de colaborativ. În loc ca oamenii să plece și să lucreze separat, de multe ori adunăm în aceeași cameră un designer, un manager de produs și inginerul de Android/iOS, ne așezăm cu agentul Kiro și pur și simplu descriem ceea ce încercăm să începem să construim. Devine un fel de exercițiu de lucru în pereche.

Iar acel interval care dura câteva săptămâni este acum comprimat într-o discuție rapidă de 15 minute sau o oră. Decidem ce să construim, iar apoi punem agenții să treacă la treabă. Deoarece procesul este atât de comprimat, devine extrem de iterativ. Mergem, construim, obținem poate un prototip, ajungem la jumătatea implementării și spunem: „Ah, poate nu asta ne doream, hai să ne întoarcem la planul inițial și să o facem din nou”.

Pentru că investiția de timp în producerea acelor artefacte intermediare este mult mai mică, a fost cu adevărat grozav, deoarece oamenii se atașează mai puțin de ideile proaste. Poți pur și simplu să iterezi mai repede. Vezi că o idee nu a funcționat prea bine? Nicio problemă, o arunci și încerci alta. Ne place foarte mult acest mediu extrem de colaborativ care se creează și rapiditatea cu care poți transforma ideile în realitate.

Adrian Popa: Poate, pentru un context complet, ne puteți spune despre echipa dumneavoastră și ce face mai exact, ca să înțelegem ce înseamnă 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 aplicațiile principale de cumpărături Amazon există și ele de multă vreme. Ceea ce am făcut noi cu Kiro a fost să modernizăm agresiv baza de cod. Există câteva efecte interesante în dezvoltarea bazată pe agenți: limbajele moderne de programare — cele care sunt type-safe, thread-safe și memory-safe — sunt mult mai sigure și mai bune de utilizat cu agenții de codare.

Dacă compilatorul poate impune aceste constrângeri, agentul primește un răspuns mai clar dacă soluția generată de el funcționează sau nu. De fiecare dată când primești un feedback mai bun de la compilator, obții iterații mai bune și rezultate remarcabil de sigure, foarte similare cu modul în care ai fi făcut-o manual ca dezvoltator uman.

Prin urmare, am demarat un efort de modernizare a bazelor de cod pentru Android și iOS cu aceste limbaje mai moderne, deoarece în prezent ele sunt scrise în limbaje mai vechi. Objective-C, de exemplu, nu era thread-safe, memory-safe sau type-safe la momentul compilării; folosea verificări în timpul rulării (runtime) pentru toate acestea. Așa că am depus un efort mare pentru a le moderniza.

Un alt lucru care a fost foarte eficient pentru noi este că, atunci când definim specificațiile funcționalităților pe care le construim — fie că le facem prin inginerie inversă din funcționalități mai vechi, fie că adăugăm unele noi —, putem lua cerințele de business ale aplicației (ceea ce face ea, capabilitățile dorite, chiar și schițe de pe tablă sau fișiere de design), le punem cap la cap și generăm o specificație care spune: „Iată cum se vor comporta aceste funcționalități”.

Apoi generăm concomitent codul pentru iOS și Android. Acest lucru este excelent pentru noi deoarece, atunci când oamenii construiau separat pe ambele platforme, ne chinuiam mereu să le menținem sincronizate. În funcție de piața pe care activai, echipa care construia funcționalitatea putea fi mai interesată de versiunea de Android sau de cea de iOS, în funcție de unde se aflau clienții lor. De multe ori construiau o funcționalitate pentru Android și poate nu o mai făceau pentru iPhone. Am avut această problemă de-a lungul anilor, cea de a menține funcționalitățile sincronizate.

De aceea, mizăm foarte mult pe această metodologie. Acest proces va face dezvoltarea pe mobile mult mai consecventă și mai ușoară, deoarece îmi pot transpune expertiza de iOS în directivele pe care agentul le folosește pentru a construi funcționalitatea. Inginerul de Android poate face același lucru. Iar alți ingineri, care nu sunt la fel de familiarizați cu subtilitățile platformei, își pot lua cerințele de business și pot dezvolta cod de o calitate la fel de bună pe fiecare platformă, deoarece am reușit să instruim, să ghidăm și să configurăm procesul astfel încât să producă răspunsuri bune pe ambele părți.

Adrian Popa: Ați menționat obținerea unor câștiguri semnificative de productivitate prin această metodă, unele echipe lucrând mult mai rapid. Mai exact, ce înseamnă această economie de timp pentru clienții care au aplicația Amazon pe telefoanele lor?

McLaren Stanley: Voi vorbi în sens mai larg despre productivitatea magazinelor în general, deoarece proiectul pentru aplicație este încă în desfășurare și vom vedea rezultatele finale în viitor. Însă am realizat un proiect pilot în cadrul magazinelor noastre, pe o mulțime de tehnologii diferite, și am evaluat acele echipe comparativ cu propria lor rată de lansare în producție.

Motivul pentru care am făcut asta este că la Amazon există foarte multe echipe de inginerie diferite, cu stiluri, tehnici și platforme diferite pentru care construiesc. Le-am configurat sistemul și apoi am măsurat cât de des trimiteau codul în producție. Am constatat că, în medie, în rândul echipelor din proiectul pilot care au încercat această abordare de dezvoltare nativă cu IA, numărul de lansări în producție a crescut de 4,5 ori în acea perioadă de testare.

Acest lucru creează un ciclu de inovare extraordinar, deoarece putem testa idei considerabil mai rapid. În proiectul nostru de modernizare, acest lucru ajută la stabilitate și la adoptarea mai rapidă a noilor funcționalități. În plus, simplul fapt de a reduce durata ciclului de dezvoltare și de a avea capacitatea de a itera contează enorm. Există atât de multe idei, iar multe dintre aceste echipe au liste uriașe de sarcini (backlogs) de care nu s-au putut atinge niciodată din cauza timpului, a priorităților sau a volumului de muncă. Acum, rentabilitatea investiției (ROI) pentru rezolvarea acelor probleme s-a schimbat atât de mult încât pot realiza mult mai multe lucruri.

Asta înseamnă o securitate mai bună și o funcționalitate superioară. Un exemplu excelent este accesibilitatea pentru persoanele care folosesc un cititor de ecran. Inginerul meu de accesibilitate poate introduce expertiza profundă de Android, iOS și web în acest proces. Echipele obișnuite — din sutele de echipe și mii de ingineri care construiesc funcționalități pentru experiența de retail a magazinelor — nu au neapărat aceste abilități extrem de specializate pe fiecare platformă în parte. Sunt echipe mici. Însă odată ce am integrat acea expertiză în sistem, acum putem gestiona nevoile clienților noștri care folosesc cititoare de ecran sau alte funcții de accesibilitate mult mai consecvent și mai rapid, la nivelul întregii companii.

Adrian Popa: Și afectează acest lucru în vreun fel prețurile produselor vândute în aplicație? Mă refer pe termen lung, dacă sunteți mai eficienți și aveți un produs mai bun.

McLaren Stanley: În mod general vorbind, da. Întregul model de afaceri al Amazon este de a transfera eficiența noastră către clienți sub forma unor prețuri mai bune. Dar, dincolo de asta, a rămas o mulțime de lucruri uimitoare de făcut care acum pot fi realizate, oferind mai multă valoare clienților noștri pe toate nivelurile sistemului.

Adrian Popa: Care este procesul de rezolvare a erorilor majore atunci când codul generat eșuează?

McLaren Stanley: Vă referiți la o eroare, la o greșeală? Cheia pentru ca dezvoltarea cu IA să funcționeze cu succes este să îți configurezi întregul flux de lucru și tot ciclul de viață al dezvoltării software pentru a profita de ea. Nu este vorba doar de scrierea codului, ci de cât de sigur îmbinăm și testăm acel cod.

Înainte, când aveai o echipă mică ce scria cod manual, membrii ei puteau să își automatizeze o parte din teste sau să ruleze un test de control al calității (QA) pentru a se asigura că funcționalitatea e în regulă. Acum, din cauza volumului și a vitezei cu care se lucrează, trebuie să acordăm mai multă atenție asigurării unei testări foarte solide. Adică să ai suite de teste automate cu acoperire completă care rulează la fiecare salvare, pentru a te asigura că agentul nu introduce cod care să spargă sistemul. Înainte puteai folosi oameni și echipe de QA care să monitorizeze asta în timp; acum am descoperit că avem nevoie de o infrastructură de testare mult mai robustă.

De asemenea, avem nevoie de o modalitate de a implementa aceste modificări mai în siguranță, deoarece vin mult mai multe schimbări și există riscul de a apărea conflicte dacă foarte mulți agenți lucrează în aceeași bază de cod. Acest lucru ne-a obligat cu adevărat să regândim modul în care codul circulă de la computerul dezvoltatorului până la utilizatorul final și să adăugăm măsuri de siguranță suplimentare, testare și instrumente de verificare a calității codului. Folosim aceste bariere pentru a ne asigura că agentul face ceea ce trebuie și nu poate face ceva ce nu ar trebui.

Pe de altă parte, când apare o problemă, poți folosi tot agentul pentru a o analiza. De cele mai multe ori, deoarece agenții sunt foarte buni la recunoașterea tiparelor, dacă există o eroare, o prăbușire a aplicației sau o urmă a stivei de execuție, o trimiți agentului și acesta poate depista cauza inițială și diagnostica problema considerabil mai rapid decât oamenii. Poate analiza rapid un index uriaș al tuturor segmentelor de cod care ar putea avea o problemă și o poate localiza imediat. Înainte de a avea acești agenți era nevoie ca cineva să reproducă problema, ca un inginer să citească tot codul sau să analizeze fișierele de jurnal pentru a descoperi unde s-a greșit. Acum, având agenții ca instrumente, aceștia pot analiza volume mari de date extrem de repede și pot identifica sursa problemei mult mai repede.

Adrian Popa: Când IA scrie cod la scara Amazon, nu se pierde memoria tehnică instituțională? Dacă un sistem complex generat de IA se strică peste cinci ani, iar inginerii care au ghidat acele comenzi au plecat din companie, cât de greu îi va fi unui inginer uman să facă inginerie inversă pe tehnologia generată de IA?

McLaren Stanley: Aceasta este o întrebare excelentă. Aici intervine frumusețea dezvoltării bazate pe specificații. Există multe tehnici diferite în prezent prin care oamenii construiesc software cu ajutorul agenților, dar ceea ce diferențiază Kiro este structura modului în care construiești lucrurile. Aceasta creează un istoric al deciziilor tale de business prin intermediul specificațiilor: „Iată cerințele pentru care am construit această funcționalitate și iată designul software propriu-zis”. Sistemul corelează cerințele cu faza de proiectare și testare, explicând în limbaj natural decizia de business care a fost luată acolo.

Noi salvăm acele fișiere în sistem; ele rămân alături de codul generat. Echipa mea face asta — deși unele echipe au fluxuri de lucru diferite —, salvăm aceste date pentru a avea o evidență a deciziei. Acest lucru este excelent din nou pentru problema Android/iOS: dacă creez ceva pentru o platformă, am dovada scrisă a motivului pentru care am făcut-o în acel mod specific, iar apoi o pot rula pe cealaltă platformă. Pe termen lung, avem o evidență a acelei decizii.

Pe de altă parte, am realizat rapid că cea mai mare parte a codului nostru actual provine dintr-o perioadă în care a fost scris de oameni și se confruntă exact cu aceeași problemă: persoana respectivă a plecat, codul a fost scris acum 10 ani și nimeni nu știe exact ce face. De aceea, am construit un instrument folosind agenți din Amazon Bedrock numit Spec Studio. Acesta scanează bazele de cod existente și extrage prin inginerie inversă cerințele de business din codul actual. Analizează un pachet sau un grup de pachete de cod și explică ce face acea logică de programare. Ba mai mult, dacă acel pachet nu avea documentație (pentru că inginerul respectiv a considerat că nu are nevoie sau a uitat să o scrie), instrumentul va genera documentația pentru dezvoltatori.

Și face acest lucru cu o acuratețe destul de bună. În timp, folosim acel agent pentru a genera documentația și a înregistra deciziile luate. Poate nu îți va spune de ce au fost luate acele decizii, dar măcar îți spune ce decizie s-a luat. Iar asta le permite oamenilor să înțeleagă mult mai ușor ce se întâmplă în sistemele complexe la scară Enterprise. La o scară precum cea a Amazon, chiar dacă știi ce faci, poate fi foarte greu să înțelegi exact ce s-a întâmplat pe o porțiune mare din baza de cod. Mi se întâmplă chiar și mie, cu codul scris de mine: „De ce am făcut asta? Nu îmi mai aduc aminte, unde era linia asta sau ce fișier cu simboluri trebuie să caut?”. Faptul că agentul construiește acea evidență structurală le ușurează tuturor înțelegerea sistemului.

Adrian Popa: Ce limbaje de programare folosesc agenții dumneavoastră?

McLaren Stanley: În cazul nostru, am trecut în întregime la Swift pentru iOS și Kotlin pentru Android. Am făcut asta special datorită caracteristicilor lor de siguranță (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 și a devenit standardul pentru dezvoltarea iOS în prezent, ajutându-ne în acest efort de modernizare.

Există și alte tipare pe care agentul le preia foarte bine, dar în general, Swift are o comunitate open-source activă. Asta înseamnă că modelul a avut acces și a fost antrenat pe volume uriașe de date despre Swift. Modelele vor ști nativ cum să gestioneze foarte bine limbajele care sunt deschise, disponibile și utilizate pe scară largă. Dacă ai un limbaj intern proprietar, modelele nu se vor descurca nici pe departe la fel de bine ca în cazul celor open-source care au o mulțime de exemple de cod pe internet. Astfel, cu măsurile de siguranță adecvate, agenții se descurcă mult mai bine cu limbajele utilizate pe scară largă și care au un volum mare de cod open-source disponibil.

Adrian Popa: În unele domenii, cum ar fi apărarea, dar și în meseria mea, cum ar fi scrierea de articole jurnalistice sau texte literare, utilizarea IA rămâne controversată. De ce nu este cazul și în programare, unde utilizarea ei este încurajată activ?

McLaren Stanley: Conceptul de open-source este un răspuns bun și pentru această întrebare. Ingineria software își are multe dintre rădăcini în această idee de open-source, unde construim pe baza a ceea ce s-a realizat deja. Linux și toate celelalte platforme open-source majore își partajează codul pentru ca oamenii să îl poată construi, schimba și modifica. Acea comunitate open-source a creat deja un efect de colaborare.

IA a putut profita de acest lucru. Dar, în plus, creativitatea în ingineria software vine din capacitatea de a aduna acele tipare existente în soluții unice pentru a rezolva problemele clienților, chiar dacă altcineva a scris acea librărie inițială. Cred că ingineria software a fost perfectă pentru asta deoarece noi deja împărtășeam, reutilizam și contribuiam la eforturi colective de acest gen. Ca disciplină, am fost mai deschiși la acest tip de partajare.

În plus, codul este un mijloc de a atinge un scop. Actul creativ este ceea ce construiești cu el, nu neapărat limbajul sau codul în sine, corect?

Adrian Popa: Da, și nu este considerat chiar o artă… poate de aceea nu este atât de controversat. Este informatică, este o știință.

McLaren Stanley: Corect, este informatică. Este o știință. Există o creativitate în modul în care pui totul cap la cap, și sunt mulți indivizi care au opinii foarte stricte legate de stilul și modul în care ar trebui să construiești. Însă, în cele din urmă, noi rezolvăm probleme pentru oameni. Acesta este rezultatul final pe care îl urmărim.

Adrian Popa: Mulți oameni, inclusiv eu, folosesc instrumentele de IA ca asistenți pentru redactarea de texte sau generarea de idei. Care este diferența dintre a fi asistat de IA și a construi ceva de la zero folosind IA?

McLaren Stanley: Am observat mult acest aspect la început, când instrumentele au devenit disponibile și le-am pus la dispoziția tuturor inginerilor noștri: „Mergeți și testați-le!”. Am identificat un tipar foarte devreme. Oamenii care au început proiecte de la zero au avut o oportunitate mai bună de a-și configura întregul proces pentru a profita de IA. Acele echipe s-au descurcat considerabil mai bine decât cei care au încercat doar să o atașeze la fluxul lor normal de lucru.

Tendința naturală a oamenilor atunci când primesc un instrument nou este să înceapă să construiască software așa cum ar fi făcut-o în mod normal și doar să adauge IA pe alocuri pentru a vedea dacă îi ajută să meargă mai repede. Și da, îi ajuta să fie mai rapizi cu un anumit procent. Însă echipele care și-au făcut timp să își regândească procesele și să le reorganizeze au mers mult mai repede. Ei s-au întrebat: „Dacă primesc un volum mai mare de modificări de cod într-un timp mai scurt, cum schimbă asta modul în care îmi proiectez sistemul sau cum gestionez schimbările de cod?”.

Noi am numit asta „să pornești încet ca să mergi repede”. Echipele au avut nevoie de timp să pună o scurtă pauză pe sarcinile zilnice, să înțeleagă instrumentele și să își regândească modul de lucru. Echipele care au făcut un pas înapoi și au adoptat o nouă perspectivă au depășit rapid echipele care doar au continuat să lucreze mecanic la lista lor veche de probleme, încercând doar să obțină un ajutor iterativ de la IA. Când am văzut acest tipar, ne-am întrebat cum putem extinde această abordare: să îți iei timp, să regândești sistemul, să petreci o lună sau două cunoscând uneltele și abia apoi să aplici asta la modul de operare al echipei. Rezultatele sunt semnificativ mai bune.

Adrian Popa: Dacă sunt inginer software și am câștiguri atât de uriașe de productivitate folosind IA, ce fac cu timpul meu la birou? Beau mai multe cafele? Fumez mai multe țigări?

McLaren Stanley: Mulți dintre ei ajung să facă mai multe lucruri în paralel. Ingineria software este o disciplină a blocajelor; adică aștepți după compilator, faci o anumită modificare, o compilezi, vezi cum funcționează. Când termini un segment destul de mare dintr-o funcționalitate, o trimiți altcuiva pentru revizuire. Întotdeauna au existat aceste blocaje în proces unde trebuia să aștepți ca acea persoană să îți verifice codul, timp în care ea poate făcea altceva. Așa că așteptai puțin, iar după ce îți dădea acordul, uneai codul și așteptai ca sistemul CI/CD să ruleze și să îl lanseze. Procesul avea mereu un caracter asincron.

Acum că am reușit să accelerăm procesul de scriere, programatorii pot paraleliza munca. Termini o unitate de lucru, trimiți revizuirea și te apuci de altceva. Ceea ce vedem mult acum este că inginerii software pot gestiona mai multe sarcini concomitent. Dacă lucrez la o anumită specificație sau design, definitivez acea parte, pun agenții să o construiască și pot începe deja să lucrez la următoarea.

Asta înseamnă că echipele pot lucra în paralel mult mai eficient. Eu însumi am scris considerabil mai mult cod. Am scris mai mult cod anul trecut decât în tot restul carierei mele la Amazon la un loc. Pentru un inginer de nivel Senior Principal sau Lead, nu este un lucru obișnuit să scrie cod non-stop, din cauza atribuțiilor de leadership tehnic: discuții de arhitectură, ghidarea altor echipe, dezvoltarea unei viziuni pe termen lung. Pentru mine, a fost o modalitate excelentă de a mă reconecta cu „materia primă” a acestei discipline, de a reveni la construcția de zi cu zi. Am continuat mereu să scriu cod, dar pur și simplu nu mai aveai atât de mult timp pentru asta cum aveai la început, când singurul tău rol era să stai acolo, să scrii cod și să înțelegi sarcinile primite. A fost minunat pentru reconectarea cu motivul inițial pentru care am intrat în acest domeniu: voiam să construiesc lucruri grozave, iar uneori toate acele alte obligații stau în calea magiei pe care am simțit-o când am creat prima mea aplicație. Capacitatea de a face mai mult a fost o experiență excelentă pentru mulți oameni.

Adrian Popa: Mai au dezvoltatorii juniori oportunități de a lucra în companii mari dacă IA le preia o parte din rol? Mai merită să înveți programare astăzi dacă ești tânăr?

McLaren Stanley: Da, cu siguranță! Amazon a avut întotdeauna o viziune pe termen lung asupra ingineriei software. Am considerat mereu că investiția în următoarea generație de ingineri merită pe deplin. Este un efort care merită pentru a ne asigura că avem o nouă generație, deoarece nu știi niciodată care dintre absolvenții de facultate va ajunge să schimbe disciplina în viitor. Fiecare a început de undeva.

Există un principiu de leadership la Amazon numit „Învață și fii curios”. Inginerii juniori, proaspăt ieșiți de pe băncile facultății și noi în acest domeniu, se află permanent în această stare de curățenie și învățare. Desigur, ai studiat în facultate, ai învățat cum se construiește un limbaj pentru a scrie un program și ai învățat teoria informaticii, dar când te lovești de realitățile practice ale ingineriei software, înveți mereu ceva complet nou.

Această atitudine de deschidere și curiozitate este incredibil de necesară în lumea IA, deoarece multe dintre tiparele și procesele stabilite care erau considerate „bune practici” atunci când am terminat eu facultatea se schimbă acum. Faptul că avem acești ingineri mai noi, care aduc o perspectivă proaspătă, care se simt confortabil folosind instrumentele și care sunt dispuși să exploreze lucruri noi mult mai ușor decât inginerii care sunt deja blocați în obiceiurile lor, este un avantaj uriaș.

Am constatat că, dacă luăm acea energie și curiozitate de la inginerii juniori și o combinăm cu expertiza oferită de inginerii cu experiență în sisteme distribuite sau dezvoltare de aplicații, obținem o combinație minunată pentru echipă, beneficiind de ambele perspective. Și cred că acest lucru va rămâne valabil și în viitor.

Adrian Popa: Când angajați personal tineri talentați, ce calități căutați?

McLaren Stanley: Acel principiu, „Învață și fii curios”, este absolut esențial. La Amazon folosim principiile de leadership ca ghid pentru angajare, ca o modalitate de a vedea dacă te vei integra bine în modul în care Amazon gândește lumea. Curiozitatea este un factor uriaș, mai ales în acest moment.

Un alt principiu de leadership foarte important în acest moment în industrie este „Înclinația spre acțiune”. Deoarece lucrurile se schimbă atât de rapid, oamenii care se implică, explorează noile schimbări, dezvoltă modalități noi la care nimeni nu s-a gândit înainte sau descoperă un tipar nou sunt, de cele mai multe ori, cei care acționează primii. Cei care testează acea idee nouă au cel mai mare succes. Pe măsură ce alți oameni vin mai târziu și finisează aceste idei, de obicei inovatorii timpurii sunt cei care stabilesc cum va arăta noul tipar. Acest lucru a fost valabil cu dezvoltarea bazată pe specificații și cu alte concepte care au apărut; ele au venit de la ingineri care au văzut o problemă specifică în modul în care IA construiește codul și au găsit o cale mai bună de a o rezolva. Acest tip de înclinație spre acțiune este critic atunci când industria se schimbă atât de repede.

Adrian Popa: În ce domenii ale unei companii precum Amazon este IA încă incapabilă să înlocuiască lucrătorii umani în prezent?

McLaren Stanley: În linii generale, discernământul uman la nivel înalt este în continuare cea mai valoroasă resursă. Acesta este un aspect la care modelele de limbaj (LLM) nu sunt deloc bune, în mod măsurabil. Ele sunt excelente la recunoașterea tiparelor și la sintetizarea informațiilor din seturi mari de date, așa cum discutam mai devreme. Sunt instrumente foarte bune pentru a-i ajuta pe oameni să înțeleagă deciziile care trebuie luate și pentru a aduna informații, dar acea componentă unic umană de a putea lua decizii bazate pe un discernământ superior, odată ce informațiile sunt disponibile, este zona unde ne vom aduce valoarea în viitor. Și nu cred că există o cale previzibilă în prezent în care acest lucru să se schimbe.

Adrian Popa: Un pilot de avion de vânătoare a spus ceva similar acum câteva săptămâni la un eveniment.

McLaren Stanley: Da, exact.

Adrian Popa: Și ultima întrebare. IA și-a dovedit clar utilitatea. Totuși, ca utilizator avansat, cu o înțelegere profundă a tehnologiei, credeți că există o promovare excesivă în jurul IA sau predicțiile despre expansiunea sa rapidă sunt justificate?

McLaren Stanley: Ori de câte ori există o schimbare industrială de o asemenea amploare, apare mereu un val de entuziasm, în special pentru una care a captivat imaginația publicului larg. Imaginația noastră era deja captivată de acest concept prin SF și cultura populară; ideea de IA exista cu mult înainte de apariția modelelor generative de limbaj. Cred că, uneori, acel element SF pătrunde în discuțiile tehnice sau în ciclul de promovare excesivă, alimentând ideea că aceste tehnologii ne vor schimba complet viețile. Cu siguranță ne vor schimba viețile, dar va arăta asta ca în reprezentările SF sau ca SF-ul colectiv? Evident că nu.

Trebuie să privim aspectele practice a ceea ce poate face IA generativă — acest tip de potrivire complexă de tipare bazată pe tokenuri. Este aceasta calea către AGI (Inteligența Artificială Generală)? Ce înseamnă măcar AGI? Aceste întrebări cu care ne confruntăm sunt valoroase, dar când auzi oameni spunând că va înlocui complet mințile sclipitoare, acele descrieri fantastice nu reflectă realitatea a ceea ce pot face de fapt modelele de limbaj.

Este foarte important, din perspectivă tehnică, să rămânem ancorați în realitate, deoarece oamenii au uneori tendința de a le antropomorfiza (de a le da calități umane), ceea ce nu este o abordare corectă. Dacă antropomorfizezi rezultatul, pierzi controlul.

Există două tipuri de oameni: cei care folosesc LLM-urile pentru a-i ajuta să gândească mai repede, mai bine și pentru a colecta informații, și cei care își externalizează gândirea către LLM. Aceștia din urmă nu mai fac efortul de a colecta informații și de a lua o decizie, ci doar întreabă IA: „Tu ce ai face?” și lasă totul în seama ei. Prima categorie reprezintă modul corect de a privi lucrurile: oameni care folosesc tehnologia pentru a-și îmbunătăți modul în care adună informații și pentru a lua decizii mai bune, dar care aplică în continuare discernământul uman superior. Aceștia au o înțelegere mult mai realistă a IA și a capacităților sale decât cei care adoptă abordarea SF și cred că IA va rezolva orice problemă doar printr-o simplă conversație.