Claude Code minden mérnököt hármassá alakított. Most a cégeknek több terméktervezőre van szükségük.

Az Anthropic nemrég a növekedési csapatának azt mondta, hogy ne kevesebb, hanem több termékmenedzsert alkalmazzanak. Az iparági beszámolók szerint ennek az az oka, hogy a Claude Code csendben átformálta mérnöki szervezetét egy olyan csapattá, amely körülbelül háromszor annyit szállít, mint amennyi valójában a létszáma. A szűk keresztmetszet a korábbi integrált fejlesztési környezetről (IDE) a termékek kiválasztására váltott. Ezt a részletet könnyű elhanyagolni az AI termelékenységi állítások zajában. Ez az iparág többi része által most megélt strukturális váltás is. A szoftvereknél már nem a gépelés a szűk keresztmetszet. A döntések meghozatala vált azzá. Azok a mérnökök, akik ezt mások problémájaként kezelik, hamarosan megrekednek. Az utolsó évtized legnagyobb részében ez a döntés valaki más kezében volt. A szoftverfejlesztés egy olyan mesterség volt, amelyet lassan sajátítottál el, majd egy hosszú, kiszámítható sorrendben gyakoroltál: mélyen velemerültél a technológiába, megírtad a kódot, Stack Overflow-t kérdeztél, ha elakadtál, továbbítottad egy magasabb szintű mérnöknek, amikor a Stack Overflow nem segített, majd elküldted a jegyet. A termékmenedzser birtokolta a tölcsért. A mérnök birtokolta az építést. Mindkét fél ezt a megosztást fizikai törvényként kezelte. Aztán a tölcsér öt lépésben megbukott.

A mérnökök napjának összesűrítése rövid története

A Stack Overflow korszaka (2014-től 2022 végéig): Az, ahogyan a mérnökök gondolkodtak, egy helyen élt. De az új havi kérdések száma a Stack Overflow-n körülbelül 77%-kal csökkent 2022 novemberétől, ami nem véletlen, hiszen akkor indult a ChatGPT. A csökkenés nem egy referendum a weboldalról. Ez egy referendum az általa képviselt munkafolyamatról. A böngészőfül korszaka (2022 vége - 2024): Az első ChatGPT-generáció az IDE-n kívül ült. A mérnökök ugyanazt a ciklust futották, mint régen, csak egy gyorsabb orákulum mellett: Írj egy kérést a böngészőben, másold be a választ a VS Code-ba, ismételd. A munka még mindig egy szálon futott és mérnök-vezérelt volt. A tőke valós, de helyi volt. Az IDE-hez kötött korszak (2024-2025): A Cursor és a Claude Code a modellt a szerkesztőbe helyezte és hozzáférést biztosított a teljes repozitóriumhoz. A magasabb szintű mérnöki eszkalációs útvonal nagyrészt megszűnt. Évekig a tapasztalt mérnökök körében elterjedt vélemény volt, hogy a Bash a legnagyobb eltarthatósággal rendelkező eszköz a stackben. 2026-ra a dolgozó fejlesztők jelentős hányada számára az első parancs, amelyet egy friss terminálban beírnak, a claude. A specifikáció-vezérelt korszak (2025-2026): A nagyobb kontextusablakok az egy munkamenetes munkát olyan dologgá alakították, ami korábban jegyeket, tervezési dokumentumokat és sprinteket igényelt. Az Amazon Kiro IDE csapata állítólag a jellemzően kéthetes funkciófejlesztéseket két napra zsugorította, a szállított specifikációs munkafolyamat használatával. Az AWS mérnöki csapata egy 18 hónapos újratervezésről számolt be, amelyet eredetileg 30 mérnökre terveztek, de 6 ember 76 nap alatt befejezte. A szűk keresztmetszet már nem az volt, hogy mennyi időbe telik a kód megírása. Az lett, hogy a csapat mennyire világosan tudja leírni, hogy mi a helyes. A rutinok korszaka (2026): Áprilisban az Anthropic kiadta a Claude Code Routines-t: Ütemezett, folyamatos ügynökök, amelyek egy ütemterv szerint futnak, webhorgon vagy éjszaka, amíg a laptop zárva van. A Cron visszatért. A horgok visszatértek. A mérnökök feladata most részben az szervezés: egy rajot feléleszteni lefekvés előtt, áttekinteni egy halom pull requestet reggel. Harmadik féltől származó burkolók, mint például az OpenClaw, amelyet az Anthropic áprilisban rövid időre felfüggesztett, majd részlegesen visszaállítottak, ugyanazt az üzenetet közvetítették az open-source oldalról. A szűk keresztmetszet áthelyeződött; a legtöbb csapat nem. A mérnöki létszám körülbelül háromszorosára nőtt. A termékmenedzsment nem változott. A hagyományos 1:8 arányú PM-ek és mérnökök az már eddig is megfeszítette, most közelebb áll az egy hatékony 1:20 arányhoz, mert minden mérnök naponta többet szállít. Például a LinkedIn lecserélte az asszisztens termékmenedzser pályát egy "Terméképítő" programra, amely általános területeken képez általánosokat, a termék, tervezés és mérnöki területeken. Az Anthropic több PM-et alkalmaz, nem kevesebbet. A minta következetes a valóban ügynöki munkafolyamatokat a gyakorlatban bevezető cégeknél: A rendszer gyorsabban termel kiépült funkcionalitást, mint amilyen gyorsan döntéseket hoz arról, hogy mit kellene építeni. A mérnökök számára ez a legfontosabb karrierjelzés az évtizedben, és a legkönnyebb kihagyni, míg a termelékenységi történetek dominálnak az információs áramlásban.

