# basode: Balanced Software Development Lifecycle – Conceptual Framework and Implementation Guide v0.5

Monolitikus SSOT és Injektált Állapotvezérelt Softver fejlesztés orchestrator modell

Balanced Software Development Lifecycle – Conceptual Framework and Implementation Guide © 2026 by akotomars is licensed under CC BY-SA 4.0

## **1\. Miért kell ez? A kód percek alatt kész, és az embernek nyakába szakad… **

Az ember dolga egy szoftver fejlesztési projektben manapság ennyi: megmondja az AI agentnek, hogy mit csináljon, és utána ellenőrzi a produktumot, visszajelzést ad róla az agentnek \- ezt mindaddig, amíg eléri a kívánt állapotot.

Volt egy jó kis Antigravity-s projektem. Valamiért nem szeretem ezt a “vibe coding” kifejezést \- talán, mert szeretek programozni \-, de akár így is nevezhetjük. Nagyon jól indult, hetekig hasítottam, pörögtem, hajnalig ébren, csak előre, valósítottam meg az álmaimat. De… De egyre csak nőttek az apró eltérések, néha ez, néha az, néha az agent úgy elment a bozótba, hogy alig győztem a károkat helyreállítani. Számomra érthetetlen okból elkezdett olyan dolgokon rágódni, amiket napokkal előtte tisztán elkészített \- rosszabb esetben el is kezdte szétverni a korábbi jól működő részeket. Égette a tokeneket, és a lelkesedésemet. Szép lassan ott találtam magam, hogy apróbb és nagyobb feladatok sokasága szakadt a nyakamba, és elkezdtem azt is érezni, hogy bármihez nyúlok, minden mindennel összefügg, egyre mélyebb üregekbe jutok, és már emlékem sincs a korábbi napfényes világról, ahol nemrég még szárnyaltam. Egy nyomasztó pókhálóban találtam magam, ahol ezer kicsi szál húzott erre és arra, és bár egyenként mindegyik kezelhetőnek tűnt, de ahogy egyet húztam, jött vele még sok másik szál.

Ekkor önvizsgálatot kellett tartsak, és a projektemre is rá kellett nézzek. Mit is csinálok tulajdonképpen? Az AI agent működését \- rule-okat, skilleket, stb-t \- is folyamatosan csiszolom, a termékemnél mozgó célpontra lövök \- hiszen épp fejlesztek \-, és ennek megfelelően közben az infrát és a deploy folyamataimat is állandóan ehhez igazítom. Káosz? Követhető? Mit is kell most csináljak?\!

Ez a gondolati keretrendszer \- balanced SDLC (basode) \- azoknak szól, akik többé-kevésbé hasonlókat élnek meg, vagy ha okosabbak nálam: még előtte felismerik, hogy ezt el szeretnék kerülni.

### **Egyensúly az ember és AI agent munkamegosztásában**

Mivel az agentic fejlesztésben a programozási és programozott tesztelési munka már autonóm módon, ember nélkül zajlik, a projekt hosszát a a klasszikus fejlesztési projektek maradék \- emberre maradó \- feladatainak számossága és párhuzamosíthatósága adja, a költségét pedig az élőmunka és a tokenek.

A basode alapvető célja a humán-AI munkamegosztás optimalizálása. Másként fogalmazva: egy szoftver fejlesztési projekt fő szervező szempontja: az AI felé delegálás optimalizálása. Ha hatékonyságra optimalizálunk \- avagy az én esetemben: szeretném elkerülni a kiégést \-, akkor ilyesmi az egyik fő szabály: káros döntés bármilyen munkát vagy felelősséget átvenni az AI modelltől olyan területeken, amelyeket az AI gazdaságosabban képes elvégezni.

