Modernizáció leállás nélkül

A kérdésedre a válasz egyébként, ezt mindenre így kiterjeszthetjük, hogy az AI-t szerintem lehet jól meg rosszul használni, és az emberek 90%-a, ezeket rosszul használja.

Ez itt a Digit Podcast Deltával közös felvételének második évada, Pintér Szabolcs ügyvezető az UpScale-től és Neuwald Tivadar fejlesztési és értékesítési stratégiai igazgató, a Delta Technologies Zrt.-től. Amiről ma kéne, hogy beszéljünk, ez kapcsolódik egyébként az elmúlt három konferencia összes témájához, legaszi rendszerek modernizációja. És azt gondolom, hogy ebben elképesztően érdekes gondolatok vannak, de gyakorlatilag azért abba senki nem gondol bele, hogy ezeket a modernizációkat olyan éles rendszereken kellene végrehajtanunk, amik nem állhatnak le. Azt szeretném megkérdezni Szabolcs, hogy hogy látod te ezt, hogy jön a legaszi rendszerek cseréje, módosítása, üzemben tartása a jelenlegi világ AI fejlesztéseihez.

Köszönöm szépen még egyszer a kérdés meglehetősét, hogy itt lehetünk. A kérdésben már berejtettél azért sok mindent a válaszból, amit ehhez hozzá tudok tenni, ami kritikus probléma, az természetesen az üzletfolytonosság. Ami most aktualitást ad a témának, az pedig a mesterséges intelligencia valóban, mert ez azért már számos cégnél napirenden volt, ahogy haladtunk elő az évtizedekkel, hogy különböző dolgok adtak aktualitást, ennek maga az internet előretörése, a mobilbanknak, a mobil friss technológiának az előtörése mind igényelte azt, azok a fajta technológiai megoldások, a valós idő adatszolgáltatás igénye az mind diktálta azt, hogy a regasszív rendszereket modernizáljuk, de most valóban a mesterséges intelligenciának egy újabb lökést fog adni, mert még magunk is, akikkel így találkozunk ügyfelekkel, lehetséges ügyfelekkel, ott visszatérő probléma, hogy az AI hype közepette mindenki nagyokat álmodik, és aztán a valósággal nyilván szembesülünk, hogy ennek adott esetben képességei, korlátai vannak egy cégen belül, hogy kihasználják azt a lehetőséget, amit a mesterséges intelligencia egyébként valóban nyújtani tudna, hogyha ehhez adott lenne az a fajta háttér, amit egy ilyen rendszerarchitektúrának,

amivel integrálódni szükséges, biztosítania kell. Így ha még egy két szót így hozzátehetek, akkor egyébként az Abski maga onnét született, ezt nem tudom mennyire ismeritek, hogy 2016-7 folyamán az egyik nagy magyar banknál gyakorlatilag ott visszatérő probléma volt, hogy gyakorlatozott az Internet és Mobilbank, és ott az Abskill gyakorlatilag akkori alapítója, kedves barátom, Csendes Miklós volt az, aki egy remek architektora gondolattal előállt, és megchallenge-elte azt a fajta Legacy monolit rendszert egy mikroszőr vizes tejosztott konténerizált megoldással, ami aztán biztosította azt a skálázhatóságot és architektúrát, ami lehetővé tette, hogy onnantól kezdve már ne jelenjen meg minden nap a vezető hírportálokon, hogy leállt az internetbank, és ez egy üzletfolytonossági probléma is volt akkor ebben a kontextusban, de ahogy te a kérdésben feltetted, úgy is valóban az, hogy egy ilyen Legacy rendszert lecseréljünk, az egy óriási kockázat egy cégnek, hogy az üzlet folytonosságát megőrizze.

Én szerintem átadom a szót Tivadarnak.

Nagyon szépen köszönöm az átadást.

Én visszanyúlnék egy picit régebbre egyébként, ahol teljesen belém vésődött egy mondat, amit a Citixnek az akkori igazgatója mondott nekem, ez a Folkesmeiser úr, hogy nem a technológia húzza az üzletet, hanem az üzlet húzza a technológiát. És amikor arról beszélgetünk, hogy van egy régi Lagasir rendszer, egy Corbusiness, egy Line of Business rendszer, és az mondjuk monolitikus. Nem az a kérdés, és soha nem is lehet az a kérdés, hogy a monolitikus rendszert le kell cserélni azért, mert, hanem az a kérdés, hogy az üzlet mit diktál. Nem feltétlen módon kell lecserélni egy monolitikus legaszi rendszert, csak azért, mert valaki kitalálja, le kell cserélni, hanem meg kell vizsgálni az üzleti oldalát ennek, hogy valóban igaz ez az állítás, hogy az, hogyha ezt lecseréljük, és mondjuk egy microservieses rendszerre hadd idézzelek, hogy hogyan alakult meg az Abscale, akkor annak valódi értékteremtése lesz-e, mennyi idő alatt, milyen fajta auditálhatósággal, milyen fajta biztonságossággal, milyen kompliance-ekkel, és nyilván mennyi költségbe.

Bocsássatok meg, de itt két kérdés is felmerült az egyik kérdés, ugye gyakorlati tapasztalat. Értem és elfogadom, amit mondasz, de hol van az a pont, amikor lassítja magát az innovációt, hogyha nem cseréled le? Tehát ez egy fontos skálázás. Értem, hogy az üzlet vezényli, de mondhatja azt az üzlet, hogy nekünk mondjuk egy Lotus Notes még mindig jó, de már nincs Lotus Notes üzemeltető. Ugye?

Igen, szerintem mind a kettőtökben megvan az az igazság, és hadd értsek először egyet Tivadarral, akko.

Én csak kérdezek.

Nem is kell egyetérteni.

De még emellett is maximálisan igazad van, mert hogy amellett, hogy maximálisan egyetértek Tivadarral egyébként, és most egy kicsit ki is vetítem akár a mesterséges intelligenciára is, hogy ott is a probléma legtöbbször, amit mi is látunk, hogy sokan ezt az eszközt tekintik öncélú megoldásnak, hogy akkor legyen mesterséges intelligencia. És szeretjük visszavinni oda az utazásban az ügyfeleket, hogy nézzük meg, hogy milyen problémát akarunk megoldani, és mi az üzleti fájó pont, amit kezelni szeretnénk, és talán itt találkozik azzal a gondolattal, amit a kérdésedben feltettél, hogy ez sokszor nem olyan direkt módon elkülöníthető, hogy ez üzleti vagy technológiai probléma, mert ugye egy rendszerleállás, amit én most példaként hivatkoztam, az valóban felfoghatjuk egy technológiai problémának is, de nyilvánvaló, hogy ez ügyfélvesztést idézett ő annál a pénzintézetnél is, meg komoly szolgáltatási fennakadásokat, amiből effektív jövedelmezőség csökkenése származott, vagy annak a kockázata nőtt meg óriásira.

