MI-láz utáni kijózanodás: Miért nem a kódírás a szoftverfejlesztés szűk keresztmetszete?

2023-ban a tech világ hangos volt a jóslatoktól: a nagyvállalati vezérigazgatók azt vizionálták, hogy a mesterséges intelligencia 2025-re a fejlesztők 80%-át feleslegessé teszi. Most, 2026 elején azonban egy egészen más valóságot látunk. Nemhogy kevesebb, de több fejlesztőt vesznek fel a cégek, mint valaha.

Vajon az MI kudarcot vallott? Szó sincs róla. Csupán változott a hozzáállás és megértettünk pár dolgot: a szoftverfejlesztés lényege nem a gépelés.

Gyors áttekintés

A probléma: Az MI zseniálisan kódol izolált környezetben, de elvérzik a komplex, összefüggő rendszerek és a változó üzleti igények útvesztőjében.
A kockázat: Az MI által generált kód esetén kétszer akkora az esélyhogy javításra szorul (code churn) és a biztonsági incidensekre.
A megoldás: A fejlesztő szerepe átalakul: kódoló munkásból rendszerszemléletű döntéshozóvá és „MI-pilótává” válik.

---

A Devon-lecke: A demó és a valóság közötti szakadék

2024-ben a világ megismerte Devont, az „első MI szoftvermérnököt”. A látványos demók után a piac pánikba esett, hogy most aztán mindenkinek elveszi a munkáját a mesterséges intelligencia, de a valódi projektek során gyorsan jött a kijózanodás. Kiderült, hogy míg egy MI képes percek alatt megírni egy egyszerű alkalmazást, egy élő kódbázisban – ahol ezer szálon függnek egymástól a funkciók – már képtelen tartani a lépést. Nem elég nagy a context window, nem tud mindent átlátni és folyamatosan emlékezni is rá.

Azok a cégek, amelyek elsiették a humán erőforrás MI-re cserélését, hónapokon belül kénytelenek voltak visszavenni a fejlesztőiket. Nem azért, mert az MI „rossz”, hanem mert félreértették a szakma alapjait.

---

Három fal, amibe az MI minden projektben beleütközik

PM szemlélettel nézve a szoftverfejlesztés egy kockázatkezelési folyamat. Itt látszik leginkább az MI korlátja:

1. A kontextus-vakság (Context Problem)

Egy modern szoftver több százezer sornyi kódból és több tucat fájlból áll. Az MI-nek van egy technikai korlátja (kontextus-ablak): képtelen az egész rendszert egyszerre „észben tartani”. Ha megkérjük, hogy módosítson egy funkciót, ami 40-50 fájlt érint, elkerülhetetlenül hibákat és következetlenségeket fog létrehozni.

• Adat: Egy friss kutatás szerint az MI-kód esetén a javításra szoruló sorok száma (code churn) a duplájára nőtt a tisztán emberi kódhoz képest.

2. A rejtett követelmények csapdája

A fejlesztés legnehezebb része nem a „hogyan”, hanem a „mit”. Az ügyfél kérése („Kellene egy fizetési rendszer”) mögött több tucat ki nem mondott üzleti szabály rejlik (visszatérítések, adószámítás, csalásszűrés).

Az MI szó szerint veszi az utasítást, a tapasztalt fejlesztő viszont kérdez. Az MI nem tudja kiszűrni a rejtett igényeket, a fejlesztő viszont tudja, hol fog elvérezni a projekt, ha nem tisztázzuk a részleteket az elején.

3. Stratégiai döntéshozatal

Minden kódsor egy üzleti döntés.

• Gyorsan akarunk piacra lépni, vagy skálázható architektúrát építünk?
• Beáldozzuk az olvashatóságot a teljesítményért?

Az MI nem ismeri a csapatod büdzséjét, a határidőket vagy a hosszú távú célokat. Egy technikailag működő, de fenntarthatatlan kódot bármikor legyárt – de a karbantartási rémálmot 6 hónap múlva neked kell kifizetned.

---

Ember és AI: Ki miben erős?

 

---

Az új korszak: A fejlesztő mint „Erőgép-kezelő”

Az asztalosokat sem tette feleslegessé az elektromos fúró, csak gyorsabbá és precízebbé váltak vele. Ugyanez történik a szoftveriparban is. Az MI alapvetően egy képességnövelő.

A jövő fejlesztője nem az, aki fejből tudja a szintaxist (azért nem árt tisztában lenni vele), hanem az, aki:

• Rendszerben gondolkodik: Átlátja a fájlok közötti komplex kapcsolatokat.
• Jól kérdez: Képes az ügyfél zavaros igényeit tűpontos specifikációvá gyúrni.
• Auditál: Nem vakon bízik az MI-ben, hanem minőségbiztosítási pontokat (gate-eket) épít be a folyamatba.

Konklúzió

A szoftverfejlesztés nem halt meg, sőt, izgalmasabbá vált. Az MI átvette a favágást (repetitív kódolás), így a fejlesztőknek végre maradt ideje arra, amiért valójában fizetik őket: problémát megoldani és értéket teremteni.

A kérdés már nem az, hogy az MI levált-e téged, hanem az, hogy te megtanulod-e irányítani az MI-t, mielőtt a konkurenciád teszi meg.