Nahradí AI vývojáře, nebo jen odhalí špatné systémy?

Od chvíle, kdy začaly AI nástroje zvládat psát použitelný kód, se pořád dokola vrací stejná otázka: nahradí AI vývojáře?

Čím víc s ní ale reálně pracuji, tím méně mi tahle otázka připadá zajímavá. Ne proto, že by AI neměnila způsob, jakým software vzniká. Mění ho podle mě rychleji než skoro jakákoliv technologie za poslední roky. Jen si myslím, že její největší dopad zatím není v tom, že by jednoduše nahrazovala lidi.

Mnohem víc zesiluje rozdíl mezi dobře a špatně nastavenou prací.

Když má vývojář jasné zadání, rozumnou architekturu, kvalitní kontext a způsob, jak výstup rychle ověřit, může mu AI výrazně zvýšit rychlost. Když ale stejný nástroj pustíme do projektu, kde nikdo pořádně neví, co se staví, kód nemá strukturu a každá změna rozbije něco jiného, AI ten problém nevyřeší.

Jen nám umožní vyrábět chaos rychleji.

A podle mě právě tohle AI ve vývoji odhaluje nejvíc.

AI je zesilovač

AI se často prezentuje jako něco, co do firmy nebo projektu přinese novou schopnost. To je samozřejmě částečně pravda. Dokáže napsat komponentu, připravit testy, analyzovat chybu, projít dokumentaci, refaktorovat kód nebo implementovat větší část funkcionality.

Jenže kvalita toho, co dostaneme ven, pořád výrazně závisí na systému, do kterého AI zapojíme.

Představme si dva projekty.

První má srozumitelnou architekturu, konzistentní naming, automatické testy, jasně definované typy, dobře oddělené části systému a dokumentaci základních rozhodnutí. Když agentovi zadáme změnu, může si projekt relativně rychle načíst, pochopit souvislosti, upravit potřebná místa a pomocí testů ověřit, jestli něco nerozbil.

Druhý projekt vznikal několik let bez větší disciplíny. Business logika je částečně v komponentách, částečně v API a něco důležitého se děje v helperu, kterého se všichni bojí dotknout. Neexistují testy, datový model není konzistentní a jediný člověk, který přesně ví, proč některé věci fungují právě takhle, už ve firmě nepracuje.

AI dokáže psát kód v obou.

V prvním případě ale násobí dobře postavený systém. Ve druhém násobí technický dluh.

Rychlost sama o sobě není produktivita

Jedna z věcí, které AI změnila nejviditelněji, je rychlost produkce kódu.

Dříve mohl vývojář strávit půl hodiny psaním relativně rutinní části implementace. Dnes často popíše, co potřebuje, a první verzi má během několika sekund. U větších úkolů může agent projít několik souborů, připravit změny a spustit testy, zatímco člověk řeší něco jiného.

To je obrovská změna.

Zároveň ale vytváří nebezpečnou iluzi, že množství vyprodukovaného kódu je totéž jako množství vytvořené hodnoty.

Není.

Pokud za den místo 300 řádků napíšeme s AI 3 000, ale následně trávíme další dva dny opravováním regresí, pochopením vygenerované implementace a odstraňováním duplicit, žádný desetinásobný růst produktivity se nekonal.

Stejně tak není výhra implementovat za hodinu funkci, o které jsme si předem neověřili, jestli ji zákazník potřebuje.

AI dramaticky snižuje cenu samotné výroby. O to víc se podle mě přesouvá hodnota do rozhodnutí co vyrábět, jak to má fungovat a jak poznáme, že je výsledek správně.

Špatná architektura začíná být mnohem viditelnější

Technický dluh existoval samozřejmě dávno před generativní AI. Jen se často dokázal poměrně dlouho skrývat.

Vývojář, který s projektem pracuje několik let, si postupně vytvoří mentální mapu všech jeho zvláštností. Ví, že určitou komponentu nesmí použít tímhle způsobem. Ví, že po změně jedné tabulky musí ručně upravit ještě dvě další věci. Ví, že název určité funkce vůbec neodpovídá tomu, co ve skutečnosti dělá.

Systém je objektivně špatně navržený, ale konkrétní člověk v něm pořád dokáže fungovat, protože si kolem jeho nedostatků vytvořil vlastní návyky.

