Názory k článku Vývojáři už v Česku kód nepíšou. Místo toho kočírují smečky AI agentů
-
V mém týmu mega nadšení a nadšení šéfů, jak se zbaví mnoha vývojářů, debilní kecy, jak Claude nahradí 90 % vývojářů. Tak jsem si tu příšeru nainstaloval, po pár týdnech používání - tak na základy asi OK, apka funguje (občas), všude skryté chyby. Kvalita kódu sodoma-gomora, zbytečně složitá řešení, optimalizace rychlosti Claude také nic neříká, i když instrukce byly jasné. Laděním a čištěním kódu strávím víc času, než kdybych si to napsal sám. Nejvíc mě dostává, že ti samí lidé, co šikanovali při code review a zaklínali se design pattern, teď pouští hromadu špatného kódu od Claude.
-
Kód, který za mě napsala AI a já mu dal jen zelenou na review, nikdy nebude kód, kterému budu do hloubky rozumět. A vzhledem k tomu, co občas dokáže AI vyplodit a jaké chyby jsem už za 10 let v praxi řešil, si myslím, že nějaký dohled druhým agentem není dostatečný. Už teď slýchávám historky do CEO poblázněných do AI, kteří tlačí na vývojáře a pak narážejí na realitu, kdy jejich AI prototyp vážně není možné jen tak hodit za pár dní do produkce. Mám pocit, že tyhle startupy jedou podobnou linku, ale na rozdíl od velkých firem nemají dostatek zkušených vývojářů ochotných umírnit své CEO v očekáváních.
Celé mi to připomíná pár let staré pobláznění mikroarchitekturou. Snad na každém pohovoru chtěli znát moji zkušenost s mikroarchitekturou. Mnoho inzerátů bylo na projekty, které se přepisovaly na mikroarchitekturu. Ono to pak i nějak fungovalo, ale bylo zajímavé slýchávat, že potenciální výhody celkem často vyměnily nové problémy - týkající se synchronizace dat mezi moduly. Ukázalo se, že mikroarchitektura není všelék a implementovaná bez rozmyslu nemusí nutně přinést výhody "zadarmo".
A to se děje i teď s AI kódem. AI kód je trochu jako droga. Napíšete co chcete a relativně rychle máte prakticky "zadarmo" výsledek, který by vám jinak trval několikanásobně déle vytvořit. Najednou toho chcete generovat víc a víc a kontrolovat ručně méně a méně. Ale výsledek skoro zadarmo je jenom nebezpečná iluze. 90 % procent výsledku zvládnete opravdu rychle, ale na vyladění těch 10 % klidně propálíte nesmyslně mnoho tokenů. Navíc čím víc kódu generujete, tím větší technologický dluh si vytváříte - ať už co se týká bugů, neoptimálního fungování, budoucího refaktoringu nebo integrace s jiným kódem. Zvlášť pokud už nikdo ten kód nezná do hloubky. Sázet na to, že přece i ten dluh zvládnou hravě AI agenti je gambling, protože právě v tom dluhu jsou nejtužší bugy a problémy. Boiler plate kód na zelené louce je oproti tomu úplně jiná liga.
-
Je to úplný nesmysl. Senior není jen o tom, že vyprodukuje složitější výstup (a řekněme za relativně kratší čas než by to dělal junior). Je to především i o tom, že má přehled, dokáže domyslet důsledky a rozumí tomu, co vytvořil a proč to vytvořil tak a ne jinak. K takovým znalostem junior patlající "seniorní" výstupy s pomocí AI sotva kdy dospěje.
-
"co dnes považujeme za mediora až seniora, bude pro juniory nový entry level" - Co přesně tím chtěl autor říct? Že juniorům dáme seniorní práci a budeme po nich požadovat odpovědnost za její odevzdání? Nebo naopak že po nově nastupujících "juniorech" budeme požadovat už v prvním zaměstnání senioritu? A jak ji mají získat, když už se nebude nikde programovat, a to ani po nástupu do práce? Takže jediná expozice kódem bude na škole? A nebudeme si potom stěžovat, že by školy měly učit spíše práci a agenty?
Nebo už to teda nějak doklepem na existujících seniorech až do nástupu AGI a junior už nebude nikdy potřeba? The lost art of programming?
-
Jako nevím, ale používám to jen na prototypování. Na nadhazování různých řešení to není špatné, ale jinak všechny neuronky produkují minimálně 30% problematického obsahu - klidně řeknu odpad i když "funkční". Skoro celé to je nutné následně přepsat - navíc ten čas dohadování se s LLM co je třeba ...
To do produkce může nasazovat jedině totální blázen. Spíš se pohybuju na té nejnižší úrovni, trénování a provozování modelů na vlastním železe. Jen opravdu malé neuronové sítě mohou poskytovat extrémně validní výsledky. Ty velké modely si kolikrát nejsou ani jisté jestli si načíst nějaký tool a je to sázka do loterie.Možná pokud se nebudou používat transformery, ale LLM difuze třeba to bude lepší???
Domnívám se, že ti lidé co to používají vůbec nechápou jak to funguje a stačí jim "něco", protože kdyby ano tak jim bude jasné, že to má limity, které asi nepůjde ani vyřešit.
Manažerům stačí jakékoliv demo aby trpěli přes svůj minimální intelekt FOMO efektem. Jako ta paní co si smazala počítač (fakt jí to překvapilo?).O užitečnosti neuronových sítí nikdo nepochybuje... ale
Pokud nejste schopní výsledek přesně ověřovat je to cesta do pekla. -
Jako programátor, kterému hodně záleží na kvalitě kódu mám teď docela problém, protože kolegové s pomocí AI odbouchávají ticketu rychleji, než je stačím projít a posoudit. Já toho s pomocí codexu taky zvládnu víc udělat, ale s tím dělat rychleji a stejně kvalitně review mi to zatím moc nepomohlo. I když jsem si udělal skill, který jsem postavil na svých komentářích u PR za poslední dva roky a dotáhne si automaticky informace z trella a githubu. Asi budu muset trochu rozvolnit dvé standardy a nebo zkoušet dál.
Každopádně se zdá, že to review je momentálně bottleneck. -
Super článek. Je zajímavé, že jsem na podobně kvalitní text v anglicky psaných zdrojích zatím nenarazil. Jediné, co bych mu (prosím ne doslova) vytkl, je rozsah a míra detailu – snesl by výrazně větší objem a hloubku.
Například na definování pravidel pro agenta jsem strávil několik set hodin (znám ukázková pravidla na GitHubu), a přesto s agenty narážím na problémy. Např.: mám explicitně a logicky popsaná pravidla, připravené podrobné zadání včetně příkladů a testovacích dat – a přesto je agent klidně hned v prvním kole poruší a začne si věci upravovat po svém, navíc chybně.
Nejprve mu popíšu chyby ve výstupu. Následně začne tvrdit, že problém je na mé straně, provede několik nesmyslných kontrol a tím vytvoří další chybu. Protože mě nebaví domýšlet, jak k ní došlo, podívám se do kódu – a obvykle poměrně rychle najdu logickou chybu i nedodržení podstatné části zadání. Typicky jde o požadavky, které na první pohled nepůsobí logicky – a právě ty ho nejčastěji rozhodí.
Jakmile chybu opravím a zadám další kroky, první, co agent udělá, je, že moje opravy smaže a vrátí tam své původní chyby. V takové chvíli mu důrazně připomenu, že se má nejdříve zeptat, než něco přepíše. Následně se začne ptát na každou drobnost – jako nový zaměstnanec.
V tomto konkrétním případě jsem používal model Sonnet 4.5 či 4.6. Přepnul jsem tedy na GPT-5.3 Codex, který úlohu dokončil (což ale nutně neznamená, že je obecně lepší).
Cursor mě neoslovil.
Často se podaří vygenerovat funkční kód na první či druhý pokus, ale stále mě překvapuje, jak někdy selže i u relativně jednoduchých věcí.
Mimochodem – podobně hluboké články jsem na anglicky psaných technologických webech hledal poměrně obtížně. Tento text mi ale pomohl si téma lépe zmapovat a díky němu jsem nakonec několik souvisejících zdrojů dohledal. -
by mě zajímalo, kdy si ti "vývojáři" všimnou, že takhle to prostě nemůže fungovat. Množství kódu, které takhle vznikne není spravovatelné ani těmi AI. S kódem přichází také odpovědnost, teda hlavně nějaká režije na jeho opravy, údržbu, stabilitu.
Je to v podstatě asi pár měsíců, kdy se takhle začalo masivně vyvíjet i u nás. Za těch pár měsíců se tady objevují už firmy, které mají miliony nových řádků kódu a přestává jim na to stačit předplatné. Nakupují tokeny a pomalu se náklady dostávají dost vysoko. To je přitom jen pár měsíců.
Tenhle způsob vývoje mi připadá, že je spíše anomálie a zase se to celé ještě převrátí. Tvořit jednorázové rozsáhlé aplikace je velmi drahé a zatím to je spíše taková hračka, ikdyž spoustu lidí na venek hraje hru, že to je profi a má to pod kontrolou. Je zajímavé vidět ten kontrast některých společností, které tady článek cituje a jaké vlastně reálně s tím mají komplikace a problémy :).
ČLÁNKY DO MAILU