Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: xyz 28. 03. 2026, 13:24:01
-
Ahoj,
pisete jeste dnes nekdo kod rucne? Nebo uz to nechavate na LLM? Jak se vyrovnavate s "junioritou" LLM? (zabugovany, nebezpecny, neefektivni kod, neznalost standardnich frameworku, spousta boilerplate kodu)? Mate zmerene zvyseni produktivity pri stejne kvalite? (tvrda data) Co spokojenost? (misto uspokojeni s kvalitne napsaneho kodu -> rizeni LLM nebo agentu).
Diky.
-
zatim si nechavam naseptavat a obcas se zeptam na nejakou funkcionalitu, kterou nechci sam analyzovat.
ale zkusil jsem zadat jednoduchy task agentovi a vyresil to spravne, planuju zkusit agenta na pristi vetsi implementaci co se chysta, ze to agent cele napise a ja to upravim.
-
Hodně otázek. Kód už pár měsíců ručně prakticky nepíši. Je ho ale vždy potřeba kompletně celý důkladně přečíst, odstranit nebo nechat refaktorovat všechny problémy a zkrotit obvyklou ukecanost a častý overengineering. Složitější úlohy je navíc třeba správně rozdělit do podúkolů. A základní zásada je chápat, co se kde přesně děje. Každou část a všechna rozhodnutí si musím být schopen před kýmkoliv bez dalšího obhájit. Spokojený jsem hlavně tehdy, pokud vše funguje tak jak má. Sice mě pak netěší ručně napsaný kód ale zase to na druhou stranu šetří spoustu otravné dřiny což je fajn.
Je také třeba říci, že postup je vždy více či méně výrazně iterativní, kdy celkovou kvalitu postupně v několika fázích zlepšuji do stavu, kdy je vše použitelné jak z hlediska požadované funkčnosti, tak patterns obvyklých na projektu i z hlediska kvality a spravovatelnosti výsledku. Což trvá možná 80 % času a dnešní LLM samy o sobě to jednoduše dostatečně spolehlivě rozhodně nedělají. (Což všichni ti speakeři a influenceři z LinkedInu, co ještě včera neveděli, co je proměnná a dnes o tom píší oslavné články úplně ignorují protože o tom reálně nemají ani páru.)
-
Hodně otázek. Kód už pár měsíců ručně prakticky nepíši. Je ho ale vždy potřeba kompletně celý důkladně přečíst, odstranit nebo nechat refaktorovat všechny problémy a zkrotit obvyklou ukecanost a častý overengineering. Složitější úlohy je navíc třeba správně rozdělit do podúkolů. A základní zásada je chápat, co se kde přesně děje. Každou část a všechna rozhodnutí si musím být schopen před kýmkoliv bez dalšího obhájit. Spokojený jsem hlavně tehdy, pokud vše funguje tak jak má. Sice mě pak netěší ručně napsaný kód ale zase to na druhou stranu šetří spoustu otravné dřiny což je fajn.
Je také třeba říci, že postup je vždy více či méně výrazně iterativní, kdy celkovou kvalitu postupně v několika fázích zlepšuji do stavu, kdy je vše použitelné jak z hlediska požadované funkčnosti, tak patterns obvyklých na projektu i z hlediska kvality a spravovatelnosti výsledku. Což trvá možná 80 % času a dnešní LLM samy o sobě to jednoduše dostatečně spolehlivě rozhodně nedělají. (Což všichni ti speakeři a influenceři z LinkedInu, co ještě včera neveděli, co je proměnná a dnes o tom píší oslavné články úplně ignorují protože o tom reálně nemají ani páru.)
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
-
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
Zvláštní otázka. Jazyk samozřejmě češtinu. Jaký význam mají frameworky v době LLM, který ušije aplikaci na míru?
-
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
Zvláštní otázka. Jazyk samozřejmě češtinu. Jaký význam mají frameworky v době LLM, který ušije aplikaci na míru?
clovek si vybere nejaky jazyk a pripadne framework a pak se ai pta, aby kod byl v jeho oblasti. nebo nechas ai samu rozhodnout i o jazyku?
-
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
Zvláštní otázka. Jazyk samozřejmě češtinu. Jaký význam mají frameworky v době LLM, který ušije aplikaci na míru?
Jaký význam mají frameworky v době peogramátorů, kteří ušijí aplikaci na míru?
-
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
TypeScript, React. Technologicky nic zázračného. Což je samozřejmě výhoda. Zásadní je ale stejně kvalita okolní codebase. Modus operandi LLM je opakovat patterns. Máte-li codebase ve špatném stavu, třeba Claude Code to začne celkem bez váhání přebírat. Stejně tak pochopitelně přebírá to správné. A čím větší ta existující codebase je, tím lépe, tím spíš se bude mít podle čeho řídit.
clovek si vybere nejaky jazyk a pripadne framework a pak se ai pta, aby kod byl v jeho oblasti. nebo nechas ai samu rozhodnout i o jazyku?
Jak jsem psal, základ je přesně vědět, co se kde děje a proč a základ je vědět co je dobře a špatně v rámci daného jazyka a platformy protože ty LLM to dokonale prostě fakt nevygenerují. Ale k tomu, abyste věděl jak to má být správně musíte tu technologii pochopitelně ovládat. Jinak je to jen eskalovaný diletantismus.
Jaký význam mají frameworky v době peogramátorů, kteří ušijí aplikaci na míru?
Mají smysl pro lidi a pro spravovatelnost. AI to neudělá na míru. To tvrdí jen LinkedInoví plácalové. (Pozdravujeme pana Ludwiga a další.)
-
N/A
-
LLM používam na hobby veci pre seba, kde mi nevadí AI slop. Rád mám na tom, že keď poviem - toto je pomalé, sprav to rýchlejše. Tak povie "nech sa páči". A ono je to fakt rýchlejšie. Ani nemusím explicitne povedať, ako to má zrýchliť.
-
Postupně používám víc a víc. Je to nástroj, co může hodně pomoct, ale taky spálit hromadu času a práce. Základ je:
- Není to magie, platí, že kvalita vstupu odpovídá kvalitě výstupu. Když budu nejdřív půl hodiny přemýšlet, pak hodinu strávím chystáním implementačního plánu a požadavků, jako bych to chystal pro juniora, ve spolupráci s tou LLM, tak to potom za deset minut často udělá to, co by mě trvalo tři hodiny. A i pokud ne, tak mám aspoň užitečný plán pro sebe, protože během toho plánování si všimnu spousty speciálních případů, nejednozačností, a tak dál. Ale pokud tomu dám z prstu vycucané zadání na půl odstavce, tak to nejspíš bude odpad, ty tři hodiny strávím snahou se k něčemu dostat, a pak to stejně budu muset udělat od nuly.
- Dokumentace, dokumentace, dokumentace. Pokud to nemá dost ukazatelů a popsanou strukturu, tak si to nebude nic pamatovat, propálí hromadu tokenů na čtení existujícho kódu, a pak to stejně udělá blbě. Protože tomu bude chybět klíčová informace, co není z kódu očividná (například "k čemu ten program reálně je používaný"), nebo něco půlce práce vypadlo z kontextového okna. Naštěstí ty LLM si tu dokumentaci umí připravit - když jim to člověk řekne.
- Obrovsky záleží na tom, co za klienta používáš, a na cokoliv složitějšího, než izolovaných pár řádků, je potřeba lokální agent, ne webový chat. Stejný model, stejné zadání, ale ty řídící prompty (které nevidíš), nástroje, které ten agent má k dispozici, ... To udělá fakt velký rozdíl. A agenti na míru konkrétnímu providerovi (Google Antigravity, OpenAI Codex, ...) z mojí zkušenosti udělají lepší práci (nebo aspoň snáz to dokopeš k užitečné úrovni), než obecní agenti typu KiloCode. Nepřizpůsobíš si je tak na míru, ale to na začátku ani dělat nechceš.
* Agent = stručně řečno, klient na steroidech, který ten model diriguje do zjisti-přemýšlej-vykonej-znovu smyčky a dává tomu nástroje.
-
Ale pokud tomu dám z prstu vycucané zadání na půl odstavce, tak to nejspíš bude odpad,
To není nutně pravda. Já osobně jsem prakticky nenapsal prompt delší než pět vět. Jenomže pak je třeba postupovat iterativně. Nelze samozřejmě očekávat, že od takového promptu dostanete hotové řešení a hlavně to nelze chtít. Ostatně kdybyste to psal sám, taky byste postupoval iterativně v postupných krocích. Psát gigantická zadání a pak doufat, že se to celé v jednom kroku nějak vyrobí považuju za docela solidní antipattern nevedoucí ve výsledku moc nikam, vytvářející obrovský prostor pro chyby a dezinterpretaci a častou chybu obecně. Nemluvě o tom, že ty modely pořád jsou hlavně konverzační a je to na nich vidět. Mnohem efektivnější mi přijde přistupovat k LLM AI jako ke kolegovi při párovém programování než jako k juniorovi, co mu píšete zadání.
Obrovsky záleží na tom, co za klienta používáš, a na cokoliv složitějšího, než izolovaných pár řádků, je potřeba lokální agent
Z toho pojmu "agent" se jednou zcvoknu. Ten termín mohl vymyslet jen nějaký AI hujer.
... než obecní agenti typu KiloCode. Nepřizpůsobíš si je tak na míru, ale to na začátku ani dělat nechceš.[/li][/list]
Marně přemýšlím, co je na Kilo Code obecného. Jen je ho třeba nakonfigurovat, poskytnout mu dobrý index a nainstalovat potřebná MCP s nástroji. Nemá vestavěný tooling. S kvalitním modelem pak výsledky nejsou o moc horší a vlastně mohou v některých ohledech být klidně i lepší. Třeba Claude Code ostatně většinu času nedělá nic jiného, než spoustu globálních grepů. Nepřidává tomu žádnou další velkou magii. Druhou věcí je, že je to pak celkem drahé ale to je jiný problém.
-
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
Zvláštní otázka. Jazyk samozřejmě češtinu. Jaký význam mají frameworky v době LLM, který ušije aplikaci na míru?
Jaký význam mají frameworky v době peogramátorů, kteří ušijí aplikaci na míru?
Pochopitelně, v první řadě finanční. Stejně jako je lepší si koupit na prodej háčkovaných ponožek Shoptet, než e-shop na míru.
Jenže dnes už je možné mít aplikační boilerplate, nebo eShop na míru, za pár minut.
Frameworky samozřejmě mají další výhody. U e-shopu to bude operations a maintenance. Stejně tak u frameworku. Pro vibecodery je furt bezpečnější použít kus kódu, který spravuje někdo chytřejší. Dále také jim stačí čas od času udělat `npm update`, když i ten chytřejší někde udělal chybu.
Ale co se týče úspory ohledně boilerplate kódu, tam už je výhoda frameworků pasé. Tak to bylo asi myšleno.
-
jaky jazyk a frameworky pouzivas, bylo by zajimave porovnat jak ruzne modely ruzne dobre vyrabeji kod pro ruzne jazyky.
Zvláštní otázka. Jazyk samozřejmě češtinu. Jaký význam mají frameworky v době LLM, který ušije aplikaci na míru?
Jaký význam mají frameworky v době peogramátorů, kteří ušijí aplikaci na míru?
dalekovětší než kdy dřív, ověřené postupy jsou důležité, správná architektura také, to pak LLM umí velmi dobře používat, k frameworku je api, dokumentace, v tom je doma. Vymýšlet pořád něco od nuly je nesmysl, zejména, když v tom pokaždé udělá nespočet chyb.
-
Ale pokud tomu dám z prstu vycucané zadání na půl odstavce, tak to nejspíš bude odpad,
To není nutně pravda. Já osobně jsem prakticky nenapsal prompt delší než pět vět. Jenomže pak je třeba postupovat iterativně.
Z mojí zkušenosti je právě lepší udělat větší zadání hned na začátku, protože to dost oseká potřebu iterací, kde se půlka vygenerovaného kódu musí přepsat, protože něco. Nebo potřebuji mít hodně dobrou představu, kam a jak se chci dostat hned od začátku - ale to pak ten implementační plán máš už v hlavě a jen mikromanažuješ ten model podle toho plánu. Což už ale celkem slušně zvládají ty modely samy - když mají podle čeho.
Z toho pojmu "agent" se jednou zcvoknu. Ten termín mohl vymyslet jen nějaký AI hujer.
Souhlas, ale když už se to používá, tak ať aspoň lidi ví přesně, co to znamená.
Marně přemýšlím, co je na Kilo Code obecného. Jen je ho třeba nakonfigurovat, poskytnout mu dobrý index a nainstalovat potřebná MCP s nástroji. Nemá vestavěný tooling. S kvalitním modelem pak výsledky nejsou o moc horší a vlastně mohou v některých ohledech být klidně i lepší.
Obecné = nesvázané s konkrétní sadou modelů. Zkus do Codex app dostat Claude nebo Gemini. Což zároveň znamená, že ten Codex je víc šitý na míru GPT modelům a dává lepší výsledky na první dobrou. KiloCode prostě vyžaduje větší časovou investici hned na začátku -> horší učící křivka -> když chce někdo začít, tak ho odkážu na ten ucelený balíček, který dělá víc věcí sám.
(Plus tyhle vlastní aplikace, jako Codex nebo Antigravity, jsou součástí $20 předplatných, zatímco KiloCode je nutně pay-per-token api - což pro člověka, který si to chce používat pro vlastní nevýdělečné projekty, je další faktor.)[/list]
-
vyžaduje větší časovou investici hned na začátku -> horší učící křivka
Nesmysl. Nainstaluju přes npm a okamžitě jedu kompexní tasky klidně i s free modelem. Je to přebrandovaný opencode a ten není tak oblíbený bezdůvodně.
KiloCode je nutně pay-per-token api
Nesmysl, mám v tom předplatné a podporuje se nejen kilo cloud, ale i další provideři jak s předplatným, tak volitelně pay per token.
Zkus do Codex app dostat Claude nebo Gemini.
Zase nesmysl. Běžně používám v claude code modely MiniMax a GLM. Existují i různé lokální proxy a "orchestrátory", které umožňují jednotlivé tooly a modely efektivně kombinovat (teď myslím ofic povolené postupy, nikoli vyzobávání interních oauth tokenů).
Codex CLI to umí taky.
-
Z mojí zkušenosti je právě lepší udělat větší zadání hned na začátku, protože to dost oseká potřebu iterací, kde se půlka vygenerovaného kódu musí přepsat, protože něco. Nebo potřebuji mít hodně dobrou představu, kam a jak se chci dostat hned od začátku - ale to pak ten implementační plán máš už v hlavě a jen mikromanažuješ ten model podle toho plánu. Což už ale celkem slušně zvládají ty modely samy - když mají podle čeho.
Nyni se LLM kodovani treba v Antigravity dela dvoukrokove. Nejprve se ve spolupraci s LLM sestavi plan, ktery se iterativne doladi a ulozi jako *.md soubor primo do projektu, pak se s LLM postupne implementuji kroky planu, onen MD soubor je soucasti kontextu.