Ha az AI írja a kódot, mi marad a fejlesztőknek?

Egy gyakorlatilag technikai háttér nélküli, mondjuk azt, hogy üzleti felhasználó is nagyon messzire el tud jutni, tehát össze tud rakni egy majdnem kész rendszer, csak ez a probléma ezzel, hogy majdnem kész.

Mai vendégeink Bács Zoltán, az Artofinfo ügyvezetője és Kozma Ferenc, a Delta fejlesztési és technológiai igazgatója. Köszöntelek benneteket a stúdióban. Az első kérdés, hogy ez a mai világban, ugye így kezdi minden AI, hogy a mai világban hogyan változott ez a fejlesztési trend, amiről tulajdonképpen beszélgetünk. Tehát nagyon érdekes az a rész, amikor egy vállalat valamilyen szoftveres megoldást szeretne. A szoftveres megoldást azonnal akarja, és kétféle dolog szokott történni a saját tapasztalatom szerint, A letöltik, B, elkezdenek valahol valamiféle ilyen shadow IT és shadow AI módon fejlesztgetni. Egy kicsit be tudnátok mutatni, hogy mi ez az Art of Info, hogy kezdődött el a sztori, és ebben a világban hogyan tudtok boldogulni?

Melyikőtök kezdi?

Kezdem én. Igazából a működésünk az 10 évvel ezelőtt kezdődött, egyedi alkalmazásfejlesztés volt a fő fókusz. Ez különböző szolgáltatási területeken, egészségügy, bank, biztosítás, ipari területek, tehát egészen szerteágazó. Ez kiegészült, aztán az évek során karbantartás supportal, nyilván azokat a szolgáltatásokat, vagy azokat a megoldásokat, amiket mi szállítottunk, azokat továbbra is szapportáltuk az esetek nagy részében támogattuk, hiszen ezeknek a szoftvereknek ugye életciklusa van, folyamatosan változik a körülöttük lévő környezet, ezeket update-elni kell, update-elni, illetve az üzleti folyamatok is változnak, úgyhogy ezeket életben kell tartani, tovább kell fejleszteni, úgyhogy ezt is csináljuk.

Ebből aztán kinőtt egy még egy üzletágunk, ez a szoftver tékor, az majd esetleg egy külön téma is.

Külön kéne kiadás?

Igen, vagy külön is lehet erről beszélni, amikor már nemcsak az általunk fejlesztett szoftvereket, hanem harmadik fél által fejlesztett szoftvereket veszünk át, és visszük tovább a szoftver életciklusának megfelelően. Tehát egy egyedi alkalmazásfejlesztésből indultunk, igazából 10 év alatt is rengeteget változott a világ, főleg itt az utóbbi években. Egyrészt amivel mi szembesültünk, az az, hogy rengeteg low code, now code rendszerplatform jelent meg. Nyilván ezek nem teljesen új dolgok, hiszen amióta a szoftverfejlesztés megy, azóta nyilván mindenki gyorsabban szeretne, hatékonyabban, olcsóbban, úgyhogy korábban is voltak eszközök, csak most jutottak el szerintem olyan szintre, ami tényleg jól használható, és viszonylag nagy most már a penetrációja ezeknek az eszközöknek, illetve megjelent az AI, generatív AI, és most már ugye egészen máshogy dolgozik egy programozó, mint tíz évvel ezelőtt, amikor kezdtük.

A Deltában hol és mikor merült föl a rendszerintegrációs funkcióban, hogy valamiféle programozás és valamiféle low code now code platformra van szükség.

Üdvözlöm a kedves nézőket, hallgatókat. Igazából ez mindig is terítéken volt, de az utóbbi pár évben nyílt meg a lehetőség arra, hogy akkor szánta-e magát a Delta tőzsdérőlépés után, hogy bővíti a portfólióját avval a képességgel, hogy önmaga is tudjon részt venni a fejlesztésekben, és valójában ilyen cégeket kerestünk, én ugye a műszaki felméréseket vittem ilyen szempontból. Gyakorlatilag az Artofinfóban egy olyan céget találtunk, ami az univerzálishoz közelítő, de mégis szükséges specializációkkal rendelkező klasszikus fejlesztő stúdió, ami képes megvalósítani a portfóliónak azt a részét, ami a legjelentősebb arányban áramlik be így, mint ügyféligény. És én nem mennék el, amit az Ali mondott, hogy szoftver tékover, én például ezt mindenképp kibontanám ebben az adásban, ugyanis ez magán a felmérés nem is volt érdekes módon része, ez csak menet közben derült ki, hogy ez egy rendkívül.

Milyen felmérés?

Az akvizíciós felmérése során. Tehát én ugye nem találkoztam evvel, hiszen ez egy futó kaland volt úgymond, tehát egy említésre került, hogy ilyennel is foglalkoznak, de hogy ez nem jelentette a portfoliók jelentős részét. Utólag derült ki, hogy egyébként erre mekkora hatalmas nagy piaci igény van, és hogy ez mennyire nincs kompetencia a piacon.

Egy picit segítsetek nekem. Ugye a hallgatóknak szól az adás, és ezért érdemes kifejtenünk, mert nagyon sokszor belefutunk abba a szakmai hibába, hogy annyira triviálisnak, egyértelműen magától értetődően kezelünk valamit, szoftver tékóver. De mit értünk ez alatt? Tehát, hogy akkor, amikor ott ülök a vezetőségin, akkor mindig ilyen három-négy dimenziót próbálok meg így feltárni. Az egyik, hogy márpedig nekünk az egyik szó, hogy költségcsökkentés, ugye? Tehát minél hatékonyabb a szoftver, annál jobb. De ehhez azért kellenek folyamatok. De egy picit körbe tudnátok lőni, hogy szoftvertékóvás, egyedi fejlesztés, mi miben különbözik, miért jó a lókódnókód, csak egy picit menjünk bele ezekbe a szeleteibe.

Zoli?

Jó, tehát az egyedi fejlesztés általában egy ügyfél speciális igényére készülő megoldás, amikor nem talál dobozos terméket az ügyfél, tehát saját folyamatainak, saját üzleti modelljének megfelelően szeretne támogatást kapni alkalmazás oldalról. Ezt ugye különböző módszerekkel lefejlesztjük, majd ezeket ugye kifejtjük. A szoftver t Cover, az pedig arról van szó, szoftverátvétel vagy szoftvermentésnek is hívjuk, amikor egy-egy ügyfélnél már nagyon nagy alkalmazásportfólió halmozódik fel, rengeteg. Tehát van olyan ügyfelünk, akinek több ezer alkalmazása van, tehát hogy iszonyú nagy tömeg, és ezeknek az alkalmazásoknak nincs esetenként gazdája, mert az a beszállító már tönkrement, megszűnt, vagy egy belső fejlesztőcsapat végezte, aki közben leépült, vagy nyugdíjba mentek azok a fejlesztők, akik 50 éve vagy 30 éve elkezdték.

