Nemcsak szövegíráshoz kell: hogyan használj promptokat UI-generáláshoz, kódfelülvizsgálathoz, SEO-struktúra tervezéséhez és hibakereséshez.
2026-ban már nem az a kérdés, hogy használ-e AI-t a fejlesztőcsapatod. Hanem az, hogy ugyanannyi idő alatt jobb szoftvert szállít-e miatta – vagy csak gyorsabban termeli a technikai adósságot. A prompt engineering ma már fejlesztői alapkészség – és ezzel együtt üzleti kérdés. Mert ha a kód nagy részét már egy modell gépeli, a valódi kérdés nem az, hogy „melyik promptolási trükköt tanuld meg". Hanem az: ki adja hozzá a kontextust, az ítéletet és a felelősséget, ami a legépelt kódból megbízható, skálázódó szoftvert csinál. A kód legépelése olcsó lett. A működő szoftver nem. Ez a cikk arról szól, hol kezdődik az, amit egy gép nem vállal át – és miért pont ez dönti el, mennyit ér a gyorsaság.
És itt a cikk legfontosabb gondolata: az AI nem a fejlesztőt váltja ki. Áthelyezi azt, amiért a fejlesztő munkája értékes – a puszta kódolásról a rendszerszemléletre, a kontextusra és a felelősségvállalásra. Aki ezt a réteget adja, azt az AI nem kisebbé teszi, hanem nélkülözhetetlenné.
Nem szövegíráshoz találták ki
Ha valaki azt mondja, hogy prompt engineering-gel foglalkozik, a legtöbb ember marketingesre vagy tartalomgyártóra gondol. Valakire, aki ChatGPT-vel blogbejegyzéseket ír, vagy kép generátorhoz próbál tökéletes leírást megfogalmazni.
Ez a kép 2026-ban már pontatlan.
A prompt engineering ma a fejlesztők egyik leghasznosabb – és legkevésbé tudatosan használt – eszköze. Nem azzal van a baj, hogy a fejlesztők nem használnak AI-t: a 2025-ös Stack Overflow fejlesztői felmérésben (közel 50 000 válaszadó) a fejlesztők 84%-a használ vagy tervez használni AI-eszközt, és 51%-uk naponta; a JetBrains 2025-ös felmérése pedig 85%-os rendszeres használatot mér. Az AI tehát nem ritkaság a kódbázisokban – hanem alapfelszereltség. A gond az, hogy a legtöbb fejlesztő még mindig autocomplete-ként kezeli ezeket az eszközöket, nem pedig gondolkodó partnerként.
A valóság az, hogy ma már promptokkal generálunk React-komponenseket, debuggolunk, írunk SQL-lekérdezéseket, ellenőrzünk reguláris kifejezéseket, tervezünk SEO-struktúrát, schema markupot és dokumentálunk. Nem véletlen: a feladatok, amelyekhez korábban Google keresés, Stack Overflow és egy szenior kolléga kellett, ma egyetlen jól megírt prompttal megoldhatók – ha tudod, hogyan kell írni.
Ez a cikk nem arról szól, hogyan kérj meg egy AI-t arra, hogy írjon neked egy e-mailt. Arról szól, hogyan legyél hatékonyabb fejlesztő azzal, hogy megtanulod, mikor és hogyan kommunikálj az AI-eszközökkel.
És ha cégvezetőként vagy termékgazdaként olvasod: ez nem belső fejlesztői apróság. Azon múlik, mennyivel lesz tényleg gyorsabb és olcsóbb a következő szállításod – és ki felel, ha a gyorsabban legyártott kód nem jó kód.
Amit a legtöbb fejlesztőcsapat rosszul csinál az elején
Érdemes ezzel kezdeni, mert az összes tanács értékesebb, ha tudjuk, hova vezet a rossz irány.
Amikor egy csapat először kezdi komolyan beépíteni az AI-eszközöket a fejlesztési folyamatába, jellemzően ugyanaz a két hiba jön elő.
Az első: túl rövid prompt. „Írj egy React navbar komponenst." Az AI ír valamit, ami működik, de nem passzol a projekt architektúrájához, nem követi a kódbázis konvencióit, és nem kezeli azokat az edge case-eket, amelyek az adott rendszerben fontosak. Innen két út van: vagy elmegy húsz perc a javításával, vagy megszületik a kényelmes következtetés, hogy „az AI mégsem olyan jó, mint mondják."
A második: az AI-t önálló fejlesztőként kezelik, nem copilotként. Bemegy egy feladat, kijön a kód, és már megy is a commit. Pedig egy junior fejlesztőtől sem fogadna el senki kódot review nélkül – az AI-generált kódtól sem szabadna.
Mindkét hiba ugyanarra vezethető vissza: az AI nem gondolkodik, hanem mintákat követ. Ha a rendszer saját kontextusát nem kapja meg, a legáltalánosabb, legsablonosabb mintát adja vissza. Ez nem az AI hibája. Ez a kommunikáció hibája.
Ezt a két hibát nem tankönyvből ismerjük. Ügyfélprojekteken, napi szinten látjuk viszont – és pontosan ezért kezdünk minden AI-t is használó fejlesztést a kontextus rögzítésével, nem a promptok csiszolgatásával. A tapasztalatunk egyszerű: egy csapat nem a jobb promptoktól lesz gyorsabb, hanem attól, hogy a saját rendszerét át tudja adni az eszköznek.
Nem a prompt a szűk keresztmetszet, hanem a kontextus
Ez az a pont, ahol a legtöbb „prompt engineering tipp" cikk félrevezet.
Azzal foglalkoznak, hogyan kell megfogalmazni a kérést – milyen szavakat használj, milyen sorrendben, milyen technikával. A valóság az, hogy az AI-eszközök 2026-ban elég okosak ahhoz, hogy a megfogalmazáson átlássanak. Amit nem látnak át: amit nem mondasz el nekik.
Ezt nem csak mi gondoljuk. A Bain elemzése szerint a kód megírása és tesztelése a teljes fejlesztési életciklusnak nagyjából csak 25–35%-a – a többi a követelmények megértése, a review, a hibakeresés, a dokumentáció. A prompt a látható, kisebbik részt gyorsítja. A szűk keresztmetszet a láthatatlan, nagyobbik rész – és azt nem prompttal oldod meg, hanem kontextussal.
A kontextus az, ami igazán számít:
- Milyen technológiai stacken dolgozol?
- Mi az architektúra – milyen mintákat követ a projekt?
- Milyen konvenciók vannak a kódbázisban?
- Mi az üzleti cél, amit a feature szolgál?
- Milyen edge case-eket kell kezelni?
- Milyen már létező kóddal kell kompatibilisnek lennie?
Egy tapasztalt szenior fejlesztő, akit felveszel, az első héten nem ír éles kódot. Megismeri a rendszert, kérdez, megérti a kontextust. Az AI-nak ez a „beilleszkedési idő" nincs meg – minden promptnál nulláról indul, ha nem adod meg a szükséges hátteret.
A W5labs-nél ezért nem promptokat dokumentálunk először, hanem rendszereket. Minden projekt elején rögzítjük azt a technikai és üzleti kontextust, amelyet ugyanúgy megkap az új fejlesztő, mint az AI-eszköz. Ettől lesz a generált kód valóban a projekt része, nem egy generikus internetes megoldás.
Egy konkrét példa:
Rossz prompt:
„Írj egy autentikációs middlewaret Node.js-ben."
Jó prompt:
„Express.js alapú API-n dolgozom, JWT-alapú autentikációval. A middleware-nek ellenőriznie kell a Bearer tokent az Authorization headerben, 401-et kell visszaadnia lejárt vagy hiányzó token esetén, és a dekódolt user objektumot a
req.user-be kell tennie a következő handlernek. A projekt TypeScript-alapú, és a jsonwebtoken library-t használjuk. Hibakezelés az általunk használt AppError osztályon keresztül megy."
A különbség nem a megfogalmazásban van. A különbség a kontextusban van. A második prompt nem bonyolultabb – csak pontosabb.
A kontextus többet ér, mint a tökéletes prompt.
Mire használjuk tényleg – a fejlesztői use case-ek
UI-komponensek és layout-generálás
Az egyik leghasznosabb terület, ahol a prompt engineering valóban fejlesztői skillt igényel. A „csinálj egy navbar komponenst" típusú promptok általában generikus eredményt adnak. A jól megírt prompt specifikálja a designrendszert, az összetevőket (Tailwind, shadcn, saját CSS), a responsive viselkedést, az accessibility-követelményeket, és azt, hogy milyen adatstruktúrából dolgozik a komponens.
Egy tipikus jó UI-prompt struktúra:
„React + TypeScript + Tailwind CSS. Csinálj egy kártyakomponenst terméklistához. Props: title (string), price (number), imageUrl (string), badge (optional string). A badge jelenjen meg a bal felső sarokban, ha van. Mobile-first, 2 oszlopos grid szülőben fog megjelenni. A shadcn/ui Card komponensét ne használd, saját implementáció kell."
Rossz prompt: „Csinálj egy responsive navbart React-ben."
Jobb prompt: „React + Tailwind navbar: bal oldalt logó, jobb oldalt négy menüpont egy items tömbből (label, href), 768px alatt hamburger-menü. Az aktuális oldal menüpontja legyen kiemelve. shadcn/ui nélkül, saját komponens, billentyűzettel is bejárható."
Hibakeresés
Az AI hibakeresési képessége meglepően jó – de csak akkor, ha megadod a teljes kontextust. Nem elég bedobni a hibaüzenetet. Szükséges a stacktrace, a releváns kódrészlet, és annak leírása, hogy mit vársz el a kódtól, és mit csinál ehelyett.
Amit sokan kihagynak: az a sor, ami leírja, hogy mit próbáltál már ki. Ez megakadályozza, hogy az AI ugyanazokat a megoldásokat javasolja, amelyeket már elvetettél.
Rossz prompt: „Miért nem működik ez a kód? [kód]"
Jobb prompt: „Ez a függvény néha undefined-et ad vissza, pedig user objektumot várok. Itt a kód és a stacktrace [...]. Node 20, TypeScript, a user.profile az adatbázisban mindig kitöltött. Optional chaininggel már próbáltam, nem segített. Mi lehet az ok?"
Refaktorálás
Az egyik legjobb felhasználási terület, ahol az AI valóban időt spórol. A kulcs: mondd meg, miért refaktorálsz. Olvashatóság? Teljesítmény? Testability? Egy adott tervezési minta bevezetése? Ezek teljesen különböző outputot eredményeznek.
Rossz prompt: „Refaktoráld ezt a komponenst, hogy szebb legyen."
Jobb prompt: „Refaktoráld ezt a komponenst tesztelhetőségre: válaszd külön az adatlekérést a megjelenítéstől, hogy a logikát külön unit-tesztelni lehessen. A működés és a props maradjon ugyanaz, csak a szerkezet változzon."
SQL-lekérdezések és regex
Két olyan terület, ahol a fejlesztők rendszeresen bajba kerülnek, és ahol az AI kiemelkedően hasznos – ha megadod a séma kontextusát és leírod pontosan, mit kell visszaadnia a lekérdezésnek. Regex esetén mindig add meg a konkrét input-output párokat.
Rossz prompt: „Írj egy lekérdezést a legjobb vásárlókról."
Jobb prompt: „PostgreSQL. Adott az users (id, name) és az orders (id, user_id, created_at, total, status) tábla. Add vissza azt a 10 vásárlót, akik 2025-ben a legtöbbet költötték – névvel és összeggel, csökkenő sorrendben. Csak a status = 'completed' rendelések számítsanak."
SEO struktúra és schema markup
Kevesen gondolnak erre, de a prompt engineering az egyik leghasznosabb eszköz a technikai SEO tervezésnél. Az AI segíthet tartalmi klaszterek felépítésében, FAQ schema generálásában, breadcrumb struktúra tervezésében, hreflang implementáció ellenőrzésében – ha megadod a tartalom kontextusát és az üzleti célt.
Egy schema markup generáláshoz hasznos prompt struktúra:
„JSON-LD schema markupot szeretnék generálni egy ügyvédi irodának. Az oldal egy konkrét szolgáltatást mutat be (ingatlan adásvétel). A cég neve, telefonszáma és cím adott. Adj JSON-LD-t, amely tartalmazza a LocalBusiness és a Service schema kombinációját, Schema.org validáció szerint."
Rossz prompt: „Csinálj egy FAQ schémát az oldalhoz."
Jobb prompt: „Generálj JSON-LD FAQPage schémát ehhez a négy, az oldalon ténylegesen megjelenő kérdés-válasz párhoz [lista]. A szöveg maradjon szó szerint azonos a látható tartalommal, ne találj ki új kérdéseket, és Schema.org szerint validáljon."
Dokumentáció és tesztek
Két olyan feladat, amelyet fejlesztők általában halogatnak, és amelyekre az AI meglepően jó – különösen ha a kódot is odaadod kontextusként, nem csak leírod szavakkal.
Rossz prompt: „Írj teszteket ehhez a függvényhez."
Jobb prompt: „Írj Jest unit-teszteket ehhez a függvényhez [kód]. Térj ki a határesetekre is: üres input, null, túl nagy érték. Kövesd a meglévő tesztstílusunkat (describe/it blokkok, AAA-minta), és mockold a külső API-hívást."
Hogyan épül fel egy jó fejlesztői prompt
Nincs egyetlen univerzális sablon, de van egy gondolkodásmód, ami következetesen jobb eredményt ad.
1. Szerepkör és eszközkontextus – Mondd meg az AI-nak, milyen rendszerben dolgozol. Framework, library-k, TypeScript vagy JavaScript, meglévő konvenciók.
2. A feladat pontos leírása – Nem az, hogy „csinálj valamit", hanem az, hogy mit kell a kódnak csinálnia, milyen inputot kap, milyen outputot ad vissza.
3. Korlátok és elvárások – Mit ne csináljon. Milyen library-t ne használjon. Milyen megközelítést kerüljön el. Ez sokszor fontosabb, mint a pozitív elvárások.
4. Edge case-ek és hibakezelés – Ha tudod, hogy milyen peremfeltételekkel kell számolni, mondd el előre.
5. Output formátum – Kérsz kommenteket a kódhoz? TypeScript típusokat? Teszt kódot is? Ezt is érdemes specifikálni.
Ez nem bonyolultabb annál, mint megmagyarázni a feladatot egy új csapattagnak. Éppen ezért nem varázslat – kommunikációs design.
A prompt nem varázslat. Kommunikáció.
Ahol az AI még mindig elveszíti a fonalat
Az AI-eszközök 2026-ban lenyűgözően hasznosak, de van néhány terület, ahol a humán beavatkozás nem helyettesíthető.
És ez nem hangulati óvatosság – ezt mérik is. A Stack Overflow 2025-ös felmérésében a fejlesztők legnagyobb frusztrációja (66%) a „majdnem jó, de mégsem" AI-megoldás, és 45% szerint az AI-kód hibakeresése több időbe telik, mint amennyit megspórol. A METR 2025-ös kontrollált kísérletében a tapasztalt fejlesztők 19%-kal lassabban végeztek AI-val – miközben úgy érezték, 20%-kal gyorsabbak. Ez a 39 pontos szakadék az érzés és a valóság között pontosan az a réteg, amit a gép nem lát: a rendszer egésze és a saját ítéleted.
Architektúrális döntések. Az AI jó a megvalósításban, de nem látja az egész rendszert. Ha egy döntés hosszú távon hat a skálázhatóságra, a karbantarthatóságra vagy a biztonsági modellre, azt embernek kell meghoznia. Az AI véleményt tud adni, de az üzleti és technikai tradeoffokat te látod, nem ő.
Üzleti logika értelmezése. Az AI nem tudja, hogy az active mező az adatbázisban mit jelent az üzleti folyamatban, ha nem mondod el. A domain tudás a fejlesztőben van – és ennek hiányában az AI elfogadható, de helytelen kódot generál.
Kódbázis teljes megértése. A context window véges. Ha egy projekt több ezer soros, az AI csak töredékét látja. Cursor és Claude Code projektszintű kontextussal dolgoznak ezen – de az összképet a fejlesztő tartja a fejében.
Kódfelülvizsgálat. Az AI-generált kódot mindig review-zni kell. Nem azért, mert rossz – hanem mert átmehet az összes teszten és mégis nem illeszkedik a rendszer elvárásaihoz, biztonsági modelljéhez, vagy konvencióihoz. Egy junior fejlesztő kódját sem küldenéd review nélkül.
A megnevezett ellenfél: a review nélküli „vibe coding"
A GitHub 2025-ös Octoverse jelentésében a Broken Access Control – a hibás jogosultságkezelés – lett az első számú CodeQL biztonsági riasztás, több mint 151 000 repóban. Nem véletlen: az AI-asszisztált „vibe coding" gyakran olyan végpontokat generál, amelyek kinéznek helyesnek, de hiányzik belőlük a kritikus jogosultság-ellenőrzés. Az ilyen kód átmegy minden teszten – és pont ott nyit kaput, ahol a legnagyobbat lehet bukni: éles adat, valódi felhasználók, valódi jogi felelősség mellett. Aki review nélkül szállítja az AI kódját, nem időt spórol. Kockázatot szállít.
A legdrágább AI-kód az, amit review nélkül élesítenek.
Cursor, Claude Code, GitHub Copilot – melyiket mikor
Az eszközök megválasztása valójában másodlagos kérdés a gondolkodásmódhoz képest – de praktikus szempontból érdemes látni a különbségeket.
GitHub Copilot – a legelterjedtebb, mélyen integrált a VS Code és JetBrains ökoszisztémába. Erős az autocomplete-ben és a kisebb feladatokban. Ha már egyébként is a GitHub ecosystemben élsz, az első természetes választás.
Cursor – az az eszköz, amit azok preferálnak, akik projektszintű kontextussal akarnak dolgozni. Az egész kódbázisba bele tud látni, ami azt jelenti, hogy nem kell minden prompthoz manuálisan bemásolni a releváns kódrészleteket. A Composer funkciója multi-file változtatásokra alkalmas.
Claude Code – egy terminálalapú agentic eszköz, amely a komplexebb, több lépéses feladatokban erős, és az angol nyelvű piacokon különösen gyorsan terjed. Azoknak ajánlott, akik komplexebb, több lépéses feladatokat akarnak AI-jal megoldani, és kényelmesen dolgoznak terminálos környezetben.
A lényeg: az eszköz másodlagos. Az elsődleges a kontextus, amit adsz neki.
A legtöbb cégvezetőt nem az érdekli, hogy Cursorral vagy Claude Code-dal készült-e a kód. Az érdekli, hogy időben elkészül-e a projekt, biztonságos-e a rendszer, és egy év múlva is fejleszthető marad-e. Az AI csak akkor jelent valódi üzleti előnyt, ha ezeken javít – nem pedig csak gyorsabban termeli ugyanazokat a hibákat.
Saját tapasztalat: hogyan használjuk ezt napi szinten
Legyünk őszinték: a rutinfeladatok – komponensvázak, tesztek, SQL-lekérdezések, schema markup – jelentős részét ma már nálunk is az AI gépeli. A kérdés sosem az, hogy használjuk-e. Hanem az, hogy mi marad az emberre – és a válasz pontosan az, amiről ez a cikk szól: a kontextus, a rendszerszintű döntések és a review. Az AI gyorsítja a munkát; attól, hogy a végeredmény vállalható, még ember lesz.
A prompt engineering és a rendszerszemlélet
Van egy tágabb gondolat, ami mögött az egész téma áll – és ami a fejlesztőknek szóló prompt engineering egyedi nézőpontja.
A legjobb fejlesztők nem azért jók az AI-eszközökkel, mert megtanultak valami speciális promptolási trükköt. Azért jók, mert rendszerszemléletben gondolkodnak. Tudják, mit akarnak elérni, milyen kontextusban, milyen korlátokkal. Ez az, amit az AI-nak át tudnak adni – és pontosan ezért kapnak jobb eredményt.
A prompt engineering tehát közelebb áll a rendszertervezéshez, mint a copywriting-hoz. Nem az a kérdés, hogyan kéred meg az AI-t – hanem az, hogy te magad mennyire érted a feladatot, amelyet delegálni akarsz.
Ez a gondolat vezet el egy praktikus következtetéshez: a prompt engineering nem az AI-t teszi okosabbá. A te gondolkodásodat teszi strukturáltabbá. Ha egy feladatot nem tudsz világosan leírni egy promptban, valószínűleg magáról a feladatról is van egy-két tisztázatlan pont.
Ebből a nézőpontból a prompt engineering egy fejlesztői önfejlesztési eszköz – amelynek mellékes hozadéka, hogy az AI-tól is jobb kódot kapsz.
Az AI a kódot írja. A rendszert továbbra is az ember tervezi.
Érdemes kimondani, mert ez a cikk legfontosabb állítása: az AI nem kiváltja a fejlesztőt – áthelyezi az értékét. A puszta gépelés értéke lecsökken; a rendszerszemléleté, a kontextusé és a felelősségvállalásé viszont felmegy. Aki csak sorokat írt, azt szorítja az AI. Aki rendszert tervez, azt felerősíti.
A jó prompt és az AI-láthatóság ugyanarról szól
Érdemes egy lépéssel tágítani a képet. Ugyanaz a készség – érthetően átadni a kontextust –, amivel egy fejlesztő jó kódot kap egy modelltől, dönt abban is, hogy a céged tartalmát megértik-e az AI-keresők. Ahogy egyre többen kérdeznek a ChatGPT-től, a Google AI-összefoglalójától vagy a Perplexitytől ahelyett, hogy tíz kék linket néznének végig, úgy lesz egyre fontosabb, hogy az oldalad gép számára is értelmezhető legyen.
Valójában ugyanarról a készségről beszélünk. Ahogy egy AI-modellnek kontextus kell ahhoz, hogy jó kódot írjon, ugyanúgy a ChatGPT-nek vagy a Gemini-nek is strukturált kontextus kell ahhoz, hogy megértse a weboldaladat. A prompt engineering és az AI Visibility ugyanannak a gondolkodásmódnak két különböző alkalmazása.
Ezt hívják AI Visibilitynek (vagy GEO-nak, generatív motoroptimalizálásnak): a strukturált tartalom, a tiszta címhierarchia, a schema markup és a jól tagolt, válaszorientált szövegek nem csak a klasszikus SEO-nak szólnak. Ezek mondják meg az AI-modelleknek, miről szól az oldalad, és mikor érdemes téged idézniük. A jól megírt prompt és a jól strukturált weboldal mögött ugyanaz a logika áll: aki érthetően adja át a kontextust, jobb eredményt kap – akár egy modelltől, akár egy AI-keresőtől.
Ez nem laza párhuzam, hanem ugyanaz a készség két helyen. Amikor egy fejlesztő pontos kontextust ad egy modellnek, jobb kódot kap. Amikor ugyanezt a pontosságot a weboldal szerkezetébe építjük – tiszta címhierarchia, schema markup, válaszorientált szövegek –, az AI-keresők jobban megértik, miről szól az oldalad, és nagyobb eséllyel idéznek. Aki képes érthetően átadni a kontextust, az egyszerre kap jobb kódot az AI-tól és jobb láthatóságot az AI-keresőkben. Nálunk ez egyetlen diszciplína: nem külön csapat írja a promptot és külön az AI számára is olvasható oldalt – ugyanaz a rendszerszemlélet hajtja mindkettőt.
Mikor éri meg minket bevonni
Itt lép be az ügynökség – nem azért, hogy promptot írjon helyetted, hanem azért, hogy meglegyen az a réteg, amit a gép nem ad. Az AI-generált kódot úgy nézzük át, mint egy junior kolléga munkáját: nem azért, mert eleve rossz, hanem mert átmehet minden teszten, és mégsem illik a rendszer biztonsági modelljéhez, konvencióihoz vagy üzleti logikájához.
Egy magyar kkv-döntéshozónak ráadásul nem az a kérdés, melyik eszközt vegye licencre. Hanem az: ki felel a leszállított rendszerért, amikor élesben, valódi ügyfelekkel kell működnie. A licencet bárki megveszi. A felelősséget nem a licenc vállalja.
És itt a lényeg, amiben mások vagyunk: mi nem promptokat írunk és nem AI-eszközöket vezetünk be. Olyan digitális rendszereket tervezünk, amelyekben az AI gyorsítja a fejlesztést – de a minőségért, a biztonságért és a végeredményért továbbra is mi vállaljuk a felelősséget. Az eszközt bárki megveszi; a felelősséget kevesen vállalják a nevükkel. Mi igen.
A kód legépelése olcsó lett. A működő, megbízható szoftver nem. A munka egy részét hozza a gép – a maradékért, és a felelősségért, ember felel. Mi pedig pontosan azok vagyunk, akik őszintén megmondják, ha az AI önmagában elég – és azok is, akik a nevüket adják az eredményhez, ha nem.
Ha a következő projekted ott mozog, ahol a gyors kódból megbízható rendszernek kell lennie – ahol valakinek a nevét és a felelősségét kell az eredmény mögé tennie –, beszélgessünk róla.