Úgyhogy valahol a kettő így tud találkozni, és felfoghatjuk ezt egy technológiai problémának is, hogy a technológia egy idő után korlátja lehet ennek. Gondoljunk akár egy ilyen skálázódási problémára, hogy nem tudja elérni azt a szintet, ez is egy felfoghatjuk technológiai problémának is, hogy a kedvenc példám, amit be szoktam hivatkozni, ugye még mai napig találkozunk még cégekkel, akik mondjuk egy Black Friday-on nem tudnak felskálázódni mondjuk egy kereskedelemben, és azt látjuk, hogy leáll az adott szolgáltatás, egy webshop mondjuk, mert nem tudja kiszolgálni már az igényeket, vagy nézzünk egy NAV-nál is még jó pár évig tapasztaltuk az SZJA beadási határidőnél, hogy ott betorlódtak mondjuk azok a fajta igények, ezek mind felfogható technológiai problémának is, hogy a technológia nem képes kiszolgálni ezt az egyszerű üzleti igényt, de valóban ez egy összetett történet, és alapvetően visszavezethető üzleti gyökérokokra, hogy ez valahol egy Aid & of the Day-jel szoktam mondani, bocsánat, angolosan, ugye a nap végén ez csak abból származik, hogy az ügyfél ebből hátrányt tapasztal, vagy annak a kockázatát.

Tehát az a fajta, mondjuk azt, hogy technológiai adósság, ami akkor keletkezik, amikor a szervezet maga azért és úgy reagál egy változásra vagy változtatásra, egyébként üzleti érdek miatt, hogy azt mondja, hogy az a rendszer, ami jelenleg fut és jelenleg kiszolgálja az üzleti igényeket, abban a változtatási igény túl sok vagy túlságosan kockázatos, vagy túl nagy költség, akkor nyilván érdemes elgondolkodni egyébként azon, hogy legyen egy olyan új modern rendszer, ami az üzleti igényeket gyakorlatilag skálázható módon képes kiszolgálni. Ez az egyik része. A másik része az pedig a felgyorsult világunk. Tehát gyakorlatilag mondjuk ki nyugodtan, nincsen már idő arra, pláne az AI korszakban. És akkor erről majd később beszélgessünk is, hogy egész egyszerűen túl sok időt azzal eltöltsünk vagy elpazaroljunk, hogy mi egy régi rendszert toldozgatunk, foldozgatunk, miközben egyébként az üzlet elmegy mellettünk.

Amikor a saját kollégáink, akik a szervezeten belül dolgoznak, azzal a visszajelzéssel jönnek vissza, hogy a rendszer nem képes kiszolgálni, onnantól fogva a rendszer mondja meg azt, hogy milyen legyen az üzlet, és nem az üzlet mondja meg, hogy milyen legyen a rendszer, óriási különbség.

Ugye mindennel mindig általában egy más aspektusból próbáljuk meg ezt a kérdést vizsgálni és föltenni. Ugye gyakorlati tapasztalat, tehát hogy azért megéltem már egy pár Legacy rendszernek az idézőjelben elavulását, ami az elavulás azt jelentette, hogy konkrétan a programozó mondjuk kiment az utcára, elütötte a villamos. Ez megtörtént eset, viszont nem volt utód. Nem tudták átvenni az üzemeltetést. Viszont egy gyárban egy üzletkritikus szolgáltatás, azért gondoljunk bele, hogy egy gyártási rendszerben azért nem mondjuk azt, hogy tudjátok ti is, hogy az XP-s gépek viszonylag még gyakoriak. Nincs rátéve, de már hogy az internetre meg nem frissül, meg nem csinál semmit, de technikailag, ha és amennyiben megdöglik alatta a vas, akkor is kell valamit tudni csinálni.

Tehát ez az egyik fele, a másik fele a kérdésnek pedig az, hogy ha kiberszekurity szempontból egy valamilyen auditon pont emiatt nem megy át a cég, akkor meg megint hiába van az üzleti igény, hogy maradjon, valamilyen irányba el kell mozdulni. És akkor értitek, hogy mit szeretnék egy kicsit feszegetni ezzel, ebben mi a tapasztalat?

Ha nem haragszok, hogy most forrásmegjelenéssel be is idézem egy régi volt kollégámat, nagy tisztelők, Benda Ferenccel tegnap találkoztam, pont így az irodánkba meglátogatott, és Citibankban dolgoztunk együtt vele, és ő most ilyen kiberbiztonsági dolgokkal foglalkozik. Ő mondta nekem tegnap ezt az információt, hogy az egyik nagy operációs rendszer szolgáltató ezer darab ilyen biztonsági frissítést tudott ki legutóbbi ilyen verziójában, és ez egy elképesztő szám tényleg, tehát én nekem is csak csodálkoztam rajta, hogy ilyen mértékű, hát nem is tudom, hogy nevezzem, de amit egyébként Tivadar is utalt rá, hogy ilyen gyorsan változik a világ, talán azzal is összefüggésben, meg valószínű azzal is összefüggésben, hogy ezeket a kódokat tényleg rettentő gyorsan gyártják és próbálnak lépést tartani az innovációval, ezek óhatatlanul együtt járnak ezzel.

De visszakanyarodva egyébként a kérdésedre, sőt még az előzőre is ráköt, hogy az üzletfolytonosság, hogy a legaszi rendszerek korlátai azok egyébként nagyon sok mindenben kiütköznek már így az üzletfolytonossági problémák mellett így gondoljunk arra, hogy egy hiba megtalálása, hogyha valamilyen hiba történik egy rendszerben, annak a beazonosítása egyáltalán, hogy hol volt. A felskálázódás az egy tipikus ilyen probléma, a költséghatékonyság, az üzemeltetés, hogy mekkora költségből tudok fenntartani egy ilyen Legacy rendszert, amiről szintén beszéltetek, de ahogy utaltál erre, ez is egy valós és élethelyzet, hogy nekünk is van egy ügyfelünk, akit az vitt rá a modernizációra, hogy megszűnik a támogatás mondjuk az egyik kor adatbázisa mögött, amit eddig használt nagyvállalati környezetben, de hasonlóan volt ilyen is, ami szintén utalt erre, hogy már nem találnak olyan programnyelven fejlesztőt, aki karbantartani tudja azt az adott rendszert.

Tehát hogy végtelen sok ilyen probléma van azon túlmenőleg, hogy az üzleti dolgokat elkezdenénk így boncolgatni, ami önmagában szükségessé teszi a modernizációt magát azt, hogy elkerülhetetlenné teszi, gyakorlatilag nincs alternatívája, hogy az ember hozzányúljon egy ilyen rendszerhez.

És akkor hadd üljek rá ezekre a gondolatokra Szabolcs, mert azt szeretném visszagazolni, hogy a kérdés maga is alapvetően helytálló, ezek a gondolatok is helytállók, olyannyira, hogy ezt a piacról is abszolút visszaigazolva látom, sok személyes tárgyalásom van azzal kapcsolatban a szó szoros értelmében, mikor kihal egy cég egy-egy nagyon komoly Legacy rendszer, ami esetleg lehet egy SAP előtétrendszer, egy logisztikai modul, nagyon sok minden olyan dolog, aminél gyakorlatilag vagy a fejlesztői gárda egyszemélyes, ami óriási kitettség egyébként, tehát nincs hozzá megfelelő támogatás, ráadásul azok a dokumentációk, amik az üzemeltetéssel, karbantartással kapcsolatosak, azok sem léteznek, sőt mi több, akár nem is hajlandók megírni.

A másik oldalon pedig ugyancsak rácsatlakozva erre a válaszra, több helyen találkoztunk azzal, hogy vannak olyan programnyelvek, amelyek egész egyszerűen már nem élnek, és a programozói gárda is gyakorlatilag szó szerint eltűnt a nyelvről, például ilyen a delfi, amivel nagyon konkrétan találkoztunk egyébként, ahol nem lehet már kérdés az, hogy a Legacy rendszert valamilyen más rendszerrel kelljen vagy lehessen helyettesíteni.