Jó kis kobolban megcsinálták.

Abszolút ezek futnak ezek az ilyen rendszerek.

Igen, és minden helyzet más és más.

Abszolút más és más. Hát az a közös benne, hogy egy fejfájást okoz az ügyfélnek, hogy mit csináljon, ki supportálja, ki ért hozzá, hogy tudja ezt gazdaságosan fenntartani, és mi ezeknek az alkalmazásoknak a sorsa. De valamit csak valameddig fenn kell tartani, mert tudja az ügyfél, hogy bevezet egy másik rendszert, ami majd kiváltja, de addig fenn kell tartani, tehát ez is egy eset. De van olyan, hogy nem látja ennek a lehetőségét, tehát igazából újra kellene írni, újra kellene gondolni, új funkciókkal ellátni, tehát tovább kellene vinni.

Az az érdekesség ebben az átalakításban, hogy én is gyakorlati tapasztalatokat szoktam megkérdezni, és mivel szembesültem én, ezt valahogy úgy hívom, hogy projekt purgatórium. Ugye, hogy egy csomó cég megvesz egy csomó szoftvert, elkezdi használni, majd elfeledkezik róla. Mi volt az a legmegoszthatóbb történet, amikor belefutottatok egy ilyenbe, hogy egyről volt szó, és akkor nem tudom, száz lett belőle, mert azért így szokott ilyen lenni.

Mind a ketten.

Ez nagyon jó kérdés, hogy mi a megosztható. A nem megoszthatók közül rengeteg olyat tudok, ahol, de nyilván el tudják képzelni a kedves nézők és hallgatók is, ahol az az igazán nagy cég, ahol már biztos vannak olyan szerverek, amit senki nem mer lekapcsolni, mert nem tudják, hogy az alkalmazás mit csinál, és milyen gondot okoz, ha az megszűnik.

Igen.

Tehát itt kezdődnek a problémák.

Abszolút. Illetve ugye ez, hogy egy kicsiből nagy lesz, erre is van egy példa. Az egyik egyébként multinacionális cég egy innovatív dologra felbérelt mondjuk egy freelancert, aki egy egyszemélyes cég volt, és megoldott neki egy olyan problémát, ami fontos volt. Viszont ugye ez az egyszemélyes cég, ez nem tudta követni azt az igényhalmazt, azokat a fejlesztési igényeket, amit ugye ez a multinacionális cég szeretett volna, ugye ez nem csak egy telephely, hanem ez sok országban működő cégről beszélünk, úgyhogy akkor ő ezt átadta ugye egy másik csapatnak, csak ott meg a csapatnak a kiválasztása nem volt megfelelő, mert ott nem egy összeszokott fejlesztőcsapatot sikerült, hanem toboroztak egy csapatot, akik soha nem dolgoztak együtt, úgyhogy akkor ott mindenki hozta a saját tapasztalatát, saját technológiáját, úgyhogy ott elkezdett elburjánzani, és akkor egyből lett öt alkalmazás különböző technológiákkal.

Persze működött, tehát hogy igazából siker volt a cégnek, csak ugye ennek utána megint a skálázhatósága, meg az upgrade-je.

Naprakészen tartása.

Igen, igen, igen, tehát hogy nagyon sokszor olyanokat látunk, hogy nem tudják lecserélni a régi, réges-régi Windows, akár XP-re.

XP-re, igen, ez a csapaton fut a szoftver, és már nem tudják, hogy hogyan lépjenek ebből ki, tehát ezek ilyen kérdésekkel szembesülünk.

És hogy tudtok rugalmasak lenni? Tehát azért, hogy az AI megjelent, elképesztő változás ment végbe. Tehát eddig sem volt egyszerű, egy kicsit beszélhetnénk arról is, hogy honnan indultunk. Tehát, hogy régebben ez a fejlesztés azért úgy volt, hogy viszonylag korlátozott keretek között fölmerült valakiben egy ötlet, volt egy átfutási idő, volt egy implementációs idő, volt egy tesztidőszak, és utána ment élesbe.

Ez hogy változott?

Az AI alapvetően ezt a folyamatot nem változtatta meg, igazából minőségileg rontotta, ha lehet így mondani, ugyanis amit mi várunk az AI-tól, hogy felgyorsult világunkban még nagyobb sebességet hozzon, még nagyobb sebességfokozatra kapcsoljunk. És ugye sokszor elhangzik, hogy az AI elsősorban legelőször a fejlesztők munkáját fogja kiváltani, és utána jön majd a többi felmérések szerint. Ezt egyébként maguk a fejlesztők kevésbé tapasztalják, merthogy igazából a nyomás nő rajtuk, hogy ugyanannyi idő alatt jóval nagyobb produktivitást várnak el tőlük, és ezt az AI által, viszont az AI olyan mennyiségű kódot generál, amit nagyon megnöveli a belépési küszöböt, nagyon kiszorítja a kezdőket a profik részére, ami még inkább munkaerőpiaci szűk keresztmetszetet okoz, ez is megér egy misét, és ráadásul az AI által generált nagy mennyiségű kód az szinte követhetetlen minőségi szempontból, tehát a legnagyobb problémát majd ennek a helyes mederbe terelése jelenti.

Tehát most egy olyan fázisban vagyunk az AI-s fejlesztések kapcsán, mint anno az aranyláznál, amikor így a jeges folyóból kézzel ásták ki az aranyrögöket a fagyban, mindenki próbálja rávetni magát, de még nem alakult ki az a, vagy folyamatosan inkább az a helyes, folyamatosan alakul az a meder, amiben ez biztonságosan végezhető majd.

Ez ugye munkaerőpiaci oldalon meg ott van a szűk keresztmetszet, hogy kiestek a juniorok, és egyből ugye aki a piacon maradt, mint szenior, ő az, aki létezik, de hát hogy lehet akkor ezt egyensúlyban tartani? Itt a kérdés másik fele.

