A vibe coding ma már nem elvont technológiai fogalom: vak fejlesztők valódi, piaci értékű alkalmazásokat hoznak létre AI segítségével, nulláról. A Double Tap podcast legfrissebb adásában Michael Babcock, ismert nevén Mickey B, végigvezette a hallgatókat azon a folyamaton, amellyel megalkotta saját iOS podcast-alkalmazását. Az út olykor meglepő fordulatokat tartogat, és olyan részleteket, amelyek nemcsak vak fejlesztők számára relevánsak.
—
Mi az a vibe coding, és miért érdekes most?
A „vibe coding” az elmúlt évben terjedt el széles körben: olyan fejlesztési módszert jelent, amelyben a fejlesztő természetes nyelven fogalmazza meg az igényeit egy AI-rendszernek, és az AI generálja a tényleges kódot. Hagyományos programozástudás nem szükséges hozzá.
Michael Babcock ezt nem elméleti szinten közelíti meg. Hónapokkal ezelőtt egy vasárnap ülte oda magát, hogy megoldjon egy konkrét, személyes problémát: az általa hallgatott óránkénti hírpodcastok ugyanazokat a sztorikat ismételgették nap mint nap, és ő szerette volna automatikusan kiszűrni a 48 óránál régebbi epizódokat. Ilyen funkció nem létezett a piaci podcast-alkalmazásokban. Ezért megcsinálta.
Az eredmény az Earshot nevű iOS-alkalmazás, amelynek a cikk írásának időpontján körülbelül száz bétatesztelője van a TestFlight platformon, és a fejlesztő a közeli App Store-megjelenést tervezi.
Babcock hangsúlyozza: mielőtt elkezdte a projektet, soha nem írt egyetlen sor iOS-kódot sem. Nem ismerte a Swift nyelvet, nem hallott a Flutter keretrendszerről. Amivel rendelkezett, az a precízen megfogalmazott probléma volt – és egy AI, amelynek el tudta magyarázni.
A folyamat során Babcock arra is rájött, hogy a vibe coding nem csupán tömeges felhasználásra szánt termékek készítésének eszköze. Saját csapatának például egy naptárütemező eszközt épített, amely automatikusan elküldi a napi programot – megelégelte a kézi másolás-beillesztést és az emberi hibákat. A program kezdetben csak terminálból volt elérhető, majd egy grafikus felületet kellett köré építeni, mert a munkatársak nem tudtak parancssori utasításokat futtatni. Ez az egyszerűnek tűnő lépés önmagában újabb tanulási folyamatot jelentett.
—
A PRD: az alap, amely mindent meghatároz
Az egyik legfontosabb fogalom, amelyet Babcock bevezet, a PRD – Product Requirements Document, vagyis termékkövetelmény-dokumentum. Nem titokzatos szakmai műfaj: lényegében egy részletes, strukturált leírás arról, hogy a tervezett szoftvernek mit kell tudnia, milyen problémát old meg, és hogyan kell viselkednie.
A módszert Babcock a BITS (Blind Information Technology Solutions) programozási kurzusán sajátította el. A folyamat, amelyet aztán alkalmazott: összegyűjtötte az összes igényét és elvárását, majd átadta a Claude AI-nak azzal az utasítással, hogy tegyen fel egy kérdést egyszerre, és segítsen összeállítani a dokumentumot. Két-három nap kérdezz-felelek után állt elő az a .md (Markdown) fájl, amelyből az Earshot fejlesztése elindult.
A végső termék azonban jelentősen eltért az eredeti PRD-től. Babcock eleinte cross-platform megoldásban gondolkodott: egy appot akart, amely egyaránt fut iPhone-on és Androidon. A Flutter keretrendszer kézenfekvőnek tűnt – aztán kiderült, hogy az egyedi VoiceOver-akciók dinamikus újrarendezése Flutterben technikai korlátokba ütközik: a változtatások csak az alkalmazás teljes újraindítása után lépnek életbe. A projekt ezért SwiftUI-ra váltott.
Ez az átállás nem volt fájdalommentes: a bétatesztelők podcast-adatai elvesztek. Az eset rávilágít arra, hogy a vibe coding sem varázspálca – a döntéseknek következményei vannak, és az újrakezdés időbe kerül.
A PRD-módszer tanulsága ennek ellenére egyértelmű: minél pontosabban fogalmazzuk meg, mit akarunk, annál jobb eredményt kapunk. AI-alapú környezetben ez különösen meghatározó.
—
Akadálymentesítés alapból, nem utólag
A vibe coding egyik visszatérő kritikája, hogy az AI által generált kód sokszor figyelmen kívül hagyja az akadálymentesítési szempontokat. Babcock megközelítése erre rendszerszintű megoldást kínál.
A Claude AI-ban lehetőség van CLAUDE.md konfigurációs fájlokat beállítani – ezek olyan szabályok, amelyeket az AI minden munkamenetben figyelembe vesz. Babcock a saját fejlesztői környezetét úgy állította be, hogy bármilyen felhasználói felületet érintő változtatásnál a Claude automatikusan átadja a kódot egy akadálymentesítési ügynöknek. Ez ellenőrzi a WCAG (Web Content Accessibility Guidelines, vagyis webes akadálymentesítési irányelvek) előírásainak való megfelelést, a gombok feliratait, a kontrasztarányokat és egyebeket – mielőtt a változtatás bekerülne a projektbe.
A rendszer alapja a community-access.org weboldalon elérhető anyag, amelyet a vak és gyengénlátó közösség állított össze. Az integrálás maga is AI-alapú: elegendő megnyitni a Claude-ot, megadni a webcímet, és megkérni, hogy telepítse az akadálymentesítési ügynököket.
Ez alapvetően különbözik attól, amikor a fejlesztő az alkalmazás elkészülte után próbálja visszamenőleg akadálymentessé tenni a szoftvert. Az automatizált ellenőrzés beépítésével az akadálymentesítés nem plusz teher, hanem a fejlesztési folyamat szerves része.
Shaun Preece saját tapasztalatával erősíti meg ezt: többször próbált ki különböző UI-keretrendszereket, és mindig az akadálymentesítés döntötte el, melyiket tudja ténylegesen használni. A QT platform modern és jól felépített, de nem támogatja a képernyőolvasók számára kritikus élő bejelentés funkciót. A WinUI 3 akadálymentes volt, de hagyományos menüsort nem támogat. Minden választásnál az akadálymentesítés szűk keresztmetszet.
—
Claude Fable 5 és az AI-modellek gazdaságtana
Az adásban szóba kerül egy aktuális fejlemény is: az Anthropic Claude Fable 5 modelljének elérhetőségi változásai. A Fable 5 a Claude AI legerősebb, nyilvánosan elérhető modellje – mélyebb elemzésre képes, és nagyobb számítási kapacitást igényel.
Az Anthropic 2026 júliusában a Fable 5-öt kivette a 20 dolláros havi Pro-előfizetés alapárajánlatából. Aki ezentúl Fable-t akar használni, a 100 vagy 200 dolláros Max tervre kell váltania – ahol a modell a használati kvóta 50%-át foglalja el –, vagy API-n keresztül, megtérítési alapon kell fizetnie az egyes kérésekért.
Babcock szerint az AI-használatnak korlátai vannak, és a Fable ezekből a keretekből többet vesz igénybe, mint a könnyebb modellek. A technológiai ipar felhasználói számára ez fontos tanulság: nem minden token egyenlő értékű, és a „korlátlan” előfizetések valójában rejtett súlyozással működnek.
A Fable egyik meglepő viselkedéséről Damashe Thomas – a Technically Working podcast Babcock melletti társmüsorvezetője – számolt be: a Fable felépített egy komplex weboldalt, majd amikor biztonsági ellenőrzést kért tőle a felhasználó, a rendszer automatikusan egy óvatosabb modellre váltott vissza – holott maga a Fable hozta létre a kódot, amelynek auditját kérték.
Ez a fajta óvatosság nem mindig felhasználóbarát, és rávilágít arra, hogy ezek a rendszerek sem hibátlanok. Babcock is említett egy esetet, amelyben a Fable egy feltöltött szövegfájlról azt állította, üres – holott nem volt az.
—
Clipman és a platformok közötti vágólap-kezelés
Az adásban helyet kap André Louis másik projektje, a Clipman is. A vágólap-kezelők nem új keletű eszközök – a Windows beépített megoldása tíz elemet tárol, míg a nyílt forráskódú Ditto 500-at –, de Clipman egy új réteget ad hozzá: Raspberry Pi-alapú szerverrel és Tailscale VPN-nel kombinálva lehetővé teszi, hogy különböző platformokon (Windows, Mac, iOS, Android) egyazon vágólap-előzményhez férjünk hozzá.
Babcock ezt „univerzális vágólap szteroidokon”-nak nevezi: Windowson másolt szöveget Mac-en beilleszteni, majd az egészet iOS-ről is elérni – egyetlen, vibe coding segítségével épített alkalmazáson keresztül.
A Clipman egyúttal illusztrálja a személyre szabott fejlesztés egyik legfontosabb előnyét is: a vakok által épített eszközök már a fejlesztési folyamat során átmennek a hozzáférhetőségi tesztelésen, mert a fejlesztő maga is képernyőolvasót használ.
—
Verziókövetés, monetizáció és az alkotói önbecsülés
Az adás egyik emberileg is izgalmas szála a monetizáció körül forog. Babcock kezdetben úgy érezte: mivel AI írta a kódot, nem illik pénzt kérni az alkalmazásért. Aztán megváltozott a véleménye.
Az érvelése: a hagyományos szoftverfejlesztésnél sem a programozó az egyetlen alkotó. Az architekt, aki meghatározza a megvalósítandó funkciót, a megoldandó problémát, a nyújtandó felhasználói élményt, szintén alkotó. Vibe coding esetén ez a szerep a fejlesztő-promteré, aki hónapokat tölt az igények finomításával, a tesztelők visszajelzéseinek feldolgozásával és az akadálymentesítési szempontok beépítésével.
Az Earshot végül ingyenesen letölthető, de 10 podcastra korlátozza a szabad használatot. A teljes funkcionalitáshoz 3 dollár/hó, 20 dollár/év, vagy 50 dolláros egyszeri díj szükséges.
Szóba kerül a GitHub-alapú verziókövetés is: Babcocknak az Earshot projektjén valószínűleg ezres nagyságrendű commitja van. Ebben a kontextusban a commit nem más, mint a munka mentett pillanatképe, üzenettel ellátva – amely lehetővé teszi a visszagörgetést, ha egy változtatás valamit elront. A community-access.org weboldalon elérhető egy ingyenes GitHub-tananyag is, amelyet Babcock és egy munkatársa állítottak össze kezdőknek, szöveges és hangos formátumban egyaránt.
A verziókövetőrendszer mellett a Claude Code egy másik lehetősége is szóba kerül: Babcock a /RC parancs segítségével Las Vegasból, telefonon keresztül nyolc frissítést adott ki a TestFlight-ra – miközben laptopja otthon maradt bekapcsolt állapotban. A funkció értesítést és URL-t küld a mobilra, amellyel távolról irányítható a fejlesztői munkamenet.
—
Mit jelent mindez a technológiai közösség számára?
A vibe coding demokratizálja a szoftverfejlesztést – de ez nem jelenti azt, hogy mindenki könnyen és hibátlanul alkothat. Babcock tapasztalata azt mutatja, hogy a folyamat iteratív, olykor fájdalmas, és sok tanulással jár.
Allison Sheridan, a NosillaCast podcast házigazdája egyetlen kérdésbe sűríti a lényeget: „Mi a megoldandó probléma?” Ha erre van válasz, a vibe coding valódi eszköz lehet.
A kockázatok sem elhanyagolhatók. Ahogy Babcock megjegyzi: az AI-szoftverek elburjánzása arra késztette az Apple-t, hogy az App Store-benyújtásnál megkérdezze, miben különbözik az adott alkalmazás a már meglévőktől. Ez a kérdés egyszerre szükséges minőségi szűrő és potenciális innovációs akadály – az Amazon Echo skill-tárhoz hasonlóan, ahol megkülönböztethetetlen, sablonos tartalmak árasztják el a platformot.
A vak fejlesztők közösségére mindez különösen fontos hatást gyakorol. Olyan eszközöket hozhatnak létre, amelyek pontosan az ő igényeiket elégítik ki, beépített akadálymentesítéssel, általuk tesztelve. Amikor a fejlesztő maga is képernyőolvasót használ, az akadálymentesítés nem utólagos megfontolás, hanem az alapkövetelmény – és ez látszik a végeredményen. Ez nem mellékes szempont, hanem a lényeg.
—
A cikk a Double Tap podcast 2026. július 20-i adása alapján, AI felhasználásával készült, ezért apróbb pontatlanságokat tartalmazhat.