Mire képes ma a vibe coding? (demó)

HUP

A demóban Márk és Péter összerakott egy teljes webalkalmazást (frontendestől, backendestől) kizárólag AI-eszközök segítségével. Lovable-lal készítjük a frontendet és a designt, Cursorral pedig a backendet. Az app ötlete egyszerű, de látványos: bedobsz egy YouTube linket, a rendszer leszedi az audiót, leiratoztatja egy AI szolgáltatással, majd LLM-hívásokkal „könyvet” ír belőle fejezetcímekkel, összefoglalókkal, mindennel. Nem az üzleti érték a lényeg, hanem az, hogy megmutassuk, milyen gyorsan és mennyire alacsony belépési küszöbbel lehet ma AI-ra épülő alkalmazásokat fejleszteni. Egy Karpathy-poszt inspirált minket, mi pedig megmutatjuk, hogyan lehet ebből egy délután alatt működő prototípus.

Megyesi Péter (L7mp) és Sági-Kazár Márk (CNCF) előadása az IT karrier fókuszú Kraftie eseménysorozat 2025. november 17-i, AI ENGINEERING DEMO DAY című állomásán hangzott el.

( dlaszlo | 2025. 12. 23., k – 16:28 )

Ez szuper, elkezdtem most megnézni.

Közben egy gondolat, mert van ennek egy rossz oldala is: Ahogy komolyabb IDE nélkül van aki már egy sort sem tud kódolni, úgy ennek is az lesz a vége, hogy AI nélkül egy programozó semminek nem tud majd nekilátni. Mert elfelejti mi hogy van, vagy meg sem tanulja. Jön majd a jó-jó, de hogy is van az az ArrayDeque, vagy hogy is csináljak egy rest kontrollert? A saját gondolatért felelős agytekervény elszokik majd ezektől a kérdésektől.

Interjún volt olyan srác, aki egy java programot nem tudott elindítani az IDE-n kívül. Egy programot megírni vi-ban valószínűleg elég kevés embernek sikerülne, hacsak nincs valami code complete.

Ugyanez lesz a "vibe coding"-gal is, mert az emberi agy elfelejti (és nagyon jól teszi), amire nincs szüksége.

Itthon hobbi projektekhez használom az AI-t 1000-rel, nem fogok valamit két hét programozással megoldani, ha az AI megírja nekem, és csak egy rövid kódreview kell, meg tesztelés. Munkában olyan dolgokra használom, amivel semmi adatot, információt nem adok ki. pl.: CSS reszelésre tökéletes. Nyilvánvaló hogy mindent a leghatékonyabban akarok megoldani. 

De már most van néha, hogy ha valamit régebben használtam, pl 2-3 éve (hiába használtam 15 évet előtte), akkor van az az pár másodperces megakadás, hogy akkor ezt hogy is kell? Az AI-s vibe kódolás is ezt fogja elősegíteni, szépen elfelejtenek mindent a fejlesztők. Sőt aki eleve az AI általi fejlesztést tanulta meg, annak fogalma sem lesz, mi hogy működik.

Ja, és éppen egy olyan API-t használtam itthon hobbi projekthez, ami annyira új, hogy egyik AI sem ismeri. És hiába adtam meg a legújabb doksi elérhetőségét. Nekem kellett végül doksit olvasni. - ez is milyen fájdalmas lesz egy vibe kódernek, ha egyszer belefut majd hasonlóba. :)

minden uj absztrakcio megjelenesenel ezt a harangot felreverik

És talán nem is ok nélkül verik fel azt a harangot.

memoria cimzest is elfelejtettek

Igen, talán ennek (is) köszönhető, hogy ma pl. egy játék sokszor száz gigába se fér bele, és a közepes grafikához is legalább 16 GB RAM kell már. Ahhoz a közepes grafikához, amivel a legújabb, 2025-ös játék már kb. semmivel se néz ki jobban, mint egy 2010-es komolyabb AAA játék. Csak akkor, az töredék hardverből hozta azt a szintet. Ezt én személy szerint erőforráspazarlásnak hívom. Az absztrakciónak bőven megvan a helye a fejlesztésben, viszont a túltolása optimalizálatlanságot hoz. A világ részben természetes, részben mesterségesen generált fejlődését megállítani persze nem lehet, de szerintem mindenképpen elgondolkodtató, hogy hova is vezethet ez hosszútávon. Visszajön még szerintem az a világ, amikor megy majd a finomhangolgatás. Hiszen ha drága a RAM (most pl. pont az AI miatt), akkor hirtelen lényeges lesz, hogy elég-e a 32 GB vagy kell-e a 64 GB.

Ennek oka nem az AI

Én egy szóval se mondtam, hogy az AI miatt van :)