Igen, abszolút ez egy jogos kérdés. Én azt gondolom, hogy meg fog változni az, hogy hogyan jut el egy juniorra a szenior fejlesztő kategóriába, tehát nem úgy, hogy nagyon sok programsort ír és megtanulja, hanem úgy, hogy az AI-t használja, tehát rombolja, ezt kell majd megtanulnia. Tehát igazából mást kell megtanulnia, az eredmény az nagyon hasonló lesz ahová eljut. És még bocsánat, még visszatérve az eredeti kérdésedre, hogy hogyan változtatja meg, én annyit szeretnék mondani, hogy igazából majdnem mindegyik lépését a szoftverfejlesztésnek megvalósítja, mert ugye azt látjuk, hogy a specifikációkat is jelgenerálja, adott esetben marden nyelven leírva, amit majd utána könnyen tud értelmezni az AI. Utána a fejlesztés az egyértelmű, tehát most egy fejlesztő az nem kódsorokat ír, hanem agenteket futtat párhuzamosan ami generálja neki a kódokat és aztán azt validálja és rakja össze, tehát hogy teljesen más a módszer, ahogy dolgozik.

Gyakorlatilag az eszközök is adnak támogatást, tehát akár a tesztelés, tesztforgatókönyveknek a legyártása a specifikáció alapján megint nem kézzel történik, hanem generálódnak. Tehát hogy az egész folyamaton végighalad, és mindenhol érintett, minden lépés érintett gyakorlatilag az AI-t.

Azért itt több kérdés is felmerül, mert hozza a következőt. Az egyik az ecurity kérdésből mit jelent ez, és hogy tudjátok nyomon követni. Tehát azért azt is látom, hogy mondjuk egy példát szeretnék mondani. A példa az az, hogy amikor egyetemen programozókat tanítok, akkor jellemzően azt látom, hogy ők nem értenek az adott szakmához. Tehát ő nem tud könyvelni, de nagyon vibe kód alapon tud különböző kódokat lefuttatni, és ezt már nem vizsgálja felül, hogy security szempontból mennyire támadható ez a rendszer.

Ez óriási probléma egyébként, és itt akadnak meg ugye a vibe coderek, mert egy gyakorlatilag technikai háttér nélküli, mondjuk azt, hogy üzleti felhasználó, és nagyon messzire el tud jutni, tehát össze tud rakni egy majdnem kész rendszer, csak ez a probléma ezzel, hogy majdnem kész. Tehát, hogy a 90%-áig eljut, és utána nem tudja, hogy az egy deszkamodellnek jó, egy proof of conceptnek jó, de arra, hogy ez egy vállalati környezetben megfeleljen a mindenféle security, skálázhatósági, tehát nagyon sok követelménynek, arra meg nem jó. Tehát, hogy ezért még nem tartott a Vibe Coding, hogy akkor ezzel az üzleti felhasználók már nagyvállalati alkalmazásokat írjanak.

És így rendszerintegrációban találkoztok-e olyannal, amikor elkezditek átvenni, és kiderül, hogy vájkódolva volt az egész, és hogy itt milyen kérdéseket vett ez föl átvételkor?

Még nem találkoztunk ilyennel, ez csak idő kérdése egész biztosan.

Viszont egyébként keresünk ilyen lehetőségeket, ugyanis ebből rengeteget lehet tanulni. Tehát előbb-utóbb érdemes elébe menni, mert előbb-utóbb mindenki találkozni fog vele, minden fejlesztőcég találkozni fog olyan szcenárióval, amikor az ügyfél magának lefejlesztett valamit, és szeretné, hogy ez életben maradjon, mert hogy már komplett folyamatok alapulnak rajta, és nem engedheti meg magának a cég, hogy ezt veszni hagyja, és át kellene venni, csak teljesen instabil a szoftver, és innen ez egy új, hát nem is módszertan, egy know-how lesz gyakorlatilag ennek a kitapasztalása, hogy hogy lehet ebből hatékonyan életképes és úgymond a minőségi mutatókat már megütő szoftvert létrehozni. Hozzátéve, hogy egyébként ezek a vibe kódolt rendszerek, ahány annyiféle, tehát például találkoztunk olyannal, ahol nyilván az AI egy low code nocode platform segítségével generálta le a szoftvert, merthogy az volt a leghatékonyabb, és nyilván a leghatékonyabbat fogja választani.

Tehát rengetegféle eset lehetséges.

Igen, hát olyannal gyakran találkozunk, hogy mondjuk egy üzleti tudással gyakorlatilag domain ismerettel rendelkező belső felhasználó, az lefejlesztett valamit korábban még Excelbe vagy Visual Basic-be, és ugye működik, tehát hogy csak ugye ezeknek a skálázhatósága, illetve hát az enterprise nagyvállalati környezetbe történő implementálása az egész más.

Ott már megbukik a dolog.

És akkor ilyenkor kell gyakorlatilag, vagy ilyenkor vesszük át, lépünk be, és akkor segítünk ezen túllépni, mert a tudás az ott van benne a szoftverben, csak éppen nem alkalmas arra, hogy az új környezetben működjön.

Egyébként visszatérve erre, hogy a minőség hogy garantálható ilyen esetben, egy személyes élményt megosztva. Egyik fiam az most kezdett az egyetemen programozási területen, és gyakorlatilag Huskellel találkoznak funkcionális programozással már az elején, és ugye ez fog átváltani majd abba, hogy amint elhelyezkedik a munkaerőpiacon, akkor egyből szembe arcon találja majd az AI, hogy minden mennyiségben ez fog kelleni, mint munkaeszköz, tehát ez lesz a kalapács számára. És gyakorlatilag a juniorok képesek fejleszteni AI segítségével, viszont minőségileg validálni és a munkafolyamatot irányítani csak a nagyon tapasztalt fejlesztőképesek, hiszen eszméletlen mennyiségű kódsort kell átnézni, hogy ők az AI segítségével mit generáltak.

Korábban ugye kis kezükkel beütöttek pár oldalnyit, és beküldték, és akkor ezt reviews-zgatta a vezető fejlesztő vagy az architekt. Most ha nem vigyáz, akkor megkéri az AI-t, hogy az egész alkalmazást tervez újra, és beküld egy tízmilliósoros kérést, és gyakorlatilag, hogyha ilyennel szembesülnek nap mint nap még akár helyes mederbe terelve is a vezető fejlesztők, az már egy év után már látszik, és folyamatosan jelzik is a kiégést.

Hát igen, mert a Security szakmában is a logelemzés az mindig ott égeti ki az embert, és hogy erre jönnek rá ezek, de hogy én azt látom, hogy ugyanígy a fejlesztés kapcsolatán például a tesztautomatizációt egyre többször bízzák AI-ra. És hogy ebben nem éreztek valami disszonanciát, hogy az amúgy AI a fejlesztett programot, utána betesszük egy AI-jal fejlesztette ezt automatizációs megoldásba, ami ad valamilyen eredményt.

