Vibe coding ve firmě: jak ho dostat pod kontrolu CTO

Krátká odpověď: Vibe coding ve firmě dostanete pod kontrolu pěti kroky: inventářem toho, co už lidé s AI postavili, pravidly pro data a modely, společným prostředím a přístupy, povinným review každé změny a jasnou odpovědností za provoz. Zákaz nefunguje, protože lidé vyvíjejí dál, jen mimo dohled. Cílem CTO není vibe coding zastavit, ale přesunout ho tam, kde ho vidí.

Proč na tom záleží

Vývoj s AI už ve firmách běží, ať ho CTO schválil, nebo ne. Podle Stack Overflow Developer Survey 2026 (30 903 respondentů ze 169 zemí, výsledky zveřejněné 6. 10. 2026) používá AI asistenty nebo agenty pro programování 66 % respondentů a 73 % z nich denně. Výstupu AI přitom 48 % věří jen tehdy, když ho může snadno ověřit. A jen 24 % respondentů uvádí, že jejich firma má schválené AI nástroje a pravidla, jak je používat; u dalších 30 % je používání AI v práci dobrovolné a ponechané na jednotlivci. Jinými slovy: AI nástroje používají skoro dvě třetiny vývojářů, ale schválené nástroje a pravidla má jen čtvrtina firem. To není rozpor, to je popis situace, kterou má CTO řídit.

Druhé číslo říká, proč na tom záleží i mimo vývojové oddělení. Veracode v roce 2025 testoval přes 100 jazykových modelů na 80 programovacích úlohách a ve 45 % případů modely vytvořily kód s bezpečnostní chybou, i když bezpečná varianta existovala. Vibe coding, tedy vývoj, při kterém člověk popisuje, co chce, a AI píše kód, tyhle chyby nevyrábí schválně. Jen je nikdo nehlídá, pokud firma nemá nastavené, kdo a jak kód kontroluje. U nás v MeguMethod jsme to pojmenovali jako čtyři rizika, se kterými za námi firmy chodí do AI Ops: úniky citlivých dat, závislost na autorovi, duplicitní vývoj a neudržitelné aplikace.

Chcete vědět, co už ve vaší firmě vzniklo s AI a kde jsou největší rizika? Rezervujte si 30 minut online s námi. Projdeme, kdo co staví, kde to běží a na co to sahá. Domluvit online call

Co se ve firmě děje, když lidé vyvíjejí s AI bez pravidel

Bez pravidel vzniká ve firmě paralelní IT, které nikdo nevidí a za které nikdo neručí. Nejde jen o vývojáře. Obchodník si nechá napsat skript, který stahuje data z CRM do tabulky. Analytik postaví interní aplikaci na reporting. Marketing si vytvoří nástroj, který posílá data o zákaznících do externího modelu. Každý z nich vyřešil svůj problém a žádný z nich nemá důvod to hlásit.

CTO se o těchto nástrojích obvykle dozví ve třech situacích: když přestanou fungovat, když jejich autor odejde, nebo když se někdo zeptá, kam vlastně odcházejí data. V tu chvíli už je drahé cokoli měnit. Nástroj je součástí něčího workflow, kód je v cizím účtu a nikdo kromě autora neví, co dělá.

Podstatné je, že problém není v tom, že lidé vyvíjejí. Problém je, že vyvíjejí bez prostředí, které by jim dalo bezpečné mantinely. Lidé si vybírají cestu nejmenšího odporu. Pokud je nejjednodušší cesta „nahrát data do veřejného modelu a nechat si napsat appku“, půjdou tudy. Pokud je nejjednodušší cesta „firemní prostředí s připravenými nástroji“, půjdou tamtudy. Práce CTO je udělat tu druhou cestu jednodušší.

Krok 1: Inventář. Co už s AI vzniklo a kde to běží

První krok není pravidlo, ale seznam. Než začnete cokoli zakazovat nebo povolovat, potřebujete vědět, co existuje. Inventář odpovídá na čtyři otázky u každého nástroje nebo aplikace: kdo ji postavil, kde běží, na jaká data a systémy sahá a kdo ji dnes používá.

Nejrychlejší cesta k inventáři není audit, ale amnestie. Řekněte lidem, že chcete vědět, co postavili, a že jim to nikdo nebude vyčítat. Většina lidí je na svoje nástroje hrdá a ráda je ukáže. Pokud začnete kontrolou, inventář bude neúplný, protože lidé schovají to, za co se bojí postihu.

Z inventáře obvykle vyplyne, že část nástrojů je neškodná (skript pro přejmenování souborů), část je cenná a zaslouží si zpevnit (interní aplikace, kterou používá celé oddělení) a část je riziková (cokoli, co posílá data zákazníků mimo firmu). Teprve s tímhle seznamem má smysl nastavovat pravidla. Je to také přesně první krok, kterým začínáme v AI Ops: zmapovat, co ve firmě běží.

Krok 2: Pravidla. Co smí do modelu a co ne

Nejdůležitější pravidlo se netýká kódu, ale dat. Každý člověk ve firmě musí vědět, co smí poslat do AI modelu a co ne. Je to jednoduché na vyslovení a těžké na dodržení, protože AI nástroj nerozliší testovací data od produkční databáze zákazníků.

Náš pohled: pravidla mají být krátká a konkrétní, ne dvacetistránková směrnice. Příklad struktury, kterou doporučujeme:

Které modely a nástroje jsou schválené. Seznam poskytovatelů a účtů, přes které firma s AI pracuje. Firemní účty místo osobních, protože u firemního účtu víte, jaké má podmínky zpracování dat, a u osobního ne.

Co se do modelu nesmí posílat nikdy. Osobní údaje zákazníků, přihlašovací údaje, klíče k API, obchodní smlouvy, zdrojový kód produktů, u kterých to zakazuje licence nebo smlouva s klientem. Tenhle seznam má být vyvěšený tam, kde lidé pracují, ne v intranetu, kam nikdo nechodí.

Kde smí vznikat kód. Jeden firemní verzovací systém (typicky Git), do kterého patří všechno, co se používá víc než jednou. Kód v osobním účtu, na lokálním disku nebo jen uvnitř AI nástroje není firemní majetek, ale riziko.

Kdo rozhoduje o výjimkách. Pravidla bez vlastníka nikdo nedodržuje. Jeden člověk nebo malá skupina, která umí během dne odpovědět na otázku „můžu tenhle nástroj použít na tahle data?“.

Pravidla pro data patří k tématům, kde se vyplatí ověřit s právníkem, co pro vás plyne z GDPR a případně z další regulace. V článku píšeme obecné principy, konkrétní nastavení pro vaši firmu je na právní konzultaci.

Krok 3: Prostředí a přístupy. Dát lidem bezpečnou cestu

Pravidla fungují jen tehdy, když je jejich dodržování jednodušší než obcházení. Proto třetí krok není další dokument, ale prostředí, ve kterém lidé vyvíjejí s AI bezpečně, aniž by o tom museli přemýšlet.

Co takové prostředí obsahuje:

Schválené nástroje s firemními přístupy. Ať už tým používá Claude Code, Codex, Cursor nebo jiné nástroje, přístupy a klíče spravuje firma, ne jednotlivci. Když člověk odejde, přístup se vypne. Když poskytovatel změní podmínky, firma to ví. Jak tyhle nástroje prakticky zavést, od přístupů přes pravidla u projektu až po review, popisujeme v samostatném návodu o AI agentech pro vývoj ve firmě.

Pravidla přímo v projektu. Moderní AI nástroje umí číst soubor s instrukcemi uložený v projektu: jaké technologie používáme, jak se jmenují věci, co se testuje, co se nesmí. Instrukce v repozitáři platí pro každého, kdo s projektem pracuje, včetně AI. Je to nejlevnější způsob, jak udržet jednotný stack, aniž byste to museli každému vysvětlovat.

Připravené napojení na firemní data. Pokud lidé potřebují, aby AI nástroj viděl do interní dokumentace nebo systémů, dejte jim k tomu schválenou cestu, třeba přes MCP (Model Context Protocol, otevřený standard pro připojení AI nástrojů k datům). Schválená cesta znamená, že víte, jaký nástroj na jaká data sahá a s jakými právy. Neschválená cesta znamená, že si to každý udělá po svém.

Oddělené prostředí pro experimenty a pro produkci. Vibe coding je skvělý na prototyp. Prototyp ale nesmí běžet nad živými daty zákazníků. Oddělení vývojového a produkčního prostředí je základní hygiena, kterou AI nástroje samy nezajistí.

Tohle je zároveň část, kde se CTO nejčastěji rozhoduje mezi „postavíme si to sami“ a „necháme si to postavit“. Obojí je legitimní; obecné srovnání obou cest máme v článku Vibe coding, nebo vývojový tým. Záleží na tom, jestli máte v týmu lidi, kteří prostředí nejen postaví, ale budou ho i udržovat.

Krok 4: Review. Každá změna projde kontrolou

Kód napsaný s AI musí procházet stejným review jako kód napsaný člověkem, a v některých ohledech přísnějším. Důvod je ten, který ukázal Veracode: model vytvoří funkční kód s bezpečnostní chybou, aniž by to kdokoli poznal na první pohled. Funkčnost se pozná hned, zranitelnost až při útoku.

Review má dvě vrstvy. První je automatická: testy, statická analýza, kontrola závislostí, bezpečnostní skeny a automatické AI code review, které projde celý kód a najde možné chyby. Běží při každé změně a zastaví to, co zjevně neprojde. Druhá je lidská: zkušený vývojář se podívá na architekturu, na práci s daty a přístupy a na to, jestli kód dělá to, co má, a nic navíc. Kódu z AI je tolik, že ho člověk ručně celý efektivně neprojde; proto automatika dělá rutinu a člověk řeší podstatná rizika a stabilitu základu. U kódu z AI je lidská vrstva důležitější, ne méně důležitá, protože autor často nedokáže vysvětlit, proč kód vypadá tak, jak vypadá.

