Most már értem, mit csinál egy fejlesztő. Amit az AI-val építés tanított

Marketingesként éveken át dolgoztam együtt fejlesztőkkel, láttam kívülről, mit csinálnak. Mégis alábecsültem, mennyi döntés, rendszer-gondolkodás és felelősség van abban, amit szállítanak. Amikor magam kerültem a döntések másik oldalára, más lett a megbecsülésem. Az AI a gépelést vette el, nem a szakmát. Ez a sorozat személyes utószója, a nyitás küszöbén írva, az első valódi vásárlás után: arról, hogy a fejlesztői tudás nem leértékelődött, hanem felértékelődött, hogy a technikai értés kell, de elsajátítható, hogy az éles nap még egyszer megtanít alázatra, és miért nézetem át az egészet szakértővel, mielőtt kinyitok.

A sorozat eddigi részei arról szóltak, mi kell a rajthoz, mennyibe kerül, biztonságos-e és mi a folyamat. Ez a rész más: nem a projektről szól, hanem arról, mit tanultam közben magáról a szakmáról és önmagamról. És mivel épp a nyitás előtt állok, ez nem diadaljelentés, hanem számvetés.

A fejlesztői tudás nem leértékelődött, hanem felértékelődött

Ez a rész önreflexió, úgyhogy őszinte leszek. Kívülről dolgoztam fejlesztőkkel, tudtam, hogy a munkájuk összetett. Amit nem éreztem, az a súlya volt: milyen az, amikor rajtad múlik, hogy a döntés jó-e, és te felelsz azért, ami élesbe kerül. Ezt csak akkor értettem meg igazán, amikor magam kerültem a másik oldalra.

Az AI tényleg elvette a gépelést. De ettől a szakma nem lett kevesebb, hanem a maradék rész lett a lényeg: az ítélet, a rendszer-gondolkodás, a döntés, hogy mi a jó és mi a törékeny megoldás, és a felelősség azért, ami élesbe kerül.

Andrej Karpathy, aki magát a „vibe coding" kifejezést megalkotta, 2026-ban pontosan erről beszélt. A mondatai közül három is fejbe vágott. „A gondolkodásodat kiszervezheted, a megértésedet nem." „A megértés a szűk keresztmetszet, mert nem lehetsz jó rendező, ha nem érted, amit rendezel." És: az AI-ügynökök most olyanok, mint a gyakornokok, a felügyelet, az ízlés és az ítélet a tiéd marad.

Egy másik megfogalmazás még élesebb: az AI megváltoztatta, ki írja az első vázlatot, de azt nem, ki felel azért, ami kimegy. És a felelősség súlya nem elméleti. Az AI-szolgáltatásokban talált sebezhetőségek száma fél év alatt a tízszeresére nőtt. Valakinek meg kell néznie, mit szállított a gép, és ehhez pontosan az a tudás kell, aminek korábban nem éreztem a súlyát.

Volt egy mondat, amit a tizenkettedik héten én mondtam ki, dühösen, az AI-nak, egy dia-kör negyedik javítási menete után: miért követed el ezeket a dühítő amatőr hibákat még mindig? A hibák: keskenyebb panel a doboz fölött, gomb a rossz helyen, üres félvászon, csupa nagybetűs mock, egy kártya fél centivel lejjebb a szomszédjánál. Egyik sem működési hiba, mind átment minden gépi kapun. És miközben kimondtam, leesett, hogy ezt a mondatot fejlesztő-vezetők mondják gyakornoknak, és a válasz sosem a gyakornokban van. Abban van, hogy a senior szeme mit lát, amit egyetlen szabály sem ír le: az egység nem ízlés, hanem fegyelem, és a fegyelem nem abból áll, hogy egy elemet jónak látsz, hanem abból, hogy a szomszédjához méred. Ez a designer és a senior fejlesztő közös szakmája, és ezt is alábecsültem. Ebből is szabály lett és mérő, de a felismerés előbb jött: a hiba nem az AI-é volt, hanem az enyém, mert az összehasonlítást nem kértem tőle, és magam sem csináltam meg.

Ezért most, amikor egy fejlesztő átnézi majd a munkámat, nem védekezve fogok állni, hanem hálásan.

Nem ellentmondás: kell a technikai értés, csak elsajátítható

