A kérdés nem az volt, hogy tud-e segíteni az AI — hanem hogy hogyan tartjuk szabályozott keretek között, miközben a fejlesztést is rá bízzuk. Erre a válasz a Spec-driven Development.

A házon: A telek, amin 20 év alatt toldás toldásra épült — terv nélkül; ma senki nem tudja biztosan, melyik fal tartó. · SdD-ben: Itt kezdődik a lánc: felmérés és szándék (brief.md) — mielőtt bárki tervet rajzolna.

Az ember dönt, az AI végrehajt. Az 05–06 lépéspár a TdD: a teszt előbb születik, mint a kód — róla külön dia lesz. A lánc két emberi kapuval zárul (A9): Verifikáció (a review emberi része) + Validáció (a QA-átvétel) — pontosan a ház: a műszaki ellenőr azt nézi, a terv szerint épült-e meg, a család azt, hogy azt kapta-e, amire szüksége volt. A 09 pedig zárja a kört: a ház nem a kulcsátadásnál ér véget — a család beköltözik, és amit ott hiányol, az lesz a következő szándék. A termék az üzemelő alkalmazás, nem a beolvasztott kód.

A házon: család (szándék) → építész (engedélyezési terv) → kiviteli terv → próbakocka a betonozáskor → brigád → műszaki ellenőr → a család átveszi → beköltözés. · SdD-ben: 01 → 02–03 → 04 → 05 TdD → 06 → 07 → 08 → 09 — ugyanaz a kilenc lépés, ugyanazokkal a kapukkal.

Az agent négy arca — ki irányítja a lépéseket?

Az LLM statisztikai szövegjósló: a súlyai nem változnak a beszélgetéstől, és amit az aktuális kontextus vagy az eszközei nem hoztak be, arra abban a lépésben nem tud támaszkodni — csak újrakombinál, és magabiztosan téved. (Friss tényhez az agent jut hozzá: fájlt olvas, DB-t kérdez, eszközt hív.) A context window ráadásul véges — nem fér bele a rendszer, tehát minden session választ, mit olvas be. Ezért tesszük a tudást dokumentumokba, amit minden session újratölt: az aranyhal-memóriájú agentnek a repo a memóriája. A modell felejt — a platform nem. Mint a Memento hőse: nincs hosszú távú memóriája, minden nap emlékek nélkül kezdődik — ezért mindent leír (cetli, polaroid, tetoválás), és abból rakja össze, hol tart. Minden session egy ilyen új nap.

Új viselkedést nem „promptolgatással" érünk el, hanem a szabályfájl módosításával — ami diffelhető, review-zható, és minden jövőbeli session örökli.

A házon: A brigád minden reggel emlékezet nélkül érkezik: a tervrajzból és az építési naplóból tudja, hol tart. · SdD-ben: A spec, a szabályok és a git log az AI memóriája; a context window az aznapi munkaasztal.

A lényeg egy mondatban: a repo a fejlesztői környezet. Ami nincs a repóban — szabály, döntés, konfiguráció, tudás — az a felejtő agent számára nem létezik. Ezért kerül minden fájlba, és ezért lesz minden fájl diffelhető.

A házon: Az építési terület: a tervtár, a szabványok és a szomszéd épületek egy telken. · SdD-ben: A szabályok és a specek ugyanott laknak, ahol a kód — munka közben olvashatók, nem egy távoli wikiben.

Vibe codingnál a git csak mentés. Spec-driven fejlesztésnél a git a kontrollpont. Az ember nem minden sort ír — de minden sort átenged. Ez a különbség, és a git teszi elvégezhetővé.

És itt a fogás: az AI-nak nincs fáradtságjelzése. Nem érzi, hogy nagy a diff — boldogan ír 2000 sort egy kérésre. Az ember viszont fárad, és a fáradt review pecsételéssé válik. Ezért a diff méretét előre, a specben és a taskokban kell korlátozni, nem utólag a review-n. A kis diff nem stílus — ez tartja életben az emberi kaput (A10).

A kapu a review: ha a diff a követelményen kívüli fájlt vagy sort érint, az MR visszamegy — „vágd ketté". Cserébe mindkét javítás külön visszavonható, és a git bisect egyetlen okra mutat.

Java-hasonlat: ez ugyanaz a fegyelem, amit a jó commit-kultúrától mindig is vártunk — csak most nem opcionális. Amíg ember gépelt, a diff magától kicsi maradt, mert lassan nőtt. Egy gép mellett a méret korlátját szándékosan kell odatenni.

