Názory k článku AI asistenti pro vývoj software: nástroje používané pro agentické programování

Když to funguje, je to báječné, když se to zasekne shánějte šamana. Jenom bych doplnil že GitHub Copilot v kombinaci s VS Code super, plugin do JetBrains katastrofa a každou aktualizací se to zhoršuje, asi ta AI co to programuje dělá cílenou sabotáž protože jiné pluginy fungují líp.

JetBrains AI plugin funguje paradne (zcela pochopitelne diky obema firmam). Maji tam i nejaky basic free tier a za me dobry prave diky prime integraci v IDE (ale zatim davam prednost Claude Code).

Já už se bez copilota v postatě nehnu a cítím se spíše specifikátorem. Zajímalo by mě hlavně hostování si nějakého LLM na programování na vlastním železe. Třeba ted ten nový laptop od Dell vypadá zajímavě. I když mě by stačilo to mít ve sklepě a levnější.

ma tvuj notas npu? tak hledej nejaky vhodne velky llm model co se do npu vleze a muzes to mit na notasu.
otazka je pak jak z toho udelat programovaciho agenta spojeneho s ide.

NPU je pro LLM nahouby.

Proč? NPU ani pořádnou grafickou kartu nemám, ale uvažuji o tom. Můžeš, to pls, rozvéct?

NPU, alespoň dnes, má omezené schopnosti. Je to spíš akcelerátor některých AI operací, jako rozpoznání řeči nebo detekci pozadí pro videohovor. na LLM to nepomůže.

Grafika je něco jiného, potřebujete ale takovou která pojme celý model (a podporuje ji soft, což třeba na ollamu je snad jen nvidia).

Na ntb. jen malinké modely (max. v jednotkách bil.) a neinteraktivně (případně ntb. s hodně dobrou externí grafikou, kam se ten model vejde). Na CPU jsou ty odpovědi řádově v min. desítkách sekund, to je na copilota nepoužitelné, ale hrát se s tím dá.

Pre Aider exituje GUI nadstavba a plugin do VSCode/IntelliJ
https://aiderdesk.hotovo.com
https://github.com/hotovo/aider-desk

Kolegov projekt.
V praci mame sessions ohladom AI programovania a sa to slusne vyvija.
Ked clovek vidi ako to funguje na realnych veciach a od niekoho, kto to vie pouzivat, tak je to sila.

Osobne pouzivam ChatGPT(skoro od zaciatku, platenu verziu nieco viacej ako 2 roky) a ten rozdiel v kvalite odkedy som ho zacal pouzivat je velky.
Na zaciatku to bol dobry teoretik/nastroj, ktory vedel vysvetlit,co a ako funguje ale nezvladal velky kontext a vygenerovany kod bol nic-moc. Pre mna to bolo aj tak super, lebo som sa ucil novy jazyk a usetril som kopec casu hladanim informacii na internete/ v dokumentacii.
Aktualne zvlada ovela vecsi kontext, kvalita kodu je slusna. Ako som uz niekde pisal, tak niekde na urovni mediora. Samozrejme jeho kvalita zalezi na objeme a kvalite dat, na ktorych je nauceny. Takze to neplati pre vsetky jazyky.
Pouzivam ho aj na taky projekt, kde vela zdrojov nieje a tam je jeho kvalita rovna tomu, co zvladal 2 roky dozadu u popularneho jazyka.

Mám předplatné Claude Code. Používám v CLI s pluginem v Intellij Idea a občas claude.ai web.

Primárně používám LLM na programování.

Kde se mi LLM osvědčilo a myslím si, že jsem rychlejší než bez LLM:

1. release notes, MCP do Jira, seznam git commitů, které má použít a v promptu jsem vysvětlil jak pozná Jira tiket
Takto mám release notes "k dodělání" za 5 minut, toto by mi zabralo několik hodin a nějaké chyby bych udělal taky - např. zapomenutá méně důležitá změna

2. konfigurace programů, obvykle je to možné jedním způsobem
* konfigurace ADFS serveru s expirovaným certifikátem k testování SP, když jsem chtěl postup jak to naklikat, tak to nešlo moc dobře, ale ve chvíli, kdy jsem chtěl PowerShell příkazy tak to šlo velmi rychle i když windows nepoužívám
* učím se Clojure a chtěl jsem si zkusit Emacs, základní nastavení Emacs podle knížky o Clojure nefungovalo, s LLM opraveno za cca 30 minut

3. konfigurace buildu v Gradle, zejména upgrade na novou verzi , nebo vytvořit plugin e.g. https://github.com/zvrablik/downloadMaven2Repository/tree/development a https://github.com/zvrablik/forbiddenPackages
převod existujícího Gradle Groovy SDK na Gradle Kotlin SDk

4. upgrade knihoven na novou verzi, nastavení, aby vše fungovalo jak v předchozí, popřípadě přepis na nové api

5. experimentování , scénáře co kdyby

6. začít něco k validaci nápadu - zvyšuje ochotu si prostě něco vyzkoušet i když to třeba moc neznám a zasekl bych se na nějaké konfiguraci programu, LLM mi umetá cestičku, Ty dva Gradle pluginy v bodě 3. psal víc Claude než já

7. vytváření dokumentů a vektorové grafiky (SVG) z ručně psaného textu naskenovaného v PDF

Dost zalezi kto to pouziva a naco to pouziva. Ak som programator a robim vyvjam v oblasti kde sa pohybujem, tak je ai fajn - dokazem kod rychlo skontrolovat ak ai vyprodukuje nejaku hlupost viem to rychlo identifikovat a tak isto ho skorigovat nech nevymysla uplne hluposti. A vzdy je dolezity kontext a celkovo llmka pomaha ked modifikuju nieco existujuce co je pekne navrhnute. Akonahle to ma nieco sa mo vymyslat a este aj nieco komplexne tak je to konecna. A tiez je dolezite pouzitie z pohladu casu. Dnes sa tlaci na terminy a cas, a llm pomaha len clovek ma potom tendenciu ked to funguje nechat to tak a kvalita potom pokulhava ale to je celkovo problem pri vyvoji - rychlo nieco splacat a nasadit lebo neni cas.
Pre niekoho kto zacina alebo nikdy neprogramoval, to je take dvojsecne. Moze to pomoct pri zaciatkoch a vyucbe ale treba si uvedomit ze ta kvalita je velmi roznoroda.
Celkom fajn je llm na generovanie konfigov alebo pomocnik na pochopenie nejakej funkcionality (zvlast ked dokumentacia je biedna).

Vo firme máme Copilota, a osobne mi to príde takmer nepoužiteľné.

1. Napísanie promptu a vygenerovanie kódu trvá dlhšie než napísanie kódu človekom (asi najväčšie mínus)
2. "You are absolutely Right!"
3. LLMs sú hyperaktívne, a keď im povieš "urob A" snažia sa urobiť A, B, C, D, a ešte aj E. Chceš aby ti to opravilo jeden unit test? Zmenia implementáciu až polovice projektu, aj totálne nesúvisiacich vecí.

Osobne som dlhodobo skôr z LLM, Agent toolov atď skôr sklamaný. Využitie to určite má, a je to fajn na tasky typu oprav typo chyby v komentároch, nájdi mi v projekte kde sa robí X, či najprimitívnejšie konvertovanie dát z jedného formátu do druhého (napríklad vytvorit Bru file z CURL, i keď to zvláda aj ich samotný nástroj), ale tam to asi tak končí, na serióznu implementáciu akejkoľvek logiky, kreatívne tasky, či dokonca písanie dokumentácie to zlyháva (áno, napíše do krásne 500 riadkov textu do dokumentácie, akurát že polovica z nich je nevalídna a plná nezmyslov).

A to máme ten najvyšší premium a priamu spoluprácu s MS a GH, prístup ku všetkým modelom (Skúšal som ako Opus 4.5, Gemini 3 Pro, GPT-5.1 a mnohé ďalšie, aj verzie špecificky určené na programovanie).

Mně ten Opus od Claude přijde docela dobrej a "držící se tématu". GPT mi dělá to, že ukradne někde nějaký kód (z GitHubu) a cpe mi ho celej, i s tím, co vůbec nepotřebuju. To fakt zdržuje a hodně, protože mnoho času zabere pochopit, co to je a proč to tam je...

My sme začali používať cursor, so Sonet 4.5, tým dám najskôr naštudovať kód, nájsť patterny a uložiť ako dokumentáciu do MD. Potom pred písaním funkčnosti vyrobiť najskôr plán, skorigovať ho, ak treba. Niekedy sa sám opýta doplňujúce otázky. Ak to vyzerá ok, build kódu (stačí aj s rýchlejším modelom composer). Neni to dokonalé, ale dokáže to občas veci také, že mi spadne sánka. Skúšam aj rovno hodiť mu slovenský text zadania s popisom bugu na kód ktorý som videl roky dozadu a nepamätám si ho, on si to preloží, analyzuje kód a občas ma dobre nasmeruje. Minule som sa trápil s gemnini a chatgpt aby mi vyganerovali c++ kód pre win api na screenshotovanie videa, niekoľko pokusov dopadlo zle, nefungovalo to, alebo len so starými kodekmi, sonet mi na prvý pokus spravil perfektný funkčný kód, ja by som to študoval niekoľko dní

