Majú firmy naskočiť na vlnu vibe codingu?

Má firma naskočiť na vlnu vibe codingu? A má poslať zamestnancov na školenie vibe codingu? Naša odpoveď v oboch prípadoch znie, že to závisí od toho, čo od toho firma očakáva. Opierame sa pri tom o rozhovor s Tomášom Lodňanom, výkonným riaditeľom softvérovej firmy GoodRequest, a o výskumy bezpečnosti a kvality kódu vytvoreného pomocou AI.

Pre vedenie je dôležité odpovedať na niekoľko otázok skôr, ako prvá takáto aplikácia začne pracovať s reálnymi údajmi. Čo má aplikácia firme priniesť? Kto sa o ňu bude starať, keď ju začnú používať kolegovia alebo zákazníci? A koľko bude stáť jej prevádzka a údržba?

Čo je vibe coding a ako ho vidí prax

Pojem vibe coding zaviedol vo februári 2025 Andrej Karpathy, jeden zo zakladajúcich členov OpenAI. Slovník Collins ho neskôr vyhlásil za slovo roka 2025. Karpathy ním opisoval tvorbu softvéru, pri ktorej človek zadáva požiadavky AI a prijíma výsledok bez dôsledného čítania a kontroly kódu. Nie je to preto synonymum každého vývoja s pomocou AI. Ak vývojár kód kontroluje, testuje a zodpovedá za jeho návrh, ide o iný spôsob práce než o pôvodný Karpathyho opis.

Nástroje ako Lovable, Cursor alebo Claude Code môžu pomôcť vytvoriť prototyp aj ľuďom bez programátorskej praxe. Čas a výsledok však závisia od zadania a potrebnej kontroly, nie od samotného výberu nástroja.

O príležitostiach aj limitoch tohto prístupu hovoril Tomáš Lodňan v podcaste Žijeme Sci-Fi. Z rozhovoru vyberáme tri myšlienky, ktoré považujeme za dôležité pre vedenie malých a stredných podnikov (MSP).

• Prototyp môže pomôcť spresniť zadanie. Klienti podľa Lodňana prichádzajú s klikateľnou ukážkou, vďaka ktorej dokážu lepšie vysvetliť, čo chcú postaviť. Dodávateľ tak môže nadviazať na konkrétnejšie zadanie.
• Netechnický manažér nemusí vidieť, čo prototyp nerieši. Aplikácia môže interne pracovať s údajmi a objednávkami, no nemusí mať vyriešené škálovanie, zálohovanie ani prístupové práva. Lodňan to ilustruje príkladom nesprávne nastaveného prístupu k mzdovým údajom.
• Vibe-codnutej aplikácii môže chýbať oponent. Pri štandardnom vývoji prechádza kód kontrolou ďalšieho vývojára, testovacím prostredím a automatizovanými kontrolami. Aplikáciu, ktorú človek večer vytvorí a zverejní, nemusel vidieť nikto iný. Pri kontrolách aplikácií niektorých startupov podľa Lodňana našli vážne bezpečnostné nedostatky.

CEO GoodRequestu zároveň vibe coding nezatracuje. Programovanie podľa neho prestáva byť výsadou úzkej skupiny ľudí, firmy by mali s novými nástrojmi experimentovať a vedenie by malo ísť príkladom. Zdôrazňuje však aj potrebu rozpoznať limity vlastného riešenia a prizvať odborného partnera. Prirovnáva to k situácii, keď doma tečie voda a človek si zavolá inštalatéra. V rozhovore hovorí aj o zlepšovaní nástrojov a o tom, ako jasné zadanie, kontext a kontroly pomáhajú kvalite výsledku.

Opatrnosť pri práci s AI zachytáva aj Stack Overflow Developer Survey 2026. Zo 14 304 respondentov otázky o dôvere uviedlo 48 %, že AI dôverujú vtedy, keď si výstup môžu ľahko overiť. Dôveru pri mnohých úlohách vrátane dôležitých pracovných rozhodnutí deklarovalo 6,6 %. Ide o postoje dobrovoľne zapojených respondentov, nie o meranie bezpečnosti ich kódu ani o reprezentatívny obraz všetkých vývojárov.