Itt fel kell oldanom egy látszólagos ellentmondást a saját sorozatomban. Az elején azt írtam, nem kell fejlesztői tudás ahhoz, hogy AI-val építs. Ez igaz, de csak a belépésre. A jó eredményre nem.

A legpontosabb megfogalmazást egy fejlesztői szakmai lapban találtam: a belépési küszöb leszállt, de nem tűnt el. Kódot generálni bárki tud. De kódot generálni és fenntartható szoftvert építeni nem ugyanaz. Menet közben meg kellett tanulnom, hogyan működik egy rendszer: mi az architektúra, mik a függőségek, hol vannak a korlátok, mi az a kompromisszum, amit be kell vállalni. És igen, ez átszövi az egészet: a felület, a felhasználói élmény, a design, az adat, a biztonság, mind kér egy adag technikai értést.

De itt a jó hír, és ez a cikk lényege: ez elsajátítható. Én is menet közben sajátítottam el, kérdésről kérdésre. Van erre egy szép fogalom. A T-alakú szakember egy területen mély, sok területen széles. A Pi-alakú viszont kettőben is mély: nálam ez a marketing ÉS a mostanra megszerzett technikai értés. Pont ez a kombináció az, ami egy marketingesnek az AI-korban nagy előnyt ad.

Egy fontos határ viszont marad. A felszínes, „épp csak veszélyes vagyok" tudásszint elég a zöld zónában (landing, tartalom, katalógus), de nem elég a pirosban, ahol pénz és személyes adat van. Ott vagy mély értés kell, vagy külső szakértő. És ezzel el is érkeztünk a következő ponthoz.

Ezért nézetem át szakértővel, mielőtt kinyitok

Épp a nyitás előtt állok. És mielőtt a platform éles forgalmat kap valódi vásárlókkal, tapasztalt fejlesztővel és biztonsági szemmel átnézetem az egészet. Nem azért, mert a sorozatban leírt szabályaim (a tesztek, a jogosultsági ellenőrzések, a fail-closed elv) ne érnének valamit. Hanem mert a második rész tanulsága pont ez volt: a saját vakfoltodat nem te látod meg.

A nyitás előtti review a legmegtérülőbb lépés, mert egyetlen kiszivárgott kulcs vagy egy rossz jogosultság is elég a bajhoz.

Ha téged is foglalkoztat a saját projekted, itt egy átvehető prelaunch-lista, amit egy szakértő (vagy te magad, egy alapos körben) végigmehet. A lista mellé odaírom, nálam ma mi áll mögötte, mert a lista önmagában csak szándék.

• A titkok (jelszavak, kulcsok) ki vannak véve a kódból ÉS a verziótörténetből is. Nálam a kiadási parancs minden kimenő változást kulcs-mintákra keres, és megáll, ha talál.
• A jelszavak nem nyersen tárolódnak, hanem titkosítva. Nálam jelszó nincs is: belépő link e-mailben.
• Minden védett funkció ellenőrzi, hogy a hívónak van-e joga hozzá. Nálam ezt 42 külön állítás bizonyítja egy eldobható adatbázison, és a felük negatív: kinek NEM szabad látnia. Az a jogosultsági hiba, ami egy hónapig lapult, pont azért maradhatott, mert csak pozitív állítás volt.
• A belépési pontokon van sebesség-korlát a próbálgatás ellen. Nálam ahol pénz mozog vagy levél megy, a korlát kiesésekor a végpont zár, nem nyit.
• Az adatbázis-lekérdezések nem tákolhatók szét kívülről (paraméterezettek). Nálam az adatbázis típusai a kódba generálódnak, és ez a lépés önmagában hét laza pontot buktatott ki.
• A felhasználói bevitel meg van tisztítva, mielőtt megjelenik. És a hibaüzenet sem megy ki nyersen, mert egy adatbázis-hiba táblanevet és oszlopnevet is elárul.
• Van külön fejlesztői, teszt és éles környezet. És a titkos értékek az élesben nem olvashatók vissza, ami jó, de az éles napon pont ez tette nehézzé megtalálni a felcserélt kulcsot.
• A kritikus utakra (belépés, fizetés, mag-funkciók) van automata teszt. Nálam egy szerződés-teszt megköveteli, hogy MINDEN végponthoz legyen teszt, sebesség-korlát és méret-korlát; kivétel csak indoklással.
• A függőségek ismert sebezhetőségekre le vannak ellenőrizve.