Nagyon fontos kérdés, és rá kell térnünk arra, hogy hol üzemeltetjük ezeket a legaszi rendszereket. Mert itt a szintén tapasztalati útból, vagy tapasztalatból mondom, hogy hát a bontókban is elkezdett elfogyni a Pentium 133-as. De a legnagyobb probléma, hogy most már inkább a RAM fogy el, meg a táp, ami hiányzik belőle, és ezért nagyon érdekes kérdést vet föl, hogy felhő, de hogyan felhő akkor, amikor egy gyártási környezetben nem kéne kiengednem internetre, hiszen min fut, vagy pedig hogy teszek alá egy olyan vasat, ami hát hogyan installálsz újra valamit, aminek nincs meg a telepítő lemeze, ez sem a dokumentációja. Ilyenkor mit kell csinálni?

Szerencsére ennek van azért módszertana, hogy hogyan történjen meg egy ilyen modernizáció egyébként, mert nem is csak a hol futás a kérdés itt, hogyha egy kicsit kiegészíthetem a kérdéseket.

Kérlek, persze, csak hát ugye megpróbáltam a kérdést egyszerűen föltenni.

Nagyon jó kérdés egyébként önmagában is. Annyival egészíteném ki, hogy önmagában probléma egyébként egy ilyen legacy rendszernél az, hogy általában ezek ilyen nagy rendszerek, tehát egy nagyon komplex integrált rendszerek, ezer szálon kötődnek össze mindenféle szatellit rendszerekkel, és ennek az üzletfolytonos modernizálás önmagában egy probléma. Egyébként ennek nagyon szép szakirodalma van, ezt mi is körüljártuk, merthogy ez volt az Abskinek a korkompetenciája, amit kiépített 2017 körül, 2017 körül, hogy most nem akarok csúnya szavakat használni, mert megbeszéltük, hogy ez nem feltétlen technikai embereknek szánjátok ezt a podcastot, de ugye ez a Stranglerpaternes módszertan, vagy az MVSP-s módszertan.

Itt most elvesztettük őket.

Igen, visszahozom őket gyorsan, mert egyébként nem olyan bonyolult, sőt Tivadar nem olyan régen járt Brazíliába, és el is küldte nekem azt a fát, amiről meséltem neki, hogy egy nagyon jó metaforánk is van erre, hogy ott van egy ilyen természeti jelenség, hogy egy fát körbenő egy ilyen élősködő növény, és gyakorlatilag felemészti kívülről, a végén pedig már nincs is fa, csak ez a külső képződmény, ami ott marad, erről van egy fényképe is, hogy lehet, hogy majd bemutatjuk.

Küldd el és bevágjuk.

Igen, ez nagyon érdekes, és ezzel szoktuk így szimbolizálni. Egyébként az egyik módszertan gyakorlatilag, ez, amit ezzel a csúnya szóval interpretáltam, hogy a Legacy rendszer köré is el tudunk kezdeni felépíteni egy ilyen új rendszert, mondjuk egy ilyen modern architektúrát, és ez gyakorlatilag ilyen darabonként felemésztjük a régi architektúra részeit, és egyszer csak azt látjuk, hogy ott egy új rendszer működik már. A másik módszerta, meg amikor gyakorlatilag párhuzamosan elkezdjük funkcionként ilyen MVP szemléletben kiépíteni ezeket a kis architektúra boxokat, mikroszervizeket, most nem akarok megint csúnyákat mondani, ilyen kis szolgáltatási egységeket, és abból szépen felépítjük ezt a rendszert.

Hogyha ezzel kiegészíthetem a kérdésedet, és akkor most visszatérek a válaszodra, és szerintem itt át fogom majd adni azért Tivadarnak is a szót, hogy hol fusson ez az architektúra, sőt egy kis csillagot megengedsz, akkor teszek ide, hogy miért is ülünk itt együtt, mert talán ezt kihagytuk a bemutatkozásból, hogy a Delta csoport a nyár folyamán 51 százalék tulajdonrészt szerzett az Abské a csoportban, és ezt most azért csillagoztam be ide, mert az egész akvizíciónak a racionalitását adta, hogy a Delta 1100 aktív ügyfélkapcsolattal rendelkezik, akikre most utalt a Tivadar, hogy hány olyan ügyfelük van, akik legaszi rendszereken futnak, még óriási ügyfélbázist jelent ez számunkra, akik pedig egy modern szolgáltatást tudunk nyújtani, tehát hogy itt volt egy óhatatlan szinergiánk.

A másik pedig pont az, amit említettél, és itt kanyarodok vissza, hogy a Delta azért Magyarország vezető rendszerintegrátoraként a hardverszolgáltató piacon egy kiemelt szereplő, és nekünk meg az a fajta erős Devops kompetencia, amivel rendelkezünk, az adja magát, hogy ezt az infrastruktúrára mondjuk olyan modern architektúrákat kezdjünk el tervezni, építeni és azt a köztes layert kiépíteni, hogy hol is fusson ez a rendszer, és pont amit említettél, hogy ezek gyakorlatilag csomagoltan költöztethetőek legyenek ezek a rendszerek, próbálok távol maradni a technikai törmöktől, ez óhatatlan pontatlansággal jár, kis diszkrimer, de hogy lehetővé tegye azt, hogy ezek monitorolva legyenek ezek a szolgáltatások, logóval legyenek ezek a szolgáltatások és üzletfolytonosan tudjanak futni.

Ebben sincs olyan fekete-fehér válasz, és szerintem itt fogom majd átadni a szót a Tivadarnak. Mi magunk szakosodtunk felhőszolgáltatásokra és dolgozunk gyakorlatilag a nagyobb felhőszolgáltatókkal, Microsofttal, Édabuyasszal, az Amazonnal és a Google-lel is, illetve egyéb kisebb ilyen szatellit szolgáltatókkal is, akik nyújtanak számos előnyt menedzselt szolgáltatásokkal, szerválástechnológiákat, tehát lehet operálni a modernizáción túl ilyenekkel is. Sok esetben indokolja a földön maradást egyébként az ügyfél vagy a piaci környezet vagy az ágazat, amiben dolgozik. Ilyenkor mi azt szoktuk javasolni, hogy a kérdésedre is válaszoljak, hogy először csak ilyen liftensifttel dolgozunk, hogyha viszünk is valamit, tehát először csak fogjuk és felvisszük a felhőbe úgy, ahogy van, és utána kezdjük el azokat az addicionális előnyöket, amiket a felhőszolgáltatás nyújtani tud hozzáépíteni.

De még egyszer sokszor egy felskálázódásban is segítséget tud adni mondjuk egy ilyen felhőtechnológia, tehát adott esetben üzemelteti a saját infrastruktúráján a cég a megoldását, az alkalmazásait, mondjuk maradjunk a webshopos példánál is, és Black Friday akkor egyszerűen felskálázódunk hozzá erőforrást a felhőbe, és akkor ki tudjuk szolgálni azokat az igényeket, de nem terheli őt egész évben az a fajta költség, amit egy nagyobb erőforrás infrastruktúra igényelne.

Tivadar?

Nagyon szépen köszönöm, meg én azt gondolom, hogy kevésbé, de hála Isten kevésbé technológiai, inkább tényleg üzleti gondolatok voltak, és maradjunk is meg ezen a síkon. Az előző évben, amikor volt a podcast, akkor nagyon sokat beszélgettünk a mesterséges intelligencia kapcsán az adatokról.

Ez így van.

