Mérnöki esettanulmány
Kódot írni AI-jal ma már hétköznapi. Futó gépet változtatni vele nem az, mert itt egy rossz lépés nem egy commitba kerül. Hanem egy hostba, ami nem indul el. Így ment mégis, négyszer, írott módszertan szerint — és abból a négy gépből hármon maguk az agentek laknak.
Négy gép, AI-agenttel üzemeltetve, írott módszertan szerint, 347 nap és 160 commit alatt. Az a rész, ami meglepi az embereket: a négyből három azért létezik, hogy az AI fejlesztő ügynököknek legyen hol dolgozniuk. Az agent a saját élőhelyét tartja karban.
A negyedik a szokásos eset — egy alkalmazás éles, staging és teszt környezete. Vagyis a négyes lefedi a munka mindkét felét: a birtokot, amin az agentek élnek, és egy valódi rendszert, aminek felhasználói vannak.
És most a szám, ami megmondja, mi ez a munka valójában. A 326 dokumentumból 234 issue-bejegyzés. Mindennek a háromnegyede, ami leíródott, arról szól, hogy valami elromlott. Ez nem hibaarány. Így néz ki az üzemeltetés, ha becsületesen írod le — és bármelyik módszer, ami ennél rendezettebb papírmunkát termel, egy másik munkát ír le.
Alatta: 119 790 sor dokumentáció, 94 szkript, 391 deployment-fájl. Egyetlen egy ember írta, aki húsz éve üzemeltetett utoljára — és aki a négy platform egyikéhez soha életében nem nyúlt.
Egyetlen cím, hostnév, hálózati tartomány, felhasználónév vagy hardvermodell sem szerepel ebben a dokumentumban. Ezek a gépek még futnak. Egy kiszivárgott cím nem kellemetlenség, hanem térkép. A technológiák viszont meg vannak nevezve, mert egy eszköz megnevezése senkit nem azonosít, és ez az a rész, amivel kezdeni tudsz valamit.
A felidézés az agenté. Az ítélet az üzemeltetőé. A fegyelem a módszertané.
Három tagmondat, és a középsőt hagyja ki mindenki. Mondjuk hát ki nyersen, melyik változata egyszerűen hamis:
„Nem kell többé érteni az üzemeltetéshez, megcsinálja az AI." Aki ezt elhiszi, ki fogja hagyni a mentést, mert nem érzi, mit kockáztat. A mentés pedig az egész oka annak, hogy ez a módszertan létezik. Az állítás csak a második tagmondattal együtt működik.
Ami tényleg igaz, az szűkebb és hasznosabb. A szükséges szaktudás alakot vált. Kikerül a memóriából, és átköltözik az ítéletbe. Nem kell fejben tartanod a szintaxist, a kapcsolók nevét és azt, hol laknak a konfigurációs fájlok — az agentnél mindez megvan, végig, és sosem fárad el. Amit viszont neked kell vinned, az az a rész, ami eldönti, lefuttassuk-e egyáltalán: mihez nyúl ez, mi törik el, ha rossz, vissza tudom-e csinálni, és az előttem lévő állítást megmérte valaki, vagy csak jól hangzik?
Ezt a változatot elhiszi bárki, aki valaha üzemeltetett, mert egyezik azzal, amit már tud. A veszélyes rész sosem a gépelés volt.
Van itt egy célpont, ami tovább viszi az állítást, mint a húszéves történet. A négyből az egyik olyan platformon fut, amin az üzemeltető soha nem dolgozott. Nem volt mi elkopjon, és nem volt mit visszaadni. Mégis működött — mert a „ments előbb", az „ellenőrizd, hogy odaérsz" és a „mondd meg, hogy mérted-e" nem platformtudás. Ezek mindenhol ugyanazok. A 13. szakaszban ott a csapda, ami ezzel jár.
Minden más egyetlen különbségből következik, úgyhogy ez megy előre.
Egy repóban valaki már megépítette neked a védőhálót. A verziókövetés megőrzi az előző állapotot, akár gondoltál rá, akár nem. Egy gépen nincs ilyen ajándék: a változtatás előtti állapot csak azért létezik, mert valaki gondoskodott róla, előre, szándékosan.
Ezért nincs köze a képességhez az első alapelvnek abban az útmutatóban, amit az agentnek el kell olvasnia — és ez az az egyetlen alapelv, ami mind a négybe bele van írva. Így szól: ments, mielőtt változtatsz; ellenőrizd az előfeltételeket; validáld az eredményt; soha ne hagyj ki egy biztonsági lépést azért, mert lassú. Az utolsó tagmondat végzi az érdemi munkát. Senki nem azért hagy ki egy biztonsági lépést, mert hibásnak tartja. Azért hagyja ki, mert lassú.
Egy módszer egyetlen alkalmazása anekdota. Négy, a stack négy különböző szintjén, már kezd mintának látszani.
Nézd meg a jobb oldali címkéket, és átrendeződik a dolog. Ez nem négy egymástól független doboz. Három közülük az a birtok, amin az AI-fejlesztés zajlik, egy pedig egy valódi alkalmazás valódi felhasználókkal. Az agent nem csak gépeket üzemeltet. Karbantartja azt a helyet is, ahol a kollégái dolgoznak.
A csupasz vasas megérdemel egy külön mondatot, mert annak van foga. Egy fejlesztői gép és egy tároló ugyanazon a hardveren ül. A fejlesztői oldal azért van, hogy kísérletezzenek rajta. A tároló oldalon olyan adat van, aminek túl kell élnie. Ugyanaz a doboz. Ez nem elvont „a meglévő adatot meg kell őrizni" — ez egy gép, amivel egyszerre akarsz vakmerő és óvatos lenni.
A negyediket az írja le, miből áll, nem az, hogy mi: Node és React szolgáltatások identitáskezelővel, headless CMS-sel, adatbázissal, cache-sel és monitorozással, konténerekben, élesben, stagingen és teszten. Ez szándékos — és őszintén szólva amúgy is ez a jobb leírás, mert ha valami hasonlót futtatsz, magadra ismersz benne. Egy terméknév semmit nem mondott volna.
| Gép | Commit | Dokumentum | Dok. sor | Szkript |
|---|---|---|---|---|
| egy szerver operációs rendszer | 40 | 104 | 46 570 | 27 |
| egy távoli build-gép | 12 | 48 | 20 540 | 0 |
| egy sokrészes alkalmazás | 76 | 115 | 40 007 | 30 |
| csupasz vas és virtualizáció | 32 | 59 | 12 673 | 37 |
A build-gépnél egyetlen szkript sincs. Ez inkább tanulságos, mint kínos: ott szinte minden egyszeri konfigurációs döntés volt, nem olyasmi, amit érdemes automatizálni. Egy minta, ami ragaszkodna hozzá, hogy a szkriptmappa tele legyen, ceremóniát termelt volna, nem értéket.
Hét rögzített dokumentum és hét rögzített könyvtár, mind a négy repóban. Méréssel ellenőrizve, nem emlékezetből.
Két dolog miatt ez több egyszerű iktatásnál. Először: a végrehajtási útmutató az agentnek szól, nem embernek, és azzal kezdődik, mit kell az agentnek önmagáról ellenőriznie, mielőtt bármit tenne. Másodszor: a szerkezet azonos olyan gépek között, amiknek technológiailag alig van közük egymáshoz — vagyis egy session, ami már dolgozott az egyiken, tudja, hol keresse a dolgokat a többiben.
Ez az igazi haszon agenttel: a tájékozódás szinte nullára esik. Márpedig egy session az első erőfeszítésének nagy részét pont tájékozódásra költi.
Egy agent semmire nem emlékszik a gépről két session között. Tehát a gép állapotának adatként kell valahol laknia — különben minden session találgatással kezd, és pontosan ez az, amit nem akarsz egy visszafordíthatatlan lépés előtt.
Két tulajdonság teszi megbízhatóvá, nem csak meglévővé.
Minden értéken rajta a dátum. A gépek elcsúsznak. Egy fél éve megállapított érték a múltról szóló állítás, jelen időbe öltözve. A dátum nélküli állapot rosszabb a semmilyennél, mert elhiszik.
Az értékek megmondják, mértek-e. A fájl a saját szövegében különbözteti meg azt, amit valaki megfigyelt a gépen, attól, amit a dokumentációból feltételeztek. Ez a következő szakasz, és az itteni leghordozhatóbb gondolat.
4-ből 3 repóban a sablon van verziókövetve, az élő állapotfájl szándékosan nincs — mert az a gép valódi címeit tartalmazza. A negyedikben követve van. Ez eltérés a gyakorlatban, és itt le van írva ahelyett, hogy egységes szabálynak tüntetnénk fel valamit, ami sosem volt egészen az.
Egyenesen abból az útmutatóból, amit az agentnek először el kell olvasnia. Érdemes pontosan megmondani, honnan: ez a négy útmutató közül a legutolsóban van benne, nem mindegyikben. A módszer menet közben élesedett, és ez a legélesebb, amihez eljutott.
Mondd ki világosan, melyik állításod mért és melyik következtetett. Nem felcserélhetők, és a különbség pont akkor számít a legtöbbet, amikor a következő lépés visszafordíthatatlan.
Az agentek gördülékenyek. És pont ez a baj: egy ésszerű tipp és egy közvetlen megfigyelés teljesen egyformán jön ki. Ugyanaz a magabiztosság, ugyanaz a megfogalmazás, egyikben sincs bizonytalanság. Kódírásnál ez egy bukó tesztbe kerül. Egy partícionáló parancs előtt valamivel többe.
Ezért nincs a jószándékra bízva a megkülönböztetés. Be van tolva az eszközökbe. Az állapotfájl mértként jelöli a mért értékeket. Az útmutató kimondatja az agenttel, melyik melyik. Az eredmény: elolvasol egy javaslatot, és kérdezés nélkül látod, mely részei támaszkodnak arra, amit valaki tényleg megnézett.
Bármelyik feladat előtt az agent leellenőrzi, hogy tényleg eléri-e azt a gépet, amiről azt hiszi, hogy üzemelteti. Egy dokumentált cím nem bizonyíték.
Az előző alapelvhez hasonlóan ez is a legutolsó útmutatóba van beírva, nem mind a négybe — az alábbi hiba után került bele, és a jó szabályok nagy része így születik.
Pont addig hangzik bürokráciának, amíg meg nem látod, mit fog meg. Egy agent futtatókörnyezete nem rögzített. Lehet konténerben, virtualizált alrendszerben, más gépen, mint múlt héten. Az a hálózat, amit lát, nem feltétlenül az, amit a dokumentáció leír — és belülről esélye sincs észrevenni.
Az agent nem érte el a gépet. Az internet ugyanabból a futtatókörnyezetből tökéletesen ment, tehát egyáltalán nem látszott hálózati gondnak. Az ok: egy konténer-bridge segítőkészen kiosztott magának egy alhálózatot, ami átfedte a fizikai hálózatot, és csendben megette az összes arrafelé tartó csomagot.
A mellé iktatott tanulság: az útválasztást nézd, ne a tűzfalat — és ellenőrizd a saját elérésed, mielőtt bármelyik dokumentált címben megbíznál. A legnehezebben megnevezhető hibák azok, amelyek mellett a hálózat nagy része tovább működik.
Amitől ez háborús történetből szabály lesz, az az általánosítás: egy agentnek előbb meg kell állapítania, hol van, mielőtt a világ bármilyen leírása alapján cselekszik. A dokumentáció nem volt hibás. Az agent egyszerűen nem ott volt, ahol a dokumentáció feltételezte — és ezt a dokumentációból semmi nem mondhatta volna meg neki.
Két végrehajtó, leírt határral: egy ember a fizikai gépnél, egy agent SSH-n.
Bizonyos dolgok nem delegálhatók, és ezen semennyi képesség nem változtat. Telepítőt tenni egy pendrive-ra. Nézni egy boot-képernyőt. Megerősíteni, hogy a monitoron tényleg ott a bejelentkezési prompt. Ott lenni, amikor ki kell húzni a tápot. A módszertan ezt hangosan kimondja ahelyett, hogy úgy tenne, mintha nem így lenne — és ez számít, mert a kimondatlan határ az a hely, ahol egy terv csendben feltételezi, hogy valaki elérhető lesz.
Az érdekes rész nem a szétválasztás, hanem az átadás: ellenőrzött, nem feltételezett. Az ember része olyasmivel zárul, amit az agent maga is le tud ellenőrizni, és az agent része azzal kezdődik, hogy leellenőrzi. Az az átadás, ahol az egyik fél egyszerűen sikert jelent a másiknak, nem átadás. Az remény, időbélyeggel.
Arra a kérdésre is válaszol, amit az emberek valójában fel akarnak tenni — mi lesz, ha hajnali háromkor elromlik? Valakinek továbbra is oda kell tudnia állni a gép elé. Jobb ezt előre tudni, mint az incidens közben felfedezni.
| Fajta | Dokumentum | Mi ez |
|---|---|---|
| Issue | 234 | valami elromlott, vagy egy döntést rögzíteni kellett a következő visszafordíthatatlan lépés előtt |
| Eljárás | 39 | hogyan kell csinálni valamit, végrehajtásra írva |
| Riport | 37 | mit csináltunk, és hogy sült el |
| Referencia | 3 | mi van, visszakereséshez |
A dokumentáció háromnegyede issue. Nem eljárás, nem letisztult referenciakönyvtár — annak a rögzítése, ami félrement, és azoké a döntéseké, amiket írásba kellett fagyasztani, mielőtt bármi visszafordíthatatlan történt.
Ezen az arányon érdemes elidőzni, mert ellentmond annak, ahogy ezt a munkát be szokták mutatni. Gépeket agenttel üzemeltetni nem eljárások rendezett polcát termeli. Hanem egy jókora halom incidenst, kérdést és indoklással ellátott döntést. Az eljárások az az üledék, ami akkor marad, amikor ez mind leülepedik.
Azt is megmagyarázza, miért így olvasnak a dokumentumok. Olyan agentnek készülnek, aki egyiknél sem volt ott. Egy issue, ami csak azt rögzíti, mit csináltak, használhatatlan neki. Az az issue, ami rögzíti, mit vártak, mi történt valójában, és mire jutottak, az teszi lehetővé, hogy a következő session ne ismételje meg.
A négy gépből három azért van, hogy agentek dolgozhassanak rajtuk. Ami azt jelenti, hogy az üzemeltetési problémák jó részét maguk az agentek okozzák.
Ez kevésbé baljós, mint amilyennek hangzik, és sokkal érdekesebb. A fejlesztői munka lemezt fogyaszt. Konténereket indít. Portokat foglal. Állapotot hagy szanaszét. Csináld ezt folyamatosan, olyan gépeken, amiknek közben fent is kell maradniuk, és kapsz egy rendszert, ami maga termeli az incidenseit.
A 8. szakasz útválasztási hibája pont ebből a fajtából való. Egy fejlesztői eszköz konténer-bridge-e elkapott egy alhálózatot, ami átfedte a fizikai hálózatot, és elnyelte a forgalmat. Senki nem támadott semmit. A birtok saját magában botlott meg.
Ma ezt a hurkot kézzel zárjuk be. Egy agent okozza a problémát, egy ember észreveszi, egy ember szól az üzemeltető agentnek, az üzemeltető agent megjavítja. Az ember egy üzenetbusz — egy olyan üzenetbusz, aminek aludnia is kell.
A kézenfekvő következő lépés az, hogy kivesszük az embert abból a középső helyről. Hadd jelezze a fejlesztő agent közvetlenül az üzemeltető agentnek, akinek már most van leírt szerepe, eljárásai, állapotfájlja és feljegyzése arról, mi ment el korábban. Ennek a nagy része már megvan. Ami hiányzik: egy csatorna és egy jogosultsági határ.
Ha az agentek egyszerre okozzák és jelentik a hibát, akkor az üzemeltető agent bemenete abból jön, ami elrontotta. Egy bejelentés pedig következtetés, akármilyen magabiztosan van megfogalmazva.
Itt szűnik meg a „mért, vagy következtetett?" kedves alapelvnek lenni, és válik azzá a gerendává, ami a tetőt tartja. Az üzemeltető agentnek újra kell mérnie a gépet, nem elhinnie a jegyet. Különben a hurok bezárul, csak épp rosszul.
Ebből adódik a határ, és ez nem új. Ugyanaz a vonal, amit a módszertan már meghúzott a két végrehajtója között — csak most a fejlesztő agent áll a lánc elején, nem egy ember.
| Munkaosztály | Ki dönt | Miért |
|---|---|---|
| Visszafordítható — diagnosztizál, újramér, javít, jelent | az üzemeltető agent, végig | ha rossz, vissza lehet csinálni, és a rögzítésből látszik, mit csinált |
| Visszafordíthatatlan — amit nem tudsz visszavenni | ember hagyja jóvá | a szabály nem változott: visszafordíthatatlan lépés nem állhat következtetésen |
Kereken kimondva: az eszkaláció automatizálható. Az a döntés, hogy csinálunk-e valami helyrehozhatatlant, nem. Ez nem önmagáért való óvatosság — ez ugyanaz a mondat a 7. szakaszból, egy láncszemmel feljebb alkalmazva.
347 nap az első committól a legutóbbiig, és 62 különböző napon van commit — összesen 160 commit a négy repóban.
| Gép | Első | Utolsó | Nap committal |
|---|---|---|---|
| egy szerver operációs rendszer | 2025-10-15 | 2026-09-27 | 23 |
| egy távoli build-gép | 2025-11-14 | 2026-01-27 | 5 |
| egy sokrészes alkalmazás | 2026-01-22 | 2026-08-11 | 28 |
| csupasz vas és virtualizáció | 2026-09-14 | 2026-09-27 | 10 |
Sebességre vonatkozó szám sehol nincs ebben a dokumentumban, szándékosan. Ez egy minta négy alkalmazása, mindig akkor indítva, amikor egy gépnek éppen kellett valami. A commitokat elosztani a napokkal olyasmit adna, ami ütemnek látszik és semmit nem jelent — egy dokumentumban pedig, aminek az egész érvelése a mért és a következtetett megkülönböztetéséről szól, ez többe kerülne, mint amennyit hozna.
Az alakja őszintén göröngyös is. Az üzemeltetés nem projekt burn-down görbével. Egy gép négy hónapig érintetlen, aztán követel egy hetet — és a rögzítés pontosan ezt mutatja.
Ennek a hasznos és a veszélyes fele közvetlenül egymás mellett ül, úgyhogy szét kell húzni őket.
Nem szünteti meg annak szükségességét, hogy legyen valaki, aki tudja, mikor kell gyanakodni. A módszertan a fegyelmet rögzíti — előbb ments, ellenőrizd az elérést, jelöld, amit mértél. Azt az ösztönt nem tudja pótolni, ami észreveszi, hogy egy magabiztos javaslat hibás. Itt ez az ösztön onnan jött, hogy húsz éve volt üzemeltetés. A felidézés elveszett; az ítélet nem. Ha egyikkel sem rendelkezel, nem vagy ugyanabban a helyzetben, és nem is úgy kellene ezt olvasnod.
És egy ismeretlen platformon ez a rés tágabb. A négyből az egyik olyan platformon fut, amihez az üzemeltető soha nem nyúlt. A módszer ott is működött, mert a biztonsági szabályok nem platformtudás. De van egy csapda, amit ki kell mondani: olyan platformon, amit nem ismersz, a kockázatot továbbra is meg tudod ítélni — mihez nyúl ez, vissza lehet-e csinálni —, a konkrétumokat viszont egyáltalán nem tudod józan ésszel ellenőrizni. A mentés, a nulladik lépés és a mért-jelölés ott nem extra ceremónia. Az az egyetlen dolog, ami a hiányzó tudás helyén áll.
Nem teszi biztonságossá a visszafordíthatatlan műveleteket. Felkészültté teszi. Más szó, és a különbség az a mentés, amit azelőtt csináltál, hogy szükséged lett volna rá.
És nem hatékonysági állítás. Semmi nem mondja itt, hogy ez legyőz egy gyakorlott rendszergazdát, aki kézzel csinálja. Azt mondja, hogy lehetséges, megismételhető és le van írva — ezek más tulajdonságok, és hasznosabbak, amikor a munkát két évtizede nem csinálta senki.
És dátumhoz kötött. Ez 2025 végétől 2026-ba tart. Ami az akkori eszközkészlettel lehetséges volt, nem az, ami később lesz, és egy ilyen beszámoló hónapok alatt öregszik. A mérés dátuma ezért van rajta minden oldalon.
Három dolgot, érték szerinti sorrendben. Az állapotfájlt — gépenként egy dokumentum arról, mi az valójában, minden értéken dátummal, és jelöléssel azokon, amiket valaki megmért. A rögzített szerkezetet — ugyanazok a dokumentumok és könyvtárak minden gépnél, hogy egy session ne tájékozódásra pazarolja az első erőfeszítését. A nulladik lépést — az agent kiderítse, hol van, mielőtt bárki világleírása alapján cselekszik.
Soha ne hagyj ki egy biztonsági lépést azért, mert lassú. És: mondd ki világosan, melyik állításod mért és melyik következtetett. Mindkettőt olcsó bevezetni, és egyik sem függ egyetlen itt leírt dologtól sem.
Írásba. 119 790 sorba, aminek nagy része arról szól, ami elromlott. Ha ez soknak hangzik, az őszinte válasz az, hogy az alternatíva az, hogy mindez egyetlen ember fejében lakik — márpedig pont ettől lesz karbantarthatatlan egy rendszer, és ebben az állapotban egy agent egyáltalán nem tud dolgozni.
Ott, ahol valakinek a gép mellett kell állnia. És annál az ítéletnél, hogy lefuttassuk-e a parancsot — az továbbra is a tiéd, és azt érdemes élesen tartani.
Ha valaha üzemeltettél rendszereket, és ma nem bíznád magadra egyedül — vagy ha futtatsz valami ilyesmit, és másképp mesélnéd el —, szívesen összevetném.