Google nemrég közreadta "The New SDLC With Vibe Coding" című Day 1 papírját, amelyet Addy Osmani, Shubham Saboo és Sokratis Kartakis jegyeznek. A cikkben foglalt fő gondolat az, hogy az ügynök nem csak a modell: az ügynök a modell plusz a „harness” — azaz az a körítés és infrastruktúra, amelyben a modell működik. A paper gyakorlati tanácsokat ad a kontextuskezelésre, verifikációra és az ügynökrendszerek gazdaságosságára vonatkozóan.
Az ügynök: modell plusz harness
A szerzők egy egyszerű, de fontos keretet javasolnak: „An agent is a model plus a harness.” A modell csak egy bemenet; a harness tartalmazza az utasításokat és szabályfájlokat, az eszközöket és MCP szervereket, a sandboxokat, az orkesztrációs logikát, a determinisztikus kódhorgokat és az observabilitást, amely jelzi, ha a viselkedés eltér a várttól. A paper durva megosztása szerint ez körülbelül 10% modell és 90% harness.
Gyakorlati illusztrációként a cikk említ két példát: egy Terminal Bench 2.0 vizsgálatban egy csapat a harness megváltoztatásával a top 30-ból a top 5-be juttatott egy kódolási ügynököt ugyanazon modell megtartása mellett; egy LangChain kísérletben pedig a rendszerprompt, az eszközök és a middleware módosítása 13,7 pontot hozott ugyanazon benchmarkon, szintén a modell érintése nélkül. A következtetés: amikor az ügynök hibázik, először a harness konfigurációját érdemes ellenőrizni.
Kontextusmérnökség: mi dönt a számlán
A harness részeként a kontextuskezelés az egyik legfontosabb kapcsoló. A paper hat kontextustípust különít el: utasítások, tudás, memória, példák, eszközök és guardrailok. A kulcskérdés, hogy mi kerül statikus kontextusba (betöltődik minden hívásnál) és mi marad dinamikus (csak igény szerint töltődik).
- A statikus kontextus (például rendszerutasítások, globális memória, alapvető szabályok) megbízható, de költséges, mert minden hívásnál fizetni kell érte.
- A dinamikus kontextus (például eszközök eredményei, RAG-dokumentumok, készségek, amelyek csak feladat egyezéskor töltődnek) olcsóbb, mert csak akkor számítódik, amikor valóban szükséges.
A paper javaslata, amelyet a szerző is támogat: a statikus/dinamikus határt kezeld valódi architekturális döntésként — legyen PR-ben áttekintve és verziózva. Skálázhatóságot hoz a „progressive disclosure” mintázat: az ügynök csak a minimális metaadatot látja induláskor, teljes utasítások csak egyezéskor, a nehéz hivatkozási anyagok pedig csak tényleges igény esetén töltődnek be.
Verifikáció: a vibe coding és az engineering határvonala
Ugyanazzal az ügynökkel lehet a spektrum bármely pontján dolgozni; a döntő tényező a verifikáció szintje. A paper kettéválasztja a determinisztikus és a nem determinisztikus ellenőrzést: a tesztek a determinisztikus részeket fedik le ( adott bemenet → adott kimenet), míg az evalok a nem determinisztikus viselkedést mérik. A szerző kiemeli a végső javaslatot vezetőknek: a küszöböt az evalnál állítsd meg, ne a demónál — a demo egyszeri működést mutat, az eval-sorozat és rubric megbízhatóságot ad.
A paper tovább bontja az evalokat output-evalre (a végső eredmény helyessége) és trajectory-evalre (az oda vezető út, a hívott eszközök és a gondolkodás menete), és mindkettő fontos: egy helyesnek látszó, de ellenőrzéseket kihagyó válasz veszélyesebb lehet, mint egy nyilvánvalóan rossz eredmény.
Hogyan változnak a szoftverfejlesztés fázisai
Az AI felgyorsítja a fejlesztés életciklusát, de nem egyenletesen. Az implementáció hetekről órákra esik vissza, miközben a követelménygyűjtés, architektúra és verifikáció továbbra is lassabb, mert ítélkezést igényelnek. Ennek eredményeképp a specifikációk minősége lesz az új szűk keresztmetszet, és a verifikáció szerepe a munkafolyamat közepére kerül.
Fázisonként:
- Követelmények: nem csupán dokumentum, hanem párbeszéd, amely specifikációt és első prototípust hoz létre egyszerre — az ügynök vázolja a user story-kat és felszínre hozza a sarokeseteket.
- Architektúra: marad emberi-domináns, mivel üzleti kontextusban hozott kompromisszumokat kell dokumentálni.
- Implementáció: jelentős produktivitásnyereség és ugyanakkor ellenőrzési költség; feladatoknál a nettonyereség változó (surveys 25–39% hatékonyságnövekedést jeleznek, egy METR tanulmány 19% lassulást talált egyes feladatoknál, ha a javításra fordított időt is számítjuk).
- Tesztelés és QA: felcserélődik a szerepük; a tesztek és evalok adják meg, hogy az ügynök mit értsen "helyesnek", és ez egy zárt hibajavító ciklust alakít ki.
- Karbantartás: alulértékelt előny — ügynökök képesek olvasni és modernizálni olyan kódot, ami korábban "túl kockázatos" volt kézbe venni.
A plafon továbbra is az „80% probléma”: az ügynök gyorsan elvégzi az első 80%-ot, a maradék 20% — sarokesetek és rendszerek közötti illesztések — még mindig emberi kontextust igényel.
Gazdasági oldalak: kontextus és routing mint pénzügyi karok
Egy vezető számára a kulcsszám nem a sebesség, hanem a teljes tulajdonlási költség. A papír szerint a vibe coding kezdetben olcsó, de működtetéskor 3×–10× többe kerülhet feature-onként; az agentic engineering fordítottja: többet fektetsz be előre (sémák, tesztek, strukturált kontextus), de utána kevesebb lesz az egyes feature-ök költsége.
A fontos üzenet: a kontextuskezelés és a modellrouting pénzügyi karok. Nem lehet mindenhívásba 100,000 tokenes repo-t tolni és elvárni a skálázást. Routinggal a komplex gondolkodást egy nagy modellhez, a rutin munkát pedig olcsóbb modellekhez lehet terelni — a minőség megmarad, a számla csökken.
A prototípusból lesz a production agent
A paper figyelmeztető és érdekes pontja, hogy a terminálból kilépő prototípusok immár közvetlenül production ügynökké válhatnak: perzisztens memória, scoped jogosultságok, eval lefedettség és observabilitás egy lasszóval összekapcsolható a fejlesztői loopban. Google Agents CLI például egy egyszeri telepítés után lehetővé teszi, hogy a kódoló ügynök készségeket vegyen fel a teljes életciklus kezeléséhez és természetes nyelven vezérelve építsen, értékeljen és deploy-oljon.
A paper említ egy kísérletet, ahol egy Anthropic csapat ügynökök csoportjával egy működő C-kompilert építtetett Rustban két hét alatt, miközben emberek irányítottak és felügyeltek, ahelyett hogy közvetlenül kódoltak volna. Ez a szerkezet körvonalazza a lehetséges jövőt.
A mindennapi munka két mód között vált: a „conductor” (valós idejű, IDE-s, exploratív munka) és az „orchestrator” (aszimmetrikus, cél átadása ügynököknek, felülvizsgálat). A szerző szerint ez elsősorban készségváltás lesz, majd eszközváltozás.
Alkalmazási arányok és kezdő lépések
A paper egy több generációt bemutató ábrát is tartalmaz, és idézi az adaptációs számokat: korai 2026-os adatok szerint a profi fejlesztők 85%-a rendszeresen használ AI kódoló ügynököket, 51% naponta, és körülbelül 41% az új kódok aránya AI-generált.
A javaslatok röviden: fókuszálj a specifikációra és a verifikációra, mert az AI felgyorsítja a generálást — de amit az AI talál meg, azt az adott mérnöki kultúra felerősíti, jó és rossz irányban egyaránt. A paper részletesebb ajánlásokat ad egyéneknek, vezetőknek és szervezeteknek.
Következtetés
A Whitepaper lényege, hogy az ügynökök hasznossága és költséghatékonysága nem egyszerűen modellválasztás kérdése: a harness és a kontextuskezelés döntően meghatározza a teljesítményt és a költséget. A verifikáció — különösen a jól felépített eval-sorozat — az, ami elválasztja a véletlenszerűen működő demo-t a megbízható mérnöki folyamattól.
Ha van egy vonal, amit érdemes megjegyezni a paperből: tanuljuk meg jól specifikálni és verifikálni az ügynököket; a generálás nagy része megoldott, a hátralévő munka a specifikáció és a verifikáció rendszereinek kiépítése.