És ha arról beszélgetünk, hogy milyen megoldás kell, milyen technológiai stacket választhat az ügyfél. Attól függően, hogy mondjuk léteznek publikus felhőmegoldások, léteznek hibrid felhőmegoldások, meg léteznek on-premise, tehát helyszíni szerverek, meg tárolók, akkor induljon már ki az adatból, és akkor itt szeretnék visszakapcsolódni Szabolcs gondolataira, mert igenis, hogy voltak olyan nagyon, én azt gondolom, hogy nagyon komoly szakmai, professzionális beszélgetéseink ügyfelekkel, akik az államigazgatásban dolgoznak, akik helyettünk széleskedve mondták azt el, hogy drága uraim, mi azonnal felsoroljuk a felhőtechnológia előnyeit. Látjuk a felskálázhatóságot, látjuk a kiugró amplitúdó kezelését, látjuk a költségeket.

Viszont nekünk nincsen arra lehetőségünk, hogy az adatainkat egy publikus felhőben tároljuk. Még úgy sem, hogy azokat nagy biztonságosságú AWS Badrok, meg hasonló jellegű környezetekben helyezik el. Tehát ők maguk elmondták ezt. Ez azt is jelenti, hogy sok esetben maga az adat, vagy az adat kezelője, birtokosa határozza meg a technológiai megoldás lehetőségét. Kizárólag on premis megoldások, tehát kizárólag helyszíni megoldások. Viszont én azt is gondolom erről, hogy az adattartalom, meg a lehetőségek, azok igenis változatos forgatókönyveket tudnak az életben létrehozni, hogy hol érdemes, hogy hol lehet ilyen jellegű megoldásokat alkalmazni. És mivel azt is látom, és akkor megint szeretnének idézni, hogyha van egy olyan jellegű webshop, aminek az adatai nem egészségügyi adatok, nem állampolgári adatok, hanem gyakorlatilag olyan fajta, mondjuk ilyen webshop, egyéb cikkszám, termékneves, stb. Ezeket nagyon jól fel lehet ültetni felhőbe.

Nyilván a megfelelő szabályozottsággal. Lássuk be, hogy egy felhőben futó kiberbiztonsági lehetőségek, azok jóval nagyobbak egyébként, és jóval biztonságosabbak, mint egy on premis. Ha csak azt veszed figyelembe, hogy az on premis megoldásoknál van egy-két rendszergazda vagy három, addig egy ilyen jellegű fürtözött megoldást több tízezer vagy százezer szerverről beszélgetünk, óriási adatbiztonsággal meg redundanciával működik.

Ugye itt van azért most kiberszekuriti szempontból közelítsük meg, hogy ezeknél a rendszereknél a felhőben a kkv-k nagyon máshogy gondolkoznak, tehát ők azt gondolják, hogy bekapcsolás nélkül is működik a visszaállíthatóság és a mentés, de nem. Tehát azt be kell kapcsolni.

Így van.

Nyilván nagyvállalatnál ugye kisvállalat, kis gond, nagyvállalat, nagy gond, teljesen máshogy skálázódnak, viszont abban azt gondolom, hogy nagyon fontos kiegészítést szeretnék kérdezni, merthogy itt az AI-ról még nem beszéltünk, kerülgetjük, de hogy az ilyen típusú átállásoknak azért a legnagyobb rákfenéje, hogy a cég a saját folyamatait nem ismeri. Na most folyamatok nélkül hogy lehet AI-t bevezetni?

Ez egy nagyon érdekes kérdés egyébként, mert ezt már megpróbáltuk körbejárni, de közben azért volt ennek egy nagyon szép evolúciója, meg nagyon szép íve a Deltán belül, és közben nagyon sok tapasztalatunk jött a különböző üzletek folyamán.

Akkor is elmondtam, hogy én már szeretnék úgy visszajönni, hogy élő üzletekről tudok beszélgetni, meg olyan jellegű tapasztalatokat tudok megosztani, ha valóban az üzleti döntéshozók részére érthető emberi nyelven leírja azt, hogy mire érdemes figyelni. És akkor ezeket nagyon szívesen meg is osztanám egyébként ebben a válaszban, mert én még mindig azt látom, hogy azért vannak olyan kritikus pontok, amiket nem feltétlen módon vesznek figyelembe. És ezeket a kritikus dolgokat én most már látom az üzleteink kapcsán. Nyilván az első, a legfontosabb az adat. Tehát az, hogy lássuk, hogy milyen adataink vannak, egyáltalán azok az adatok, amiket felhasználunk, relevánsak-e az adott fejlesztés szempontjából, ez nagyon-nagyon fontos dolog.

Meg az adatkonzisztencia, meg az adattisztaság. A másik ilyen dolog, amit én látok, és nagyon-nagyon ebbe az irányba megyünk el, az a folyamat, vagy a folyamatfelmérés. Tehát lássuk azt, hogy az adott adatokhoz tartozó folyamat az pontosan micsoda. Meg is kell, hogy értsük, és majd itt én azt gondolom, hogy érdemes beszélgetni egyébként arról, hogy egy gárdai fejlesztői csapatnak a feladata már nem csak az, hogy azokat a programozási feladatokat, amiket neki valaki elvisz, azokat lefordítsa a programozás nyelvére.

Erről kérem szépen beszéljünk.

Hadd szúrjak közbe. Az egyik olyan dolog, ami szerintem nagyon fontos, hogy ott ültem gazdasági igazgatóknak szervezett konferencián, és nagyjából 260 döntéshozó ült ott, és megkérdeztem tőlük, hogy tetszenek-e emlékezni 2009-re, amikor Data World House projektek garmadát indítottuk el. Emlékszel-e? Emlékszik mindenki. Szuper. Kinek működik? És kettő ember tette föl a kezét. Nagyon jó, mert ők be tudnak vezetni AI-t. Mit gondolsz erről?

Hát azt gondolom, és akkor szeretném tovább folytatni ezt az egész gondolatot, hogy a következő ilyen jellegű dolog, ami a tapasztalatainkból származik az, és a Szabi már említette egyébként ezt, hogy ezek a rendszerek, ezek nem önállóan vannak. Ezek architekturális szinten egy nagyobb vállalati szakrendszerbe illeszkednek be, amit egész egyszerűen figyelembe kell venni, mert az a fajta folyamat, meg az a fajta automatizáció, amit az AI bevezetésével el lehet érni, annak nagyon tudatosan illeszkednie kell ezekbe a rendszerekbe, adatot kell tudni cserélni oda-vissza azért, hogy ez egy valóban jól működtethető megoldás legyen. És akkor nézzük meg a következőt, ami számomra kritikusan fontos, és ezt látjuk egyébként az ügyfél visszajelzése kapcsán is.

Tehát ez a fajta dolog az a megfelelőség és az adatbiztonság. Ezeket a dolgokat, ezeket gyakorlatilag ma a NIS2, a GDPR, az AI-jekt, mint keretrendszer vezényli és fedi le, illetve ugye itt nagyon-nagyon fontos az is, hogy az a fajta biztonságosság, amit éppen te mondasz, hogy a kiberbiztonság, azt egész egyszerűen figyelembe kell venni ebben az esetben. És akkor vannak még nagyon fontos tényezők, amiket most már nagyon tisztán látunk. Az egyik egyébként a Governance. Tehát gyakorlatilag az, hogy egy AI modellt nagyon-nagyon szigorú gázlélek közé kell rakni az egyik oldalon, szabályozás kell. Mondok egy nagyon jó példát. Egy AI modell például egy bankban nem hozhat hitelügyleti döntéseket önmaga, csak mondjuk 10 millió forint alatt, de afelett nem.

