Mi az a vibe coding? AI-fejlesztés 2026-ban

Néhány éve egy új üzleti alkalmazás ötlete általában úgy indult, hogy valaki összerakott egy specifikációt, fejlesztői becslést kért, és hetekkel vagy hónapokkal később elkészült az első használható verzió. Egy kisebb belső eszköz, egy új ügyfélportál vagy akár egy kényelmi funkció is könnyen annyiba került, hogy végül inkább el sem készült.

2026-ban ez sokszor egészen máshogy néz ki. Természetes nyelven leírod, milyen alkalmazást szeretnél, és egy AI-os alkalmazásépítő (AI app builder) elkezdi felépíteni. Fejlesztőként pedig az AI-t már arra is használhatod, hogy egy egész projektet átnézzen: egy mai AI-ügynök (coding agent) több fájlt módosít, parancsokat futtat, teszteket ír és futtat le, és az eredmény alapján dolgozik tovább, ami jóval több egy függvény megírásánál vagy egy hibaüzenet megfejtésénél.

Ettől még nem lett mindenki szoftverfejlesztő, és a jó szoftver sem lett egyszerű. Ami alapvetően megváltozott, az a távolság egy ötlet és az első működő verzió között. Szerintem az AI egyik legfontosabb hatása ráadásul nem is a gyorsabb kódírás: az AI azt is megváltoztatja, mit éri meg lefejleszteni.

Ez vállalkozói szemmel legalább annyira érdekes, mint maga a technológia. Olyan belső eszközök, automatizálások, MVP-k, ügyfélélményt javító funkciók és kisebb fejlesztések is megérhetik, amelyek néhány éve túl drágák lettek volna ahhoz képest, amennyi mérhető eredményt hoztak.

Ebben a cikkben ezért a vibe coding fogalmán túl azt is megnézzük, milyen AI-os fejlesztőeszközök vannak, mi a különbség a Lovable vagy a Replit és a Claude Code között, miből áll valójában egy modern webalkalmazás, mi az a Next.js, a Laravel és a Supabase, mikor elég egy AI-jal összerakott MVP, és hol kezdődik az a pont, ahol már komolyabb mérnöki munka kell.

Mi az a vibe coding?

A vibe coding kifejezést Andrej Karpathy tette széles körben ismertté 2025-ben. Eredetileg egy elég laza fejlesztési módot írt le: természetes nyelven elmondod az AI-nak, mit szeretnél, kipróbálod, amit készített, és újabb utasításokkal (promptokkal) alakítod tovább. Nem azzal kezded, hogy megtervezed az adatmodellt, kiválasztod a tervezési mintákat és megírod a komponenseket, inkább ennyit mondasz:

„Készíts egy ügyfélkezelő felületet, ahol látom az ügyfeleimet, az aktív projekteket, a következő feladatokat és a kifizetetlen számlákat.”

Az AI elkészít egy első verziót, megnézed, és azt mondod, hogy a projektek inkább kártyák legyenek. Utána kérsz szűrést, aztán bejelentkezést, adatbázist és jogosultsági szinteket, és egyszer csak a látványterv helyett egy működő alkalmazás van előtted. Ez nagyon más élmény, mint a klasszikus fejlesztés, ezért is terjedt el ilyen gyorsan a kifejezés.

2026-ra viszont maga a fogalom is árnyaltabb lett. Mást jelent, amikor valaki fejlesztői háttér nélkül összerak egy belső alkalmazást a Lovable-ben, és mást, amikor egy tapasztalt fejlesztő a Claude Code-dal dolgozik egy több éves Laravel-projekten. Mindkettőben rengeteg kódot írhat az AI, és mindkettőben természetes nyelvű utasításokat használunk, a kontroll, a rendszer felépítése (architektúra), a kódellenőrzés, a tesztelés és végső soron a felelősség viszont egészen más lehet.

Ezért én különválasztanám a klasszikus vibe codingot és az AI-val támogatott szoftverfejlesztést. Az elsőnél sokszor az eredményből indulunk ki: működjön, nézzen ki jól, oldja meg a problémát, és utána finomítunk rajta. A másodiknál ugyanúgy szoftverfejlesztési folyamatban gondolkodunk, csak a megvalósítás nagy részét AI-jal gyorsítjuk. A kettő között pedig egyre kevésbé éles a határ.

A Copilottól eljutottunk az agentic codingig

Az AI nem egyik napról a másikra változtatta meg a fejlesztést. A programozók régóta használnak olyan eszközöket, amelyek csökkentik a rutinmunkát: a fejlesztőkörnyezetek (IDE-k) kiegészítették a változóneveket és a metódusokat, a Google és a Stack Overflow gyakorlatilag a napi munka része lett, később pedig megjelentek az AI-alapú kódkiegészítők, amelyek már teljes kódrészleteket és függvényeket javasoltak. Ez még úgy működött, hogy a fejlesztő írta a kódot, és az AI segített.

Az AI-ügynököknél más a helyzet. Egy mai ügynöknek már nem azt mondod, hogy „írj egy PHP-függvényt, ami ellenőriz egy e-mail-címet”, inkább ilyesmit:

„Nézd át a jelenlegi ügyfélimportot. Az új CSV-ben megjelent két új oszlop. Módosítsd az importot úgy, hogy kezelje őket, a hibás sorokat tegye külön feldolgozási listába, írj hozzá teszteket, majd futtasd le az érintett tesztcsomagot.”

Ehhez az AI-nak meg kell értenie a meglévő projektet: meg kell keresnie a megfelelő fájlokat, fel kell ismernie a használt mintákat, több helyen módosítania kell a kódot, le kell futtatnia a teszteket, és ha hibát kap, vissza kell mennie javítani. Ez már egy feladat végrehajtása, jóval több a kódkiegészítésnél.

A Claude Code például ilyen ügynökként (agentic coding eszközként) fel tud térképezni egy kódbázist, több fájlban változtat, parancsokat és teszteket futtat, és együtt dolgozik a meglévő fejlesztői eszközökkel. Ez jól mutatja, mennyire eltávolodtunk attól, hogy csak kérdezünk valamit egy chatbottól.

A fejlesztő szerepe ettől nem tűnik el, de változik. Egyre több idő megy arra, mit kell megépíteni, hogyan illeszkedjen a rendszerbe, milyen kompromisszumokat vállalunk, hogyan teszteljük, és hogyan engedjük ki biztonságosan élesbe.

AI app builder vagy coding agent? Nem ugyanarra valók

A mai AI-os fejlesztőeszközöket szerintem hiba egyetlen listában rangsorolni. A „Lovable vagy Claude Code” például furcsa összehasonlítás, mert más problémát oldanak meg.

Lovable