A házon: Egyszerre egy fal, amit a műszaki ellenőr még végig tud nézni; a tegnapi naplóbejegyzést nem radírozzák ki. · SdD-ben: Kis diff = egy review-egység; minden lépés a saját próbakockájával (TdD-teszt) megy be.

A házon: Az építési szabványok — minden házra érvényesek, és a terv fölött állnak. · SdD-ben: Az axiómák a spec fölötti alaptörvény: ha ütköznek, az axióma nyer.

A tézis: az AI nem rövidítés a gondolkodás megspórolására, hanem erősítő a jó kontextusra. Rossz alapra rakva gyorsan termel — rosszat is.

A kontextus nyelve — miért angolul írjuk a specet és a szabályt?

De nem mindent angolul — a vágás éles (A7): az infrastruktúra és az orchestráció beszél angolul (szabályok, EARS-kikötések, kódbeli azonosítók, commit-üzenetek), az üzleti tartomány marad magyarul (a domén fogalmai, a felhasználónak szóló szövegek, ez a diasor is). A BA nem lesz angol nyelvű követelményíró: a szakterületi szó magyar marad, csak a kikötés váza angol.

A házon: Szilárd híd vs. kártyavár: alap és statika nélkül a gyorsan felhúzott fal az első tehernél leomlik. · SdD-ben: A kontextus (spec + szabály) az alap — az AI erősítő, nem rövidítés; a TdD-teszt a statikai számítás.

A házon: A brigád dolgozik, a tulajdonos és az ellenőr a kapuknál áll; a darut a brigád és a gépész is használja. · SdD-ben: Az AI végzi a lépéseket, az ember tartja a kapukat — a motornak két hívója van: az alkalmazás és az AI.

# élő napló — pfworker-infra, éles szerver, 2026-09-23
04:00:38.541  pipeline start  name=ops_dep_extract steps=5
04:00:38.710  step done  Extract Dependencies  success  168 ms
04:00:38.710  step done  Log Result            success
04:00:38.718  pipeline start  name=ops_graph_sync steps=9
04:00:38.899  pipeline done   ops_graph_sync  success  source_edges=53
04:00:38.900  step done  Sync Graph Store      success  188 ms
04:00:38.901  step done  Done                  success
04:00:38.901  pipeline done  ops_dep_extract  success  steps_run=4  359 ms

steps_run=4, nem 5 — a hibaág sikeres éjszakán kimarad, és ezt a fájl mondja meg, nem egy kód mélyén rejlő if. A tanulság is a futtatható fájlban él: a 27 zöld, de üres futás története ott áll a lépés fölött, ahol a következő szerkesztő (ember vagy AI) biztosan elolvassa. A dokumentum és a kód nem tud elcsúszni egymástól, mert ugyanaz a fájl (A2).

Egy forrás, négy fogyasztó — ezért Markdown

Ha a tudás csak a kódban él, három olvasója van: a fordító, a szerző — és senki más.

A házon: A tervrajz nem utólagos leírás — a brigád ebből épít, és ha a fal eltér tőle, a falat bontják. · SdD-ben: Document = Code: ugyanaz a fájl a spec, a dokumentáció és a futtatható.

A házon: Egy hiteles tervrajz a helyszínen — nem kettő, és nem a brigád fejében. · SdD-ben: A1 + A2: egy igazságforrás, és az maga a futtatható.

Mi hová tartozik: DB — szűrés, rendezés, összesítés · BE — transzport, auth, session · FE — megjelenítés · AI — a tierek elérése, nem a logikájuk. Ha a munka a BE-be kerül, az adatot akkor is csak tárolt függvényen át érjük el: a hely mozdulhat, a hozzáférés módja nem. Az invariáns: az igény változik → az entitásspec vagy a pipeline-fájl változik → a generált kód frissül. Nem fordítva.

A házon: Alap → falak → tető → berendezés; senki nem a tetővel kezdi. · SdD-ben: DB → BE → FE → AI — felülről lefelé, a spec szerint.

Ebből a szemszögből a módszertan lényege: a blueprint nem a fejlesztés mellékterméke, hanem az üzemanyaga — az AI miatt végre megéri jó tervdokumentumot írni, mert van, aki garantáltan és minden alkalommal elolvassa.

Az ötrétegű dokumentumtérkép — minden réteg egy valós fájl

Az irány mindig felülről lefelé: szabály → terv → spec → futtatható artefaktum → tükör (HTML, Confluence, Jira). Lefelé sosem írunk kézzel olyat, amit feljebb spec birtokol.

Az EARS-kikötés a szerződés szövege. A BA írja, a fejlesztő olvassa, az AI implementálja, a teszt pedig bizonyítja. Egy jó EARS-kikötésből a következő dia szerint gyakorlatilag magától lesz kód.