AI takovou historickou znalost automaticky nemá.

Potřebuje kontext, který lze nějak získat z kódu, dokumentace, testů nebo dalších zdrojů. Pokud jsou důležité informace pouze v hlavách několika lidí, kvalita práce AI rychle klesá.

To podle mě vytváří docela zajímavý tlak na celé softwarové projekty. Dobré pojmenování, jasné hranice mezi moduly, kvalitní typy, testy a dokumentace už nejsou jen otázkou toho, aby se v projektu lépe orientovali lidé.

Začínají přímo určovat i to, jak efektivně na projektu dokážeme používat AI.

Kontext začíná být součástí infrastruktury

U generativní AI se hodně řeší prompting. Jenže v reálném vývoji podle mě prompt velmi rychle přestává být tím hlavním problémem.

Můžeme napsat perfektní zadání, ale pokud model nemá přístup ke správnému kontextu, bude stejně hádat.

Potřebuje vědět, jak projekt funguje, jaké má konvence, které části systému spolu souvisejí, jaké rozhodnutí už tým udělal, jaká omezení existují a podle čeho se pozná správný výsledek.

Proto mi přijde zajímavější přemýšlet ne nad tím, jak lépe promptovat, ale nad tím, jak vytvořit prostředí, ve kterém má AI správné informace k dispozici automaticky.

To může znamenat dobře strukturovaný repozitář, dokumentaci architektury, automatické testy, popsané API kontrakty, jasné produktové zadání nebo třeba projektové instrukce, které agent načte pokaždé, když začne pracovat.

Najednou se z kontextu stává infrastruktura.

A čím autonomněji chceme AI používat, tím důležitější tahle infrastruktura bude.

AI zároveň odhaluje špatná zadání

Stejný problém není jen technický.

Hodně času ve vývoji se neztrácí proto, že by někdo neuměl napsat kód. Ztrácí se proto, že není jasné, co má vlastně vzniknout.

„Přidej možnost filtrovat objednávky.“

Podle čeho? Má být možné kombinovat filtry? Má se jejich stav ukládat do URL? Co se stane na mobilu? Funguje filtrování na serveru, nebo klientsky? Kolik objednávek může být v systému? Jak má fungovat nulový stav? Má se výběr zachovat po návratu z detailu?

Zkušený vývojář si podobné otázky často začne pokládat automaticky. Pokud odpovědi nemá, dohledá je, zeptá se nebo udělá rozumné rozhodnutí.

AI může místo toho velice rychle implementovat první interpretaci zadání.

A právě rychlost, se kterou to udělá, může způsobit, že špatně definovaný požadavek vytvoří problém mnohem dřív.

Čím rychlejší je exekuce, tím dražší začíná být nejasnost.

Pokud nám implementace dříve zabrala tři dny, měli jsme během ní spoustu času přemýšlet, jestli dává smysl. Když první verze vznikne za dvacet minut, musí větší část tohoto přemýšlení proběhnout předem.

AI tedy podle mě nesnižuje potřebu produktového myšlení.

Naopak ji zvyšuje.

Bottleneck se přesouvá od psaní k rozhodování

Dlouhou dobu bylo jedním z hlavních omezení softwaru to, kolik toho vývojář dokáže fyzicky vytvořit.

Každá stránka, integrace, endpoint, test nebo interní nástroj znamenal určité množství práce. Proto dávalo smysl velmi pečlivě rozhodovat, čemu vývojový čas věnovat.

AI cenu mnoha těchto úkolů dramaticky snižuje.

To ale neznamená, že zmizely bottlenecky. Jen se přesouvají.

Když dokážeme za stejné množství času vytvořit násobně víc funkcionality, potřebujeme také násobně lépe rozhodovat, která z ní má vůbec vzniknout. Potřebujeme rychleji kontrolovat výsledky, rozumět širším dopadům změn a udržet konzistenci systému.

Najednou není nejvzácnější schopností samotná produkce.

Vzácnější je úsudek.

Umět rozdělit problém. Rozpoznat špatné zadání. Navrhnout správnou architekturu. Vědět, co neimplementovat. Poznat, kdy AI vytvořila něco, co sice funguje, ale dlouhodobě je to špatné řešení.