Pro CTO z toho plyne praktické rozhodnutí: kdo review dělá u nástrojů, které postavili lidé mimo vývojový tým. Obchodník svůj skript sám nezkontroluje. Buď to udělá interní tým, nebo partner. V MeguMethod je to čtvrtý krok AI Ops: nad kódem, který vzniká ve firmě, dohlíží automatika i naši inženýři a každou změnu kontrolují z hlediska bezpečnosti, architektury a funkčnosti. Na úrovni jednotlivého produktu stejný princip používáme v App as a Service, kde každou změnu kontroluje automatika i naši inženýři, než jde do provozu.

Nejčastější bezpečnostní chyby, kterým review předchází, popisujeme v samostatném článku o bezpečnosti aplikací psaných s AI.

Krok 5: Odpovědnost. Kdo nástroj udržuje, až autor odejde

Každý nástroj, který firma používá, potřebuje vlastníka, a to nejen autora. Autor nástroj postavil, ale vlastník za něj ručí: ví, že existuje, ví, na čem závisí, a má plán, co se stane, když přestane fungovat nebo když autor odejde.

Tohle je riziko, kterému říkáme závislost na autorovi: nástroj postavený s AI, kterému rozumí jen člověk, který ho popsal modelu. Když odejde, nástroj zůstane běžet a nikdo ho neumí opravit. Ochrana je jednoduchá na popsání: kód ve firemním repozitáři, pár odstavců dokumentace, jak nástroj spustit a co dělá, a druhý člověk, který ho alespoň jednou viděl.

Druhé riziko je duplicita. Bez inventáře si tři oddělení postaví tři verze stejného nástroje. Každá se udržuje zvlášť a každá má jiné chyby. Centrální seznam projektů, do kterého se lidé podívají dřív, než začnou stavět, je levnější než tři nástroje.

Tahle část souvisí i s širším jevem, kterému se říká shadow AI: lidé používají AI nástroje a staví si vlastní řešení bez vědomí IT. Věnujeme mu samostatný článek. Pro CTO je podstatné, že odpovědnost se nedá nařídit zpětně. Musí být součástí pravidel od začátku.

Kdy vibe coding ve firmě podporovat a kdy ho brzdit

Vibe coding podporujte, když:

• lidé staví interní nástroje pro sebe a svůj tým a data, se kterými pracují, nejsou citlivá,
• jde o prototyp nebo ověření nápadu v první verzi, které nikdy nepůjde k zákazníkům bez přepracování,
• máte nastavené prostředí, kam kód patří, a někoho, kdo ho zkontroluje,
• nástroj nahrazuje ruční práci, kterou by jinak nikdo neautomatizoval, protože na ni není rozpočet,
• autor je ochotný nástroj zdokumentovat a předat.

Vibe coding brzděte, když:

• nástroj sahá na osobní údaje zákazníků, platby nebo přihlašovací údaje a nikdo ho nekontroloval,
• kód existuje jen v osobním účtu nebo uvnitř AI nástroje a firma k němu nemá přístup,
• na nástroji závisí celé oddělení a rozumí mu jeden člověk,
• aplikace má jít k platícím zákazníkům a nikdy neprošla architektonickým a bezpečnostním review,
• lidé ho používají proto, aby obešli IT, ne proto, aby vyřešili problém, který IT neřeší.

Náš pohled: rozdíl mezi oběma seznamy není v nástroji, ale v tom, jestli má firma prostředí, pravidla a review. S nimi je vibe coding zrychlení. Bez nich je to dluh, který se splácí ve chvíli, kdy to nejmíň čekáte.

Pokud jste se našli v druhém seznamu, napište nám pár vět o tom, co u vás s AI vzniká. Ozveme se s tím, jak bychom postupovali. Poslat poptávku

Jak k tomu přistupuje MeguMethod

V AI Ops děláme pro firmy přesně těch pět kroků, které jsou v tomhle článku, jen s našimi lidmi a nástroji. Nejdřív zmapujeme, co ve firmě běží: kdo co staví, kde to je hostované a na co to sahá. Pak nastavíme pravidla pro stack, prostředí a nasazení. Tým vybavíme a proškolíme: dostane AI skills a MCP k modelům, které už používá, přístup k seznamu všech projektů postavených s AI a praktický workshop o vibe codingu bez ztráty kvality. A nakonec dohlížíme na kód: každou změnu kontroluje AI i naši inženýři z hlediska bezpečnosti, architektury a funkčnosti.

Začínáme 30minutovou online konzultací bez závazků. Projdeme, co vaši lidé staví, kde to běží a na co to sahá, a odejdete s konkrétním seznamem rizik a prvních kroků. Pokud řešíte jeden konkrétní produkt, který má jít do provozu, je pro vás vhodnější App as a Service.

Další krok

Chcete mít vývoj s AI ve firmě pod kontrolou, aniž byste ho brzdili? Podívejte se, jak funguje AI Ops od MeguMethod, nebo si rovnou domluvte 30 minut online a projdeme, co u vás s AI vzniká. Pokud chcete nejdřív kontext, přečtěte si, co je vibe coding a kde končí jeho možnosti.

Související čtení z našeho blogu: AI agent: co to je a jak ho využije firma a Report z AppParade 37: čtyři AI trendy.