Az alapelvek most fontosabbak, nem kevésbé

Az az ösztön, hogy az alapokat elavultnak nyilvánítsuk az ügynöki korszakban, pont a trendet rontja el. Amikor egy memória szivárgás miatt 3 órakor leáll a termelés, és kiderül, hogy a kiváltó ok egy négy évvel ezelőtti apró tulajdonosi hiba, akkor jelenleg nincs olyan ügynök, aki zárni tudja ezt az összefüggést a kezdettől a végéig. Az operációs rendszerek, hálózatok, párhuzamosság és lekérdezési tervek továbbra is eldöntik, ki képes egy valós eseményt kezelni. Arról is döntenek, ki tudja észrevenni azokat a pillanatokat, amikor egy ügynök kimenete felszínen helyesnek tűnik, de csendesen, drágán rossz a mélyben. Az az ügynök, aki a modern repozitórium 70%-át írta, nem képes megbízhatóan megmondani bárkinek, hol tért el az elképzelése a szálbiztonságról, memóriahasználatról vagy tranzakciós izolációról a futási időtől. Az a mérnök, aki képes olvasni a különbségeket és észrevenni ezt, az a mérnök, akire a csapat többi tagjának szüksége van a teremben, és ez a mérnök az alapelveken alapul, nem a megfogalmazás képességén. Az ebből következő dolog, hogy az alapelvek most tőke képességgé váltak, nem pedig higiéniás képességgé. 2014-ben, ha tudtad, hogyan működik a TCP retransmit, gyorsabban zártál le egy hibaelhárító jegyet. 2026-ra ugyanaz a tudás megakadályozza, hogy egy egész ügynök által vezérelt kiadás során regressziót szállítsanak nagy méretben. Az a mérnök, aki tudja, mi történik a háttérben, növelte a robbanás körzetét.

A felülvizsgálat az új írás