És akkor gyakorlatilag ugye még én azt gondolom, hogy kell ide még egy nagyon fontos dolog, amit az ügyfeleink visszaeső kapcsán látunk, az pedig az, hogy kell egy felelős. És ez valahol válasz egyébként a te kérdésedre is, hogy hol buknak el az AI projektek, egy része ott, hogy ezek folyamatában nincsenek betartva, másrészt nincsen olyan ember, akit felelős szinten meg lehet nevezni azért, hogy az AI projekt működjön. Visszautalva a 10 millió forintos Go No Go stop, ugye a Human Interloop, tehát az emberi döntéshozatalban azért, hogy az AI 10 millió alatt jó hitel döntéseket hozzon, azért felelős mondjuk a hitelintézési igazgatója az adott banknak. És még egy nagyon fontos gondolat egyébként, amit most már nagyon tisztán látunk, hála Istennek, az az úgynevezett minőségi kontrol, vagy kvaliti kontroll.

Azért lássuk be, hogy egy tradicionális alkalmazásfejlesztésnél az autputok azok determinisztikusak. Nagyon jól kiszámítható módon determinisztikusak. Egy AI modell az diasztikus. Az valószínűségszámítással működik.

Folyamatosan, felelős módon az kell, hogy egy AI modell működtetése vagy modellek működtetése kapcsán legyen minőségkontroll szervezetben, és így működtethető ezzel a gyakorlatilag 7 modulárisan nagyon jól egymásba illeszkedő megoldással egy jaji modell úgy, hogy az nem csak prompt fog működni, amikor bevezetik, hanem két-három év múlva is.

Nagyon fontos gondolatok ezek. Legfőképpen azért, mert én azt tapasztalom, megint a piacról mondom, hogy nagyon sok olyan komplians sértés, hívjuk így, ez ilyen finom szó, komplians sértésünk van, ahol a Shadow AI, Shadow IT vonatkozásában nem tudjuk elégszer felhívni a figyelmet, hogy kollégák, állítsunk már be annak a nyomorult AI-nak egy felhasználónevet meg egy jelszót. Az API-kulcsoknál is megvan az a lehetőség, hogy API-szintű, tehát hogy program szintű jelszót állítok be, időzítést adok neki, hogy egy hétig működjön, vagy két hétig működjön, ami security szempontból kellemetlen, mert le fog járni, oda kell rá figyelni, de akkor, amikor egy ilyen típusú fejlesztéshez érkezünk, akkor én azt is szeretném megkérdezni, hogy a Security-t hogy tudjátok beépíteni ebbe a Legacy rendszerekbe így, hogy most már AI is van, meg ezzel a problémakörrel küzdünk.

Ez nektek mennyire nehéz?

Mondanám, hogy by design, és akkor mer válaszolni, de azért nyilván jó a kérdésed, és olyannyira, hogy akik minket megtalálnak, és talán ez az előző gondolataitokkal is összecsengnek akár a folyamatokra, az üzleti folyamatokra, ami kérdezte az adatokra is, meg magára erre a komplexre is, az adatbiztonságra is, hogy a legtöbb ügyfél, aki minket is megtalál, az megoldást vált. Tehát a dilivery oldalon gondolkodik. Mi most így tudatosan szétszedtük három pontra a belépési lehetőséget, ha egy ügyféllel beszélgetünk, akkor amellett, hogy vannak kész dobozos megoldásaink, és akkor ezt most így reklámozom így halkan egy kicsit, mert most az elmúlt két hétben nekünk 200 körüli interjút bonyolított le a mesterséges intelligencia, ami miatt ne olyan interjút érts, hogy most ez egy ilyen felolvasok kérdéseket, és akkor válaszolsz rá, hanem tényleg beszélgetéseket.

Magyar nyelven egy órán keresztül, adott esetben visszakérdezgetve abba, amiket mondasz, és természetesen ő maga vezérli a beszélgetést, ő maga értékeli ki, és ott van a végén az ember, aki ezt felül tudja bírálni, ami kijön ebből. Ezt már például South Service alapon elő tudod magad fizetni, és mi amit adunk mögé, az gyakorlatilag a nagy felhőszolgáltatók által garantált security keretrendszer. Mi magunk is egyébként, mint abszkér, a saját mesterséges intelligencia megoldásainkat egy ilyen felhőben kialakított, de zárt rendszerben használjuk, tehát hogy a te fogalmaiddal az az, amit úgy hívunk, hogy meghatároztuk azokat, hogy mit tehet, mit nem tehet. Vannak ilyen szerepköri hozzáférési jogosultságkezelések, vannak monitoringok, és hát a legfontosabb, hogy egy zárt rendszerként működtetjük ezeket, hogy ne tudjon kimenni.

Természetesen tőlünk se olyan dolog, ami a fejlesztésünket érinti. Tehát, hogy van olyan egyszerű megoldás mondjuk, amikor ezekhez most már hozzá tudsz férni, egy kicsit kis csillaggal visszacsatolva, ugye tudomásom szerint mi vagyunk az egyetlen, akik már átmentünk egy nemzetközi ügyvédi adatvédelmi hatásvizsgálaton, és erről papírunk van, tehát rendelkezünk azzal, hogy mi tényleg a dizájnba az AI-ek, tehát a GDPR-t, illetve ezeket a Security Requirementeket már beépítettük, és úgy készítettük el ezeket a megoldásokat. De visszakanyarodva ide, hogyha nem ezt az egyszerű utat akarod követni, amire most azért próbálunk mi mindenkit sarkallni, hogy ha már van egy ilyen megoldás, akkor az a legegyszerűbb neki is, ha self-service-ben előfizeti és gyakorlatilag kifizeti rá az X dollárt, és megveszi a csomagot, és valamennyi interjút vagy szerepjátékot vagy tréninget le tud bonyolítani vele, akkor ha egyedi implementációt szeretnél, mert még azért sokan vannak ebben a mezőben, akkor ne egyből ugorjunk ki ebbe az utolsó delivery fázisba.

Mi három belépési pontot azonosítottunk, van ez az angolul neveztük el, ez a pripper, tehát amikor magát a felkészülést kell támogatni, és egyébként ha rajtunk múlik, mi mindenkit megpróbálunk felvilágosítani, ez talán csúnya szó, edukálni abban, hogy miért vannak még abban a fázisban, mert az a tapasztalatunk, hogy legtöbben ott vannak. És a középső fázis lenne, mert erre épül a zenéből fázis, amikor képessé tesszük őket, és amiről eddig beszélgettünk, talán itt az integrációk, az adatoknak a rendelkezésre állása, a követelményrendszerek, minden, ami szükséges ahhoz, hogy képessé tegyük a rendszerüket, az egy középső blokk, és csak ezt követheti az az ezekre ráépülő dilveri fázis, amit legtöbben meg akarnának, hogy már szállítsuk le nekik, de nincsenek tisztában azzal, hogy milyen jogi megfelelési követelménynek kell megfelelniük, nincsenek tisztában azzal, hogy milyen biztonság, milyen kockázatérzékenységük van, mert amit a Tivadar mondott példaként ezzel a hitelbírálatos dolggal, és ez is azért cégenként más a kockázatérzékenység, tehát én mondhatom ezt hárommillióról is, egymillióról is, hogy mondhatom azt is, hogy bocsánat, de én szeretném mindenhol bent tartani első körben azért az embert a folyamatban.