A Lovable a „leírod, és megépíti” típusú alkalmazásépítők (prompt-first app builderek) tipikus példája. Leírod, milyen alkalmazást szeretnél, a rendszer pedig felépíti a felületet és a működés jelentős részét, így nagyon gyorsan eljuthatsz egy ötlettől egy kattintható, majd működő alkalmazásig. Jól használható MVP-khez, belső eszközökhöz, egyszerűbb SaaS-ötletekhez, ügyfélportálok első verziójához, adminfelületekhez és prototípusokhoz.

Fontos változás, hogy az ilyen platformokat már nem érdemes egyszerű látványtervgyártónak tekinteni. A Lovable például kétirányú GitHub-integrációt is ad, vagyis a kód nem marad bezárva az eszközben: a projekt továbbvihető a megszokott fejlesztői munkafolyamatba, lehet benne ágakkal (branchekkel) dolgozni, kódellenőrzést végezni és fejlesztőket bevonni.

Bolt

A Bolt szintén természetes nyelvű leírásból készít működő webes alkalmazásokat, és ma már a frontenden túl adatbázis, bejelentkezés, szerveroldali funkciók, titkos kulcsok kezelése és más háttérfunkciók is részei lehetnek egy Bolt-projektnek. Ez azért fontos, mert az „AI builder” szóról könnyű még mindig egy olyan eszközre gondolni, ami generál három React-komponenst és egy szép landing page-et, 2026-ban viszont ennél jóval többről van szó.

Replit

A Replit is egyre inkább teljes, AI-alapú fejlesztési platform. A saját Agent-útmutatója is egy építés, előnézetben (Preview) tesztelés és publikálás folyamaton vezeti végig a felhasználót:

leírod az ötletet → az Agent megtervezi → felépíti → előnézetben teszteled → javíttatod → publikálod

Ez óriási mértékben csökkenti a belépési küszöböt. Korábban ahhoz, hogy egy ötletből nyilvános webalkalmazás legyen, legalább érintőlegesen értened kellett a fejlesztői környezethez, a csomagkezelőhöz, a tárhelyhez, az élesítéshez és gyakran az adatbázishoz is, ma ezeknek egy részét a platform elrejti előled.

Ez egyszerre előny és veszély. Előny, mert sokkal több ember tud működő szoftvert készíteni, és veszély, mert attól, hogy valamit nem látsz, még létezik. Az adatbázisnak ugyanúgy van szerkezete, a bejelentkezésnek ugyanúgy vannak biztonsági követelményei, és az élesítés mögött ugyanúgy ott az infrastruktúra, csak ezek egy részének kezelését a platform leveszi a válladról.

Claude Code, Codex, Cursor és a fejlesztői oldal

A másik világ az AI-ügynököké és az AI-jal kibővített fejlesztői környezeteké. Itt jellemzően már van kódtároló (repository), Git, keretrendszer (framework), csomagkezelő, helyi vagy távoli fejlesztői környezet, adatbázis, tesztek, élesítési folyamat és valamilyen kialakított architektúra.

A fejlesztő itt nem azt mondja az AI-nak, hogy „készíts nekem CRM-et”, inkább konkrét fejlesztési feladatokat ad ki: egy új funkciót, átszervezést (refaktorálást), hibajavítást, tesztelést, dokumentációt, adatbázis-módosítást (migrációt) vagy akár egy nagyobb modul megírását. Az AI itt nem a fejlesztői környezetet adja, maga válik a fejlesztői környezet egyik szereplőjévé, és szerintem ez az a pont, ahol a „vibe coding” kifejezés már kevés.

A két világ egyre jobban összemosódik

A valóságban nem kell választani az alkalmazásépítő és a klasszikus fejlesztés között. Elkészülhet egy MVP a Lovable-ben, a forráskódja felkerülhet GitHubra, és egy fejlesztő átveheti: a Claude Code-dal átnézi a projektet, átszervezi a kritikus részeket, a meglévő Supabase-backend maradhat, vagy bizonyos üzleti logika külön backendbe költözhet, a rendszer pedig teszteket, felügyeletet (monitorozást), automatikus élesítést (CI/CD) és komolyabb jogosultságkezelést kaphat.

Fordítva is működik: egy fejlesztő is használhat alkalmazásépítőt arra, hogy nagyon gyorsan kipróbáljon egy felületi ötletet vagy összerakjon egy belső prototípust. Szerintem ezért téves az a gondolkodás, hogy van a „vibe coder” és van a „rendes fejlesztő”, 2026-ban sokkal inkább egy skáláról van szó. A kérdés az, mekkora kontrollra, szakértelemre és mérnöki fegyelemre van szükség az adott rendszer adott életszakaszában.

Miből áll valójában egy modern webalkalmazás?

Ahhoz, hogy érthető legyen, miért nem old meg mindent egyetlen alkalmazásépítő, érdemes röviden megnézni, miből áll egy alkalmazás. Vegyünk egy egyszerű ügyfélportált: az ügyfél bejelentkezik, látja a projektjeit, dokumentumokat tölthet le, üzenetet küldhet és megnézheti a számláit. Kívülről ez egyetlen weboldalnak tűnik, a háttérben viszont több réteg dolgozik.

Frontend

A frontend az, amit a felhasználó lát: a bejelentkezési képernyő, a vezérlőpult (dashboard), a projektlista, a számlák, a gombok, az űrlapok, a mobilnézet és a visszajelző üzenetek. Modern JavaScript-alkalmazásoknál ezt gyakran Reacttel vagy egy Reactre épülő keretrendszerrel készítjük.

Backend

Amikor az ügyfél megnyomja a „Számla letöltése” gombot, valaminek el kell döntenie, hogy tényleg hozzáférhet-e ahhoz a számlához. Amikor üzenetet küld, valaminek el kell mentenie, amikor fizet, valaminek beszélnie kell a fizetési szolgáltatóval. Ez a backend dolga, és itt van az alkalmazás üzleti logikájának nagy része.

Adatbázis

Valahol tárolni kell a felhasználókat, az ügyfeleket, a projekteket, a számlákat, a jogosultságokat, az üzeneteket és az állapotokat, ez az adatbázis. Egy modern webalkalmazásnál nagyon gyakori a relációs adatbázis, például a PostgreSQL vagy a MySQL.

Azonosítás és jogosultságkezelés

Ezt a kettőt érdemes külön kezelni. Az azonosítás (authentication) azt kérdezi, ki vagy, a jogosultságkezelés (authorization) pedig azt, mit csinálhatsz. Attól, hogy valaki sikeresen bejelentkezett, még nem láthat minden adatot, egy ügyfélportálon például az egyik ügyfél semmilyen körülmények között nem láthatja egy másik ügyfél számláit. Ez az a fajta probléma, ami egy prototípusnál könnyen észrevétlen marad, éles rendszerben viszont kritikus.

