Mi az a vibe coding? Így változik a szoftverfejlesztés az AI korában

Utoljára frissítve: 2026. augusztus 18.

Mi az a vibe coding? Így változik a szoftverfejlesztés az AI korá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, majd 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ó fejlesztése is könnyen annyiba kerülhetett, hogy végül inkább nem készült el.

2026-ban ez már sok esetben egészen máshogy néz ki.

Leírhatod természetes nyelven, hogy milyen alkalmazást szeretnél, és egy AI app builder elkezdi felépíteni. Fejlesztőként pedig már nem csak arra használhatod az AI-t, hogy írjon helyetted egy függvényt vagy segítsen megfejteni egy hibaüzenetet. Egy modern coding agent képes átnézni egy teljes projektet, több fájlt módosítani, parancsokat futtatni, teszteket írni és végrehajtani, majd tovább dolgozni az eredmény alapján.

Ettől még nem lett mindenki szoftverfejlesztő, és a jó szoftver sem lett automatikusan egyszerű.

Ami viszont 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 nem is az, hogy gyorsabban lehet kódot írni.

Az AI azt is megváltoztatja, hogy mit éri meg lefejleszteni.

Ez vállalkozói szempontból legalább olyan érdekes, mint maga a technológia. Olyan belső eszközök, automatizációk, MVP-k, ügyfélélményt javító funkciók és kisebb fejlesztések válhatnak gazdaságossá, amelyek néhány éve egyszerűen túl drágák lettek volna ahhoz képest, amennyi közvetlenül mérhető eredményt hoztak.

Ebben a cikkben ezért nem csak azt nézzük meg, mit jelent a vibe coding. Arról is szó lesz, milyen AI kódoló eszközök vannak, mi a különbség egy Lovable vagy Replit és egy Claude Code között, miből áll valójában egy modern webalkalmazás, mi az a Next.js, Laravel és Supabase, mikor lehet elég egy AI-val ö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. A fogalom eredetileg egy meglehetősen laza fejlesztési módot írt le: természetes nyelven elmondod az AI-nak, mit szeretnél, elfogadod vagy kipróbálod, amit készített, majd újabb promptokkal alakítod tovább.

Nem feltétlenül azzal kezded, hogy megtervezed az adatmodellt, kiválasztod a design patternt és megírod a komponenseket.

Inkább azt mondod:

„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 készít egy első verziót.

Megnézed.

Azt mondod, hogy a projektek inkább kártyák legyenek.

Utána kérsz szűrést.

Majd bejelentkezést.

Aztán adatbázist.

Utána jogosultsági szinteket.

Egyszer csak már nem egy látványterv van előtted, hanem egy működő alkalmazás.

Ez a folyamat nagyon más élmény, mint a klasszikus fejlesztés, ezért is terjedt el ennyire gyorsan a vibe coding kifejezés.

Viszont 2026-ra maga a fogalom is sokkal árnyaltabb lett.

Nem ugyanaz történik akkor, amikor valaki fejlesztői háttér nélkül Lovable-ben összerak egy belső alkalmazást, és akkor, amikor egy tapasztalt fejlesztő Claude Code-dal dolgozik egy több éves Laravel projekten.

Mindkettőben rengeteg kódot írhat AI.

Mindkettőben természetes nyelvű utasításokat használunk.

De a kontroll, az architektúra, a review, a tesztelés és végső soron a felelősség egészen más lehet.

Ezért én különválasztanám a klasszikus vibe codingot és az AI-assisted software engineeringet.

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, aztán iterálunk.

A másodiknál továbbra is szoftverfejlesztési folyamatban gondolkodunk, csak az implementáció jelentős részét AI-val gyorsítjuk.

A kettő között pedig egyre kevésbé van éles 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 kézzel elvégzendő munkát.

Az IDE-k kiegészítették a változóneveket és metódusokat. A Google és a Stack Overflow gyakorlatilag a fejlesztői workflow részévé vált. Később megjelentek az AI-alapú autocomplete eszközök, amelyek már teljes kódrészleteket vagy függvényeket tudtak javasolni.

Ez még alapvetően úgy működött, hogy a fejlesztő írta a kódot, az AI pedig segített.

A coding agenteknél már más a helyzet.

Egy mai agentnek nem feltétlenül azt mondod:

„Írj egy PHP függvényt, ami validál egy email címet.”

Hanem például ezt:

„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 ne dobja el, hanem tegye külön feldolgozási listába, írj hozzá teszteket, majd futtasd le az érintett tesztcsomagot.”

Ehhez az AI-nak már 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 kell módosítania a kódot.

Futtatnia kell a teszteket.

Ha hibát kap, vissza kell mennie és javítania.

Ez már nem egyszerű autocomplete.

Ez egy feladat végrehajtása.

A Claude Code például agentic coding eszközként képes feltérképezni egy kódbázist, több fájlban változtatni, parancsokat és teszteket futtatni, valamint a meglévő fejlesztői eszközökkel együtt dolgozni. Ez jól mutatja, mennyire elmozdultunk a „kérdezz valamit a chatbottól” típusú használattól.

A fejlesztő szerepe ettől nem tűnik el, de változik.

Egyre több idő mehet arra, hogy mit kell megépíteni, hogyan illeszkedjen a rendszerbe, milyen kompromisszumokat vállalunk, hogyan teszteljük és biztonságosan hogyan engedjük ki productionbe.

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

A mai AI-fejlesztési eszközöket szerintem hiba egyetlen listában rangsorolni.

