Mi a spec-driven fejlesztés?

Azt jelenti, hogy leírod, mit kell egy funkciónak tudnia, hogyan épül meg, és hogyan ellenőrzöd, és csak ezután engeded, hogy egy kódoló ügynök ezek alapján írjon kódot. A specifikáció, a terv és a feladatlista olyan fájlok, amelyeket átnézhetsz, összevethetsz és tesztelhetsz, nem pedig egy csevegési előzmény.

A spec-driven fejlesztés csak a vibe coding több papírmunkával?

Több papírmunka, igen, de az átnézés áthelyeződik. A vibe coding alapos átnézés nélkül is elfogadhat kimenetet. A spec-driven munka az átnézést a specifikációra, a tervre és a bizonyítékokra helyezi. Ugyanarra a funkcióra többet kerül, ezért több fájlt érintő vagy kockázatos változásoknál éri meg, kisebb javításoknál nem.

Melyik eszközt használjam?

Azt, amelyet a csapatod folyamatosan használni fog. A Spec Kit a specifikáció, a terv, a feladatok és a megvalósítás lépéseit csevegési parancsként futtatja, és funkciónként egy mappában tárolja az artefaktumokat. A Kiro követelményeket, tervet és feladatokat tart fájlként minden spec-hez. A Claude Code és a Cline tervező módja csak egy csak olvasható tervezési lépést ad. Ez segít, de nem tart fenn helyetted specifikációt.

Hogyan segítenek az elfogadási kritériumok a kódátnézésben?

Minden kritérium olyan ellenőrzéssé válik, amelyet az átnéző megnézhet. Azt kérdezi, van-e bizonyíték minden kritériumra, meg tud-e bukni az ellenőrzés, és változott-e valami a hatókörön kívül. Ez kisebb és megbízhatóbb feladat, mint egy nagy diffet átnézni úgy, hogy nem tudjuk, mire való.

Spec-driven fejlesztés kódoló ügynököknek

A vibe coding addig működik, amíg a kódbázisnak nincs története. Egy prototípus azon mérhető, fut-e. Egy éles szolgáltatás nem, mert az ügynök nem ismeri a senki által le nem írt szabályokat: a fizetési csapat által elfogadott újrapróbálkozási szabályt, az egyik régi importot védő kapcsolót, a lekérdezést, amelynek egy időkorláton belül kell maradnia. Ezeket a réseket hihető találgatásokkal tölti ki, és ezeket átnézéskor találod meg, amikor a kód már létezik. A megoldás az, hogy a szándékot előre leírod: egy specifikációt ellenőrizhető elfogadási kritériumokkal, egy tervet, amelyet jóváhagyod, és egy feladatlistát, amelyet az ügynök egyenként végigvisz és kipipál, minden pipához bizonyítékkal. Ez a spec-driven fejlesztés, és én minden olyan változtatáshoz ezt használnám, amely egynél több modult érint.

Andrej Karpathy 2025 februárjában alkotta meg a vibe coding kifejezést: szoftver építése úgy, hogy a modellnek leírod, mit szeretnél, és a kimenetet alapos átnézés nélkül elfogadod. Egy hétvégi eszköznél ez rendben van. Ott válik drágává, ahol ez a szokás konvenciókkal, megosztott modulokkal és fizető ügyfelekkel rendelkező kódbázisba ütközik, mert ekkor az átnézés végzi a valódi munkát, és senki nem határozta meg, mit kellene ellenőriznie.

Miért bukik el a vibe coding valós kódbázisokon

Négy hibamintázat folyamatosan visszatér. Közös az okuk: az ügynök egy promptból dolgozik, a csapat pedig egy olyan megértésből, amelyet soha nem írtak le.

