5 nejčastějších chyb při zavádění AI do vývojářského workflow

Za poslední rok jsem prošel řadou týmů, které chtěly „nasadit AI do vývoje“. Vzorce chyb se opakují natolik, že je sepisuju sem. Nejde o nedostatek nástrojů — coding agentů a IDE pluginů je dnes přebytek. Jde o to, že adopce se dělá jako instalace, ne jako změna procesu. Tady je pět věcí, které vidím nejčastěji.

1. Shadow IT: osobní AI účty na firemním kódu

Symptom: Vývojáři jsou rychlejší než nákupní oddělení. Než firma něco schválí, půlka týmu už lepí firemní kód do osobního ChatGPT nebo Claude přes neschválené rozšíření.

Proč to bolí: Nemáte přehled, kam kód odtéká, jestli se na něm trénuje, ani audit trail. U regulovaných klientů to je děravý bezpečnostní rámec — proprietární logika, klíče v komentářích, struktura interních API odejdou do služby bez data processing agreementu.

Co dělám místo toho: Nasadit schválenou variantu rychleji, než zákaz stihne zastarat. Zero-retention endpoint, SSO, jasně daný seznam nástrojů. Zákaz bez alternativy nefunguje — lidi obejdou cokoliv, co jim brání být produktivní.

2. Zrychlení bez testovací sítě = nestabilita

Symptom: Throughput vyletí nahoru. Víc PR, víc mergů, víc featur za sprint. Vedení nadšené.

Proč to bolí: DORA metriky chodí v páru. Když zvednete jen rychlost (deployment frequency, lead time) a nesáhnete na stabilitu (change failure rate, time to restore), nezrychlili jste dodávku — jen jste rychleji vyrobili nestabilitu. AI je accelerator. Accelerator bez safety-netu znamená, že do produkce teče víc nezkontrolovaného kódu rychleji.

Co dělám místo toho: Accelerator a safety-net se zavádí současně, ne sekvenčně. Konkrétně:

• automatizované testy a CI gates dřív, než zvednu objem generovaného kódu,
• review zůstává povinné — AI píše, člověk schvaluje,
• sleduju všechny čtyři DORA metriky, ne jen ty „hezké“.

3. Měření přes vanity metriky místo reálného ROI

Symptom: „Máme 80 % suggestion acceptance rate!“ „Vygenerovali jsme 40 % řádků!“ Hero-numbers do prezentace pro management.

Proč to bolí: Acceptance rate neměří hodnotu — měří, kolikrát někdo zmáčkl Tab. Procento vygenerovaných řádků koreluje spíš s rozvláčností než s produktivitou. Tyhle metriky se dají triviálně nafouknout a neřeknou nic o tom, jestli se firmě vyplatí licence.

Co dělám místo toho: Měřím výstupy, ne aktivitu. Cycle time od otevření ticketu po merge. Change failure rate před a po. Kolik review iterací PR potřebuje. A ptám se vývojářů přímo — vnímaná zátěž a flow jsou validní signál, když se sbírají systematicky. ROI je rozdíl v dodané hodnotě, ne počet tokenů.

4. Governance a regulace jako afterthought

Symptom: Nástroj běží půl roku. Pak přijde dotaz od právního nebo bezpečnosti: „A jak tohle sedí s GDPR? A s EU AI Act?“ Ticho.

Proč to bolí: DORA (nařízení o digitální provozní odolnosti), EU AI Act i GDPR nejsou volitelné. Když governance dolepujete zpětně, zjistíte, že agent má přístup k věcem, kam nikdy neměl — produkční databáze, secrets, autentizační logika. A to už je incident, ne risk.

Co dělám místo toho: Hranice nastavuju předem, ne po auditu. Pevné pravidlo, které dávám každému týmu:

# Kam AI agent NESMÍ sahat — guardrail, ne doporučení
deny:
  - auth/**          # autentizace, autorizace
  - payments/**      # platební toky
  - "**/secrets.*"   # klíče, tokeny, credentials
  - infra/prod/**    # produkční infrastruktura

Agent generuje featury a testy. Auth, platby a klíče zůstávají v rukou člověka. Tohle není nedůvěra k modelu — je to dělba odpovědnosti, kterou potřebujete doložit auditorovi.

5. Nasazení nástroje místo procesu

Symptom: „Koupili jsme licence Copilota pro celý tým. Hotovo, máme AI.“

Proč to bolí: Nástroj bez procesu je jen další ikona v IDE. Za rok přijde lepší nástroj, vy migrujete a celá „adopce“ začíná od nuly, protože nebyla v hlavách ani ve workflow — byla v jednom vendoru. Tohle je jádro posunu, o kterém mluvím jako o cestě ze software engineeringu do context engineeringu: hodnota není v modelu, je v tom, jak mu dodáte kontext a jak ho zasadíte do práce týmu.

Co dělám místo toho: Stavím procesy nezávislé na nástrojích. Konkrétně:

• konvence pro kontext (kde žijí instrukce pro agenta, jak se udržují) přežijí výměnu modelu,
• definice „done“ s AI v loopu — kdo reviduje, co se testuje, co agent nesmí,
• onboarding, který učí jak přemýšlet s AI, ne které tlačítko mačkat.

Když vyměníte nástroj, proces zůstane. To je rozdíl mezi adopcí a nákupem.

Závěrem

Žádná z těchhle chyb není o tom, že by AI nefungovala. Jsou o tom, že se zavádí jako produkt, ne jako změna způsobu práce. Když zacházíte s adopcí jako s engineering problémem — měřitelné cíle, guardrails předem, proces nad nástrojem — vyjde to. Když ji berete jako instalaci, zaplatíte za to později a dráž. Začněte v malém, měřte výstupy a hranice si nakreslete dřív, než je za vás nakreslí incident.