A „Lovable vs Claude Code” például önmagában furcsa összehasonlítás, mert más problémát próbálnak megoldani.

Lovable

A Lovable tipikus példája a prompt-first app builder megközelítésnek.

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. Kifejezetten gyorsan lehet vele eljutni egy ötlettől egy kattintható, majd működő alkalmazásig.

Ez nagyon jó lehet például:

• MVP-khez
• belső eszközökhöz
• egyszerűbb SaaS ötletekhez
• ügyfélportálok első verziójához
• adminfelületekhez
• prototípusokhoz

Fontos változás, hogy az ilyen platformokat már nem érdemes egyszerű mockup-generátorként kezelni.

A Lovable például kétirányú GitHub-integrációt is biztosít. Ez azért fontos, mert a kód nem feltétlenül marad egy bezárt builderben. Egy projekt továbbvihető hagyományos fejlesztői workflow-ba, lehet brancheket használni, code review-t végezni és fejlesztőket bevonni.

Bolt

A Bolt hasonlóan természetes nyelvű leírásból képes működő webes alkalmazásokat létrehozni.

A platform ma már nem csak a frontend generálásáról szól. Adatbázis, autentikáció, szerveroldali funkciók, secret kezelés és más háttérfunkciók is részei lehetnek egy Bolt projektnek.

Ez azért fontos, mert amikor azt mondjuk, hogy „AI builder”, 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 ennél már jóval többről beszélünk.

Replit

A Replit szintén egyre inkább teljes AI-alapú fejlesztési platformként használható.

A Replit saját Agent útmutatója is egy build, Preview-ban történő tesztelés és publish folyamaton vezeti végig a felhasználót:

leírod az ötletet → az Agent megtervezi → felépíti → Preview-ban teszteled → javíttatod → publikálod

Ez hatalmas belépési küszöb csökkenés.

Korábban ahhoz, hogy egy ötletből publikus webalkalmazás legyen, legalább érintőlegesen értened kellett a fejlesztési környezethez, package managerhez, hostinghoz, deploymenthez é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 létrehozni működő szoftvert.

Veszély, mert attól, hogy valamit nem látsz, az még létezik.

Az adatbázisnak továbbra is van struktúrája.

Az autentikációnak vannak biztonsági követelményei.

A deploymentnek továbbra is van infrastruktúrája.

Csak a platform leveszi ezek egy részének kezelését a válladról.

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

A másik világ a coding agentek és AI-val kibővített fejlesztői környezetek világa.

Itt jellemzően már van:

• repository
• Git
• framework
• package manager
• lokális vagy távoli fejlesztési környezet
• adatbázis
• tesztek
• deployment folyamat
• valamilyen kialakított architektúra

A fejlesztő nem feltétlenül azt mondja az AI-nak, hogy „készíts nekem CRM-et”.

Sokkal inkább konkrét fejlesztési feladatokat delegál.

Ez lehet egy új feature, refaktor, hibajavítás, tesztelés, dokumentáció, migráció vagy akár egy nagyobb modul implementációja.

Itt az AI nem feltétlenül a fejlesztési környezetet adja.

Az AI maga válik a fejlesztési 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, hogy vagy builder, vagy klasszikus fejlesztés.

Elkészülhet egy MVP Lovable-ben.

A forráskód bekerülhet GitHubra.

Egy fejlesztő átveheti.

Claude Code-dal átnézheti a projektet.

A kritikus részeket refaktorálhatja.

A meglévő Supabase backend maradhat, vagy bizonyos üzleti logika átkerülhet külön backendbe.

A rendszer kaphat teszteket, monitoringot, CI/CD-t és komolyabb jogosultságkezelést.

Ugyanez fordítva is működik.

Egy fejlesztő is használhat AI buildert arra, hogy nagyon gyorsan kipróbáljon egy UI-koncepciót vagy elkészítsen 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 spektrum van.

A kérdés az, hogy 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 AI builder, é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.

Ide tartozik például:

• login képernyő
• dashboard
• projektlista
• számlák
• gombok
• űrlapok
• mobilnézet
• visszajelző üzenetek

Modern JavaScript alkalmazásoknál ezt gyakran Reacttel vagy valamilyen Reactre épülő frameworkkel készítjük.

Backend

Amikor az ügyfél megnyomja a „Számla letöltése” gombot, valaminek el kell döntenie, hogy valóban hozzáférhet-e ahhoz a számlához.

Amikor üzenetet küld, valaminek el kell mentenie.

Amikor fizet, valaminek kommunikálnia kell a fizetési szolgáltatóval.

Ez már backend feladat.

A backendben található az alkalmazás üzleti logikájának jelentős része.

Adatbázis

Valahol tárolni kell:

• a felhasználókat
• ügyfeleket
• projekteket
• számlákat
• jogosultságokat
• üzeneteket
• státuszokat

Ez az adatbázis.

Egy modern webalkalmazásnál nagyon gyakori valamilyen relációs adatbázis, például PostgreSQL vagy MySQL.

Authentication és authorization

Ezt a kettőt érdemes külön kezelni.

Authentication: ki vagy?

Authorization: mit csinálhatsz?

Attól, hogy valaki sikeresen bejelentkezett, még nem következik, hogy minden adatot láthat.

Egy ügyfélportálnál 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, productionben viszont kritikus.

Storage

A fájlok gyakran nem közvetlenül az adatbázisban vannak.

Dokumentumok, képek, videók és feltöltött fájlok külön object storage rendszerbe kerülhetnek.

Külső API-k

A modern alkalmazások ritkán működnek teljesen önállóan. Sok esetben API-kon, webhookokon vagy külön automatizációs rétegen keresztül kapcsolódnak más rendszerekhez. Ha ez a rész érdekel, külön írtam arról is, mi az az n8n, illetve összehasonlítottam az n8n, Zapier és Make megközelítését.

Kapcsolódhatnak például:

• számlázóhoz
• Stripe-hoz
• CRM-hez
• email szolgáltatóhoz
• AI API-hoz
• logisztikai rendszerhez
• n8n workflow-hoz

Backend és háttérfolyamatok

A backend nem csak az adatbázissal kommunikál és az üzleti logikát futtatja. Itt történik sok olyan művelet is, amit nem akarunk vagy nem is szabad közvetlenül a böngészőre bízni.

Ide tartozhat például:

• jogosultságok ellenőrzése
• külső API-k biztonságos meghívása
• API-kulcsok és más érzékeny adatok használata
• webhookok feldolgozása
• email küldés
• fizetési folyamatok kezelése
• hosszabb háttérfolyamatok indítása

Nem minden feladatot érdemes egy böngészős kérés alatt elvégezni. Ha például feltöltesz egy 100 000 soros CSV-t, a rendszer felveheti a feldolgozást egy queue-ba, majd egy háttérben futó worker dolgozhat rajta.

Hogy ezek pontosan hol futnak, már az alkalmazás architektúrájától függ. Lehet egy hagyományos VPS-en futó Laravel backend, konténerizált szolgáltatás, serverless környezet vagy egy platform által biztosított szerveroldali futtatási környezet.

És valahol mindennek futnia kell

Attól, hogy egy AI builder vagy cloud platform sok technikai részletet elrejt, az alkalmazás mögött továbbra is van infrastruktúra.

Valahol fut a frontend és a backend, valahol működik az adatbázis, valahol tárolódnak a feltöltött fájlok.

Egy production rendszer körül ezért olyan dolgokról is gondoskodni kell, mint:

• hosting és futtatási környezet
• domain és DNS
• HTTPS
• adatbázis
• fájltárolás
• mentések
• rendelkezésre állás
• monitoring
• alkalmazás- és infrastruktúra-logok gyűjtése
• deployment és verzióváltások

A logging jó példa arra, hogy ezek a rétegek összekapcsolódnak. Az alkalmazás generálja a logokat, de azok összegyűjtése, tárolása, kereshetősége és a hibákra épített riasztások már az üzemeltetéshez is tartoznak. A secretek használata szintén alkalmazásoldali kérdés, miközben a biztonságos tárolásukat jellemzően a futtatási környezet vagy egy külön secret manager biztosítja.

Egy olyan platform, mint a Vercel, Supabase, Replit vagy egy AI builder ezekből sok mindent szolgáltatásként adhat. Saját szervernél viszont ezek nagyobb részéről nekünk kell gondoskodnunk.

Az AI-val nem tűnt el az infrastruktúra. Sok esetben egyszerűen magasabb szintű szolgáltatások mögé került, ezért nem nekünk kell közvetlenül üzemeltetni minden egyes rétegét.

Ha saját infrastruktúrán futtatnál webalkalmazást vagy más üzleti rendszert, a rendszerüzemeltetés és a self-hosted eszközök témájával külön is foglalkozom.

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

Gyakran hallani olyan állításokat, hogy az AI mellett hamarosan mindegy lesz, milyen programozási nyelvet vagy frameworköt használunk.

Szerintem ez túlzás.

Lehet, hogy fejlesztőként egyre kevesebb boilerplate kódot írok kézzel, de az alkalmazás továbbra is valamilyen technológiai alapra épül.

A framework meghatározza többek között:

• hogyan szerveződik a projekt
• hogyan kezeljük a routingot
• milyen minták szerint dolgozunk az adatbázissal
• hogyan kezeljük a requesteket
• milyen eszközöket kapunk teszteléshez
• hogyan oldunk meg gyakori problémákat
• milyen ökoszisztémából választhatunk csomagokat

Az AI sokkal gyorsabban tud dolgozni egy jó frameworkben.

De attól még valakinek el kell döntenie, melyik framework illik a problémához.

React és Next.js

A React alapvetően felhasználói felületek építésére szolgáló JavaScript könyvtár.

A Next.js erre épít egy teljes webes frameworköt.

Next.jsben ma már nem csak frontendet lehet készíteni.

Van szerveroldali renderelés, Server Components, Route Handlers, Server Actions és több más szerveroldali képesség.

Ezért teljesen életszerű, hogy egy alkalmazás jelentős része egyetlen Next.js projektben éljen.

Például egy kisebb SaaS-nál lehet:

• Next.js frontend
• Next.js szerveroldali logika
• Supabase adatbázis és auth
• Stripe fizetés
• külső email szolgáltató

És ennyi.

Nincs külön Laravel vagy Node backend.

Ez nem „rossz architektúra” csak azért, mert nincs külön backend repository.

Viszont van egy pont, ahol érdemes elgondolkodni azon, hogy az üzleti logika már önálló backendet kíván-e.

A Next.js dokumentációja full-stack React frameworkként írja le a Next.js-t. Ettől még architekturálisan nem minden rendszerben érdemes az összes backend felelősséget ugyanabba a Next.js alkalmazásba tenni. A framework támogatja a Backend for Frontend mintát, vagyis nagyon jó réteg lehet a frontend és más szolgáltatások között.

Ez nem azt jelenti, hogy Next.jsben nem lehet komoly szerveroldali kódot írni.

Azt jelenti, hogy az architektúrát a rendszer igényei alapján kell megválasztani.

Laravel

A Laravel egy teljes értékű PHP alkalmazásframework.

Én különösen szeretem olyan rendszereknél, ahol maga a backend is jelentős üzleti alkalmazás.

Például egy CRM-nél lehet:

• lead kezelés
• ügyfélkezelés
• státuszok
• jogosultságok
• automatikus folyamatok
• időzített feladatok
• importok
• exportok
• email feldolgozás
• külső API-integrációk
• riportok

Ilyenkor nagyon kényelmes, hogy a Laravel rengeteg jól kialakított eszközt ad ezekhez.

Vegyünk egy egyszerű példát.

Egy ügyfél feltölt egy 50 000 soros Excel vagy CSV fájlt.

Nem akarjuk a teljes importot egyetlen HTTP request alatt végrehajtani.

Laravelben létrehozhatunk jobokat, queue-ba rakhatjuk őket, worker dolgozhat rajtuk a háttérben, kezelhetünk retry-t, timeoutot és hibákat.

A Laravel queue rendszere egységes API-t ad többek között Redis, Amazon SQS és relációs adatbázis alapú queue backendekhez.

Ez nem jelenti azt, hogy ugyanezt Next.js környezetben ne lehetne megoldani.

Meg lehet.

A különbség inkább az, hogy 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 frontend-központú
• viszonylag egyszerű üzleti logikával rendelkezik
• gyors MVP a cél
• sok logikát eleve külső szolgáltatások adnak
• Supabase vagy más backend szolgáltatás kezeli az infrastruktúra jelentős részét

akkor a Next.js önmagában vagy Supabase-szel együtt nagyon jó megoldás lehet.

Ha viszont:

• maga az üzleti logika komplex
• sok háttérfolyamat van
• sok rendszerrel integrálódunk
• hosszú futású jobok vannak
• összetett jogosultságkezelés kell
• több külön kliens használja ugyanazt az API-t
• nagy admin vagy ügyviteli rendszer készül

akkor én gyakran külön backendben gondolkodnék, például Laravelben.

De ezt sem dogmaként.

Lehet olyan nagy rendszer, ahol Next.js tökéletes.

Lehet olyan kis rendszer, ahol Laravel a legegyszerűbb.

És lehet olyan projekt, ahol egyáltalán nincs szükség Next.jsre.

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

Ez is egy gyakori félreértés.

Egy Laravel alkalmazás készülhet például Blade-del, Livewire-rel és Alpine.js-szel.

Ilyenkor egyetlen alkalmazáson belül lehet backend és interaktív frontend.

Egy belső CRM-nél vagy admin rendszernél ez sokszor sokkal egyszerűbb, mint külön React frontendet és külön API backendet fenntartani.

Megint ugyanoda jutunk:

nem a legtrendibb stack a cél, hanem a problémához illő stack.

Mi az a Supabase?

A Supabase neve szinte elkerülhetetlen, ha AI app builderekkel kezdesz dolgozni.

Viszont sokan úgy találkoznak vele, hogy valójában nem teljesen világos, mi is az.

A Supabase nem frontend framework.

Nem is ugyanaz a kategória, mint a Laravel.

A legegyszerűbben úgy lehet elképzelni, mint egy backend platformot, amely több gyakori infrastruktúra-elemet készen ad.

Minden Supabase projekt mögött PostgreSQL adatbázis van.

Ez fontos.

Nem valamilyen saját, elrejtett „AI adatbázist” kapsz, hanem PostgreSQL-t.

Erre épül többek között:

• Auth
• Storage
• Realtime
• Edge Functions
• Data API

Ezért lehet vele elképesztően gyorsan alkalmazást építeni.

Supabase Database

Tegyük fel, hogy ügyfélportált készítünk.

Szükségünk van táblákra:

users

companies

projects

invoices

messages

Ezeket létrehozhatjuk PostgreSQL táblákként.

Kapcsolatokat hozhatunk létre közöttük.

Indexeket készíthetünk.

SQL-t futtathatunk.

Használhatunk Postgres extensionöket.

Tehát nem arról van szó, hogy a Supabase helyettesíti az adatbázist.

A Supabase egyik legfontosabb része maga a Postgres adatbázis.

Supabase Auth

A következő probléma a bejelentkezés.

Nem akarunk minden projekthez saját jelszókezelést, email verifikációt és session rendszert nulláról építeni.

A Supabase Auth kész autentikációs réteget ad.

Lehet például:

• email + jelszó
• magic link
• OTP
• social login
• SSO

A felhasználó bejelentkezik, a rendszer pedig JWT segítségével azonosítani tudja.

De itt jön 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 authorization.

Row Level Security, vagyis RLS

A Supabase egyik nagyon erős, de rosszul konfigurálva veszélyes része a PostgreSQL Row Level Security.

Vegyük az ügyfélportál példáját.

Van egy invoices táblánk.

Ebben minden ügyfél számlája szerepel.

Nem elég azt mondani a frontendnek:

„csak az aktuális user számláit kérd le.”

A frontend a felhasználó gépén fut.

Egy támadó módosíthatja a requestet.

A biztonsági szabálynak az adatbázisnál is érvényesülnie kell.