Moje mala zkusenost: Claude code dela jen to co mu reknu. Jetbrains AI dela presne tohle co popisujes. Ja mu reknu "udelej tohle" a on mi automaticky prida vsechny if checky i kdyz ja vim, ze nemuze nastat situace kdy to tam neni. Mozna neskenuje na rozdil od Claude celou codebase.

Nejvic mi sedi na psani shell scriptu okolo CI/CD ktere kdyz udela tak chapu co se tam deje, ale nejsem v tom profik tak bych to sam tvoril den kvuli syntax a apod.

Zatím bych to ohodnotil tak, že situace na bojišti se mění každým okamžikem, a to doslova. Cursor byl se svým IDE/mixem modelů před měsícem dobrý, ale nějak se to začalo kazit, dobré modely čím dál pomalejší, ty slabší prostě hloupé, tak jsem si na další měsíc zaplatil čistě jen Claude, a najednou zase AI dává celkem smysluplné a svižné odpovědi.

Těch hype je kolem toho obecně tolik, že to snad ani nejde sledovat. Na vlně je teď nějaký Trae.ai a Z.ai (což je zmíněné GLM) odněkud z Asie a ceny maj na půlce. Jak tohle dopadne, čert ví.

27. 11. 2025, 17:54 editováno autorem komentáře

Má zkušenost s Trae: je to levné, funguje to pro mě osobně tak nějak průměrně, plugin do Visual Studia těžce nic moc, celkově: nezaujalo. Jsou to podle mého Číňani nevím jakého druhu. Kilo Code stále vede. Dobrý byl Augment Code ale s novým ceníkem jsou úplně mimo, podle mého jim došly peníze a nedávají to.

Já bych nechtěl lidi od toho odrazovat, ale co jsem si všiml asi za 1 rok používaní ve firmě je, že hodně lidí to udělá strašně líné a vlastně si chcou celý den psát s chatbotem a nic jiného nedělat. No a z juniorů jsou pořád junioři, protože se z nějakého důvodu nic nenaučí.

Takže já to používám v práci, ale na domácí bastlení si vystačím sám, a baví mě to víc.

Nejhorší je, že to navíc i z průměrných mediorů občas dělá jen dobré juniory. Tady jeden člověk, co občas předtím něco napsal ručně a jakž takž se to dalo teď vyrábí "díky" AI věci, které by u mě neprošly pull requestem ani jen po letmém shlédnutí. Třistařádkové funkce, desítky modulů nasypaných bez ladu a skladu někam do "shared" adresáře, navíc mám podezření, že to celé trvá dost podobně jako kdyby to psal ručně... A to prý za AI utrácí přes 200 USD měsíčně.

Jenže je teď zřejmě línej dělat víc. Nebo tajně dělá ještě pro někoho dalšího...

28. 11. 2025, 19:31 editováno autorem komentáře

Přijde mi, že úspěšnost nejvíc závisí na množství kontextu (potřebného/do­daného) a vazeb na okolní svět. Pokud děláte víceméně izolovanou věc, kterou dokážete velmi dobře vyspecifikovat, i poměrně složitou, často ji to dokáže vysypat na první pokus. Čím více komplexních interakcí s okolním světem, tím je to větší minové pole.

Myslím, že agentic coding by mohl přinést velkou renesanci unixové filosofie, protože prostě s malou a dobře ohraničenou věcí, které má malá a dobře popsaná rozhraní k okolí, si agenti vždy poradí lépe než s velkým molochem, kde je všechno provázané se vším.

Taky je agent tím užitečnější, čím větší je propast mezi složitostí popisu, co daná věc má dělat, a složitostí implementace. Pokud je ta věc jednoduše popsatelná a zároveň spousta práce ji udělat, pak je agent super. Pokud je tam naopak spoustu nuancí, máte velmi specifické a detailní představy o tom, jak má implementace vypadat, atp., často je lepší napsat to ručně. Ale to je koneckonců podobné jako s lidmi. Někdy prostě máte v hlavě tak jasnou a detailní vizi, že je pro vás výrazně rychlejší to prostě napsat než ji vysvětlit kolegovi.

Obecně toto funguje jako dobrá heuristika. Pokud se na agenta díváte jako na inteligentního, obecně znalého, občas až příliš hrr nadšeného brigádníka, který o vašem záměru a projektu neví nic kromě toho, co mu řeknete, myslím, že to často dá dobrou intuici o tom, kdy můžete chtít na něj nějakou práci delegovat a kdy ne.

Příklad dobře definovaného a ohraničeného problému: tady mám nějakou hardwarovou krabičku s nějakým rozhraním. Předhodím agentovi PDF datasheet/doku­mentaci, řeknu udělej věc, co se s tím baví a na druhé straně má MQTT rozhraní s takovými topicy. Typicky na první pokus hotovo.

Díky za cenné informace.

Učím s GenAI programovat PyLadies a podporuji v tom i mé studenty na VOŠ.
Ale vedu je k tomu, aby tomu rozuměli a uměli do toho "sáhnout".

První programy jsem psal v roce 1986 na papír a pak si prošel od BASICu, přes ASM, Pascal, Delphi, Cčko, Javu, PHP, JS, cca od roku 2K používám Python, dnes už na většinu věcí.

Kdyby nepřišly LLM a generativní nástroje (díky Tomáši Mikolove), tak bych si je musel napsat sám, neb některé oblasti, pro které dělám interní core business cloudové aplikace byly z velké části o tom, přehazovat data z jedné hromady na druhou. Vážně jsem uvažoval o nasazení genetických algoritmů na tuhle oblast.

Na něco to tedy funguje dobře. Nejlépe pokud jsou to izolované věci, které moc nezávisí na okolí. Tomu lze jít naproti. Proto si dát záležet a designovat to ještě víc odděleně, než bývalo dobrým zvykem. Bývá to nezřídka na úkor výkonnosti, ale část výkonnostní optimalizace se dá řešit zpětně, po profilování.

Včera jsem zkoušel "promptovat" plugin do Firefoxu, ale tam jsem ani po několika iteracích neuspěl. Až jsem tu stejnou funkčnost vyřešil kódem pro Violentmonkey a tam už to vyšlo na druhou dobrou.

Je mi jasné, že u větších projektů, kdybych neuměl programovat a neuměl to inženýrsky ošéfovat, že by to bylo zoufalství a peklo s tím něco tvořit.

Osobně si myslím, že to časem povede k tomu, že většině kódu nebudou jejich programátoři detailně rozumět, jako dnes nerozumí strojáku ani assembleru ani nekoukají, jak je co implementováno v knihovnách a frameworcích, na kterých jejich aplikace stojí, ale snad to bude vykompenzováno nástroji, které to budou testovat i ověřovat bezpečnostní chyby.

A o to, že by v horizontu 25 let mělo být kvůli GenAI potřeba méně "ajťáků" obavy nemám. Lidstvo toho má ještě hodně co je třeba zdigitalizovat a naprogramovat.

Programuju od zacatku osmdesatych let od strojaku 8080/Z80 (ano, psal jsem to primo v hex kodech) pres basic, assembler, Pascal, C, vsechny mozne scriptovaci jazyky, PHP, Javascript, Python, Lua a kdovi co vsechno dalsi az po C++ pro embeded zarizeni (esp32 a podobne). Jak tady nekdo uz predtim zminoval - AI je proste dalsi krok kupredu. Driv jsme psali v assembleru, pak jsme zacali pouzivat kompilatory a malokdo by dnes uz byl schopen psat v assembleru. Zvlast kdyz treba x86 se vsemi nadstavbami ma desetitisice instrukci a nemyslim si, ze by nekdo znal vsechny. Assembler se zacal komplikovat a byl tezky na pouzivani? Prislo C. Z C se vyvinulo C++ a uz je tak komplikovane a slozite na pouzivani, ze je na case zacit pouzivat neco o stupen vys.

Ted ovsem chci popsat jeden konkretni pripad z minuleho tydne. Potreboval jsem napsat jednoduchy testovaci nastroj, ktery bude po serialce posilat data jako by sly z radaroveho vyskomeru. Potrebuji graficky interface, kde si posuvnikem nastavim pozadovanou vysku a chci, aby ze serialky sly packety s touto vyskou. Napsal jsem Copilotovi presne tohle:
create a http server that provides html page with slider. Moving this slider it should show height from 0 to 600ft and transmit that info to the server. The server should send periodically, one time at 20ms a packet on serial /dev/ttyUSB0 with this height
Copilot se na par sekund zamyslel a vyplaznul priblizne 150 radku kodu v pythonu, ktery delal presne tohle. Udelal web server poslouchajici na portu 8000, obsahoval html stranku ve ktere byl posuvnik a ve strance byl javascript, ktery pri startu a pri zmene pozice posuvniku poslal post na server. Server pri tomto postu updatnul promennou (se semaforem), mezitim co ve druhem threadu periodicky posilal stav teto promenne (cetl ji samozrejme take se semaforem) na serialku.
Tohle fungovalo na prvni drc. Pridal jsem tam jenom echo na stdout, abych videl, co se tam posila. Samozrejme neposila to packet ve spravnem formatu, format jsem munespecifikoval, takze posila jenom cislo. Ale mam na cem stavet. Doplnim dalsich par radku na vytvoreni spravneho packetu a je to hotovo. Tohle kdybych psal od nuly, by mi trvalo pul dne, nez bych do doladil.

Není asembler také kompilátor? Makra, pojmenované bloky paměti, symbolická jména instrukcí...I CZ počítač SAPI měl něco takového.