Hogyan tudhatjuk megmondani, hogy hol van ez a határ? Változó. A gazdaságosságok az is meghatározza, hogy az agent viselkedését mennyire tudjuk szabályozni, és a kívánt eredménytől való eltérő outputjait mennyire kevés élőmunkával és mennyire korai stádiumban \- kevés idő és token elégetése után \- tudjuk észlelni. Ha ez egy vállalati projekt, akkor a rosszul megválasztott határ vagy hibás szabályozás elkezdi emészteni a pénzt \- ha pedig hobby projekt, mint az enyém volt: az fejlesztő kikészül, belefullad a feladataiba. Miért? Mert részben brutálisan magas kognitív fókuszt és időt igénylő munka szakad rá: precíz és egyértelmű specifikálás, és eredmény doksik alapos átolvasása, korrigálása, másrészt brutálisan sok favágó munka: a tesztelés. Legalábbis velem ez történt. Ez volt a kiindító oka, hogy ez a gondolati framework megszületett \- mert ez a nyomás volt az én személyes megélésem az AI támogatott fejlesztésben. Ha ez a vibe coding, akkor én kikészültem tőle.

A két tanulság, amit leszűrtem: a humán aktor szerepe akkor van jól minimalizálva, ha:

* Feladat definiálása az agent számára: itt szigorúan minimális transzformáló feladatokat kell vállalni. *Erre még visszatérünk \- mert kucsfontosságú. Röviden: mesével, történettel definiálom a feladatot.*
* Végrehajtás ellenőrzése: az eredmény validálása is a legkisebb időt és kognitív terhet rak az humán szereplőre.
* Visszajelzés: minimális munkával. Az egész körforgás egyik kifejezetten élőmunka igényes része lehet, hogy pontos visszajelzést adjunk.

Erről fog szólni ez az iromány.

—-

### **A dokumentáció: a programozás programja. Ezért ez sok figyelmet igényel.**

Hagyományos szoftverfejlesztési környezetben a projektmenedzsment konzisztenciáját a humán aktorok soft skilljei, a formalizált SOP-k (Standard Operating Procedures), valamint az íratlan közösségi normák és implicit munkaköri leírások egyensúította.

Az autonóm AI ágensek (Agentic AI) belépésével ez a paradigma érvényét veszti. Az ágensek nem rendelkeznek a projekt munkakönyvtárán kívüli tacit tudással; működésük szigorúan az explicit módon biztosított kontextusra és determinisztikus utasításokra korlátozódik. A munkavégzés szabályai immár nem a projekten kívül lebegő vállalati kultúra részei, hanem a projekt elválaszthatatlan, kódként kezelt (**Docs-as-Code**) komponensei kell, hogy legyenek.

A **basode** keretrendszer erre az architekturális kényszerre reagál. A korábban lágy, humán-vezérelt folyamatokat gépileg értelmezhető, nyomon követhető szabályrendszerré konvertálja. Ez radikálisan kitágítja az AI ágensek autonómiájának határait, képessé téve őket komplexebb és vertikálisan kiterjedtebb fejlesztési iterációk önálló végrehajtására.

## **2\. A dinamika: A tó víztükre és a kettős könyvelés**

A basode egyik fő pillére a rendszer pillanatnyi állapotának transzparenciája: ránézésre egyértelműnek kell lennie, hogy a rendszer stabil (stable), vagy változás zajlik benne.

### **A tó és a hullámok**

A stabil rendszer egy tó, amelynek tükörsima a felülete. Az új igény egy impulzus, amit valaki beledobott a tóba. A basode a fizikai törvények gyűjteménye, amelyek a tó működését modellezik azzal a céllal, hogy a végén újra sima legyen a vízfelület.

Ha rossz a modellezés (rossz a fizika), az igények egymásra hatása nem csitul el, a tó állandóan hullámzik, és rengeteg erőforrás (token, idő, pénz) megy el a víztükör helyreállítására. A jó fizika biztosítja, hogy minden inger – legyen az nagy szikla vagy kicsi tavirózsa – gyors és hatékony csillapodáshoz vezessen.

### **A számviteli analógia és a kettős könyvelés**

A számvitelben egy új számla (impulzus) hatása legkésőbb az év végi mérlegben foglalja el a helyét, kialakítva az új egyensúlyt. Egy utalásos számla esetén a nyilvántartás kettéválik:

1. Az üzleti eredményt azonnal befolyásolja a bizonylat összege (kötelezettség).
2. Egy másik szinten várjuk a bankszámlán a fizikai pénzmozgást (teljesítés).

A basode ezt az elvet adaptálja. Szigorú kötelezettség, hogy minden új igényt két helyre „könyveljünk”:

* **Állapot-kimozdítás a dokumentációban (SSOT):** Beírjuk a kész rendszer működési dokumentációjába egy explicit WIP (work in progress) jelöléssel.
* **Állapot-kimozdítás a feladatkezelőben (Kanban):** Létrejön a feladat, amely a fizikai megvalósulást várja.

Ahogy a feladaton végrehajtjuk a műveleteket, a megvalósítással eltűnik a „tartozás”: lezárjuk a jegyet, és kivesszük a WIP jelzést a dokumentációból. A tó elcsitult, a kő leért az aljára, új stabil állapot jött létre.

## **3\. Az alap architektúra: Target és Delivery System**

A keretrendszer a szoftverfejlesztést egy megosztott memóriájú, monolitikus állapotgépként kezeli, amely egyetlen determinisztikus igazságforrásra (SSOT) támaszkodik.

### **A kettős termékmodell (3D nyomtató analógia)**

A basode egyidejűleg két rendszert fejleszt:

* **Target System (Termék A \- a „pohár”):** A létrehozandó szoftverproduktum.
* **Delivery System (Termék B \- a „3D nyomtató”):** Az előállító módszer, infrastruktúra és folyamatrendszer. A Delivery System módosítása mindig prioritást élvez a Target Systemmel szemben, mivel rosszul kalibrált gépsorral nem lehet jó terméket gyártani.

### **N-rétegű dokumentáció (doclayerN)**

* **doclayer0 (Ideák):** Strukturálatlan, rendszeren kívüli igények (a repülő kő).
* **doclayer1 (TargetSpec):** Irodalmi szintű specifikáció, a globális SSOT (a becsobbant kő).
* **doclayer2…N-2 (Átmeneti modellek):** Technikai specifikációk, ábrák, ahol az aktorok pontosítják a feladatot.
* **doclayerN-a (Aktív implementáció):** Tesztek, futó forráskód és infrastruktúra (a tó medre és a víz).
* **doclayerN-b (Passzív projekciók):** User manual, tudásbázis, RAG. A rendszer automatikusan generálja ezeket a ciklus végén (tájékoztató táblák a tó partján).

### **Triage és Instant-issue**

* **Triage:** A pillanat, amikor az idea zöld utat kap, és megtörténik a kettős könyvelés (WIP injektálás és Kanban jegy nyitása).
* **Instant-issue:** Az „Andon cord” megfelelője. Alulról építkező kritikus hiba esetén a pipeline azonnal befagy, és soron kívüli hatásvizsgálat, majd javítás következik.

## **4\. A rendszerek rendszere: tulipán hagyma modell**

A valóságban a „Target” és a „Delivery” fogalma relatív \- bár az esetek jelentős részére elégséges (pareto elv, és ne bonyolítsuk, amit nem kell). A rendszerünk: rendszerek rekurzív láncolatából áll. A rendszerünk: egy tulipán hagymája. Indulunk a gondolattal, és hozzuk létre az egyre beljebb belső héjakat, végül egy csodálatosan komplex eredményt. Elöször a külső héj kicsiben megalkotja a projekt célokat, és szabályrendszert \- és legbelső mag, a termék, amit létrehozunk.

* **syslayer1 (Framework):** A legkülső burok (metodológia).
* **syslayer2 (DevOps / Platform):** CI/CD tervek és pipeline-ok.
* **syslayer3 (Dev Tools / Agents):** Fejlesztési szabályok, ágens profilok, szkriptek.
* **syslayer4 (Product):** A belső mag (üzleti specifikáció és kód).

A feladatkövetés ebben a modellben lehet elosztott (külön csapatok esetén) vagy monolitikus (agentic fejlesztésnél), ahol egyetlen Kanban táblán metaadatok jelölik az érintett hagymahéjat.

## **5\. Tesztelések: hol mi folyamati lépés, dokumentációs szint, és hol önálló rendszer?**

