Alakulok át-podcastsorozatunk első epizódjában (Hogyan írja át az AI a szoftverfejlesztést?) arról beszélgettünk, hogy hogyan formálja át a mesterséges intelligencia a szoftverfejlesztést, mit jelent ez a fejlesztők mindennapjaiban, és miért nem az AI-eszközök önmagukban, hanem azok használati módja, a kontextus és a mögöttes szakmai gondolkodás jelenti az igazi versenyelőnyt. Az epizódban szó esett arról is, hogyan változik a fejlesztő szerepe egy olyan világban, ahol egyre több kódot állít elő mesterséges intelligencia, miközben a mérnöki szemlélet továbbra is megkerülhetetlen marad.
A beszélgetés során több szervezeti és stratégiai szempont is előkerült, de talán a legérdekesebb tanulságokat azok a mindennapi helyzetek adják, amikor az AI már nem elméleti lehetőségként, hanem a napi munka részeként jelenik meg.
Az alábbi írásban a saját fejlesztői és vezetői tapasztalataimon keresztül mutatom be, milyen következtetésekre jutottunk a Webstarnál az elmúlt időszakban, miközben egyre több feladatot oldottunk meg AI-támogatással, és miért gondolom úgy, hogy az AI bevezetése valójában sokkal inkább szervezeti, mint technológiai kérdés.
Igaz közmondások
A Webstarnál visszatérő kihívás, hogy a napi ügyfélprojektek mellett kevés kapacitás marad a belső rendszereink fejlesztésére. Jellemzően a saját igényeink a backlog aljára kerülnek, és sokáig, néha örökre ott is maradnak. A közmondás igaz ránk is, miszerint a suszternek mindig lyukas a cipője.
Mielőtt a Webstar CTO-ja lettem, nagyrészt mobilfejlesztéssel foglalkoztam, ezért szeretem azt hinni, hogy van frontend fejlesztői szemléletem és szakmai alapom. Webes alkalmazásokat operatív szinten nagyon keveset fejlesztettem. Ebből kifolyólag TypeScript-ben és Angular-ban közel sem rendelkezem olyan a rutinnal, mint azok a kollégáim, akik napi szinten ebben dolgoznak.
Az utóbbi egy-másfél évben sikerült több időt szakítanom egy belső webes alkalmazásba beérkezett igények átolvasására és megértése. Szoftverfejlesztői tapasztaltomra alapozva nekifutottam az egyszerűbb feladatok megvalósításának az éppen aktuális AI-eszközökkel.
Hamar kiderült, hogy ilyen helyzetben óriási segítséget nyújtanak, hiszen programkódot olvasni sokkal könnyebb, mint a semmiből előállítani azt.
Egyszerűbb feladatoknál ez a kezdetektől szuperül működött, 2026 elején pedig a Claude Code használatával érezhetően sokkal jobb lett. Viszonylag összetettebb feladatok esetén is pár óra alatt eljutottam olyan eredményekig, amelyek korábban napokat igényeltek volna.
Tanulságok
Az elmúlt fél évben három dolgot tanultam ezekből a helyzetekről, ami alapvetően megváltoztatta azt, ahogy az AI használatáról és bevezetéséről gondolkozok:
1. A szakmai felelősség az emberé
Az AI sok területen kiegészíti a tudásunkat, a szakmai mélységet viszont továbbra is nekünk kell biztosítani. A fejlesztések, amiket elkészítettem a belső rendszereinkben szuperül működtek, a kollégák által végzett code review során viszont előkerültek olyan szempontok, amelyeket sem az AI, sem én magamtól nem vettünk észre. Előfordult, hogy
- egy adott problémára létezett egyszerűbb (a keretrendszer/nyelv által biztosított) megoldás,
- volt már rá kialakult minta a kódbázisban (ezért a megoldásom duplikációt vezetett be), vagy
- az adott technológiában teljesen más megközelítésben szokás megoldani a problémát, mint amit én választottam.
Egy kisebb belső rendszerben ezek miatt nem dől össze a világ. Egy nagy terhelésű, üzletileg kritikus, hosszú távon fejlesztett alkalmazásnál viszont ugyanennek már ára lehet teljesítményben, biztonságban, karbantarthatóságban és stabilitásban, ami közvetlenül rányomja a bélyegét a felhasználói élményre és üzleti eredményekre is.
Bár sokkal könnyebben tudok idegen technológiában érdemi munkát végezni, de ettől még nem szereztem meg azokat az évek alatt kialakuló reflexeket és intuíciót, amelyekkel az adott területen egy tapasztalt szakember rendelkezik. Ilyen szempontból egy adott keretrendszer mély ismerete nemhogy feleslegessé vált, hanem még értékesebb lett.
2. A fejlesztés elérhetőbb, de nem vált mindenki fejlesztővé
Az AI-val olyan kollégák is képesek működő funkciókat létrehozni, akik korábban legfeljebb üzleti vagy projektoldalról találkoztak a fejlesztéssel. Egyik kollégám, aki évek óta üzleti elemzői és projektvezetői teendőket lát el (tehát régóta nem programozott aktívan) AI segítségével egy összetettebb koncepciót épített fel ugyanahhoz a belső adminisztrációs rendszerhez, amit én is fejlesztgetek. Funkcionálisan működő dolgot szállított, viszont a code review-n komoly problémák kerültek elő: a kódszintű csapatkonvenciók, architekturális szempontok és olyan minőségi megfontolások hiányoztak, amelyeket egy fejlesztő figyelembe vett volna.
Az üzleti problémára adott gyors megoldás rövid távon előnyt jelenthet, de ha nem illeszkedik a rendszer egészébe, hamar fenntarthatósági problémákat (technikai adósságot) okoz.
Nálunk ezt a code review – mint minőségi kapu – még időben kiszűrte. Ennek hiányában viszont néhány hónap múlva hibákban, nehezebb továbbfejlesztésben és saját magunk elé épített akadályokban jelentkezne ugyanez. Ebből azt tanultuk meg, hogy AI segítségével szoftverfejlesztői tapasztalat nélkül is jól lehet prototípust készíteni, de
production-rendszerek fejlesztéséhez továbbra is szükséges a mérnöki gondolkodásmód, az alaposság és a körültekintés.
3. Az AI használatát a kódgenerálásnál jóval tágabban kell értelmezni
Kezdetben leginkább úgy tekintettünk az AI-ra, mint egy eszközre, ami nagyon gyorsan tud helyettünk programkódot írni. Ez már kicsi, pontosan definiált feladatoknál is remekül működik. Összetettebb fejlesztéseknél azonban hamar kiderült, hogy a bemenet minősége mennyire meghatározó az eredmény szempontjából. Ha nem gondoljuk át és írjuk le pontosan a célt, a korlátokat és az elvárt minőséget, az AI a hiányzó részeket maga tölti ki a saját szempontrendszere szerint.
A kapott eredmény valószínűleg működőképes lesz, csak jó eséllyel nem olyan, amivel hosszú távon szeretnénk együtt élni.
Ez arra tanított minket, hogy többet foglalkozzunk egy-egy feladat előkészítésével. Muszáj volt megtanulnunk jobban specifikálni és tervezni a rendszer adottságainak ismeretében. És sajnos még ez sem elég, hiszen a fenntartható megoldás megtalálásához képet kell alkotni a jövőbeli életútról, lehetséges továbbfejlesztési területekről is, hiszen ennek fényében kell a rendszer rugalmasságát és komplexitását finomhangolni.
Ezzel együtt világossá vált, hogy az AI értékének csak egy része a programkód előállítása. Ugyanúgy használható
- egy ismeretlen kódbázis feltérképezésére,
- alternatívák gyors kipróbálására,
- egy terv kritizálására,
- dokumentálásra vagy
- review támogatására.
Ez a három tanulság a saját, fejlesztői oldalról szerzett tapasztalatom, de úgy gondolom, hogy jól bemutatják azokat a pontokat, amikre egy szervezetnek is oda kell figyelnie, amikor AI-megoldások bevezetését tervezi.
Az AI-bevezetés nem beszerzési projekt
Könnyű lenne az AI-bevezetést, a szervezetek AI-transzformációját úgy kezelni, hogy kiválasztjuk a megfelelő eszközt, megvesszük a licenszeket, tartunk egy oktatást, majd várjuk a hatékonyság-növekedést.
A saját tapasztalatom alapján azonban a transzformáció jóval többről szól. Minden helyzetben végig kell gondolnunk a következőket:
- Milyen feladatot bízhatunk az AI-ra: a kódgenerálás csak az egyik lehetőség a sok közül.
- Hogyan kell a bemenetet előkészítenünk: amit mi nem gondolunk végig, azt az AI tölti ki helyettünk – a saját szempontrendszere szerint.
- Hol és milyen mélységű szakértői ellenőrzésre van szükség: nálunk a code review szűrte ki azt, amit sem az AI, sem én magamtól nem vettem észre, és ugyanez fogta meg az üzleti oldalról érkező megoldás architekturális hiányosságait is.
- Milyen új kompetenciákra lesz szükségünk, hogy rendszerszinten, hosszútávon nagyobb értéket teremtsünk: a pontos specifikálás és a hosszú távú tervezés egyaránt ide tartozik.
Az AI elképesztő mértékben fel tudja erősíteni a mindennapi szellemi munkát számos területen,
ehhez viszont nekünk is meg kell tanulnunk érettebben, tudatosabban, más megközelítésben dolgozni.
Mivel nem csak egy eszköz adaptációjáról van szó, hanem a saját szokásaink megváltoztatásáról, ez már valójában egy szervezetfejlesztési kezdeményezés, és mint ilyen nem ér véget a beszerzési projekttel.
Szeretne többet megtudni a projektről?
Ez neked azért jó, mert ipsum dolor sit amet, consectetur adipiscing elit. Aliquam faucibus risus quis lectus hendrerit.
Adja meg email címét ahová külhetjük!
SIKERES FELIRATKOZÁS
A megadott e-mail címre hamarosan küldjük!