A mérnökök 2026-ban olyan sebességgel generálnak kódot, amely meghaladja azt az ütemet, amit bármelyikük alaposan el tudna olvasni. Az a csapat, amely gyorsan szállít és túlél, az az lesz, amelynek mérnökei az AI-generált kód felülvizsgálatát legalább olyan szigorral kezelik, mint amit korábban az írásra tartogattak. A 2025-ös Stack Overflow fejlesztői felmérés azt mutatta, hogy a fejlesztők 84%-a használ AI eszközöket, 46%-uk azonban nem bízik az eredményben, ami éles emelkedés az előző év 31%-ához képest. Ez a szakadék, az intenzív használat és az alacsony bizalom párosa, pontosan ott van, ahol a felülvizsgálati képességek most a legfontosabbak. Azok a programozók, akik sokat nyomnak és keveset végeznek felülvizsgálatot, olyan adósságot halmoznak fel, amely a következő valódi esemény során esedékessé válik, és az a mérnök, aki ezt kifizeti, az, aki párosítja a mennyiséget a rendszerekkel kapcsolatos mély elsődleges elvekkel.

Az új megkülönböztető jegy a termék tölcsér

Mindkettő szükséges. Egyik sem elegendő. Az a mérnök, aki számít 2026-ban, az az, aki abbahagyta a várakozást, hogy a tölcsér Jira-jegyként érkezzen. Ez azt jelenti, hogy olyan dolgokat kell tennie, amelyeket a szerepe történelmileg megengedett, hogy kihagyjon. Beszélgessen az ügyfelekkel. Figyelje, hogyan használják valóban a terméket. Olvassa el a támogatási sort. Vegyen részt az értékesítési híváson. Az a jel, amit egy termékcsapat három réteg összefoglalón keresztül kap, most egy mérnök számára egy délután alatt elsőkézből érkezik. Generálj ötleteket, ne csak becsléseket. Az a termékmenedzser, aki korábban 8 mérnök számára gyűjtött ötleteket, már nem tud 20-nak ugyanazon a pontossági szinten ötleteket adni. Az a mérnök, aki validált, behatárolt lehetőséggel érkezik, már nem végzi a PM feladatát. A mérnök a feladatot végzi el, amit az új arány megkövetel. Dolgozzon visszafelé az ügyféltől. Az Amazon már két évtizede először a sajtóközleményt írja. A fegyelem jól átültethető egyes csapatokra és ügynökcsapatokra is. Mindkettő sok működő szoftvert termel a rossz irányba, anélkül, hogy világos nyilatkozat lenne arról, mit jelent a "ügyfélgyőzelem" bármiféle kód írása előtt. Ne bújj a kapacitás mögé. Az őszinte válasz arra a kérdésre, hogy "Van kapacitásod erre az ötletre?", régen "Nem" volt. A rutinokkal, horgokkal és együttműködő ügynökstackkel az őszinte válasz közelebb áll ahhoz, hogy "Mennyit ér az ötlet?" Ez egy másfajta beszélgetés, és sokkal nehezebb, ha nincs valódi nézőpontod az ügyfélről.

A következő évtized jutalmaz

A fenti öt fázisú történet valójában nem az eszközökről szól. Ez egy olyan történet, amely arról szól, hogy a munka mely részét kellett az embernek elvégeznie. Az a rész, amely még mindig emberi, és amely a közeli jövőben is emberi marad, feljebb került a tölcsérben: A gépelésből, a felülvizsgálatból, a döntéshozatalból, a kiválasztott ügyfélből, akit kiszolgálni kell és a problémából, amelyet meg kell oldani. A 2026-os nagyszerű mérnök nem az, aki a legtöbb kódot írja. Hanem az, aki tudja, mit kell építeni, tudja igazolni, hogy érdemes építeni, és rendelkezik az ügynökflottával, valamint a felülvizsgálati szigorról, hogy szállítani tudja anélkül, hogy a rendszer a saját sebessége alatt összeomlana. Azok a mérnökök, akik ezt magukévá teszik, a következő évtizedet a szoftverek legérdekesebb munkájával fogják tölteni. Azok a mérnökök, akik egy jegyre várnak, azt fogják eltölteni, hogy figyelik, ahogy a mellettük ülő ügynök megírja a jegyet. Ishan Gupta egy szoftverfejlesztő az Amazonnál.