AI a szoftverfejlesztésben: mennyivel gyorsíthatja a projektedet 2026-ban?

2026. szeptember 24-én cégvezetők, IT-vezetők és fejlesztőcégek tulajdonosai ültek le az Adaptérben megrendezett MVÜK x LogiNet Café-n, hogy kiderüljön, mennyi a hype és mennyi a valóság az AI-val támogatott szoftverfejlesztésben. Az előadók és a panel résztvevői egyetértettek abban, hogy a kódolás hatékonyabb lett, az igény megfogalmazása, az ellenőrzés és a karbantartás viszont ugyanolyan nehéz maradt. Aki nem tudott eljönni, annak összegyűjtöttük a délután legfontosabb gondolatait.

Előadást tartott Máriás Zsigmond, a LogiNet alapítója és ügyvezetője, valamint Dávid Zoltán, a budapesti feature flag szolgáltató ConfigCat vezetője. A panelbeszélgetésen csatlakozott hozzájuk Zentai Balázs, a TOPdesk fejlesztésekért felelős igazgatója (VP of Engineering), valamint Grünzweig Tamás, az IBM budapesti laborjának engineering vezetője. A rendezvényt a LogiNet az MVÜK-val közösen szervezte.

A négy résztvevő négy különböző szemszögből nézi a szakmát, mégis ugyanarra a következtetésre jutott. A kódolás tényleg hatékonyabb és és gyorsabb lett. Ami körülötte van, az viszont ugyanolyan nehéz maradt: pontosan megfogalmazni az igényt, ellenőrizni, amit a gép írt, évekig karbantartani, és eldönteni, mit érdemes egyáltalán megépíteni.

Mit tud ma az AI a szoftverfejlesztésben?

Zsigmond szerint 2025-ig az AI a fejlesztésben egy okosabb automatikus kiegészítés volt. A 2025 végén megjelent modellek és a rájuk épülő AI coding agentek viszont teljesen átírták a munkát, és a fejlesztők ma egészen más világban dolgoznak, mint egy-két éve. A számítógép az emberi nyelven, pontatlanul megfogalmazott feladattal is tud kezdeni valamit, a kód pedig sokszor gyorsabban készül el, mint korábban.

A lelkesedés mellé rögtön odatett egy lábjegyzetet is. Boris Cherny, a Claude Code megalkotója 2025-ben még azt mondta, coding is solved, 2026-ban már azt, hogy largely solved. Zsigmond ezt úgy fordította le, hogy kódot tényleg gyorsan írunk, csak a hibákat is ugyanilyen gyorsan gyártjuk.

A délután egyik visszatérő gondolata innen jött. Az általános funkció, átlagos minőségben és kisebb méretben, ma szinte ingyen van. Ha viszont kifejezetten egyedi dolgot akarsz, és az átlagnál jobb minőséget vársz, az ugyanolyan nehéz, mint eddig. Felzárkózni könnyű lett, de aki a versenytársainál jobbat akar, az általában nagy és specifikus rendszert épít, és ebben az AI keveset segít.

Két LogiNet projekt mutatta meg, mit jelent ez a gyakorlatban. Az egyik egy nagy vállalati nyelviskola 2003 óta működő ügyviteli rendszerének kiváltása volt. Ennek a legacy rendszernek az újraírásával egy korábbi beszállító öt év alatt sem végzett, a LogiNet csapata viszont határidőre és a kereten belül maradva vitte végig. Zsigmond becslése szerint coding agentek nélkül a projekt legalább kétszer annyiba került volna. Ehhez a munkához viszont kifejezetten senior fejlesztők kellettek, mély technikai tudással és rengeteg előzetes tervezéssel. Arra a kérdésre, hogy egy junior kolléga is megcsinálta volna-e, háromszor mondott nemet.

A másik projektben az AI egy nagykereskedő e-mailben érkező rendeléseit dolgozza fel, amelyeket korábban emberek gépeltek be. A megoldás rengeteg munkát spórol, és nem volt nehéz megépíteni. Ez azonban csak a projekt „hurráoptimista” olvasata. A realista képhez hozzátartozik, hogy az AI-funkció nem determinisztikus, és az esetek 5–10%-a problémás határterületre esik. Ezeket egy-egy hagyományos bugfix nem feltétlenül oldja meg, mert ahogy Zsigmond mondta, „benyomod itt, kidudorodik valahol máshol”. Az ilyen funkcióknál ezért a fejlesztés mellett a verifikációra és a későbbi supportra is fel kell készülni.

Mennyivel gyorsabb a fejlesztés AI coding agentekkel?

Ha egyetlen mondatból pár óra alatt elkészül egy 3D-s játék, a gyorsulás végtelen, csak épp a játék üzleti értéke nulla. Az igazság az, hogy a szoftver komplexitását máig nem tudjuk mérni. A burkoló tudja, mennyibe kerül 100 négyzetméter, a szoftvernek nincs ilyen mértékegysége. Ugyanazt a projektet pedig senki nem fejleszti le egyszer AI-jal, egyszer anélkül.