Ellentmondásnak hangzik, de valójában sajnos nem is tud működni másképp, ugyanis ha átgondoljuk, hogy tegyük fel legenerálsz egy millió sornyi kódot, és az működik, és akarsz rá teszteket írni, megírod rá a teszteket, tegyük fel kézzel, és másnap az egész milliósat kidobod, és egy másik félmilliót változtatsz rajta, akkor gyakorlatilag a szűk keresztmetszet teszteknek a kézi módosítása lesz, ráadásul meg sem fogod érteni. Tehát az AI úgyis promptokból úgymond a felhasználási eseteket promptnak véve generálja le a kódot. Valójában ő tudja legjobban megmondani, hogy milyen jó tesztesetek kellenek ahhoz, hogy az eredeti felhasználási eset visszaellenőrizze.

Igen, szerintem sincs más út, hiszen ugye hát azt mondják, hogy exponenciálisan nő a világban a coachorok száma, viszont a tesztelők száma az véges.

Mondjuk, hogy lineárisan nő, de hogy semmiképpen nem tud lépést tartani ezzel a hatalmas kódbázissal, tehát hogy az automata tesztelésnek még inkább egyre nagyobb jelentősége lesz, azt gondolom.

Illetve a kiégéssel még csak csökken is a számok.

Igen.

És figyeljetek, azt szeretném, ez mindig kérdésem. Mennyire kell érteni ahhoz a céges folyamathoz, mondok mindjárt egzakt példát is, amit programoz. Tehát mondom az egzakt példát. 2000-es évek magasságában nagyon sok könyvelő elképesztően jó könyvelő volt, és szeretett volna automatizációt, és megtanult programozni, leautomatizálta, csinált egy programot, és ezzel kezdett el könyvelni. De a mostani programozók nem értenek a könyveléshez, csak programoznak.

Ez az üzleti elemzőknek a problémaköre valójában, tehát ezt nem is kell a programozónak érteni feltétlen, hanem mély szinten ehhez.

Nem feltétlenül, de azért szerintem az a hatékony, hogyha a programozó azért domaintudással is rendelkezik, tehát hogy tudja, hogy mit csinál.

Ez egy kicsit provokatív kérdés is, mert hogyha én tudok könyvelni, akkor tudom, hogy melyik gombnak kell ott lennie és melyiknek nem. Ezért kérdezem ezt a kérdést.

Nem tudja az üzleti elemző a programozótól szükséges teljes megértést átvenni. Tehát ő leírhatja, hogy mit kell csinálni, de nem tudja annyira mélyen dokumentálni, hogy ne várná el azt a minimális befektetett energiát vagy józan megértést a kivitelezőtől, hogy tudja, hogy mit épít.

Igen. Tehát ez gyakorlati tapasztalat, tehát hogyha az a kolléga, aki nem mondjuk egy picit szélesebb rálátással és megértéssel dolgozik, akkor ott lehet, hogy leszállít egy részt, de hogy az nem fog együttműködni esetleg a mellette ülő kollégának a dolgaival, hogyha nem értik az egészet. Tehát, hogy szerintem domaintudás az mindenképpen szükséges, anélkül nem lehet.

És mennyire okoz most problémát ez a hármasság, hogy van egy AI, van egy junior senior különbség, meg van egy felgyorsult világ. És ebben a megértés és az információ átadás, amikor programoztok az üzleti elemzők versus a programozók között?

Hát ugye szerintem ugye átalakul ez az együttműködés. Ugye az AI támogatja mindegyiket, tehát támogatja az üzleti elemzőt, hiszen ugye az üzlettel való beszélgetés során akár kész tűpontos felületi tervekkel megy, amit ugye véleményez az üzlet, tehát ezzel meg van támogatva az ő kommunikációja, illetve a munkája, és sokkal gyorsabb, ugye nem figmába rajzolgatja, vagy vízióba, vagy valamilyen eszközzel, hanem igazából percek alatt legenerálja egy leírás alapján a felületet, az üzlet ezt validálja, visszaigazolja, ki is lehet adott esetben próbálni, meg is lehet kattintgatni.

Ugye valójában azért egy nagyon fontos dolgot nem jártunk körbe, hogy azok a módszertanok, amivel szoftvert lehet fejleszteni és a cégbe implementálni lehet, azok ugye mondok egy példát vízesés scrum agilis. Ugye ezek olyan szavak, amit nagyon sokszor hallunk, és nem tudjuk, hogy mit jelent mögötte a működés. Erről egy picit tudnátok így egy átfogó képet adni, hogy mit mire használnak, mire jó?

Hát visszakanyarodva így a projektmenedzsment vonalról tekintve erre az egészre, egy lépéssel visszább lépve. Vizes és modellt egyszerűen csak üzleti szempontból úgy kell tekinteni, mint úgymond a projektmenedzsment háromszöge, ahol a költség, az idővonzat és a cél, tehát az elvégzendő feladat a háromszögnek a különböző sarkain szerepel, középen a minőség ezt kicsit így feszíti. Ott gyakorlatilag a funkció az, ami fix, és hát az idő az nagyjából fix, mert tudom, hogy ez a munka nagyjából mennyibe fog kerülni, és ajánlatokat kérek be, ahol az árváltozó, mert mindenki más összegért fogja ezt megcsinálni, nagyjából hasonló időre, és utána elfogadom, és gyakorlatilag vagy sikerül nekik, vagy nem, a minőség is ugye lesz amilyen.

Ezzel szemben az agilis módszertanok és a scrum ennek egy része arra esküszik, hogy ha nem tudod, hogy mit szeretnél elérni, és egyébként ez a legtöbb esetben még akkor sem biztos, hogyha egy specifikációba érkeznek, mert simán lehet, hogy nem jól fogták meg a problémát. Gyakorlatilag ott az idő és a költség a fix, merthogy folyamatosan embereket bérelsz úgymond, vagy folyamatosan emberek dolgoznak a problémádon állandó sebességgel, és te időről időre két-három hetes sprintekben tipikusan kapsz egy ellenőrzési pontot, ahol meglátod, hogy mit értek el addig, és gyakorlatilag ez olyan, mintha egy három hetente lenne egy vízesés modelled, és mindig újratervezhetsz, és menet közben tudod kitalálni, hogy mi lesz a helyes irány.