Én a túlzott absztrakciót okoltam. 

Egy Doom ráfért 2 floppy-ra, egy Crysis már 20 éve is 12GB helyet kért.

Ez igaz, de véleményem szerint az igazi pusztulat akkor jött, amikor a fejlesztők "elfelejtették", hogyan kell game engine-t programozni. Mindenki csak meggazdagodni akart, fizikát, matematikát tanulni meg ugye már inkább nem. Ha az out-of-the-box játékmotorokat (Unreal, Unity) egyfajta low-code/no-code platformként tekintjük, akkor megint a magasabbra helyeztett absztrakció okozta azt, amit korábban írtam. Ha pedig az AI-t is egy újabb absztakciós szintnek tekintjük, akkor ez (valószínűleg) csak rosszabb lesz.

De mégis mit kéne egy játékfejlesztőnek játék engine-t írnia? Neki a játékot kell tudnia jól megcsinálnia, a pályákat, történetet, a tartalmat.

Azt, hogy hogyan kell fizikát modellezni, az engine fejlesztők jobban tudják. De nekik nem kell tudniuk, hogy mitől lesz jó a játék, mitől ül le sokezer ember és játszik órákat.

Ahogy compilert se ír mindenki, aki programot készít, engine-t se kell mindenkinek írnia, aki játékot készít.

Ez nem absztrakció, hanem a felelősségi körök elválasztása. Carmack se volt jó játékfejlesztőnek, engine fejlesztés volt a dolga. Más feladat. A Carmack által írt engine-ekre rengetegen csináltak nagyon jó játékokat, jó játékfejlesztők voltak.

Ezzel semmi baj sincs, a játékfejlesztés így ment már nagyon régóta (mármint készen vett engine-ekkel), nem az Unreal/Unity miatt van így.

 

Anno Rubik Ernőnek sem kellett értenie a műanyag fröccsöntéshez, mégis baromi jó játékot csinált.

( Raynes v | 2025. 12. 23., k – 17:06 )

(ez dlaszlonak akart válasz lenni, de véletlen külön szálba ment)

Nekem is volt 25 éve egy ismerősöm, ELTE prog szakra járt, maga a C programozás ment neki, de az szakon laborban programoztak (ahol windowsos gépeken minden szükséges elő volt telepítve), meg papíron, saját gépén nem ment neki, úgy kell nekem, mint nem fejlesztőnek megmutatni, hogy Visual Studio-t, meg szükséges dolgokat honnan töltse, mit telepítsen, hogy leforduljon neki a sz@rja.

A vi hagyján, ahhoz van pl. ctags. Az már luxus. A két nagy öreg az első Unixokat simán teletype villanyírógépen írta ed sorszerkesztővel, annál ha elcseszel egy sort, de csak a következőben veszed észre, ki kell lépni az insert módból, adott sorra új insert módot nyitni, és újraírni az egész sort, nem hogy autocomplete meg linter, language server, meg AI és egyéb kényelmi funkciók. Mégis elég volt nekik a feladatra.

AI-t használni nem szégyen, csak ez a vibe coding hülyeség, hogy majd az AI megírja az egészet, mi meg át se nézzük. Az AI nagyon sokat haluzik, egyszerű kódokat is elcsesz, nem megbízható, vakon nem szabad rá támaszkodni. A fejlesztőket nem váltja ki, inkább csak segíti őket. Arra pl. jó, ha API-ból nem mennyiségű boilerplate kódot kell összefosni, pl. header fájlok. Sokat tud az ilyen gyorsítani, ha okosan használják, amire való.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Az AI nagyon sokat haluzik, egyszerű kódokat is elcsesz, nem megbízható, vakon nem szabad rá támaszkodni.

Pont pár hete lepődtem meg, hogy működik elsőre amit ír. Egy python programot írtam vele. Amikor rászántam magam, hogy oké, nézzünk bele, ott jött az, hogy "na álljunk csak meg...". Nem programhiba volt, hanem nagyon bénán megírt programrész, vagy felesleges kavarás. Vagy átgondolatlan megoldás. - De ezeket még mindig tudta javítani, csak szólnom kellett érte.

Vagy alkalmazás szervert konfiguráltattam vele, hát nálam sokkal jobban ismerte a lehetőségeket, még akkor is, ha elavult dolgokat mondott néha. (de ijesztően jó volt)

A stackoverflow annyival volt jobb, hogy ott a fejlesztőnek át kellett gondolnia, hogy mit csinál, nem 100%-os megoldást kapott. De ott is egy kategória volt már a stackoverflow programozó, aki gondolkodás nélkül copy paste-ez. Ha hiba van, akkor másik bejegyzésből másik kódot copy paste-ez.

