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