Kitalált követelmények. Az ügynök hihető viselkedéssel tölti ki a réseket, például új alapértelmezett értékkel vagy hibaüzenettel, amelyről senki nem döntött, mégis bekerül a kódba.
Konvenció-eltérés. Minden változtatás önmagában helyes, miközben figyelmen kívül hagyja azokat a mintákat, amelyekre a kód többi része épül.
Meghatározatlan kész. Az Anthropic Claude Code-útmutatója szerint ha nincs olyan ellenőrzés, amelyet az ügynök le tud futtatni, a „késznek tűnik” az egyetlen jel, ami rendelkezésre áll.
Drága átnézés. Egy menetben íródott nagy diff arra kényszeríti az átnézőt, hogy a szándékot a kódból rekonstruálja.

A mért költség nem az, amire a legtöbben számítanak. 2025 júliusában a METR 246 valós hibajegyet, nagy nyílt forráskódú tárolókból, véletlenszerűen osztott ki úgy, hogy azokat MI-eszközzel vagy anélkül kellett megoldani. A vizsgálat többnyire Cursor Pro-val és Claude 3.5 vagy 3.7 Sonnet modellel készült, 16 tapasztalt fejlesztő részvételével. A vizsgálat előtt 24%-os gyorsulást vártak az MI-től. Utána még mindig úgy gondolták, 20%-kal gyorsabbak lettek. A mért eredmény az volt, hogy MI engedélyezése mellett 19%-kal hosszabb ideig tartottak a feladatok.

A munkafolyamat: specifikáció, terv, feladatok, ellenőrzés

A munkafolyamatnak öt szakasza van, és mindegyik olyan artefaktumot hoz létre, amelyet ember elolvashat, mielőtt a következő szakasz elindul. A papírmunka nem a lényeg. Minden jóváhagyási pont olcsó alkalom arra, hogy megállítsd az ügynököt, és a két pont közötti munka az ügynöké.

A jóváhagyási pontok a specifikáció, a terv és az ellenőrzés alatt vannak. Egy rövid spec vagy terv olcsón javítható, egy összefésült változás nem.

Specifikáció. A probléma, a kívánt viselkedés, a nem-célok és az elfogadási kritériumok. Egy ember jóváhagyja.
Terv. A módosuló fájlok és interfészek, a munka sorrendje, a kockázatok és az, hogy mi nem tartozik a hatókörbe. Egy ember jóváhagyja, mert a hibás tervezés itt szűrhető ki a legolcsóbban.
Feladatok. Kis lépésekből álló ellenőrzőlista, mindegyiknek saját ellenőrzéssel.
Megvalósítás. Az ügynök egyszerre egy feladathoz ír kódot és teszteket, és csak akkor pipálja ki, ha az ellenőrzés sikeres.
Ellenőrzés. Minden kritérium egy teszthez, parancshoz vagy kézi ellenőrzéshez tartozik, a bizonyíték pedig a változáshoz van csatolva. Egy ember ezt a bizonyítékot nézi át, nem önmagában a diffet.

Az Anthropic Claude Code-ra vonatkozó legjobb gyakorlatok útmutatója ugyanezt a sorrendet írja le: felfedezés, tervezés, megvalósítás, commit. Az útmutató szerint a tervezés akkor a leghasznosabb, ha bizonytalan vagy a megközelítésben, ha a változás több fájlt érint, vagy ha nem ismered a módosítandó kódot. Ha a diffet egy mondatban le tudod írni, hagyd ki a tervet. Mindkét felével egyetértek.

Specifikáció elfogadási kritériumokkal

A specifikáció rövid. Ha több száz szónál hosszabb, valószínűleg a megvalósítást írja le, és az a tervbe tartozik. A legfontosabbak az elfogadási kritériumok, és én az EARS-szal kezdeném, vagyis az Easy Approach to Requirements Syntax-szal. Alistair Mavin és kollégái a Rolls-Royce-nál dolgozták ki, miközben egy sugárhajtómű vezérlőrendszerének légialkalmassági szabályait elemezték, 2009-ben jelent meg először. Minden követelmény néhány forma valamelyikét ölti: WHEN eseményekhez, WHILE állapotokhoz, IF és THEN nem kívánt helyzetekhez, WHERE opcionális funkciókhoz.