Nekünk van tényleg banki ügyfelünk, aki AI-jal, mesterséges intelligenciájal is dolgozunk, és ott például egy általam tiszteletreméltóan egy nagyon szigorú ilyen biztonsági dokumentáció elkészítését követően mi azt javasoltuk, hogy fél évig olyan KPI-ok mentén üzemeltessük ezt a rendszert, amiben visszamérhető az üzleti eredményessége is a dolognak, az erőforrás igényei is, ugye akár AI felhőköltségek, azért sok minden van, ami itt bejátszik ebben a történetben, és az alatt a féléves időszak alatt meg tudják nézni ezt. És az, hogy ott meg mellette aztán klónozott rendszerekből és olyan proxykkal dolgozik, amik nem teszik lehetővé, hogy az én adataim kimenjenek, vagy ezeket legalábbis a lehető technológiai fejlettségi szintjén a legbiztonságosabban garantálni tudjuk, az egy másik kérdés.

Nyilván itt egyébként, hogy teljesen egzakt legyek, vagy precíz, itt sok esetben hagyatkozunk azokra a nagy felhőszolgáltatókra, akik ezt mögénk tudják tenni. Ezeket a biztonsági követelményeket, és nyilván addig terjed a mi kezünk is, amíg ezt mi be tudjuk állítani, meg biztosítani tudjuk. Itt most egy kicsit utalhatok egyébként a Tivadarnak az értékes gondolataira, hogy valóban egyébként a felhő, mert tud ilyenfajta biztonsági extrákat adni, most gondoljunk akár egy ilyen DDOS-nek csúfolt, ugye egy ilyen terheléses támadásokra, amikor ugye ezt terhelik. Nem nagyon tudok olyan cégről, aki akár költségoldalról képes lenne felvenni egy Amazon Web Servicesszel mondjuk egy ilyenfajta támadásnak a költségét, terhét, hogy a végtelenségig fel lehet skálázni egy ilyen rendszert, nyilván azokkal a centerekkel, amik mögötte állnak, tehát hogy ellehetetleníti ezeket a támadásokat, tehát azokat a fajta biztonsági garanciákat sok esetben mi meg tudjuk mögé adni, amit a felhő biztosít ilyenkor.

És hát a tapasztalatunk abszolút összecseng azzal, amit mondtál, hogy itt sokszor az alaptudások hiányoznak. Tehát ez a Preparel nevű, a Diliverben a Dilivert akarják, de mi megpróbáljuk ezt tisztává tenni, hogy a Prepar-höz még sok minden lemaradásuk van. Aztán a zenéből is sok minden lemaradásuk van, és egy felelős cég csinálhat pocokat, csinálhat ilyenfajta pilot projektekig is talán eljutózkodhat, de ahhoz, hogy felskálázható módon tudjon dolgozni, ahhoz muszáj ezeket befutni, és már látom, hogy készülsz a következő kérdésre, hogy még egy kis csillagot tegyek ide, mert a költség is egy olyan aspektus, amit sokan nem, vagy elsiklik egy kicsit fölötte sok mindenki. Látunk olyanokat, akik tényleg már százmilliókat tapsolnak el AI-ra.

Az, hogy a megoldást architektúrában by design, hogyan alakítja ki az ember, az nagyon sok múlik rajta. Például én büszkén hirdetem, hogy nekünk az interjúztató megoldásunkban, például amikor én, mint egy Rick Router összeállítom magát az interjút, a Jack Descriptiont feltöltöm egyébként, ez nem egy bonyolult történet, és ahhoz az AI dolgozik, akkor ott mi szerveres technológiát használunk, aminek vannak előnyei, vannak hátrányai. Az előnye a költség, a hátránya, meg hogy ott fut egy homokóra, amit ha az ügyfél igényli, mi kiveszünk, és egy pillanat alatt fog menni bármikor, amikor megszólítja, de úgy voltunk vele, hogy a költségekben 40 szék megtakarítása az megéri azt, hogy azon az oldalon nem az ügyfélélményt rombolom, ott meglegyenek ezek a lehetőségeink, hogy játszunk ezekkel a technológiákkal.

Ugyanez igaz az ellenemhívásoknak az optimalizálására, hogy borzasztó nagy költségeket lehet spórolni ezekkel. Hogyha valaki jól épít fel egy architektúrát, és most nem adom ki az összes konyhatitkunkat, akkor jelentősen csökkentheti azt a láthatatlan költséget, ami majd a dilveri után jön egyébként, merthogy az sem egy elenyésző tényező, mi abba beleraktuk egyébként abba a dobozba, hogy amit leszállítunk megoldást, amit megrendeltél tőlünk, és leszállítunk esetleg másfélszer olyan drágán, mint a konkurensünk, aki bevállalja, tételezzük fel, hogy még ugyanolyan minőségben is működik, de egy-két hónap alatt már kiderül, hogy az a költség, ami tradicionálisan az üzemeltetése, fenntartása rátesz, az már bőven meghaladja ilyen totál koszt kalkulációban azt, amit mi leteszünk, úgyhogy most segítünk egy ügyfelünknek így egy ajánlat összeállításában, és tényleg nagyon jó tippeket tudtunk adni neki, ez is egy ilyen szolgáltatás, amit nyújtunk, hogy igenis ezeket kérje be a szolgáltatóitól, mert úgy tudja összehasonlíthatóvá tenni.

Mi ezzel rendszeresen küzdünk egyébként itt, hogy mi nem a legolcsóbb megoldást visszük, de egyszerűen azért, mert nem a legolcsóbb minőséget visszük, tehát hogy és itt a minőségbiztosítás ugyanúgy benne van, hogy ez teljesen igaz, most volt az Amazon Web Servicesnek egy ilyen committee day, ahol ott jelen voltunk tíz kollégámmal vagy kilenc kollégámmal, és visszaigazolt minket az, ami most elhangzott ott az EVS előadóitól, hogy ezek borzasztó nagy jelentőséggel bírnak, hogy hogyan alakítja össze az ember, és hogy hogyan alakítja ki a folyamatokat minőségbiztosítás oldaláról is, hogy adott esetben ez már nem az a klasszikus devops munka, ami eddig volt, és volt is egy ilyen szlogen, hogy infrastructure, ez a kontext, nem ez a kód, aki ugye jártas benne, az tudja, hogy itt a végeredmény, ahogy Tivadar is mondta, én nem azt használnám, hogy sztochasztikus egyébként, mert ma már a rendszerek tudnak olyanfajta hallucinációgátlást, meg olyanfajta objektivitást vinni ezekbe a rendszerekbe, akár a mi interjúztatónknál is, hogy támaszkodhatok rá, mint ember, ellenben tudomásul kell venni, hogy közben ha én modellt váltok, ha én promptot cserélek, azoknak ugyanúgy ráhatása lesz a végeredmény, inkább én erre hegyezném ki,

hogy a klasszikus kvality gate-ek, tehát minőségbiztosítási kapuk, amiket egy szoftverfejlesztésnél használtunk, azok erősen kibővülnek, és ha bármihez hozzányúlok, akkor az eredményt befolyásolhatja. És innentől kezdve ezt tapasztaljuk is. Tehát, hogy ilyenkor ugyanúgy végig kell verziózni kell a promptokat, nem tudom, hogy hányan csinálják rajtunk kívül. Ezekre szükség van, hogy ilyenkor az ember úgy realizálja, hogy ezek mind benne legyenek egy verzióváltásnál. Mondjuk például egy borzasztó innováció van, ezt te is mondtad, hogy nem csak a hardver oldalon egyébként a GPU-ban, meg a processzorokban, hanem a technológiákba is.