Fájltárolás

A fájlok gyakran nem az adatbázisban vannak: a dokumentumokat, képeket, videókat és feltöltött fájlokat külön fájltároló (object storage) rendszer őrzi.

Külső API-k

A modern alkalmazások ritkán működnek teljesen önállóan, sokszor API-kon, webhookokon vagy egy külön automatizálási rétegen keresztül kapcsolódnak más rendszerekhez: számlázóhoz, a Stripe-hoz, CRM-hez, e-mail-szolgáltatóhoz, AI-API-hoz, logisztikai rendszerhez vagy egy n8n-munkafolyamathoz. Ha ez a rész érdekel, az automatizálásról és az AI-integrációról szóló oldalon mutatom meg, hogyan kötöm össze a rendszereket.

Backend és háttérfolyamatok

A backend az adatbázissal való kommunikáción és az üzleti logikán túl sok olyan műveletet is végez, amit nem akarunk, vagy nem is szabad a böngészőre bízni: ellenőrzi a jogosultságokat, biztonságosan hívja a külső API-kat, használja az API-kulcsokat és más érzékeny adatokat, feldolgozza a webhookokat, e-mailt küld, kezeli a fizetéseket, és hosszabb háttérfolyamatokat indít.

Nem minden feladatot érdemes egyetlen böngészős kérés alatt elvégezni. Ha például feltöltesz egy 100 000 soros CSV-t, a rendszer sorba állíthatja (queue) a feldolgozást, és egy háttérben futó folyamat (worker) dolgozik rajta. Hogy ezek pontosan hol futnak, az architektúrától függ: lehet egy hagyományos virtuális szerveren (VPS) futó Laravel-backend, egy konténeres szolgáltatás, egy szerver nélküli (serverless) környezet vagy egy platform saját szerveroldali futtatókörnyezete.

És valahol mindennek futnia kell

Attól, hogy egy alkalmazásépítő vagy felhőplatform sok technikai részletet elrejt, az alkalmazás mögött ugyanúgy van infrastruktúra: valahol fut a frontend és a backend, valahol működik az adatbázis, és valahol vannak a feltöltött fájlok. Egy éles rendszer körül ezért a tárhelyről és a futtatókörnyezetről, a domainről és a DNS-ről, a HTTPS-ről, az adatbázisról, a fájltárolásról, a mentésekről, a rendelkezésre állásról, a felügyeletről, a naplók gyűjtéséről, valamint az élesítésről és a verzióváltásokról is gondoskodni kell.

A naplózás jól mutatja, hogyan kapcsolódnak össze ezek a rétegek: a naplókat az alkalmazás írja, az összegyűjtésük, tárolásuk, kereshetőségük és a hibákra épülő riasztások viszont már az üzemeltetéshez tartoznak. A titkos kulcsok (secretek) használata szintén az alkalmazás dolga, a biztonságos tárolásukat viszont jellemzően a futtatókörnyezet vagy egy külön titokkezelő adja. A Vercel, a Supabase, a Replit vagy egy alkalmazásépítő ezek közül sok mindent szolgáltatásként ad, saját szervernél viszont a nagyobb részükről nekünk kell gondoskodnunk.

Az AI-jal nem tűnt el az infrastruktúra, sokszor egyszerűen magasabb szintű szolgáltatások mögé került, ezért nem nekünk kell közvetlenül üzemeltetni minden rétegét. Ha saját infrastruktúrán futtatnál webalkalmazást vagy más üzleti rendszert, a rendszerüzemeltetéssel és a self-hosted eszközökkel külön is foglalkozom.

Mi az a framework, és miért számít még mindig?

Gyakran hallani, hogy az AI mellett hamarosan mindegy lesz, milyen programozási nyelvet vagy keretrendszert (frameworköt) használunk. Szerintem ez túlzás. Lehet, hogy fejlesztőként egyre kevesebb ismétlődő alapkódot (boilerplate) írok magam, de az alkalmazás ugyanúgy valamilyen technológiai alapra épül.

A keretrendszer meghatározza többek között, hogyan szerveződik a projekt, hogyan kezeljük az útvonalakat (routing) és a kéréseket, milyen minták szerint dolgozunk az adatbázissal, milyen eszközöket kapunk a teszteléshez, hogyan oldjuk meg a gyakori problémákat, és milyen ökoszisztémából választhatunk csomagokat. Az AI sokkal gyorsabban dolgozik egy jó keretrendszerben, de valakinek attól még el kell döntenie, melyik illik a problémához.

React és Next.js

A React felhasználói felületek építésére való JavaScript-könyvtár, a Next.js pedig erre épít egy teljes webes keretrendszert. Next.jsben ma már a frontenden túl szerveroldali renderelés, Server Components, Route Handlers, Server Actions és más szerveroldali képességek is vannak, ezért teljesen életszerű, hogy egy alkalmazás nagy része egyetlen Next.js-projektben éljen. Egy kisebb SaaS állhat például egy Next.js-frontendből, Next.js-es szerveroldali logikából, Supabase-adatbázisból és -bejelentkezésből, Stripe-os fizetésből és egy külső e-mail-szolgáltatóból, és ennyi, külön Laravel- vagy Node-backend nélkül.

Ez nem rossz architektúra csak azért, mert nincs külön backend-kódtár, de van egy pont, ahol érdemes elgondolkodni, kell-e már az üzleti logikának önálló backend. A Next.js dokumentációja full-stack React-keretrendszerként írja le a Next.js-t, ettől még nem minden rendszerben érdemes az összes backendfeladatot ugyanabba a Next.js-alkalmazásba tenni. A keretrendszer támogatja a Backend for Frontend mintát is, vagyis nagyon jó réteg lehet a frontend és más szolgáltatások között. Next.jsben tehát lehet komoly szerveroldali kódot írni, az architektúrát viszont a rendszer igényei alapján kell megválasztani.

Laravel

A Laravel egy teljes értékű PHP-alkalmazáskeretrendszer, és különösen azoknál a rendszereknél szeretem, ahol maga a backend is jelentős üzleti alkalmazás. Egy CRM-ben például van érdeklődőkezelés (lead), ügyfélkezelés, státuszok, jogosultságok, automatikus folyamatok, időzített feladatok, importok és exportok, e-mail-feldolgozás, külső API-kapcsolatok és riportok, és ezekhez a Laravel rengeteg jól kialakított eszközt ad.

Vegyünk egy egyszerű példát: egy ügyfél feltölt egy 50 000 soros Excel- vagy CSV-fájlt. A teljes importot nem akarjuk egyetlen HTTP-kérés alatt végrehajtani, ezért Laravelben feladatokat (jobokat) hozunk létre, sorba állítjuk őket, egy háttérfolyamat dolgozik rajtuk, és kezeljük az újrapróbálkozást, az időtúllépést és a hibákat. A Laravel queue rendszere egységes felületet ad többek között a Redishez, az Amazon SQS-hez és a relációs adatbázisra épülő sorokhoz. Ugyanez Next.js-környezetben is megoldható, a különbség inkább az, milyen problémák köré milyen eszköztár és fejlesztési modell épült.

Next.js vagy Laravel backend?

Erre nincs egyetlen jó válasz. Ha egy projekt erősen frontendközpontú, viszonylag egyszerű az üzleti logikája, gyors MVP a cél, sok logikát eleve külső szolgáltatások adnak, és az infrastruktúra nagy részét a Supabase vagy más backendszolgáltatás kezeli, akkor a Next.js egymagában vagy a Supabase-zel együtt nagyon jó megoldás lehet.

Ha viszont maga az üzleti logika összetett, sok a háttérfolyamat és a más rendszerekkel való kapcsolat, hosszan futó feladatok vannak, összetett jogosultságkezelés kell, több külön kliens használja ugyanazt az API-t, vagy nagy admin- és ügyviteli rendszer készül, akkor gyakran külön backendben gondolkodnék, például Laravelben. Ezt sem dogmaként: lehet olyan nagy rendszer, ahol a Next.js tökéletes, olyan kicsi, ahol a Laravel a legegyszerűbb, és olyan projekt is, ahol egyáltalán nincs szükség Next.jsre.

Laravel nem jelenti azt, hogy külön React frontend kell

Ez is gyakori félreértés. Egy Laravel-alkalmazás készülhet például Blade-del, Livewire-rel és Alpine.js-szel, így egyetlen alkalmazáson belül van a backend és az interaktív frontend. Egy belső CRM-nél vagy adminrendszernél ez sokszor jóval egyszerűbb, mint külön React-frontendet és külön API-backendet fenntartani, és megint ugyanoda jutunk: a cél a problémához illő technológia (stack), akkor is, ha nem a legdivatosabb.

Mi az a Supabase?

A Supabase neve szinte elkerülhetetlen, ha AI-os alkalmazásépítőkkel kezdesz dolgozni, sokaknak viszont nem teljesen világos, mi is az. Nem frontend-keretrendszer, és nem is ugyanabba a kategóriába tartozik, mint a Laravel: a legegyszerűbben egy backendplatformként lehet elképzelni, amely több gyakori infrastruktúraelemet készen ad.

Minden Supabase-projekt mögött PostgreSQL-adatbázis van, és ez fontos: szabványos PostgreSQL-adatbázist kapsz, valamilyen elrejtett „AI-adatbázis” helyett. Erre épül többek között a bejelentkezés (Auth), a fájltárolás (Storage), a valós idejű frissítés (Realtime), a szerveroldali függvények (Edge Functions) és az adatelérési felület (Data API), ezért lehet vele nagyon gyorsan alkalmazást építeni. Bővebben a Supabase-ről szóló cikkben írok róla.

Supabase Database

Tegyük fel, hogy ügyfélportált készítünk, és szükségünk van néhány táblára: users, companies, projects, invoices, messages. Ezeket PostgreSQL-táblákként hozzuk létre, kapcsolatokat és indexeket készítünk közöttük, SQL-t futtathatunk, és használhatjuk a Postgres-bővítményeket (extensionöket) is. A Supabase tehát nem helyettesíti az adatbázist, a Supabase egyik legfontosabb része maga a Postgres-adatbázis.

Supabase Auth

A következő feladat a bejelentkezés. Nem akarunk minden projekthez nulláról saját jelszókezelést, e-mail-ellenőrzést és munkamenet-kezelést építeni, és a Supabase Auth ehhez kész azonosítási réteget ad: lehet e-mail-cím és jelszó, egyszer használható belépőlink (magic link), egyszeri kód (OTP), közösségi bejelentkezés vagy céges egyszeri bejelentkezés (SSO). A felhasználó belép, a rendszer pedig egy token (JWT) segítségével azonosítja.

Itt jön viszont egy fontos különbség: attól, hogy tudjuk, ki a felhasználó, még nem tudjuk, milyen adatot láthat, ez már a jogosultságkezelés kérdése.

Row Level Security, vagyis RLS

A Supabase egyik nagyon erős, de rosszul beállítva veszélyes része a PostgreSQL sorszintű jogosultságkezelése (Row Level Security, RLS). Maradjunk az ügyfélportálnál: van egy invoices táblánk, amelyben minden ügyfél számlája szerepel. Nem elég azt mondani a frontendnek, hogy „csak az aktuális felhasználó számláit kérd le”, mert a frontend a felhasználó gépén fut, és egy támadó módosíthatja a kérést, ezért a biztonsági szabálynak az adatbázisnál is érvényesülnie kell.

Egy RLS-szabállyal (policyval) megadhatjuk például, hogy egy bejelentkezett felhasználó csak olyan sort olvashat az invoices táblából, amely a saját cégéhez tartozik. Ez nagyon erős modell, de pontosan meg kell tervezni. A Supabase RLS-dokumentációja szerint a kívülről elérhető sémák tábláin az RLS-t mindig be kell kapcsolni, és a szabályok határozzák meg, melyik szerepkör mely sorokat olvashatja vagy módosíthatja.

Van egy másik nagyon fontos szabály is: a service role vagy más titkos kulcs nem kerülhet a frontendbe, mert ezekkel meg lehet kerülni az RLS védelmét. Egy AI-jal generált alkalmazásnál éppen az ilyen hibákat kell különösen komolyan ellenőrizni.

Supabase Storage

Ha az ügyfélportálon szerződéseket vagy képeket kell tárolni, a Storage szolgáltatást használhatjuk, ahol szintén jogosultsági szabályok határozzák meg, ki melyik fájlt érheti el. Ez megint rengeteg infrastruktúramunkát spórolhat meg.

Realtime

Bizonyos alkalmazásoknál egy adatváltozásnak azonnal meg kell jelennie a többi felhasználónál is, például egy csevegésben, egy élő vezérlőpulton, egy státuszváltozásnál vagy közös munkánál. A Supabase Realtime ehhez kész infrastruktúrát ad.

Edge Functions

Ha olyan szerveroldali logika kell, amit nem szeretnénk közvetlenül a böngészőből futtatni, például egy külső API hívása, egy titkos kulcsot igénylő művelet, egy webhook feldolgozása vagy valamilyen speciális üzleti logika, az Edge Functions szerveroldali függvényeit is használhatjuk. Ez tovább árnyalja a „Supabase vagy saját backend” kérdést, mert a valóságban rengeteg köztes megoldás van.