# Spec: cart login prompt and payment safety (example)

## Problem
Logged-out visitors reach checkout without learning that an account unlocks the B2B price list. A timeout on the payment call sometimes leads to a second order.

## Behaviour
What the shop must do, from the user's point of view.

## Non-goals
- No change to how price lists are modelled
- No redesign of the cart layout

## Acceptance criteria
- AC-1: WHEN a logged-out visitor opens the cart, the system SHALL show a login prompt above the checkout button.
- AC-2: WHILE the price cache is older than 15 minutes, the system SHALL refetch prices before it shows totals.
- AC-3: IF the payment call times out, THEN the system SHALL keep the order pending and SHALL NOT submit a second charge.
- AC-4: WHERE the account has a negotiated price list, the system SHALL show that list instead of the public price.

## Verification
- AC-1 -> tests/cart/login-prompt.spec.ts (e2e)
- AC-2 -> tests/pricing/cache-refetch.test.ts (unit, fake clock)
- AC-3 -> tests/checkout/timeout.spec.ts (e2e) and a payment unit test
- AC-4 -> tests/pricing/negotiated.test.ts (unit)
Done when every line above passes in CI and the evidence is attached to the change.

Az ebben a példában szereplő kritériumok egy B2B-webshophoz vannak kitalálva. A forma a lényeg: egy mondat egy eseménnyel vagy állapottal, amelyből teszt írható, és egy azonosító, amelyre a terv és a bizonyíték hivatkozhat. Az IF–THEN sor a legfontosabb, mert megóv a dupla terheléstől, és ilyen esetre az ügynök nem gondol, hacsak le nem írod.

A tervfájl és a feladatlista

A terv a hogyanra válaszol, és elég rövidnek kell lennie ahhoz, hogy percek alatt át lehessen nézni. Az Anthropic útmutatója szerint a leghasznosabb specifikációk megnevezik az érintett fájlokat és interfészeket, kimondják, mi van a hatókörön kívül, és egy végpontok közötti ellenőrzéssel zárulnak, amely bizonyítja, hogy a funkció működik. A tervnek emellett tartalmaznia kell az ismert kockázatokat és a munka sorrendjét. A legkockázatosabb részt építsd meg elsőként, amíg a tervezés még változhat.

# Plan: cart login prompt and payment safety

## Files that change
- src/cart/CartPage.vue: login prompt for logged-out visitors (AC-1)
- src/pricing/priceCache.ts: refetch after 15 minutes (AC-2)
- src/pricing/negotiated.ts: negotiated list lookup (AC-4)
- src/checkout/payment.ts: idempotency key, timeout keeps the order pending (AC-3)

## Interfaces
- payment.charge() gains an idempotencyKey argument; both callers are updated
- priceCache.get() keeps its signature and also returns fetchedAt

## Order of work
1. Idempotency key and timeout path (riskiest, built first)
2. Negotiated price lookup
3. Price cache refetch
4. Login prompt (UI, last)

## Risks
- A retry after a timeout could charge twice (covered by AC-3)

## Out of scope
- Changing how price lists are stored

A feladatlista láthatóvá teszi az ügynök munkáját. Minden feladat elég kicsi ahhoz, hogy az ellenőrzése egy okból bukhasson meg, és megnevezi a kritériumot, amelyet szolgál. Ellenőrzés nélküli pipa csak állítás, az állításokon pedig a vibe coding alapul. Ugyanez az elv áll a harness engineering cikkemben szereplő útmutatók és érzékelők mögött.

# Tasks: cart login prompt and payment safety

- [x] T1 Idempotency key on payment.charge() (AC-3)
      check: unit test 'retry after timeout does not charge twice' passes
- [x] T2 Timeout path keeps the order pending (AC-3)
      check: e2e 'payment timeout' passes
- [ ] T3 Negotiated price lookup (AC-4)
      check: unit test 'account sees negotiated list' passes
