Mérnöki esettanulmány
Egy moduláris üzleti platform és a keretrendszer, amin fut — egyszerre megépítve, egyetlen fejlesztővel, AI-asszisztált módszerrel. Ez a munkamódszer leírása, és azoké a méréseké, amelyek megmutatják, hogy megállt-e a lábán.
Egy fejlesztő. Egy termékfüggetlen portál-keretrendszer és egy teljes üzleti platform, egyszerre, a nulláról. 2026-09-07-i mérés szerint: 82 önállóan verziózott csomag, 4 697 commit, 2 045 kiadott verzió, 214 051 sor forráskód és 137 518 sor teszt — mindez 95 aktív munkanap alatt.
Nem ezek a számok a dokumentum lényege. Sok kódot gyorsan előállítani már egy ideje nem figyelemre méltó teljesítmény. Az érdekes kérdés a közvetlenül utána következő: mi akadályozza meg, hogy egy ilyen tempóban készülő kódbázis heteken belül karbantarthatatlanná váljon?
A válasznak két fele van. Az első néhány mechanizmus — tíz darab —, amelyek külön-külön egyáltalán nem látványosak, együtt viszont eldöntik a kérdést. Az állapot a lemezen él, nem egy beszélgetésben. Egy munkaegység egyetlen munkamenetre van méretezve, és soha nem marad félbe. Az architekturális döntések zároltak, nem nyithatók újra. Az állítás nem elfogadható, csak a bizonyíték. A séma szerződés, és a benne lévő hiány change request, nem rögtönzés. A munkafolyamok között kemény határok vannak. A tesztek pedig az a racsni, amitől biztonságos hozzányúlni olyan kódhoz, amit senki nem emlékszik megírni.
A második fele szervezeti. Nem egy asszisztens gépel diktálás után, hanem nyolc állandó ügynök-szerep dolgozik rögzített hatáskörrel, két gépen — az építők elválasztva azoktól, akik integrálnak és ellenőriznek —, és ezekből mindössze kettő szól valaha az emberhez. Mögöttük egy 1 067 dokumentumos tervezési kaszkád áll, és egy audit-mátrix, amely minden artefaktumot ahhoz mér, amiből származik.
A módszernek ára van, és ezt a dokumentum ki is mondja: nagyjából egy sor dokumentáció minden sor forráskódra. Ez az arány nem a munka körüli adminisztráció. Ez maga a munka — ez az a memória, amitől a következő munkamenet egyáltalán lehetséges.
Zöldmezős, a szó erős értelmében: nem volt kész keretrendszer, nem volt csapat, nem volt örökölt kódbázis, amit bővíteni lehetett volna. A cél egy üzleti platform volt egy szerviz- és eszközgazdálkodási vertikumra — ügyfelek, termékek, munkabizonylatok, eszközök, projektek, ticketek, pénzügy —, amit egy valódi integráló fél telepít, és aki közben várja a kiadásokat.
A meghatározó megkötés az volt, hogy két dolgot kellett egyszerre előállítani: egy termékfüggetlen portál-keretrendszert, és egy belőle összeállított üzleti platformot. Bármelyiket önmagában megépíteni hétköznapi munka. A kettőt együtt viszont azt jelenti, hogy minden keretrendszer-döntést azonnal terhel egy valódi fogyasztó, és minden termékigény visszahat a keretrendszerre. Nincs az a kényelmes szakasz, amikor az alap már kész és stabil.
A második megkötés a munkaerő szerkezete volt: egy ember, és AI-ügynökök, akik az építést végzik. Ez egy nagyon konkrét módon írja át egy projekt gazdaságtanát. A kód megírásának költsége összeomlik, és a szűk keresztmetszet az lesz, hogy mit tudunk biztosan a kódról — ez másik probléma, és minden alábbi erre adott válasz.
Azt is átírja, mit jelent az, hogy „egy fejlesztő”. A létszám egy maradt; a szerkezet nem. Ami kialakult, az egy ügynök-szerepekből álló szervezet, szétválasztott felelősségekkel, saját tervezési kaszkáddal és saját audit-szintekkel — ezekről az 5. és 6. szakasz szól. Aki a dokumentum többi részét úgy olvassa, mint egy ember gyorsabb gépelését, épp a lényeget hagyja ki.
Az AI-asszisztált projektek felismerhető módokon buknak el, és egyik sem a szokásos értelemben vett kódminőségről szól.
Amnézia. Az asszisztens nem emlékszik a tegnapra. Amit beszélgetésben megállapodtunk, de nem került lemezre, az a következő munkamenetre elveszett. Az így vitt projekt elsodródik, mert minden munkamenet kicsit más világképpel indul.
Kényszeres újratervezés. Egy lezárt döntést egy jó képességű asszisztens készséggel újranyit, és jobbat javasol. Külön-külön minden javaslat védhető. Összességében egy projekt, ami hetente újratervezi magát, és semmit nem fejez be.
Magabiztos tévedés. Az asszisztens sikert jelent. Független ellenőrzés nélkül a státusznapló megtelik olyan állításokkal, amelyek soha nem voltak igazak, és a napló meg a lemez közti eltérés jóval később, drágán derül ki.
Tegyük hozzá a sebességet, és megjelenik a negyedik: a hatósugár. Napi több kiadásnál, tucatnyi egymásra épülő csomag mellett egy megosztott rétegbeli módosítás elronthat egy olyan fogyasztót, amibe egy hétig senki nem néz bele.
A következő szakasz minden mechanizmusa e négy valamelyike ellen létezik. Egyik sem ötletes. Mindegyik le van írva, a repóban, még mielőtt szükség lett volna rá — mert az a szabály, ami csak valakinek a fejében él, nem éli túl a következő munkamenetet.
Ezek nem elvont alapelvek. Mindegyik konkrét artefaktumként létezik a repókban, és mindegyik a projekt saját munkadokumentumaiból származik.
Egyetlen státuszdokumentum a hiteles forrás arról, mi kész és mi következik. Minden munkamenetnek ezzel kell kezdenie, ellenőriznie az előző egység készültségi feltételét a lemezhez mérve, folytatnia a következő tervezett egységgel, és lezárás előtt frissítenie a fájlt. Ez a sarokkő: ettől lesz egy emlékezet nélküli asszisztensből folytonosságot tartó projekt.
A munkaegységek úgy vannak méretezve, hogy egyetlen munkameneten belül elkészüljenek. Ha egy egység túl nagynak bizonyul, fel kell bontani — és a felbontást a munka megkezdése előtt rögzíteni kell. Semmi nem marad félbe, mert épp a félbehagyott egység az az állapot, amit a következő munkamenet nem tud rekonstruálni.
A backend munkautasítás nyers mondattal kezdődik: a tervezés kész — építs, ne tervezz újra. Az architektúra és a technológiai stack számozott döntésnaplóként rögzített, és az építőnek kifejezetten tilos újranyitnia őket. Ez az egyetlen mondat állítja meg a heti újratervezést.
Külön ellenőrző szerep vizsgál minden munkaegységet a valósághoz mérve, mielőtt elfogadná. A projekt saját szavaival: az állítás nem elfogadható, a bizonyíték igen. Egy egység akkor kész, ha van artefaktum — egy lefutott tesztsorozat, egy publikált verzió, egy ellenőrzött image-lenyomat —, nem akkor, ha egy munkamenet ezt mondja.
Egy validált adatbázis-séma határoz meg minden adatszerkezetet. Az utasítás abszolút: pontosan tükrözni kell, és soha nem szabad mezőt kitalálni — a hiány számozott change request, nem rögtönzés a kódban. Ez egy egész elsodródási osztályt szüntet meg, mert pontosan egy hely van, ahol egy adatszerkezet legitim módon megváltozhat.
A backend munkautasítás szó szerint megtiltja, hogy a backend-fejlesztés alatt bárki hozzányúljon a frontendhez. A frontend oldalon abszolút szabály, hogy egy munkamenet egy ágon dolgozik — ezt egy incidens után vezették be, amikor commitok tévedtek rossz ágra, és visszavonással kellett takarítani. A határok teszik biztonságossá a párhuzamos ügynököket; nélkülük a párhuzamosság csak gyorsabb út a károkozáshoz.
Nem monorepo. Minden modul saját repó, saját verzióval, saját pipeline-nal és saját kiadási ritmussal, és a modulok közönséges publikált csomagként fogyasztják egymást. Két következménye számít: minden ügynök egy kicsi, körülhatárolt kontextusban dolgozik, amit ténylegesen át tud fogni, és a szemantikus verziózás lesz az integrációs szerződés olyan munkafolyamok között, amelyek soha nem nyúlnak egymás fájljaihoz.
A frontend mockolt adatokra épült, egy adapter-interfész mögött, pontosan a validált séma alakjában. A backend hónapokkal később érkezett, és ezen a varraton csatlakozott, a frontend átírása nélkül. Ugyanez a minta ismétlődik a számlázási szolgáltatóknál és a megosztott singletonoknál: előbb definiáld az illesztést, aztán építsd a két felét egymástól függetlenül.
Az első fázisban minden üzleti modul kapott egy működő vázat — lista, létrehozás, szerkesztés, törlés — séma-alakú mock adatokon. A mélyítés csak ezután indult. Ettől a teljes rendszer alakja korán láthatóvá és bírálhatóvá válik, amikor a változtatás még olcsó.
A kontraktus-tesztek egy függőség publikált típusai ellen fordulnak. A végponttól végpontig tesztek a valódi frontendet futtatják a valódi backend és valódi adatbázis ellen. A regressziós specifikációk arról a hibáról kapják a nevüket, amit lezárnak. Ettől lesz biztonságos, hogy egy ügynök hozzányúljon olyan kódhoz, amit sem ő, sem más nem emlékszik megírni — a racsni nem forog visszafelé.
Az „egy fejlesztő AI-segítséggel” a létszámról igaz, a szerkezetről félrevezető. Ami valójában fut, az egy kis szervezet: nyolc állandó ügynök-szerep rögzített hatáskörrel, két gépre osztva — és ezekből mindössze kettő szól valaha az emberhez.
A két gép közötti szétválasztás a lényeg. Az egyik gép épít; a másik integrálja, amit megépítettek, teszt-környezetbe telepíti, és integrációs teszteket futtat rá. Aki előállít valamit, soha nem az igazolja, hogy működik — ez a szétválasztás egy mérnöki szervezetben magától értetődő, AI-asszisztált felállásban viszont szinte soha nem valósul meg.
Az emberhez csak két vezető szerep szól, chaten: az egyik gépen a framework-integrátor, a másikon a frontend-leader. Mindenki más ügynök-ügynök egyeztet. Ez span-of-control döntés, és ettől kezelhető az egész egyetlen embernek: a termékgazda termék- és prioritáskérdésekre válaszol, nem üzenetbuszként működik. Az a felállás, ahol minden ügynök az embernek jelent, körülbelül háromnál nem skálázódik tovább — a legtöbb kísérlet ezért áll meg ott.
A munkamenet alatt a munka újra szétágazik. Minden szerep felokosított subagentekre bontja a saját munkáját — feladatonként egyre, mindegyiknek csak azt adva, amire az adott feladathoz szüksége van. A munkamenet így a felelősség egysége marad, ahogy az M2 megköveteli, a subagent pedig a végrehajtás egysége lesz. Az önálló auditor szerep ugyanígy dolgozik, és az alatta futó ellenőrzés is: a funkcionális teljességet a koncepciókkal olyan szerep és olyan subagentek vetik össze, amelyek nem állították elő a munkát.
A 4. szakasz mechanizmusai egy délután alatt átvehetők. Ez nem. Előre és írásban el kell dönteni, melyik szerep mihez nyúlhat és mihez nem — aztán tartani kell a vonalat épp azokban a pillanatokban, amikor átlépni gyorsabb lenne. Az M6 határszabályai nem szabályzati dokumentumok; ezek akadályozzák meg, hogy nyolc párhuzamos ügynök felülírja egymás munkáját.
Semmi nem épül beszélgetésből. Minden problémához koncepció készül; minden koncepcióhoz epicek; minden epichez issue-k és implementációs tervek. A kód implementációs terv ellen íródik, nem kérés ellen.
| Dokumentumosztály | Darab | Mire válaszol |
|---|---|---|
| Koncepciók | 64 | miért, és mi számítana megoldásnak |
| Epicek | 22 | milyen munkablokkokat jelent a koncepció |
| Issue-k | 609 | konkrétan minek kell megváltoznia |
| Implementációs tervek | 39 | hogyan — még mielőtt kód íródna |
| Rendszertervek | 167 | a kompozíciós rétegek megfelelője |
| Audit- és státuszjelentések | 166 | mit találtunk valójában |
| Összesen | 1 067 |
Önmagában a kaszkád csak papírmunka lenne. Attól lesz teherhordó, hogy minden szomszédos artefaktum-pár egymáshoz mérve auditálva van, három független tengelyen.
| Tengely | Szint | Mit vet össze |
|---|---|---|
| Feladat-nyomonkövethetőség | 3 | koncepció ↔ epic · epic ↔ issue és implementációs terv · issue és implementációs terv ↔ kód |
| Funkcionális lefedettség | 2 | koncepció ↔ use case-ek és funkciók · use case-ek és funkciók ↔ teszt-lefedettség |
| Tesztelés | 3 | unit · végponttól végpontig, funkció- és use-case-alapon · integrációs, funkció- és use-case-alapon |
A funkcionális lefedettség tengelye az, ami a legtöbb projektből hiányzik. Olyan kérdést tesz fel, amire a teszt-lefedettség önmagában nem tud válaszolni: nem azt, hogy „le van-e tesztelve ez a kód”, hanem hogy „megvan-e egyáltalán minden funkció, amit a koncepció ígért, és tesztelve van-e”. Egy kódbázis ülhet teljes sorlefedettségen úgy is, hogy a felét nem csinálja meg annak, amit kellett volna.
A bizonyíték három formát ölt: dokumentum, jelentés és képernyőkép. A tesztelés során készült képernyőképeket auditor subagentek ellenőrzik — egy ügynök vizsgálja egy másik ügynök vizuális bizonyítékát. Ezek a felvételek belső bizonyítékok, soha nem illusztrációk; ezért nem szerepel egy sem ebben a dokumentumban.
Egy módszerhez alapréteg kell, és az alapréteg is elkészült — a termék mellett, nem megvásárolva.
Minden konténerben fut, mindkét gépen — beleértve azokat a szerkesztő-szervereket is, amelyeken belül maguk az ügynök-munkamenetek futnak, és amelyek böngészőből elérhetők és felügyelhetők. A következmény, hogy egy munkamenet környezete reprodukálható és eldobható, nem pedig egy gép, amit valaki egyszer beállított, és most már nem tud újraépíteni.
Semmi nem kerül ki tesztelés nélkül, a valódi formájában. Mielőtt egy kiadás elhagyná a fejlesztői gépet, konténerben-konténerben lefut rajta a teszt — így az szállítódik, amit teszteltek, nem egy olyan build, ami történetesen átment a fejlesztő gépén.
A kiadási láncnak rögzített kapui vannak. Unit- és végponttól végpontig tesztek futnak a kiadáskor; a kiadás mindkét registrybe publikál, forrás- és konténer-oldalra; és minden integráció után teszt-üzembehelyezés és integrációs teszt következik a másik gépen. Egyetlen lépés sem marad ki azért, mert a változás kicsinek látszott.
Mindezt kiszolgálja a módszerhez épített eszközkészlet: egy orchesztrációs szolgáltatás, amely munkasoron keresztül futtat ügynök-munkafolyamatokat; egy absztrakciós réteg, amely a kódoló asszisztenst hívható API-ként teszi elérhetővé terminál-munkamenet helyett; és egy saját üzemeltetésű CI/CD-platform, amit kódügynökökre terveztek, nem emberi munkafolyamatból alakítottak át.
Ez az a rész, amit az AI-asszisztált fejlesztésről szóló beszámolók többsége elhagy, pedig a ráfordítás jelentős hányada. Az eszközkészlet a módszer futtatható formája: a szabály, ami csak egy dokumentumban él, megsérül — a szabály, ami egy pipeline-ba van kódolva, nem.
Az architektúra nagyrészt a módszer következménye, nem önálló döntés. Az ügynökök kicsi, körülhatárolt kontextusa sok kis csomagot jelent. A verziózás mint integrációs protokoll független kiadási pipeline-okat jelent. A varratok-előbb elv explicit rétegeket jelent.
A határtérkép legalább annyira számít, mint a rétegtérkép. A párhuzamos munkafolyamokat explicit szabályok tartják külön, és csak publikált verziószámoknál találkoznak.
A platform-mag első commitja 2026-03-18-i, a legutóbbi 2026-09-07-i: 173 eltelt nap, ebből 95 hordoz commitot. Ez 49 commit aktív naponta, egyetlen fejlesztőtől.
Az érdekesebb mérés viszont nem a ráta, hanem az alak. Minden commitot a prefixe szerint osztályozva, hónapokra bontva látszik, ahogy a projekt fázist vált — anélkül, hogy ezt bárkinek ki kellene jelentenie.
A kiadási ritmus ugyanezt mondja el más szögből — és megmutatja, hogy a rétegek szándékosan eltérő sebességgel mozognak.
| Vonal | Kiadás | Időablak | Naponta |
|---|---|---|---|
| Portál-keretrendszer | 74 | 164 nap | 0,45 |
| Backend host | 143 | 80 nap | 1,79 |
| Frontend host | 307 | 83 nap | 3,70 |
A modul-átfutási időt — első committól az első kiadásig — kimértük, és eldobtuk. Modulonként jóval egy nap alatti értéket adott, ami értelmetlen: a frontend modul-repók mind ugyanazon a napon jöttek létre, amikor egy fát önálló repókra bontottunk. Az első commitjuk a szétbontás dátuma, nem a munka kezdete. A kiadási ritmus lépett a helyére. Egy szám, ami hízeleg, de nem jelent semmit, rosszabb, mint ha nem lenne szám.
Szándékosan rövid: ez a módszer bizonyítéka, nem a dokumentum tárgya.
| Réteg | Repó | Commit | Kiadás | Forrás | Teszt | Dok. |
|---|---|---|---|---|---|---|
| Keretrendszer | 14 | 1 871 | 357 | 42 101 | 30 166 | 98 341 |
| Frontend | 39 | 1 757 | 1 038 | 85 178 | 47 601 | 59 816 |
| Backend | 29 | 1 053 | 650 | 86 772 | 59 743 | 22 044 |
| Összesen | 82 | 4 697 | 2 045 | 214 051 | 137 518 | 180 756 |
A leszállított felület: 765 API-művelet 439 útvonalon — publikus, ügyfél által elérhető API, nem backend-for-frontend; 129 tábla és 16 nézet egy számozott change requestekkel kormányzott sémában; 4 181 fordítási kulcs két teljes nyelven; és 52 katalogizált use case 6 szereplőre, mindegyik bizonyítékkal rögzítve, nem állítva.
1 263 frontend és 2 452 backend teszteset van. A végösszegnél árulkodóbb, hogyan oszlik meg a végponttól végpontig futó tesztkészlet:
| Készlet | Spec-fájl | Mi ellen fut |
|---|---|---|
| Mock mód | 289 | mockolt adat az adapter-varrat mögött |
| Use case-ek | 49 | katalogizált felhasználói utak, rögzítve |
| Valós mód | 118 | valódi backend, valódi adatbázis |
A frontend teszt-egészséget nem önértékeléssel, hanem két célra épített szkennerrel zárták le — az egyik a lefedettséget méri egy felületenkénti szabálykészlet ellen, a másik a szigorúságot: hogy egy teszt tényleg állít-e valamit, vagy csak azt ellenőrzi, hogy egy elem létezik. Végállapot: 1 189 teszt, 488 a 488 lefedettségi helyből kitöltve, 0 szigorúsági kifogás, és egy teljes futás 1 092 sikerrel és 0 bukással, 42 perc alatt.
Mindkét szkenner verziókövetett, és újrafuttatható azokon a repókon, amelyeket mér. Ez választja el a minőségi mérést a minőségi benyomástól: a számot eszköz állította elő, nem vélemény, bármikor reprodukálható, és egy későbbi futás nyugodtan ellentmondhat egy korábbinak.
A gyors fejlesztésről szóló beszámolók többsége az első szállításnál abbahagyja. Az a rész viszont, ami eldönti, hogy egy rendszert érdemes-e birtokolni, ezután jön — és mérhető.
Két hibafolyam futott párhuzamosan. Egy külső integráló fél, aki egy telepített kiadást tesztelt valódi adatokon, 17 tételt jelzett; ebből 16 valódi volt és javításra került, 1 pedig bizonyítottan nem volt hiba — teszt-fixture eltérés —, és ezt vissza is jelezték, nem csendben lezárták vagy láthatatlanul „megjavították".
Belül az integrált végponttól végpontig futások 34 észrevételt vetettek fel. Ebből csak 17 élte túl a triázst valódi hibaként; 15 javításra került, egyet tudatosan elutasítottak, egyet átsoroltak. A felvetett észrevételek fele nem volt hiba — pontosan ezért kezdődik a hurok ellenőrzés-alapú triázzsal, nem javítással. A projekt saját fegyelmi dokumentuma úgy fogalmaz: egy hamis javítás egy nem-hibán maga is regresszió.
Hét hiba ment át a mock módú tesztkészleten, és csak a valódi backend ellen bukott meg — három egyetlen kiadásban, további négy a javítási kör alatt. Egy zöld tesztkészlet mockolt adaton nem bizonyítja, hogy a rendszer működik. Az egész kiadási kapu ezért futtatja a valódi klienst a valódi szerver ellen.
Egy backend lefedettségi átvizsgálás során 14 látens hibát találtak, és szándékosan nem javították. Mindegyiket bizonyítékkal rögzítették, és mindegyikhez tartozik egy jellemző teszt, amely a jelenlegi, hibás viselkedést állítja — így a teszt abban a pillanatban pirosra vált, amikor valaki javítja a hibát. Az indok, hogy egy lefedettségi átvizsgálás és egy javítási kör két különböző kockázati profilú tevékenység, és a keverésük mindkettőt nehezebben ellenőrizhetővé teszi.
A frontend oldalon a 289 mock módú specifikációs fájlból 32 arról a konkrét hibáról kapta a nevét, amit lezár. Egy javított hiba teszt nélkül olyan hiba, aminek a visszatérése be van ütemezve.
Az önértékelés ezen a méreten értéktelen, ezért a platformot két független külső tengelyen auditálták: egy folyamat-keretrendszer (az APQC Process Classification Framework) és bevett nyílt forráskódú ERP- és CRM-rendszerek adatmodell-alapvonalai ellen. Bizonyítéknak csak sématábla, API-végpont vagy modul-manifest számított. Az önbevallás semmit nem ért.
| Terület | Folyamat | Teljes | Részleges | Hiányzik | Súlyozott |
|---|---|---|---|---|---|
| ERP | 74 | 19 | 31 | 24 | 47% |
| CRM | 42 | 5 | 18 | 19 | 33% |
A verdikt hasznos módon volt kedvezőtlen. Ami elkészült, az egy szerviz- és eszközgazdálkodási rendszer erős dokumentumlánccal — nem általános ERP és nem CRM. A dokumentummotor és a platform-réteg a nyílt forráskódú referenciák fölött mért. Az értékesítési tölcsér felső fele — érdeklődő, minősítés, lehetőség, fázis, előrejelzés — nullán.
Ezek a számok szándékosan szerepelnek itt a kedvezőek mellett. Az az esettanulmány, amelyik csak a győzelmeiről számol be, semminek nem bizonyítéka; a hajlandóság, hogy 33%-ot leírjunk, az teszi a dokumentum többi részét olvasásra érdemessé.
A legerősebb állítás ebben az esettanulmányban nem a méretről vagy a sebességről szól. Hanem arról, hogy a keretrendszer valóban termékfüggetlen — és ehhez az állításhoz van kontrolleset.
Két alkalmazás fut ugyanazon a keretrendszeren. Az egyik a teljes üzleti platform: tucatnyi üzleti modul, komplett dokumentumlánc, publikus API, több bérlős jogosultságkezelés. A másik egy referencia-alkalmazás, amely ugyanazt a vázat és néhány generikus modult állít össze — saját megfogalmazásában konfiguráción túli egyedi kód nélkül, nagyjából száz sorban. Ugyanaz a keretrendszer, ugyanaz a váz, ugyanaz a plugin-futtató; gyökeresen eltérő termékek.
Az üzleti következmény a lényeg: egy következő termék nem újraírás, hanem modulválogatás. Ugyanazon rétegek másik kompozíciója más hatókörű rendszert ad — szervizirányítás, eszközgazdálkodás, értékesítési bizonylatlánc — anélkül, hogy hozzá kellene nyúlni a megosztott rétegekhez, amelyeken mindegyik nyugszik.
A platform-mag 214 051 sor forráskódot és 180 756 sor dokumentációt tartalmaz. Nagyjából egy az egyhez.
Ez az arány a módszer őszinte költsége, és szembemegy azzal a közkeletű várakozással, hogy az AI-asszisztencia kevesebb szöveg írását jelenti, nem többet. Nem azt jelenti. Ha a munkaerőnek nincs memóriája, akkor az írott feljegyzés maga a memória — a státuszfájlok, a döntésnaplók, a change requestek, a bizonyíték-nyomvonalak, a munkautasítások. Vedd el őket, és a 4. szakasz mechanizmusai egyszerre omlanak össze. Aki átveszi ezt a módszert, tervezzen ezzel, és számítson rá, hogy a dokumentáció aránytalannak fog tűnni — egészen az első munkamenetig, amelyik különben a nulláról indult volna.
A rendszer nincs kész, és a projekt ezt a saját nyilvántartásában ki is mondja. Modulonkénti halasztási lista nevezi meg minden szándékosan kihagyott képességet, a hozzá szükséges sémaobjektumokkal együtt. Egy ratifikált verzió-ütemterv sorba rendezi a hátralévő munkát. Tizennégy látens hiba rögzítve és szándékosan javítatlanul áll. A külső audit hat képesség-hiányt nevez meg prioritási sorrendben, a szolgáltatási szint-megállapodásokkal és az értékesítési tölcsérrel kezdve.
Ebből semmi nem mentegetőzés. Az a projekt, amelyik pontosan fel tudja sorolni, mit nem épített meg, ugyanazt a fegyelmet mutatja, mint az, amelyik bizonyítani tudja, mit igen.
Nem szünteti meg az ítélőképesség szükségességét — a 12. szakasz triázs-számai megmutatják, hogy a felvetett észrevételek fele emberi döntést igényelt arról, mi is igaz valójában. Nem teszi egy fejlesztőt egy csapattal egyenértékűvé; azt teszi lehetővé, hogy egy fejlesztő ekkora rendszert olyan formában tartson, amely túléli a távollétét. És semmit nem mond arról, hogy a termék a jó termék-e: erre a kérdésre a 13. szakasz válaszol, egy audittal, és a válasz részben nem.
Az itt leírt módszer egyetlen projektből és egyetlen vertikumból nőtt ki; hogy mennyi vihető át belőle, azt őszintén szeretném megtudni. Ha valaki így visz projektet, mérlegeli, vagy próbálta és arra jutott, hogy nem áll meg — érdekel az összevetés. Erb Ferenc a LinkedInen