To jsou věci, které začínají být s rostoucí rychlostí generování ještě důležitější.

Vývojář se postupně posouvá o úroveň výš

Neznamená to podle mě, že vývojář přestane programovat.

Spíš se mění poměr práce.

U části úkolů už dnes nedává moc smysl ručně psát každý řádek. Člověk popíše změnu, nechá AI připravit implementaci a potom kontroluje architekturu, edge cases, bezpečnost, performance a to, jestli výsledek skutečně odpovídá požadavku.

Jindy použije AI jen na malou část práce. Nechá si vysvětlit cizí knihovnu, vygenerovat test cases nebo projít problém, se kterým se zasekl.

A někdy je stále rychlejší kód napsat přímo.

Podstatné podle mě není, kdo fyzicky napsal konkrétní řádek. Podstatné je, kdo rozumí systému a nese odpovědnost za výsledek.

To je důvod, proč mi přijde představa „AI vs. vývojář“ příliš jednoduchá.

Vývojář, jehož jedinou hodnotou je převést přesně definovaný ticket na syntakticky správný kód, bude mít samozřejmě problém. Právě tuhle část práce dokáže AI automatizovat čím dál lépe.

Vývojář, který dokáže pochopit business problém, rozdělit ho, navrhnout řešení, pracovat napříč stackem, vyhodnotit trade-offy a výsledný systém skutečně dostat do produkce, získává naopak extrémně silný nástroj.

Samostatnost bude důležitější než úzká specializace

Jedna z věcí, které na AI při vývoji považuji za nejzajímavější, je to, jak rozšiřuje okruh úkolů, které dokáže jeden člověk rozumně zvládnout.

Frontend developer si může rychleji poradit s backendem. Backend developer dokáže připravit použitelnější interface. Founder, který technice rozumí, může během krátké doby vytvořit interní nástroj, na který by dříve potřeboval dalšího člověka.

Neznamená to, že specializace přestává mít hodnotu. U složitých systémů bude hluboká expertiza pořád zásadní.

Ale hranice mezi jednotlivými rolemi začínají být méně pevné.

Člověk s dobrými základy a schopností správně používat AI může zasahovat do mnohem větší části produktu než dříve. Místo toho, aby každá drobná změna cestovala mezi několika specialisty, může jeden člověk převzít větší kus problému od začátku až do konce.

A to podle mě mění hodnotu lidí, kteří umí skutečně stavět, ne jen vykonávat jeden úzký typ úkolu.

Ne každý výstup AI si zaslouží stejnou úroveň kontroly

Pokud chceme AI používat více autonomně, potřebujeme zároveň lépe pracovat s rizikem.

Nedává smysl kontrolovat úplně stejně změnu textu v interním dashboardu a migraci databáze s produkčními daty.

Čím větší potenciální dopad chyba má, tím silnější musí být kontrolní mechanismy kolem ní.

U nízkorizikových úkolů může být správný workflow velmi jednoduchý: AI provede změnu, spustí testy a člověk ji rychle zkontroluje.

U kritických částí systému potřebujeme code review, automatické testy, staging, observability, možnost rollbacku a někdy i explicitní schválení dalšího člověka.

To není problém specifický pro AI. Dobrý engineering takhle pracoval vždycky.

AI ale opět zvyšuje rychlost, a tím zesiluje důsledky špatně nastaveného procesu. Pokud dokáže agent během hodiny změnit desítky souborů, potřebujeme o to lepší způsob, jak zjistit, jestli změny skutečně dělají to, co měly.

Autonomie bez kontroly není leverage.

Je to jen rychlejší cesta k chybě.

Zajímavé je, že samotná AI produktivita není vůbec jednoduchá na měření

Je lákavé předpokládat, že lepší model automaticky znamená rychlejšího vývojáře. Reálná data ale ukazují, že vztah není tak přímočarý.

METR například v experimentu z roku 2025 sledoval zkušené open-source developery pracující na projektech, které velmi dobře znali. S tehdejšími AI nástroji jim práce v průměru trvala o 19 % déle, přestože sami očekávali výrazné zrychlení. V pozdějším experimentu s novějšími nástroji už data naznačovala posun směrem ke zrychlení, ale výzkumníci sami upozorňovali, že kvůli výběrovým efektům nebylo možné jeho velikost spolehlivě určit.