- [ ] T4 Price cache refetch after 15 minutes (AC-2)
      check: unit test with fake clock passes
- [ ] T5 Login prompt for logged-out visitors (AC-1)
      check: e2e 'logged-out cart' passes
- [ ] T6 Full suite green; attach output and map AC-1 to AC-4 to tests

Mit adnak valójában az eszközök

Az eszközök kevésbé térnek el a munkafolyamatukban, mint abban, hol van a specifikáció, és mi érvényesíti a jóváhagyási pontot. A táblázat azt mutatja, amit 2026 októberében a hivatalos dokumentációban meg tudtam erősíteni.

Eszköz	Mit tart meg	Hol van az emberi jóváhagyás	Megjegyzés
GitHub Spec Kit	Csevegési parancsok a constitution, specify, plan, tasks, implement és converge lépésekhez, plusz egy spec-mappa funkciónként	Csevegési lépések; a constitution előírja, hogy a teszteket a megvalósítás előtt jóvá kell hagyni	Sok papírmunka, ahogy Böckeler is megállapította
Kiro spec-ek	requirements.md (vagy bugfix.md), design.md és tasks.md minden spec-hez	A Quick Spec egy menetben, jóváhagyási pontok nélkül hozza létre mindhárom fájlt	Olyan ceremónia, amire egy kis hibajavításnak nincs szüksége
Claude Code tervező mód	A terv a munkamenetben; a Ctrl+G megnyitja a szerkesztőben	A tervet jóvá kell hagyni, vagy Shift+Tab-bal kell kilépni a tervező módból	Csak olvasható tervezés, nem tartós specifikáció
Cline Plan és Act	A terv a csevegésben marad, hacsak nem kérsz Markdown-összefoglalót	A tervező mód nem szerkeszthet fájlokat és nem futtathat parancsokat; az Act mód igen	A váltáshoz nincs leírva jóváhagyási beállítás
Codex /plan	Az OpenAI parancsreferenciájában „Toggle plan mode for multi-step planning” néven szerepel	A megnyitott oldalakon nincs leírva	A csak olvasható működés és a tárolás nincs ellenőrizve, ezért nem támaszkodom rá

A táblázat két sora többet ér a többinél. A tervező mód egy mód, nem specifikáció: megakadályozza, hogy az ügynök gondolkodás közben szerkesszen, ami hasznos, de nincs olyan tartós artefaktum, amelyet átnézhetnél, összevethetnél vagy tesztelhetnél. A fájl-alapú eszközök a költséget az átnézésbe tolják, amire lentebb visszatérek.

A Kiro bemutatkozása szerint a felhasználói történetei EARS-elfogadási kritériumokat tartalmaznak, azt a formát, amelyet alább ajánlok. A lényeg az állandó mondatforma, amelyből teszt írható. A Spec Kit a lépéseit az ügynök csevegésében futtatja, a beállítás pedig a terminálban történik:

uv tool install specify-cli
specify init my-project --integration copilot
cd my-project

Ezután a csevegésben futtasd egyszer projektenként a /speckit-constitution parancsot, funkciónként pedig a /speckit-specify, /speckit-plan, /speckit-tasks és /speckit-implement parancsokat. A README előfeltételként a Python 3.11 vagy újabb verzióját, az uv-t és egy támogatott MI-kódoló ügynököt sorolja fel, a példáiban pedig a GitHub Copilot szerepel. A módszertani dokumentumban a constitution tesztelés-először cikke előírja, hogy a teszteket a megvalósítás előtt kell jóváhagyni.

Hogyan teszik a specifikációk az ügynök kimenetét átnézhetővé és tesztelhetővé

A specifikáció megváltoztatja, mit csinál az átnéző. Enélkül a diffből rekonstruálja a szándékot. Vele négy konkrét kérdést tesz fel: Van-e minden kritériumnak olyan ellenőrzése, amely megbukhat? Van-e bizonyíték arra, hogy minden ellenőrzés sikeres? Változott-e valami a hatókörön kívül? És az eredmény még mindig megfelel-e a tervben megnevezett kockázatoknak? Minden kritérium egy feladatra mutat, minden feladat egy tesztre, és minden teszt hagy maga után bizonyítékot.

A teszt nélküli kritérium vagy a bizonyíték nélküli teszt olyan hiány, amelyet az átnézőnek jeleznie kell.

Az Anthropic útmutatója ugyanezt az ügynök oldaláról mondja. Adj neki olyan ellenőrzést, amelyet le tud futtatni, például teszteket, buildet vagy képernyőképet az összehasonlításhoz, és kérj bizonyítékot állítások helyett: a teszt kimenetét, az általa futtatott parancsot és azt, amit az visszaadott. Az útmutató egy második véleményt is javasol: egy friss kontextusú al-ügynököt, amely a diffet a tervvel veti össze.

Az ügynökök által írt pull requestek ezt sürgetőbbé teszik. A MI-kódátnézés szűk keresztmetszete című cikkem arról szól, mi történik, amikor megtelik az átnézési sor, és a bizonyítékokon alapuló átnézés az egyik módja annak, hogy a sor mozgásban maradjon.

Tartsd szintetikusnak a példákat a specifikációkban. A specifikációk és tervek committálva, átnézve és gyakran kontextusként egy modellnek küldve kerülnek elő, így egy valódi ügyfélnév a példában személyes adat, amelyet harmadik fél dolgoz fel. Ha a GDPR érvényes, derítsd ki, hol dolgozza fel az ügynök-szolgáltató ezt a kontextust és meddig tárolja, és ellenőrizd, hogy az adatfeldolgozási szerződésed lefedi-e.

Költség és idő: mikor térül meg a specifikáció

Az első költség emberi idő, nem token. Egy specifikáció és egy terv megírása és átnézése valódi időbe kerül, és ez az ár a megközelítésért. Nincs mért számom arról, mennyit takarít meg, és a gyártói számokat ugyanúgy meg kell kérdőjelezni, mint a METR-számokat. A token-oldal kicsi, és könnyen ellenőrizhető.

Az Anthropic jelenlegi árain egy körülbelül 6000 tokenes specifikáció, amelyet az ügynök 40 hívás mindegyikénél olvas, gyorsítótár nélkül nagyjából 48 centbe kerül a Claude Sonnet 5.5 modellen, mivel a bemeneti tokenek ára millió tokenenként 2 dollár. Az 5 perces promptgyorsítótárral az első írás millió tokenenként 2,50 dollárba, minden további olvasás 0,10 dollárba kerül, így ugyanez a 40 hívás nagyjából 4 centre jön ki, ha a gyorsítótár ablakán belül érkeznek. Ezek a saját számításaim a hivatalos árazási oldal alapján. Kihagyják az ügynök által olvasott kódot és minden kimeneti tokent, tehát a specifikáció részesedését mutatják a számlából, nem magát a számlát.

Két fenntartás érvényes. A Claude 4.7 és újabb modellek által használt új tokenizáló ugyanarra a szövegre körülbelül 30%-kal több tokent állít elő, ezért tokenekben számold a specifikációt, ne szavakban. Ennél fontosabb a figyelem. Az Anthropic útmutatója szerint a teljesítmény romlik, ahogy a kontextusablak megtelik, és a modell elfelejtheti a korábbi utasításokat. Tartsd a specifikációt a kritériumokra, a feltételekre és a nem-célokra, a részleteket pedig a tesztek vigyék.