Dôvera respondentov v AI závisí od možnosti overiť výstup.

• Dôverujem, keď môžem výstup ľahko overiť48 %
• Dôverujem pri mnohých úlohách vrátane dôležitých pracovných rozhodnutí6,6 %

Treba dodať, že GoodRequest ako dodávateľ softvéru má na tejto téme aj obchodný záujem. Jeho pohľad preto v ďalších častiach dopĺňame akademickými štúdiami a meraniami či prieskumami dodávateľov. Aj bezpečnostné firmy Veracode a Escape a konzultačná spoločnosť BCG majú na téme obchodný záujem. Ich zistenia preto čítame spolu s metodikou a jej obmedzeniami.

Náš pohľad: rozhoduje, čo od aplikácie firma očakáva

V tomto článku sa venujeme najmä situácii, keď zamestnanec alebo manažér pomocou AI nástroja vytvorí aplikáciu alebo automatizáciu pre vlastnú prácu či pre tím. Samotné programátorské vzdelanie neurčuje, či ide o vibe coding. Podstatné je aj to, ako človek výsledku rozumie a ako ho kontroluje. Na otázku, či má firma na túto vlnu naskočiť, preto odpovedáme áno aj nie. Rozhodujúce je, čo má aplikácia firme priniesť a v akej fáze sa nachádza.

Ako vhodný krok v MSP vidíme tvorbu prototypov pomocou AI v dvoch situáciách. Prvou je overenie nápadu skôr, ako firma investuje do vývoja. Druhou je spôsob, akým si zamestnanci vyskúšajú možnosti a limity AI pri vlastnej práci.

Zároveň berieme vážne riziko, že sa experiment nenápadne zmení na systém, na ktorom stojí časť firemných procesov, bez toho, aby ktokoľvek rozhodol, kto zaň zodpovedá. Takáto aplikácia potom môže pracovať s údajmi zákazníkov alebo zamestnancov, no nikto ju neudržiava, nekontroluje jej bezpečnosť a nevie, ako by sa obnovila po výpadku.

V ďalších častiach preto rozoberáme tri otázky, ktoré by si malo vedenie položiť: čo má aplikácia priniesť, kto sa o ňu postará a kedy a s akým očakávaním poslať zamestnancov na školenie vibe codingu.

Otázka 1: Čo má aplikácia firme priniesť?

Rovnaký nástroj môže slúžiť na krátky experiment aj na systém, s ktorým pracujú zákazníci. Nároky na bezpečnosť a starostlivosť sa pritom medzi týmito situáciami výrazne líšia. Pre rozhodovanie vedenia preto odporúčame rozlišovať tri úrovne.

Tabuľku môžete posunúť do strany →

Ide o naše orientačné rozdelenie, nie o úplný bezpečnostný zoznam. Aj interný nástroj môže byť pre firmu kritický. Rozhoduje citlivosť údajov, oprávnenia a následok zlyhania, nie iba počet používateľov alebo označenie „interný“.

GoodRequest odporúča zvýšiť pozornosť najmä v troch situáciách: do aplikácie vstúpia reálne údaje, aplikácia sa sprístupní cez internet alebo sa prepojí s ďalšími firemnými systémami. Prístupové kľúče k iným systémom totiž môžu otvoriť cestu aj k údajom, ktoré s pôvodnou aplikáciou nesúvisia.

Predtým, ako firma začne stavať, sa oplatí overiť aj to, či problém nerieši existujúci nástroj alebo jednoduché prepojenie systémov, ktoré firma už používa. Vlastná aplikácia totiž prináša aj vlastnú starostlivosť. Ak sa firma rozhodne stavať, odporúčame pred začatím odpovedať na päť otázok:

1. Akú úlohu aplikácia rieši a koľko času alebo chýb dnes táto úloha stojí?
2. Kto bude aplikáciu používať a čo každý z používateľov smie vidieť?
3. Aké údaje do nej vstúpia, najmä či pôjde o osobné údaje zákazníkov alebo zamestnancov?
4. S akými systémami, účtami alebo službami sa bude prepájať?
5. Čo sa stane, keď aplikácia prestane fungovať, a kto ju opraví?

Prvá otázka má aj praktický význam. Ak firma pozná východiskový stav, môže po niekoľkých týždňoch overiť, či aplikácia naozaj priniesla úsporu, a rozhodnúť, či sa oplatí investovať do jej ďalšieho rozvoja.

Otázka 2: Kto sa o aplikáciu postará?

Keď aplikáciu začnú používať kolegovia alebo zákazníci, vznikajú nároky, ktoré pri prototype nebolo vidieť: bezpečnosť, zálohy, prístupové práva, opravy chýb a požiadavky na nové funkcie. Ak ich firma prehliadne, môže neskôr platiť za nápravu problémov, ktorým sa dalo predísť plánovanou starostlivosťou.

Čo hovoria výskumy o bezpečnosti a údržbe

• V benchmarku Veracode zostala priemerná bezpečnostná úspešnosť podobná. Bezpečnostná firma v roku 2025 otestovala viac ako 100 jazykových modelov na 80 vybraných programátorských úlohách a približne 45 % testovaných výstupov obsahovalo zraniteľnosť. V správe za rok 2026 uvádza 44 % a priemernú bezpečnostnú úspešnosť 56 %. Ide o laboratórne testy vybraných bezpečnostných úloh bez výslovných bezpečnostných pokynov, nie o meranie celých aplikácií alebo podiel zraniteľného kódu vo firmách. Výsledky sa líšia podľa modelu a typu chyby, preto podobný priemer neznamená, že bezpečnosť všetkých modelov stagnuje.
• Funkčný výsledok AI agenta nemusí prejsť bezpečnostnými testami. Zhao a kolektív v aktuálnej verzii benchmarku SUSVIBES (v4 z 21. septembra 2026, príspevok prijatý na ICML 2026) skúmali 186 bezpečnostne citlivých úloh z Python projektov. Úlohy vychádzajú z funkcií, pri ktorých ľudskí programátori v minulosti vytvorili zraniteľný kód. SWE-agent s Claude 4 Sonnet prešiel funkčnými testami pri 57 % úloh a funkčnými aj bezpečnostnými testami pri 11,8 %. Obe percentá sa vzťahujú na všetkých 186 úloh. Doplnenie bezpečnostných pokynov bezpečnostnú úspešnosť čiastočne zlepšilo, ale sprevádzal ho pokles funkčnej úspešnosti. Testovanie na úrovni repozitára zachytáva aj úpravy viacerých súborov, nejde však o reprezentatívnu vzorku firemných aplikácií a úspech v testoch nie je zárukou úplnej bezpečnosti.
• Opakované úpravy cez AI môžu bezpečnosť zhoršiť. Shukla, Joshi a Syed (2025, recenzovaný príspevok konferencie IEEE ISTAS) nechali GPT-4o opakovane upravovať desať východiskových ukážok kódu v C a Jave. Pri štyroch stratégiách zadávania a desiatich iteráciách vzniklo 400 výstupov. Bez ľudských zásahov medzi iteráciami pribúdali aj nové zraniteľnosti. Bezpečnostne orientované zadania však mali menej nálezov než zadania na pridávanie funkcií a niektoré iterácie bezpečnosť zlepšili. Výsledok preto nemožno preniesť na všetky modely ani na vývoj s odborným dohľadom.
• Problémy sa objavujú aj v nasadených aplikáciách. Bezpečnostná firma Escape (2025) vo svojej jednorazovej vzorke 5 600 verejne dostupných vibe-codnutých aplikácií uvádza 2 038 zraniteľností, ktoré označuje za vysoko kritické, v približne 1 400 aplikáciách. Zistila aj viac ako 400 odhalených tajomstiev a 175 prípadov sprístupnenia osobných údajov vrátane bankových. Aplikácie zbierala z verejných katalógov, vyhľadávania a komunít, výrazne medzi nimi prevažoval Lovable. Automatizované skenovanie doplnila ručnou kontrolou časti nálezov. Nešlo o reprezentatívnu vzorku ani o porovnanie s aplikáciami vytvorenými bez AI a výsledky opisujú stav v čase merania.
• Aj historické údaje ukazujú význam údržby. Lientz, Swanson a Tompkins (1978, Communications of the ACM) získali odpovede od 69 organizácií. Manažéri odhadovali, že na údržbu a rozširovanie existujúcich systémov pripadalo 48 % ročných personálnych hodín a na nový vývoj 46,1 %. Za najväčší manažérsky problém považovali požiadavky používateľov na nové funkcie. Ide o historické dotazníkové odhady, nie o meranie dnešného vývoja alebo nákladov AI aplikácií. Ilustrujú však, že používaná aplikácia prináša aj nároky na údržbu a nové požiadavky.

Funkčný výsledok ešte nemusí prejsť bezpečnostnými testami.

• Prešli funkčnými testami57 %
• Prešli funkčnými aj bezpečnostnými testami11,8 %

Konkrétnym príkladom je aj CVE-2025-48757. Záznam opisuje nedostatočné pravidlá databázových prístupov v stránkach generovaných cez Lovable do 15. apríla 2025, ktoré mohli umožniť čítanie alebo zápis bez prihlásenia. Dodávateľ záznam spochybňuje s odkazom na zodpovednosť zákazníkov za ochranu údajov ich aplikácií. Neznamená to, že sú zraniteľné všetky aplikácie vytvorené cez Lovable alebo dnešná verzia služby.

Uvedené merania bezpečnosti ukazujú, že funkčná aplikácia a bezpečná aplikácia nie sú to isté. Pre plánovanie preto odporúčame brať prvú verziu skôr ako začiatok starostlivosti než ako jej koniec. Náklady na kontrolu závisia od rozsahu riešenia. Lodňan v podcaste približne v čase 37:23 uvádza, že niektoré bezpečnostné audity môžu stáť jednotky tisíc eur. Je to orientačný odhad v rozhovore, nie cenník ani ponuka pre konkrétnu aplikáciu.

Pri porušeniach uvedených v čl. 83 ods. 5 GDPR môže horná hranica pokuty dosiahnuť 20 miliónov eur alebo pri podniku 4 % celosvetového ročného obratu za predchádzajúci finančný rok, podľa toho, ktorá suma je vyššia. Konkrétna sankcia závisí od okolností. Nie každá bezpečnostná chyba patrí do tejto kategórie a nejde o automatickú pokutu za únik údajov.

Ako si nastaviť starostlivosť

Aj firma bez vlastného IT oddelenia potrebuje nastaviť starostlivosť o aplikácie. Preto navrhujeme niekoľko krokov, od ktorých môže začať aj menšia firma:

1. Menovaný vlastník. Každá aplikácia, ktorú používa viac ako jej autor, má človeka, ktorý za ňu zodpovedá a rozhoduje o zmenách.
2. Prehľad aplikácií. Firma vie, aké aplikácie a automatizácie existujú, aké údaje spracúvajú a kto k nim má prístup.
3. Kontrola pred rozšírením. Kontrola inou AI môže odhaliť ďalšie chyby, ale nie je dôkazom bezpečnosti ani náhradou odborného posúdenia. Pri internom nástroji s firemnými údajmi a pri prevádzkovom systéme odporúčame kontrolu odborníkom.
4. Tajné kľúče mimo kódu. Heslá, tajné API kľúče a tokeny s oprávneniami patria do zabezpečeného úložiska, nie do repozitára ani do kódu odosielaného do prehliadača. Zámerne verejné identifikátory a kľúče treba od tajomstiev odlišovať.
5. Rozpočet na prevádzku. Do nákladov patrí hosting, licencie nástrojov, prípadné poplatky za používanie AI modelov a čas ľudí, ktorí aplikáciu udržiavajú.
6. Plán prechodu. Firma vopred vie, pri akom rozsahu používania, type údajov alebo následku výpadku aplikáciu odovzdá odborníkovi, prestaví ju alebo zruší.