Érdekeség, hogy közben új szakma is született erre: a „vibe code takarító" szakértő, akinek egyszerre kell értenie, mit próbált csinálni az AI, és mit kíván valójában a rendszer. Vagyis pontosan az a senior, akit review-ra behívsz. A kör bezárul: az a tudás, amit alábecsültem, most a legértékesebb segítség, amit kaphatok.

Az éles nap, ami megint megtanított

Van egy nap, ami ebbe a cikkbe utólag került, és a legőszintébb része.

A nap, amikor az éles fizetés és a számlázás bekapcsolt. Minden teszt zöld volt, három audit-kör lefutott, a próba-környezetben hetek óta ment minden. Az első valódi, bankkártyás vásárlás mégis háromszor bukott el, mielőtt átment. A két éles titkos kulcs felcserélve került a szerverre, és mert a szerver a titkos értéket nem mutatja vissza, a hibát a napló egyetlen sorából kellett kiolvasni. A belépő e-mail linkje egy elgépelt cím miatt a semmibe mutatott. A számlázó visszautasította a rendelésszámot, mert az ingyenes csomagja nem fogadja. Egyik sem kód-hiba volt, egyik sem tesztelhető, és egyik sem derül ki máshol, csak élesben.

Ez az üzemeltetés szakmája, amit szintén kívülről néztem évekig. A fejlesztő megírja, a rendszergazda működteti, és a kettő közti szakadékban van a legtöbb éles baj. Most már azt is értem, miért van egy jó csapatban külön ember arra, hogy a bekapcsolás napján a naplót olvassa. És miért van kézikönyv, amiben le van írva, hogy a titkos érték nem olvasható vissza, tehát a bekötés sorrendje számít. Nálam ez a kézikönyv is megvan, mert a napból az lett.

A vásárlás átment. A rendszer teljesítette a rendelést, kiállította a számlát, kiküldte a visszaigazolást. És az adatbázisban ott maradt négy próba-vásárlás, amit kézzel kell visszatéríteni és sztornózni, mert ezt a részt nem automatizáltam. Ez is a szakma: tudni, hogy mi marad kézi, és azt le is írni.

A nagy metafora: a siló, ami szétveri a terméket

Van egy analógia, ami szerintem a legjobban megvilágítja, mit is old meg valójában a vibe coding. És nem a kódról szól, hanem a szervezetről.

A cégeknél az üzlet, a fejlesztés és a marketing gyakran nem érti egymás nyelvét. Az üzlet eredményt kér, a fejlesztés korlátokról beszél, a marketing ígéretet tesz, amit a másik kettő nem tud tartani. Ebből a fordítási veszteségből esik szét sok termék. Van erre egy régi szoftveres törvény, Conway törvénye: a szoftver a szervezet kommunikációs szerkezetét tükrözi. Ha a cégben silók vannak, a termék is szétdarabolt és inkonzisztens lesz.

A példák nem elméletiek. A Microsoft Kinectje és Zune-ja is részben azért bukott meg, mert a részlegek nem beszéltek egy nyelvet, és a végén több százmillió dolláros leírás lett belőle. A marketing és az informatika közti súrlódásról pedig kemény adat van: a magas belső súrlódással küzdő cégek jóval ritkábban érik el a bevételi céljukat, és a marketingesek túlnyomó többsége panaszkodik erre a törésre.

És most jön a csattanó. Amikor egy ember fejében nincs siló, mert ugyanaz a fej gondolkodik az üzletről, a marketingről és a megvalósításról, akkor a fordítási veszteség eltűnik. A vibe coding ígérete valójában nem az, hogy nem kell fejlesztő. Az, hogy egy fej beszélheti mindkét nyelvet, és így a termék nem esik szét a részlegek közti résben. Ezt éltem meg: nem kellett átadnom a marketinges szándékot egy fejlesztőnek, mert a szándék és a megvalósítás ugyanabban a fejben volt.

Egy figyelmeztetés viszont idekívánkozik. Az AI felnagyítja azt a szerkezetet, amiben dolgozik. A jó, egységes gondolkodást is, és a rossz, kaotikus silót is. Ezért a híd nem magától épül, hanem attól, hogy hajlandó vagy megtanulni a másik oldal nyelvét.

A valódi motor: tanulás, kíváncsiság, kérdés, iteráció