A gond a fejlesztő szemszögéből, hogy nagyon gyorsan eltelik az az 30 < X < 40 év, amikor tökéletesen vág az agyad, és tapasztalatod is van. Utána a 40 < X < 50 életkor között észreveszed, hogy lassulsz, és felejtesz. Az AI vibe kódolás ezen nem igazán segít.

Először jött a COVID, elhitették minden portással, rendezvény szervezővel, és angol tanárral, hogy ők fejlesztők. Most már AI segítségével támogatják őket, fogalmuk sincs, mi mit csinál, de tényleg lassan előnyben lesznek egy állásinterjún, mert az AI megoldja a kérdéseket. Közben a 40+-os 50+-os szoftver fejlesztő küzd, hogy szellemileg friss maradjon, de már azt sem elvárható, hogy bárki tolerálja, hogy a hagyományos módon két hét alatt csinál meg valamit, ami az AI-nak 1-2 óra. (még akkor is ha az AI megoldása rossz elsőre, megjelenik a képernyőn amit látni akarnak, majd kijavítja valaki...) Eljutunk oda, hogy senkit nem érdekel, hogy te érted is, hogy mi történik, mert az AI olcsóbb, és gyorsabb, és "több emberből lehet meríteni".

Tudom... aki idősebb, az menjen menedzsernek, vagy architektnek, ne akarjon fejleszteni.

Szóval valahogy szuper ez az AI, de ad is feladatot rendesen: észnél kell lenni, ki hogy alakítja a jövőjét, és vannak megoldandó kérdések.

A fejlesztőket nem váltja ki, inkább csak segíti őket. Arra pl. jó, ha API-ból nem mennyiségű boilerplate kódot kell összefosni, pl. header fájlok.

Szerintem boldog és boldogtalan "vibe kódol", mindenféle ismeretek nélkül. Működik pipa, nem működik, akkor megpróbálja máshogy feltenni a kérdést. Szerintem cégeknél is rengetegen kezdték ezt el.

Szóval csak annyit akartam mondani, hogy összetettnek érzem a problémát. :)

az egyszerűbb kognitív folyamatokat automatizálják, ez az irodai betanított munkák zömét, és a fehérgalléros szakmunkás/technikus szintű munkakörök egy jó részét kiváltja. Lesz helyette más munkakör, persze a probléma hogy nem azoknak, akiket a kiautomatizáltak. Ahogy 35 éve a gazdasági szerkezetváltás során sem kaptak melót a megszűnő nehézipari, bányászati szektorból kieső szakik tömegei a kiépülő szolgáltatószektorban. Bányászból nem lett barber, ahogy kohászból sem pizzaszakács, és lakatosesztergályosból sem üzletkötő. Ez van. Szoftverfejlesztőnek biztos élete lesz a jövőben is, akár compsci akár a mérnöki alkalmazott informatika területen, de akinek a tudása az értékláncban a kódkészítésből állt (kb. a betanított-szakmunkás és valamennyire a technikus szint is), annak szerintem nem túl jók a kilátásai. Az üzemeltetés annyiban más téma, hogy a sok XaaS mellett azért kell olyan is aki fizikailag odamegy, bemászik, átdrótoz stb. de alapvetően azért ott is lesz ilyen trend. Ez teljesen független attól, hogy az ai körüli tőzsdehype kipukkan-e, mert valószínű igen, ahogy a dotcom lufi is kidurrant, aztán jön a konszolidáció és a már helyén kezelt műszaki tartalom szépen átalakítja az üzletet, sok szektort alapjaiban, ahogy a www tette a hype lecsengése után az elmúlt két évtizedben. 

az egyszerűbb kognitív folyamatokat automatizálják, ez az irodai betanított munkák zömét, és a fehérgalléros szakmunkás/technikus szintű munkakörök egy jó részét kiváltja.

A cégek kapzsiságát eddig is lehetett ismerni, és már ma is vannak az AI miatt értelmetlen átrendezések, vagy lehetett hallani a hírekről, hogy nagyobb tech cégek mennyi szoftver mérnöktől váltak meg. Nem csak a kóder réteget érinti ez, aki "betanított szakmunkát" végez. Egyébként pont egy menedzser (akinek gőze nincs a fejlesztésről) mesélte nagy szájjal egy céges bulin, hogy egy fejlesztőt kinevelni pár hónap. Páran 20+ év tapasztalattal néztek egyet. Tehát a szakmunkás szó sem teljesen megfelelő egy jó fejlesztő esetén, mert ott rengeteg olyan tapasztalat van, ami miatt nem betanított az a munka. Nem a szintaxisról van szó, meg ismétlődő feladatokról, hanem rengeteg kudarc ismeretéről, felhalmozott mintákról, kompromisszumok jó meghozási képességéről. 