Így nem garantált, hogy valaha el fogsz jutni oda, ami területileg elképzelhető. Valószínűleg nem is fogsz, mert mindig menet közben ki szokott derülni, hogy melyek az igazán fontos célok, és gyakorlatilag ez is az agilisnek úgymond az alap létjogosultsága, hogy folyamatosan szállítani, és mindig naprakészen, most nem akarok belemenni az angol rövidítésekbe, de főleg nem is az a szakterületem, a Scrum, de gyakorlatilag mindig egy működő szoftvert kell tudni megpróbálni, vagy egy működő produktumot kell tudni átadni egy adott sprint végén?

Hát én azt gondolom, hogy a leghatékonyabb, és ezt gyakoroljuk az Art of Infónál. Ez egy hibrid megoldás.

Az elején a problémának a felmérése az továbbra is nagyon fontos. Tehát az, hogy megérteni és belehelyezni magunkat abba az üzleti környezetbe, azokba az üzleti folyamatokba, amit majd szoftverrel támogatni fogunk. Ez továbbra is egy elengedhetetlen része, tehát hogyha így a vízesés modellnek ugye az első részét nézzük, akkor az ugyanígy működik. Utána ugye a fejlesztésben eltérjen a vízesésmodell az, ahol megkapta a fejlesztő a feladatot, elvonult, aztán majd egy idő után visszajött pár hónap, vagy akár hosszabb idő után, és utána szembesült az ügyfél, hogy mit kapott. Ezzel szemben ugye az agilis módszereknél akár hetente, kéthetente vagy havonta, de látja az ügyfél, hogy hol tart a dolog, és tud visszajelzést adni.

Tehát sokkal korábban tud visszajelzést adni és validálni azt, hogy jó irányba halad a dolog. És utána így eljutunk szerintem egy pontosabb eredményhez, mint amikor az elején meghatároztuk, és a végén nézett rá az ügyfél, vagy végén kapta meg a végeredményt.

Ugye azt szokták mondani, hogy baromi nehéz követni úgy valakit, hogyha nem tudják, merre megy. Tehát ezek az üzleti folyamatoknál ugye nagyon sokszor tapasztalom én is azt, hogy folyamatot nem mértünk föl, de ötletünk az van. Nem tudjuk, hogy miért nem működik, de azt meg kell javítani. És akkor itt most mind a kettőtöket szeretném megkérdezni, hogy mit gondoltok a folyamatfelmérésről, mint olyan, mennyire fontos, mennyire nem fontos, átalakított-e az AI agent megold mindent, és folyamatot is föl fog tudni mérni, vagy mit gondoltok erről?

Ennek kapcsán még az kicsit az előzőre is visszakanyarodva gyakorlatilag már a 70-es években észrevették, csináltak ilyen felméréseket, és azóta is viszi tovább, és meglepő módon ez nemhogy javult volna, hanem ugyanúgy még picit erősödött is a Gartner és minden ezt visszajelzi évente, hogy minél nagyobb a projekt, annál valószínűbb, hogy megbukik. Tehát ha fél évnél hosszabb egy projekt, akkor már egy kimutathatóan magas számban arra, hogy ez a projekt nem fog megfelelően hasznosulni, vagy akár el sem készül. Ha belegondolunk, egyéves projekt már simán lehet, hogy már nem dolgozik ott, akik érte, és senki nem fogja tudni, hogy ez a szoftver mire van. Ráadásul már az összes üzleti igény megváltozik, hiszen olyan gyorsan változik az élet, hogy lehet, hogy már rég nem is nincsenek az asztalon azok az elvárások.

Igen, itt a folyamatfelmérés kapcsán azt gondolom, hogy nagyon fontos, illetve nem csak ez a fontos, hanem az, hogy mi úgymond tanácsadóként ezeken a folyamatokon megértve javaslatokat teszünk a változtatásra, tehát hogy újra strukturáljuk ezeket, mert nagyon sokszor az van, hogy nem tudják már az ügyfelek, hogy miért is az a folyamat.

Azért így csináljuk, mert így tanítottak be.

Szokásjog.

Szokásjog, és igazából kialakulhatnak olyan körök, ami tök felesleges egy-egy vállalatnál, és nem veszi észre senki, mert ő csak továbbadja, a következő átveszi, feldolgozza, és gyakorlatilag ilyeneket ki lehet szűrni, tehát hogy ezért fontos az, hogy ezeket a folyamatokat újra is tervezzük, miközben felmérjük és újratervezzük.

Ebből adja magát, hogy ugye akkor, amikor lókod long code platformról beszélünk, akkor egy kicsit van egy dashboardom, összekattintom, mint az AI ügynököt, és hogy akkor egyszer csak működik. De hát hogy kapcsolódik most akkor ide ez a lókódnókód. Tehát, hogy van az egyedi fejlesztés, ahol ott ülnek a fejlesztők, és a lókódnókódban meg egy keretrendszeren van, ahol kattintok.

Hát igen, tulajdonképpen ez is csak egy eszköz, tehát ugyanúgy, ahogy az AI, illetve a lókód és az AI is együtt is megjelent most már. Tehát, hogy a low code-nak az a now code rendszereknek, hogy gyakorlatilag nem kell programozni, ahogy mondtad, össze lehet állítani felületeket, űrlapokat, listákat, portál frontend felületeket anélkül, hogy egy coach-ot leírna az ember. Ez nyilván behatárolja a lehetőségeket, mert amit ott azzal az eszközzel meg lehet csinálni, azt odáig lehet eljutni. Ugye innen jönnek a lókódrendszerek, ahol már ezeket a komponenseket, amiből építkezünk, ezeket testre lehet szabni, lehet módosítani a viselkedésüket, újabb tudást hozzáadni. És hát szerencsés esetben ugye vannak olyan rendszerek, ahol ezeket a komponenseket is lehet szállítani, tehát új komponenseket lehet fejleszteni, és ez azért nagyon kellemes, mert hogyha nincs olyan építőelem, ami szükség lenne, akkor tudsz hagyományos módon csinálni ilyen építőelemet és beilleszteni a platformba.

Tehát hogy ez igazából ugyanazt a célt szolgálja, mint az egyedi hagyományos kódolás, csak itt építőkövekből építkezünk, és ezek az építőkövek ugye leteszteltek, ezek együttműködnek, tehát sokkal kisebb a hibázás lehetősége egyébként. Ezért is gyorsabb, tehát hogy a mi tapasztalatunk alapján háromötször gyorsabb a fejlesztés a hagyományos kódoláshoz képest egy low kód platformon.

Igen, tehát a folyamatból átkötve gyakorlatilag, hogyha kimegy az ember az ügyfélhez, és az üzleti elemző megkérdezi, hogy mi a valós üzleti problémája, tegyük fel, hogy sikerül is elkapni a valós problémát, csinál rá terveket, és visszamenve a kis íróasztalához a UX-es legyárt neki az említett mondjuk figmába, akár vagy bármiben egy rapid prototípust, ahol szépen színes-szagos felületek kattintható, átmegy a következő képernyőre. Az ügyfél látja már az egészet, hogy hogy néz ki. Sokszor ezt egy nap alatt megcsinálja a komplett rendszert akár 50 képernyőt is, és még másnap visszamennek az ügyfélhez, bemutatják, és az ügyfél kérdezi, hogy ez csodálatos, de hát akkor kész is a szoftver, nem? Gyakorlatilag a lókódnokoldat úgy kell elképzelni, hogy ezt picit lassabban is fejlesztő rakja össze, aki érti, hogy a háttérben mi történik, csak ő be tudja mutatni, hogy igenis ez működik is.

Tehát merthogy ez a mögötte az adatstruktúrákat is generálja, nem csak a felületet.

Így van.

Na most ugye itt azért visszakérdezek, ha megengeditek.

Ugye az az állítás, már hogy így ezt látom a hírekben, hogy a lókód és az AI a folyamatokat alapjaiban alakítja át. És hogy szerintetek ez igaz?

Mindenképpen. Azt hozzá kell tenni, hogy az AI többféle módon jelent meg a fejlesztésben. Először, és eleve úgy indult, és ahogy a Koppány ott mai napig is benne van, csak nem túl új modellel, ezért és kontextusablakkal, ezért nem is annyira elégedettek, de gyakorlatilag minden AI egyrészt megjelenik magában a különböző eszközökben, tehát a Figmában is, a Catchem rendszerekben, Photoshop, bármiben, amit nézünk, megjelenik AI támogatás, illetve külön standalon módon is lehet használni AI-t kézi irányítással, illetve lehet olyan is, hogy gyakorlatilag bottal lökdössük és agenteket futtatunk vele. Tehát azt majd megmondjuk az agentnek, hogy te a másik agenteket hogyan programozd föl. Egy architektage-nek megmondjuk, hogy milyen irányvonal mentén noszogasd a backend és a frontendfejlesztő agentet.

És gyakorlatilag a low-code now kód és az AI kapcsolata az már elválaszthatatlan, merthogy egy local nokot platform rendkívül hatékony módon támogatható meg beépített AI-jal.

Lókod és az AI folyamatok azért itt valahol össze is kapcsolódnak van-e olyan terméketek amiket amit használtok vagy amit kifejlesztettetek, ez mind a kettő lehet kérdés.

Igen, itt a Mendix platformnak vagyunk a magyarországi egyik képviselője, illetve fejlesztőkapacitással bírunk ezen a platformon. És itt ugye ebben az évben jelent meg ugye a Mendix AI Assistance Maya, ami ugye tovább gyorsítja ezt a fejlesztési folyamatot, ugye eddig is 3-5-ször gyorsabb volt a hagyományoshoz, és most megjelent ez az AI asszisztens, ez azt jelenti, hogy már a felületeket is, hogy a folyamatokat összerakja egy specifikáció alapján, vagy promptolás alapján, tehát hogy már azt se kell összekattintani, tehát hogy a fejlesztés az mondjuk egy specifikáció leadása után, vagy megismertetése után ott kezdődik, hogy készen van a felület, készen van egy folyamat, és azt validálja a fejlesztő, hogy ezen mit kell módosítani.

Tehát, hogy elképesztő ez a sebességbeli ugrás is.

Igen, igen, tehát az egyik legelterjedtebb platform nyilván a Microsoft erejénél fogva a powerplatform volt, poweros platform, de az nyilván a saját ökoszisztémáját, saját maga felé hajlik a keze, azt erősíti. A Mendix, ez gyakorlatilag a Siemens által fölvásárolt eredetleg ügyviteli, a Siemens tulajdonlása óta már nyilván ipari irányba is elvitt lókódnokot platform, tehát tényleg univerzális, és ellentétben az egyéb gyártók saját ökoszisztémáiba beilleszkedő megoldásaival, ez gyakorlatilag teljesen általános célú megoldásra született, és ezt a piac is visszaigazolja.

Még mielőtt továbbmennénk, van a műsorunkban egy nagyon fontos rész.

Személyes szálnak hívják, és egyáltalán nem kapcsolódik a témánkhoz. Podcaster társam, Személy László a következő kérdést tette föl. Mi az a dolog az életetekben, amit szándékosan nem akartok felgyorsítani?

Hát mondjuk így a szabadidőre vagy a hobbira gondolva, mondjuk a főzés, mert én szeretek főzni, és az egy mondjuk egy vacsorafőzés, az egy nap végén egy egy kellemes lecsengése a napnak, tehát azt nem szeretném felgyorsítani, mert az egy jó dolog azt végigcsinálni, és mindegyik más és más, mert nem receptes könyvből főzök.

Én személy szerint egy hobbit emelnék ki, ahol ezt megpróbáltam és nem sikerült. Gyakorlatilag egy társasjáték tervezésébe kezdtem, amit nyilván ennek megvan a folyamata, tudom is az akadályait. Nyilván nem a naponta a világon megjelenő 200 társasjáték mellé még ez hiányzik pluszban, de hogy ismerem a kereteit, korlátait, van egy világos cél, és ez gyakorlatilag egy hatalmas átgondolást igényel, és azon találtam magam, hogy a végén már AI-jal próbáltam generálni vele dolgokat, és még az architekt múltamból eredő ilyen rendszerszemlélettel próbáltam az egészet így áttekinteni, hogy hogy válik ez szórakoztatóvá az üzleti folyamatok felmérése, hogy mik a döntési pontok, és rájöttem, hogy az egész cél maga, amiért ezt elkezdtem, az evvel kezd megsemmisülni, ha ily módon állok hozzá.

Tehát itt vissza kell kapcsolni abba a sebességbe, amiért eredetileg ezt elterveztem, hogy ez szórakoztatóvá váljon maga a folyamat is.

Hát nagyon érdekes, tényleg, tehát hogy az egyik oldalon bekapcsoltátok, a másik oldalon visszakapcsoltátok, de hogy visszatérve az adás eredeti tervéhez és vissza a gondolatokhoz, hogyan változtatja meg például az ügyfelekkel való ilyen kommunikációt, elszámolást ez a típusú új gondolkodás. Akár az AI-jal, akár a lókoddal.

Igen, megváltoztatja nyilván, mert ugye felgyorsulnak a folyamatok, és múlt heti példa, hogy ugye sikerült leszállítani az ügyfélnek valamit, ami sokkal rövidebb idő alatt megtörtént, mint amit eddig tudtunk szállítani. Tehát amit eddig nem tudom, azt mondta a fejlesztő, hogy akkor most egy hét fejlesztés, azt megcsinálta egy délután alatt. És ezt az ügyfél is nyilván szembesült ezzel, hogy akkor megkapta, tehát tudtunk szállítani. Aztán szóltam a programozó kollégának, hogy nem azt jelenti, hogy most hátradőlhet a maradék négy napra, hanem innentől ez az elvárás, ez lesz az elvárás az ügyfelek részéről.

Igen, hogy mindet holnapra.

Igen, tehát hogy az ügyfél érzékeli ezt, tehát hogy ott majd nem lehet öt napot elszámolni, hanem csak egy felet, amit ezzel töltöttünk. Ugyanakkor majd még hozzá kell számolni azt, hogy milyen költsége van ennek a tokenfogyasztás oldalán, tehát az nem elhanyagolható adott esetben, tehát hogy szerintem ennek a kettőnek az eredője lesz majd, amit az ügyfélnek végül ki kell fizetnie, de valószínűleg ez kevesebb, mint amit eddig fizetett.

Nagyon nehezen lesz így skálázható. Van-e erről már tapasztalat? Tehát integrátor oldalon persze ők megcsináltak valamit és tokent használnak, de hogy ez mennyire váltja ki egyébként azt, amit le kéne fejleszteni?

Maximálisan a probléma, mint korábban említettük, az nem itt van, hanem a kiégési faktorban, de ezt mindjárt ki is fejtem. Ennek kapcsán eszembe jutott az előző történet kapcsán, hogy elhangzott pont, hogy olyan drága már a token költség az AI-ban, hogy lassan újra megérik juniorokat foglalkoztatni. Gyakorlatilag egy fejlesztés úgy történik, hogy a fejlesztő elképzeli, hogy hogy lehet a kódsorokkal formába önteni azt a problémát, amit algoritmizálni kell, és szépen a kis kezével beüti, nem sikerül elsőre, akkor ezt így javítgatja, és ez így megszületik. Ugyanez most AI-jal gyakorlatilag megkéri az AI-tól, hogy milyen megoldásokat különböző utakon, de megkéri, hogy milyen megoldásokat javasol rá, és eldönti, hogy az megfelelő-e, ami rendkívül feszült figyelmet igényel, hogy át tudja elemezni gyakorlatilag a legenerált igen nagy mennyiségű kódot, hogy ez valóban azt fogja-e csinálni, amire ő gondolt.

És sokkal hamarabb elkészül, viszont sokkal nagyobb mentális feszültséget okoz, sokkal nagyobb stresszt, és valójában a minőséget eléri, de lesz egy láthatatlan határ, ahol már nem vállalhatjuk el, nem várhatjuk el senki egy vezető fejlesztő vagy architektől sem, hogy mindent le tudjon ellenőrizni, merthogy az emberi képesség határa, tehát a koncentrációképesség határát már átlépte régen, és efölött dolgozik nap mint nap. Tehát igazából ezt látom én szűk keresztmetszetnek.

Abszolút tapasztaltuk még a low code platformokon is, hogy mivel nem kell olyan dolgokkal foglalkozni, olyan favágó dolgokkal, mert egy csomó minden ott van már, hanem igazából gondolkodni kell és összerakni azokból az építőelemekből, és ez egy folyamatos terhelést ad az agynak, és nagyon gyorsan történnek a dolgok, tehát ezért a nap végére sokkal jobban elfáradnak a fejlesztők.

Ezt meg tudom erősíteni. Én azt szeretném így visszacsatolni, hogy aki soha nem próbálta, hogy milyen AI-jal együtt dolgozni, annak azt szeretném elmondani, hogy egy egyszerű program is a 16. verziónál kezd el mondjuk azt, hogy jól működni, de közben bármennyire pontos a specifikáció, egyszerűen az AI, mivel nem látjuk, hogy mit csinál belül, nagyon sokszor elvesz és hozzátesz olyan dolgokat, amit nem kértünk, vagy korábbi verziókban benne volt, de kivette. És ezt nagyon kevesen látják még, és itt most a következő kérdésem erre ráülve, hogy hogyan fogjátok tudni mérni, hogy mit jelent egy projektnek a sikere?

Ügyfélelégedettség. Tehát valójában a nap végén egy működő szoftvert akar szállítani az ember, ami az ügyfél igényeit maximálisan kielégíti. Tehát én hallottam anno egy ilyen mondást, hogy nem hiszek a szoftver minőségben, mert van gyakorlatilag lespecifikálva egy elváráshalmaz, és ha másképp használjuk a szoftvert, azt nyilván nem fogja teljesíteni, mert nem arra tesztelték le. Tehát itt egy elvárás, egy elsődleges felhasználási eset van, és annak a mellékágai, amire teljesülnie kell a szoftvernek a minőségi mutatói, és hogyha ezt, hogyha az ügyfél ezt át tudja venni, és tényleg az történik, és jól tudja használni, akkor ez egy sikeres projekt. És visszatérve, amit korábban említettem, ugye a minél nagyobb projekt annál kevésbé sikerül.

Itt is ez észrevehető, hogy az adaptáció, tehát soha nem műszaki okokból bukik el szinte egy nagy projekt sem. Azokat meg tudják oldani, tehát kockázati kereteken belül általában szinte kivétel nélkül, nem a NASA-nak fejleszt általában az ember, úgyhogy ezek bevált dolgokat kell implementálni. Gyakorlatilag mindig üzleti oldalon adatminőség, átvételi képesség, tehát a szervezet érettsége. Tehát volt egy érdekes mutató, hogy a TOP 7 technológiai cég kvadránsba belső cégeknél a projektek sikeressége azok méretétől függetlenül szinte 90% fölött volt, és az alatta lévő 90%-nál pedig radikálisan exponenciálisan csökkent. Tehát, hogy a cégben lévő IT képesség az nagymértékben korlátozza, hogy egy sikeres projektet hogy lehet véghezvinni?

A siker kapcsán, amit korábban a Feri említett, ez a háromszög ügyfélelégedettség nyilván, de hogy a másik oldalon az, hogy a költségek ne szálljanak el, tehát hogy azon a büdzsén belül maradjunk, illetve a határidők is, tehát hogy ne csússzon szét a projekt, ezek mind kellenek ahhoz, hogy sikeres legyen, és ugye a minőség, ami nagyon fontos, meg a hosszú távú fenntarthatóságát jelenti, továbbfejleszthető, skálázható, tehát egy olyan, ezek mind hozzátartoznak a sikerhez.

