AI při tvorbě kódu:
co už dnes umí, kde pomáhá
a v čem stále zásadně selhává
Umělá inteligence se během posledních let posunula od jednoduchého doplňování kódu k nástrojům, které umějí číst repozitář, upravovat soubory, spouštět příkazy, navrhovat opravy chyb nebo připravovat pull requesty. Současné systémy tedy nejsou jen „chytrý autocomplete“, ale stále častěji fungují jako programátorský asistent nebo agent. Současně však i oficiální dokumentace těchto nástrojů zdůrazňuje, že nejde o náhradu odborníka a že výstupy je nutné kontrolovat, testovat a bezpečnostně ověřovat.
V praxi je AI dnes nejsilnější tam, kde je úloha jasně vymezená, lokální a dobře ověřitelná. GitHub uvádí mezi typické silné stránky psaní testů a opakujícího se kódu, opravy syntaxe, vysvětlování a komentování kódu nebo generování regulárních výrazů. OpenAI a Anthropic popisují podobné využití šířeji: psaní funkcí, opravy bugů, odpovídání na otázky nad kódovou základnou, práci napříč více soubory a automatizaci vývojových úloh. U interního používání v Anthropic navíc mezi nejčastější scénáře patří debugging a porozumění cizí codebase.
Z toho plyne, že AI je dnes velmi užitečná zejména v oblastech, jako je webový a aplikační vývoj s opakujícími se vzory, tvorba CRUD funkcionality, generování testů, refaktoring, převody dat, skriptování, práce s API, dokumentace a orientace v existujícím projektu. Dobře funguje i tam, kde lze výsledek rychle ověřit lintem, testy nebo buildem. Jinými slovy: čím je programátorský problém více rozložitelný na menší kroky a čím jasnější je definice správného výsledku, tím větší má AI praktický přínos.
Tím ale končí optimistická část. Zásadní slabinou dnešní AI není to, že by „neuměla psát kód“, ale to, že stále neumí spolehlivě nést celé inženýrské myšlení od zadání po provoz. METR v roce 2025 popsala, že délka softwarových úloh, které agent zvládne samostatně s 50% spolehlivostí, sice rychle roste, ale zároveň výslovně uvádí, že nejlepší dnešní agenti zatím nedokážou samostatně realizovat substantivní projekty ani přímo nahradit lidskou práci v plném rozsahu.
Velmi problematické zůstávají dlouhé a vícefázové úlohy. Anthropic při práci s dlouho běžícími coding agenty popsala dva typické vzorce selhání: model se pokusí udělat příliš mnoho naráz, ztratí kontext a zanechá po sobě polovičaté, špatně zdokumentované změny; nebo naopak po dílčím pokroku chybně vyhodnotí, že je práce hotová. To je mimořádně důležité, protože právě takto vypadají reálné softwarové projekty: nejsou to izolované funkce, ale dlouhé sekvence rozhodnutí, závislostí, kompromisů a návratů k předchozím krokům.
Další zásadní limit je práce s velkým repozitářem jako celkem. Novější výzkum z roku 2026 ukazuje, že i když modely formálně podporují velmi dlouhý kontext, jejich skutečná schopnost nad takovým kontextem správně uvažovat je výrazně slabší. Ve studii na úlohách odvozených ze SWE-bench Verified výkon při přímém dlouhém kontextu prudce klesal; objevovaly se halucinované diffy, špatně cílené úpravy souborů a neplatné patch hlavičky. Jinak řečeno: „vidět celý repozitář“ ještě neznamená „správně mu rozumět“.
Závažným problémem jsou také halucinace. Nejde jen o chybné vysvětlení v textu, ale o reálně neexistující balíčky, funkce, třídy nebo API volání. Studie o package hallucinations výslovně doložila tento jev napříč Pythonem, JavaScriptem i Rustem. V programování je to obzvlášť nebezpečné proto, že taková chyba může na první pohled působit přesvědčivě, projít povrchní kontrolou a selhat až později při integraci, nasazení nebo provozu.
Neméně vážná je oblast bezpečnosti. Empirické studie z roku 2025 ukazují, že současné modely mají přirozenou tendenci generovat i nezabezpečený kód a že kvalita výstupu výrazně závisí na dodaných bezpečnostních vodítkách, zpětné vazbě a následné opravě. Stejně tak GitHub ve své oficiální dokumentaci zdůrazňuje, že návrhy od AI je nutné kontrolovat nejen po funkční stránce, ale i z hlediska bezpečnosti, čitelnosti a udržovatelnosti a že je vhodné zapojit automatizované testy, linting a code scanning. AI tedy zatím sama od sebe negarantuje bezpečný software.
Důležitou korekcí proti příliš velkému nadšení je i otázka produktivity. Přestože firmy i vývojáři často popisují zrychlení práce, METR ve své randomizované studii zkušených open-source vývojářů pracujících na vlastních repozitářích zjistila, že s tehdejšími AI nástroji byli v průměru o 19 % pomalejší. To neznamená, že AI nepomáhá vůbec; znamená to spíše, že přínos není automatický a že u složitých, kontextově bohatých projektů může cena za kontrolu, opravy a korekce převýšit původně očekávanou úsporu času.
Ještě jedna věc je podstatná: i benchmarky mohou skutečné schopnosti nadhodnocovat. SWE-bench je dnes jedním z hlavních měřítek schopnosti řešit reálné GitHub issues a leaderboard sleduje procento skutečně vyřešených instancí. Zároveň však práce „The SWE-Bench Illusion“ upozorňuje, že část vysokých výsledků může být dána i memorováním nebo kontaminací benchmarku, nikoli čistou schopností obecného softwarového uvažování. Proto je rozumné chápat benchmarky jako užitečný signál, ale ne jako definitivní důkaz plné programátorské autonomie.
Celkově lze tedy dnešní stav shrnout poměrně přesně. AI už umí velmi dobře pomáhat s psaním kódu, zrychluje opakující se a jasně vymezené úlohy, pomáhá s testy, refaktoringem, debuggingem i orientací v cizím projektu. Zatím ale nedokáže samostatně a spolehlivě řešit celé složité softwarové problémy, které vyžadují dlouhodobé plánování, stabilní práci s rozsáhlým kontextem, architektonické rozhodování, hluboké doménové porozumění, bezpečnostní odpovědnost a jistotu, že řešení je skutečně správné i v hraničních stavech. Dnešní AI je tedy velmi silný akcelerátor práce programátora, nikoli plnohodnotná náhrada zkušeného softwarového inženýra.
Zdroje
OPENAI. Introducing Codex [online]. 16. 5. 2025 [cit. 2026-04-04]
GITHUB. Best practices for using GitHub Copilot to work on tasks [online]. [cit. 2026-04-04].
ANTHROPIC. Effective harnesses for long-running agents [online]. 26. 11. 2025 [cit. 2026-04-04]
KWA, Thomas aj. Measuring AI Ability to Complete Long Tasks [online]. 19. 3. 2025 [cit. 2026-04-04].
BECKER, Joel aj. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity [online]. 10. 7. 2025 [cit. 2026-04-04].
KRISHNA, Arjun, Erick GALINKIN, Leon DERCZYNSKI a Jeffrey MARTIN. Importing Phantoms: Measuring LLM Package Hallucination Vulnerabilities [online]. 31. 1. 2025 [cit. 2026-04-04]
PUBLIKOVÁNO
10.04.2025, 15:56
ODKAZ
https://www.weloveit.education/Article/20260410-AI-pri-tvorbe-kodu/