A működő demó és a működő rendszer a képernyőn ugyanúgy néz ki. A különbség mindaz, ami alatta van, és ezt hívjuk rendszerszemléletnek. Egy AI-val egy este alatt összerakott készletnyilvántartó bevételez, kiad, a lista frissül, minden szép. Aztán ketten használják egyszerre, a számlázó nem válaszol, valaki törli a rossz sort, és kiderül, hogy a demó nem tud olyasmit, amit soha senki nem kért tőle, mert nem is tudta, hogy kérni kell. Ebben a cikkben ezt a hét réteget mutatjuk meg hétköznapi példákkal, és adunk egy tízkérdéses listát, amivel te magad eldöntheted: demó vagy rendszer, ami nálatok fut.
🧭 Mit jelent a rendszerszemlélet a szoftverfejlesztésben?
A rendszerszemlélet azt jelenti, hogy egy szoftvert nem önálló képernyőként, hanem egy egész részeként tervezünk: emberekkel, akik egyszerre használják, más rendszerekkel, amelyekhez kapcsolódik, és idővel, amely alatt az adat gyűlik, a szabályok változnak, a hibák előjönnek. A rendszerszemléletű fejlesztő nem azt kérdezi, hogy „működik-e a gomb”, hanem azt, hogy mi történik, ha…: ha ketten nyomják, ha a másik rendszer nem válaszol, ha rossz adatot írnak be, ha két év múlva vissza kell keresni valamit.
Ez nem elmélet és nem programozói sznobizmus. Egy jó könyvelő is így gondolkodik: nem az a kérdés, hogy a számla kinyomtatható-e, hanem hogy a NAV-nál, a vevőnél és a főkönyvben is ugyanaz szerepel-e. A szoftvernél ugyanez a gondolkodás az, ami a vibe codinggal készült demót és a napi munkára bízható rendszert elválasztja.
🧊 Mi az a 7 réteg, ami a képernyőn nem látszik?
A demó a jéghegy csúcsa. Alatta hét réteg van, és mindegyikhez van egy történet, amit valamelyik ügyfelünknél már láttunk, még mielőtt hozzánk fordult volna.
- Egyidejű használat és tranzakció. Két raktáros egyszerre veszi ki az utolsó csapágyat. Mindkét képernyő 1 darabot mutatott, mindkettő levonta, a készlet −1. Senki nem kap hibaüzenetet, a leltárnál derül ki, három hét múlva. Vagy: a kolléga kétszer kattint a „Számla kiállítása” gombra, és két számla születik ugyanarról a rendelésről. Tranzakció és zárolás nélkül ez nem lehetőség, hanem idő kérdése.
- Jogosultság a szerveren. Az AI szívesen „elrejti a gombot” a nem jogosult felhasználó elől. A szerver viszont továbbra is végrehajtja a kérést, ha valaki a böngésző fejlesztői eszközével elküldi. Egy raktáros így írhat át eladási árat anélkül, hogy a felületen valaha látta volna a mezőt. A valódi jogosultság a szerveren dől el, nem a képernyőn.
- Naplózás és visszakövethetőség. Eltűnt egy rendelés. Ki törölte, mikor, miért? Ha nincs napló, nincs válasz, és nincs kit megkérdezni. Egy nyilvántartásnál a „ki, mikor, mit” nem extra funkció, hanem maga a nyilvántartás lényege.
- Integráció. A demó elküldi a számlát a számlázónak, és ez a bemutatón működik. Élesben a számlázó néha nem válaszol, néha hibát ad, néha lassú. Ilyenkor a rendelés elveszik, vagy duplán megy, és a hiba nem a képernyőn, hanem a könyvelésben jön elő hónapokkal később. Ugyanez igaz az ERP-re, a webshopra, a futárszolgálatra.
- Mentés és visszaállítás. A legtöbb demónál készül valamilyen mentés. Amit szinte soha nem csinálnak meg: egyszer visszatölteni, és megnézni, jó-e az adat. A kettő nem ugyanaz. A mentés akkor ér valamit, ha egy próbán már visszaállt belőle a rendszer.
- Környezetek és verziózás. A vibe-kódolt appot ott javítják, ahol fut: az éles adaton. Egy „javítsd ki ezt” prompt közben más funkciót is átír, tesztek nélkül nem látszik, és ha reggel „valami elromlott”, nincs tegnapi verzió, amire vissza lehetne állni. A tesztkörnyezet és a verziókezelés nem a nagy cégek luxusa, hanem a legolcsóbb biztosítás.
- Hibakezelés és határesetek. Negatív készlet, üres mező, ékezetes vevőnév, hálózati hiba félúton, december 31-i dátum. A határesetek ritkán adnak hibaüzenetet; csendben rossz adatot írnak az adatbázisba, és onnantól minden kimutatás arra épül.
Egyik sem látszik a demón. Mindegyik akkor jön elő, amikor a szoftver már a napi munka része, és többen függenek tőle. Ezért mondjuk, hogy a működő demó még nem rendszer: nem azért, mert rosszul lett megírva, hanem mert ezek a rétegek nem kerültek bele, mert senki nem kérte őket.
🤝 Rendszerszemlélet és AI: nem ellentét, hanem sorrend
Félreértés ne essék: nem az AI-val van a baj. Mi is minden nap AI-val írunk kódot, és gyorsabbak vagyunk tőle, mint valaha. A különbség a sorrend: nálunk előbb születik meg a rendszerterv (ki használja, mivel kapcsolódik, mi történik egyidejű használatnál, mit naplózunk), és az AI ezt a tervet valósítja meg, a mi mintáink és szabályaink szerint. Így a fenti hét réteg nem utólagos javítás, hanem a kiindulópont. Hogy ez a gyakorlatban hogyan néz ki, azt az AI programozásról szóló cikkünkben lépésről lépésre leírjuk.
Egy friss példa: a Business Central MRP-riportunknál az AI első lekérdezési javaslata a demóadaton tökéletesen működött. A rendszerszemlélet ott jött be, hogy tudtuk: élesben 33 000 rendelési soron és egy többmilliós táblán fog futni, ezért valós adatmásolaton mértük, és a végleges változat pár másodperc alatt fut le. A prompt ugyanaz lett volna; a kérdés, amit feltettünk mellé, volt más.
🔍 Hogyan ismered fel, hogy a demód még nem rendszer?
Nem kell hozzá programozónak lenned. Tíz kérdés, amire ha a válasz „nem tudom” vagy „még nem próbáltuk”, az adott réteg hiányzik:
- Hányan használják egyszerre, és kipróbáltátok már, mi történik két egyidejű mentésnél vagy dupla kattintásnál?
- A tiltott műveletet a szerver is elutasítja, vagy csak a képernyőn nincs rá gomb?
- Visszakereshető, ki, mikor, mit módosított vagy törölt?
- Ha a számlázó, az ERP vagy a webshop nem válaszol, az adat elveszik, duplán megy, vagy várakozik és újrapróbál?
- Mikor állítottatok vissza utoljára mentésből, és jó volt az adat?
- Van tesztkörnyezet, vagy az éles adaton javítotok?
- Vissza tudtok állni a tegnapi verzióra, ha ma elromlik valami?
- Mit csinál negatív készletnél, üres mezőnél, ékezetes névnél, megszakadt kapcsolatnál?
- Ki kap értesítést, ha éjjel leáll, vagy reggel a kolléga veszi észre?
- Ki felel érte, és ki érti a kódot azon kívül, aki összerakta?
Tapasztalatunk szerint a mérce egyszerű: ha a tízből legfeljebb kettőre bizonytalan a válasz, az már rendszer. Három–öt bizonytalan válasznál átvizsgálás kell, hat fölött pedig általában olcsóbb a terv alapján újraépíteni, mint a demót foltozni.
🛠️ Mit tegyél, ha a demód már a napi munka része lett?
Nem kell kidobni, és nem kell szégyellni sem: a vibe-kódolt prototípus sokszor a legjobb specifikáció, amit kaphatunk, mert pontosan mutatja, mit szeretnétek. Amit tenni kell: élesítés előtt, vagy ha már éles, minél előbb átnézetni valakivel, aki ezt a hét réteget keresi benne. Nálunk ez egy célzott, néhány napos átvizsgálás AI-val készült szoftverekhez: a végén írásos lista marad arról, mi hiányzik, mi javítható, és mit érdemes átvenni változatlanul. Van, amikor a válasz az, hogy a demó pont elég, mert alacsony a tét, és ezt meg is mondjuk.
Ha szeretnéd, hogy ránézzünk, az oldal alján lévő űrlapon elég annyit írnod, mit csinál az app, hányan használják, és mihez kapcsolódik. A többit megkérdezzük.
❓ Gyakori kérdések a rendszerszemléletről
Mi a rendszerszemlélet egyszerűen megfogalmazva?
Az a gondolkodásmód, amely egy szoftvert a környezetével együtt néz: a felhasználókkal, akik egyszerre használják, a rendszerekkel, amelyekhez kapcsolódik, és az idővel, amely alatt hibák, változások és adatmennyiség gyűlik. A kérdése mindig az, hogy „mi történik, ha…”, nem az, hogy „működik-e”.
Miért nem adja hozzá az AI magától ezeket a rétegeket?
Mert azt készíti el, amit kérnek tőle, és a legtöbb prompt a látható eredményről szól. A tranzakciókezelés, a szerveroldali jogosultság vagy a naplózás akkor kerül bele, ha valaki tudja, hogy kérni kell, és ellenőrzi, hogy tényleg benne van-e.
Minden belső eszköznél kell ez a hét réteg?
Nem. Egy egyszemélyes kalkulátornál vagy egy eldobható demónál felesleges. A rétegek akkor válnak kötelezővé, amikor többen használják, más folyamat függ tőle, vagy ügyfél-, bér- és pénzügyi adat van benne.
Mennyi ideig tart kideríteni, hogy a demónk rendszer-e?
A fenti tíz kérdést fél óra alatt végig tudod gondolni magad. Egy szakmai átvizsgálás, amely a kódot és az adatbázist is megnézi, jellemzően néhány napos, egyszeri díjas munka, és írásos eredménnyel zárul.
A rendszerszemlélet nem azt jelenti, hogy mindent túl kell tervezni. Azt jelenti, hogy tudod, mi múlik a szoftveren, ha hibázik, és ahhoz méred, mennyit építesz alá. Ebben szívesen segítünk eldönteni, hol a határ.