Zsigmond ezért a saját tapasztalatát osztotta meg, és kiemelte, hogy mérés nincs mögötte. Egy zöldmezős proof of conceptnél simán 5-10-szeres a különbség. Egy nagyobb, önálló kódbázisban a fejlesztők kétszer-háromszor gyorsabban haladnak. A nagy, szervezetileg nehéz legacy projektekben is segít az AI, csak ott a költséget nem a kódolás határozza meg. A határt a kontextus mérete és a feladat egyedisége jelöli ki.

Zentai Balázs egy nagyobb szervezetből hozott példát. A TOPdesknél nagyjából 170 fejlesztő dolgozik egy terméken, és az elmúlt évben érezhetően több feature fért bele a negyedéves tervekbe. Egy saját MCP szerver segítségével az AI még az 1990-es években írt, egyedi frameworkre épülő legacy kódot is képes kibogozni. A változást a használattal kezdték mérni: januárban szinte nulláról indultak, márciusra a fejlesztők 60-65%-a naponta használta az eszközöket. Közben arra is figyelmeztetett, hogy az AI ma „annyira olcsó, hogy még megtérülésszámítást sem kell végezni rá", de ez nem marad így örökké.

Grünzweig Tamás hozta a másik végletet egy nagy nemzetközi vállalat példájával, ahol felülről írták elő, hogy a team velocity egy hónap alatt nőjön 40%-kal. Szerinte amit egy szervezet látni akar a számokban, azt látni is fogja. Úgy látja, „a hatékonyság csak a fegyelemmel együtt működik”: ha nem mérjük, hogy az AI-jal előállított munka közelebb visz-e a céljainkhoz, hatékonyságról sem beszélhetünk.

Mit bíz az AI-ra egy szoftvercég, és mit nem?

Dávid Zoltán a ConfigCat saját szoftverein mutatta meg, hol húzza meg a határt. A macskás lövöldözős játékot, amelyet a konferenciastandjukra készítettek, teljes egészében AI-ra bízza, mert az üzletnek nem kritikus. Az üzleti döntéseit támogató szimulátort nagyjából 80%-ban, a weboldalt 20% körül, mert az már identitás kérdése. A core termék, vagyis a dashboard és az SDK fejlesztésében az AI legfeljebb a gépelést veszi át.

A szimulátort Zoltán fejlesztőcégtől sosem rendelte volna meg, mert ahogy fogalmazott, „nem tudtam, hogy mit akarok, amikor elkezdtem". Fejlesztés közben jött rá, mire van szüksége, és ehhez az AI-jal fejleszteni volt a legjobb út. A vásárlásnak is megvan a helye: a saját építésű CDN-jüket a cég növekedésével bérelt szolgáltatásra cserélték.

Mutatott egy saját ábrát is arról, hogyan alakul egy ember és egy AI hasznossága a projekt előrehaladtával. Az ember tanul, és egyre hasznosabb lesz. Az AI az elején jobban teljesít, de ahogy nő a komplexitás, „előbb-utóbb többet rombol, mint amennyit épít". Kis, önálló projektbe ezért bátran belevág AI-jal, nagyba ember nélkül biztosan nem kezdene bele.

Hová került a szűk keresztmetszet a szoftverfejlesztésben?

Zentai Balázs az igényre mutatott. Ha a kód gyorsan elkészül, azt is könnyű legyártani, amit senki nem gondolt végig és nem tesztelt az ügyféllel. „Rengeteg szemetet vagyunk képesek emiatt gyártani", mondta, és összességében ez nem lesz olcsó. Grünzweig Tamás hozzátette, hogy régen igenis a fejlesztési kapacitás volt a szűk keresztmetszet, ma pedig az lett a nehéz, hogy megtaláljuk, hol van az érték.

A prototípusból közben kommunikációs eszköz lett. Zoltán este leírja az AI-nak, milyen apró módosítást szeretne. Reggel már működő kóddal mutatja meg a kollégáinak, a jó megvalósítást pedig rájuk bízza. Korábban a szándék elmagyarázása tovább tartott, mint maga a fejlesztés.

A fejlesztő munkája is átalakul. Zsigmond szerint fejlesztőként nem érdemes megpróbálni megjósolni, merre tart az AI: „ne akard kitalálni, mi lesz, mert úgysem tudod”. Sokkal fontosabb érteni, hol tart most a technológia, mire képesek a coding agentek, és mit lehet reálisan elvárni tőlük. Úgy látja, a kódolásból egyre inkább AI agentek felügyelete lesz, sok tervezéssel és sok code review-val.

Volt egy rövid időszak, amikor terjedt az a megközelítés, hogy az AI által generált kódot nem kell elolvasni, elég elfogadni. Zsigmond szerint mára világossá vált, hogy komolyabb fejlesztéseknél a kódot ugyanúgy review-zni és verifikálni kell. Hogy egy funkció működik-e, azonnal kiderül. Hogy karbantartható-e, azt csak a következő öt év mutatja meg, és ezt az AI nem látja előre.

