Complexitatea adăugată de IA schimbă atât modul în care se dezvoltă aplicațiile, cât și dinamica piețe. Am acoperit o mică parte din acest subiect alături de invitații noștri la panelul de discuții:
Alex Popescu - Solutions Architect @ msg systems Romania,
Cosmin Sandu - System Architect & Java Tech Lead @ P3,
Alexandru Ilieș: Am terminat și eu UTCN-ul în 2016 și de atunci sunt developer la MSG. Am lucrat în fel de fel de proiecte și tehnologii. În ultimii ani, m-am axat pe tehnologii cloud, iar, în ultimii trei ani, cum a zis și Alex, am folosit diverse tooluri și automatizări cu IA. Eu mi-am făcut un obicei de vreo lună. În fiecare zi scriu un exercițiu de cod, pentru că s-ar putea peste doi-trei ani să avem o surpriză așa mai interesantă...
Cosmin Sandu: Eu am terminat Informatică la UBB în 2002. La început, am fost extrem de tânăr și neliniștit. Am schimbat foarte multe tehnologii, companii, pentru că aveam așa o dorință de a mă tot metamorfoza și a tot învăța câte ceva nou. Mă plictiseam repede într-un loc. Acum am mai încărunțit și lucrez la P3 de opt ani.
Alex, tu spuneai la un moment dat în prezentarea ta, dacă nu mă înșel, că nu mai avem nevoie de atâția programatori. Până acum, noi nu realizam lucruri din cauză că eram limitați de timp, de echipe, de resurse și așa mai departe. Acum este, în sfârșit, momentul în care putem să ne facem proiectele, să le implementăm. Din perspectiva aceasta, s-ar putea de fapt să apară de 100 de ori mai multe proiecte decât erau până acum. Lumea și-a dat seama că proiectele se pot face mult mai rapid. Nu știu dacă și mai ieftin. Cum comentezi acest aspect?
Alex Popescu: Da, așa sper și eu. Să ai dreptate tu, și nu eu. Ce spuneam în articol este că, la un moment dat, acest lucru va deveni noua normă. Va trebui să livrezi fie multe aplicații, fie una singură, dar repede. Va trebui să facem două, trei, cinci taskuri în paralel.
Cred că visez la o aplicație TSM de 10 ani, pe care acum, în sfârșit, o pot face. Îți dă foarte multe aripi. În loc să lucrăm mai puțin, eu văd exact opusul. Lucrăm mult mai mult și suntem mult mai conectați. În momentul în care ajung să mă dau cu bicicleta mă bucur că uite, în sfârșit, mă dau cu bicicleta și iau o pauză de la toți agenții.
Alex Popescu: Da, așa e. Se poate ajunge la un soi de dependență! Când ai, de exemplu, cinci agenți, cărora le dai de lucru, pe care trebuie să-i coordonezi și să le fii un soi de manager. Eu sper să se compenseze rapiditatea printr-un volum mai mare. Atunci vom avea cu toții de muncă.
Probabil că vor apărea multe firme mici, se va mai fragmenta piața și toată lumea poate face prompting.
Alex Popescu: Era o carte din seria Strategic Architecture. Acum, noi suntem în zona de Vibe Coding sau Intent-Driven Development. Este un fel de Strategic Development. Intent Development înseamnă că tu spui ce dorești, IA construiește, iar tu nu te uiți înăuntru. E un black box.
Avantajul este că noi, oamenii, înțelegem foarte mult context adiacent. În timp ce IA nu înțelege.
Alexandru Ilieș: Oricine, tehnic sau non-tehnic, poate face o aplicație mică, personală. Problema, pentru noi, developerii, va apărea într-un sistem complex care necesită o mentenanță de 10-20 de ani. Cine va face mentenanță după 10 ani? Probabil că, dacă nu vor fi oameni care să poată face mentenanță, nu vor mai exista nici sistemele acelea după 10 ani. Prin urmare, contextul global al sistemelor respective trebuie să persiste în mințile oamenilor.
Cosmin, tu ce părere ai? Ce se va întâmpla peste 10 ani? Vor necesita mentenanță bordurile de mașină și softul?
Cosmin Sandu: Nu cred. Mi se pare că totul se accelerează. În trecut, îmi era aproape imposibil să sper că pot să mă apuc să fac un proiect personal. Acum, cu IA este destul de simplu, ceea ce va lăsa loc pentru multă inovație pentru viitor. Dar e important să canalizezi creativitatea pe o anumită direcție. Nu va fi niciodată o înlocuire totală a omului. Va fi nevoie de o oarecare sinergie. Pe de o parte, am câștigat o anumită libertate, pentru că pot să experimentez mai repede anumite idei. Pe de altă parte, trebuie să ai cunoștințe și baze foarte solide, tehnice, pentru că, altfel, pur și simplu nu poți să ții lucrurile sub control. Cred că pentru o aplicație simplă, ți se va genera rapid aplicația. Dacă este o aplicație complexă, tu trebuie să deții cumva controlul.
Dacă mergem pe ideea de control, ce sfaturi ai da ca să ții o aplicație sub control?
Cosmin Sandu: În primul rând, să îți fie clar ce dorești să ai. Dacă îmi schimb ideile de astăzi pe mâine, evident că o să fac o harcea-parcea din proiectul respectiv. Generând repede cod, va aplica repede și orice idee proastă. Este ca și când nu știi să conduci, dar mergi cu un Bugatti cu 300 km/h. În al doilea rând, este bine că te prinzi tu repede ce nu funcționează. Poate nu te prinzi de azi pe mâine. Poate te prinzi după foarte mult timp, iar atunci nu mai știi pe unde vrei sau poți să ieși.
Da. Aici cred că intervine frameworkul: să ai teste, să ai specificații, să ai procese pentru a prinde problemele.
Cosmin Sandu: Da. Eu mă refer la aplicații distribuite, să zicem, unde ai mai multe git repository-uri, ai microservicii, iar ele trebuie să se integreze. Anumite integrări pot aduce un breaking change.
Crezi că testăm aplicațiile mai mult ca oricând? Mi se pare că testez foarte mult sau că pierd timpul cu asta. N-am încredere tot timpul că dacă IA a făcut ceva, nu a stricat în altă parte.
Cosmin Sandu: Cred că cel mai mare risc al folosirii IA, dată fiind viteza foarte mare, este să produci calitate proastă inclusiv în partea de testare. Dacă IA îmi generează code coverage, eu nu am garanția că testele acelea chiar au întotdeauna sens. Mi-e ușor să fiu tentat să fiu leneș. Ești tentat să nu mai faci un review de calitate și, practic, ai o falsă siguranță, la fel cum poți avea o falsă siguranță că implementarea este corectă, până la proba contrarie.
Am observat că IA este foarte bun la citit loguri. Îți găsește rapid problema. Am avut la The Developers probleme de performanță și mici probleme cu streamul. IA nu îți găsește problemele de performanță. Mie nu mi le-a găsit. Nu știu voi ce experiență aveți aici.
Alex Popescu: Este o temă interesantă și am avut discuția asta anul trecut la altă ediție TSM. Este un lucru care, de obicei, ne doare. Problema cu IA-ul este că nu găsește ce i-ai cerut, dacă nu i-ai dat toolul cu care să analizeze. Spre exemplu, articolul de anul trecut era despre Java și cum faci profiling pe Java. Sunt deja MCP-uri pe profiling, IA se conectează la ele și face analiza ca și cum ai face-o tu analiza. Te costă, nu este ieftin, dar face ce i-ai cerut.
Alexandru Ilieș: Nu mai vorbim de Vibe Coding, ci de Software Prompting. Pentru mine, Vibe Coding este persoana care nu cunoaște fundamentele unui software sau nu are cunoștințe tehnice, dar face o aplicație. Din prompt zic că vreau aplicația X să facă Y. De unde știe persoana respectivă că există profiling și că poate fi folosit?
Ce recomandări ai în momentul în care ai un proiect complex și vrei ca tot codul să fie în limitele stabilite de tine. Ce opțiune ai? Ce faci de obicei?
Alex Popescu: Depinde. Pot să dau două exemple din ultimele două proiecte. Am un proiect pe care-l lansăm acum intern - o aplicație cu componentă UI unde poți să îți publici diferite skilluri și agenți, realizată 100% cu Vibe Coding. Nu știu ce este înăuntru. Nu mă interesează. A făcut deploymentul, a făcut release-ul, a făcut review-ul. Eu nu știu ce este acolo, pentru că mă uit numai la UI. Am și un MCP server.
Vreau ca modelele să fie clare, iar controllerele și comunicările externe să fie împărțite. Nu vreau să fie un talmeș-balmeș. Prin urmare, tu poți să îi dai niște reguli de separare și de organizare. În prezentarea sa de la The Developers, Neil Ford spune că un IA îți generează cod, doar că tu trebuie să îi specifici ce pachete să folosească, ce are voie să facă și ce nu are voie să facă. În general, Vibe Coding este foarte ușor și se poate ajunge la spaghetti coding. Toate comunică cu toate, iar, în momentul în care se strică ceva, s-a dus totul.
Alex Popescu: Am zis că-ți dau două exemple. Primul exemplu este cel în care nu m-am uitat, deci nu am făcut aplicația ca și cum aș ști cod. Pur și simplu am zis ce doresc, am dat serverul și am obținut prototipul. Și am tot adăugat feature-uri. Cam în trei zile am publicat aplicația. Exemplul doi este proiectul mai serios, să zic așa, cel care și produce bani pentru BMW. Acolo nu lucrăm așa. Acolo aplicăm conceptul de Strategic Architecture, Strategic Coding, adică Vibe Coding în care te ocupi de cum arată codul, care este arhitectura, care sunt interfețele, care sunt regulile și în care verifici ce cod se scrie. Facem review, avem skilluri de knowledge, MCP-uri și strategii de testare. În principiu, nu ne mai uităm la sintaxă atât de mult. În schimb, zona de arhitectură este responsabilitatea noastră.
Alexandru Ilieș: Toolurile pe care noi le avem și cu care ne jucăm la capitolul de skilluri și de MCP-uri au rolul de a face dintr-un sistem nedeterminist unul cât mai determinist, adică să genereze ceva exact cum ne așteptăm noi să genereze. La nivel de skilluri, MCP-uri și prompturi poți să poți să îți orchestrezi agenții tăi ca să îți genereze chestii cât mai cât mai deterministe și să autoînvețe din greșelile pe care le face. Ajungi într-un final să ai o calitate destul de bună a codului și a structurii. Există loopuri unde se autoînvață pe baza greșelilor anterioare. Ia niște prompturi sau niște text, le introduce în fișierele de configurare și acela devine knowledge-ul lui sau memoria lui. Problema majoră cu care ne-am întâlnit se referă la cum creezi contextul proiectului tău în așa fel încât IA-ul să știe să genereze un cod cât mai bun sau pe baza requirement-urilor specificate.
Eu, de obicei, lucrez singur, dar voi, lucrând în echipă, cum vă împărțiți munca?
Alexandru Ilieș: Noi am făcut un experiment intern pe un proiect recent. Au fost modificări la nivel de de workflow. A menționat cineva într-un articol despre Spec-Driven Development. Noi asta am încercat să testăm pe un proiect intern și avem rezultate foarte bune. Nu este o metodologie nouă. Este una veche de prin anii '90 de când a apărut și Test-Driven Development: scrii prima dată teste, iar apoi implementezi. Spec-Driven Development înseamnă că scrii prima dată specificația tehnică la ce urmează să se facă, cum și unde modifici codul, în ce fișiere. Specificația trebuie să fie source-of-truth și să îți ghideze codul generat. Prin urmare, dacă tu ai o specificație bună, vei avea un cod similar la fiecare run. Și în trecut defineai exclusiv clasele și toți pașii, doar că în trecut era costisitor să urmezi metodologia respective. Dacă trebuia să modifici deja un cod existent, trebuia să treci peste tot codebase-ul ca să știi exact unde să modifici. Treci un detaliu în specificație, dar tu nu modifici codul la momentul respectiv, faci un review la specificație și numai după aceea te apuci de implementare. Înaintea IA-ului era foarte costisitor și neproductiv. Acum, IA-ul generează specificația, pentru că are acces la cod și are un context destul de bun. Tu, ca developer sau ca team lead tehnic, faci un review la specificație, te uiți dacă are sens ce se va implementa sau ce urmează să implementeze. Apoi, specificația respectivă merge ca input la următorul ciclu de implementare, iar implementarea se va face strict pe specificația care vine ca input. Specificația respectivă vine și ca o documentație care rămâne în codebase cumva. În felul acesta, se poate lucra în paralel la specificații diferite. Nu mai contează ce generezi, ci contează ce specificații ai. Înaintea introducerii IA-ului pe proiect, developerii se împărțeau. Eu fac taskul de UI, eu fac taskul de backend, eu scriu teste. Acum, developerul care ia specificația le face pe toate, pentru că este mai greu să le împarți.
Eram curios pe partea de UX, cum gestionați partea de user interface, mock-ups? De obicei, IA ori nu le face bine, ori cumva acolo contează un pic de human touch.
Alexandru Ilieș: Pe proiectul pe care îl testăm încă avem un UX designer care face designul în Figma pe care îl folosim drept input. HTML-ul generat în Figma este inclus în specificația care urmează să se implementeze. Avem un PM care nu este tehnic. Întrebarea este cum îi dăm acces la codebase în așa fel încât și el să interacționeze cu un IA care să aibă context de cod.
Am ajuns la concluzia că orice proiect ai avea, dacă nu este gigantic, ar trebui să-l poți termina în două săptămâni.
Cosmin Sandu: Complexitatea cea mai mare vine când ai un proiect foarte mare. Ca reviewer pierzi deja din context. Contextul tău se degradează și prompturile tale se degradează dacă nu faci Spec-Driven Development, unde menții ca knowledge base-ul la unison cu codebase-ul.
Cum vezi partea de securitate care, de obicei, poate fi o problemă mare?
Cosmin Sandu: Securitatea este parte integrată din arhitectură. Când definești arhitectura definești și partea de securitate. IA-ul are foarte multe patternuri de securitate învățate. Cu greu poți să vii cu ceva în plus.
Tudor Damian (întrebare din sală): Prima linie de cod am scris-o acum vreo 35 de ani. Cu IA poți să faci multe chestii pe care le aveai în backlog ca idei pentru care știai că nu ai timp. Exact ce zicea Ovidiu. Trebuie să fim conștienți că toate modelele acestea au fost antrenate pe ce era la momentul respectiv cod public. Veracode a făcut un studiu pe vreo 100 și ceva de LLM-uri. Toate generează de 2,5 - 3 ori mai multe vulnerabilități în cod decât o fac oamenii în medie. Alt studiu arată că aproximativ 60% din codul generat cu IA conține vulnerabilități. Vorbim de vulnerabilități de top10 de acum 20 de ani. Mai există un paradox, anume că 80% din oameni au impresia că, dacă codul este scris cu IA, codul acela este mai sigur decât cel scris de oameni. Prin urmare, nu mai stai să verifici. E acel looks good to me pe un PR. Dacă tu îi spui că scopul este să treacă testele, va face un mock-up acolo unde testul dă fail, ca să treacă testul. Nu va schimba codul, nu îți va semnala codul greșit. După aceea, în etapa de review, încărcarea cognitivă este mult mai mare. Nimeni nu mai stă să citească tot codul. De aici rezultă problemele pe care noi le vedem în aplicațiile pe care le testăm. În ultimul an, găsim tot mai multe probleme de securitate din categoria celor de bază - la autentificare, la lipsa de validare de requesturi. SQL Injection a reapărut și este în creștere. Vorbim de SQL Injection care era un subiect de discuții acum 20 și ceva de ani. Cei care fac Vibe Coding nu au cum să valideze soluția, nu au cum să verifice, nu au cum să înțeleagă complexitatea. Dacă ei iau niște decizii arhitecturale care nu au nicio legătură cu realitatea, mai ales într-un sistem non-determinist, chiar și cu același prompt, vor fi outputuri diferite. Ce se întâmplă dacă într-o zi, pentru câteva ore, cei de la Anthropic au o problemă cu infrastructura? Nu mai scrie nimeni cod? Asta e realitatea. Cum rezolvi problemele fără internet? Toată lumea are impresia că știe, că face. Până când nu mai ai baterie la telefon, până când este căzut modelul tău favorit, până când ai rămas fără tokens, s-a dus fereastra de cinci ore. Cred că luna aceasta cel mai relevant exemplu este ce a făcut GitHub, cu toate schimbările în billing. Acum, mă costă de 10, 100, 200 de ori mai mult exact lucru pe care îl făceam în mai, dacă fac în iunie subscripția de GitHub Copilot. Nu mai este de mult relevant să folosești subscripția aia de 20 $. Trebuie una de 200 $. Cifrele indică faptul că a scăzut calitatea codului. Am fost la trei conferințe anul acesta, iar la una dintre ele, în keynote, cineva a spus: "Noi anul ăsta am livrat 500000 de linii de cod a reason to be proud of it." Eu pun pariu că 490000 din cele 500000 linii de cod nu au avut review. Cât de sustenabil va fi pe termen lung? Apropo și de discuția de angajare, de interviuri, de facultate unde ne-am tot plâns de fundamente, de algoritm, de design patterns, de system thinking. Dintr-o dată ne dăm seama că toate lucrurile acelea acum sunt relevante, iar cine nu le știe și face tot ce face doar cu IA nu își va dezvolta gândirea critică, systems thinking. În momentul în care le tai accesul la IA, oamenii aceia nu vor putea să își revină. Nu angajăm juniori. Tot asta aud de doi ani de zile în industrie, că nu mai are sens. Acum este nevoie nu de 20 $, ci de 200 $ să avem echivalentul muncii unui junior. Este fezabil?
Alex Popescu: Da. Este fezabil. Este doar un nou nivel de abstractizare. Nu mai scrie nimeni cod mașină și bits. Toată lumea face Java. Și înainte se făcea infrastructură. Acum se face Terraform. Nu mai știi tu ce este acela un server și network interface. Scrii un pic de Terraform și apare o infrastructură. Poți să intri la anumit nivel de detaliu, de exemplu aplică design patternul X sau Y, componente, API-uri, dar va fi o cerere așa de mare pentru a crește viteza de codare încât vei accepta trade-offul. Dacă tu ești developer bun, vei genera cod bun de 10 ori mai repede. Dacă ai un developer mediocru, vei genera cod pe care altcineva trebuie să-l repare în apartament. Clienții și oamenii încă nu și-au adaptat stilul de muncă la IA. Am clienți care încă îmi cer să iau taskul și să îl împart. Cât e XL? Fă-l un M sau un L. Era gata de mult dacă mă lăsai în pace. Lumea încă nu s-a adaptat să renunțe un pic chiar și la Agile. Când lucram în bancă și în Insurance, mă urau când mă duceam la ei și le ziceam o să vă dăm feature-ul la anul. Înnebuneau oamenii : "Cum la anul? Mie îmi trebuie mâine, îmi trebuie ieri.'' Pentru ei este mană cerească să vezi că dintr-o dată poți să obții feature-uri extrem de rapid. Noi, IT-iștii, ne concentrăm foarte mult pe zona noastră tehnică. Am făcut refactoring, Terraform și design patternul acela, dar nu au nicio valoare. Tu trebuie să livrezi business pentru că businessul produce banul. În sfârșit putem să livrăm business, să ne concentrăm, de fapt, pe ceea ce trebuie.
Alexandru Ilieș: De acord. Dar cunosc o istorie nu neapărat publică, de la cineva din privat. O companie de finanțe, nu neapărat bancară, avea vreo câțiva developeri, un business analyst sau un product owner și un sistem care genera foarte mulți bani și clienți. A început product ownerul să facă Vibe Coding și să implementeze el feature-uri. Și a mers timp de câteva săptămâni și apoi s-a decis: dăm developerii afară, rămâne product ownerul cu business ownerul. La un moment dat, s-a blocat totul și s-a cerut ajutorul de la o persoană mai tehnică, un consultant. Consultantul s-a uitat și a constatat că oamenii nu aveau nimic, nici backup-uri, nici rollback. Nu mai puteai să faci nimic și s-a încheiat businessul. Așadar, dacă nu ai niște fundamente bine structurate de software architecture, de software design, s-ar putea să ai surprize neplăcute. Ce se întâmplă dacă pică IA-ul? Dacă România nu mai are acces la Claude, din motive economice, politice? Ce te faci? Partea bună este că există și modele open-source care pot fi folosite. Într-o lume ideală, o companie ar fi sau ar avea un data center micuț cu ceva modele destul de performante unde să le poată folosi intern fără să depindă de un actor extern.
Gândește-te că și hardware evoluează și tu rămâi blocat. Trebuie să faci upgrade și mentenanță. Poate la trei luni trebuie să schimbi modelele. Personal, folosesc modelele local. Problema vine din zona de AI governance. Nimeni nu face așa ceva. Este haiducia aceea de la începuturile cloudului. Hai să folosim toți IA, dar abia acuma încep unii să își dea seama că, de fapt, ne costă mai mult decât estimasem. Vine Uber și zice la început de aprilie noi ne-am cheltuit tot bugetul de IA, pe tot anul. N-a urmărit nimeni. Performance criteria este numărul de tokens de IA folosite sau numărul de pull request sau numărul de linii de cod. Avem cereri de la clienți: iar am fost atacați, iar nu mai merge nu știu ce aplicație. Facem de vreun an - doi încoace Pentest pe LLM apps și orice aplicații făcute cu LLM pe zona de Prompt Injection. Este îngrozitor ce găsești acolo, chestii elementare, dar care nu sunt făcute.
Alexandru Ilieș: Eu cred că vor exista și companii unde fundamentele vor fi bine puse la punct și nu va fi cazul să se închidă businessurile, dar vor fi și companii care se vor închide la un atac mai serios.
Cosmin Sandu: Eu vreau să ies un pic din contextul IA-ului și să vă spun o poveste de demult. La un moment dat, într-o firmă unde lucram, erau două tabere: Hybernate versus Native Query TB. Cine poate să facă un cod mai performant din punctul de vedere al vitezei, să zicem? Răspunsul a fost: Depinde! Un average developer cu un framework precum Hybernate obținea cod mai performant decât un average developer care trebuia să scrie cod nativ. Pe de altă parte, cineva care știa bine să scrie cod nativ scotea o performanță mult peste framework. IA este un tool, depinde cum îl folosim.
(Întrebare din sală) Având în vedere că în economie banii trebuie să circule și dacă cu IA generezi o aplicație cu doi oameni, ce impact are acest lucru pentru economie? Se schimbă industria auto, se schimbă în electrice? Se micșorează? Se mai distribuie banii în societate?
Alex Popescu: E o întrebare bună. Am prezis eu anul acesta, la o prezentare, că vor apărea foarte mult businessuri care nu au existat până acuma. Dădeam exemplu dentistului care și-ar putea automatiza o grămadă de procese. Am un prieten care face planuri. Să facă o plombă cu Vibe Coding. Da, vibe plomba. Suntem foarte fericiți noi care plătim încă 200 $. Eu, ultima dată, când am măsurat, am văzut că suntem pe undeva pe la două milioane de tokenuri pe zi, pe om. Și probabil că o să mai crească. Dacă faci lucrurile serios cu testare, cu de toate, se mănâncă repede din tokenuri.