To mi přijde důležité hlavně proto, že to rozbíjí jednoduchou představu „AI = automaticky vyšší produktivita“.

Záleží na člověku, typu úkolu, znalosti projektu, kvalitě nástroje i prostředí, ve kterém pracuje. V průzkumu METR z jara 2026 už techničtí pracovníci sami uváděli výrazně větší přínos novějších AI nástrojů, autoři ale znovu upozorňovali, že subjektivní odhad produktivity může skutečný efekt nadhodnocovat.

Jinými slovy: nestačí koupit lepší model.

Je potřeba vybudovat způsob práce, ve kterém jeho schopnosti skutečně dokážeme využít.

Dobré systémy získávají díky AI větší náskok

A tady se podle mě dostáváme k nejzajímavějšímu důsledku.

Představme si dva stejně schopné týmy, které dostanou stejné AI nástroje.

První má dobře rozdělený produkt, automatické testování, jasný deployment proces, kvalitní zadání, observability, dokumentovaná rozhodnutí a rychlou zpětnou vazbu z produkce.

Druhý funguje hlavně díky tomu, že několik zkušených lidí drží celý systém v hlavě a problémy řeší operativně, když nastanou.

AI zrychlí oba.

Ale nezrychlí je stejně.

První tým může postupně předávat AI větší a větší části práce, protože má infrastrukturu, která dokáže výsledek kontrolovat. Druhý musí každý krok hlídat ručně, protože automatizovanému procesu nemá čím věřit.

Rozdíl mezi nimi se tak může místo zmenšování ještě zvětšit.

To je podle mě podstatnější než otázka, jestli AI nahradí konkrétní pozici.

Kdo tedy bude mít problém?

Nemyslím si, že smysluplná hranice vede mezi „lidmi“ a „AI“.

Spíš mezi lidmi a firmami, kteří dokážou AI zapojit do dobrého systému, a těmi, kteří ji používají jako rychlejší autocomplete.

Problém budou mít role postavené převážně na mechanickém převodu dobře definovaného vstupu na dobře definovaný výstup. Pokud člověk dostane přesný ticket, podle něj něco naprogramuje a tím jeho odpovědnost končí, velká část jeho práce je z principu vhodná k automatizaci.

Mnohem odolnější budou lidé, kteří pracují s nejasností.

Dokážou pochopit problém ještě předtím, než existuje ticket. Umí mluvit se zákazníkem. Rozumí technologii dostatečně hluboko na to, aby poznali špatný návrh. Chápou ekonomiku produktu. Dokážou rozhodovat mezi několika řešeními a převzít odpovědnost za výsledek.

A právě takoví lidé mohou mít díky AI paradoxně ještě větší leverage než dříve.

AI tedy vývojáře nenahrazuje?

Tak absolutně bych to určitě netvrdil.

Některé úkoly už nahrazuje dnes a jejich podíl bude pravděpodobně dál růst. Je dost možné, že stejný objem softwaru bude postupně potřebovat méně lidí než dříve. Stejně tak se může výrazně změnit to, co od juniorních i seniorních vývojářů očekáváme.

Jen si nemyslím, že správný závěr je: „AI umí programovat, takže vývojáře nebudeme potřebovat.“

Software nikdy nebyl jen o psaní kódu.

Je o překladu nejasných problémů do funkčních systémů. O rozhodování. O trade-offech. O komunikaci mezi produktem, technologií a byznysem. O kontrole výsledku a odpovědnosti za to, co pustíme mezi skutečné uživatele.

AI dramaticky zlevňuje jednu velkou část tohoto procesu — samotnou produkci.

A tím zvyšuje relativní hodnotu všeho ostatního.

Proto bych otázku, jestli AI nahradí vývojáře, otočil.

Co zůstane hodnotné ve chvíli, kdy bude samotné psaní kódu téměř zdarma?

Podle mě právě schopnost navrhovat dobré systémy, rozhodovat se v nejasnosti, propojovat jednotlivé části produktu a poznat, kdy výsledek opravdu dává smysl.

AI špatné systémy nezachrání.

Jen mnohem rychleji ukáže, že byly špatné už předtím.

Zdroje

• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR — We Are Changing Our Developer Productivity Experiment Design
• METR — Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity