Kihagyás és továbblépés a tartalomhoz

A prototípustól az éles rendszerig: a 70%-os fal

A híres „70%" mögött **nincs mérés** — a szerző maga írja, hogy egy tweetből vette. Ami viszont mérve van: a cégek **37%-a** tud bármilyen üzemi eredményhatást az AI-nak tulajdonítani, és ez az arány egy év alatt **nem mozdult** — miközben 80% személyesen termelékenyebbnek érzi magát. Ez a fal.
2026. szeptember 13. által
A prototípustól az éles rendszerig: a 70%-os fal
Krisztian Eyssen, Krisztian Eyssen

Honnan jön a 70%, és mi nincs mögötte

A fogalmat egy 2024 végi szakmai írás vezette be, és a szerző szokatlanul őszinte a forrásával:

„Egy tweet, ami nemrég megakadt a szememen, tökéletesen megragadja, amit a terepen látok."

A megfogalmazás így szól: a nem fejlesztők „meglepően gyorsan eljutnak a 70%-ig, de az utolsó 30% a csökkenő hozadék gyakorlata lesz".

Mondjuk ki: a 70% megfigyelés, nem mérés. Nincs mögötte minta, módszertan, publikáció. És nem azt jelenti, hogy az AI a munka 70%-át elvégzi — ezt a számot semmilyen mérés nem támasztja alá.

Ez nem gyengíti a gondolatot, hanem élesíti: a megfigyelés helytálló, a szám kitalált. A valódi mérések máshol vannak — és erősebbek.

A másik szám, amit rosszul idéznek

Ha valaki a megtérülésről beszél, előbb-utóbb előkerül, hogy „az AI-pilotok 95%-a megbukik". Érdemes pontosan tudni, mi ez.

A forrás egy 2025-ös riport, ami 52 strukturált interjún, iparági konferenciákon gyűjtött 153 vezetői kérdőíven és 300-nál több nyilvánosan bejelentett kezdeményezés áttekintésén alapul. Kényelmi minta, nem lektorált, nem reprezentatív.

És amit valójában ír: „a szervezetek 95%-a nulla megtérülést ér el". Ez nem ugyanaz, mint hogy a pilotok 95%-a megbukik.

Egy egyetemi szakértő értékelése a riportról, szó szerint: „Úgy tűnik, nincs további alátámasztás a 95%-os állításhoz. Többször végigolvastam a dokumentumot, és még mindig nem értem, honnan jön."

Amit helyette érdemes idézni

A legjobban dokumentált adat 2026 augusztusából származik: 1 719 válaszadó, 97 országból, a felvétel 2026 május–júniusában.

  • A cégek 37%-a tulajdonít legalább valamekkora üzemi eredményhatást az AI-használatnak.
  • Ez ugyanannyi, mint egy évvel korábban.
  • Mindössze 6% számít élenjárónak.
  • Miközben 80% szerint nőtt a személyes termelékenysége.

Ez a fal egy mondatban: egyéni haszon van, vállalati haszon nincs. Nyolcvan százalék érzi gyorsabbnak magát, harminchét százalék tud bármit kimutatni — és ez az arány egy éve áll.

Van egy előrejelzés is, amit gyakran mérésként idéznek: eszerint 2027 végéig az agent-alapú AI-projektek több mint 40%-át leállítják. Ez becslés, nem adat — de ugyanez az elemzés megjegyzi, hogy a magukat agent-alapúnak nevező több ezer gyártó közül nagyjából 130 kínál valóban agent-képességet.

Mi van a maradék részben?

Négy dologra van kemény mérés, a többire csak gyakorlat. Érdemes megkülönböztetni.

Biztonság — mérve. Több mint száz modellen, négy nyelven: a kódminták 45%-a megbukott a biztonsági teszten, ismert sérülékenységet vezetve be. Nyelvenként nagy a szórás: az egyik nagy vállalati nyelvnél az átmenő arány mindössze 28%. A vizsgálatot vezető szakember mondata: „Miközben a modellek egyre jobbak lettek a működő, szintaktikailag helyes kód írásában, a biztonságos kód írásában semmivel nem lettek jobbak."

Karbantarthatóság — mérve. Egy 623 millió kódváltozást elemző vizsgálat szerint 2022 és 2026 között a refaktorálás aránya a változtatott sorokban 21%-ról 3,8%-ra esett, a kódblokk-duplikáció 81%-kal nőtt, a hibaelnyelő szerkezetek 47%-kal.

Szállítási stabilitás — mérve. A legnagyobb iparági felmérés szerint az AI-adopció pozitívan függ össze az átbocsátással, de negatívan a stabilitással: több hibás változtatás, több újramunka, hosszabb átfutás.

A termelékenység-illúzió — mérve. Egy kontrollált kísérletben tapasztalt fejlesztők AI-val 19%-kal lassabban végeztek, miközben utólag 20%-os gyorsulást éreztek.

És ami nincs mérve: autentikáció, jogosultságkezelés, adatmigráció, hibatűrés, terhelés, megfigyelhetőség, megfelelőség. Ezek a gyakorlatból jönnek, nem mérésből — de a fal nagyobbik fele ezekből áll, és ezért nem lehet számmal megcáfolni.

Mibe kerül üzemeltetni?

