1. Bevezetés – az AI demo élmény
Nemrégiben részt vettem egy előadáson, amelynek egyik része az AI gyakorlati használatáról szólt. Többek között arról, hogyan írjunk megfelelő promptokat[1], hogy minél pontosabb eredményeket kapjunk. Szoftvertervező és -fejlesztőként érdekesnek találtam az előadást, de volt egy pontja, aminél még én is felkaptam a fejem — csak valószínűleg nem ugyanazért, mint a körülöttem ülők.
A bemutató során néhány perc alatt legeneráltak egy weboldalt. Fejlesztőként pontosan tudom, hogy egy weboldal mögött mennyire eltérő komplexitás húzódhat meg. Nem mindegy, hogy egy egyszerű landing oldalról, egy webshopról vagy egy több rendszerrel integrált vállalati alkalmazásról beszélünk.
A körülöttem ülők reakciója viszont gondolkodásra késztetett. Többen csodálattal jegyezték meg:
„Néhány kattintás, és 2-3 perc alatt kész?”
Nem lepődtem meg. Az utóbbi időben egyre gyakrabban találkozom a kérdéssel:
„Ha az AI tud kódot írni, akkor miért van még szükség programozókra?”
Pedig a demo valójában egy HTML oldalt generált. A leglátványosabb részt mutatta be. Nem feltétlenül a legnehezebbet.
Fred Brooks már 1986-ban, a No Silver Bullet című esszéjében arról írt, hogy a szoftverfejlesztés legnehezebb problémái nem egyszerűen technológiai problémák. Az eszközök fejlődhetnek, gyorsulhatnak, de az üzleti problémák valódi komplexitása attól még megmarad.
[1] Prompt: olyan utasítás vagy kérés, amely alapján az AI választ vagy eredményt generál.
2. A kívülről látható rész
Az évek során megtanultam, hogy a munkámnak vannak látványos és teljesen láthatatlan részei is. A legtöbb ember egy működő weboldalt vagy programot lát. Ha valaki megkérdezi, mivel foglalkozom, a válasz általában gyorsan leegyszerűsödik arra, hogy „kódot írok”.
Pedig a fejlesztés jóval több ennél.
Sokszor azt is nehéz kívülről megérteni, hogy egy-egy funkció elkészítése miért tart hosszabb ideig. Különösen akkor, amikor maga az ügyfél sem teljesen biztos abban, mire van pontosan szüksége, vagy nem tudja jól megfogalmazni.
Az AI megjelenésével ez a kérdés még hangsúlyosabb lett. Hiszen igen: az AI ma már képes használható kódot generálni. Nem kell órákon át fórumokat böngészni vagy dokumentációkat túrni egy alap megoldásért. Sok esetben elég egy jól megfogalmazott prompt, és néhány másodperc múlva már ott is van a kész kódrészlet.
Csakhogy a kód önmagában még nem maga a szoftverfejlesztés.
3. A színfalak mögött
Az AI megírta a kódot. Rendben. De ki ellenőrzi, hogy az valóban jól lett-e megírva? Ki látja át, hogyan fog működni fél év múlva? Mi történik, ha változnak az igények vagy hibák jelennek meg?
A szoftverfejlesztés egyik sajátossága, hogy a legfontosabb munka gyakran láthatatlan marad. A felhasználó egy működő gombot lát. Nem látja azokat a döntéseket, kompromisszumokat és hibamegelőző megoldásokat, amelyek miatt az a gomb megbízhatóan működik.
Mit építünk egyáltalán?
A fejlesztés egyik legfontosabb része nem a programozás, hanem a probléma megértése.
Az AI hatalmas segítség lehet, ha pontosan meg tudjuk fogalmazni, mire van szükségünk. Csakhogy ehhez először nekünk is értenünk kell a problémát.
A Domain-Driven Design (DDD)[2] egyik fontos gondolata például az, hogy a fejlesztők és az üzleti oldal közös nyelvet használjanak. Ez azonban nem azt jelenti, hogy az üzleti folyamatokat egy az egyben át lehet fordítani kódra. A kettő között mindig szükség van értelmezésre, tervezésre és döntésekre.
Az AI ebben segíthet. De helyettünk nem fogja megérteni a vállalat működését.
[2] DDD (Domain-Driven Design): domainvezérelt tervezési szemlélet.
Mi történik fél év múlva?
Egy szoftver ritkán marad változatlan. Egy vállalat fejlődik, új igények jelennek meg, változik a terhelés, új folyamatok kerülnek bevezetésre.
A kérdés ezért nem csak az, hogy egy rendszer ma működik-e, hanem az is, hogy mennyire lesz módosítható később.
Martin Fowler a technical debt fogalmával írja le azt, amikor egy gyors vagy kényelmes technikai döntés később jelentős problémákat okoz. Egy rendszer valódi értéke ezért sokszor nem az első verzióban, hanem a hosszú távú karbantarthatóságban mérhető.
Hogyan illeszkedik más rendszerekhez?
A modern szoftverek ritkán működnek teljesen önállóan. Külső szolgáltatásokhoz, API-khoz, belső rendszerekhez vagy beszállítói megoldásokhoz kell kapcsolódniuk.
És itt kezd igazán bonyolulttá válni a történet.
Lehet, hogy egy integráció technikailag megoldható, de:
- van-e rá megfelelő API,
- mennyibe kerül,
- mennyire stabil,
- ki üzemelteti,
- és mi történik, ha a másik rendszer változik?
Ezek már nem egyszerűen programozási kérdések. Ezek mérnöki és üzleti döntések.
4. Az AI és a félreértés
Ma rengeteg helyen hallani arról, hogy az AI mennyire felgyorsítja a munkát. És ez valóban igaz.
Szoftverfejlesztőként például pontosan tudom, mennyi időt képes elvinni egy dokumentáció elkészítése. Megfogalmazni szakmailag pontosan, képernyőképeket készíteni, adatokat kitakarni, formázni, szerkeszteni. Korábban ez akár napokat is jelenthetett. Ma ezeknek a feladatoknak egy része néhány perc alatt automatizálható.
Az AI rengeteg sablonos vagy ismétlődő munkát gyorsabbá tett. Ettől a munkavégzés valóban hatékonyabb lett. Sokan azonban ebből azt a következtetést vonják le, hogy maga a szakértelem is olcsóbb lett.
Pedig a rossz döntések ára továbbra sem lett kisebb. Sőt, bizonyos esetekben még nagyobb is lehet.
Simon Willison fejlesztő többször hangsúlyozta, hogy az AI jelenleg sokkal inkább egy rendkívül erős asszisztens, mint autonóm mérnök. A generált kód értelmezése, ellenőrzése és rendszerbe illesztése továbbra is emberi döntéseket igényel.
Nézzünk egy egyszerű példát.
Egy kisebb vállalkozás külsős fejlesztőcéggel dolgozik együtt. A vezetőség részt vesz egy AI előadáson, ahol percek alatt elkészül egy látványos weboldal. Jogosan merül fel bennük a kérdés:
„Ha ez ilyen egyszerű, akkor miért fizetünk fejlesztőknek?”
A vállalkozás végül úgy dönt, hogy saját maga generálja le az új webshopot AI segítségével. Az oldal első ránézésre működik is. Csakhogy marad benne egy apró hiba: a kosárból nem lehet véglegesíteni a rendelést.
Nincs fejlesztői tesztelés. Nincs review. Nincs monitoring. Az eredmény pedig nem technológiai probléma lesz, hanem üzleti veszteség.
5. Záró gondolatok
Az AI nem rossz. Sőt: elképesztően hasznos eszköz.
A jövő egyértelműen ebbe az irányba halad, és fejlesztőként szerintem hiba lenne figyelmen kívül hagyni. Az AI gyorsít, támogat, automatizál és rengeteg monoton feladatot levesz az ember válláról. Viszont fontos megérteni a határait is.
Valószínűleg a klasszikus „kódolgatás” szerepe egyre kisebb lesz. De ettől a mérnöki gondolkodás értéke nem csökken — inkább felértékelődik.
A jó rendszertervezés, a problémamegértés, a döntéshozatal, a kommunikáció, az egyszerűségre való törekvés és a hosszú távú gondolkodás továbbra sem automatizálható néhány prompttal.
Az AI gyorsan és olcsón elkészíti a puzzle darabjait. De a kirakót továbbra is valakinek össze kell raknia.