Az utóbbi évek eszközfejlődése — különösen a modellek szerkesztőbe integrálása és az agentikus munkafolyamatok bevezetése — alapjaiban átalakította a mérnöki munkát. A bottleneck (szűk keresztmetszet) már nem a begépelés vagy a kód írásának sebessége: a korlát most az, hogy ki és milyen részletességgel dönt arról, mit kell építeni.
Mi történt (ki, mikor, miért számít)
Anthropic példáján keresztül megfigyelhető a jelenség: belső visszajelzések szerint a Claude Code használata azt eredményezte, hogy egyes mérnöki csapatok nagyjából háromszoros sebességgel szállítanak azon mérnökfejlétségükhöz képest. Ennek következtében a szűk keresztmetszet az IDE-ről azokhoz a személyekhez tolódott, akik meghatározzák, mit kell fejleszteni — azaz a döntéshozatal lett a legfőbb korlát.
Rövid történet: hogyan tömörödött a mérnök napi munkája
- Stack Overflow korszaka (2014–2022 vége): a mérnökök munkafolyamata sokáig egyfajta lineáris rutin volt — beleásni magukat a technológiába, kódolni, ha elakadnak Stack Overflow, majd tapasztaltabb kolléga segítsége. Az új kérdések havi száma a Stack Overflow-n körülbelül 77%-kal esett vissza 2022 novembere óta, ami egybeesik a ChatGPT megjelenésével; ez nem a webhelyről szól, hanem az azt tükröző munkafolyamatról.
- Böngésző-alapú AI korszaka (2022 vége–2024): az első ChatGPT-generáció az IDE-n kívül működött: promptot írtak a böngészőben, bemásolták a választ a szerkesztőbe, és ismételték. A folyamat még mindig egy-egy mérnök által hajtott, de gyorsabb lett.
- IDE-native korszak (2024–2025): eszközök mint Cursor és Claude Code a modelleket az editorba helyezték, hozzáférést adva a teljes repóhoz. A senior mérnöki „escalation” útvonal sok esetben megszűnt; a korábbi gyakorlat, miszerint a Bash a leghosszabb életű eszköz, egyes fejlesztők számára 2026-ra megváltozott úgy, hogy az első parancs egy terminálban gyakran már "claude".
- Spec-driven korszak (2025–2026): a nagyobb kontextusablakok lehetővé tették, hogy egy munkamenetben kezeljenek olyasmit, ami korábban jegyeket, design dokumentumokat és sprintet igényelt. Az Amazon Kiro IDE csapatáról jelentették, hogy a funkciók építését két hét helyett két napra tömörítették hasonló, specifikációközpontú munkafolyamattal. Egy AWS mérnöki csapat állítása szerint egy 18 hónapra tervezett átépítést — eredetileg 30 mérnök becsült létszámával — hat ember fejezett be 76 nap alatt. Ekkor a korlát már nem a kód megírásának hosszában volt, hanem abban, mennyire világosan lehet meghatározni, mit jelent a helyes eredmény.
- Rutinok korszaka (2026): 2026 áprilisában az Anthropic piacra dobta a Claude Code Routines-t: ütemezett, perzisztens ügynököket, amelyek időzítve, webhookon vagy éjszaka futva dolgoznak. Visszatért a cron és a hook-nyelv. Harmadik féltől származó wrapper-ek, például az OpenClaw (amelyet részben felfüggesztettek, majd részben visszaállítottak), az open-source oldalon hasonló következtetésre vezettek.
A bottleneck eltolódott; a szervezetek nagy része nem követte
A mérnöki termelékenység lényegében megtriplázódott ott, ahol ezeket az agentikus munkafolyamatokat élesben bevezették. Ezzel szemben a termékmenedzsment létszáma nem emelkedett arányosan: a hagyományos 1:8 PM–mérnök arány, amely már korábban is feszült volt, most gyakorlatilag inkább 1:20 hatékonyságként jelenik meg, mivel egy mérnök sokkal több dolgot képes szállítani naponta. Például a LinkedIn megszüntette az associate product manager pályát, és bevezette a "Product Builder" programot, ami általánosabb készségeket ad termék, dizájn és mérnöki területeken. Anthropic pedig több termékmenedzsert vesz fel, nem kevesebbet.
A mintázat konzisztens azzal, amit azok a cégek látnak, amelyek élesben használnak agentikus munkafolyamatokat: a rendszer gyorsabban állít elő kész funkciókat, mint ahogy születnek a döntések arról, mit kell építeni.
Mit jelent ez a mérnökök karrierje szempontjából?
- Alapelvek fontossága nőtt: az operációs rendszerek, hálózatok, konkurencia és lekérdezés-tervek továbbra is meghatározzák, ki tud megoldani egy valódi incidenst. Egy ügynök, amely a modern repó 70%-át írta, jelenleg nem megbízható abban, hogy hol tévedett a szálbiztonság, memória-ownership vagy tranzakciós izoláció feltételezéseiben; ezeket a hibákat a fundamentumok ismerete alapján kell észrevenni és javítani.
- Az alapelvek ezentúl tőkehatású képesség (leverage skill), nem csupán alapkövetelmény. Ami 2014-ben gyorsabb hibakeresést jelentett, 2026-ban egész agent-vezérelt release-pipeline-okat képes megvédeni regresszióktól.
- Review lett a fő írás: 2026-ra a mérnökök által generált kód mennyisége meghaladja azt, amit bármelyikük alaposan el tud olvasni. A csapat, amelyik gyorsan szállít és túléli, az, amelyik legalább ugyanazzal a rigorizitással vizsgálja át a gépi kódot, mint korábban az ember által írt kódot.
Példaszámok a bizalom-hiányról: a 2025-ös Stack Overflow fejlesztői felmérés szerint a fejlesztők 84%-a használ AI-eszközöket, de 46%-uk nem bízik az outputban — ez jelentős növekedés a 2024-es 31%-hoz képest. A nagy használat és az alacsony bizalom közti rés az a terület, ahol a review-készségek ma a legtöbbet számítanak.
Az új megkülönböztető: a termék-funnel
A két előző csoport képesség együtt szükséges, de önmagukban nem elégségesek. A 2026-ban értékes mérnök olyan, aki nem várja passzívan, hogy egy Jira-jegy érkezzen. Tud beszélni ügyfelekkel, megfigyelni a termék használatát, olvasni a support sorokat, vagy részt ülni egy értékesítési híváson — olyan közvetlen jeleket kaphat így, amelyeket korábban három összefoglaló rétegen keresztül kapott volna a termékcsapat.
A mérnököknek öt tevékenységet kell elkezdeniük végezni, amelyeket korábban el lehetett kerülni:
- Beszélni az ügyfelekkel; megérteni a tényleges használatot.
- Ötleteket generálni, nem csak becsléseket adni. Egy PM, aki korábban 8 mérnöknek adott ötleteket, nem tud azonos részletességgel ötletet szolgáltatni 20 mérnöknek.
- "Work backwards" szemlélet alkalmazása: a customer-centric célok korai és világos meghatározása kritikus.
- Ne a kapacitás mögé bújni: a válasz ma ritkán 'nincs kapacitás', sokkal inkább az lesz, hogy "mit ér ez az ötlet?" — sokkal nehezebb beszélgetés, ami valódi nézőpontot kíván az ügyfélről.
Mire fizet majd rá a következő évtized?
A technológiai fázisok története valójában arról szól, melyik munkafázis marad emberi kötelesség. Az, ami emberi marad és emberi marad a közeljövőben is, feljebb mozdult a funnelban: a begépeléstől a review-n át a döntéshozatalig, majd az ügyfél és a probléma kiválasztásáig.
A 2026-os "nagyszerű mérnök" nem az, aki a legtöbb kódot írja, hanem az, aki tudja, mit kell építeni, bizonyítani tudja, hogy érdemes megépíteni, és rendelkezik az ügynökflottával és a review-fegyelemmel, hogy gyorsan és biztonságosan szállítsa azokat a változtatásokat.
Azok a mérnökök, akik elsajátítják ezeket a készségeket — alapelvek, review-képesség, ügyfélorientált gondolkodás — a következő tíz évben a legérdekesebb munkákat fogják végezni. Akik továbbra is jegyre várnak, azzal töltik majd az évtizedet, hogy nézik, amint a jegyet az ő ügynökük írja meg.
Szerző
Ishan Gupta, software engineer, Amazon.