Változtatás	Megközelítés	Miért
Elütés, naplósor vagy átnevezés	Közvetlen prompt, terv nélkül	Az egész diff egy mondatba fér
Ismert okú hiba	Először egy megbukó teszt, utána a javítás	A megbukó teszt a legkisebb hasznos specifikáció
Egy modulon belüli funkció	Rövid terv tervező módban, a végén ellenőrizve	Az átnézés olcsó, a tervezés pedig még kiszűri a hibás megközelítést
Több modult érintő változtatás, vagy kockázatos út, például fizetés vagy azonosítás	Teljes specifikáció, terv, feladatok és bizonyítékok	A javítási munka többe kerül, mint a papírmunka
Olyan kód, amelyet mások hónapokig bővítenek	Dokumentációként karbantartott specifikáció	Az elavult specifikáció jobban félrevezet, mint semmilyen

Böckeler hasonló következtetésre jutott. Azt találta, hogy a Spec Kit egy közepes méretű funkciónál „túlzásnak tűnt a probléma méretéhez képest”, és azzal érvelt, hogy egy hasznos eszköznek több munkaméretet kell támogatnia. Az eljárást a változtatás méretéhez kell igazítani, nem ahhoz az eszközhöz, amely már a kezedben van.

Hol marad el a spec-driven fejlesztés

Papírmunka átnézés nélkül. Böckeler azt találta, hogy a Spec Kit „rengeteg Markdown-fájlt hozott létre átnézésre”, és inkább kódot néz át, mint ezeket a fájlokat. Ha senki nem olvassa a specifikációt, az színház.
Elavuló specifikációk. Böckeler megkülönbözteti a spec-first, a spec-anchored (a specifikáció fennmarad, és karbantartja a funkciót) és a spec-as-source szinteket. A három vizsgált eszköz közül kettő spec-first, és sok megközelítés homályos marad abban, hogyan tartják karban a specifikációt.
Túlbonyolítás. A Thoughtworks 2025 novemberében az Assess gyűrűbe sorolta a spec-driven fejlesztést, és megjegyezte, hogy a munkafolyamatai „bonyolultak és véleményvezéreltek maradnak”, valamint figyelmeztetett: „lehet, hogy egy keserű leckét újra meg kell tanulnunk”.

A specifikáció nem teszi helyessé az ügynököt. Korábban láthatóvá teszi a hibákat, és ad valamit, amit az átnéző ellenőrizhet. Böckeler ezt a korlátot is látta: a Tessl-ben ugyanabból a specifikációból ismételten generált kód nem ugyanazt az eredményt adta, azaz nem determinisztikus. A tisztességes összefoglaló az, hogy a spec-driven fejlesztés fegyelem a változtatás azon részeiért, amelyek elronthatók, és többletmunka a többiért.

Amit először tennék

Ehhez nincs szükség konkrét eszközre. Egy Markdown-fájl, egy ellenőrzőlista és egy tesztcsomag elég a kezdéshez. A kódoló ügynök skilljeiről szóló cikkem ugyanezt a fegyelmet mutatja be egy hibán, a bejelentéstől a pull requestig, a human in the loop ügynökökről szóló jegyzetem pedig arról szól, hová kerüljenek a jóváhagyási pontok.

Válassz ezen a héten egy olyan változtatást, amely két vagy több modult érint, és írd meg a specifikációját elfogadási kritériumokkal, mielőtt megnyitod az ügynököt.
Fogalmazd meg minden kritériumot egy mondatként, fix formában, például EARS-ban, és adj neki azonosítót, amelyre a terv és a feladatok hivatkozhatnak.
Kérj tervet, olvasd el tíz percig, és módosítsd a fájllistát és a munka sorrendjét, mielőtt kód születik.
Tedd minden feladat kipipálását bizonyítékhoz kötötté a változtatásban: egy teszt nevéhez, egy parancshoz a kilépési kódjával vagy egy képernyőképhez.
Töröld a specifikáció azon részeit, amelyekkel a kód már nem egyezik, ahelyett, hogy hagynád elsodródni őket.
Az eredményt a javítási munka és az átnézési idő alapján ítéld meg, ne aszerint, milyen gyorsan készült el az első változat. A METR-eredmények megmutatják, mennyire megbízhatatlan ez az érzés.

Spec-driven fejlesztés kódoló ügynököknek: a terv a kód előtt

A lényeg röviden