Ha a végén meg kell neveznem, mi vitt előre, nem a kód lenne a válasz. A kíváncsiság, a jó kérdés és az iteráció. Ezek nem fejlesztői készségek, hanem emberi készségek, és pont ezek voltak meg bennem.

A módszerem végig ugyanaz volt: úgy használtam az AI-t, mint egy interaktív magyarázót. Kérdeztem, és követtem a logikát. Nem fogadtam el a választ, ha nem értettem, hanem visszakérdeztem, amíg értettem. Van erre egy gondolkodásmód, amit growth mindsetnek hívnak, és a lényege egy mondat: a „még nem tudom, de megtanulom" nem gyengeség, hanem erő.

A kíváncsiság a nyitás előtt egy harmadik szakmához is elvitt, amit szintén kívülről tiszteltem: a kontrolleréhez. Két év számláját szedtem össze, 43 sor lett, és abból az AI-val egy 36 hónapos terv, tény és eltérés, amortizációval, cash-flow-val. Az első változatra ránézve azonnal láttam, hogy nem így néz ki egy eredménykimutatás: nincsenek kódolt sorok, nem fentről lefelé épül, nincs EBITDA. Két kör kellett, mire úgy nézett ki, ahogy egy kontrolling-osztály elvárná. Ugyanaz a tanulság, mint a kódnál: a padló lesüllyedt, egy marketinges is meg tudja csinálni, de a mércét a szakma állítja. Nekem itt szerencsém volt, mert évek óta ülök olyan megbeszéléseken, ahol ez a mérce. A kódnál ilyen szerencsém nem volt, és pont ezért kell a külső szem.

A padló lesüllyedt, a plafon nem

Álljon itt az összegzés, a nyitás előtt.

Az AI lejebb vitte a belépés szintjét. Bárki elkezdheti, és ez őszintén jó hír. De a plafont nem. A jó, biztonságos, fenntartható termékhez ugyanaz az ítélet kell, mint mindig. A különbség csak annyi, hogy ezt az ítéletet ma egy kíváncsi marketinges is elsajátíthatja, ha hajlandó tanulni, kérdezni, iterálni, és tudni, mikor kell segítséget kérni.

Én most itt tartok. A nyitás küszöbén, az első valódi vásárlás után, egy szakértői átvizsgálás előtt, és sokkal nagyobb tisztelettel a fejlesztői, a designer, az üzemeltetői és a pénzügyes szakma iránt, mint amikor elkezdtem. Ez talán a legfontosabb, amit az egész projekt adott: nem egy platform, hanem egy megbecsülés, ami korábban hiányzott belőlem.

Ha innen kezdenéd, olvasd el, mi kell egyáltalán a rajthoz. Ha pedig kíváncsi vagy, mit épített ez a folyamat: a kurzusok között ingyenes próbalecke vár, a Nagy Marketingteszten pedig felmérheted, hol tartasz a szakmában.

Felhasznált források

Karpathy, A. (2025). There's a new kind of coding I call "vibe coding". X.

Karpathy, A. (2026). Sequoia Ascent 2026 summary. karpathy.bearblog.dev.

Osmani, A. (2025). Treat AI-generated code as a draft. Elevate (Substack).

Kaspersky (2026). The number of vulnerabilities within AI services surged tenfold in the first half of 2026. Kaspersky.

Wardzinski, T. (2026). The uncomfortable truth about vibe coding. Red Hat Developer.

Brinker, S. (2012). Econsultancy's CEO: Marketing needs pi-shaped people. chiefmartec.

Mishra, S. (2025). Vibe Coding Gives Rise to a New Job: Vibe Code Cleanup Specialist. Indeed.

Conway, M. E. (1968). How Do Committees Invent?. Datamation.

Xenoss (2025). Cross-Functional Team Alignment: Product, Sales and Engineering. Xenoss.

Gartner (2024). Gartner Survey Reveals 84% of Marketers Report Experiencing High 'Collaboration Drag' From Cross-Functional Work. Gartner.

De Libero, G. (2026). Why Marketing-IT Alignment Fails: The Problem Is Structural. How Marketing Technology Works.

Dweck, C. (2014). The power of believing that you can improve. TED.

Di Stefano, G., Gino, F., Pisano, G. P., Staats, B. R. (2014). Learning by Thinking: How Reflection Aids Performance. Harvard Business School Working Paper 14-093, SSRN.