Ne a végén review-zd az agentet

Biztos te is jártál már így: kiadsz egy feladatot az agentnek, és amíg ő dolgozik, te elmész kávézni, vagy épp egy másik ticketen ügyködösz. Mire visszaérsz, ott vár egy 1400 soros diff, ami harminc fájlt érint, a tesztek zöldek, és a PR leírása is egészen meggyőzően hangzik. Ilyenkor pedig az ember azt csinálja, amit mindenki más is: görget egy darabig, keres benne valami ismerőset, aztán, mert mi mást tehetne, jóváhagyja.

A mai agentic trendek nagyjából mind ebbe az irányba mutatnak. Egyre hosszabb autonóm futások, párhuzamosan dolgozó agentek, háttérben pörgő taskok, és lehetőleg minél kevesebb emberi beavatkozás. Ez a demókon valóban látványos, csakhogy a review terhét nem tünteti el, hanem egyetlen helyre gyűjti össze, mégpedig a folyamat végére. Pontosan oda, ahol a legkevesebb kontextusod van arról, mi miért történt, és ahol a legerősebb a kísértés, hogy egyszerűen rányomj az approve gombra.

Ezért írtam egy skillt, ami szándékosan az ellenkező irányba indul el. baby-steps a neve, és a lényege annyi, hogy az agent egyszerre mindig csak egy apró lépést javasol, elmondja, miért éppen azt, és amíg jóvá nem hagyod, hozzá sem nyúl a kódhoz. Lassabb, igen. De pont ez benne a lényeg.

A review nem skálázódik a diff méretével

Egy 50 soros változtatást még rendesen végig tudsz olvasni, soronként, és közben azt is végiggondolod, hogy jó-e. Egy 1400 sorosnál ez már nem megy, és őszintén szólva senki sem csinálja. Egy bizonyos méret fölött a review csendben átvált olvasásból mintakeresésbe: már nem azt nézed, hogy helyes-e a kód, hanem csak azt, hogy ismerősnek tűnik-e.

A nagy diffből ráadásul a sorrend is eltűnik. Nem látod, melyik döntés melyikből következett, miért született meg az a helper, vagy miért pont oda került az az if. Az agent ezt menet közben mind tudta, hiszen ő hozta meg ezeket a döntéseket, a végső diffben viszont csak az eredmény marad meg, az indoklás nem.

A harmadik probléma pedig a legdrágább. Ha az agent már a harmadik lépésnél rossz irányba indult el, akkor a többi huszonhét lépés is erre épül, egymásra rakódva, egyre mélyebbre betonozva a hibát. Mire a végén észreveszed, már nincs mit javítani. Kidobod az egészet.

Egy lépés, egy fájl, egy indoklás

A baby-steps ezt a három problémát fordítja meg, egy dolgot viszont szándékosan nem csinál: nem tervez. Arra két másik skillem van. A clarify egy kérdezz-felelek, amiben az agent egyszerre mindig csak egy kérdést tesz fel, egészen addig, amíg közös nevezőre nem jutunk arról, mi is pontosan a probléma, és mi nem tartozik bele. Ha a feladat ezután is túl nagy, akkor jön a vertical-slice, ami vertikális szeletekre bontja: olyan darabokra, amelyek a UI-tól az adatig az egész stacken átvágnak, és önmagukban is demózhatók. A baby-steps tehát nem egy óriási feladatot koordinál, hanem egy task breakdown után egyetlen ilyen szeletet valósít meg.

Nagyjából így áll össze, mikor melyik skill kerül elő:

Ezen belül sem kapsz előre megírt lépéslistát, csak mindig a következő lépést. Az agent megmondja, mit változtat, és azt is, hogy miért pont most és miért pont így, aztán megmutatja a teljes diffet a chatben, rövidítés és „a többi változatlan” nélkül. Ekkor a diszken még egyetlen fájl sem változott.

Egy lépés pontosan egy fájlt érint, és jellemzően húsz sor körül marad: egy új függvény, egy endpoint váza vagy egy új if ág. Ha egy logikai változás több fájlra is kiterjed, például egy új függvény és annak importja, akkor abból két egymást követő lépés lesz. Ha pedig a diff már túl hosszú ahhoz, hogy teljes egészében kiférjen a chatbe, az a skill szerint nem megjelenítési probléma, hanem annak a jele, hogy a lépés túl nagy, és szét kell vágni.

Minden lépés után négy lehetőséged van. Jóváhagyod, módosítást kérsz, elutasítod, mert rossz az irány, vagy engedélyt adsz nagyobb lépésekre, de csak az aktuális részre, mondjuk egy tesztcsoport vagy egy endpoint erejéig. Jóváhagyás után az agent pontosan azt alkalmazza, amit megmutatott, lefuttatja a legszűkebb releváns tesztet vagy buildet, és röviden beszámol az eredményről. Commitolni viszont magától soha nem fog, mert a commit is külön lépés, saját jóváhagyással.

Egy lépés a chatben valahogy így néz ki:

**Következő lépés:** `parseDuration` hozzáadása, ami az "1h30m" alakú bemenetből perceket csinál.

**Miért:** Az endpointnak percekre van szüksége, és az előző lépésben megírt, most még piros teszt pontosan ezt a viselkedést rögzíti. A parsolás egy pure helperbe kerül, így önmagában is tesztelhető marad.

