A mesterséges intelligencia nem söpri el a szoftverfejlesztőket — de alapjaiban írja át, mivel telik a napjuk. McLaren Stanley, az Amazon Senior Principal Engineere (ez a cég egyik legmagasabb műszaki rangja) azt a csapatot vezeti, amely az Amazon iOS-es és androidos vásárlási alkalmazásait modernizálja — azt az appot, amelyben világszerte több mint 300 millió aktív vásárló böngészi, hasonlítja össze és veszi meg a termékeket. Az alkalmazást most AI-natív módszerekkel és a Kiro nevű, agentikus AI-alapú fejlesztőkörnyezettel (IDE) építik újjá. A közép- és kelet-európai újságírókkal tartott legutóbbi találkozóján Stanley elmesélte, hogyan szervezte át a csapata a teljes szoftverfejlesztési folyamatot az AI köré, mit hozott ez a gyakorlatban — és miért gondolja, hogy egy egyre automatizáltabb világban továbbra is az emberi ítélőképesség a legértékesebb erőforrás.
Az AI-eszközök egyre elérhetőbbek, mégis gyakran tátong szakadék aközött, amit a technológia ígér, és amit a felhasználó a gyakorlatban kap. Te nap mint nap AI-val építkezel: hol tart most valójában a technológia, és hol fújták túl az elvárásokat?
Minden ekkora ipari fordulatnál jön egy lelkesedési hullám. Ezt a koncepciót a sci-fi és a popkultúra már rég beültette a fejünkbe, és ez a sci-fi-elem néha beszivárog a szakmai beszélgetésekbe is — táplálja azt a képet, hogy ezek a technológiák mindent felforgatnak. Az életünket tényleg meg fogják változtatni, de úgy, ahogy a filmekben láttuk? Nyilván nem.
Nagyon fontos két lábbal a földön maradni, mert hajlamosak vagyunk emberi tulajdonságokkal felruházni az AI-t — és ez tévút. Aki emberként kezeli a kimenetet, elveszíti felette a kontrollt. Kétféle felhasználó van: az egyik arra használja az AI-t, hogy gyorsabban és jobban gondolkodjon, információt gyűjtsön — a másik magát a gondolkodást szervezi ki. Az első a helyes hozzáállás. A magas szintű emberi ítélőképesség ma is a legértékesebb erőforrás. Az AI-modellek kiválóan ismernek fel mintázatokat és rendszereznek információt, de az az egyedülállóan emberi képesség, hogy a már összegyűlt információk alapján jó ítélettel döntsünk — ez az a terület, ahol a jövőben mi tesszük hozzá az értéket.
Az Amazon egyik legmagasabb mérnöki pozícióját töltöd be, mégis azt mondtad, tavaly több kódot írtál, mint előtte az egész karriered alatt. Hogy jön ez össze?
Senior Principal vagy lead szinten nem szokás folyamatosan kódolni — a technikai vezetői feladatok viszik el az időt: architektúra-egyeztetések, más csapatok terelgetése, a hosszú távú vízió kidolgozása. Az AI ebből kivette az adminisztratív teher jó részét. Ma egyszerre több feladatot viszek: befejezek egy munkát, beküldöm review-ra, és már kezdem is a következőt. Remek alkalom volt újra kapcsolatba kerülni a szakma nyersanyagával, visszatérni a mindennapi építkezéshez. Kódot mindig is írtam, csak egyszerűen nem fért bele annyi. Az, hogy megint többet tudok csinálni, nagyon jó élmény.
Ha ma már az AI írja a kód nagy részét, mi marad a programozónak? Tényleg építőmunkásból lett építész?
Ez egészen jól leírja a helyzetet. Ha a kódot az agent írja, a kimenet minősége azon múlik, milyen jól tervezted meg a rendszert, amit fel akarsz vele építtetni. Az időnk nagy része ma az előzetes gondolkodásra megy: mit építsünk, hogyan működjön a különböző platformokon — aztán a követelmények kidolgozására. A specifikációk és a konkrét feladatok, amelyeket később az agent hajt végre: ma itt telik a legtöbb időnk.
A mérnöki munka ettől furcsa módon felszabadult: több idő jut a kreatív részére, és kevesebb a kódmergelésre, a konfliktusok bogozására meg a szakma többi robotmunkájára.
Milyen egy tipikus munkanap így? És hogyan magyaráznád el a spec-driven developmentet — a specifikáció-vezérelt fejlesztést — valakinek, aki nem programozó?
Nálunk a spec-driven development rendkívül kollaboratív műfaj lett. Az AI előtt sokáig tartott kézzel megírni a tervdokumentumokat, kitalálni, pontosan hogyan épül fel egy funkció. Valaki napokat-heteket ült egy design-dokumentum fölött, aztán jött a review, a módosítások, vissza a rajzasztalhoz. Rengeteg idő ment el erre az aszinkron előkészítésre.
Ma beültetjük egy szobába a designert, a termékmenedzsert és a mérnököt, leülünk a Kiro agenttel, és egyszerűen elmondjuk, mit akarunk építeni. Egyfajta páros munkává válik az egész. Ami régen hetekbe telt, az ma egy pörgős negyedórás-egyórás beszélgetésbe sűrűsödik: eldöntjük, mit építünk, aztán munkára fogjuk az agenteket.
És mivel a köztes munkaanyagok elkészítése már nem nagy befektetés, az emberek kevésbé ragaszkodnak a rossz ötleteikhez. Gyorsabban iterálsz. Nem vált be egy ötlet? Semmi gond — eldobod, jöhet a következő.
Közép-Európában rengeteg középvállalat kísérletezik az AI-val, de sokan elakadnak, amikor a meglévő IT-környezetbe kellene beilleszteni. Szerinted mi most a legnagyobb szűk keresztmetszet?
Az ember természetes reflexe, hogy amikor új eszközt kap, ugyanúgy fejleszt tovább, ahogy addig, csak itt-ott bedob egy kis AI-t, hátha gyorsít. És igen, gyorsít is valamennyit. De azok a csapatok, amelyek időt szántak rá, hogy újragondolják és átszervezzék a folyamataikat, sokkal gyorsabban haladtak.
Ezt úgy hívtuk: indulj lassan, hogy gyors lehess. A csapatoknak idő kellett, hogy fékezzenek a napi feladatokon, megismerjék az eszközöket, és újragondolják, hogyan dolgoznak. Akik hátraléptek és új szemszögből néztek rá a munkájukra, hamar lehagyták azokat, akik mechanikusan darálták tovább a régi feladatlistát. Amikor ezt a mintát megláttuk, feltettük a kérdést: hogyan lehet ezt a megközelítést kiterjeszteni? Szánj rá időt, gondold újra a rendszert, tölts egy-két hónapot az eszközök megismerésével, és csak utána építsd be a csapat működési modelljébe. Az eredmény így lényegesen jobb.
A hardver megint kritikus tényező az AI-bevezetésnél. Hogyan látod a programozási nyelvek, az infrastruktúra és az AI-teljesítmény viszonyát?
A modern, típus-, szál- és memóriabiztos programozási nyelvek sokkal jobban működnek együtt a kódoló agentekkel. Ha ezeket a korlátokat a fordító kényszeríti ki, az agent egyértelmű visszajelzést kap arról, működik-e a megoldása. Mi kifejezetten ezek miatt a biztonsági tulajdonságok miatt álltunk át teljesen Swiftre iOS-en és Kotlinra Androidon.
A siker kulcsa, hogy a teljes munkafolyamatot — a szoftverfejlesztés egész életciklusát — az AI-ra hangold. Nem csak a kód megírásáról van szó, hanem arról is, hogyan mergeled és teszteled biztonságosan. Teljes lefedettségű, automatizált tesztkészletek kellenek, amelyek minden mentésnél lefutnak, hogy az agent ne csempészhessen be olyan kódot, ami elrontja a rendszert. És biztonságosabb módszer kell a változtatások bevezetésére is, mert sokkal több változás érkezik — ha sok agent dolgozik ugyanabban a kódbázisban, nő a konfliktusok kockázata.
A másik oldalon viszont: ha gond van, ugyanazt az agentet ráengedheted az elemzésre. Hiba, alkalmazás-összeomlás, stack trace? Odaadod az agentnek, és az embernél jóval gyorsabban megtalálja a kiváltó okot.
A csapataitok 4,5-szeresére növelték a production release-ek számát. Mit jelent ez a hétköznapi felhasználónak?
Rengeteg különböző technológián futtattunk pilotprojektet, és minden csapatot a saját korábbi release-üteméhez mértünk. Az AI-natív fejlesztést kipróbáló csapatoknál a production release-ek száma a tesztidőszak alatt átlagosan 4,5-szeresére nőtt.
Ez rendkívüli innovációs ciklust indít el, mert sokkal gyorsabban tesztelhetünk ötleteket. Ötlet mindig rengeteg van, és a legtöbb csapat hatalmas backloggal él, amihez idő, prioritás vagy kapacitás híján sosem jutott el. Most viszont annyira megváltozott ezeknek a problémáknak a megtérülése, hogy sokkal több minden belefér. Ez a felhasználónak nagyobb biztonságot és fejlettebb funkciókat jelent.
Remek példa az akadálymentesítés. Az akadálymentesítési mérnökünk mély platformszintű tudását be tudtuk építeni a folyamatba. Egy átlagos csapatban nincs meg minden platformra ez az erősen specializált tudás — de amint egyszer beépítettük a rendszerbe, a képernyőolvasót vagy más kisegítő funkciót használó vásárlóink igényeit az egész vállalatnál sokkal következetesebben és gyorsabban tudjuk kiszolgálni.
Rengeteg cég futtat olyan örökölt alkalmazásokat, amelyekhez se dokumentáció, se az eredeti fejlesztők. Ebben tud segíteni az AI?
Pontosan itt jön ki a spec-driven development szépsége: a specifikációkon keresztül megőrzi az üzleti döntéseid történetét. Itt vannak a követelmények, amelyek miatt a funkció megszületett, és itt a hozzá tartozó szoftverterv — ezek a fájlok a generált kód mellett maradnak a rendszerben.
De hamar rájöttünk, hogy a mostani kódunk nagy része olyan korból való, amikor még emberek írták — és pont ugyanez a baja: a szerzője elment, a kód tízéves, és senki sem tudja pontosan, mit csinál. Ezért építettünk az Amazon Bedrockra egy Spec Studio nevű eszközt. Átfésüli a meglévő kódbázisokat, és a kész kódból fejti vissza az üzleti követelményeket: elemzi a kódcsomagokat, és elmagyarázza, mit csinál az adott programlogika. Ha egy csomagnak nem volt dokumentációja, generál hozzá a fejlesztőknek.
Mindezt egész jó pontossággal. Azt talán nem mondja meg, miért született egy döntés, de azt igen, hogy mi volt a döntés. És ettől vállalati léptékű, komplex rendszerekben is sokkal könnyebb megérteni, mi történik.
Sok fiatal fejlesztő attól fél, hogy az AI elveszi előlük a lehetőségeket. Érdemes ma egyáltalán programozni tanulni?
Határozottan igen. Az Amazon mindig hosszú távon gondolkodott a szoftverfejlesztésről, és mindig úgy tartottuk: a következő mérnökgenerációba fektetni maximálisan megéri. Sosem tudhatod, melyik friss diplomás forgatja fel egyszer a szakmát. Mindenki elkezdte valahol.
Ez a nyitottság és kíváncsiság az AI világában különösen fontos, mert most épp azok a bevett minták és folyamatok változnak, amelyeket eddig best practice-nek tartottunk. Óriási előny, hogy vannak fiatal mérnökeink, akik friss szemmel jönnek, otthonosan mozognak az eszközök között, és sokkal könnyebben fedeznek fel új dolgokat, mint a megszokásaikba ragadt kollégák.
Ha a juniorok energiáját és kíváncsiságát összerakjuk a tapasztalt mérnökök elosztott rendszerekben vagy alkalmazásfejlesztésben szerzett tudásával, az remek kombináció a csapatnak. És szerintem ez a jövőben is így marad.
Sok területen máig vitatott az AI használata. A programozásban miért nem az?
A szoftverfejlesztés gyökerei jórészt a nyílt forráskód gondolatába nyúlnak: arra építünk, amit mások már megcsináltak. A Linux és a többi nagy open source platform megosztja a kódját, hogy bárki építhessen rá, alakíthassa, módosíthassa. Ez a közösség már rég megteremtette az együttműködés kultúráját — az AI pedig ezt ki tudta használni.
Ráadásul a szoftverfejlesztésben a kreativitás abból fakad, hogy meglévő mintákból rakunk össze egyedi megoldásokat a felhasználók problémáira — akkor is, ha az eredeti könyvtárat más írta. A kód eszköz, nem cél. A kreatív tett az, amit építesz belőle — nem maga a nyelv vagy a kód.