A TdD-nek van egy új veszélye AI mellett: ha a teszt a kód után születik, az agent hajlamos olyan tesztet írni, amit a saját kódja biztosan teljesít — vagy a bukó tesztet gyengíteni. Ezért két vasszabály: (1) a teszt előbb kerül commitba, mint az implementáció; (2) a review a tesztet is nézi, nem csak a kódot. A gyengített teszt zöld — és hazudik.

Vissza a házhoz (2. dia): a próbakockát a betonozás közben veszik — nem utólag választják ki, melyik falat mérjék meg. Ha a mérce a fal után születik, ahhoz igazítjuk, ami éppen kijött, és már nem mérce, hanem utólagos igazolás. A teszt pontosan ugyanez: ezért kerül commitba az implementáció előtt.

Így zárul a lánc: az EARS-kikötés mondja meg, mit jelent a „kész" — a teszt bizonyítja, hogy az — az ember pedig eldönti, hogy ez volt-e a cél. Spec, teszt és kód ugyanannak az állításnak három alakja.

A motorok alatt — a foundation réteg: keret · könyvtár · minta · példa

A foundation-* repók nem csak könyvtárak — négyféle dolgot adnak: ① keret, amibe beépülsz (pl. az app-shell) · ② könyvtár, amit behivatkozol · ③ minta, amit követsz · ④ példa, amiből kiindulsz. Hogy egy feladatnál melyiket és hogyan használja, azt az AI választja (A11: a konstrukció az AI-é).

A választás szabad, a forrás nem. A keretbe beépülsz, a könyvtárat behivatkozod, a mintát követed, a példából kiindulsz — hogy melyik illik a feladathoz, azt az AI dönti el. De a foundationből választ: ha ott van rá kanonikus megoldás, nem talál ki újat. Enélkül 16 repóban 16-féle naplózás születne, mind „helyes", mind más. A foundation-* így az AI tudástára: nem kész kódot ad, hanem választékot — és a döntést, amit nem kell újra meghozni.

A közös elv: adat a katalógusban, viselkedés a motorban — a kettő határa a review-felület.

A házon: Szabványos, előre gyártott elemek — zsalu, ajtótok, födémpanel: nem minden háznál találják fel újra. · SdD-ben: A négy motor és a foundation: a spec ezekből választ, ötödiket nem ír (A4).

Így használja Claude — fejlesztés közben: /rag-search "hol oldjuk fel a vault-ot?" → top találatok (collection + source_file) → és csak azt az egy fájlt nyitja meg (Read). Tájékozódás RAG-gel, pontos olvasás utána — a véges kontextust a releváns tudás tölti, nem a teljes repó.

A házon: A tervtár: a brigád nem visz mindent a zsebében, de tudja, hol keresse. · SdD-ben: RAG: a teljes tudásból az adott SdD-lépéshez szükséges rész kerül a kontextusba.

PostgreSQL 19 gráf — hol tartunk (2026-09-22)

Két külön RAG — sosem keveredik

A határ: ügyféladat soha nem kerül felhő-embeddingbe és nem kerül a fejlesztői RAG-ba; a fejlesztői eszközt soha nem irányítjuk ügyfél-adatbázisra. Két külön tár, két külön cél — ugyanaz a technika.

A házon: A tervtár mutatója: nem csak mi van benne, hanem mi mire hivatkozik (statika → alaprajz → anyaglista). · SdD-ben: Vektor = jelentés, él = kapcsolat — melyik spec mire épül, mit érint egy változás.

Ma vs terv. A fejlesztői RAG-ban a vektor és az él két külön lépés (/rag-search, majd /rag-connections), amit az ember és Claude kapcsol össze. A beépített fúziós rangsor terv — a súlyok a konfigban lesznek, és csak akkor kerül élesbe, ha a kiértékelés javulást mutat. A „kontextus" szó két dolgot jelent: itt a kapcsolati kontextus; az LLM munkakontextusa a végeredmény.

A házon: A tervtár és a mutató együtt: a rajz megmondja, mi van a lapon; a mutató, hogy melyik érvényes, és mi mire épül. · SdD-ben: tartalom = mit mond a spec, kontextus = mi hivatkozik rá és mi váltotta le.

A sorrend nem esetleges: nem tervezhetsz alapot, amíg nem tudod, mi van a talajban. A felmérés mondja meg, mire kell építeni; a kivitelezés azt, hogyan. A kettőt más szakember végzi, és külön is tévedhet — ezért kerül mindkettő írásban a tervre, nem szóban a helyszínre.

Először a ház: mit csinál a kész alkalmazás · ver=0.1.390 óta élesben