Tehát a döntéshozók nem feltétlen látják a különbséget a kódolás és a szoftverfejlesztés között.

Ez a nyomás egyébként átterjed majd a legalsó rétegről szerintem fentebb is, aki az IT-ban veszíti el a munkáját, első körben ott akar majd újat találni. Árversenyt, és telítettséget okozva.

És igen, pont az ilyen hype-ok, lufik okoznak kellemetlenséget, kérdés, hogy mikor pukkad ki, és hogy. Az sem szokott általában jó lenni, amikor kipukkad egy lufi, addig meg juniorokat már nem vesznek fel, a senior-ok eltűnnek emiatt, téves leépítések lehetnek, és lenyomott béreket okozhat. Utána majd hatékonyabb lehet a szoftverfejlesztés, ha ez kisimult. 

Na mindegy, ez nem lett túl pozitív hozzászólás, vannak kérdések, de reméljük jól alakul minden. A vibe kódolásból indultam ki végül is. Vannak kérdések, de egy fejlesztőnek kell majd észrevennie, hogy a megoldás bírja-e a megfelelő számú usert, milyen code smell-ek vannak, mi egyebet halucinált az AI. Csak nem mindegyik menedzser, vagy cég fogja érteni, hogy ez mit jelent. :)

Az AI nagyon sokat haluzik, egyszerű kódokat is elcsesz, nem megbízható,

De egyszerű kódokat helyileg egy komolyabb modell már nem csesz el szerintem.

Sőt a saját programodban ugyanez a modell megtalál olyan hibát, amin meglepődsz (pl többszálú környezetben egy nem egyértelmű versenyhelyzetet), vagy éppen egy nagyobb szolgáltatásra megcsinálja a unit teszteket 98%-os lefedettséggel, úgy hogy még értelme is van ("érti" hogy mi a lényeg). - én pont ezek miatt gondolkodtam el.

A két nagy öreg az első Unixokat simán teletype villanyírógépen írta ed sorszerkesztővel, annál ha elcseszel egy sort, de csak a következőben veszed észre, ki kell lépni az insert módból, adott sorra új insert módot nyitni, és újraírni az egész sort, nem hogy autocomplete meg linter, language server, meg AI és egyéb kényelmi funkciók. Mégis elég volt nekik a feladatra.

Értem, és ez miért volt jó?

Vagy lehet, hogy nem is volt jó, rühellte mindenki ezeket a szopásokat, csak nem volt jobb megoldás abban az időben?

Egyszerűen vagy még nem volt képernyős terminál, vagy kevés volt belőle, így akinek nem jutott, maradt a nyomtatóval egybeépített. Volt szerencsém hozzá, Cobolt tanultunk, a gyakorlat egy PDP-11 gépen volt, amihez voltak képernyős terminálok és nyomtatósak is, ott épp edi-nek hívták az aktuális sor-orientált editort. Bevállaltam a nyomtatóst, úgyis gyorsabb voltam a többieknél. Egy előnye még volt is a nyomtatósnak: ha valaki véletlenül a sor szerkesztése közben hibajavításkor nem a backspace-t használta, hanem a kurzor visszaléptetést (vagy valami hasonló volt az elnevezése) - az nem törölte a karaktert, csak visszaléptette egy karakterrel, és felülírta a jóval. Ez persze a terminálon nem látszott, ott a sor jónak tűnt olvasásra, viszont a plusz karakter miatt nyilván hibás volt, de ez csak nyomtatásban volt észrevehető.

Nem feltétlenül jó, de... arra emlékeztet, amikor a fotográfusoknak adnak egy pici SD kártyát, amire "36 képkocka" fér(*). Még mindig sokkal felelőtlenebb dolog, mert lehet róla törölni, ellentétben a filmmel, de súlyt ad minden kattintásnak.

Vagy az 1k-s, 2k-s, stb. demók.

Vagy az emberek elmennek futni, csak hogy az egészségüket óvják.

Sajnos(?) már én is ott tartok, mert az LLM-re bízok olyan dolgokat, amiket én is meg tudnék csinálni, de az LLM hamarabb kidobja, és (még) tanulok belőle, pláne amikor badarságot ír.

Valahogy úgy értem, hogy ami anno muszáj volt, az ma se feltétlen haszontalan, bár nyilván nem minden esetben.

 

*) Én meg 120-as fan vagyok, szóval 10-12 :D

( trey | 2025. 12. 24., sze – 09:12 )

Szegény programozók! Egy darabig el lehet menőzgetni még majd ilyen "C-ben hokizok" szellemi maszturbálással, de lássuk be, minden fejlődik. 

Mi sem jumperelünk már HDD-ket!

