It Coach - Erb Ferenc

27/09/2026

Mostanában sokszor leírom, hogy mindent, ami informatika, azt az AI-jal csinálom.
Van egy dolog, amit nem: az a számítógép-szerelés. Ahhoz nem is értek igazán, és ahogy öregszem, úgy nem is megy már igazán... 😂
Ezért amikor kiderült, hogy új gépre van szükségem, mert a régi NAS-om már nem tudja azt, ami mostanában az elvárás, ez lett az első szempont — a lehető legkevesebbet kelljen rajta csavarozgatni.

A NAS-om ugyanis nem tudott Dockert futtatni.
Tárolónak évekig tökéletes volt, de amikor ma már minden konténerben fut, zsákutca lett. Sajnos fejleszteni sem lehetett rajta.
Olyan megoldást kerestem, ami három szempontnak is eleget tud tenni, kb. ebben a sorrendben:
→ a régi NAS-lemezek menjenek bele, hogy ne kelljen adatot költöztetni
→ valami minipc-szerű legyen (mert a többi, ami van, az is az) és ne szerverszekrény
→ és minél kevesebb szerelés
Így lett AOOSTAR WTR PRO.
Négy lemezhely, Ryzen 7 5825U, 32 GB RAM + 1 TB SSD. A régi lemezek bementek, és csak a RAM és az SSD kellett bele, és ennyi volt a szerelés.

Proxmox került rá, mert így egy vason elfér a tároló és egy fejlesztői gép is. Az egyiken kísérletezni akarok. A másikon továbbra is tárolni az adatokat.
Az architektúra kiválasztásához persze az AI-t használtam, ahogy mostanában mindenki. A rendelési lista sem volt hosszú, de abban is segített.

És itt jön a legérdekesebb, amivel talán kezdenem kellett volna:
az üzembehelyezést is az AI csinálta, onnantól, hogy az alap USB-ről telepítés lefutott és rálátott a hálózaton.

És itt kaptam észbe. Sokat írok arról, hogyan fejlesztek AI-jal.
Arról azonban eddig semmit nem tettem közzé, hogyan üzemeltetek vele. Pedig az egy másik — talán sokak által vitatott — műfaj.

Fejlesztésnél egy rossz lépés egy commitba kerül.
Egy futó gépen egy hostba, ami nem indul el — vagy adatba, ami nincs többé. Egy repóban valaki már megépítette neked a védőhálót.
Egy gépen a változtatás előtti állapot csak akkor létezik, ha valaki előre gondoskodott róla.

Húsz éve üzemeltettem utoljára. Amit azóta elvesztettem, az a konkrét parancsokra emlékezés, nem az, hogy mit szeretnék vagy hogy mi a feladat — hanem hogy hogyan is kell azt elvégezni a konkrét környezetben. Ezt a tudást adja vissza az AI, korlátlanul.
Azt persze nem, hogy mikor kell gyanakodni, hogy valamivel baj lehet... mert ugye azzal baj is lesz az üzemeltetésben, ahogy mondani szokták: óvatosan a fejszével! 🤣

Írattam is az AI-jal, az AI üzemeltetési tapasztalataim alapján, ezen a friss élményen felbuzdulva egy esettanulmányt.
Négy különböző környezetről szól, nem csak erről az egyről.
Itt találjátok:
https://fefehun.github.io/ai-based-operations-case-study/hu/
https://fefehun.github.io/ai-based-operations-case-study/

Live machines run by an AI agent under a written method. Recall to the agent, judgement to the operator, discipline to the method — and three of the four machines are the agent's own habitat.

07/09/2026

📐 Belejöttem az esettanulmány-írásba.

Az előző működött, és mivel a módszertan itt is ugyanaz a zárt rendszer, gondoltam megmutatok egy korábbi munkát is, ami teljesen más szempontból lehet érdekes.

Ha érdekel, itt olvashatod:
🇬🇧 https://fefehun.github.io/legacy-rewrite-case-study/
🇭🇺 https://fefehun.github.io/legacy-rewrite-case-study/hu/

Az előző esettanulmány a nulláról fejlesztésről szólt, ami elég ritka dolog.
Ez a most bemutatott a másik fele a szakmának.

Egy működő éles rendszer érkezik egy mappában, 2 régi technológiai stackkel (frontend: angular, backend: php), a készítői már nincsenek meg, specifikáció sosem létezett.

És őszintén: sokkal több cégnek van ilyen rendszere, mint zöldmezős projektje.

Amik itt a számok:
🔹 8 sor dokumentáció minden sor forráskódra
🔹 nulla automata tesztről 50 262 sor tesztre
🔹 8 átadási csomag, 4 stack-konfiguráció, 5 elfogadási kör
🔹 234 nap, ebből 96 aktív, két fejlesztővel
A nyolcszoros arány nem szorgalom. Az ügyfél nem kódot vett — kódja már volt, évek óta, élesben. Ami hiányzott neki, az a megértés.

A megértésnek pedig nincs más formája: vagy dokumentációként létezik, vagy sehogy.

📌 A legjobb rész viszont a tesztstratégia.
A tesztkészlet az EREDETI rendszerre készült el először, még mielőtt bármit hozzáértünk volna. Az lett a szerződés.
Utána a két felet (frontend: angular → react, backend: php → node) külön cseréltük — soha nem egyszerre. Négy állapot, két független csere, egy változatlan mérce.
Ha valami nem megfelelő, annak egy lehetséges oka van, nem kettő.

Az orákulum ugyanis fogyó eszköz: azon a napon, amikor a régi rendszert lekapcsolják, a „mit kellett volna csinálnia" kérdésre örökre elérhetetlen a válasz. Írd le a kérdéseket, amíg van, ami válaszol rájuk.

📎 Ami nem sikerült, az is kint van.
A projekt fázishatáron áll jelenleg. A felhasználó által jelzett hibák mind javítva és visszajelezve — a belső tesztelés találatai nincsenek mind kijavítva. A commit-görbében ott egy kéthónapos szünet, elsimítás nélkül.
Ügyfélmunka. Ott várni kell néha.

💡 És egy dolog, amit csak most, utólag látok tisztán:
Az örökölt rendszernek nem volt reprodukálható környezete, leírt megértése, se tesztje. Az újraépítettnek mind a három megvan.
Ettől lett olyan rendszer, amit utána AI-jal lehet javítani és továbbfejleszteni. Nem célként — a három felvonás következményeként.

Vagyis a dokumentáció nem egyszeri költség, amit a szállítás megtérít. Az az alapréteg, amitől minden későbbi változtatás olcsó lesz.

Az ügyfél nincs megnevezve, a piaci szegmense sem, és a rendszeréből semmi nem szerepel. A módszer az átvehető rész.

💬 Ha te is ülsz egy ilyen rendszeren — vagy vittél már ilyet és másképp mesélnéd el — érdekel az összevetés.

Egy működő rendszer átvétele, amit már senki nem tud elmagyarázni: megérteni, újraépíteni, és úgy átadni, hogy az átvevő egyedül fel tudja állítani és le tudja ellenőrizni. Minden szám mérve.

07/09/2026

⏱ 173 nap. Ebből 95 aktív munkanap. Egy ember.
Ennyiből épült fel az a platform, amiről most először készítettem esettanulmányt. Természetesen magát az esettanulmányt is ugyanazzal a módszerrel csináltam mint amiről szól.

Ha érdekel, itt olvashatod:
🇬🇧 https://fefehun.github.io/multibrand-erp-case-study/
🇭🇺 https://fefehun.github.io/multibrand-erp-case-study/hu/

Amit eddig posztokban állítottam, azt itt először meg is mértem.
🔹 82 csomag, 2 045 kiadott verzió
🔹 214 051 sor forrás + 137 518 sor teszt
🔹 49 commit egy aktív napra
🔹 8 ágens-szerep két gépen — ebből kettő beszél velem
🔹 1 067 tervezési dokumentum: koncepció → epic → issue

De nem a méret és nem is a tempó az érdekes.
Sok kódot gyorsan előállítani már nem teljesítmény.

Az igazi kérdés az utána következő:
mi akadályozza meg, hogy ez heteken belül karbantarthatatlanná váljon?
📌 A rossz számok is kint vannak.
Egy független audit külső mércékhez mérte a platformot:
ERP 47%, CRM 33%.
Az értékesítési tölcsér felső fele nullán.
Tizennégy ismert hiba rögzítve, szándékosan javítatlanul.

Enélkül a többi szám sem érne semmit.
💡 Az ára is ki van írva: 214 ezer sor kódra 180 ezer sor dokumentáció jut.

Ez nem adminisztráció.
Ez a memória, amitől a következő munkamenet lehetséges.

🧪 Minden nap tanulok valamit, amivel bővül az eszköztáram. Ma ezt:
Ez az első ilyen esettanulmányom egy nagyobb munkáról, és nem úgy készült, hogy „megírtam egy dokumentumot".
Saját repót kapott — státuszfájllal, munkaegység-naplóval, mérőszkripttel, publikálási kapukkal.
A kapuk pedig dolgoztak. Az anonimizáló ellenőrző háromszor is sikert jelentett volna anélkül, hogy ténylegesen lefutott volna. Mindháromszor kiderült és javítva lett.

📎 Amit viszont nem tudsz ellenőrizni:
a repók privátak, a mérést kívülről nem tudod újrafuttatni.
Ez valódi korlát, és a dokumentumban is ki van írva.
Helyette minden számnál ott a hatókör, a forrás és az őt előállító parancs.

A szöveget - ahogyan minden más dokumentumot és kódot is mostanában - a Claude Code írta, a repók beolvasásából.
A mérnöki munka az enyém; az oldal beszámoló róla, nem igény rá.
Termék-, cég- és ügyfélnév nincs benne.

A módszer az átvehető és újrahasznosítható rész.
Minden folyamatosan javul, fejlődik, újra és újra tesztelődik és ellenőrzésre kerül. A munka nem áll meg... haladunk...
💬 Ez kísérlet: most próbálom először így megmutatni, amin dolgozom.

Ha te is így dolgozol, mérlegeled, vagy próbáltad és nem vált be — érdekel az összevetés.

Hogyan épült fel nulláról egy moduláris ERP/CRM platform és a saját keretrendszere egyetlen fejlesztővel, AI-asszisztált munkamódszerrel — és mi tartotta karbantarthatóan ezen a tempón. Minden szám mérve.

26/08/2026

2 éve még kiváló szakemberekből álló fejlesztői csapatot vezettem (Java és mobil stack) architektként, csapatvezetőként, It-Coach - ként.

Most ugyanezt a fegyelmet ültetem át AI-ágensekre.

A sok tanulás és a Claude Code fejlődése ma megoldotta az utolsó hiányzó részletet: az AI csapattal az ember folyamatosan megosztott figyelme nélkül egyszerűen lehet kommunikálni.

Akik követik amiket írok ismerik a módszertant korábbi post-jaimból:
spec-driven és evidence-driven fejlesztés, ahol minden sor kód mögött dokumentált terv és élő bizonyíték áll.
Eddig ezt egy-egy integrációra, kliensre alkalmaztam.

Most szintet léptem: nem egy projektet, hanem egy teljes, önállóan koordináló fejlesztői szervezetet vezetek ugyanezzel a fegyelemmel — csak épp a csapattagok ágensek.

Két "lead" ágenssel egyeztetek közvetlenül, most éppen Discordon, mint csapatvezetőkkel — ők osztják szét és felügyelik a munkát a saját területükön.
A többiek egymás közt koordinálnak, én nem vagyok bottleneck a napi munkában.
🔹Framework-integrator/lead + application-integrator (framework és appok integrálása, üzembe helyezése, integrációs tesztelése)
🔹Framework fejlesztői csapat (frontend + backend)
🔹Application fejlesztői csapat (lead-ek + fejlesztők: frontend + backend)
🔹Application auditor a megfelelőség ellenőrzésre

Mindenki szigorúan a saját felelősségi körén belül dolgozik, minden feladatot a megfelelő subagentekre bontva — nincs "egy nagy agent csinál mindent".