Supabase vs saját backend

Szerintem nem érdemes úgy kezelni ezt a kérdést, hogy az egyik profi, a másik pedig csak MVP-re való, mert a Supabase éles rendszerben is teljesen jó választás lehet. A kérdés az, hol akarjuk tartani az üzleti logikát, mekkora kontrollra van szükségünk, és milyen rendszer épül.

Amikor a Supabase nagyon jó választás

Vegyünk egy SaaS MVP-t regisztrációval, profillal, néhány egyszerű adatkezelő (CRUD) funkcióval, fájlfeltöltéssel, Stripe-os fizetéssel és egyszerű jogosultságokkal. Itt egy Next.js + Supabase felállás nagyon gyors és teljesen életszerű lehet, és nem biztos, hogy bármit nyerünk azzal, ha rögtön külön Laravel-API-t építünk.

Amikor saját backend felé mozdulnék

Tegyük fel, hogy ugyanez az alkalmazás két év múlva már 15 külső rendszerrel kommunikál, összetett számlázási logikát kezel, több száz háttérfeladatot futtat, külön mobilalkalmazás is használja, nagy importokat dolgoz fel, összetett szerepkörei vannak, és saját munkafolyamat-motort kapott. Itt már lehet, hogy jobb egy központi alkalmazásbackend, például Laravel, a Supabase pedig akár ekkor is maradhat bizonyos feladatokra. A technológiából nem kell vallást csinálni.

Az AI legnagyobb üzleti hatása: megváltozott, mit éri meg fejleszteni

Technológiailag nagyon érdekes, hány fájlt tud módosítani egy ügynök, vagy milyen gyorsan rak össze egy adatkezelő felületet, vállalkozói szemmel viszont szerintem ennél fontosabb dolog történik: csökken a szoftver elkészítésének határköltsége.

Korábban egy kisebb funkciónál is számolni kellett a specifikációval, a tervezéssel, a fejlesztéssel, a teszteléssel, a javításokkal és az élesítéssel. Ha egy funkció 40 fejlesztői órába került, üzletileg indokolhatónak kellett lennie, és ha nem tudtad megmondani, hogy visszahoz-e több százezer forintot, könnyen arra jutottál, hogy „jó lenne, de most nem fontos”. Így került rengeteg cégnél a teendőlista végére minden olyan fejlesztés, ami nem létfontosságú, csak jobbá tenné a rendszert.

AI-val támogatott fejlesztésnél ugyanaz a funkció bizonyos esetekben sokkal gyorsabban elkészülhet, és ekkor teljesen megváltozik a döntés. Nem kell biztosnak lenned abban, hogy 5 millió forint plusz bevételt hoz, lehet, hogy egyszerűen megéri kipróbálni.

Az MVP-k elkészítése is felgyorsult

Az MVP (Minimum Viable Product, vagyis a legkisebb még használható termék) célja, hogy a lehető legkisebb működő verzióval kipróbáld a feltételezésedet, és ehhez nem rossz, olcsó szoftvert kell készíteni. Tegyük fel, hogy van egy ötleted egy SaaS-ra. Régen lehet, hogy már az első verzió előtt kellett felhasználói élmény (UX) tervezés, frontend- és backendfejlesztés, adatbázis, bejelentkezés, tárhely és élesítés, és mire az első ügyfél kipróbálta, már komoly pénz és idő volt benne.

Ma a Lovable, a Bolt vagy a Replit segítségével akár maga az ötletgazda is elkészíthet egy első működő verziót, vagy egy fejlesztő AI-val támogatott munkával sokkal gyorsabban leszállíthatja ugyanazt az MVP-t. Ez nem garantálja, hogy jó lesz az ötlet, és éppen ez a lényeg: olcsóbban kiderül, ha rossz, és ez óriási előny.

Gyorsabb lett az ötlet, fejlesztés, mérés, iteráció ciklus

Szerintem ez az AI egyik legfontosabb hatása a termékfejlesztésre. Korábban egy funkció útja így nézhetett ki:

ötlet → specifikáció → priorizálás → sprint → fejlesztés → tesztelés → kiadás → mérés

Ha maga a fejlesztés drága és lassú, természetesen sokkal óvatosabbak vagyunk azzal, mit teszünk bele. Most bizonyos funkcióknál ez lehet:

ötlet → első verzió → teszt → mérés → javítás

Így több feltételezést lehet kipróbálni, és nem kell minden döntést a tárgyalóasztal mellett meghozni, mert a felhasználók a viselkedésükkel megmondják, mi működik.

Az AI miatt több CX és UX fejlesztés érheti meg

Szerintem ez különösen érdekes. Vannak funkciók, amelyeknél könnyű kiszámolni a megtérülést: ha egy új pénztároldal 15 százalékkal növeli a konverziót, könnyű eldönteni, hogy megéri-e. De mi a helyzet egy olyan funkcióval, amitől csak kényelmesebb lesz az oldal? Ilyen egy jobb termékválasztó, egy egyedi kalkulátor, egy okosabb keresés, egy jobb státuszkövetés az ügyfélportálon, a rendelés utáni önkiszolgáló módosítás, egy tömeges művelet a belső adminban, az automatikus adatkitöltés, vagy egy gomb, ami egy dolgozónak napi 10 percet spórol meg.

Ezeknek összesítve komoly értékük lehet, de nehéz előre forintosítani őket. Ha egy ilyen funkció 1 millió forint, könnyű elengedni, ha viszont AI-val támogatott fejlesztéssel az első verzió sokkal kisebb ráfordításból elkészül, már megéri kipróbálni. Ezért gondolom, hogy az AI a meglévő fejlesztések gyorsításán túl új fejlesztési kategóriákat is gazdaságossá tesz.

Belső céges eszközökből is sokkal több készülhet

Ugyanez igaz a belső rendszerekre. Rengeteg vállalkozásnál a folyamatok egy része Excelben, Google Táblázatokban, e-mailekben, Slack-üzenetekben és különböző SaaS-rendszerek között él, adatok másolgatásával. Sokszor mindenki tudja, hogy jobb lenne egy saját kis alkalmazás, csak eddig nem érte meg lefejleszteni: ha egy 8 fős csapatnak kellett egy egyszerű belső eszköz, nem biztos, hogy indokolt volt rá több millió forintos egyedi fejlesztést indítani.

Alkalmazásépítővel vagy AI-val támogatott fejlesztéssel viszont már teljesen más lehet a matek, és szerintem ez a következő évek egyik érdekes területe lesz. Lehet, hogy nem a következő Facebook készül el vibe codinggal, de tízezrével készülhetnek olyan kis belső alkalmazások, amelyek egy konkrét vállalkozás egy konkrét problémáját oldják meg.

