Ha ma elveszed a fejlesztőtől a kódoló AI-t, sokaknál nem „lassabb nap” lesz belőle, hanem „inkább nem is csinálom”. Csakhogy a sebesség ára gyakran később jön meg: hibákban, javításokban és dráguló üzemeltetésben.

Mi történt

Egy friss kutatási próbálkozás meglepő falba ütközött: a METR (egy ismert AI-kutatólab) 2026 februárjában arról számolt be, hogy a fejlesztők többsége nem volt hajlandó részt venni olyan feladatokban, ahol akár csak korlátozottan is, de AI nélkül kellett volna dolgozni.

A helyzet pikantériája, hogy a labornak volt már egy korábbi, 2025-ös produktivitási vizsgálata nyílt forráskódú fejlesztőkkel: a résztvevők úgy érezték, az AI-tól gyorsabbak lettek, a mérések viszont azt mutatták, valójában lassultak. Az AI ugyan hamarabb „kidobta” a kódot, de több idő ment el a hibák felderítésére és javítására, az eszköz terelgetésére (promptolás, pontosítás), illetve a várakozásra, amíg lefut.

Mivel az ismétlés nem jött össze, a METR végül egy májusi felmérésre támaszkodott, ahol technikai munkakörben dolgozók önbevallás alapján értékelték a hatást. A válaszadók jellemzően úgy látták, az AI nagyjából kétszer értékesebbé teszi őket a szervezetük számára.

Miért fontos

Az önérzetes „kétszeres hatékonyság” jól hangzik, de a szoftverfejlesztésben a valódi költség ritkán az első verzió leírása. Gondolj rá úgy, mint egy autóra: nem az a drága, hogy legyártják, hanem hogy évekig szervizelni kell. Ha az AI-val gyorsabban írsz kódot, de közben több rejtett hibát és nehezebben érthető megoldást termelsz, akkor a karbantartás (bugfix, refaktor, kompatibilitás, biztonsági foltozás) „kamatos kamattal” jöhet vissza.

Ezt a képet erősítik a 2026-os „tokenmaxxing” tanulságai is: sok helyen a felhasznált tokenek (az AI-modellek által feldolgozott szöveg egységei, ami a költségek és a használat egyik mérőszáma) alapján próbálták mérni a produktivitást, de kiderült, hogy a több AI-használat nem automatikusan több érték. Belső ranglistákat lehet „meghekkelni” túlzott használattal, miközben a számla nő, a kézzelfogható output nem.

Mire figyelj

  1. Mérőszámok: token ≠ érték – Érdemes figyelni, mivel mér a cég: a tokenfogyasztás vagy a lezárt, stabilan működő funkciók, csökkenő hibaszám és rövidülő átfutási idő számít-e.
  2. AI mint „junior fejlesztő” – A legéletszerűbb működési modell az, hogy az AI gyorsan termel, de szoros review kell. Nem „átadod és elfelejted”, hanem úgy ellenőrzöd, mintha egy új kolléga commitolna.
  3. QA és karbantartás: előre beárazni – Erősebb tesztelés (automata tesztek, statikus elemzés, kódreview-folyamat) nélkül a gyors kódolás könnyen lassú üzemeltetéssé válik.
  4. Emberi fókusz: architektúra és biztonság – A nagy képet (rendszerterv, adatáramlás, jogosultságok, fenyegetési modell) nem érdemes kiszervezni. Ezek a döntések határozzák meg, hogy a későbbi hibák olcsók vagy fájdalmasak lesznek.

A TechCrunch AI által idézett kutatási és iparági jelek alapján a kérdés már nem az, hogy használsz-e AI-t fejlesztéshez, hanem az, hogy tudsz-e mellette ugyanúgy felelősen mérni, ellenőrizni és karbantartható rendszert építeni.