Ugye minden nagyvállalatnak a rendszerei mögött ott vannak az emberek, és most a mi kis podcastunkban is szeretnék egy kicsit behozni egy személyes szál nevezetű vonalat. A Tivadar már tudja, te még nem, hogy ez arról szól, hogy kicsit sem az adáshoz kapcsolódó kérdést fogok föltenni, amit egy kicsit megállunk, és a sok technológia után megpróbálunk értelmezni. Személy László podcaster társam a következő kérdést tette föl, hogy mi az a technológiai vagy hétköznapi dolog az életetekben, amit tudatosan nem akartok automatizálni?

Tivadar?

Ez nagyon érdekes kérdés, ez az automatizálás, mert ugye mindenki automatizálni akar. Tudom, óhatatlanul átnyúltam az üzleti életbe, attól függetlenül, hogy ez egy személyes jellegű kérdés, sportot nem tudom automatizálni. Szerintem azt nem lehet automatizálni, vagy legalábbis én azt gondolom, hogy semmiképpen sem érdemes, de egy picikét csak tényleg egy kicsit visszanyúlva így az automatizálás kapcsán az előző kérdésre. Tehát kétfajta biztonság vagy biztonságosság van az üzleti életben. Az egyik ez a nagyon klasszikus operatív kiberbiztonság. Már az én olvasatomban aztán ezzel nem kell egyetérteni feltétlen módon, de amikor megjelenik az AI, és akkor mondjuk azt, hogy a nem sztochasztikus, de mondjuk ahhoz közeli outputokat generál, akkor az AI baromira jó abban, hogy ezeket nagy számban azonnal tudja multiplikálni.

És ezért tartom nagyon fontosnak, hogy nem szabad automatizálni feltétlenül mindenhol. És ez egy nagyon kritikus dolog. Sőt, továbbmegyek, nem szabad mindenhol AI-t használni.

De visszatérünk, de most a személyes szálnál maradva.

Személyes szál nálam akkor a sport. Ez sport?

Igen.

Szabolcs?

Én kényelmes vagyok, én nekem mindent, amit tehet, én megpróbálok egyébként automatizálni, nyilván a sportot nem tudom, vagy nincs értelme, mondjuk így, inkább így mondanám, úgyhogy ebbe tudok csatlakozni hozzád, én már nyaraláshoz csináltam ügynököt, aki segít nekem kiválasztani a kis szálláshelyeket, hogy mi lenne optimális nekem, mert ezt nehéz egyenként szűrögetve így végignézegetni, és nagyon élmény volt látni egyébként, ahogy dolgozik ezekben, de valóban az emberi kapcsolatok azok olyan pontot alkotnak így, ami még talán hozzátehető.

Köszi! És most jövünk vissza ahhoz a témához, ami szerintem minden ilyen jellegű kérdésnél fölmerül. Vibe kód, AI kódoló, Agent. Melyik oldalról szeretnétek megközelíteni a kérdést, hogy legaszi rendszerek leváltása, átalakítása és a mostani kérdések.

Óriási helye van az AI-nak ebben, tehát hogy akkor kezdem én ezzel a válasszal, hogy a legaszi rendszereknek egy óriási betegsége az is, hogy ezek azt mondanám, hogy jellemzően aluldokumentáltak, hogy politikaiak korrekt legyek, de egyébként mindenhol aluldokumentáltak, hogyha nagyon sarkítanám, nem nagyon találkoztam még jól dokumentált legaszi rendszerrel, egyszerűen ahogy evolválódik az évek során, évtizedek során, nem követik le a dokumentációt, és óriási félelem mindig hozzányúlni egy ilyen Legacy rendszerhez, hogy mihez nyúlunk, mit húzunk meg és az mit ránt magával. Ebben az évben például már egy nagyon szép segítséget tud nyújtani, mert végeztünk ilyen, hogy architektúrát feltérképezni, nyilván Rivers Engine-ből visszafejteni kódot, ezekben tud segítséget adni egyébként legalább annyira, hogy indikációkat adjon egy architektnek.

De a kérdésedre a válasz egyébként, ezt mindenre így kiterjeszthetjük, hogy az AI-t szerintem lehet jól meg rosszul használni, és az emberek 90%-a rosszul használja az AI-t. Egyszerűen amiatt, mert nagyon egyszerű analógiát szoktam így használni ilyen literaszi tréningeken, meg a United Waynak az a megtiszteltetésem ért engem, hogy bor tagjává választottak, és ott például tartottunk egy ilyen literaszi tréninget ott a tanári gárdának, tehát oktatóknak, tanároknak. És ott is azt mondtam, hogy ez tényleg olyasmi, mint amikor én delegálok egy feladatot egy kollégámnak, azt lehet jól, meg rosszul csinálni, ha nem tudja, hogy mikorra mit csináljon, meg milyen eszközben, vagy milyen forrásokból használ, valljuk be őszintén, a legtöbb vezető nem jól delegál, én is sokszor beleesek abból, hogy gyorsan kell a folyosón kiadni egy feladatot, és elfeledkezek ezekről a komponensekről, akkor hiába nagyon jól dolgozik a kollégám, és nagyon jól elvégzi a munkáját, nem leszek vele elégedett, vagy lesz egy ilyen gapünk, egy ilyen eltérés, hogy amit ő csinált, az nem az, amit én vártam, vagy fordítva.

Mindamellett, hogy ő jó képességgel elvégezte a legjobb tudása szerint a feladatot, amiben nem volt benne, hogy ez nekem holnapra kell és nem holnaputánra, akkor az nyilván nem az ő hibája. Az AI-nál én ugyanígy látom, hogy a legtöbben ezt nem tudják megugrani, hogy megértsék, hogy az AI egyébként szerintem ma már van olyan okos, hogy okos, csak ha nem tudja, hogy mit akarok, akkor nem biztos, hogy azt kapom, amit akarok. És a Whitecoding itt jön be ugye, amit mi magunk is használunk, hogy mindenre igaz, hogy ne ugorjak már egy fejest, hogy elkezdjek egy kódot íratni egy homályos elképzelésre, vagy mindig szakaszoljuk le azt, amit szeretnénk, ne úgy induljon a történet, hogy én szeretnék egy ilyen rendszert és csináld meg nekem.

Ez nem fog működni, mert nem érti, hogy mit akarok először. A követelményeimet kell vele megfogalmaznom együtt, adott esetben egy kollaborációban az AI-jal, ezt hívjuk most leegyszerűsítve vibe codingnak, hogy utána azt le tudjam úgy képezni egy kóddá, hogy az aztán tényleg az legyen, amit én vártam tőle. Ha csak annyit mondok neki, hogy szeretnék egy gombot a felületre, akkor ő megcsinálja a gombot a felületre, de ha én nem leszek boldog, mert ő pirosat csinált, én zöldet akartam, akkor az ne haragudjatok, de az én hibám nem az övé, az nem hallucináció, ez is egy fontos, hogy elhatároljuk a hallucinációt, meg a promtolási hibát. A hallucináció ma már azért elég jól kezelhető ezekkel a megoldásokkal, a gát a jelekkel, meg a ragokkal, meg az MCP szerverekkel, meg a felsorolhatnám azokat a 8-10 szemantik layert, amit mondjuk adott esetben egy komplexebb rendszernél beépítünk egy AI alkalmazásba.

Egy ilyen rombolási hiba az tényleg annak a következménye, hogy nem tudtam jól megfogalmazni, mit szeretnék, és akkor így szerintem átadom, hátha a Tivadar.

Igen, én szeretném, hogyha egész, azt szeretném kérni, hogy egészítsd ki.

Igen.