A BBPro Connect jó példa erre a változásra

Magyarországon is látni már érdekes példákat. A BB PRO saját rendszere, a BBPro Connect azért érdekes számomra, mert Sándorfy Adrián alapítóként maga fejleszti AI-támogatással a saját vállalkozásuk rendszerét.

A lényeg nem az, hogy ettől mindenkinek fejlesztővé kell válnia. Sokkal érdekesebb, hogy Adrián közvetlenül ismeri az üzleti problémát és a felhasználókat, ezért nagyon rövid lehet az út egy ötlettől az első működő funkcióig és a valós használatból jövő visszajelzésig. Ha van egy ötlet egy funkcióra, gyorsan el lehet készíteni, ki lehet próbálni, meg lehet mérni, használják-e, és ha beválik, tovább lehet fejleszteni, ha nem, el lehet engedni.

A Biznisz Boyz egy külön podcastepizódban is foglalkozott azzal, hogyan épül saját szoftver AI-jal, és szóba kerül benne a vibe coding, a Claude Code és a BBPro Connect is. Szerintem ez sokkal jobban mutatja az AI-os fejlesztés valódi lehetőségét, mint az, hogy valaki húsz perc alatt generált egy teendőlista-alkalmazást.

De ettől nem kell minden cégvezetőnek vibe codernek lennie

Itt érdemes megállni egy pillanatra. Az AI körüli kommunikáció hajlamos abba az irányba menni, hogy mostantól mindenkinek alkalmazást kell fejlesztenie, ami szerintem ugyanolyan túlzás, mint az, hogy az AI miatt többé nincs szükség fejlesztőkre.

Van olyan vállalkozó, aki ezt élvezi: érdekli a technológia, szeret kísérletezni, és nem zavarja, ha meg kell értenie, mi az az adatbázis-migráció vagy az RLS-szabály. Neki óriási lehetőséget adnak ezek az eszközök. Van viszont, aki egyszerűen nem ilyen: nem akar GitHubot kezelni, promptokkal hibát keresni, eldönteni, hogy Next.js vagy Laravel legyen, és azon gondolkodni, hol tároljuk a titkos kulcsokat. És nem is kell.

Az AI előnyeit kiszervezett fejlesztésnél is megkapod

Attól, hogy nem te használod a Claude Code-ot, a fejlesztésed még lehet AI-val támogatott. Ha egy fejlesztő vagy fejlesztőcsapat jól használja ezeket az eszközöket, gyorsabban tud prototípust készíteni, kódot írni, átszervezni, teszteket és dokumentációt írni, hibát keresni és alternatív megoldásokat kipróbálni. Vállalkozóként nem kell tudnod, hogyan működik mögötte az AI, azt kell tudnod, milyen problémát akarunk megoldani.

Én is AI-val támogatott fejlesztéssel dolgozom az ügyfélprojektekben, és az ügyfélnek ettől nem kell Claude Code-szakértővé válnia. Elmondja az üzleti problémát, én pedig segítek eldönteni, hogy WordPress, egyedi WordPress-fejlesztés, Next.js, Supabase, Laravel vagy valami más illik hozzá.

A vibe coding legveszélyesebb mondata: „működik”

Ez az a rész, amit szerintem nem lehet kihagyni egy ilyen cikkből. Elkészítetted az alkalmazást, be tudsz jelentkezni, létre tudsz hozni egy ügyfelet, el tudod menteni, és megjelenik a vezérlőpulton. Akkor kész? Nem biztos, mert éles szoftvernél a „működik” csak az egyik követelmény.

Néhány kérdés, amire ilyenkor választ kell adni. Mi történik, ha valaki módosítja a frontendről érkező kérést, és ellenőrzi-e a backend, hogy jogosult a műveletre? Hozzáférhet-e egy felhasználó egy másik cég adataihoz? Hol vannak az API-kulcsok? Mi történik, ha a fizetési szolgáltató kétszer küldi el ugyanazt a webhookot, vagy ha az e-mail-API harminc másodpercig nem válaszol? Van-e újrapróbálkozás, terheléskorlát (rate limit), mentés és felügyelet? Kap-e valaki értesítést, ha egy háttérfeladat három napja folyamatosan hibára fut? Van-e műveleti napló (audit log)? És mi történik, ha egy hibás kiadás adatbázis-módosítást is tartalmaz, vissza tudunk-e állni?

Ezek nem látványos kérdések, és egy bemutatóvideóban nem ezek látszanak. Élesben viszont sokszor éppen ezek választják el a működő prototípust a megbízható rendszertől.

Authentication nem ugyanaz, mint authorization

AI-jal generált alkalmazásoknál ez különösen fontos. Az azonosítás (authentication) azt mondja meg, ki vagy, a jogosultságkezelés (authorization) pedig azt, mit csinálhatsz. Lehet tökéletes bejelentkezési rendszered úgy, hogy közben az alkalmazás adatvédelmi szempontból teljesen hibás: például minden bejelentkezett felhasználó lekérheti az összes számlát, és csak a frontend szűri ki belőle a sajátját. A felületen minden rendben látszik, egy támadó viszont közvetlenül meghívja az API-t, és máris látja más ügyfelek adatait. Ezért kritikus a szerveroldali jogosultságkezelés, Supabase-nél pedig például a megfelelő RLS.

A frontend nem biztonsági határ

Ez olyan alapelv, amit vibe coding mellett mindenkinek érdemes legalább fogalmi szinten megértenie. A böngésző a felhasználó gépén fut, és a felhasználó módosíthatja, ezért nem bízhatunk abban, hogy valami azért nem történik meg, mert nincs hozzá gomb a felületen. Ha egy adminfunkcióhoz nincs gomb egy átlagos felhasználó képernyőjén, az API-végpont attól még létezhet, a jogosultságot ezért ott kell ellenőrizni, ahol a művelet ténylegesen megtörténik.

Secretek és API-kulcsok

Egy másik tipikus probléma a titkos kulcsoké: egy külső AI-API kulcsa, a Stripe titkos kulcsa, az e-mail-szolgáltató API-kulcsa vagy a Supabase service role kulcsa nem kerülhet csak úgy a frontend kódjába. A Supabase dokumentációja is egyértelműen különválasztja a frontendben használható nyilvános (publishable) kulcsokat azoktól a titkos és service role kulcsoktól, amelyek megkerülik az RLS-t, és ezért csak megbízható szerveroldali környezetben használhatók. Egy működő alkalmazás tehát ettől még lehet rosszul felépítve.

Mit jelent valójában a production-ready?

