Előző este 23:26-kor üzenetet kaptam egy ügyféltől. Nem egy issue-t vett fel a rendszerben, hanem írt: valami elakadt, blokkolja a folyamatukat, és sürgős. Egy országos digitális kampányon dolgozunk együtt, sok automatizációval és admin funkcióval. Az ügyfél oldaláról 10+ adminisztrátor használja nap mint nap, úgyhogy egy blokkoló hiba náluk azonnal sokakat érint.
Öt percen belül, félálomban csináltam három képernyőképet arról, amit küldött, odaadtam Claude-nak, hogy dolgozza fel, és vegyen fel belőle egy ticketet a Linearba. Mire elolvastam a kész ticketet, vissza is aludtam. Az egész öt perc volt.
Reggel bekapcsoltam a gépet, és egyetlen kérést adtam a Claude Code-nak: nyisd meg ezt az issue-t, járj utána, reprodukáld. Mire lefőtt a kávé, a hiba reprodukálva és letesztelve volt. Egy ritka peremesetnek (edge case-nek) bizonyult, nem szisztémás hibának.
Ezt könnyű úgy olvasni, hogy az alapító éjjel is talpon van, és ez a titok. Pedig pont az ellenkezője igaz, és szerintem ez az egyetlen érdekes tanulság az egészben.
A gyorsaság itt nem érdem
Ha az kellett volna, hogy éjjel éber és éles legyek, ez nem jó sztori lenne, hanem figyelmeztető jel. Az egy emberen múló gyorsaság nem megismételhető: legközelebb alszom, beteg vagyok, vagy egyszerűen nem veszem észre az üzenetet. Az öt perc félálom pontosan azért volt elég, mert a folyamat nem attól függött, hogy én ébren vagyok-e. Én csak elindítottam. A munka nagy részét nem én végeztem, és nem is akkor.
Hol vész el valójában az idő
Vegyük a klasszikus utat egy éjjel érkező hibabejelentéstől a reprodukált hibáig. Jön a bejelentés. Reggel valaki ránéz, és eldönti, kihez tartozik. Kiosztják valakinek, aki éppen ráér. A fejlesztő elolvassa a csetet, és kihámozza belőle, mi is a hiba valójában. És csak ezután kezdődik az érdemi rész: az utánajárás és a reprodukció.
Ha megnézzük, hol telik el az idő ebben a láncban, kiderül, hogy nem az érdemi munka a lassú. A reakcióidőt az átadások közti holtidő viszi el: a várakozás, hogy valaki ránézzen, és a fordítás, amíg egy laza üzenetből használható feladat lesz. A tényleges utánajárás ehhez képest rövid.
Ebben az esetben ez a két szakasz nullázódott ki. Éjjel a laza üzenetből azonnal strukturált ticket lett, tehát a fordítás megtörtént rögtön, nem reggel. Reggel pedig az utánajárás és a tesztelés emberi idő nélkül futott le, tehát a várakozás sem számított. Az AI nem a gondolkodást váltotta ki, hanem a holtidőt az átadások között.
A rejtett hős az unalmas fegyelem
Van egy csendes előfeltétele annak, hogy reggel működött. Éjjel nem az a válasz született, hogy majd reggel megnézem, hanem egy rendes, visszakereshető ticket: mi a hiba, hol jelentkezik, mit küldött az ügyfél. Reggel a Claude Code azért tudott elindulni, mert éjjel egy valódi munkadarabot kapott, nem egy három szavas emlékeztetőt.
Ez a rész átvihető máshová is, és sokkal unalmasabb, mint amilyennek egy AI-sztori hangzik. Az AI-gyorsaság előfeltétele a bemenet-fegyelem: hogy a rendszerbe strukturált, egyértelmű munkadarab kerüljön, ne egy odavetett mondat. Aki ezt kihagyja, annak az AI gyorsan fog gyártani egy magabiztos, de rossz ticketet, és a hibát a reprodukció csak később hozza elő, ha egyáltalán.
Ami nélkül ez csak dicsekvés lenne
Fontos kimondani, mi tette ezt lehetővé, különben az egész csak dicsekvés. A kódbázis fel van készítve arra, hogy egy AI-ügynök eligazodjon benne. Vannak tesztek, amikkel a reprodukció ellenőrizhető. És a Linear be van kötve, úgyhogy a ticket nem egy külön rendszerbe került. Enélkül a három képernyőképből ugyanúgy lett volna ticket, csak nem lehetett volna rá építeni.
És a lánc két vége szándékosan emberi maradt. Én döntöttem el, hogy ez tényleg sürgős, és reggel én néztem át, hogy a reprodukált hiba valóban az, aminek látszik. Az AI a közét vitte: a fordítást és az utánajárást, ott, ahol egy embernek amúgy is csak várnia és gépelnie kellett volna.
A tanulság
A sztori vége tehát nem az, hogy gyorsak vagyunk. Hanem az, hogy az éjszakai énem és a reggeli énem is alig csinált valamit, és pont ez a lényeg: a reakcióidő megszűnt attól függeni, hogy egy ember épp ébren van-e, ráér-e, és elég éles-e. Egy működés akkor lesz igazán gyors, ha meg meri kérdezni magától, hogy a láncában hol vált egy éber ember szűk keresztmetszetté, és hogy ott tényleg hozzátesz-e valamit, vagy csak vár és fordít.