Ez az a rész, amiről a legtöbb tévhit kering, ezért érdemes végigszámolni.

Tegyük fel, hogy van egy funkciód — mondjuk ügyfélszolgálati összefoglaló —, ami havi tízezer kérést szolgál ki, kérésenként 4 000 bemeneti és 600 kimeneti tokennel. Ez havi 40 millió bemeneti és 6 millió kimeneti token.

Modellszint Havi inference-költség
Olcsó szint ~15 dollár
Belépő szint ~70 dollár
Középszint ~140 dollár
Csúcsszint ~350 dollár

(Saját számítás 2026. szeptemberi listaárakkal. Képlet: kérésszám × token/kérés ÷ 1 000 000 × egységár, bemenetre és kimenetre külön.)

Tízszeres forgalomnál, középszintű modellel ez havi 1 400 dollár, évi nagyjából 16 800. Ismétlődő kontextus gyorsítótárazásával a bemeneti oldal töredékére csökkenthető; aszinkron kötegelt feldolgozásnál további jelentős kedvezmény jár.

A nagyságrendi tanulság: a token nem a drága rész.

És most jön, ami nincs benne ebben a számban:

  • hosting, adatbázis, vektoradatbázis, monitorozás, naplózás;
  • az újrapróbálkozások és az agent-körök — egy agent-futás nem egy hívás, hanem tíz-száz; a szorzó könnyen tíz-ötvenszeres;
  • a kiértékelő futtatások, amik fejlesztés közben gyakran többet fogyasztanak, mint az éles forgalom;
  • az emberi felülvizsgálati hurok — ez a legdrágább tétel, és nem tokenben mérik;
  • és a modellárak változása.

A 70%-os fal tehát nem azért fal, mert drága a token. Azért fal, mert a maradék rész embert, tesztet, felelősséget és üzemeltetést igényel — és ezek közül egyik sem lesz olcsóbb attól, hogy a prototípus két nap alatt megvolt.

A fal anatómiája

AMI KÉT NAP ALATT MEGVAN
  működő képernyők, alap adatmodell, a boldog út
  -> ez az, amit a demón látsz

AMI AZTÁN JÖN
  autentikáció és jogosultság       (ki mit láthat)
  adatmigráció                      (mi legyen a régivel)
  hibatűrés és visszaállítás        (mi van, ha elszáll)
  terhelés                          (mi van, ha sokan jönnek)
  megfigyelhetőség                  (honnan tudod, hogy elszállt)
  megfelelőség                      (ki felel érte)
  BIZTONSÁG                         (mért: 45% bukási arány)
  KARBANTARTHATÓSÁG                 (mért: duplikáció +81%)

EZ NEM 30%. Ez az a rész, amiért a szoftver szoftver.

Hogyan lehet mégis átjutni

Nem varázslattal. Három dolog van, amire a mérések mutatnak:

  • Az élenjárók újratervezték a folyamatot, nem beillesztették az AI-t a meglévőbe. A fenti, 1 719 válaszadós felmérésben a legjobban teljesítők közel háromnegyede alapjaiban alakította át a munkafolyamat ot.
  • Az ellenőrzési kapacitást előre kell megtervezni. Ha a kód mennyisége nő, de az átvizsgálásé nem, a fal magasabb lesz, nem alacsonyabb.
  • A prototípus nem előszakasza az éles rendszernek, hanem külön termék. A legolcsóbb döntés gyakran az, hogy a prototípust eldobod, és a tanultakkal kezdesz neki újra.

Tipikus félreértések

  • „Az AI a munka 70%-át elvégzi." Ezt a számot semmilyen mérés nem támasztja alá; a szerzője maga írja, hogy egy tweetből vette.
  • „A pilotok 95%-a megbukik." A forrás azt írja, hogy a szervezetek 95%-a nulla megtérülést ér el — és ez 52 interjúból és konferenciákon gyűjtött 153 kérdőívből jön.
  • „Nálunk működik, mindenki gyorsabb lett." Nyolcvan százalék érzi így. Harminchét százalék tud bármilyen eredményhatást kimutatni.
  • „Drága lesz üzemeltetni a modellt." Maga az inference tíz és néhány száz dollár között van egy közepes forgalmú funkciónál. Az agent-körök, a kiértékelés és az emberi ellenőrzés a drága.
  • „Majd a következő modell átviszi a falon." A fal nagyobbik fele autentikáció, migráció, terhelés és felelősség. Ezeken egy jobb modell nem segít.

Amit érdemes elvinni

A 70% nem mért szám, a mögötte lévő megfigyelés viszont igaz — és a valódi mérések keményebbek nála: egyéni termelékenység nyolcvan százaléknál, kimutatható üzleti hatás harminchétnél, egy éve változatlanul. A maradék rész nem a modellen múlik, hanem emberen, teszten, üzemeltetésen és felelősségen. A token olcsó; a bizonyítás drága.

Hogy hol van a határ, ameddig érdemes elfelejteni a kód létezését, arról a vibe coding valósága poszt szól; a megvenni-vagy-megépíteni döntésről az új számítás poszt; az üzemeltetési oldalról pedig a DevOps AI-val poszt.

A prototípustól az éles rendszerig: a 70%-os fal
Krisztian Eyssen, Krisztian Eyssen 2026. szeptember 13.
Poszt megosztása
Archiválás