Az MI gyorsítja a fejlesztést, mégis 42% kiégettebbnek érzi magát

A Terminal szeptember 24-i közleménye szerint a 2026-os State of Remote Engineering felmérésben több mint 1800 szoftvermérnök vett részt: 77% úgy érzi, hogy az MI növelte a nagyobb értékű munkára fordítható kapacitását, 42% pedig kiégettebbnek érzi magát, mint egy évvel korábban; Dylan Serota vezérigazgató ezt mondta: „the job has to get better, not just faster”. A gyorsabb fejlesztés és a fokozódó kimerültség így ugyanannak a munkakörnyezetnek két tapasztalata.

A felmérés a szoftverfejlesztés MI-vel átalakuló munkafolyamatát, a mérnökök közérzetét és a felvételi kilátásokat vizsgálja. Az adatok válaszadói tapasztalatokat rögzítenek: a nagyobb kapacitás nem mért vállalati termelékenység, a kiégettebbnek érzett állapot pedig nem önmagában orvosi diagnózis. A számok közti kapcsolat megértéséhez azt is látni kell, melyik feladat gyorsul, és hová kerül át a figyelmet igénylő munka.

A gyorsulás érzékelt kapacitás, nem kész termék

A mérnök több időt fordíthat bonyolultabb problémára, ha az MI előállít egy első kódváltozatot vagy segít egy rutinműveletben. Ez valódi könnyebbség lehet a saját munkanapjában, de más mérce, mint a felhasználóhoz eljutó, stabil funkciók száma. Az elkészült változtatást meg kell érteni, össze kell illeszteni a meglévő rendszerrel, és ellenőrizni kell a következményeit.

A felmérés külön kérdésként kezeli a nagyobb értékű munkára érzett kapacitást és az előző évhez viszonyított kiégést. A két válaszcsoport részben átfedhet, ám a közzétett összesítésekből nem olvasható ki, pontosan kik és milyen arányban tartoznak mindkettőbe. A jelenlegi állapotról szóló válaszok nem bizonyítják, hogy az MI használata okozta a kimerültséget; a teljes munkaterhelést a határidők, a feladatok száma és a csapaton belüli felelősség is alakítja.

A különbség a vezetői döntésnél számít. Ha az új eszköz miatt gyorsabban születnek első változatok, az még nem mondja meg, hogy a csapat gyorsabban zár le ügyeket, kevesebb hibát enged át, vagy több pihenőidőhöz jut. A kapacitás emelkedése könnyen új vállalások alapjává válhat még azelőtt, hogy kiderülne, mennyi emberi ellenőrzést kíván az új munkatempó.

A kódírás után szűkülhet be a munkafolyamat

Az MI-vel készített módosításokat ugyanúgy felül kell vizsgálni és tesztelni, mint a kézzel írt kódot. Ha több változtatás érkezik ugyanahhoz a néhány tapasztalt ellenőrzőhöz, a kód előállításán nyert idő a várakozásban és az egyeztetésben veszhet el. A felülvizsgálónak nemcsak a sorokat kell átolvasnia: meg kell értenie a kívánt működést, a rendszer korábbi döntéseit és azokat az eseteket is, amelyeket az első változat nem kezel.

A The Founders Report elemzése a Terminal eredményeit a munkakörök változásával köti össze: a rutinszerű kódírás egy részének automatizálása mellett a felülvizsgálat és a műszaki mérlegelés nagyobb súllyal kerülhet a tapasztaltabb fejlesztőkre. Ez értelmezés, nem a Terminal által mért ok-okozati eredmény. Mégis megmutatja, miért nem azonos a gyorsabban elkészült kód a kisebb mentális terheléssel.

Az ellenőrzés költsége nemcsak a hibakeresésből áll. Egy változtatás több csapatot vagy szolgáltatást érinthet, a teszt eredményeit értelmezni kell, majd dönteni kell arról, hogy a módosítás beilleszthető-e a kiadásba. Több párhuzamos feladat mellett az ismételt kontextusváltás a fejlesztő figyelmét aprózza fel. Így az első változat gyorsulása mellett az egész feladat lezárása akár változatlanul lassú maradhat; ez lehetséges munkaszervezési következmény, nem a felmérésben igazolt mérési eredmény.

A felvételi várakozások nem ugyanazt jelentik minden régióban

A Terminal régiós bontásában az amerikai mérnökök 53,9%-a várja, hogy az MI hosszabb távon növeli a szoftverfejlesztői felvételeket, míg Latin-Amerikában 41,2%, Európában 32,7%, Kanadában 28,9% számít erre. Ezek az arányok a mérnökök várakozásai, nem a később ténylegesen létrejövő állások előrejelzései. Az európai érték a magyar olvasónak régiós támpont, de nem külön magyarországi adat.

A különbségek azért fontosak, mert egyéni kapacitásból nem következik automatikusan létszámnövekedés. A munkáltató a felszabaduló időt új termékfeladatokra, részletesebb minőségellenőrzésre vagy a meglévő csapat határidejének rövidítésére is fordíthatja. Más régiókban a mérnökök eltérően ítélhetik meg, melyik vállalati válasz valószínű. A felmérés a várakozást rögzíti, a munkáltatói döntést és a későbbi foglalkoztatási eredményt külön kell majd megfigyelni.

Az új terhelés a teljes fejlesztési folyamatban látszik

A csapat szintjén az a döntő kérdés, hogy a gyorsabb előállítás után marad-e elegendő idő a felelős döntésekre. Ehhez a puszta kódmennyiség vagy az elkészült első változatok száma kevés. A vezetői ellenőrzésnek a változtatás útját kell követnie az első javaslattól a beolvasztásig, valamint azt, hogy az emberek mennyi megszakítás nélkül végezhető munkát kapnak.

• Hosszabbodik-e a változtatás elkészülte és az érdemi felülvizsgálat közti idő, illetve nő-e a várakozó módosítások sora?
• Több javítási kör kell-e a beolvasztáshoz, és mennyi ellenőrzői időt visznek el az MI segítségével készült változatok?
• Marad-e tervezett idő tesztelésre és rendszertervezésre, vagy minden gyorsulás után új feladat kerül a csapathoz?
• Hogyan alakul a jelzett túlterheltség, az ügyeleti munka és a szállítási ütem ugyanabban az időszakban?

Ezek helyi munkaszervezési mutatók, nem a felmérés további eredményei. Akkor válnak hasznossá, ha a csapat a gyorsabban elkészült kód mellé az ellenőrzési kapacitást és a vállalt határidőket is igazítja. Ha a változtatások egyre hosszabb ideig várnak felülvizsgálatra, az új kapacitás terhe már a kiadás előtt megjelenik a fejlesztők napjában.

Olvassa el ezt is:

• Duplázódott az MI-képzés, mégis 56% munkaidő nélkül tanulna
• Ollama vagy LM Studio: ugyanaz a modell, mégis más munkafolyamat