MŮŽE UMĚLÁ INTELIGENCE NAHRADIT PROGRAMÁTORY?
Nástroje založené na umělé inteligenci dokážou psát kód, navrhovat testy a opravovat některé chyby. Z toho ale ještě neplyne, že přebírají celou práci programátora. Výsledek závisí na typu úkolu, znalosti systému, kvalitě kontroly a odpovědnosti za provoz.
TŘI STUDIE, TŘI RŮZNÉ VÝSLEDKY
Původní článek porovnává tři studie, které měřily odlišné situace.
První sledovala jednoduchý laboratorní úkol: vytvoření malého serveru v JavaScriptu podle jasného zadání a automatických testů. Účastníci s GitHub Copilotem úkol dokončili výrazně rychleji. Takové měření dobře ukazuje pomoc při ohraničené práci, ale neobsahuje provoz velkého systému, týmovou kontrolu ani řešení výpadků.
Druhá studie pracovala s tisíci vývojářů ve firmách a zjistila přibližně čtvrtinové zvýšení počtu dokončených úkolů týdně. Firemní prostředí je realističtější, ale ani počet uzavřených úkolů sám neříká, kolik chyb vzniklo, kolik času zabrala kontrola a zda se změnila dlouhodobá kvalita.
Třetí studie sledovala zkušené vývojáře při práci ve známých otevřených projektech. S AI byli v průměru pomalejší, přestože měli pocit, že jim nástroj pomáhá. U složitého kódu může být první návrh rychlý, ale člověk musí prověřit odbočky, které by sám nenapsal, a hlídat souvislosti, které model nezná.
PROGRAMÁTORSKÁ PRÁCE MÁ VÍCE VRSTEV
Generování kódu je pouze jedna část. Dalšími jsou pochopení požadavku, návrh architektury, orientace ve starém systému, kontrola změn, bezpečnost, nasazení a odpovědnost při poruše.
AI může být velmi dobrá při doplňování opakující se kostry kódu, přípravě prvního návrhu, převodu mezi formáty nebo tvorbě testů. Méně jistá je tam, kde zadání není úplné, systém obsahuje historické výjimky nebo chyba může poškodit zákazníky.
KONTROLA MŮŽE SPOTŘEBOVAT UŠETŘENÝ ČAS
Užitečnost nástroje se nemá měřit jen dobou, za kterou vznikne návrh. Je potřeba připočítat čas na přečtení změn, spuštění testů, ověření bezpečnosti, opravy a uvedení do stavu, za který je vlastník služby ochoten nést odpovědnost.
Pokud se psaní zkrátí o půl hodiny, ale kontrola se prodlouží o hodinu, produktivita neklesla kvůli tomu, že model „neumí programovat“. Úkol pouze přesunul práci z tvorby do ověřování.
VEŘEJNÝ TEST NENÍ VAŠE FIRMA
Srovnávací testy mohou měřit, zda agent opraví předem připravený problém v konkrétním repozitáři a projde testy. Nezkoušejí pokaždé poradu s produktem, migraci bez výpadku, odpovědnost za osobní údaje nebo noční rozhodnutí, zda změnu vrátit zpět.
Výsledek benchmarku je proto užitečný signál, nikoli personální plán. Model s vysokým skóre může být slabší v češtině, interní dokumentaci nebo technologii, kterou firma používá. Naopak nástroj s nižším veřejným skóre může dobře zvládat úzkou každodenní práci konkrétního týmu.
JAK AI TESTOVAT V REÁLNÉM TÝMU
Vyberte několik typických úloh: jednoduchou s jasnými testy, změnu ve známé části systému a úkol s bezpečnostním nebo provozním rizikem. Každou proveďte bez asistenta i s ním.
Měřte nejen dobu vytvoření návrhu, ale také kontrolu, počet oprav, nalezené chyby a čas do bezpečného nasazení. Sledujte, zda nástroj pomáhá začátečníkům i seniorům stejně a zda jeho přínos neklesá s rostoucí znalostí projektu.
CO TO ZNAMENÁ PRO PRACOVNÍ MÍSTA
Rychlejší práce může vést k menšímu týmu, ale také k většímu množství funkcí, rychlejším opravám nebo vyšší kvalitě. Samotné technické zrychlení nerozhoduje, co firma udělá s ušetřeným časem.
Zároveň vzniká otázka výcviku. Jednoduché úkoly jsou pro firmu nákladem, ale pro juniora prostředím, v němž se učí poznávat chyby. Pokud je AI převezme, organizace musí vytvořit jinou cestu k odbornosti.
ZÁVĚR
Umělá inteligence pravděpodobně promění programátorskou práci po jednotlivých úkolech, nikoli jediným okamžikem, kdy „zmizí programátor“. Správná otázka zní: kde nástroj šetří čas, kde přidává kontrolu a kdo ponese odpovědnost, když automaticky vytvořená změna selže v reálném provozu.
RYCHLEJŠÍ PSANÍ KÓDU NENÍ TOTÉŽ CO ODPOVĚDNOST ZA CELÝ SYSTÉM
Některé nástroje umělé inteligence dokážou programátorům výrazně urychlit dílčí práci. To ale ještě neznamená, že nahrazují celé povolání.
Tři citované studie ukázaly tři různé výsledky. V laboratorním úkolu napsali lidé s pomocí GitHub Copilotu jednoduchý server podstatně rychleji. Ve firemním prostředí jiná studie naměřila přibližně o čtvrtinu více dokončených úkolů týdně. U zkušených vývojářů, kteří dobře znali své rozsáhlé projekty, však další měření zjistilo s AI naopak zpomalení.
PROČ SE VÝSLEDKY LIŠÍ
Každá studie měřila něco jiného. Jedna sledovala jasně zadaný úkol s automatickými testy. Druhá běžné pracovní úkoly ve firmách. Třetí změny ve složitém kódu, o němž měli lidé mnoho znalostí, které model neměl.
AI proto často pomáhá u rutinního a opakujícího se kódu, prvních návrhů nebo testů. U známého a složitého systému může přidat návrhy, které musí zkušený člověk dlouze prověřovat.
PRÁCE SE MŮŽE PŘESUNOUT
Když AI zkrátí psaní, část času se může přesunout do kontroly. Někdo musí návrh přečíst, pochopit jeho důsledky, doplnit testy a rozhodnout, zda je bezpečné změnu nasadit. Pokud se ušetřený čas ztratí při ověřování, práce nezmizela. Jen se přesunula na jiné místo.
Veřejné testy modelů navíc obvykle nezkoušejí porady s produktem, odpovědnost za bezpečnost, noční výpadek ani rozhodnutí, zda změnu vrátit zpět.
ZÁVĚR
Správná otázka nezní pouze „nahradí AI programátory?“. Přesnější je ptát se: které konkrétní úkoly urychlí, kolik času zabere kontrola a kdo ponese odpovědnost, pokud změna poškodí skutečný systém.
Rubrika: Technologie & AI Autor: V Délka čtení: ~27 min Prameny a další četba: 22 položek Témata: AI, programování, Copilot, Cursor, produktivita, testy, provoz, odpovědnost SEO / pracovní titulek: Může AI nahradit programátory?
Může AI nahradit programátory? Otázka zní jednoduše jen do chvíle, než si všimneme, že neporovnáváme jednu práci. Zkrácení času na HTTP serveru v laboratoři není týden v týmu. Vyřešené GitHub issue není on-call. 50% time horizon modelu není polovina úvazku. A skóre benchmarku nepodepisuje incident. Článek proto nehledá datum, kdy programátor zmizí. Hledá, který úkol asistent zrychlí, kam se práce přestěhuje při kontrole a kdo zůstane u výpadku.
1. Dvanáct zelených testů na HTTP serveru není noční revert v produkci
Páteční demo vypadá přesvědčivě. Junior ukáže malý HTTP server v JavaScriptu. Testy svítí zeleně. Vysvětlí, že s Copilotem napsal řešení mnohem rychleji, než čekal. Tech lead sedí vedle něj a říká, že ve velkém interním repozitáři mu agent často přidá práci, protože kontroluje odbočky, které by sám vůbec nenapsal. Product manager ukazuje graf uzavřených tiketů. Ředitel se ptá, jestli má příští čtvrtletí nabírat méně lidí. On-call inženýr položí kratší otázku: kdo to v noci revertne, když zelené testy nestačí.
Na první pohled jde o spor „AI nahradí, nebo nenahradí programátory“. Ve skutečnosti každý měří jiný objekt. Junior laboratorní úkol s jasným zadáním. Tech lead zralý systém, který zná. Product manager počet dokončených jednotek práce. Ředitel by rád převedl úkol na plán náboru. On-call člověk měří odpovědnost za provoz.
Peng, Kalliamvakou, Cihon a Demirer ve studii s GitHub Copilotem měřili od 15. května do 20. června 2022 programátorský úkol: implementaci HTTP serveru v JavaScriptu, který měl projít dvanácti testy. Ve studii bylo 95 freelancerů z Upworku a úkol dokončilo 35 lidí v každé větvi. Autoři uvádějí zkrácení času o 55,8 % s 95% intervalem spolehlivosti 21 až 89 [1]. To je silné číslo. Neměří však produkční codebase, review, incident, vlastnictví služby ani noční rozhodnutí, zda rollback poškodí zákazníky víc než chyba.
Rychlejší HTTP server není totéž co odpovědnost za produkční systém.
— Jiný Kontext
2. Programátorská práce má nejméně šest vrstev
Když se na obrazovce objeví diff, vzniká dojem, že „kód napsala AI“. Jenže výsledek vzniká v několika vrstvách. Každá se dá měřit jinak a každá může přinést jiný závěr.
- Generování kódu: doplňování, boilerplate, testy, skripty a drobné transformace.
- Úprava známého systému: práce v repozitáři, jehož zkratky, dluhy a nepsaná pravidla člověk zná.
- Benchmark agenta: issue, patch, spuštění testů a skóre na veřejné sadě.
- Délka úkolu: horizont, na kterém model dokončuje čím dál delší práci s určitou úspěšností.
- Měření v týmu: tikety, lead time, review, defekty, přerušení práce a změna procesu.
- Odpovědnost: merge, incident, bezpečnostní dopad, audit, zákazník a rollback.
Tyto vrstvy nejsou jemné nuance. Jsou to různé předměty měření. Peng měří čas do průchodu testy na jasně ohraničeném úkolu [1]. Cui a spoluautoři měří v terénních experimentech dokončené úkoly v organizacích [2]. METR v roce 2025 měří zkušené open-source vývojáře na reálných issues v repozitářích, které dobře znají [4][5]. SWE-bench měří opravu GitHub issues v harnessu [9]. Time horizon měří, jak dlouhé softwarové úkoly modely zvládají s danou úspěšností [6].
Osnova trhu práce se ptá, co se stane s povoláním. Tady je otázka užší. Která vrstva software se zrovna měří? Pokud ji nepojmenujeme, skončíme u věty, která z jednoho zeleného testu dělá personální politiku a z jednoho zpomalení zákaz nástroje.
3. Nejlepší asistent je ten, jehož chybu zachytí test, review a rollback
U kódu je lákavé měřit rychlost psaní. Jenže software není textový odstavec. Chyba může být zjevná, levná a vratná. Nebo hladce projde testy a objeví se až v datech zákazníka. Proto dobrý asistent není jen ten, který navrhne nejvíc řádků. Je to nástroj, jehož selhání je vidět dřív, než se stane provozním problémem.
| Druh selhání | Jak vypadá | Jak testovat | Co omezí škodu |
|---|---|---|---|
| Konfabulace kódu | Diff vypadá hotově, ale mění autorizaci nebo okrajový stav | Review, CI, vlastnický test a rollback | Člověk merguje, agent má omezená oprávnění |
| Špatný design měření | Verdikt o povolání z jednoho RCT | Oddělit úkol, tiket, známé repo a provoz | Nepřenášet číslo na úvazek |
| Přesun do review | Commit je rychlejší, merge pomalejší | Měřit zadání, kontrolu a přijatelný stav | Hodnotit celý řetězec |
| Benchmark jako výpověď | SWE-bench skóre jako náhrada práce týmu | Vyjmenovat, co sada neměří | Interní úlohy před veřejným titulkem |
| Incident bez vlastníka | „Napsala to AI“ místo odpovědného merge | Kdo revertuje, kdo hlásí, kdo vysvětluje | Runbook na člověka a organizaci |
Tím se mění i nákupní otázka. Neptáme se pouze, kolik času asistent ušetří při psaní. Ptáme se, zda máme testy, review, observabilitu, oprávnění a rollback, které jeho chybu unesou. Tam, kde je chyba levná a kontrola jasná, může být přínos velký. Tam, kde chyba unikne do produkce, může rychlejší generování jen posunout problém na dražší místo.
4. Tři designy, tři směry. Ne tři verdikty o povolání
Veřejná debata má ráda jeden graf. Výzkum produktivity programátorů s AI nabízí spíš tři různé designy.
Peng a spoluautoři měřili laboratorní úkol s jasným výsledkem: HTTP server v JavaScriptu, dvanáct testů, freelancery z Upworku a čas do dokončení [1]. Cui, Demirer, Jaffe, Musolff, Peng a Salz ve verzi z února 2025 pracují s 4 867 vývojáři v Microsoftu, Accenture a jedné firmě z Fortune 100. Jejich instrumentální odhad užívání Copilotu na počet dokončených úkolů je +26,08 % týdně se směrodatnou chybou 10,3 [2][3]. METR a Becker et al. v roce 2025 sledovali 16 zkušených vývojářů, 246 reálných issues, průměrný lidský čas 2,0 hodiny a repozitáře s přibližně 23 tisíci hvězdami. S Cursorem Pro a Claude 3.5/3.7 naměřili prodloužení času o 19 % [4][5].
To nejsou tři verdikty. Jsou to tři okna. V jednom je jasný skeleton a testy. V druhém běžné firemní úkoly a adopce nástroje. Ve třetím lidé, kteří znají svůj kód a musí kontrolovat návrhy proti kontextu, který mají v hlavě. Žádné z těchto měření samo neříká, zda zanikne pracovní smlouva. A žádné z nich nejde poctivě použít bez popisu populace, období, metriky a toho, co se nepočítalo.
5. Zrychlení na skeletonu není úvazek juniora
Výsledek Pengovy studie je důležitý právě proto, že je úzký. Ukazuje, že na dobře vymezeném úkolu s testovatelným výstupem může asistent výrazně zkrátit čas. Zvlášť tam, kde je hodně boilerplate a kde testy rychle řeknou, zda řešení funguje. To je přesně typ práce, na němž se učí mnoho méně zkušených lidí.
Z toho neplyne, že lze odečíst juniora z rozpočtu. Studie měla konkrétní úkol, konkrétní období a dokončený vzorek 35 lidí v každé větvi [1]. Neměřila onboarding, znalost firemní domény, komunikaci s produktem, ladění požadavků, review cizího kódu ani držení služby v provozu. Neměřila ani to, zda tým za půl roku nezaplatí chybějící trénink nových lidí.
Správná manažerská věta tedy nezní: „AI udělá juniorní práci.“ Zní: „U úkolů podobných tomuto se může psaní výrazně zkrátit, pokud máme jasné testy a levnou kontrolu.“ To je méně efektní. Je to však použitelnější.
Pro tým z toho plyne jiný test. Vzít vlastní malý úkol, který se podobá skeletonu: známé zadání, jasný výsledek, automatické testy. Nechat jej udělat s asistentem a bez něj. Změřit nejen čas psaní, ale i čas, kdy senior čte diff. Pokud se úspora ztratí v review, nebyla odstraněna práce. Byla přesunuta.
Tento přesun může být přesto dobrá zpráva. Junior, který s asistentem rychleji vyrobí první návrh, může dříve narazit na otázky architektury, testování a odpovědnosti. To ale platí jen tehdy, pokud tým nenechá model nahrazovat učení. Když člověk neví, proč kód prošel testem, neumí jej udržovat. Když neumí vysvětlit vlastní diff, není připravený nést změnu do sdíleného systému. Přínos asistenta se proto musí měřit spolu s učením: zrychlil cestu k pochopení, nebo jen vyrobil více textu, který někdo jiný musí rozplést?
6. Víc dokončených tiketů není víc kvality v provozu
Cui a spoluautoři posouvají debatu z laboratoře do firem. To je velká změna. Čtyři tisíce osm set šedesát sedm vývojářů, tři organizace a měření dokončených úkolů týdně jsou blíž tomu, co manažery zajímá [2]. Odhad +26,08 % dokončených úkolů týdně je přitom nižší než laboratorní efekt u Pengovy úlohy, což autoři sami dávají do souvislosti s rozdílem mezi čistým úkolem a běžnou prací [2].
Jenže i tiket je jen jednotka procesu. Dokončený úkol není automaticky kvalitní změna v produkci. Záleží na tom, co organizace považuje za dokončené, jak silné je review, zda se měří defekty, incidenty, zákaznické dopady a čas ostatních lidí. Tým může s asistentem zavřít víc drobných úkolů a zároveň zatížit review. Nebo může skutečně zvýšit průchodnost bez poklesu kvality. Data o dokončených úkolech jsou začátek, ne konečný účet.
Tady se často láme debata o nahrazení. Pokud firma sleduje jen počet tiketů, bude mít pokušení přepočítat procento na lidi. Pokud sleduje i defekty, review a provozní změny, může zjistit něco jiného: asistent zvyšuje objem práce, ale vyžaduje jiný způsob kontroly a jiné rozdělení odpovědnosti.
U terénních měření je navíc důležité, kdo nástroj skutečně používá a na jaké úkoly. Adopce nebývá náhodně rozprostřená jako barva po zdi. Někdo sahá po asistentovi u jednoduchých oprav, někdo u rešerše knihoven, někdo u testů a někdo skoro vůbec. Pokud se pak sleduje počet dokončených úkolů, výsledek může míchat schopnost nástroje, ochotu lidí jej používat, typ přidělených tiketů a pravidla týmu. Cui a spoluautoři se tomu věnují výzkumným designem; čtenář by si z toho měl odnést hlavně opatrnost při překladu do vlastní firmy [2].
Firemní pilot proto nemá jen zapnout nástroj a po měsíci spočítat uzavřené položky. Musí rozlišit typy úkolů, zkušenost lidí, velikost diffu, čas review a počet vrácených změn. Jinak může dobrá zpráva o průchodnosti zakrýt nový bottleneck u těch, kteří změny kontrolují.
Ještě přesnější je sledovat, kdo zrychlení platí. Pokud asistent pomůže autorovi úkolu, ale reviewer stráví více času ověřováním, úspora se přesunula mezi lidmi. Pokud se počet tiketů zvýší, ale naroste počet vratek z QA, úspora se přesunula do jiné fronty. Pokud se zrychlí celý řetězec od zadání po bezpečně přijatou změnu, pak má tým důkaz, který stojí víc než obecný titulek o AI.
7. Zpomalení u lidí, kteří repo znají, není důkaz, že asistent nefunguje
METR v roce 2025 přinesl nepohodlný výsledek. Zkušení open-source vývojáři pracovali na issues v repozitářích, které dobře znali. Průměrná zkušenost s daným repozitářem byla několik let, úkoly měly průměrný lidský čas 2,0 hodiny a studie probíhala od února do června 2025. Když měli povoleno používat AI nástroje, čas se v průměru prodloužil o 19 % [4][5].
Ještě zajímavější je očekávání. Vývojáři předem čekali zrychlení o 24 %. Po studii stále odhadovali, že byli s AI rychlejší o 20 %, přestože měřený výsledek šel opačným směrem [5]. To není důkaz, že vývojáři nevědí, co dělají. Je to varování, že subjektivní pocit plynulé práce může klamat i zkušené lidi.
Z toho neplyne, že asistent nefunguje. Plyne z toho, že ve známém systému má člověk v hlavě kontext, který model nemá. Ví, které zdánlivě jednoduché řešení rozbije starou integraci. Ví, proč je zvláštní helper schválně zvláštní. Ví, že test selže jen v kombinaci s daty, která nejsou v repozitáři. AI může přidat návrhy, ale také slepé uličky, které je třeba ověřit.
Tři testy produktivity
Měříte čas do zelených testů na novém skeletonu? Měříte počet dokončených úkolů v týmu? Nebo měříte čas na issue ve vlastním zralém repozitáři? Tři kladné odpovědi se nesčítají. Každá patří do jiného rozhodnutí.
8. 50% time horizon není 50% náhrady úvazku
METR ve studii Kwa et al. měří schopnost modelů dokončovat stále delší softwarové úkoly. Pracuje se sadou 170 úkolů, mimo jiné HCAST, RE-Bench a 66 SWAA, a s dvanácti frontier modely. U modelu o3 uvádí přibližně 110 minut lidského času jako 50% time horizon [6]. Studie zároveň odhaduje, že se tento horizont od roku 2019 zdvojnásoboval zhruba každých sedm měsíců, přesněji 207 dní s 95% intervalem 166 až 240 dní [6][7].
To je důležité pro směr vývoje. Není to však věta, že model nahradí polovinu programátora. 50% horizont znamená, že model má na dané sadě přibližně poloviční úspěšnost u úkolu odpovídajícího určitému lidskému času. METR také uvádí, že 80% horizont je zhruba čtyřikrát až šestkrát kratší [6][7]. Produkce většinou nechce poloviční šanci. Chce spolehlivost, opakovatelnost a odpovědnost.
Poznámka METR z 20. března 2026 navíc upozorňuje, že výsledky time horizon jsou citlivé na modelovací předpoklady, regularizaci a odhad lidských časů [8]. To trend neruší. Jen brání překladu do jednoduché věty o měsících práce v libovolné firmě.
50% time horizon říká, jak dlouhý úkol model občas dokončí. Neříká, kdo v noci revertne výpadek.
— Jiný Kontext
9. SWE-bench opravuje issue s testy. Nenavrhuje architekturu a nenese pager
SWE-bench je užitečný benchmark, protože se snaží vyjít z reálných GitHub issues. Původní práce Jimeneze a spoluautorů pracovala s 2 294 issues z dvanácti Python repozitářů. V paperu dosáhl Claude 2 s BM25 vyhledáváním 1,96 % vyřešených issues; GPT-4 byl kvůli rozpočtu hodnocen na 25% podmnožině [9]. Pozdější SWE-bench Verified od OpenAI zavedl lidsky ověřený vzorek 500 položek a uvádí GPT-4o se skóre 33,2 % [10]. Epoch AI popisuje ověřenou sadu také jako variantu s 500, respektive 484 použitelnými samples podle nastavení [11].
To je pokrok v měření agentů. Není to práce programátora. Benchmark neobsahuje poradu s produktem, rozhodnutí o architektuře, čtení interních incidentů, migraci bez výpadku, bezpečnostní review ani on-call. Obsahuje issue, repozitář, testy a způsob bodování.
Správná otázka tedy nezní, zda SWE-bench ukazuje budoucnost programování. Ukazuje jednu důležitou vrstvu: schopnost modelů najít a opravit některé chyby v otevřených repozitářích pod testem. Pro výběr nástroje je to signál. Pro plán odpovědnosti v produkci je to příliš málo.
10. Zrychlení boilerplate u méně zkušených není zánik seniora
Výsledky kolem kódovacích asistentů často ukazují větší přínos u méně zkušených lidí nebo u lidí v méně známé části práce. To dává smysl. Tam, kde člověk hledá syntaxi, boilerplate, běžný vzor nebo první návrh testu, může model rychle dodat materiál k úpravě. Tam, kde senior drží v hlavě historii systému, mohou návrhy přidat šum.
Z toho neplyne zánik seniora. Neplatí ani opačná pohodlná věta, že senior je mimo dosah změny. Spíš se mění složení práce. Méně zkušený člověk může rychleji dojít k prvnímu řešení, ale musí se naučit číst diff, rozumět testům a poznat, kdy model jen sebevědomě opsal špatný vzor. Senior může méně psát rutinní kód, ale víc navrhovat hranice, kontrolovat bezpečnost a rozhodovat o přijetí změny.
Tým, který z toho udělá jen úsporu lidí, riskuje dvě věci. Ztratí učňovskou práci, na níž vyrůstají budoucí senioři. A přenese kontrolu na menší počet lidí, kteří pak nesou větší frontu review. Tým, který asistenta zakáže kvůli jednomu zpomalení, zase může nechat ležet levné zisky u dobře testovatelných úkolů.
11. Používání nástroje není důvěra ve výstup
Stack Overflow Developer Survey 2025 ukazuje vysokou adopci AI nástrojů. Podle přehledu používá nebo plánuje používat AI nástroje 84 % respondentů, oproti 76 % v roce 2024. U profesionálů se uvádí, že 51 % používá AI denně. Zároveň 46 % respondentů spíš nedůvěřuje přesnosti výstupu než důvěřuje, zatímco důvěru vyjadřuje 33 % [12][13].
To není reprezentativní výběr všech programátorů v ekonomice. Je to samovýběr respondentů Stack Overflow. Přesto je signál užitečný: používání a důvěra nejsou totéž. Člověk může nástroj používat každý den, protože šetří čas při hledání, návrhu testu nebo vysvětlení chyby. Zároveň nemusí věřit, že výstup bez kontroly patří do produkce.
Právě tento rozdíl je pro software zdravý. Programátor nemusí být odpůrce AI, aby odmítl autonomní deployment. Nemusí být nadšenec, aby používal doplňování kódu. Důvěra není nálepka na nástroj. Je to vztah k určitému úkolu, testům, oprávněním a dopadu chyby.
12. Kontrola může sežrat úsporu z generování
Asistent často zrychlí první návrh. To je vidět i bez studie. Méně viditelný je druhý účet: kontrola. Člověk musí přečíst diff, pochopit, proč změna funguje, spustit testy, dopsat chybějící test, zkontrolovat bezpečnost, najít vliv na migrace a rozhodnout, zda se dá výsledek přijmout.
U jednoduchého úkolu může být kontrola levná. Testy řeknou ano nebo ne a chyba nemá velký dopad. U zralého systému je kontrola samotná prací. Model může vygenerovat řešení, které projde lokálně, ale neodpovídá architektuře služby. Může upravit více souborů, než bylo potřeba. Může odstranit zdánlivě zbytečný guard, který chránil historický okrajový případ. Každá taková věc přidává čas seniorovi.
Kontrola má také různé ceny podle prostředí. V knihovně bez dat může stačit test a krátké review. V platebním toku, zdravotnickém systému nebo interní administraci s osobními údaji je stejný diff dražší, protože dopad chyby je dražší. Není to otázka strachu z AI. Je to stejná logika, kterou týmy používají u lidských změn: riskantní změna potřebuje víc očí, lepší observabilitu a plán návratu.
Jak testovat, kam se přestěhovala práce
Vyberte vlastní cvičný repozitář nebo interní sandbox. Nepoužívejte cizí produkční systémy a nepřekračujte oprávnění. U stejného typu úkolu měřte tři časy: zadání, kontrolu a uvedení do stavu, za který byste podepsali incident. Pokud se psaní zkrátilo, ale kontrola narostla víc, nemáte náhradu programátora. Máte přesun práce.
13. Trh práce je jiná otázka než merge do produkce
V debatě o programátorech se snadno otevře širší otázka trhu práce. Kolik je ICT specialistů, jak rostou mzdy, kolik studentů přichází na školy, co říkají OECD, ILO nebo Eloundou o expozici úkolů. To jsou legitimní témata. Jenže patří do jiné mapy než otázka, zda konkrétní asistent bezpečně urychlí změnu v repozitáři.
ČSÚ například popisuje ICT specialisty v Česku a jejich mzdy [14][15][16]. Eloundou, ILO a OECD popisují expozici úkolů a změny práce v širší ekonomice [17][18][21]. Tyto prameny neříkají, zda váš agent správně upraví autorizaci, zda review zachytí chybu nebo kdo v noci spustí rollback. Proto v tomto článku nestavíme žebříček profesí a nepřenášíme procenta z trhu práce do software procesu.
Správná hranice zní: trh práce může říct, proč je otázka důležitá. Neodpoví za merge. Jestli asistent pomáhá konkrétnímu týmu, musí ukázat vlastní úkol, vlastní test, vlastní review a vlastní provozní odpovědnost. Bez toho je debata o nahrazení programátorů příliš široká na to, aby vedla k bezpečnému rozhodnutí.
To je také důvod, proč zde nepoužíváme procenta z článku o povoláních jako zkratku. Expozice úkolů v ekonomice může být vysoká nebo nízká podle metodiky, ale merge request v konkrétním repozitáři se rozhoduje podle jiných důkazů. Má diff test? Rozumí mu reviewer? Zlepšil službu? Nepřidal tichý bezpečnostní dluh? Pokud tyto odpovědi chybějí, pracovní trh nepomůže. Pokud jsou jasné, tým může nástroj používat bez velkých prohlášení o zániku profese.
14. Skóre benchmarku nepodepisuje incident
Když agent vyřeší benchmark, podepíše to skóre. Když změna shodí produkci, podepíše to organizace. Tento rozdíl je základní. Model není zaměstnanec ve smluvním vztahu, není držitel pageru a není osoba, která klientovi vysvětlí, proč se data zpracovala špatně. Nástroj může navrhnout diff. Odpovědnost za jeho přijetí zůstává v procesu.
AI Act řadí některé systémy v zaměstnání a řízení pracovníků mezi vysoce rizikové podle použití, například při náboru nebo hodnocení osob [20]. To zde není argument, že Copilot je zakázaný, ani že programátoři zmizí. Je to připomínka, že použití AI v rozhodnutí o člověku nebo práci má jiné požadavky než generování testu v sandboxu.
Před mergem do produkce
Je výsledek pokrytý testy, které měří skutečné riziko, ne jen šťastnou cestu? Kdo je vlastník služby a kdo má právo změnu přijmout? Existuje rollback, observabilita a plán komunikace? Jsou tajemství oddělená od nástroje, který je nemá vidět? Pokud na tyto otázky tým neumí odpovědět, skóre benchmarku mu nepomůže.
15. Agent s právem měnit soubory je jiná chyba než halucinovaný snippet
Starší debata o AI v programování často vypadala takto: model navrhne snippet a člověk jej zkopíruje. Dnes agent čte repozitář, upravuje soubory, spouští testy, instaluje závislosti a někdy připravuje commit. To je jiná třída rizika. Chybný snippet je text. Chybný agentní krok může změnit stav projektu.
Nejde jen o kvalitu modelu. Jde o oprávnění. Smí agent číst produkční tajemství? Smí sahat mimo workspace? Smí spouštět příkazy, které mění databázi? Smí pushovat? Smí opravovat konflikt tak, že odstraní cizí práci? Každé „smí“ mění cenu chyby.
Dobrá praxe proto nezačíná větou, že model je chytrý. Začíná sandboxem, náhledem změn, oddělením tajemství, omezením zápisu a lidským schválením tam, kde výsledek mění sdílený stav. Agent může být výborný pomocník v bezpečně vymezeném prostoru. Stejný agent s příliš širokým přístupem může udělat škodu rychleji než člověk, kterého měl zrychlit.
Zvlášť důležitý je rozdíl mezi návrhem a akcí. Návrh může být špatný a nic se nestane, pokud jej člověk odmítne. Akce mění soubor, konfiguraci, větev, balíček nebo prostředí. Jakmile agent jedná, potřebuje stejnou logiku jako ostatní automatizace: nejmenší potřebná oprávnění, záznam kroků, možnost náhledu a možnost návratu. Inteligence modelu tuto logiku neruší. Jen zvětšuje rozsah toho, co automatizace dokáže navrhnout.
V běžném vývojářském procesu to znamená jednu prostou brzdu. Agent smí urychlit přípravu změny, ale přijetí změny musí pořád projít místem, kde je jasné, kdo rozhodl. Commit bez vlastníka, test bez smyslu a zelený běh bez možnosti návratu nejsou známky vyspělé AI. Jsou to slabiny procesu, které AI jen zrychlila.
16. Závislost na asistentovi je jiný účet než rychlost commitu
Tým může s asistentem zrychlit a přesto si vytvořit nový dluh. Ne v kódu, ale v pracovním postupu. Pokud lidé přestanou rozumět změnám, které přijímají, roste závislost. Pokud se znalost systému přesune z hlavy týmu do promptů a nástroje, roste riziko při výpadku služby, změně ceny nebo změně modelu.
Závislost nemusí být špatná. Každý tým je závislý na editoru, CI, cloudu i balíčkovacím registru. Rozdíl je v tom, zda závislost vidí. Pokud asistent zrychluje rutinu a tým stále umí číst diff, udržovat testy a řešit incident bez něj, je to nástroj. Pokud bez něj neumí pochopit vlastní změny, je to provozní slabina.
Tento účet se v benchmarku obvykle neobjeví. Benchmark měří úlohu. Závislost měří den, kdy služba nejde, model se změní, pravidla účtu se zpřísní nebo nový člen týmu musí vysvětlit starý commit. Kdo hodnotí jen rychlost commitu, může přehlédnout cenu ztraceného porozumění.
17. Tři časy řeknou víc než titulek o náhradě
Praktický test pro tým nemusí být velký. Musí být přesný. Vyberte několik úkolů, které smíte bezpečně měřit. Jeden jednoduchý s dobrými testy. Jeden ve známé části systému. Jeden, kde je důležité review nebo bezpečnostní okraj. U každého běžte variantu bez asistenta a s asistentem, pokud je to organizačně možné. Nehledejte cizí zranitelnosti, nepracujte mimo oprávnění a nedávejte agentovi tajemství, která nepotřebuje.
Měřte tři časy. První: zadání a vytvoření návrhu. Druhý: kontrola, tedy diff, testy, review a opravy. Třetí: uvedení do stavu, za který by vlastník služby podepsal incident. Právě třetí čas odlišuje demo od produkce. Kód, který projde jedním lokálním testem, nemusí být stavem, který tým přijme.
Co je potřeba testovat
U každého úkolu si předem napište, co znamená hotovo. Ne „model odpověděl“. Hotovo znamená: testy prošly, review dává smysl, riziko je pojmenované, rollback existuje a vlastník služby by změnu vzal do svého procesu. Pokud kontrola spolkne úsporu, platí věta „psaní se zkrátilo, odpovědnost ne“. Pokud se zkrátí celý řetězec, máte skutečný přínos.
18. Otázka nezní, zda AI nahradí programátory. Zní, kdo ponese výpadek
Rychlejší HTTP server může být pravda. Víc uzavřených úkolů může být pravda. Zpomalení zkušených lidí ve známém repozitáři může být také pravda. Tyto věty se nevylučují, protože neměří totéž. Jedna mluví o skeletonu a testech. Druhá o firemním toku úkolů. Třetí o kontextu, který model nemá. Čtvrtá, ta provozní, se ptá, kdo ponese důsledek.
Z toho neplyne, že otázka programátorů je klidná. Plyne z toho, že je špatně položená, pokud zní jen „nahradí, nebo nenahradí“. Software se skládá z úloh, testů, review, provozu a odpovědnosti. Některé části se zrychlí. Některé se přesunou. Některé mohou zlevnit. Některé zdraží, protože kontrola bude důležitější než psaní.
Správná otázka tedy nezní, zda AI nahradí programátory. Zní: na kterém úkolu asistent zkracuje psaní, na kterém prodlužuje kontrolu ve známém systému a kdo podepíše výpadek, až zelené testy v noci nestačí. Dokud odpověď končí u benchmarku, chybí jí produkce. A dokud končí u produkce bez měření úkolu, chybí jí důkaz.
Související texty této řady
- Která povolání nahradí AI… — trh práce; tento text je úkol, test a on-call.
- ChatGPT vs. Gemini vs. Claude vs. Grok… — SWE-bench je harness, ne verdikt o povolání.
- Komu dovolíte chybovat