A szoftvertesztelés szerepéről vita alakult ki. Zoltán cége az AI bevezetése után még egy tesztelőt vett fel, mert egyre kevésbé pótolható, hogy egy ember a felhasználó szemével nézze meg a végeredményt. Balázs szerint több tesztelőre nincs szükség. Az automata teszteket ma már az AI is megírja, így az a munkaidő, amit eddig a tesztmérnökök az automatizált tesztelésre fordítottak, a manuális tesztelésre csoportosítható át.

Szó esett az emberi oldalról is. Zoltán fejlesztőinek egy része attól szorongott, hogy elveszíti a munkáját. A cég megígérte nekik, hogy az AI miatt senkit nem küld el. Balázs a fejlesztők helyzetét egyfajta gyászfolyamathoz hasonlította, mert el kell engedniük a fejlesztői szakmáról kialakult korábbi képüket, és új feladatokhoz kell alkalmazkodniuk.

Mi marad versenyelőny, ha bármit le lehet másolni?

Amikor Zoltán elindította a ConfigCatet, három versenytársa volt, ma több mint 30. Mégsem fél. A cég tudatosan kevés dolgot csinál, azt viszont nagyon jól, és az ügyfelek egy része pont azért érkezik, mert nincs szüksége a versenytársak rengeteg funkciójára. Az övék egy kétpengés svájci bicska, a nagy versenytársaké 42 pengés, és az már a zsebbe sem fér. Szerinte ma, amikor „ingyen van az ötlet és ingyen van a megvalósítás”, könnyű mindent megépíteni, ezért az lesz az egyik legerősebb védelem, ha egy cég fegyelmezetten csak arra fókuszál, amit igazán jól csinál.

Tamás két dolgot lát, ami kitart: az elsőként piacra lépés előnyét és a bizalmat. Egy frissen összerakott bank alkalmazásra kevesen bíznák rá a fizetésüket, és a neobankoknak is évekbe telt, mire elnyerték a felhasználók bizalmát. Balázs szerint a szoftver sosem volt igazi védőárok. Az ügyfélkört és azt a visszacsatolást, amit a sok ügyfél ad, sokkal nehezebb lemásolni, mint a kódot.

Build or buy: szoftvert építs vagy vegyél 2026-ban? 

Zsigmond négy helyzetre bontotta a build or buy döntést:

• Ha van rá nagyon jó termék, vedd meg.
• Ha a funkció általános, de a termék rossz, drága, vagy csak a töredékét használod, érdemes megvizsgálni, hogy megépítsd-e. Erre korábban azt mondta volna, hogy ne is gondolkozz rajta.
• Ha a folyamat versenyelőnyt ad, építsd meg. Ami régen túl drága volt, az ma talán kevesebbe kerül, mint amennyit hoz.

A kis, önálló segédeszközöket nyugodtan megépítheted. A LogiNet egy nap alatt csinált magának parkolóhely-foglaló eszközt, amire korábban soha nem szánt volna időt.

Két figyelmeztetést is tett. Ahogy eddig 100 Excel-tábla élt egy cégben, úgy lesz most 100 kódolt eszköz, mindegyik a maga bajával, és ebből karbantartási gond lesz. A várakozásnak pedig ára van, mert a kódolás egy év múlva talán még hatékonyabb lesz, a körülötte lévő munka viszont inkább bonyolódik. A korábban túl drágának ítélt projekteket érdemes most leporolni, legyen az egy régi rendszer kiváltása vagy egy MCP szerver a meglévő ügyviteli rendszerhez, hogy az AI is dolgozni tudjon benne.

A panelen megoszlottak a vélemények a build vs buy kérdésben. Balázs a vásárlás felé hajlott, mert egy szolgáltatás üzemeltetése messze túlmutat a kód megírásán. Kritikus szoftvernél szerinte felértékelődik a megbízható partner, aki szerződésben vállalja, milyen teljesítménnyel és biztonsággal működik a rendszer. Zoltán szerint egy üzlethez legalább egy átlag feletti elem kell. Ha ez az elem a szoftver, egyedit kell csináltatni, ahogy a neobankok is tették.

Mi a tanulság a cégvezetők számára?

Igényből sosem volt hiány, mondta Zsigmond a zárásban. A cégek rengeteg ötletet azért vetettek el, mert úgysem lett volna rá idő. Ha valami könnyebben elérhető, hirtelen több kell belőle, és ma több szoftver készül, mint valaha. Ezek nagy része korábban el sem készült volna. Az AI fejlesztéssel a belépési küszöb alacsonyabb lett, és aki jól dönt, az ezt most ki tudja használni. Ehhez viszont továbbra is szoftveres szakemberek kellenek. A bemutatott projektekben az eredményt ők érték el, és egy utcáról behívott ember nem jutott volna el ugyanoda.

Köszönjük az MVÜK-nek a közös szervezést, a panel résztvevőinek a beszélgetést, és mindenkinek, aki eljött.

Nézd vissza Zsigmond teljes előadását