Pár héttel ezelőtt volt a gimnáziumi évfolyamtalálkozóm, és mindenki beszámolt arról, hogy mivel foglalkozik, és mondtam én, hogy azért így mesterséges intelligenciával igen, és akkor kérdezték, hogy tulajdonképpen mit ad hozzá így Magyarországon, meg az emberiségnek, és akkor nekem egyetlen mondatot mondtam, hogy én azt gondolom, hogy elhozta a tudás demokráciáját. És ez egy abból a szempontból nagyon fontos gondolat, és abszolút átvezet üzleti életbe, hogy egy pár hónappal ezelőtt viszont láttam egy egészen megdöbbentő képet, már nem tudom, hogy hol, amikor egy ilyen viskóba egy földműves ember tulajdonképpen számítógép előtt ül, és akkor az volt odaírva alá, hogy itt az új konkurenciát. És ez egy nagyon-nagyon érdekes gondolat.

És nagyon-nagyon átvisz abba az üzleti irányba, hogy tulajdonképpen én nyugodtan ki merem mondani, hogy nekünk már nem feltétlen módon csak a versenytársaink a versenytársaink, hanem azok az ügyfelek is, akik vibe codingot használnak. És akkor mondhatnánk azt, hogy tulajdonképpen ez nekünk egy versenytársi probléma, és ezt kezelni kell, én meg megfordítom, nekünk ez egy lead generátor. És ez egy nagyon fontos gondolat. A vibe coding, meg a mesterséges intelligencia és itt a szabi okos gondolatai ráakaszkodók egész egyszerűen lehetővé teszi azt, hogy tulajdonképpen egészen komplex projekteket megdöbbentően gyors idő alatt tudjak megfogalmazni és elkészíteni. Tehát nem évek vagy egy év most elkészíteni egy krátrendszert, egy szoftveres keretrendszert, hanem akár pár óra.

És ez azért megint tulajdonképpen párhuzamosítható azzal, hogy ha van valakinek egy nagyon jó piaci ötlete, akkor avval a fajta gyorssággal, amit az AI ad neki, azzal gyakorlatilag erre ki tud menni a piacra. És ez nagyon fontos gondolat. De a másik oldalon viszont szeretném azt ezeknek a kiváló cégeknek jelezni, hogy ez nem egy production ready, ez nem egy éles környezetbe való átállítás. És én azt látjuk, vagy mi azt gondoljuk egyébként, és egyre több ilyen megkeresésünk van, hogy van nagyon erős doméntudás az ügyfelek oldalán, hiszen az ő piacukat ők ismerik, meg látják, tudják, hogy hogy kell kezelni. De igény van a részükről arra, hogy amikor készen van egy ilyen MVP, tehát egy bemutatható, tulajdonképpen drótváz, ami az alapfunkciókat jól körbeírja, és operációs szinten be tudja mutatni, akkor gyakorlatilag fel kell készülni arra, hogy folyamat, adat, compliance, amiket elmondtam az előző válaszomban, kvality kontroll, hogy az egy működő éles környezetben hogyan rakható ki, milyen körülmények között.

És ez nagyon-nagyon fontos, hogy a Wipe coding, meg az AI valóban lehetővé teszi az MBP-ket, de az nem az éles környezet.

Bocsánat, csak akartam volna veled vitatkozni, de aztán visszahoztad a gondolataidat oda, ahol már közel egyetértünk, mert ugye volt egy ilyen állításszerűséged, hogy mennyire konkurens egy ügyfélünk, aztán utána visszahoztad, hogy nem az. Én is azt gondolom egyébként, mert egy Wipe codinggal nem tudod kiváltani egyszerűen azt a fajta tudást és ismeretet, amivel például mi rendelkezünk, és ennek egyszerű oka van, mert még ha egy nagyon tehetséges, nagyon okos ember is van, aki üzletileg mondjuk akar magának készíteni egy ilyen rendszert, ott fog az akadályokba elbotladozni, hogy szemben a mi architektünkkel, akinek megvan az a fajta technológiai ismérete és tudása és rálátása, szenioritása, hogy lehet, hogy egy nagyon tökéletes funkcionális elvárási kört tud megfogalmazni egy AI számára, de azok a nem funkcionális elvárások, amiket egy architekt hozzátervez itt most az említettek közül csak a skálázódás, a biztonság, sok olyan dolog van, ami beépül egy ilyen rendszerbe ahhoz, hogy az jó legyen a mi kontextusunk szerint, az egyszerűen nincs a látókörében.

Tehát ugyanott leszünk, hogy ő nem tudja megfogalmazni, mert nem tudja, hogy azt meg kellene fogalmazni hozzá, hogy ja igen, itt egyébként fel kell készítenem arra, hogy ilyenfajta teljesítményingadozások vannak, hogy performancia elvárások, és emiatt nem fogja tudni megfogalmazni. Nem azért, mert képességbeli korlátai vannak, hanem mert tudásbeli hiányosságai vannak.

Az a nehéz, hogy 2000 környékén nagyon sok könyvelő azért lett programozó, mert nagyon jól könyvelt, és szerette volna az ismétlődő munkáit meg gyorsítani, ezért megtanult programozni, és csinált egy keretrendszert. Most az a probléma, hogy mindenki programozó, és nem tudnak könyvelni. De mindenki könyvelő szoftvert csinál. Viszont egyetlen kérdésre maradt már csak időnk ebben. És Tivadar, téged szeretnélek megkérdezni, hogy az abscale delta szinergiával hogyan sikerül ezt a kérdést körbejárni és hogyan tudtok benne hatékonyan együttműködni.

Múlt évben a múltkori podcastokban beszélgettünk arról, hogy a Delta milyen jellegű transzformáción megy keresztül, erről a Bakos Róbert vezérigazgató úr is beszélt, illetve én is beszélgettem róla, válaszoltam a kérdésekre, és elképesztő fontos dolognak tartom, hogy közben azért ezek az akvirációk, amikről akkor még csak jövőbeli dologként beszélgettünk, ezek lezáródtak. És sem én azt gondolom, sem a kollégáim, sőt maga az üzleti élet sem tekinthet önmagában egyfajta kiterjesztett szolgáltatást halmoznak afelé, hogy van a gyapskélünk, meg vannak más egyéb akvirált cégek. Hogyha megnézzük a Deltának az evolúcióját, meg a mostani üzemszerű működését, akkor nagyon-nagyon jól látszik az, hogy amit akkor beszélgettünk abból a doboztologatós megoldásból, egy kifejezett stratégia tanácsadói céggé alakultunk át, ahol gyakorlatilag, és ez nagyon fontos gondolat, megértve az ügyfeleink üzleti folyamatait, azokra tudunk tulajdonképpen magabiztos és jól skálázható, robosztus, egyenszilárd megoldásokat biztosítani.

De ezt nem tudnánk megtenni egyébként anélkül, hogy lenne nekünk egy upscale-ünk. Én úgy tekintek az upscale-re gyakorlatilag, mint egy olyan fajta szervezetre, aki azt biztosítja az ügyfeleink részére, hogy számon kérhető módon egyetlen egy nagyvállalattól rendelhet meg egyben szolgáltatásokat, lehet az klasszikus rendszerintegrációs tevékenység, LAN van technológiák, storage szerver, stb. szállítás, illetve azok a nagyon modern, egyedi típusfejlesztések, amiket az upscale-lel tudunk megvalósítani, amik gyakorlatilag egyben tartják ezt a fajta szolgáltatói kört, és ezt tartom a legfontosabbnak.

Nagyon szépen köszönöm, elfogyott a műsoridőnk.

Köszönöm, hogy eljöttetek és tudtunk beszélgetni.