Arra, hogy mitől lesz egy rendszer éles üzemre kész (production-ready), nincs egyetlen ellenőrzőlista, hiszen egy belső szabadságnyilvántartó és egy pénzügyi alkalmazás kockázata teljesen más. Általában viszont foglalkozni kell legalább az azonosítással és a jogosultságkezeléssel, a bemenő adatok ellenőrzésével, az adatvédelemmel, a titkos kulcsok kezelésével, a hibakezeléssel, a naplózással és a felügyelettel, a mentéssel, a függőségek frissítésével, a tesztekkel, az élesítéssel, a teljesítménnyel, a skálázhatósággal és a visszakövethetőséggel. Mindez több annál, hogy minden jól működik: az éles üzemre kész rendszer arra is fel van készítve, hogy valami el fog romlani, mert előbb-utóbb el fog.

Ha Lovable-ben vagy Replitben épült, ki kell dobni?

Nem, szerintem ez a másik szélsőség. Attól, hogy egy alkalmazás alkalmazásépítőben indult, még nem rossz, és attól, hogy egy tapasztalt fejlesztő maga írta, még nem jó, a kódot és a felépítést kell megvizsgálni. Ha valaki házon belül összerakott egy működő MVP-t, én nem abból indulnék ki, hogy „ezt újra kell írni”, először megnézném.

Kódstruktúra

Átlátható-e, van-e benne rengeteg ismétlődő kód, és érthető-e, hogyan működik?

Adatmodell

Jól vannak-e felépítve a kapcsolatok, vannak-e megfelelő megkötések (constraintek), és bővíthető-e később?

Biztonság

Megfelelő-e az azonosítás, jók-e a jogosultságok, rendben van-e az RLS, és biztosan nincsenek-e titkos kulcsok a böngészőben futó kódban?

Tesztek

Van-e bármilyen automatikus ellenőrzés, és lefedik-e tesztek a kritikus üzleti folyamatokat?

Deployment

Megismételhető-e az élesítés, tudjuk-e, milyen környezeti változók kellenek, és van-e tesztkörnyezet (staging)?

Üzemeltetés

Van-e naplózás, felügyelet és mentés?

Ha ezek rendben vannak, lehet, hogy az alkalmazás nagy része maradhat, és csak néhány kritikus részt kell átalakítani. Az is lehet, hogy az MVP tökéletesen teljesítette a feladatát, de a következő növekedési szinthez már más architektúra kell. Az MVP nem kudarc attól, hogy később átépítjük, a feladata az volt, hogy olcsón kipróbáljon egy ötletet.

Az AI a WordPress-fejlesztést is megváltoztatja

A vibe codingról szóló beszélgetésekből néha úgy tűnhet, mintha 2026-ban minden alkalmazásnak Next.js-re és Supabase-re kellene épülnie, ami nyilván nincs így. A WordPress továbbra is nagyon erős választás lehet tartalomközpontú weboldalakhoz, webshopokhoz és olyan projektekhez, ahol a tartalomkezelő képességei valódi előnyt jelentenek, ezt a WordPress vs egyedi fejlesztés cikkben részletesebben is körbejártam.

WordPressen belül is lehet egyedi fejlesztést végezni, és AI segítségével gyorsabban készülhet saját bővítmény, Gutenberg-blokk, WooCommerce-módosítás, REST API-s kapcsolat, egyedi adminfelület, adatköltöztetés, import és export, automatizálás, parancssori szkript vagy teszt. Ha a WordPress már megoldja a projekt 80 százalékát, lehet, hogy sokkal jobb ráfejleszteni a hiányzó 20 százalékot, mint nulláról új alkalmazást készíteni. Az AI tehát nem teszi értelmetlenné a régebbi technológiákat, a meglévő platformokra is sokkal gazdaságosabban lehet vele egyedi megoldásokat építeni.

És mi történik a programozókkal?

Talán ez a legnagyobb kérdés az egész téma körül: ha az AI ennyi kódot tud írni, kell-e még fejlesztő? Szerintem a kérdés rosszul van feltéve, mert a fejlesztő munkája soha nem merült ki abban, hogy karaktereket gépel egy szerkesztőbe. A kódírás persze fontos része volt, de a valódi munka nagy része mindig is a probléma megértése, a követelmények tisztázása, az adatmodellezés, az architektúra, a hibakeresés, a kompromisszumok, a biztonság, az integrációk, a tesztelés, az üzemeltetés és a kommunikáció volt. Az AI most nagyon gyorsan csökkenti a kód előállításának költségét, és ettől ezek a többi képességek szerintem még jobban felértékelődnek.

A szintaxis önmagában egyre kevésbé lesz versenyelőny

Régen komoly érték volt, ha valaki fejből tudta egy keretrendszer vagy nyelv rengeteg részletét. Ez ma is hasznos, de ha az AI két másodperc alatt megmondja a pontos szintaxist, a bemagolt tudás kevésbé különböztet meg. Sokkal fontosabbak lesznek az ilyen kérdések: miért ezt az adatmodellt választottad, miért kell külön szolgáltatás, mi történik, ha egyszerre többen nyúlnak ugyanahhoz az adathoz, miért nem lehet ezt a műveletet a böngészőből indítani, hogyan kezeljük, ha ugyanaz a kérés kétszer érkezik meg, mi történik, ha az API nem elérhető, hol legyen az üzleti logika, milyen adatot szabad naplózni, és hogyan vonunk vissza egy hibás kiadást. Ezekre az AI is tud választ adni, de valakinek el kell döntenie, hogy a válasz helyes-e az adott rendszerben.

A fejlesztő egyre inkább rendszerépítő lesz

Úgy látom, hogy a fejlesztői munka egyre magasabb szintre kerül. Kevesebb idő megy arra, hogy „írd meg ezt a 200 sor alapkódot”, és több arra, hogy hogyan nézzen ki egy modul, milyen feladata legyen egy szolgáltatásnak, hogyan teszteljük, milyen szélsőséges esetek vannak, biztonságos-e, és egyáltalán érdemes-e magunknak megépíteni. A jó fejlesztők értéke ezért szerintem megmarad, csak a munkájuk változik.

Kell még programozást tanulni 2026-ban?

Szerintem igen, de már nem ugyanúgy tanulnék, mint tíz éve. Nem látom sok értelmét, hogy valaki hónapokig mesterségesen kizárja az AI-t azért, hogy „rendesen megtanuljon programozni”. Használd az AI-t, írass vele kódot, kérdezd meg, mit csinált, kérj tőle más megoldást, és kérd meg, hogy keressen hibát a saját megoldásában, közben viszont értsd meg az alapokat.

Mit érdemes megtanulni az AI korában?

Nem egyetlen keretrendszert tanulnék meg vakon, inkább egymásra épülő fogalmakat.

Webes alapok

A HTML, a CSS és a JavaScript. Nem kell minden CSS-tulajdonságot fejből tudni, de értsd, hogyan működik a böngésző és a web.

HTTP

A kérés és a válasz, a fejlécek, a sütik, az állapotkódok, a GET és a POST. Ezek nélkül nagyon nehéz megérteni, mit csinál egy webalkalmazás.

Git

A commit, az ág (branch), az összefésülés (merge) és a pull request. Ennek az az oka, hogy verziókezelés nélkül AI-jal is veszélyes komolyan fejleszteni, menő terminálparancsokra semmi szükség.

Adatbázis és SQL

A tábla, a sor, a kapcsolat, az elsődleges és az idegen kulcs, az index, a tranzakció és a megkötés. Ha ezeket érted, sokkal könnyebb észrevenni, amikor az AI rossz adatmodellt épít.

Authentication és authorization

Ki vagy, és mit csinálhatsz? Biztonsági szempontból ez az alap.

API-k

Hogyan beszélnek egymással a rendszerek: REST, webhook, JSON, token és terheléskorlát (rate limit).

Framework

Ezután érdemes mélyebben megtanulni egy konkrét technológiát, például a Next.js-t, a Laravelt, a Djangót, vagy amit a munkád indokol.

Security

A bemenő adatok ellenőrzése, az XSS, az SQL-befecskendezés (SQL injection), a CSRF, a titkos kulcsok kezelése, a legkisebb szükséges jogosultság elve és az RLS. Nem kell rögtön behatolásvizsgálónak lenni, de tudnod kell, milyen veszélyeket keress.

Deployment és infrastruktúra

A domain, a DNS, a szerver, a konténer, a környezeti változók, az automatikus élesítés (CI/CD), a naplózás, a felügyelet és a mentés. Egy szoftver nem ér véget ott, hogy a saját gépeden működik.

System design

Ahogy nőnek a projektek, egyre fontosabb látni az egészet: hol legyen az adat, melyik rendszer miért felel, mi történik hiba esetén, mi skálázódik, és hol lesz a szűk keresztmetszet.

Szerintem ezek az ismeretek az AI miatt egyáltalán nem lettek kevésbé fontosak, éppen ellenkezőleg. Minél több kódot tud előállítani helyetted az AI, annál nagyobb rendszert tudsz rövid idő alatt létrehozni, és minél nagyobb rendszert hozol létre, annál drágább lehet, ha nem érted, mit építettél.

Nem kell választani az AI és a „rendes fejlesztés” között

Szerintem ez az egyik legfontosabb tanulság. Az AI nem egy külön fejlesztési módszer, ami majd vagy legyőzi a klasszikus fejlesztést, vagy nem, egyre inkább maga is a fejlesztési folyamat része. Lehet vállalkozó és Lovable, termékmenedzser és Replit, tervező és Bolt, fejlesztő és Claude Code, Laravel, WordPress, Next.js és Supabase vagy saját backend AI-jal. Az a kérdés, hogy jó rendszert építettünk-e vele, és nem az, hogy használtunk-e AI-t.

Miben tudok segíteni?

Azért tartom különösen érdekesnek ezt az időszakot, mert sokkal több út nyílt meg egy üzleti probléma technikai megoldására. Nem minden projekthez kell WordPress vagy Next.js, nem minden MVP-hez kell külön backend, és nem minden Lovable-ben készült alkalmazást kell újraírni. A technológiát szerintem mindig a problémából kell kiválasztani.

Ha van egy ötleted

Lehet, hogy egyelőre csak egy belső eszköz, egy SaaS, egy ügyfélportál vagy egy meglévő weboldal új funkciójának ötlete van meg. Ilyenkor segítek felmérni, milyen technológiai irány ésszerű, és hogyan juthatsz el a leggyorsabban egy mérhető első verzióig. Ha egyedi webalkalmazás vagy belső üzleti rendszer a cél, az egyedi fejlesztés oldalon erről részletesebben is írok.

Ha már építettél egy MVP-t AI-val

Ha a Lovable-ben, a Boltban, a Replitben vagy más eszközzel már elkészült egy működő verzió, nem kell kidobni. Átnézem a kódot, a felépítést, az adatmodellt, a biztonságot, a bejelentkezést, a jogosultságokat, az élesítést, a teszteket és az üzemeltethetőséget, és utána együtt eldöntjük, mi maradjon, és min kell változtatni.

Ha egyáltalán nem akarsz vibe codingolni

Ez is teljesen rendben van. Elmondod, milyen üzleti problémát szeretnél megoldani, a technológiai döntést, a rendszer megtervezését és a fejlesztést pedig rám bízhatod. Az AI-val támogatott fejlesztés előnyeit így is megkapod, csak nem neked kell a fejlesztőeszközökkel, a tervezéssel és az élesítéssel foglalkoznod.

Ha van egy ötleted vagy már működő MVP-d, írj nekem, és megnézzük, mi lenne a következő ésszerű lépés.

Összefoglalás

A vibe coding látványos része, hogy leírsz néhány mondatot, és rövid idő múlva egy működő alkalmazás jelenik meg előtted, szerintem viszont nem ez a legfontosabb változás. A valódi változás az, hogy sokkal kisebb lett a távolság az üzleti probléma és a működő szoftver között. Ez lehetőséget ad a vállalkozóknak, hogy kipróbálják a saját ötleteiket, a cégeknek, hogy olyan belső eszközöket építsenek, amelyek korábban nem térültek volna meg, olcsóbbá teszi a kisebb ügyfélélmény- és felhasználói élmény-fejlesztések kipróbálását, gyorsítja az MVP-k elkészítését, és közben a szakmai fejlesztést is átalakítja.

A kód előállítása egyre olcsóbb, a jó döntés, az architektúra, a biztonság, az üzleti probléma megértése és az éles működésért vállalt felelősség viszont nem lett olcsóbb. Ezért szerintem a következő évek szoftverfejlesztésében egyre ritkábban lesz az a fő kérdés, hogy meg tudjuk-e építeni, mert egyre többször meg tudjuk. Sokkal érdekesebb, hogy érdemes-e megépíteni, milyen technológiával, hogyan tudjuk gyorsan kipróbálni, hogyan mérjük, hogy tényleg értéket teremt-e, és ha bevált, hogyan lesz belőle biztonságos, karbantartható és hosszú távon is működő éles rendszer. Szerintem igazán itt kezdődik az AI utáni szoftverfejlesztés.

Kapcsolódó: Lovable, Bolt vagy Replit? Mire elég és mikor kell fejlesztő · MVP fejlesztés AI-val