Módszertan, ami ezt megbízhatóvá teszi:
📌 Minden probléma mögött koncepció áll, minden koncepcióhoz epic, minden epic-hez issue(k) + implementációs terv(ek) tartoznak
📌 Háromszintű feladat-auditálás: koncepció ↔ epic, epic ↔ issue/impl-plan, issue/impl-plan ↔ kód
📌 Funkció-auditálás: koncepció ↔ use-case/funkció, use-case/funkció ↔ teszt lefedettség
📌 Tesztelés: unit, e2e (funkció + use case alapú), integrációs (funkció + use case alapú)
📌 Minden bizonyíték alapú: dokumentumok, jelentések, tesztek során képernyőképek
📌 Mindent auditor subagentek ellenőrznek

Infrastruktúra:
Két gépen: minden konténerben, code-server-rel (böngészős VSCode + Claude Code session - ok) távolról felügyelhetően
Háromrétegű minőségbiztosítás: Docker-in-Docker teszt → unit+e2e teszt kiadáskor → integrációs teszt minden integráció után
Automatizált kiadás: GitHub-ra és Docker Hub-ra
Stack: React, Node, PostgreSQL

Ez nem az "AI ír helyettem kódot" — ez szervezeti struktúra, ahol a csapattagok ágensek és a management felület elektronikus, ahol a fegyelem ugyanaz, amit korábban is megköveteltem a fejlesztéseknél.

Ez lesz a következő évek egyik szemléletváltása:
nem az számít, ki ír jobb promptot, hanem ki tud jobb szervezetet — emberekből vagy ágensekből — felépíteni, és megfelelő módszertanok mentén dokumentáltan, auditálhatóan feladatokat elvégeztetni velük.

Ha hasonló architektúra érdekel, vagy a saját csapatod/projekted is így futna, keress üzenetben!

06/08/2026

Ma reggel még nem létezett...

Délutánra: publikált, élesben bizonyított API-kliens. Most éppen a NAV Online Számla 3.0-hoz. (Igen, tudom, hogy ilyen már másnak is van — de ha egyszer ez kellett.)

Mi is készült el egy nap alatt, AI-asszisztált fejlesztéssel:
– teljes tervezés: koncepció → 15 epik → 106 dokumentált issue,
– mind a 11 NAV-művelet, aláírás-kriptográfiával (SHA3-512, AES) és XML-kezeléssel,
– 97 unit teszt + élő integrációs tesztek a NAV tesztkörnyezete ellen,
– minden számlatípus (normál, egyszerűsített, gyűjtő, módosító, sztornó, deviza, fordított adózás…) élesben, végállapotig validálva,
– CI/CD, biztonsági és audit-kapuk, publikált npm-csomag.

Persze nem ez volt az első. Az elmúlt hónapokban már három másik zárt számlázási API-hoz készült így kliens: Billingo, Számlázz.hu, Szamlify.hu. Együtt közel kétszáz élő integrációs teszt, valódi tesztkörnyezetek ellen. Ami hónapokig tartó integrációs projekt volt, annak elkészítése manapság csak napok kérdése.

A lényeg nem is a sebesség. Az AI persze gyorsan termel kódot már egy ideje, de megbízható, alaposan tesztelt és dokumentált kódot csak fegyelmezett folyamat ad. Ez a sebesség attól ér igazán sokat, hogy egy zárt módszertan kényszeríti ki a minőséget:
📌 A specifikáció rögzítve (SHA-256-pinelt források) — az AI sosem „emlékezetből" dolgozik.
📌 Terv a kód előtt — egyetlen sor sem létezik dokumentált issue nélkül.
📌 „Kész" csak élő bizonyítékkal — ami csak feltételezés, az őszintén annak jelölve. Amikor egy állításról kiderült, hogy túlzó volt, visszavontuk és dokumentáltuk.
📌 Minden meglepetés (dokumentálatlan hibakód, spec-drift) saját, bizonyítékkal ellátott finding — nem TODO-komment.
📌 Titkok soha logba, mutáló hívás soha auto-retry, auditkapuk a CI-ban.

Ez a kombináció — AI-sebesség + bizonyíték-vezérelt folyamat — API-független. Bármilyen zárt rendszerhez (bank, logisztika, kormányzati, legacy ERP) ugyanígy készíthető magas minőségű illesztés.
Nem hónapok alatt… hanem napok alatt.

Ha hasonló integráció előtt állsz és érdekel, hogyan működik ez a gyakorlatban, keress nyugodtan üzenetben.