És csak azután a napló: 19 aktív fejlesztési nap, 390 commit, ~20 300 sor Go mellett ~26 500 sor Markdown — több terv, mint fal: a tervrajz nem lassította az építkezést, ez tette lehetővé. De ezek nem a mérce: a sor és a commit a felrakott tégla, nem a lakható ház — a mérce az átvett követelmény (lásd a vezetői tanulságokat). A „hagyományos" ellenpont (nagyságrendileg 12–27 emberhónap) ráadásul becslés, dokumentált módszertan nélkül — nagyságrend, nem bizonyíték.

És ma (2026-09-24, ugyanabból a git logból): v0.8.951 élesben · 2 107 commit · 81 aktív fejlesztési nap · ~35 900 sor Go + ~23 600 sor Go-teszt mellett ~86 800 sor Markdown · 47 spec-mappa. Az arány nem romlott: még mindig több a terv, mint a fal. A TdD a naplóból is látszik: a 2026-09-09-i mandátum óta született 16 új spec-mappa mind az első napon tests.md-vel jött (24 a 47-ből; a többi a mandátum előtti, grandfatherelt).

Miért elég egy architekt/BA/QA? Ahogy a háznál sem a téglarakás a szűk keresztmetszet, hanem a döntés, az ellenőrzés és az átvétel — és azt ember végzi: megrendelő (szándék) → BA (BRD, EARS) → architekt (SDD) → AI (teszt + kód) → architekt (review · verifikáció) → megrendelő = QA (validáció, átvétel). A téglát az AI rakja — a három emberi kalap egy emberen van, de a lánc sorrendje és a kapuk nem tűnnek el.

A házon: Az építési napló és a próbakocka jegyzőkönyve. · SdD-ben: A git log a napló — minden commit egy bejegyzés; a TdD-teszt futása a próbakocka jegyzőkönyve.

Ez az alap. Azóta ugyanabból a láncból épült tovább: CVE- és NIS2-riportok · titok-keresés a flottán · függőségi gráf · IPAM és IT-szolgáltatás-katalógus · VM-igénylés OpenTofu-val · és a Timi IT-portál: csapat (távollét, ügyelet, standup), Jira-munkanapló, tudástár — egy felületen, AI-val a bejáratnál.

Ami a felhasználó felé nem látszik, mégis ez tartja: minden érzékeny érték már tárolás előtt álnevesítve van ({{type:hash}}), az eredeti külön, titkosítva; az AI az álnevesített oldalt olvassa. A validáció kérdése ezen a dián dől el: „ezt akartuk?" — és a válasz nem a commitok száma, hanem hogy a hétfő reggel tényleg gyorsabb lett-e.

A házon: A kész, lakott ház — és a család már a következő bővítést tervezi. · SdD-ben: 09 Használat → új szándék: a SdD lánc újraindul.

A ② kulcs és a ③ két aláírás nem a lánc egy pontján ül, hanem végig érvényes: üzem közben is, minden lépésnél — ezt a jogosultság és a napló kényszeríti ki, nem a jóindulat.

Verifikáció ≠ validáció. A verifikáció arra felel: jól építettük-e meg? (mechanizmus létezik, a gépi ellenőrzések zöldek, az ember review-zta a diffet). A validáció: a jót építettük-e meg? (a megrendelő fogadja el az eredeti üzleti célra, valós folyamaton — ez a QA kapu). Egyik sem önmagában a „kész".

A házon: a műszaki ellenőr azt nézi, a terv szerint épült-e meg (verifikáció); a család azt, hogy azt a házat kapta-e, amire szüksége volt (validáció). A fenti három kapu az építkezés közben véd — az ① egyben a verifikációs kapu; a validáció a második módszertani kapu, és az dönti el, hogy kész-e. Mindegyiknél ember dönt.

Az első lépés holnap: válassz egy kicsi, valódi igényt. Egy oldal brief, néhány EARS-mondat, a teszt előbb (TdD) — és mérd, mennyi idő alatt jut el az átvételig. Nem pilot-program kell, hanem egy végigvitt példa.

Egyetlen mondatban: bánj az AI-jal úgy, mint egy nagyon gyors, nagyon felejtős új kollégával — aki látszólag logikus, de magabiztosan téved, és nem alkot új igazságot, csak újrakombinál. Adj neki írott szabályokat, írott specifikációt, és ellenőrizd a munkáját.

A házon: Az első saját házadnál: előbb terv és szabvány, aztán falak — kicsiben, ellenőrizve. · SdD-ben: Szabály → spec → kis lépés → teszt (TdD) → verifikáció.