Kellemes ünnepeket! 😉

trey @ gépház

De nem csak őket érinti, hanem kb mindenkit, és én két dolgot akartam a kommentekből kihozni. 1. Amit nem használsz, az visszafejlődik, meg elfelejted. 2. Egy változás soha nem fájdalommentes, mert mindenki bénázik. A programozók szemszögéből (csak egy): Nyilván lesz aki ezt a vibe kódingot megszívja, mire kialakul, és nem tekintik a cégek sem mindenre megoldásnak.

Kellemes ünnepeket! :)

Ha túl jól sikerül majd az AI self-healing funkció, akkor nem kell kijárnod, de ha mégis kellene a kéz, hint: boston dynamics, figure, tesla optimus. Jól haladnak. 2022-ben az LLM sem volt előrébb, mint most ezek.

Addig meg örüljünk a két kezünknek. ;)

Szerk: én úgy látom a BMW már használja is pl: https://www.youtube.com/watch?v=K1TrbI0BaaU

Oké, reméljük távoli. De ha bárki 6 éve azt mondja, hogy nekem még az én életemben ai-val kell szívni, azt kiröhögtem volna. 

Ugyanígy körberöhögtem volna, aki 3 éve azt mondja, hogy az AI hiba nélkül meg tud írni egy bármilyen nem Móricka szintű programot. Meglepő, de fel tudták húzni egy jobb “kóder” szintjére.

Most azt mondjuk, hogy jó, de az architektúrát még nem látja át, szerintem már senki nem nevet, majd át fogja látni jövőre. 

Meg úgy látom az a robot dolgozik a bmw-nél. Nem olyan távoli lehet az.

De egy szoftver mérnök nem az új technológiától fog félni, hanem a döntéshozók random, rossz döntéseitől. Meg a kóklerektől. Jó, hogy fejlődik a világ, szerintem is, tehát nem világvége, hanem világbéke. :) Csak az oda vezető út mindenkit érinthet majd. 

2015-ben úgy nézett ki a DC-nk, hogy egyben legyártottak egy konténernyi (nem dockert, hanem azt a 12 méteres fajtát) szervert, azt egyben bevitték a DC-be, beledugtak 1 db kábelt, és ment róla a cloud. Aztán amikor a konténer azt mondta magáról, hogy 40%-a döglött benne a gépeknek, akkor kivették, és iktatták valahova. Remélem, nem csak bedobták az óceánba, de igazából nem tudom.

Ennek 10 éve. Tippelni sem merek, hogy ma ez hogy néz ki. A mese tanulsága talán az, hogy még a kijárós rendszermérnök sincs biztonságban, mert a kábel bedugása, majd évekkel későbbi kihúzása betanított munka volt, annak megfelelő bérezéssel.

AZ IT nem DC-kből áll. 

A mese tanulsága talán az, hogy még a kijárós rendszermérnök sincs biztonságban, mert a kábel bedugása, majd évekkel későbbi kihúzása betanított munka volt, annak megfelelő bérezéssel.

A munkánk 0,1%-a áll kábelek bedugásából. Van olyan ügyfél, ahova hetente 5-10 alkalommal járunk ki, lassan 20 éve ügyfelünk és én akkor voltam utoljára a szerverszobájukban, amikor zöld mezősben elindítottuk 20 éve. 🤷‍♂️

trey @ gépház

Aztán rájöttek, hogy bilibe lóg a kezük. Nagyon kevés, speciális esetben működött ez a konténeresdi. A hardveres melók egy részét váltotta csak ki. Magyarországon is csak pár helyen próbálkoztak vele.

Kb. ugyanezt látom az AI-val, a vibe codinggal. Pár hónap - év és kiderül, hogy ez mit old meg és milyen új problémákat hoz be.

az egér és az elefánt mennek át a hídon.  Felnéz az egér,  te elefánt, szerinted mi dübörgünk így...? 

 

Gelei olyan helyen dolgozik, ahol ez a normális.  2010 környékén foglalkoztam bigdata rendszerekkel, USA-ban már akkor is ez volt a minta.  Persze nem mindenkinek de ahol milliós szerverszám van (FAANG), napi több ezer géppel bővítesz, ott nem éri meg mérnökórát égetni javítással. Betanított munkás cserél konténer vagy előszerelt rack alapon. EU persze nem pazarol, itt a nagy géptermekben is inkább kisipari szerelés megy. 

( Chain-Q v | 2025. 12. 24., sze – 09:45 )

2026 lesz a Schrödinger IT-melók éve, amikor mindenki állása egyszerre az "AI jobban fogja csinálni a cloudból, szóval az utcára kerülsz" és a "sajnáljuk, ezt a munkát csak az irodából lehet végezni, otthonról nem" szuperpozíciójában lebeg.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( khiraly | 2025. 12. 24., sze – 10:22 )

