"Softwarovým inženýrům jsem zakázali psát kód. Některé jsme dokonce museli propustit, protože nebyli schopní na tento způsob práce naskočit."
To musí být docela legrace - kolik extra tokenů se propálí jenom tím, že se místo ručního zásahu musí znovu a znovu generovat kód? Tak hlavně že můžou navenek vykázat, jak jsou pokrokoví.
"S každou revolucí se povolání mění. Nabíráme ty, kteří jsou ochotní se rozvíjet,"
jj, mohli by ve vedení začít stejně: Manažerům jsme zakázali samostatně rozhodovat, některé z nich jsme museli vyhodit, protože nebyli schopni plnit rozhodnutí připravená AI :)
Já programuju za účasti v Claude. A když vidím jak halucinuje, dokáže nekontrolovaně měnit logiku kódu a pak to jen slepě dolepovat, aby to splňovalo složitější zadání bez optimalizace předešlého.. paradoxně složitější věci vyřeší lusknutím prstu a jednoduché až triviální věci je schopen se točit hodiny a hodiny bez výsledku nebo s naprosto hloupým výsledkem. Je mnohem efektivnější to udělat ručně. Já už z počátečního nadšení rychle vystřízlivěl, zvláště pokud se jedná o kritické nonstop provozy. Už vidím jak na místě u zákazníka řeší optimalizaci a chyby AI. Také si všímám, že to co není zdokumentováno (novinky), AI vůbec neví co s tím radí naprosté hlouposti a někdy až fatální.
Nicméně z takových článků mám radost. Na takovém přístupu dojedou. U nás to bylo podobně. Vyhdíme ty co nebudou používat AI, nahradíme juniory. Junioři jsou nadšení, že za ně píše Claude.. jenže teď ty junioři dojíždí na to, že absolutně nechápou souvislosti, tomu co píšou vůbec nerozumí, ztrácí schopnost kritického myšlení, ztrácí schopnost základních programátorských dovedností, nedokáží nic ručně opravit, nedokáží rychle analyzovat příčinu chyby, místo minutové rychlé opravy mlátí tisíce tokenů a kód zasekávájí zbytečným balastem. Inu, budoucnost IT.
30. 9. 2026, 17:45 editováno autorem komentáře
Vždycky mi přijde zajímavé, jak se všichni na těch větvích, co si podřezávají, hezky vrtí a hledají důvody, proč je to podřezávání tak účinné a jakou přinese skvělou budoucnost.
Tady se typicky dočteme vícero omylů a protimluvů najednou:
1. To, že vycházejí lépe metriky, tzn. že delivery týmu je rychlejší, neznamená, že jsou lidi v týmu spokojení, že dodaná práce je future-proof, že jsou dodávané změny robustní atd. Ne, rychlejší != lepší. Metriky nemetriky.
2. Je super, že si firma staví svůj interní ekosystém kolem Claude AI. Stejně jako jiné kolem Copilota nebo Codexu atd. Ještě víc super bude sledovat, jak se taková firma zachová, až dojde v výpadku dotyčného vendora: ať už z politických, ekonomických nebo jiných důvodů.
3. Když si někdo 'chce zároveň' nechat v týmu lidi, kteří rozumí podvozku, pak asi nemůže používat po delší čas AI-heavy workflow. Jednak proto, že si takové lidi nevychová, jednak proto, že to ty stávající může přestat jednoduše bavit (celý den psát prompty začíná být fakt nuda stejně jako bývá programátorům odporný byznys a produktové tahanice), jednak třeba proto, že při neustálé delegaci práce na AI i velmi zkušený senior začne po pár měsících ztrácet přehled (protože znalosti netrénuje, navíc mu přibývají hory kódu).
4. Tenhle způsob práce je po čase pro mentální zdraví naprosto devastační: místo dvou tří tasků s hlubokým fokusem najednou děláte klidně 10+ tasků najednou, protože flotila agentů krásně jede, ale vsaďme se, že daň si to vybere.
Ono jim to časem dojde až bude nějakej akutní průšvih a bude to muset řešit někdo kdo reálně ví jak to funguje.
Obávám se, že dělají chybu.
Ten kód totiž musí někdo po LLM zkontrolovat a integrovat - což nebývá zrovna juniorní programátor, ale (v lepším případě) zkušený inženýr. Jenže než se na to inženýrské místo dopracoval, pravděpodobně sám generoval kód - a tím sbíral zkušenosti, ale především se hodně, hodně naučil o tom, jak celý ten cirkus funguje.
Jednoho dne tito zkušení borci odejdou: dílem do důchodu, dílem na jiná místa... Bude potřeba je nahradit jiným zkušeným inženýrem - a takový nebude existovat, protože ty zkušenosti sbíral LLM.
Už to tady zaznělo, ale je podle mě potřeba to opakovat: programování je tvůrčí proces a každý programátor zná ten pocit, když se podaří naprogramovat něco parádního, odhalit bug po desítkách minut beznadějného bloudění nebo když si to všechno dohromady sedne a dal by za to člověk ruku do ohně…
To úplně s LLM zmizelo. Ta radost je pryč. Sám to na sobě cítím a nejen absenci radosti, ale i to, že vlastně nevím, co a jak a proč funguje… a je jedno jak dobře mám vyladěné skilly, kupodivu u mě Claude nehalucinuje, málokdy se zacyklí a kód není k zahození.
Ale co bude dál?
Produkťák mi zadání dodá od Claude, já zadání předám Claudovi, kolega mi review “udělá” pomocí Clauda… a v celém tom flow je nakrásno vidět, že nikdo nic neví, když se člověk zeptá na nějakou hlubší otázku o kódu, zadání či zákazníkových potřebách…
Nevyhýbám se pokroku, to bych jinak bastlil PHP 5… ale cítím vnitřní odpor a úzkost z toho, co teď “tvořím”.
Pracuji ve firmě, kde je cca 100 programátorů. AI využíváme ke kódování velmi aktivně, ale reálně se objevuje problém, kdy někteří programátoři do AI vkládají až příliš velkou důvěru a polevují v review. Ono totiž dbát na kvalitu kódu je mnohem těžší, když ten kód člověk nenapíše sám a časem se začne projevovat určité zpohodlnění, což se může týkat i seniorů. Tenhle hon za vyšší efektivitou pak vede ke kódu, který funguje a na první pohled vypadá hezky. Jenže když nad review a následným laděním nestrávím snad skoro tolik času, jako kdybych si to psal sám, tak tam AI bez vedení za ručičku nabouchá tunu neefektivity.
Například dynamické čtení konfigurace za běhu (kdy absence či špatná konfigurace způsobí pád až za běhu a ne hned při nasazování), používání regexů všude (i tam, kde to nedává smysl a stačila by jednoduchá for smyčka), kompilace regexů v každém běhu metody (i když by šla zkompilovat do statické konstanty) nebo neefektivní práce s cache (což dobu response protáhlo z desítek ms na vteřiny). A to je jenom pár příkladů. Naštěstí nám nikdo nezakazuje sahat na kód ručně. Spíše se teď bude řešit, abychom kód od AI řešili mnohem víc. Vždycky si při čtení těchhle článků říkám, jestli nedělám něco špatně já, nebo se ty firmy jen snaží nasadit falešnou fasádu. A mám pocit, že je to ta druhá varianta, protože z doslechu to v těch supr Čupr firmách není s AI taková sláva, jak to ze článků vypadá.
Mám takovou vlastní php třídu pro mysql builder - prostě někdy potřebuji pracovat daty skrze php, jednoduchá a učinná.
Claude ohodnotil třídu 8/10 z hlediska architektury a 6/10 z hlediska kvality (je to osobní třída, takže klasika).
Teď jsem řešil menší sql injection u funkce update, kdy hodnota pro update může být aritmetická operace s původní hodnotou (tady bylo sql injection) nebo string.
Claude příšel s nápadem přidat 5 funkcii - pro každou aritmetickou operaci a používat ji mimo funkci update (obsahujicí array). Takže defakto rozkopal smysl celé třidy - jednoduchost.
Nakonec jsem to vyřešil s třemi podmínkami a se suffixem v hodnotě pro funkci update.
Takže hodně štěští všem, kdo pojede skrze AI v programování. Optimalizaci a rozvoj to opravdu neumí..
Btw Po menších úpravách jsem dostal 7,5/10.
30. 9. 2026, 17:30 editováno autorem komentáře
Není to pravda. Připraví podle pokynů celkem rychle poměrně kvalitní kód. Ale (svůj) zapomenutý return uvnitř smyčky vyhodnocující příchozí stream, který způsoboval timeout kvůli zahazování části validních dat, najít nedokázala. Já to měl ručně za 10 minut. Je to jako každý nástroj. Na něco je dobrý, na něco ne. Vždycky je ale potřeba ruka mistra, který ví, který nástroj v kterou chvíli použít a kdy je lepší některé detaily udělat ručně, protože má nadhled. AI/LLM nadhled nemá - má nacvičené sekvence tokenů.
A pak je tu další problém a to je čím dál běžnější přetížení modelů, kvůli kterému mají ne úplně použitelnou odezvu.
Nezlobte se na mě, článek je ale absolutně o ničem.
Osobně už kod skoro taky nepíšu, jestli mě to chybí? Ani ne, osobně mám přesah do byznysu a vždy sem se snažil mít i když žádné AI nebylo. Programátor který nechápe pro koho produkt dělá, je špatný minimálně zaměstnanec. Nutit ale lidi nepsat kod, asi jen abych na lupě vypadal jako cool firma, je dobrá blbost. Jde snad o produktivitu a spolehlivost ne? Když dokážu řádek kodu napsat rychleji a lépe než AI, proč bych to měl křečovitě delegovat na AI? Když něco refaktoruju a dokážu to udělat rychleji pomocí IDE, stejnej případ. Těch případů je mraky, stejně jako případů kdy opravdu nemá smysl kod psát. Tímhle si akorát vychováte lidi co budou při každém zeptání se AI mačkat y, nebo ještě hůře budou AI pouštět s --permission-mode bypassPermissions a už nebudou řídit nic. Osobně bych spíš volil přístup pár dní v měsíci AI nepoužívat vůbec, aby člověk musel hezky po staru si projekt projít a dělat chvili ručně. Benefit to bude mít ten, že pak bude projekt minimálně lépe znát.
Nešlo by teda říct AI, ať to rovnou píše maximálně zoptimalizovaný ve strojáku? Když už je tam ten lidskej prvek zbytečnej, vyhoďme ten "human-readable" balast a ať z toho rovnou lítaj exáče, ne? :-D Vynechá se tím hafec neoptimálních zpomalujících vrstev, stejně to nikdo nebude číst, tak je zbytečný to psát v lidsky pochopitelným tvaru... ;-)
1. 10. 2026, 15:56 editováno autorem komentáře
to je přirozený vývoj, nelze dnes dělat review kódu od AI, ne v tom množství. Nedokážeme udržet tolik pozornosti. To se dá dělat v nějakém počátku adopce, ale rychle příjdeš na to, že i těm nejlepším prostě ujíždí vlak a AI je zahltí.
Změnit musíme způsob vývoje. A která cesta je nejlepší, to je otázka.
Já teď v týmu zkouším variantu, kdy na tickety dávám pořád stejně času, ikdyž s AI to trvá desetinu a zbylý čas je volně k dispozici právě na refaktor, vylepšení kódu (hlavně jeho minimalizaci), promyšlení zadání, odzkoušení a troch popřemýšlení. Můj cíl je snížit počet bugů a zjednodušit proces předání změn dál v procesu.
Při vývoji mě nestojí kód tolik peněz, stojí mě peníze zbytečná práce programátorů, opakované vracení k hotovým věcem (opravy), malé sebevzdělávání, protože na vše je málo času. U klientů vidím, že ty firmy zdesetinásobili práci programátorům (AI + víc ticketů + méně lidí), nevím, jak v tomhle chtějí za rok fungovat.
Na toto jsem přišel, když jely fóra - dělal jsem tam obsah, majitel na tom časem začal vydělávat a tvůrci obsahu nedostali ani korunu.
Realne nikdo nebude ale vedet jak veci funguji:-) a bude se muset resit rez do ziveho od nekoho kdo veci delaval rucne. A i pak bude pouzivat AI na silene pracne subtasky.
Z druhe strany bez expertu kteri umi vybrat ten spravny model na analyzu nebudete vedet jestli reportovany problem neni halucinace ktery na tom prida dalsi a dalsi urovne komplexity.
Možná to bude překvapení, ale AI zvládne nejen srozumitelně vysvětlit jak co funguje, ale také opravit ten průšvih.
Jo proč mít radost že ai našla bug, zrychlila kod. Jistě z pohledu vývojáře z toho radost mám, aplikace je lepší, vnitřní geek ale u toho umírá. Je třeba si proto hledat jiné radosti..
Tuze me zajima, zda podobne debaty probihaly treba i v dobe, kdy konske povozy byly nahrazovany auty. Predtavuji si to asi takto:
Vozkove rezete si pod sebou vetev, myslete na stolby, podkoni a kovare! Auta jsou plne horlave tekutiny a vubec jsou hrozne nebezpecne. A stejne potrebuji zpevnenou cestu, takze kone FTW.
Nebo kdyz automaticke ustredny nahrazovaly manualni, kde holky prepojovaly hovory pomoci bananku a dalo se s nimi prohodit par milych slov. Nebo se spletly a clovek mel tak moznost seznamit se s nahodnou osobou. Mohlo z toho vzniknout pratelstvi na cely zivot! Celkove ze z toho ztatil lidsky faktor.
O parnich strojich ani nemluve. Hlucne to je, smrdi to, vere to lidem praci- no celkove bych to zakazal, vsechny ty stroje. Kdo tomu fandi, ten podrezava a mel by se nad sebou zamyslet ;-)
nedávat tomu testy je dobrý nápad. Jinak když nám to projde několika kolečky AI code review (claude, codex), tak to už je v podstatě bez chyb a přijde mi, že mi lépe pokryté edge cases než bych to zvládnul sám. Ale někdy je to až zbytečně opatrné přijde mi. Ke klasickému programování se prostě už není možné vrátit, ten přínos je moc velký - za půlden zvládnu tolik práce (kódu), kolik bych dělal za týden. Nicméně jak už tu psali i ostatní, je těžké mít z aktuálního pracovního procesu radost.
AI tady už zůstane. Je jen otázkou v jaké podobě a jestli ta datacentra jsou a budou ekonomicky dlouhodobě udržitelná. Ono je fajn vyházet milióny lidí a těšit se jak budu vydělávat bez nich, jenže ty milióny lidí znamená ztrátu významné kupní síly.
Dost se to srovnává s průmyslovou revolucí, jenže ta trvala desetiletí, tady se bavíme o měsících a trh práce na to připraven rozhodně není.
Jo, code review je problém. Já to zatím zkouším vyřešit poloautomaticky - udělal jsem si skill na asistenci s code review, takže to se mnou postupně projde tickety na review, vypíchne core změny (a kde je najít), upozorní mě na možné implikace a já už pak projdu zběžně jen ty důležité věci. A můžu to rovnou pak nechat udělat komentáře, poslat zpět, rozjet lokálně a nebo schválit. Ale za měsíc to budu třeba dělat úplně jinak.
nám zatím nic nefunguje :).
Zásadní problém je, že jak moc review AI se spoléhá na komentáře a názvy funkcí/testů aniž by se podívala do kódu. Je schopná si v komentáři přečíst "otestování, funguje bez chyby!" a říct, že funkce je ok, protože je otestovaná, přitom v těle jsou abnormální boty.
Dneska jedeme strategii, že AI dostává k review kód bez testů, bez komentářů, poupze se zadáním a možnosti si spustit integrační testy. Výsledek je mnohem lepší, ale pořád bojujeme s kvalitou kódu a počtem bugů, udržet architekturu a jednotlivé oddělené vrstvy je velmi těžké. Kvůli lidem jsme postupně zavedli mono repa, teď kvůli AI zase děláme repa pro jednotlivé funkce a jasný veřejný interface/kontrakt a k tomu integrační kódy, které nedělají implementaci. Říkám, musí se to změnit :).
Na review se mi osvedcilo pouziti vice modelu (hlavne ne ten ktery kod vytvarel:-) )a u kazdeho projektu info pro agenty jak ma vypadat struktura - coz pomuze i programatorum. Problem tedy co jsem zatim zazil ve vyvoji je ten, ze kazdy projekt je jiny a jedna metodika nemusi vyhovovat treba ani na velmi podobnem projektu.
Nejsem programator takze to mozna delam blbe/neefektivne ale zatim se mi to osvedcilo. z
Spis vyplouvaji na povrch vice kompetencni problemy a rozdeleni odpovednosti.
Podle mě AI bublina hned tak nepraskne, bude proti tomu zatracepeně velká tlačenka. Jako taky bych si nesmírně přál, aby to byla vesmírná prda, ale to se momentálně nestane, ty červy do té plechovky už nijak nedostaneme. Ani to nejde dost dobře zakázat, kdo to udělá, prohraje.
> Ještě víc super bude sledovat, jak se taková firma zachová, až dojde v výpadku dotyčného vendora: ať už z politických, ekonomických nebo jiných důvodů.
Nastaví ve svých Claude proměnnou prostředí ANTHROPIC_BASE_URL někam jinam a budou pokračovat? V nejhorším s nějakým self-hosted Kimi/GLM/Deepseekem?
Přijde mi to jako výrazně menší problém, než mít v Googlu/MS/Amazonu veškeré emaily, zdrojáky (github), soubory (drive), deployunté aplikace (cloud).
Hlavne teda kdyz halucinuje muzu ji jednoduse rozepsat test pipelinu a ona uz mi vyrobi specificke kontejnery s konfiguracemi nebo kodem a otestuje je. To vnimam jako benefit. Chapu ze model obcas nevi jak se treba dany sw presne chova i kdyz je OSS, ale moznost si rychle rozjet testy ktere hodi nejake exaktni na modelu nezavisle vysledky je skutecne vzrust produktivity pri reseni jobovek.