Mekkora feladat megy?
Erre van mérés, és a metrika elegánsan egyszerű: az a feladathossz — emberi munkaidőben mérve —, amelynél a modell 50%-os sikerarányt ér el.
A 2026 eleji mérés szerint az élmezőny 320 perc körül jár, de a konfidencia-intervallum tág: 170 és 729 perc között. A trend gyors: a duplázódási idő a korábbi hét hónapról nagyjából három hónapra rövidült.
Két dolgot érdemes ehhez hozzátenni.
Az egyik egy módszertani korlát, amit a kutatók maguk írnak ki: a nyolc óránál hosszabb feladatoknál 31-ből csak 5 esetben mérték az emberi alapidőt, a többi becslés. A skála felső vége tehát bizonytalanabb, mint amilyennek látszik.
A másik a gyakorlati olvasat. Az ötven százalék nem jó arány. Ha egy ötórás feladatot adsz, az esetek felében elrontja — és az ötórányi elrontott munka átnézése neked öt óra. Az első feladatod legyen jóval egy óra emberi munka alatt, ahol a hiba azonnal látszik.
Mit adj neki, és mit ne
Az egyik nagy szolgáltató hivatalos dokumentációja kiírja, mire való az agent és mire nem. Ez a lista használhatóbb, mint a legtöbb szakmai tanács:
ERRE JÓ
hibajavítás
felületi elem módosítása
tesztlefedettség növelése
dokumentáció frissítése
akadálymentesítés javítása
technikai adósság ledolgozása
ERRE NEM
széles hatókörű refaktorálás, ami több repó ismeretét igényli
összetett feladat, ami függőségek és örökölt kód megértését kívánja
ÉLES ÜZEMET ÉRINTŐ, kritikus hiba
biztonság, személyes adat, autentikáció
homályos vagy nyitott végű feladat
AMIBŐL TE AKARSZ TANULNI <- ezt a doksi külön kiemeli
Az utolsó pont a legfontosabb, és a legkevésbé technikai. Ha egy feladat megoldásából te tanulnál valamit a kódbázisról, akkor annak a megtanulását adtad oda — nem a munkát.
Mit írj bele a feladatba
Ugyanaz a dokumentáció három dolgot kér egy jó feladatleírástól:
- A probléma vagy az elvégzendő munka világos leírása.
- Teljes elfogadási feltételek — mi számít jó megoldásnak.
- Útmutatás arról, mely fájlokat kell módosítani.
A harmadik az, amit a legtöbben kihagynak, pedig ez rövidíti le leginkább a felderítést.
Hogy mekkora a különbség, azt egy előtte-utána összevetés mutatja meg a legjobban:
| Ahogy a legtöbben kérik | Ahogy működik |
|---|---|
| „írj teszteket a foo.py-hoz" | „írj tesztet a foo.py-hoz, ami lefedi azt az esetet, amikor a felhasználó ki van jelentkezve; mockot ne használj" |
| „javítsd a bejelentkezési hibát" | „a felhasználók azt jelzik, hogy a bejelentkezés elhasal a munkamenet lejárta után; nézd meg az auth folyamatot a src/auth/ alatt, különösen a token-frissítést; írj előbb egy bukó tesztet, ami reprodukálja, aztán javítsd" |
| „nem fordul a build" | „a build ezzel a hibával áll el: [hibaüzenet]. Javítsd, és ellenőrizd, hogy lefut. A gyökérokot kezeld, ne nyomd el a hibát" |
A leggyakoribb hiba: nincs mit lefuttatnia
Ez az a pont, ami az egész munkamenetet eldönti, és a gyártói dokumentáció szokatlanul őszintén mondja ki:
„A modell akkor áll meg, amikor a munka késznek látszik. Ha nincs olyan ellenőrzés, amit le tud futtatni, akkor a »késznek látszik« az egyetlen elérhető jelzés — és te leszel az ellenőrző kör."
Ugyanez pozitívan: adj neki valamit, amit maga le tud futtatni — tesztet, buildet, egy képernyőképet, amit összehasonlíthat. Ez a különbség aközött, hogy végignézed a munkamenetet, és aközött, hogy elsétálsz mellőle.
Az első feladatnál ezért a sorrend: előbb a bukó teszt, utána a javítás. Nemcsak azért, mert így ellenőrizhető — hanem mert így a feladat definíciója maga is egyértelművé válik.
A négy fázis
A bevált munkamenet négy lépés: felderítés → terv → megvalósítás → commit. Az első kettő olyan módban fut, ahol az eszköz olvas és csak olvasó parancsokat futtat, de a forrásaidat nem írja át.
És egy ritkán idézett kiegészítés ugyanabból a dokumentációból: ne tervezz mindig. Ha a hatókör világos és a javítás kicsi — elgépelés, egy naplósor, egy átnevezés —, kérd meg, hogy csinálja meg egyből. A szabály egy mondatban: ha egy mondatban el tudod mondani a diffet, hagyd ki a tervezést.
Öt nevesített kudarcminta
Ezeket a gyártói dokumentáció külön nevesíti, mert olyan gyakoriak:
- A mindent-egybe munkamenet. Több, egymással nem összefüggő feladat ugyanabban a beszélgetésben. Közöttük törölni kell a kontextust.
- A körbe-körbe javítgatás. Két sikertelen javítás után ne a harmadikkal próbálkozz: töröld a kontextust, és írj jobb feladatleírást.
- A túlírt projektutasítás. Ha túl hosszú, a fele elveszik. Erről a projektutasítások poszt szól számokkal.
- A bizalom-ellenőrzés rés. „Ha nem tudod ellenőrizni, ne engedd ki."
- A végtelen felderítés. Szűkítsd a vizsgálat körét, vagy adj rá külön subagent et.
Mindegyik mögött ugyanaz áll: a context window gyorsan betelik, és ahogy telik, romlik a teljesítmény. A legtöbb jó gyakorlat ebből az egyetlen korlátból következik.
Mit mutat a valóság: 11 048 agent-PR
Van egy elemzés, ami 11 048 lezárt, agent által nyitott pull requestet nézett meg valódi, legalább ötszáz csillagos repókban. Ebből 9 799-et ember is bírált.
A merge-arány 63,1%. Ez jóval jobb, mint amire a szkeptikus várna — de a részletek tanulságosabbak.
Az elutasított PR-oknál csak az esetek 35,7%-ában volt maga az agent a hiba oka. A többi folyamati ok: duplikáció, elavult ág, vagy egyszerűen az, hogy a karbantartó nem kért ilyet. Vagyis az elutasítás kétharmada nem arról szólt, hogy rossz volt a kód.
És két szám, ami elgondolkodtató:
- A bemergelt agent-PR-ok 79,1%-ánál nem volt visszacsatolási kör — senki nem kért módosítást, csak bement.
- Egy másik, 40 214 PR-t vizsgáló elemzés szerint a bemergelt agent-PR-ok 77,51%-át maga a beküldő mergelte be, szemben az emberi PR-ok 57,63%-ával.
Ebből következik a legpraktikusabb tanács ebben a cikkben: az első feladatodnál ne te mergeld a saját agent-PR-odat. Nézze meg valaki más. A számok szerint ez az a lépés, ami a leggyakrabban marad ki.
Ugyanez az elemzés hoz egy furcsa paradoxont is: egy további bírálói komment az emberi PR merge-esélyét 2,7%-kal növeli, az agentikusét viszont 2,8%-kal csökkenti. Emberi PR-nál a sok komment párbeszéd; agent-PR-nál figyelmeztetés.
A benchmark, amire senki ne alapozzon vásárlási döntést
A leggyakrabban idézett kódolási mérce valódi GitHub-issue-kból áll: kapsz egy repót egy adott állapotban meg egy hibaleírást, és olyan javítást kell írni, ami átmegy az eredeti javítás tesztjein.
Amit nem mér: tervezést, architektúrát, felületet, teljesítményt, karbantarthatóságot — és mindent, ami nem ellenőrizhető egy meglévő teszttel.
Két dolgot érdemes tudni róla.
Telített. Az élmezőny 2026 őszén 97% körül áll egy 500 elemű halmazon. Ennél a szintnél a maradék néhány feladat különbsége már a zajtól sem különböztethető meg.
És volt vele egy komoly probléma. Egy 2024-es elemzés az eredeti, szűretlen változaton azt találta, hogy a sikeres javítások 32,67%-ánál a megoldás ott volt magában a hibabejelentésben vagy a kommentekben, további 31,08% pedig gyenge tesztek miatt ment át. Korrigálva ugyanannak a rendszernek az eredménye 12,47%-ról 3,97%-ra esett. Az emberi szűréssel készült részhalmaz épp ezt hivatott orvosolni — a szivárgás problémáját viszont az sem oldja meg teljesen, mert a feladatok nyilvános repókból származnak.
Ahol még van tér: egy 2026-os, terminálos feladatokra épülő mérésen a frontvonalbeli modellek 65% alatt teljesítenek.
Tipikus félreértések
- „Az agent ötórás feladatokat old meg." Ötven százalékos eséllyel. Az első feladatod jóval egy óra alatt legyen.
- „Minél részletesebb a feladat, annál jobb." A hatókör pontossága számít, nem a hossz. Ha a diff et egy mondatban elmondod, ne tervezz.
- „Ha lefutott, kész van." Az eszköz akkor áll meg, amikor késznek látszik. Ellenőrzés nélkül te vagy az egyetlen ellenőrző kör.
- „97%-ot ér el a benchmarkon, tehát szinte mindent megold." A mérce telített, és nem méri a tervezést, az architektúrát és a karbantarthatóságot.
- „Ha átment a teszten, bemergelhetem." A bemergelt agent-PR-ok háromnegyedét maga a beküldő mergeli. Az első feladatnál pont ezt ne csináld.
Amit érdemes elvinni
Az első feladat legyen kicsi, unalmas, és legyen mellette egy ellenőrzés, amit az agent maga le tud futtatni. Írd meg, mi a probléma, mi számít jó megoldásnak, és mely fájlokról van szó. Ne add oda azt a feladatot, amiből te akarsz tanulni, és ne mergeld be a saját agent-PR-odat.
A jóváhagyási módokról és arról, hol fusson mindez, a fejlesztői környezet választása poszt szól; a kész kód átnézésének konkrét hibamintáiról pedig a generált kód átvizsgálása poszt.