A legjobb fejlesztőd már alig ír kódot

Mostanában két skill trendi a fejlesztők között: a Caveman és a Ponytail. Mindkettő ugyanazt a fájó pontot célozza - hogy az AI agent hajlamos túltervezni és a kelleténél több kódot kiköpni. A Caveman gyakorlatilag annyit mond a modellnek, hogy fogd vissza magad, és írj kevesebbet. A Ponytail finomabb: ad neki egy döntési létrát, hogy előbb tegye fel a kérdést - egyáltalán érdemes-e ezt megírni.

Ahogy néztem őket, két dolog tűnt fel. Az egyik, hogy önmagában már ez is szembemegy a mai AI-metrikákkal, amik épp a több outputot, több tokent, több sort jutalmazzák. A másik, hogy én még ezeknél is nagyobban gondolkodnék. Mert a kérdés szerintem nem az, mekkora a kódrészlet, amit az agent legenerál - hanem hogy az adott dolgot egyáltalán meg KELL-e építeni.

Erről jutott eszembe egy jelenet. Egy team lead a managerével szemben ülve építi az érvelést, hogy az egyik fejlesztőjét performance improvement planre tegye. A számok már készen álltak: commitok száma a csapat alján, kódsorok száma a csapat alján, és az a bizonyos AI usage dashboard, amit ma mindenki néz, alig pislákolt a többiekhez képest. Minden metrika ugyanazt mondta - ez az ember bizony kiszállt.

A manager ekkor ránézett a képernyőre, és feltett egy kérdést, ami gyorsan rövidre zárta a beszélgetést: „Nem ő az, aki megfúrta a billing rewrite-ot?"

A számok megalapozták az érvelést

Persze érdemes igazságosnak lenni azzal a dashboarddal, mert nem hazudott. A fejlesztő tényleg kevesebb kódot szállított, mint bárki más a csapatban. Kevesebb commit, kevesebb merge-elt pull request és jóval kevesebb sor.

A team lead karrierjének nagy részében ez valódi jelzés lett volna. Amikor a kód megírása volt a szoftverépítés lassú, nehéz része, általában az vitte a legtöbbet a hátán, aki a legtöbb működő kódot szállította. A korreláció sosem volt tökéletes, de elég közeli ahhoz, hogy senki ne kérdőjelezze meg. Az output mérése nem lustaság volt - észszerű rövidítés egy olyan világban, ahol az output drága.

Csakhogy a világ megváltozott, a műszer pedig nem.

A döntés, ami nem hagyott nyomot

Három héttel a review előtt ugyanez a fejlesztő egy másik meetingen ült: a következő nagy feature tervezésén, egy teljes billing rewrite-én. Nagyjából három hónapnyi munka, körülhatárolva, indulásra készen.

Négy kérdést tett fel. Ki kéri ezt valójában? Mi történik, ha nem építjük meg? Mely ügyfelek ütköznek a jelenlegi limitbe? Hányan, az elmúlt negyedévben?

Senkinek nem volt erre egyértelmű válasza, úgyhogy utánanéztek. A limitbe kétszer ütköztek bele, egyetlen ügyfél, aki azóta egy ettől független okból churnölt el. A rewrite így csendben, de lekerült a roadmapről.

Három hónapnyi munka, amit a csapatnak sosem kellett elköltenie - és a döntés semmit nem generált. Se egy commit, se egy pull request, se egyetlen lezárt ticket. Minden dashboardon, amit a team lead használt, a negyedév legértékesebb tette egyszerűen nem létezett.

Amit a dashboard valójában számolt

A kód generálása sosem volt az igazi szűk keresztmetszet - csak elég drága volt ahhoz, hogy annak látsszon. Egy agent ma gyorsabban csinál egy bekezdésből működő feature-t, mint ahogy átnézed, és ahogy a kód ára leesett, kilátszik mögüle, hol volt végig a valódi korlát. A dashboard, ami az outputot számolja, így a munka legolcsóbb részét számolja.

A drága rész nem most keletkezett, és nem is helyeződött át - mindig is ott volt, csak eddig elfedte a kód ára. Az igazi munka mindvégig az volt, hogy egyáltalán mit érdemes megépíteni: hogy kiszúrd a feature-t, ami egy nem létező problémát old meg, hogy tudd, hová kerüljön egy boundary, hogy három másik dolog egyszerű maradjon, hogy ki merd mondani, hogy „még ne", egy lendülettel teli szobában.

Az ilyen munka úgy jelenik meg, mint a kód, ami nem íródott meg, vagy a komplexitás, ami nincs ott, hogy megszámolják: három hónap, ami sosem került be a timesheetbe. A dashboard alján lévő fejlesztő végezte a csapat legértékesebb munkáját. A műszer csak nem látta, mert a régi munkára tervezték.

„De ítélőképesség sincs kódolás nélkül"

Van itt egy jogos ellenvetés, és a team lead maga vetette fel: ha ez a fejlesztő már alig ír kódot, nem veszíti-e el szép lassan az ösztöneit, amik jóvá tették?

Ez bizony egy valódi kockázat. Az ítélőképesség nem csak úgy lóg a levegőben. Pont azért tudja feltenni azt a négy kérdést, mert éveken át épített ilyen rendszereket, szállította őket, és együtt élt azzal, ami eltört. Egy architekt, aki öt éve nem nyúlt kódbázishoz, már csak véleményt tud nyújtani, nem pedig ítéletet.

Csakhogy az „alig ír kódot" sosem volt lényeg. Továbbra is írt kódot, és a nehéz részekbe kézzel ásott bele. Ami megváltozott, az az arány. Az órák, amik korábban a kézenfekvő nyolcvan százalék legyártására mentek, ma azokra a kérdésekre mennek, amiket egy modell magától sosem tesz fel. Az értéke nem hagyta el a kódot - feljebb került nála.

A jó ízlés persze továbbra is abból jön, hogy az ember épített már dolgokat. Csak nem kódsorszámban fejeződik ki többé.

Mit mérj helyette

A manager így nem tette PIP-re. Helyette azt változtatták meg, amit vizsgáltak.

A throughput hasznos operatív metrika maradt, de megszűnt annak mércéje lenni, ki mennyit tesz hozzá. A review-kon nehezebb kérdéseket kezdtek feltenni:

• Mit előzött meg, döntött el vagy egyszerűsített ez az ember?
• Mi került ki a scope-ból, mert valaki időben feltette a jó kérdést?
• Ki lett jobb a csapatban attól, ahogy ez az ember átnézi a munkáját?

Egyik sem fér be egy oszlopba, és ma mind a munka része. A team lead utólag kerek perec megfogalmazta: majdnem azokat a fejlesztőket jutalmazta, akik a legtöbb olyan kódot generálták, amit később neki kellett karbantartania, és azt büntette, aki elég kicsiben tartotta a kódbázist ahhoz, hogy az érthető maradjon. A dashboard azt mondta volna, minden szuper - egészen addig a pillanatig, amíg nem.

Amikor a kód generálása szinte ingyen van, az output megszűnik az érték proxyja lenni. Ami szűkös - és mindig is az volt -, az annak tudása, melyik kódsorokat érdemes egyáltalán legenerálni. Ez az a rész, amihez az AI nem nyúlt hozzá - és egyre inkább ez az egész munka.