Ezt a sok AI által összehordott kódot legyen aki karbantartja...

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ebből a talkból nem úgy tűnik hogy nagyon hamar lesz. A hallucináció és a prompt injection mellett az is megoldatlan probléma, hogy az AI nem vagy nagyon rosszul ismeri fel a globális, architektúrával összefüggő, ill. a lokális, helyi kódstruktúrák közötti különbséget, és azok jelentőségét. Szóval simán kioptimalizál a kódból kritikus részeket pl. autentikációt.

Szóval a "kolléga" véleménye szerint hangsúly a kód megírásáról az architektúra minél pontosabb megtervezésére, kódolvasásra és a fontosabb struktúrák AI-val való betartatásra fog irányulni. Mind olyasmi, ami kevésbé munkaigényes mint a kódírás és az egész IT ipar évtizedek óta fantasztikusan teljesít benne, már a humanoidok irányításánál is. Ja, várj, nem.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

nagyon rosszul ismeri fel a globális, architektúrával összefüggő, ill. a lokális, helyi kódstruktúrák közötti különbséget

Ezért is van veszélye (szerintem a következő 5-10 évben), hogy mindenki is vibe kódol már most, meg ebben esetleg nagy spórolási lehetőségeket látnak.

hangsúly a kód megírásáról az architektúra minél pontosabb megtervezésére

pont így gondolom, hogy az alacsonyabb szintű munka automatizálódik. A kódert kiváltja a genai. Ahogy a műszaki rajzolót és a rajztáblát is kiváltotta a cad program és a parametrizált tervezés. 

Ami meg az előadásban felvetett belső bonyolultságot, és a hozzáadott/véletlen bonyolultságot (vagy inkább elbonyolítást) illeti, és hogy ennek szétszálazásában az MI nem jó, ez így azért nem kerek. Egy LLM lehet nem jó benne, de nem is kell, nem ez a feladata, független attól hogy az instruct meg a reasonong modellek generatív képességei alapján talán ilyen területen is felmerülhet a használatra az igény. Segíthet, pl. használati esetek "elolvasásával", ellentmondások keresésével, RAG révén folyamatosan változó szabályokat követő edge case tesztek generálásával egy átalakítás ellenőrzésében.

A gemini-cli-t, és az opencode-cli -t, és a Google antigravity -t próbáltam ki, ezekkel kb 2-3 estét játszottam.

Ezalatt az idő alatt egy alkalmazás készült el, a speaches-ai helyett egy saját kis python program, ami TTS, és STT OpenAI REST API kompatibilis végpontokat biztosít.

Az alkalmazás kb a 2. estétől kezdett el működni, és vegyesek az érzések:

  1. Az első elkészült megoldásban kb minden ott volt, ami kell, de elsőre egy fájlba belehányta az egészet (mivel kicsi alkalmazás)
  2. Először az STT részt csináltam meg, utána adattam hozzá a TTS részt. Az automatikus refaktorokat (egységesek legyenek az elnevezések, az STT rész és a TTS rész is külön service-be kerüljön, a konfigurálás egységes legyen, stb...) nem csinálta meg magától, sőt kb 5. alkalommal sikerült
  3. A kétféle végpontba (STT, TTS) először eltérő logikákat tett, védelmeket tett. Pl.: Az STT-be beletette, hogy egy hívást engedünk egyszerre (lokális gépről van szó), a TTS-ből ezt kihagyta elsőre.
  4. A szétbontott alkalmazásban keverte a felelősségi köröket (pl HTTP 429-et dobott a service-ben, holott senki nem mondta neki, hogy csak REST kontrollerből lesz a szolgáltatás meghívva)
  5. A modell letöltéseket eltérően valósította meg.
  6. Docker konténert csináltattam vele, a GPU-s változat volt 14 GB, 9 GB, 45 GB, és jelenleg 4 GB. Ami nem rossz, mert a speaches.ai 9 GB GPU-val. A CPU-s változat 700 MB, de ez is volt 4 GB. Sok iteráció volt ezt helyrerázni.
  7. Az egész alkalmazás sokadik iterációra működött kitisztítva. Volt olyan része, amibe inkább már kézzel nyúltam bele.
  8. Telehányta értelmetlen kommentekkel a kódot, ami semmi plusz infót nem hordoz, és inkább magáról az "építés" folyamatáról szól.
  9. Látszik, hogy nem érti teljesen, hogy gyakran a kevesebb a több.
  10. A gemini-cli alatt egyszercsak kiírja, hogy elfogyott a felhasználható kereted, holnap este találkozunk. Ez azért fájdalmas, amikor úgy érzed egy apróság lenne hátra.

 