RLS 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.

Viszont pontosan kell megtervezni.

A Supabase RLS dokumentációja szerint az exposed sémákban lévő táblákon az RLS-t mindig engedélyezni kell, és a policy-k határozzák meg, hogy az egyes szerepkörök mely sorokat olvashatják vagy módosíthatják.

És van egy másik nagyon fontos szabály:

service role vagy secret kulcsot nem teszünk frontendbe.

Ezek megkerülhetik az RLS védelmét.

Egy AI által generált alkalmazásnál pontosan 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, használhatjuk a Storage szolgáltatást.

Itt is jogosultsági szabályok határozhatják meg, hogy ki milyen fájlt érhet el.

Ez megint rengeteg infrastruktúra-munkát spórolhat meg.

Realtime

Bizonyos alkalmazásoknál szükség lehet arra, hogy egy adatváltozás azonnal megjelenjen más felhasználóknál.

Chat.

Élő dashboard.

Státuszváltozás.

Kollaboráció.

A Supabase Realtime ehhez ad kész infrastruktúrát.

Edge Functions

Ha olyan szerveroldali logikára van szükség, amit nem szeretnénk közvetlenül a kliensből végrehajtani, használhatunk Edge Functions funkciókat is.

Például:

• külső API hívás
• secretet igénylő művelet
• webhook feldolgozás
• speciális üzleti logika

Ez tovább árnyalja azt a kijelentést, hogy „Supabase vagy saját backend”.

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ó.

A Supabase production rendszerben is teljesen legitim 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

Például egy SaaS MVP:

• regisztráció
• profil
• néhány CRUD funkció
• fájlfeltöltés
• Stripe
• egyszerű jogosultságok

Itt egy:

Next.js + Supabase

stack nagyon gyors és teljesen életszerű lehet.

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
• komplex számlázási logikát kezel
• több száz háttérjobot futtat
• külön mobilapp használja
• nagy importokat dolgoz fel
• összetett szerepkörökkel rendelkezik
• saját workflow engine-t kapott

Itt már lehet, hogy jobb egy központi alkalmazásbackend.

Például Laravel.

A Supabase akár ekkor is maradhat bizonyos feladatokra.

Nem kell vallást csinálni a stackből.

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

Technológiailag nagyon érdekes, hogy egy agent hány fájlt tud módosítani vagy milyen gyorsan rak össze egy CRUD felületet.

Vállalkozói szempontból szerintem ennél fontosabb dolog történik.

Csökken a szoftver létrehozásának határköltsége.

Korábban egy kisebb funkciónál is számolni kellett:

• specifikációval
• tervezéssel
• fejlesztéssel
• teszteléssel
• javításokkal
• deploymenttel

Ha egy funkció 40 fejlesztői órába került, akkor annak üzletileg indokolhatónak kellett lennie.

Ha nem tudtad megmondani, hogy visszahoz-e több százezer forintot, könnyen azt mondtad:

„jó lenne, de most nem prioritás.”

Így kerültek a backlog végére rengeteg cégnél azok a fejlesztések, amelyek nem létfontosságúak, csak egyszerűen jobbá tennék 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 lennünk benne, 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, vagyis Minimum Viable Product lényege nem az, hogy készítsünk egy rossz, olcsó szoftvert.

A cél az, hogy a lehető legkisebb működő verzióval validáljuk a feltételezésünket.

Tegyük fel, van egy ötleted egy SaaS-ra.

Régen lehet, hogy már az első verzió előtt szükség volt:

• UX tervezésre
• frontend fejlesztésre
• backend fejlesztésre
• adatbázisra
• autentikációra
• hostingra
• deploymentre

Mire az első ügyfél kipróbálta, már jelentős pénz és idő volt benne.

Ma Lovable, Bolt vagy 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-assisted workflow-val lényegesen gyorsabban szállíthatja ugyanazt az MVP-t.

Ez nem garantálja, hogy jó lesz az ötlet.

Pont ez a lényeg.

Olcsóbban tudjuk kideríteni, hogy rossz-e.

Ez óriási előny.

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

Szerintem ez az AI egyik legfontosabb product development hatása.

Korábban egy feature ciklusa lehetett:

ötlet → specifikáció → prioritás → sprint → fejlesztés → QA → release → mérés

Ha maga a fejlesztés drága és lassú, természetesen sokkal óvatosabbak vagyunk azzal kapcsolatban, mit teszünk bele.

Most bizonyos funkcióknál ez lehet:

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

Ez azt jelenti, hogy több hipotézist lehet kipróbálni.

Nem kell minden döntést tárgyalóasztal mellett meghozni.

A felhasználók megmondják a viselkedésükkel.

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

Ez szerintem különösen érdekes.

Vannak funkciók, amelyeknél nagyon könnyű ROI-t számolni.

Ha egy új checkout 15 százalékkal növeli a konverziót, könnyű eldönteni, hogy megéri-e.

De mi van egy olyan funkcióval, amitől csak kényelmesebb lesz az oldal?

Például:

• egy jobb termékválasztó
• egy egyedi kalkulátor
• intelligensebb keresés
• egy ügyfélportálon jobb státuszkövetés
• rendelés utáni önkiszolgáló módosítás
• belső adminban egy tömeges művelet
• automatikus adatkitöltés
• egy dolgozónak napi 10 percet megspóroló gomb

Ezeknek lehet komoly összesített értékük, de nehéz előre pontosan forintosítani.

Ha egy ilyen funkció fejlesztése 1 millió forint, könnyű elengedni.

Ha AI-assisted fejlesztéssel az első verzió sokkal kisebb ráfordítással elkészíthető, már megéri kipróbálni.

Ezért gondolom azt, hogy az AI nem csak gyorsabbá teszi a meglévő fejlesztéseket.

Új fejlesztési kategóriákat tesz gazdaságossá.

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

Ugyanez igaz a belső rendszerekre.

Rengeteg vállalkozás működik úgy, hogy a folyamatok egy része:

• Excelben
• Google Sheetsben
• emailben
• Slack üzenetekben
• különböző SaaS rendszerek között
• manuális másolgatással

él.

Sokszor mindenki tudja, hogy jobb lenne egy saját kis alkalmazás.

Csak eddig nem érte meg lefejleszteni.

Ha egy 8 fős csapatnak kell egy egyszerű belső eszköz, nem biztos, hogy indokolt volt rá több millió forintos egyedi fejlesztést indítani.

AI builderrel vagy AI-assisted fejlesztéssel viszont már teljesen más lehet a matek.

Ez szerintem a következő évek egyik érdekes területe lesz.

Nem feltétlenül a következő Facebook készül el vibe codinggal.

Hanem 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 BBPro Connect rendszere azért érdekes számomra, mert Sándorfy Adrián alapítóként maga fejleszti a saját vállalkozásukhoz készülő rendszert AI-támogatással.

Nem az a lényeg, hogy ettől mindenkinek most 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 ötlet, az első működő funkció és annak valós használatból származó visszajelzése között.

Ha van egy ötlet egy funkcióra, gyorsan el lehet készíteni.

Ki lehet próbálni.

Lehet mérni, hogy használják-e.

Ha releváns, tovább lehet fejleszteni.

Ha nem, el lehet engedni.

A Biznisz Boyz külön podcast epizódban is foglalkozott azzal, hogyan épül saját szoftver AI-val, és szóba kerül benne a vibe coding, a Claude Code és a BBPro Connect is.

Szerintem ez sokkal jobban mutatja az AI fejlesztés valódi lehetőségét, mint az, hogy valaki húsz perc alatt generált egy todo alkalmazást.

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

Itt fontos megállni egy pillanatra.

Az AI körüli kommunikáció hajlamos átmenni abba az irányba, hogy mostantól mindenkinek alkalmazást kell fejlesztenie.

Szerintem ez 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.

Nem zavarja, ha meg kell értenie, mi az a database migration vagy RLS policy.

Neki elképesztő lehetőséget adnak ezek az eszközök.

De van, aki egyszerűen nem ilyen.

Nem akar GitHubot kezelni.

Nem akar promptokkal debugolni.

Nem akarja eldönteni, hogy Next.js vagy Laravel legyen.

Nem akar azon gondolkodni, hogy hol tároljuk a secretet.

És nem is kell.

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

Ez szerintem fontos.

Attól, hogy nem te használod a Claude Code-ot, a fejlesztésed még lehet AI-assisted.

Ha egy fejlesztő vagy fejlesztőcsapat jól használja ezeket az eszközöket, gyorsabban tud:

• prototípust készíteni
• implementálni
• refaktorálni
• teszteket írni
• dokumentációt készíteni
• hibát keresni
• alternatív megoldásokat kipróbálni

Neked vállalkozóként nem feltétlenül kell tudnod, hogyan működik mögötte az AI.

Neked azt kell tudnod:

milyen problémát akarunk megoldani?

Én például ugyanúgy használok AI-val támogatott fejlesztési workflow-kat ügyfélprojektekben.

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 valamilyen más megoldás illik hozzá.

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

Itt jön 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 ügyfelet.

El tudod menteni.

Megjelenik a dashboardon.

Tehát kész?

Nem feltétlenül.

A production szoftvereknél a „működik” csak az egyik követelmény.

Nézzünk néhány kérdést.

Mi történik, ha valaki módosítja a frontend által küldött requestet?

Megnézi-e a backend, hogy jogosult a műveletre?

Hozzáférhet-e egy felhasználó 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?

Mi történik, ha az email API harminc másodpercig nem válaszol?

Van retry?

Van rate limit?

Van backup?

Van monitoring?

Kap valaki értesítést, ha egy background job három napja folyamatosan hibára fut?

Van audit log?

Mi történik, ha egy hibás release adatbázis-migrációt is tartalmaz?

Vissza tudunk állni?

Ezek nem látványos kérdések.

Egy demo videóban nem ezek látszanak.

Productionben viszont sokszor ezek választják el a működő prototípust a megbízható rendszertől.

Authentication nem ugyanaz, mint authorization

AI-val generált alkalmazásoknál ez különösen fontos.

Az authentication azt mondja meg:

ki vagy?

Az authorization azt:

mit csinálhatsz?

Lehet tökéletes login 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, 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 authorization vagy Supabase esetén például a megfelelő RLS.

A frontend nem biztonsági határ

Ez egy olyan alapelv, amit vibe coding mellett mindenkinek érdemes legalább fogalmilag megértenie.

A böngésző a felhasználó gépén fut.

A felhasználó módosíthatja.

Nem bízhatunk abban, hogy azért nem történik meg valami, mert nincs hozzá gomb a felületen.

Ha egy admin funkcióhoz nincs gomb egy normál user képernyőjén, attól az API végpont még létezhet.

A jogosultságot ott kell ellenőrizni, ahol a művelet ténylegesen megtörténik.

Secretek és API-kulcsok

Egy másik tipikus probléma.

Külső AI API.

Stripe secret key.

Email szolgáltató API kulcsa.

Supabase service role.

Ezek nem kerülhetnek csak úgy a frontend bundle-be.

A Supabase dokumentációja is egyértelműen különválasztja a frontendben használható publishable kulcsokat és azokat a secret vagy service role kulcsokat, amelyek megkerülik az RLS-t és ezért csak megbízható szerveroldali környezetben használhatók.

Egy működő alkalmazás ettől még lehet rosszul felépítve.

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

Erre nincs univerzális checklist.

Egy belső szabadságnyilvántartó rendszer és egy pénzügyi alkalmazás kockázata teljesen más.

De általában foglalkozni kell legalább:

• authenticationnel
• authorizationnel
• input validációval
• adatvédelemmel
• secret managementtel
• error handlinggel
• logginggal
• monitoringgal
• backuppal
• dependency frissítésekkel
• tesztekkel
• deploymenttel
• teljesítménnyel
• skálázhatósággal
• jogosultságokkal
• auditálhatósággal

És nem csak azzal, hogy minden jól működik.

A production-ready 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 AI builderben indult, nem következik, hogy rossz.

És attól, hogy egy senior fejlesztő kézzel írta, még nem következik, hogy jó.

A kódot és az architektúrát 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ó?

Van benne rengeteg duplikáció?

Érthető, hogyan működik?

Adatmodell

Jól vannak felépítve a kapcsolatok?

Vannak megfelelő constraint-ek?

Később bővíthető?

Biztonság

Megfelelő az auth?

Jók a jogosultságok?

RLS rendben van?

Nincsenek secretek a kliensben?

Tesztek

Van bármi automatizált ellenőrzés?

A kritikus üzleti folyamatokat lefedi teszt?

Deployment

Reprodukálható?

Tudjuk, milyen környezeti változók kellenek?

Van staging?

Üzemeltetés

Van logging?

Monitoring?

Backup?

Ha ezek rendben vannak, lehet, hogy az alkalmazás nagy része maradhat.

Lehet, hogy csak néhány kritikus részt kell átalakítani.

És 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.

Az MVP feladata az volt, hogy olcsón validá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 + Supabase stacken kellene készülnie.

Ez 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 CMS képességei valódi előnyt jelentenek. A WordPress vs egyedi fejlesztés témát külön cikkben részletesebben is körbejártam.

És WordPressen belül is lehet egyedi fejlesztést végezni.

AI segítségével gyorsabban készülhet:

• saját plugin
• Gutenberg blokk
• WooCommerce módosítás
• REST API integráció
• egyedi adminfelület
• migráció
• import/export
• automatizáció
• CLI script
• 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 nem azt jelenti, hogy minden régi technológia értelmét veszti.

Azt is jelenti, hogy a meglévő platformokra sokkal gazdaságosabban lehet egyedi megoldásokat építeni.

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

Ez talán a legnagyobb kérdés az egész téma körül.

Ha az AI ennyi kódot tud írni, kell még fejlesztő?

Szerintem a kérdés rosszul van feltéve.

A szoftverfejlesztő munkája soha nem csak abból állt, hogy karaktereket gépel egy editorba.

Persze a kódírás fontos része volt.

De a valódi munka jelentős része mindig is:

• problémamegértés
• követelmények tisztázása
• adatmodellezés
• architektúra
• hibakeresés
• kompromisszumok
• security
• integrációk
• tesztelés
• üzemeltetés
• kommunikáció

volt.

Az AI most a kód előállításának költségét nagyon gyorsan csökkenti.

Ettől ezek a többi képességek szerintem nem kevésbé, hanem jobban felértékelődnek.

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

Régebben komoly érték volt, ha valaki fejből tudta egy framework vagy nyelv rengeteg részletét.

Ez ma is hasznos.

De ha az AI két másodperc alatt megmondja a pontos szintaxist, akkor önmagában a memorizált szintaxis kevésbé különböztet meg.

Sokkal fontosabb kérdések lesznek:

Miért ezt az adatmodellt választottad?

Miért kell külön service?

Mi történik concurrency esetén?

Miért nem lehet ezt a műveletet kliensből indítani?

Hogyan kezeljük az idempotenciát?

Mi történik, ha az API nem elérhető?

Hol legyen az üzleti logika?

Milyen adatot szabad logolni?

Hogyan rollbackelünk?

Az AI tud ezekre is válaszokat adni.

De valakinek továbbra is el kell döntenie, hogy a válasz helyes-e az adott rendszerben.

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

Én úgy látom, hogy a fejlesztői munka egyre inkább magasabb absztrakciós szintre kerül.

Kevesebb idő:

„írd meg ezt a 200 sor boilerplate-et.”

Több idő:

„hogyan nézzen ki ez a modul?”

„milyen felelőssége legyen ennek a service-nek?”

„hogyan teszteljük?”

„milyen edge case-ek vannak?”

„biztonságos ez?”

„ezt egyáltalán érdemes saját magunknak megépíteni?”

Ezért szerintem a jó fejlesztők értéke nem eltűnik.

A munkájuk változik.

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

Szerintem igen.

De én már nem ugyanúgy tanulnék, mint tíz éve.

Nem látom sok értelmét annak, hogy valaki hónapokon keresztül 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 alternatív megoldást.

Kérd meg, hogy keressen hibát a saját megoldásában.

De közben értsd meg az alapokat.

Mit érdemes megtanulni az AI korában?

Nem egyetlen frameworköt tanulnék meg vakon.

Inkább egymásra épülő fogalmakat.

Webes alapok

HTML.

CSS.

JavaScript.

Nem kell minden CSS propertyt fejből tudni, de értsd, hogyan működik a böngésző és a web.

HTTP

Request.

Response.

Header.

Cookie.

Status code.

GET.

POST.

Ezek nélkül nagyon nehéz megérteni, mit csinál egy webalkalmazás.

Git

Commit.

Branch.

Merge.

Pull request.

Nem azért, mert menő terminálparancsokat kell tudni.

Hanem mert verziókezelés nélkül komoly fejlesztést végezni AI-val is veszélyes.

Adatbázis és SQL

Table.

Row.

Relation.

Primary key.

Foreign key.

Index.

Transaction.

Constraint.

Ha ezeket érted, sokkal könnyebb észrevenni, amikor az AI rossz adatmodellt épít.

Authentication és authorization

Ki vagy?

Mit csinálhatsz?

Ez security szempontból alap.

API-k

Hogyan kommunikálnak rendszerek egymással?

REST.

Webhook.

JSON.

Token.

Rate limit.

Framework

Ezután érdemes mélyebben megtanulni valamilyen konkrét technológiát.

Next.js.

Laravel.

Django.

Vagy amit a munkád indokol.

Security

Input validation.

XSS.

SQL injection.

CSRF.

Secret management.

Least privilege.

RLS.

Nem kell rögtön penetration testernek lenni.

De tudnod kell, milyen veszélyeket kell keresni.

Deployment és infrastruktúra

Domain.

DNS.

Server.

Container.

Environment variable.

CI/CD.

Logging.

Monitoring.

Backup.

Egy szoftver nem ér véget ott, hogy localhoston működik.

System design

Ahogy nőnek a projektek, egyre fontosabb lesz 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?

Mi lesz bottleneck?

Szerintem ezek az ismeretek az AI miatt nem 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. 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, vagy nem győzi le a klasszikus fejlesztést.

Egyre inkább maga is a fejlesztési folyamat része.

Lehet:

• vállalkozó + Lovable
• product manager + Replit
• designer + Bolt
• fejlesztő + Claude Code
• Laravel + AI
• WordPress + AI
• Next.js + Supabase + AI
• saját backend + AI

A kérdés nem az, hogy használtunk-e AI-t.

A kérdés az, hogy jó rendszert építettünk-e vele.

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 projektnek kell WordPress.

Nem minden projektnek kell Next.js.

Nem minden MVP-hez kell külön backend.

És nem minden Lovable-ben elkészült alkalmazást kell újraírni.

A technológia kiválasztása szerintem mindig a problémából kell, hogy következzen.

Ha van egy ötleted

Lehet, hogy még csak egy belső eszköz ötlete van meg.

Lehet SaaS.

Lehet ügyfélportál.

Lehet egy meglévő weboldalhoz új funkció.

Ilyenkor segítek felmérni, milyen technológiai irány ésszerű, és hogyan lehet a lehető leggyorsabban eljutni egy mérhető első verzióig. Ha egyedi webalkalmazás vagy belső üzleti rendszer a cél, az egyedi webfejlesztés oldalán erről részletesebben is írok.

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

Ha Lovable-ben, Boltban, Replitben vagy más eszközzel már elkészült egy működő verzió, nem kell automatikusan kidobni.

Át lehet nézni:

• a kódot
• az architektúrát
• az adatmodellt
• a securityt
• az authot
• a jogosultságokat
• a deploymentet
• a teszteket
• az üzemeltethetőséget

Ezután lehet eldönteni, 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, rendszertervezést és fejlesztést pedig rám bízhatod.

Az AI-assisted fejlesztés előnyeiből így is profitálsz, csak nem neked kell a fejlesztési eszközökkel, a rendszertervezéssel és az élesítéssel foglalkoznod.

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

Összefoglalás

A vibe coding látványos része az, hogy leírsz néhány mondatot, és rövid idő múlva megjelenik előtted egy működő alkalmazás.

De szerintem 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 vállalkozóknak arra, hogy saját ötleteket próbáljanak ki.

Lehetőséget ad cégeknek arra, hogy olyan belső eszközöket építsenek, amelyek korábban nem térültek volna meg.

Lehetővé teszi, hogy kisebb CX és UX fejlesztéseket olcsóbban teszteljünk.

Gyorsítja az MVP-k elkészítését.

És közben a professzionális fejlesztést is átalakítja.

A kód előállítása egyre olcsóbb.

A jó döntés viszont nem.

Az architektúra nem.

A security nem.

Az üzleti probléma megértése nem.

A production felelősség nem.

Ezért szerintem a következő évek szoftverfejlesztésének legfontosabb kérdése már nem az lesz, hogy:

Meg tudjuk-e építeni?

Egyre többször meg tudjuk.

Sokkal érdekesebb kérdés lesz:

Érdemes-e megépíteni?

Milyen technológiával érdemes megépíteni?

Hogyan tudjuk gyorsan validálni?

Hogyan mérjük, hogy valóban értéket teremt-e?

És ha bevált:

hogyan lesz belőle biztonságos, karbantartható és hosszú távon is működő production rendszer?

Szerintem igazán itt kezdődik az AI utáni szoftverfejlesztés.