A tesztelési metodológiák a basode keretrendszerben nem homogén entitások. Komplexitásuktól és a rendszerre gyakorolt hatásuktól függően eltérő kategóriákba sorolandók. Az alábbi táblázat az iparági sztenderd tesztelési szinteket és azok ontológiai besorolását mutatja be a gondolati keretrendszerünkben.

| Teszt típusa | Ontológiai besorolás a basode-ban | Helye a topológiában | Funkció és működési leírás |
| :—- | :—- | :—- | :—- |
| **Linting / Statikus kódanalízis (SAST)** | folyamati lépés | syslayer3 (Delivery System) | Az ágensek vagy a CI/CD pipeline automatikus lépése, amely a forráskód szintaktikai és alapvető biztonsági tisztaságát garantálja a kódolási iteráció közben. |
| **Unit Test (Egységteszt)** | doclayerN-a szelete | doclayerN-a (Target System) | A termék forráskódjának elválaszthatatlan része. Kódként létezik, együtt mozog az üzleti logikával. A megvalósítás (tó medre) fizikai stabilitását garantálja. |
| **Komponens tesztelés** | doclayerN-a szelete | doclayerN-a (Target System) | Egy logikailag összetartozó modul (pl. UI komponens) funkcionális vizsgálata, a külső függőségek izolálásával és mockolásával. |
| **Szerződés tesztelés (Contract Testing)** | doclayerN-a szelete | doclayerN-a (Target System) | Különálló rendszerek (pl. frontend és backend API) közötti kommunikációs megegyezések betartását validáló kód. |
| **Integration / E2E Test (Gherkin, Playwright)** | doclayerN-1 szelete | doclayerN-1 (Target System) | Híd a narratív elvárások és a fizikai kód között. Gyakran önálló specifikáció (pl. BDD), amely a doclayer1 alapján generálódik. |
| **Vizuális regressziós tesztelés** | folyamati lépés | syslayer3 (Delivery System) | A UI pixel-szintű, automatizált összehasonlítása az elvárt állapottal a build vagy release folyamat során. |
| **Rendszertesztelés (System Testing)** | folyamat | syslayer2 (DevOps / Platform) | A teljes, összeépített rendszer (black-box) validálása, tisztán az API és adatbázis rétegeken keresztül a pipeline-ban. |
| **Teljesítmény- és terheléses teszt** | folyamat | syslayer2 (DevOps / Platform) | A rendszer stabilitásának és skálázhatóságának mérése meghatározott terhelési korlátok alatt a bevezetés előtt. |
| **Biztonsági tesztelés (DAST / Pen-test)** | önálló rendszer | syslayer2 vagy külső rendszer | Dinamikus sebezhetőségi vizsgálatok, amelyeket dedikált biztonsági alrendszerek vagy külső aktorok végeznek a futó alkalmazáson. |
| **UAT (User Acceptance Testing)** | folyamat | doclayer1 vs. doclayerN-a | Validációs esemény. A humán aktorok összevetik a megvalósult rendszert az elvárt SSOT-val. Az eltérések új impulzusokat (doclayer0) generálnak. |
| **Market Feedback / Telemetria** | önálló rendszer | Külső rendszer | A piac és a valós felhasználás megfigyelése. Egy folyamatos „szenzorrendszer”, amely új igényeket hajít a projekt tavába. |

## **6\. A keretrendszerünk rokonsága: felmenők, oldalági rokonság**

A basode nem vákuumban jött létre, hanem bevált iparági sztenderdek és architekturális elvek rendezgetése az AI agentic development optimalizálása céljából. A keretrendszer az alábbi rendszerekből merít inspirációt, és azokat adaptálja az Agentic AI korszakára:

### **Tartalmi és módszertani átfedések**