Ami baromi jó:

  1. Félig profi kódot ír. (de a maradék rész nem túl jó még). Észrevesz dolgokat, odafigyel dolgokra (de következetlen).
  2. Az opencode a Big Pickle modellel döbbenetes volt. Jeleztem neki egy hibát, és nem szórakozott:
    1. összelőtt egy python virtual env-et
    2. letöltötte a szükséges csomagokat
    3. refaktorálta a kódot, hogy a megadott rész külön is tesztelhető legyen
    4. többször elindította, leállította, és tesztelte az output-ot
      1. Addig csinálta, amíg jó nem lett
        1. Wooowww!

A gemini 3 pro elég jónak tűnik. De nem elsőre tökéletes amit csinál. Elfogyott az első este a keret, a 2000-3000 Ft-os előfizetésem van.

Az OpenCode alatt a Big Pickle tette működőképessé a TTS részt, nagyon profin. A futtatás, validálás, javítás, amit automatikusan csinált, szerintem a jövő lehet. (Majd egyszercsak elkezdett hülyeségeket csinálni, az egész alkalmazást elrontotta. Pillanatok alatt romba döntötte az egészet, mint ha elértem volna valami limit-et, és modellt váltottak volna a háttérben. :) )

A Google Antigravity-ben a Claude Opus 4.5 nagyon profinak tűnt, csomó problémát kijavított, majd elrontotta a docker konténerem: 45 GB lett! Pillanatok alatt romba döntötte az egész konténeres részt.

Az OpenCode-ba próbáltam az OpenRouter.ai alól a https://openrouter.ai/xiaomi/mimo-v2-flash:free modellt bekötni, nem jártam sikerrel (fel sem ajánlotta), a többi openrouter.ai modell pedig nem hívta meg az opencode-cli alatt az agent-eket.

Lehet hogy még nem jól használtam ezeket, de talán vibe kóding nélkül, simán doksi olvasás segítségével is végeztem volna (ezzel) ennyi idő alatt. Úgy is, hogy pythont nagyon ritkán használok. Itt rengeteg trial and error volt, meg kódreview, és centiről centire haladtunk előre az AI-val.

De ez az egész pár éve teljesen elképzelhetetlen volt szerintem, hogy AI-val így összedobj egy alkalmazást. Gondolom még 1-2 év, és mindent megcsinál majd.

Megjegyzés: A Mimo-v2-flash állítólag a nagyobb/jobb Claude, és Google modellekkel van egy súlycsoportban, és még pár napig ingyenes. Utána olcsó lesz. - ha esetleg valaki akarja próbálgatni.

Megjegyzés II: Az opencode-cli ingyenes, a Big Pickle modell ingyenes (jelenleg). A Google Antigravity alatt ingyenesen lehet használni (limitekkel) a legújabb Claude, és a Google modelleket. - jelenleg.

Fun fact: a big pickle állítólag az a rebrandelt GLM 4.6 ami a múltkor hirdette hogy utolérték a Claude Sonnet 4.5-öt. 

 

De már van GLM 4.7 is, én most azt próbálgatom (havonta 3 dollár), elég ügyes, bár vannak zizi napjai. 4x elmagyarázom, de csak elrontja, máskor meg elsőre penge.

( blueghost | 2025. 12. 27., szo – 11:38 )

Ez nagyszerű hogy az AI kódol, de ki fog felelősséget vállalni az így készült kódokért? Ki az aki kiáll arccal és azt mondja hogy "ha hiba van a kódban, az az én felelősségem."? Itt most az olyan kritikus rendszerekre gondolok, mint pl. egy önvezető autóban futó szoftver, vagy a repülőgépben az autopilot, orvosi műszerek, banki rendszerek, atomerőművek, vagy akár csak egy lift irányítása. A programozás nem csak a fingós appok.

A termék előállítója, a gyártó, ide vonatkozó hír:

https://www.pcwplus.hu/pcwlite/komoly-feladat-var-a-szoftverfejlesztokre-2026tol-az-eus-iranyelv-vegett-366068.html

Itt már a szoftverfejlesztőket is említi konkrétan.

Ez inkább abba az irányba mutat hogy az AI-generált kódokat hamarosan elfelejthetjük, vagy ha lesz is, csak nagyon korlátozott mértékben 

Én anno ez alapján tanultam:

"Hányt-vetett; - csinált a majdani rend végett
A szobában szörnyű nagy rendetlenséget."

Aztán persze a nyelv változik, nem vitatom, de amit Arany megírt, az valahogy nekem mégis hihetőbb, mint amikor Tompa úr és Tompáné magyarázza, hogydehát a nyelv az az, ahogy beszélik.