Pred workshopmi Myslite si s tímom ujasníme, aké nástroje má a s akými podkladmi môže bezpečne pracovať. Ak je tvorba aplikácií súčasťou dohodnutého programu, patrí k nej aj kontrola výsledku. Kontrolný zoznam alebo návrh pravidiel môžu byť dohodnutým výstupom, nie automatickou súčasťou každého workshopu.

Otázka 3: Poslať zamestnancov na školenie vibe codingu?

Naša odpoveď je áno, no s dvoma podmienkami: vhodným načasovaním a jasným očakávaním. Odporúčame vopred dohodnúť, čo sa stane s vytvoreným prototypom. Bez takého rozhodnutia sa môže experiment zmeniť na neevidovanú aplikáciu s reálnymi údajmi, o ktorej vedenie nevie.

Čo hovoria výskumy o školení a očakávaniach

• Iniciatívy zamestnávateľa súvisia s vyšším využívaním AI. Humlum a Vestergaardová v pracovnej štúdii revidovanej v marci 2026 skúmajú približne 25 000 pracovníkov na 7 000 pracoviskách v jedenástich povolaniach v Dánsku, ktorých sa AI chatboty výrazne týkajú. Modelový odhad pre typického pracovníka je 41 % pri aspoň jednom použití AI chatbota v práci bez sledovaných iniciatív zamestnávateľa a 93 % pri kombinácii podpory používania, firemného chatbota a školenia. Ide o deskriptívny odhad s kontrolou charakteristík pracovníkov, nie o izolovaný účinok školenia. Iniciatívy neboli pridelené náhodne a údaje pochádzajú z prieskumov v rokoch 2023 a 2024. V nadväzujúcej analýze autori zároveň nezistili priemerné účinky na zárobky a evidované pracovné hodiny väčšie než 2 % počas dvoch rokov od spustenia ChatGPT. To nie je dôkaz, že používatelia z AI nemajú úžitok.
• Školenie a podpora súvisia s pravidelným používaním. Konzultačný prieskum BCG AI at Work 2025 zahŕňal viac ako 10 600 vedúcich, manažérov a radových kancelárskych pracovníkov v 11 krajinách a regiónoch. Pravidelné používanie AI v ňom súviselo s aspoň piatimi hodinami školenia a prístupom k osobnému školeniu a koučovaniu. Novší prieskum BCG z júna 2026 ďalej upozorňuje na význam podpory vedenia a organizácie práce. Ani jeden nepreukazuje kauzálny päťhodinový prah alebo účinok konkrétneho školenia vibe codingu.

Používanie AI sa líši podľa iniciatív zamestnávateľa.

• Bez podpory používania, firemného chatbota aj školenia41 %
• S podporou používania, firemným chatbotom aj školením93 %

Tieto zistenia podporujú naše odporúčanie venovať sa aj tomu, čo bude nasledovať po školení. Nie sú však dôkazom, že konkrétny formát workshopu prinesie firme úsporu. Chápeme, že vedenie nemá vždy čas tieto otázky riešiť vopred. Preto navrhujeme, aby si pred školením vibe codingu dohodlo aspoň tieto body:

1. Cieľ školenia. Či ide o pochopenie možností AI, o prototypy a lepšie zadania pre dodávateľov, alebo o interné nástroje pre tím. Od školenia neodporúčame očakávať, že zamestnanci budú samostatne vyvíjať prevádzkové systémy pre zákazníkov.
2. Poradie. Tvorbu aplikácií odporúčame až vtedy, keď zamestnanci zvládajú prácu s AI na každodenných úlohách a poznajú pravidlá pre prácu s údajmi.
3. Pravidlá pre stavbu. Kto smie stavať, s akými údajmi a kde môže aplikácia bežať.
4. Cesta pre hotový prototyp. Komu zamestnanec funkčnú ukážku predstaví a kto rozhodne, či sa z nej stane interný nástroj, zadanie pre dodávateľa alebo zostane experimentom.
5. Meranie. Pri ktorých úlohách a akým spôsobom firma overí, či aplikácia skutočne šetrí čas a či kontrola či opravy neprinášajú ďalšiu prácu.

Poradie a rozostupy workshopov Myslite dohadujeme podľa potrieb tímu. Pri sérii sa vraciame k tomu, čo účastníci medzi stretnutiami vyskúšali, a podľa spätnej väzby upravujeme ďalšie stretnutie. Interný kontakt alebo šampión, ktorý zbiera skúsenosti kolegov, môže byť súčasťou dohody. Rovnako aj pomoc s meraním alebo návrhom pravidiel ponúkame len ako dohodnutú časť rozsahu.

Záver: nadšenie zamestnancov potrebuje pravidlá

Tvorba prototypov pomocou AI môže firme pomôcť overiť nápad a ukázať ho na funkčnej ukážke. O tom, či sa oplatí pokračovať, však rozhoduje aj to, čo má aplikácia priniesť, kto sa o ňu postará a kedy ju treba odovzdať odborníkovi. Školenie vibe codingu preto odporúčame vo chvíli, keď zamestnanci zvládajú základnú prácu s AI a vedenie má pripravené pravidlá pre to, čo nasleduje po prvom prototype.

Ak zvažujete, ako vibe coding uchopiť vo vašej firme, napíšte nám.

Časté otázky

Čo je vibe coding?

Pojem zaviedol Andrej Karpathy vo februári 2025 pre tvorbu softvéru pomocou AI bez dôsledného čítania a kontroly vytvoreného kódu. Nie je to synonymum každého vývoja s AI. Nástroje môžu pomôcť s prototypom aj ľuďom bez programátorskej praxe, ale čas a výsledok závisia od zadania a kontroly.

Je vibe coding bezpečný pre firemné aplikácie?

Funkčnosť sama bezpečnosť nepreukazuje. V benchmarku SUSVIBES (v4 z 21. septembra 2026) prešiel SWE-agent s Claude 4 Sonnet funkčnými testami pri 57 % zo 186 vybraných bezpečnostne citlivých úloh a funkčnými aj bezpečnostnými pri 11,8 %. Nie je to odhad bezpečnosti všetkých AI aplikácií. Izolovaný prototyp s vymyslenými údajmi, bez produkčných prístupov a integrácií má menšie riziká než nasadený systém, nie však nulové.

Kedy potrebuje vibe-codnutá aplikácia kontrolu odborníkom?

Kontrolu odborníkom odporúčame vo chvíli, keď do aplikácie vstúpia reálne osobné alebo firemné údaje, keď sa sprístupní cez internet alebo keď sa prepojí s ďalšími firemnými systémami. Posúdiť treba aj následky výpadku. Kontrola inou AI môže odhaliť ďalšie chyby, ale nie je dôkazom bezpečnosti ani náhradou odborného posúdenia.

Koľko stojí bezpečnostný audit vibe-codnutej aplikácie?

Cena závisí od rozsahu aplikácie a požadovanej kontroly. Tomáš Lodňan v podcaste Žijeme Sci-Fi približne v čase 37:23 uvádza, že niektoré bezpečnostné audity môžu stáť jednotky tisíc eur. Ide o orientačný odhad v rozhovore, nie o cenník ani ponuku pre konkrétnu aplikáciu. Rozsah a cenu si treba dohodnúť s odborníkom podľa konkrétneho riešenia.

Oplatí sa poslať zamestnancov na školenie vibe codingu?