**Fájl:** `src/duration.ts`

```diff
+export function parseDuration(input: string): number {
+  const m = /^(?:(\d+)h)?(?:(\d+)m)?$/.exec(input);
+  if (!m) throw new Error(`Invalid duration: ${input}`);
+  return Number(m[1] ?? 0) * 60 + Number(m[2] ?? 0);
+}
```

Jóváhagyod, módosítást kérsz, elutasítod, vagy engedsz nagyobb lépést erre a részre?

Négy sor, ezért tényleg végig is olvasod, és ha figyelsz, feltűnik, hogy a regex az üres stringre is illeszkedik, vagyis a parseDuration("") csendben nullát ad vissza hiba helyett. Ilyenkor egyszerűen módosítást kérsz, és a következő lépés egy teszt lesz erre az edge case-re. Egy 1400 soros diffben ez a négy sor szinte biztosan elsikkadna.

Elsőre ez úgy hangozhat, mint a sima manual approval, amit a legtöbb coding agent alapból tud: minden fájlmódosítás előtt megáll, és megkérdezi, mehet-e. A kettő viszont egészen mást szolgál. A manual approval egy biztonsági fék, ami az agentet lassítja, és megakadályozza, hogy olyasmit csináljon, amit nem akarsz, arról viszont semmit nem mond, mi a célja az adott változtatásnak. Kapsz egy fájlnevet és egy diffet, a döntéseket pedig, hogy miért pont ez, miért pont most és mi jön utána, neked kell kiolvasnod belőle. Ráadásul a lépések méretét sem korlátozza semmi, így egyetlen jóváhagyás mögött is lehet háromszáz sor. A baby-steps-ben a jóváhagyás csak a lépés vége, a súlypont az előtte álló indokláson van, és azon, hogy a változás elég kicsi ahhoz, hogy meg is értsd. Itt tehát nem az agentet fékezed, hanem a saját megértésedet tartod vele egy tempóban.

Lassabb, csakhogy itt a lassúság maga a review

Elsőre persze idegesítő. Húsz soronként rábólintani valamire, amit az agent egy perc alatt egyben is megírna, olyan érzés, mintha visszatekernénk az egész agentic fejlődést. A nagy diffnél viszont sem spórolod meg a review idejét, csak a folyamat végére tolod, ahol aztán vagy rosszul csinálod, vagy egyáltalán nem.

Apró lépésekkel mindhárom korábbi probléma eltűnik. A húszsoros diffet tényleg végigolvasod, mert elfér a fejedben, így a review olvasás marad, és nem csúszik át mintakeresésbe. Az indoklás sem vész el, hiszen minden lépés mellett ott van a miért, mégpedig abban a pillanatban, amikor a döntés születik, és nem utólag kell kitalálnod. A rossz irány pedig már ott elakad, ahol elindulna: ha a harmadik lépés rossz, akkor egy húszsoros javaslatot utasítasz el, és nem egy harminc fájlt érintő PR-t dobsz ki.

Van egy kevésbé látványos hatása is, mégpedig az, hogy menet közben te is képben maradsz. A szelet végére nem egy idegen kódot kell megértened, hanem pontosan tudod, mi miért került oda, mert minden döntésnél ott voltál. Ha pedig egy rész tényleg unalmas, mondjuk egy generált fájl vagy egy sor egyforma teszteset, arra ott a nagyobb lépés opció, de csak arra az egy részre.

A gyors út sem olcsó

Van még egy szempont, amiről ritkábban esik szó, mégpedig a költség. Ha egy autonóm futás elején becsúszik egy rossz döntés, az agent nem áll meg, hanem következetesen végigviszi: ugyanazt a rossz absztrakciót használja a következő tíz fájlban, arra írja a teszteket, és ahhoz igazítja a hibakezelést is. Ilyenkor sokszor nem is dobod ki az egészet, mert túl sok benne a használható rész, csakhogy javítani minden olyan helyen kell, ahová a hiba elért. Ez pedig megint tokenköltség. Egyszer kifizetted, amíg a rossz irányt megírta, aztán még egyszer, amíg körbejárja és kijavítja, és mivel minden javításhoz újra be kell olvasnia az érintett fájlokat, közben a kontextus is egyre csak hízik.

Apró lépéseknél ez a dupla költség fel sem merül. A rossz döntés egyetlen javaslatban marad, amire még semmi sem épült, így az elutasítása szinte semmibe sem kerül.

Mikor nem kell

Nem minden feladathoz kell ez a tempó. Egy eldobható prototípusnál vagy egy gyors spike-nál, ahol a kód úgyis a kukában végzi, felesleges minden húsz sort végigolvasni, ott nyugodtan hadd fusson az agent a saját feje után. A baby-steps ott fizet a legtöbbet, ahol a kód megmarad: production kódban, egy olyan modulban, amit később neked kell karbantartanod, vagy ott, ahol egy rossz döntés még hónapok múlva is visszaköszön.

Az agentek sebessége önmagában nem probléma. Akkor válik azzá, amikor a review nem tud vele lépést tartani, és a végén csak egy gombnyomás marad belőle. Az approve gomb a baby-steps-szel is ugyanott van, csak most minden alkalommal tudod, mire nyomod meg.