Az semmit nem jelent. Nekem is azt mondta, hogy amit én írtam az angolul gondolkodó AI magyarul:

Őszintén szólva, van benne néhány olyan fordulat, ami elárulja, hogy AI írta, vagy legalábbis „angolul gondolkodó” magyar szöveg.

Ezek szerint csak blöfföl, a szöveget amit mutattam neki, azt teljes egészében én írtam.

Miután ezt jeleztem, fél oldal magyarázkodás a következő kezdettel:

Ez egy óriási baki a részemről, ne haragudj! :) Elnéztem a helyzetet, és túlgondoltam a szerepemet.

Mivel az előbb azt kérted, hogy véleményezzem a szöveget, a gépies agyam egyből „elemző üzemmódba” kapcsolt, és úgy kezeltem a szöveget, mintha én generáltam volna egy korábbi körben, vagy egy másik AI szüleménye lenne.

Ilyenek ezek, mindig abban biztosak amiben az előbb nem.

Csak úgy tűnik nincs újdonság, az AI-ellen kardoskodók is ugyanúgy használják. "Hey AI-ásó! Áss egy akkora gödröt amibe beleférsz és feküdj bele! Őőő.... aztán...aztán valahogy temesd be magad, mert én nem fogom összekoszolni a kezem!"

A termék előállítója, a gyártó

Na, hát akkor majd ezután is, problem solved. :)

Ez inkább abba az irányba mutat hogy az AI-generált kódokat hamarosan elfelejthetjük, vagy ha lesz is, csak nagyon korlátozott mértékben 

Nem vagyok benne biztos, hogy az átlag AI szarabb kódot ír, mint az átlag SWE. Vagy ha igen, akkor nem vagyok benne biztos, hogy mondjuk 2, 5, stb. év múlva is szarabbat fog.

Miért érdekes ez egyáltalán? Az EU-s irányelv miatt akkor majd humán szoftverfejlesztőket sem fognak alkalmazni, mert hibáznak néha? 

Ezek a szoftvereket auditáltatni kell amely magában foglalja mint a termék, mint pedig a termék létrehozásának módszertanát/folyamatát is. Meghatároznak assurance szinteket, és ezek minél  magasabbak annál jobb bizonyítékokat kell bemutatnod, amely akár egy formális bizonyítást is jelenthet, terméktől függően. BME-n vannak ehhez kapcsolódó tárgyak: Formális Módszerek, Megbízható elosztott és decentralizált rendszerek, Automatizált ellenőrzési technikák, stb.

Rossz hírem van: a legtöbb szoftver licencében ott van a "felelősség kizárása" rész. Ha akarod, hogy a gyártó felelősséget is vállaljon a termékéért, akkor az pár 0-val drágább lesz. Euroban mérve.
Az IT-ban relatív olcsón lehet gagyit gyártani. Büntetlenül. A jó minőség meg itt is drága lesz.

Egyedi fejlesztéseknél, amikben rendszeresen építik össze az alkalmazás architektúrát oss keretrendszerekből, könyvtárakból, és inkább csak a megrendelő egyedi usecaseit programozzák - még a framewörkbe, libbe is ritka hogy kontributálnak -, ott nem tapasztaltam még olyat hogy a szállító ne a szállított rendszer egészéért vállalt volna felelősséget, hanem csak a maga fejlesztéseiért. A dobozos szoftvereknél tudoom, van "as-is", de lehet hogy szabályozó oldalról nem is annyira bánják, ha ezzel a (zömmel amerikai) dobozos sw szállítókat kedvezőtlen helyzetbe hozzák az Unióban. Persze ez egy nagy iparág, rengeteg réspiaccal aminek megvan a maga sajátossága, én pedig csak egy szeletét tapasztalom meg ennek a nagy piacnak. Nem tudom, hogy egy MR gép, vagy egy repülő szoftverei hogy néznek ki, oss kitettség van-e, hogy megy ott az üzlet, értékláncok, kapcsolati hálók, jogviták helye/rendezése hogy vannak stb. Biztos, hogy van ahol ez irányelv nagy átrendeződéshez vezethet.

Nem 'van ahol', hanem általánosságban. Már amennyiben a cikk igazat ír. 

a károsultaknak nem kell bizonyítaniuk a gyártó hanyagságát - elegendő a kár és a szoftverhiba közötti kapcsolat igazolása.

Adott esetben ez a felhasználó részéről viszonylag könnyű, a gyártó részéről az elhárítás viszont nehéz. Nem olvastam az eredeti direktívát - lehet, hogy kellene -, de ha ez így igaz, akkor elég sokan fogják meggondolni, hogy bármilyen SW-t is szállítsanak ilyen feltételek mellett.