Odporúčame ho vtedy, ak firma vie, čo od školenia očakáva, a zamestnanci už zvládajú základnú prácu s AI a pravidlá pre údaje. Vedenie by si pred školením malo dohodnúť, kto smie čo stavať, s akými údajmi a komu zamestnanec hotový prototyp predstaví. Školenie samo nezaručuje bezpečný prevádzkový systém ani úsporu času.

Nahradí vibe coding softvérovú firmu?

Vibe coding môže zmeniť rozsah práce dodávateľa. Prototyp môže pomôcť spresniť zadanie, ale sám nepreukazuje, že firma zvládne architektúru, bezpečnosť, škálovanie a dlhodobú údržbu bez odborného zázemia. O potrebe dodávateľa preto odporúčame rozhodovať podľa rizík a schopností tímu, nie iba podľa toho, či prvá ukážka funguje.

Zdroje

• Boston Consulting Group (2025). AI at Work: Momentum Builds, but Gaps Remain, 26. 6. 2025. Konzultačný prieskum, nie experiment s pridelením školenia.
• Boston Consulting Group (2026). AI at Work: Strategy Matters More Than Tools, 3. 6. 2026. Novší ročník prieskumu.
• Collins (2025). Word of the Year 2025: vibe coding. Vyhlásenie vydavateľa slovníka.
• Escape (2025). The State of Security of Vibe Coded Apps a metodika z 29. 10. 2025. Jednorazová nereprezentatívna vzorka verejných aplikácií, meranie bezpečnostného dodávateľa.
• Európska únia (2016). Nariadenie (EÚ) 2016/679, GDPR, čl. 83. Horné hranice pokút a okolnosti ich ukladania.
• GoodRequest (2026). Tomáš Lodňan on Žijeme Sci-Fi: Vibe coding in practice, 1. 10. 2026. Blog dodávateľa softvéru.
• Humlum, A., Vestergaard, E. (2026). Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI, NBER Working Paper 33777, revízia marec 2026. Plný text, najmä s. 11–13 a obrázok 2. Nerecenzovaná pracovná štúdia, prieskumy prepojené s administratívnymi údajmi.
• Karpathy, A. (2025). Pôvodný príspevok o vibe codingu z 2. 2. 2025 a autorský životopis.
• Lientz, B. P., Swanson, E. B., Tompkins, G. E. (1978). Characteristics of application software maintenance. Communications of the ACM, 21(6), 466–471. Recenzovaný dotazníkový prieskum, odhady personálnych hodín na s. 468.
• MITRE (2025). CVE-2025-48757. Primárny záznam, aktualizovaný 21. 8. 2025, s označením sporu dodávateľa.
• Shukla, S., Joshi, H., Syed, R. (2025). Security Degradation in Iterative AI Code Generation, arXiv v2 z 26. 9. 2025. Recenzovaný príspevok IEEE ISTAS 2025, metodika a výsledky v častiach III a IV.
• Stack Overflow (2026). Trust in AI tools a metodika Developer Survey 2026. Dobrovoľný prieskum, pri otázke dôvery 14 304 odpovedí.
• Veracode (2025). 2025 GenAI Code Security Report, oznámenie výsledkov, 30. 7. 2025. Benchmark bezpečnostného dodávateľa.
• Veracode (2026). 2026 GenAI Code Security Report, verejné zhrnutie výsledkov, 28. 7. 2026. Agregát testovaných modelov a vybraných bezpečnostných úloh.
• Zhao a kol. (2026). Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks, arXiv v4 z 21. 9. 2026. Príspevok prijatý na ICML 2026. Benchmark SUSVIBES so 186 úlohami, nie odhad výskytu zraniteľností vo všetkých aplikáciách.
• Žijeme Sci-Fi (2026). Epizóda 111: Vibe coding s Tomášom Lodňanom, 30. 9. 2026. Prototypy približne 10:35, kontrola kódu a startupy 28:54, orientačný odhad ceny auditu 37:23. Skúsenosti a názory hosťa, nie nezávislé meranie trhu.