És mi különbözteti meg a fejlesztőpartnert, meg a hosszú távú együttműködésben a jó fejlesztő partnert. Hogy látjátok ezt? Tehát, hogy mi az a kis fűszer a főzésre rákapcsolódva, ami ezt így jó együttműködővé teszi?

Hát gyakorlatilag a jó felelősségű partnert onnan lehet megismerni, hogy az ügyfél ragaszkodik hozzá, és már automatikusan meg is keresi a következő problémáival, és hatalmas fejlesztéseknél ezért is javasoljuk mindig, és ez működni is szokott, hogy egy felmérési projektet végezni már külön az elején, ahol gyakorlatilag egy specifikációt szállítunk a problémájára válaszként az ügyfélnek, amit nem is ragaszkodunk ahhoz, hogy velünk csinálja meg, de mivel bízunk abban, hogy annyira produktívak és szimpatikusak leszünk a hozzáállásunkkal már az ügyfél számára már a felmérés során. Ez már megalapozza azt a bizalmat, hogy nem is akarjon mással ezt kiviteleztetni.

Szerintem az a fejlesztő partner lesz sikeres, aki egyrészt érti az ügyfélnek a működését, igényeit, tehát megtalálják egymással a hangot, illetve itt nagyon fontos egyébként a stabilitás is, tehát hogy mi dolgoztunk olyan partnerrel, ahol a projekt végére mondjuk lecserélődött az összes projektben résztvevő, mondjuk fél éven belül.

Tehát ez nagy probléma, mert ugye nem lehet úgy végigvinni egy projektet, hogy folyamatosan cserélődnek. Tehát hogy mi erre egyébként törekszünk is az Art of Infónál, hogy nagyon stabil csapattal dolgozunk, és a kollégáink nagy része az sok éve velünk dolgozik, együtt dolgozik, és az ügyfél is ugyanezeket a kollégákat látja, és a kollégák meg ismerik az ügyfélnek a történetét is, meg a működésének a részleteit, tehát ez a stabilitás is szerintem nagyon fontos egy partnernél.

Igen, ez egyébként a Delta technológia törekvéseibe, illetve a Delta csoport törekvéseibe is abszolút illeszkedik. Tehát ezért is esett a választásunk erre a szervezetre.

Hogyan egészíti ki az Art of Info és a Delta egymást. Milyen típusú irányok jelentkeztek például a Deltánál, amik változtak az évek során?

A korábbi podcastokban már hallható módon a Delta gyakorlatilag egy infrastruktúra szállítóból nőtte ki magát igen gyorsan, és nem kerülhetjük el azt a transzformációt, ami a szolgáltatások irányába vezet, és ebben a szolgáltatásokban igenis szerepet kell, hogy vállaljon minél nagyobb arányú szoftverfejlesztés is, mert így lesz teljes a kép a különböző hardverek, üzemeltetés, IT security és egyéb széleskörű szolgáltatások mellett. Tehát hogyha a Deltára gondol valaki, és hogy meg eleve már az integrátor szó, ha azt mondja, hogy neki IT-ban szüksége van valamire, akkor A-tól Z-ig le tudja a Delta szállítani ezt.

És milyen típusú projektekben tudjátok a legjobban kiegészíteni egymást? Erre már van-e valami példátok?

Gyakorlatilag bármilyen projektben. Itt ugye most az Art of Infóval beszélgetünk, de más akvizícióink is voltak, amik szépen kiegészítik egymást, de a Delta alapkompetenciája az gyakorlatilag az infrastruktúra mindenestül. Tehát akár irodai fénymásolótól kezdve a szervertermek fölépítéséig, hálózatkiépítésig. És hát a szoftveres oldalt kellett megteremteni.

Mi azt állítjuk, minden, ami fölötte van, és ugye így együtt az egész spektrumot tudjuk szállítani.

A Delta integrátori törekvése ezáltal teljesül, tehát ezáltal ez teljes így a kép.

Nem sok kérdésre maradt már időnk, gyakorlatilag az utolsóra.

Én azt szeretném, hogy egy picit vegyük elő a jósgömböt, és hogy mit láttok az elkövetkezendő, mondjuk öt évre menjünk csak előre, mert mégiscsak informatikáról beszélünk, ahol egy napra előre is nehéz menni. Melyikőtök mit lát a következő időszakra?

Nagyon nehéz jóslásokba bocsátkozni. Ugye itt nagy elődök is óriási bakikat vétettek a jóslások tekintetében. De például az egyik dolog, amin gondolkodok mostanában, illetve felmerült bennem, hogy említettük a Wipe codingot, üzleti felhasználók eszköze, és most 90%-os találattal, vagy igen, találattal működik, tehát el lehet jutni egy 90%-os készültségre, és hogy elérhető-e a 100%, és én azt gondolom, hogy valószínű, hogy el fogja érni a technológia 100%-ot. Tehát ez tovább fogja árnyalni a képet, hogyha tényleg nem technikai tudással rendelkező felhasználók fognak, akár enterprise eszközöket, alkalmazásokat, megoldásokat tudni szállítani.

Igen.

Hát a Himalawi szokták, hogy jósolni elég nehéz, különösen a jövőt. Gyakorlatilag amire én számítókkal lókódnokolt platformok kapcsán, ha már erről volt szó. Ugye pár éve még nem is nagyon bíztak benne, és ez nagyon hirtelen futott föl, és ezt a trendet az AI erősen mellé csatlakozott, és túl is lőtt rajta bőven. Viszont ettől függetlenül nem látszik az, hogy a létjogosultsága megkérdőjeleződött volna. Amire én számítok, hogy a low code nocode platform, így mint kézi fejlesztésű eszköz, majd el fog kopni, hogy nem is kézzel kell már, amit az SE meghagy, hanem kizárólag AI-jal, és ez az AI számára, ami sokat beszéltünk a minőségről, egyfajta minőségi barrier lesz, tehát hogy ez fogja mederbe terelni, hogy mit tehet meg az AI és mit nem, és majd látni fogunk pár ilyen keretet, ami úgymond a minőségi kereteket biztosítja a legenerált szoftverhez, mert az, hogy nagyon gyorsan generálunk valamit, az nem megfelelő.

Nagyon gyorsan kell minőséget generálni.

Sajnos elfogyott a műsoridőnk, nem fér bele több kérdés, lehet, hogy még fölveszünk még egy műsort, mert még marad bennünk egy pár. Nagyon szépen köszönöm, hogy eljöttetek.

Mi köszönjük a lehetőséget.

Köszönöm szépen a lehetőséget.

Kedves nézőink, kérjük, iratkozzatok fel a Digit Podcast csatornáért.