* **Számvitel (IFRS / Kettős könyvvitel):** A tranzakciók determinisztikus, szinkronizált rögzítése a rendszer stabilitása érdekében. A WIP injektálás és a Kanban jegykezelés analógja az üzleti eredmény és a bankszámla-egyenleg vezetésének.
* **Agile / Kanban:** Az iteratív végrehajtás és a vizuális feladatkövetés (pull system), amely egyértelműen jelzi a rendszerben lévő feszültséget.
* **ITIL / ITSM (Változáskezelés):** A basode *idea-to-delivery* ciklusa a klasszikus ITIL Change Management (Változáskezelés) folyamatának modern adaptációja. Az ITIL-ben a Request for Change (RFC) életciklusa – a rögzítéstől az értékelésen (Triage) és engedélyezésen át a megvalósításig és lezárásig – logikailag megegyezik a basode állapotvezérelt Kanban és WIP-injektálás metódusával. Emellett az Instant-Issue eljárás szorosan rokonítható az ITIL Emergency Change (sürgősségi változtatás) protokolljával és az Andon cord megszakítási mechanizmussal.
* **GitOps / DevOps:** Az infrastruktúra, a folyamatok és a specifikációk kódként való kezelése (Docs-as-Code), a Single Source of Truth primátusának biztosítása.

### **A legfontosabb elvi metszéspontok**

* **Karbantarthatóság (DRY \+ SOLID \+ LoD):** Mindhárom alapelv célja, hogy ha egy helyen belenyúlunk a rendszerbe, ne törjön el tíz másik helyen. A basode a Delivery és Target System, valamint a doclayer és syslayer rétegek szétválasztásával biztosítja ezt az architekturális izolációt.
* **Egyszerűség és fókusz (YAGNI \+ SMART \+ Pareto-elv):** Ezen elvek mindegyike a fókuszt védi. Azt mondják: *”Ne csinálj többet, mint ami a cél eléréséhez feltétlenül szükséges.”* Az Agentic AI fejlesztésben ez kritikus: az ágensek token- és kontextusablak-fogyasztásának, valamint a felesleges „hullámverésnek” a minimalizálását szolgálja.
* **Helyesség és konzisztencia (SSOT \+ DRY):** Ez a duó garantálja, hogy ne legyen két különböző verzió ugyanabból az igazságból (legyen az adat, algoritmus vagy specifikáció). A kettős könyvelés ellenére a basode szigorúan védi az egyetlen igazságforrást (SSOT), megakadályozva az állapot-töredezettséget.

## **7\. Gyakorlat: megfontolandók**

### **7.1. Specifikálás: Az SSOT előállítása (Transzformáló szerep)**

A projekt indítása előtt stratégiai döntést kell hozni: mi lesz a rendszer legfelsőbb szintű leíró módja (doclayer1 SSOT), és mik a származékos (read-only) kimenetek (doclayerN-b)?

Főbb opciók a normatív SSOT felépítésére:

* **Hagyományos igényleírás / User Manual stílus:** (pl. *”A rendszernek képesnek kell lennie PDF formátumban riportokat készíteni…”*). Emberi oldalról rendkívül munkaigényes és kognitívan kimerítő a fenntartása.
* **Sztorik / Forgatókönyvek összessége (Ajánlott):** Narratív, történetalapú specifikáció (User Stories/Scenarios). Sokkal természetesebb a humán aktor számára, ugyanakkor a fejlett LLM-ek kiválóan képesek ebből pontos technikai követelményeket és architektúrát generálni.

### **7.2. Ellenőrzés és Validáció (Kognitív energiarablók)**

Az emberi fókusz drága erőforrás. A két legnagyobb időrabló tevékenység a validációs fázisban:

1. **Generált dokumentációk felelős auditja:** A köztes (doclayer2) vagy végső dokumentációk átolvasása és jóváhagyása.
2. **Humán tesztelés (UAT):** A megvalósult, futó termék manuális, emberi kipróbálása.

Ezeket a feladatokat tervezni kell, és ahol lehetséges, ágens-alapú verifikációs tesztekkel (pl. E2E Gherkin) kell helyettesíteni az emberi kattintgatást.

## **8\. Gyakorlati alkalmazás (Playbook)**

### **8.1. Zöldmezős (Greenfield) projekt checklist**

Induló projekt esetén a basode bevezetése egy determinisztikus önértékeléssel kezdődik:

1. **Rendszerek azonosítása:** Melyek a syslayer-ek (pl. van-e dedikált DevOps)?
2. **Dokumentációs szintek definiálása:** Mettől meddig tart a doclayer1, és mik a read-only kimenetek?
3. **Kanban topológia:** Monolitikus (egy tábla) vagy elosztott feladatkövetés az optimális?
4. **Egyszerűsítés (YAGNI):** Cél a struktúra végletes lecsupaszítása a felesleges komplexitás elkerülése végett (minimál mappa struktúra, alap .agent/\* fájlok rögzítése).

### **8.2. Futó projekt migrációja (Brownfield / Rescue)**

Amikor egy meglévő agentic projekt a „szétesés jeleit” mutatja (kontextusvesztés, token-égetés, hibás kódmódosítások), a basode implementációja az alábbi szigorú iterációt követi:

1. **Ideális állapot definiálása:** A 8.1-es pont alapján a célstruktúra felvázolása.
2. **Gap analízis (Önvizsgálat):** Mi a valóság? (Folderek, folyamatok, .agent fájlok állapota, az SSOT töredezettsége).
3. **Migrációs terv:** Készítsünk ágens-vezérelt szkripteket, teszteket és hozzuk létre a hiányzó dokumentációs rétegeket (Ez maga is AI feladat\!).
4. **Iteratív Cross-Model Review:** Különböző modellek bevonásával addig vizsgáltatjuk a kódot és a terveket, amíg el nem fogynak a hibalisták (findings).
5. **Végrehajtás és validáció:** Biztonsági mentés (Backup) készítése. Lépésenkénti végrehajtás, a dokumentációk maximális alaposságú, szigorú átolvasása.
* *Ha fogalmi zavar lép fel:* Restore a mentésből, majd visszacsatolás a 2\. ponthoz (goto 10).
6. **Manuális humán teszt:** A futó rendszer ellenőrzése.
* *Ha inkonzisztens:* Restore és visszacsatolás.
* *Ha sikeres:* A projekt immár hivatalosan basode alapokon fut.

*Megjegyzés:* A basode keretrendszerben a syslayer-ek (a külső hagymahéjak) a projekt legvégéig folyamatos fejlesztés alatt állnak. Az ember-gép elvárások közötti eltérések folyamatosan visszahatnak a rendszer elemeire.

### **8.3 basode átszervezés: megvastagodott layerek szétválasztása **

Ez akkor áll elő, amikor a kiindulási állapothoz képest megváltoznak a hangsúlyok, és például egy tesztelési komponens egy kis agent workflow lépésből vagy egy rule-ból önálló dokumentációs layer-ré változik. Erre nincs kialakult gondolatom, inkább csak gyakorlatom. Az előző fejezetbe viszem ezt be: a feladat szerkezetében azonos, kiterjedtségében kisebb. 

## **9\. Ágens-támogatás (A keretrendszer automatizálása)**

Ahhoz, hogy az adminisztráció és a kettős könyvelés ne emberi teher legyen, magukat az autonóm ágenseket kell felkészíteni a basode szabályainak betartására.

### **Ágens képességek (Skills)**

* **Információ-allokációs logika:** Az ágensnek képesnek kell lennie eldönteni, hogy egy újonnan generált vagy kapott információ a DRY és az SSOT elvek alapján melyik syslayer melyik doclayer rétegébe való. Nem duplikálhat, hanem a meglévő helyre kell fűznie, vagy pointert kell létrehoznia.

### **Ágens szabályok (Rules)**

* **SSOT Registry iteráció:** Információ keresése esetén az ágensnek ismernie kell a dokumentációs láncolatot. Tudnia kell, hogyan navigáljon a legfelsőbb narratív szinttől a technikai megvalósításig anélkül, hogy elveszne a kontextusban.
* **Injektálási jogosultság (Write protocol):** Szabályozott hozzáférés és szintaktikai fegyelem (\ markerek elhelyezése) az információk dokumentációs rendszerekbe történő beírásakor, garantálva a kettős könyvelés szinkronitását.