Ještě donedávna se rozhovor o umělé inteligenci v programování soustředil především na jednu otázku: vezme AI programátorům práci? V roce 2026 je tahle otázka už prakticky irelevantní. AI už píše kód, vytváří testy, analyzuje repozitáře, navrhuje opravy, připravuje pull requesty a stále pokročilejší agenti dokážou vykonávat celé sekvence úkolů bez ručního vedení developera krok za krokem.
Změnil se tedy problém.
Neptáme se už jen, zda AI umí programovat.
Ptáme se, kdo nese odpovědnost za software, který AI naprogramovala.
A to je mnohem důležitější otázka.
Kódování zrychlilo. Vývoj kvalitního softwaru ne nutně
Stojí za to začít jednou věcí: nemá smysl předstírat, že AI v programování je jen dočasný trend. Není.
AI nástroje stále hlouběji vstupují do každodenního procesu vývoje. Od jednoduchých nápověd do jednotlivých úseků kódu jsme se dostali k agentům, kteří dokážou analyzovat širší kontext projektu, upravovat více souborů, spouštět testy, reagovat na chyby a připravovat změny k ověření lidmi. Trh nástrojů se vyvíjí směrem k agentnímu tvorbě softwaru, nejen ke klasickému autocomplete.
Je to obrovská změna produktivity.
Vývojář už nemusí psát každý kus kódu od nuly. Může AI zadat úkol, dostat první implementaci, otestovat ji, upravit a přejít k dalšímu problému.
A právě tady se objevuje určitý paradox.
Čím snadněji lze kód napsat, tím méně hodnoty má samotné napsání kódu.
Za to má čím dál větší hodnotu odpověď na otázku: co vlastně má být napsáno, jak by to mělo fungovat a jak ověřit, že to bylo uděláno správně?
To je rozdíl mezi generováním kódu a softwarovým inženýrstvím.
„Funguje“ je teprve začátek
Každý developer zná situaci, kdy něco funguje. Endpoint vrací odpověď. Formulář se odesílá. Záznam se uloží do databáze. Tlačítko vykoná akci. Test projde. Dá se tedy říct: hotovo.
Jenže dobré softwarové inženýrství začíná právě v ten okamžik.
Později se objevují otázky:
- Je řešení bezpečné?
- Funguje při velkém zatížení?
- Co se stane, když uživatel zadá neočekávaná data?
- Zachytává chyby?
- Lze ho snadno rozšířit?
- Pochopí tento kód za rok jiný vývojář?
- Je řešení v souladu s architekturou celého systému?
- Nepřepisuje logiku, která už existuje jinde?
- Nevytváří technický dluh?
- Opravdu test ověřuje správné chování, nebo jen potvrzuje, že kód dělá přesně to, co autor očekával?
AI může pomoci odpovědět na část těchto otázek. Může také pomoci vytvořit testy, najít potenciální problémy nebo navrhnout refaktoring. Ale nevyvazuje organizaci z odpovědnosti za odpověď.
Nejnebezpečnější kód není ten, který nefunguje
Kód, který se okamžitě rozsype, je relativně snadné najít.
Mnohem nebezpečnější je kód, který funguje dostatečně dobře na to, aby se dostal do produkce, ale má problémy, které nejsou na první pohled vidět.
Může být zbytečně složitý. Může duplikovat kusy existujícího řešení. Může obsahovat chyby v obsluze okrajových případů. Může mít problémy s výkonem. Může používat knihovny nebo vzory, které tým v daném projektu nechce používat.
A může vypadat velmi profesionálně.
To je právě jedna z pastí generativního AI; kód může být přesvědčivý dřív, než bude dobrý.
Studie Sonar publikovaná v roce 2026 ukazuje, že 53 % dotazovaných developerů přisuzovalo AI negativní vliv na technický dluh tím, že generovala kód, který vypadal správně, ale ukázal se být nespolehlivý.
To neznamená, že AI vytváří jen špatný kód. Znamená to něco praktičtějšího: větší množství generovaného kódu není automaticky větší množství hodnoty.
AI může také urychlit vznik technického dluhu
Představme si klasický projekt.
Před AI vývojář potřeboval dva dny na vytvoření určité funkce. Po nasazení AI nástrojů to trvá půl dne. Skvělé.
Ale co když zároveň počet změn v projektu vzroste několikanásobně?
Co když místo jedné dobře promyšlené implementace vznikne pět podobných?
Co když se další funkce přidávají rychleji, než tým stíhá provádět refaktoring?
Co když je kód pravidelně generován různými modely, s různými předpoklady o architektuře?
Pak AI nejen zvyšuje produktivitu. Může také zvýšit tempo nárůstu technického dluhu.
Analýza GitClear pokrývající 211 milionů řádek kódu ukazuje nárůst duplicity kódu v analyzovaném období a autoři spojují tento trend mimo jiné s popularizací AI-assisted coding. To není důkaz, že každá řádka generovaná AI je horší, ale je to silný signál, že větší rychlost změn vyžaduje stejně intenzivní kontrolu kvality.
A tady přicházíme k velmi důležité zásadě: pokud AI zvyšuje tempo psaní kódu, musí se rozvíjet i jeho proces ověřování.
Nelze prostě zdvojnásobit produkci kódu a nechat zbytek procesu beze změny.
„AI sama zkontroluje svůj kód“
Zní to lákavě. AI napsala funkci. Jiná AI ji zkontroluje. Ještě jiná připraví testy.
Vyřešený problém? – Ne nutně.
V roce 2026 častěji vidíme i situace, kdy jeden agent vytvoří kód a druhý agent provede jeho review. Vzniká tak určitý uzavřený oběh AI-to-AI: agent vytvoří změnu, druhý ji analyzuje a organizace může výsledek schválit bez dostatečného zapojení člověka. Studie o tomto modelu ukazují, že AI-to-AI code review opravdu roste, i když stále představuje menšinu sledované aktivity agentů.
To může být velmi hodnotné. Ale má i fundamentální omezení - dvě AI mohou udělat stejný typ chyby.
Pokud agent vytvářející kód přijal chybné obchodní předpoklady, agent provádějící review je nemusí odhalit. Pokud oba systémy vychází z podobných vzorů, mohou stejný problém přehlédnout.
Proto člověk stále musí být součástí procesu. Ne jako někdo, kdo ručně přepisuje kód. Jako někdo, kdo rozumí systému, obchodnímu kontextu, rizikům a důsledkům technických rozhodnutí.
Vývojář budoucnosti nebude méně zodpovědný. Bude odpovídat za více
To je velmi důležitá změna.
Lze si představit developera, který dříve trávil 70 % času implementací, a dnes díky AI může věnovat mnohem více času analýze, architektuře, testování, review a řešení problémů.
To je pozitivní scénář.
Developer nemusí být strojem na psaní kódu. Může se stát ještě více inženýrem. Problém nastává, když organizace interpretuje nárůst produktivity výhradně jako možnost zkrátit potřebný čas na úkol.
Pak je snadné dospět k absurdnímu modelu: „Jestli to AI udělala za hodinu, proč nám dřív trvalo tři dny?“
Jenže ty tři dny mohly zahrnovat analýzu, architekturu, testy, review, opravy, integraci, dokumentaci a nasazení.
Kód byl jen jedním prvkem práce.
A co bezpečnost?
Tady je to ještě závažnější.
Vygenerovaný kód může obsahovat zranitelnosti, chybné předpoklady ohledně autorizace, nevhodnou validaci dat nebo nebezpečné použití knihoven.
Nestačí tedy říct: „Vždyť AI zkontrolovala kód“.
Výzkumy týkající se AI-powered code review ukazují, že takové nástroje by neměly být považovány za náhradu dedikovaných bezpečnostních mechanismů a manuálních auditů. V jedné studii týkající se GitHub Copilot Code Review autoři poukázali na problémy s detekcí některých významných zranitelností, mimo jiné SQL injection, XSS nebo insecure deserialization.
To vede k velmi zdravému pravidlu: AI může být součástí bezpečnostního procesu. Neměla by být jediným zajištěním tohoto procesu. Zvlášť když mluvíme o aplikacích zpracovávajících data zákazníků, platby, dokumenty, údaje zaměstnanců nebo obchodní informace.
Největší problém nastává, když není jasné, kdo rozhodl
V tradičním procesu lze změnu vysledovat.
Developer napsal kód.
Pull request byl připraven.
Někdo ho reviewoval.
Testy byly spuštěny.
Změna se dostala do produkce.
Ve světě agentního programování se tento proces stává složitějším. Agent může vykonat desítky operací. Může upravit mnoho souborů. Může vygenerovat testy. Může sám opravit chyby. Může připravit pull request.
Proto se stávají čím dál důležitějšími zásady governance pro AI v procesu vývoje softwaru.
Kdo může spouštět agenta?
Na které repozitáře má přístup?
Může měnit produkční kód?
Může provádět migrace databáze?
Může instalovat závislosti?
Může používat produkční data?
Kdo schvaluje jeho změny?
Má každá změna auditní stopu?
Lze zrekonstruovat, proč bylo dané rozhodnutí učiněno?
To nejsou otázky typu „AI někdy bude důležitá“. To jsou otázky týkající se procesu vývoje softwaru už teď.
Není náhoda, že nástroje pro vývojářské týmy začínají přidávat funkce související s kontrolou kontextu, kodovacími standardy, review agentů a monitoringem využití agentů. Fakt, že takové mechanismy se stávají součástí vývojářských nástrojů, ukazuje směr vývoje trhu: agent nesmí být jen „dalším programátorem“, musí být součástí kontrolovaného inženýrského procesu.
„Vibe coding“ je skvělý. Do určité míry
Experimentování není špatné.
Chcete vytvořit prototyp? AI je fantastická.
Potřebujete rychle ověřit nápad? Skvělé.
Chcete udělat proof of concept? Ještě lépe.
Malý interní automat? Možná AI udělá většinu práce.
Problém nastává, když se prototyp začne chovat jako produkt.
Najednou: „udělejme to rychle“ se změní na: „připojme to na CRM“.
Pak: „přidejme platby“.
Následně: „nechť to používá 500 uživatelů“.
A měsíc poté: „proč ten systém běhá tak pomalu a proč nikdo kromě autora neví, jak ho dál rozvíjet?“
Prototyp může být rychlý. Produkt musí být navržen. To je obrovský rozdíl.
AI neodvádí odpovědnost. Posouvá ji výš
A to je asi nejdůležitější závěr celé diskuse.
Když dřív programátor odpovídal především za správné napsání kódu, dnes častěji nese odpovědnost za mnohem širší proces: pochopení problému, výběr řešení, kontrolu kvality generovaného kódu, bezpečnost, testy, architekturu, udržovatelnost a soulad s obchodními požadavky.
AI může udělat část práce. Neměla by ale automaticky přebírat odpovědnost.
Navíc současné události ve světě AI ukazují, že problém kontroly už není jen teoretický. V posledních dnech se objevily zprávy o incidentech spojených s chováním AI agentů v vývojových prostředích, včetně agentů OpenAI, kteří během testů zasahovali do RubyGems. OpenAI potvrdilo účast svých agentů a provádí vysvětlení k události.
To je výborný příklad toho, proč s rostoucí autonomií AI roste význam omezení přístupu, sandboxingu, monitoringu a lidské kontroly.
AI může mít přístup ke kódu. Neznamená to, že by měla mít přístup ke všemu.
Co by měl tedy dělat dobrý software house?
Především předstírat, že AI neexistuje, se nevyplácí. Naopak.
Stojí za to ji využívat tam, kde skutečně zvyšuje produktivitu týmu: při analýze kódu, prototypování, dokumentaci, testech, refaktoringu, generování opakovatelných prvků nebo analýze problémů.
Současně je ale nutné zachovat klasické zásady softwarového inženýrství.
Architektura má stále význam.
Code review má stále význam.
Testy mají stále význam.
Bezpečnost má stále význam.
Dokumentace má stále význam.
Zkušenost developera má stále význam.
A především má stále význam člověk, který umí říct: „Ano, AI vygenerovala tento kód. Ale než ho nasadíme, ověříme, zda bychom ho vůbec měli napsat tímto způsobem.“
Nejdražší nemusí být to, kolik zaplatíte za napsání kódu
To je perspektiva, kterou stojí za to změnit.
Pokud AI dovolí vytvořit funkci za zlomek dřívějšího času, je to skvělé. Ale náklady na software nekončí prvním nasazením.
Systém bude dále rozvíjen.
Bude integrován s dalšími službami.
Požadavky se budou měnit.
Objeví se nová zařízení, prohlížeče, platební systémy, regulace a potřeby zákazníků.
Někdo se bude muset vrátit do kódu za rok.
Někdo bude muset hledat chybu ve dvě ráno.
Někdo bude muset provést migraci.
Někdo bude muset zabezpečit systém.
A teprve pak se ukáže, zda firma skutečně ušetřila na rychlém vývoji softwaru, nebo jen přesunula náklady na později.
Skutečná hodnota tedy nespočívá v tom, aby AI napsala co nejvíc kódu.
Hodnota spočívá v tom, aby díky AI vznikl lepší software rychleji, bez ztráty kontroly nad tím, co bylo postaveno.
Ve Web24 se díváme na AI jako na nástroj, ne jako na náhradu inženýrství
AI může být výborným členem týmu.
Může urychlit práci.
Může převzít opakující se úkoly.
Může pomáhat developerům analyzovat obrovské množství kódu.
Může zkrátit cestu od nápadu k prvnímu fungujícímu řešení.
Ale mezi „funguje“ a „je připravené žít příštích pět let“ je obrovský prostor.
Právě tam začíná opravdové softwarové inženýrství. Dnes je mnohem snazší vygenerovat kód. Obtížnější je postavit systém, za který lze s klidem převzít odpovědnost. A možná právě to bude jednou z nejdůležitějších kompetencí softwarových houseů v následujících letech.
Ne psaní kódu samo o sobě.
Ne pouhé používání AI.
Ale schopnost propojit AI, lidské zkušenosti, architekturu, bezpečnost a odpovědnost za celý systém.
