Používáte LLM při vývoji?

[martyd420]

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.

[Reklama]

[Standa Blábol]

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.

[Zopper]

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.

Jo, přesně to mám na mysli tou přípravou plánu.

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ě.

Až na to, že dostat stejnou úroveň výsledků se stejným modelem v KiloCode vs Codex vyžaduje víc babysittingu, než v Codexu a mnohem hůř to zvládá start-to-end samostatnou práci. Srovnával jsem si to tenhle měsíc, vidím, s čím a jak bojují kolegové v jednom i v druhém...

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.

Tak to mi prosím ukaž, jak v KiloCode můžu použít to svoje $20 Gemini předplatné. Já tam totiž nic jiného, než nacpání API klíče z Google Studio AI, prostě nevidím. Jo, jasně, můžu si platit pět různých předplatných u pěti providerů, k tomu občas něco přes tokeny, a používat tím pořád ty stejné tři modely - nebo si můžu vystačit s jedním univerzálním předplatným, jen za cenu toho, že můžu použít jen aplikaci/plugin přímo od Google, protože cokoliv jiného bude chtít ten API klíč. Dtto OpenAI.

Pro jistotu, tohle není o tom, že by ten který klient něčeho nebyl schopný, tohle je o tom, že ten který AI provider má nějakou obchodní politiku.

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.

Ok, když se chce člověk hrabat v configu, tak to tam dodat asi jde, jsem poučen. Ale pořád platí námitka o předplatném.

[Martin Poljak]

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.

To se ale nevylučuje. Každý task, který řeším rozdělím na podtasky, ty řeším jednotlivě a samozřejmě v rámci toho řešení nejdřív proběhne research, pak iterace nad plánem a ještě pak fine tuning nad výsledkem. Když to tak ale čtu, je klidně možné, že mluvíme úplně všichni přesně o tomtéž.

[listoper]

... Je ho ale vždy potřeba kompletně celý důkladně přečíst ...

No to ne. Kdybych chtel precist ten kod co mi to vygenerovalo za brezen tak mam dokonce roku co delat.
Na kod kaslu (pokud si ho nepisu sam... porad me to bavi a na nekterych projektech si s tim rad hraju bez AI).

Ja ctu dukladne funkcni dokumentaci kteru spoli s AI generujeme... a pak si davam zalezet aby mi to AI pekne otestovala...
Mam v instrukcich at pouziva TDD... a u webovych veci nechavam podle specky vygenerovat gherkin a nechavam ho to prez chrome-dev-tools mcp otestovat...

Ten gherkin je jen jako specifikace kterou AI sam interpretuje bez step definitions.

Takze celkem vzato... Specka je muj kod... a test execution report je "Vystup compileru"

[Reklama]

[Zopper]

To se ale nevylučuje. Každý task, který řeším rozdělím na podtasky, ty řeším jednotlivě a samozřejmě v rámci toho řešení nejdřív proběhne research, pak iterace nad plánem a ještě pak fine tuning nad výsledkem. Když to tak ale čtu, je klidně možné, že mluvíme úplně všichni přesně o tomtéž.

Jo, když je to napsané takhle, tak to vypadá jako jen různé variace téhož. Můj původní komentář byl myšlený ve stylu že "přijdu z oběda, plácnu 'počítači, udělej mi logování' a jdu čučet na YouTube" nejspíš skončí tím, že se vygeneruje hromada polofunkčního bordelu, který loguje nedůležité věci, neloguje to, co jsem chtěl, ukládá logy do databáze s login údajema uživatelů místo do Elasticu, ... a tedy ve výsledku to bude čistá ztráta času oproti ruční práci.

[Martin Poljak]

... Je ho ale vždy potřeba kompletně celý důkladně přečíst ...

No to ne. Kdybych chtel precist ten kod co mi to vygenerovalo za brezen tak mam dokonce roku co delat.
Na kod kaslu

Jestli je to váš hobby projekt, je to celkem váš boj. Jestli je to aplikace, kterou nedejbože někdo využívá, spoluvyvíjí a má být spravovatelná, upřímnou soustrast vám i kolemjdoucím.

[listoper]

Jestli je to váš hobby projekt, je to celkem váš boj. Jestli je to aplikace, kterou nedejbože někdo využívá, spoluvyvíjí a má být spravovatelná, upřímnou soustrast vám i kolemjdoucím.

To je dost zcestny... vubec me neznas a pritom si myslis, ze kdyz nejakej kod projde moji revizi tak mu to prida na kvalite  .

Po pravde je to proof of concept. Je to neco co je schvalne vyvyjeno tim zpusobem ze ten kod vlasne ani cist nesmim...
Delam na tom zatim sam (kdyz nepocitam AI), ale mam to predavat behem nekolika mesicu. A plan je takovej, ze i ty co to preberou tak ten kod nikdy neuvidej. Nejspis to ani nebudou tak uplne programatori...

A zatim to funguje prekvapive dobre.

Ja to opravdu beru jako dalsi uroven abstrakce... zacinali sme s dernejma stitkama a prez asm, c, javu se dostavame az k anglictine.

Paradoxne je ten vyvoj asi dost drahej. Myslim, ze to co zakaznik plati me + AI by mu mohlo pokryt 3x me  , ale asi bysme i ve trech byli pomalejsi...

[Martin Poljak]

To je dost zcestny... vubec me neznas a pritom si myslis, ze kdyz nejakej kod projde moji revizi tak mu to prida na kvalite  .

Tím bych se teda nechlubil už vůbec...

Po pravde je to proof of concept. Je to neco co je schvalne vyvyjeno tim zpusobem ze ten kod vlasne ani cist nesmim...
Delam na tom zatim sam (kdyz nepocitam AI), ale mam to predavat behem nekolika mesicu. A plan je takovej, ze i ty co to preberou tak ten kod nikdy neuvidej. Nejspis to ani nebudou tak uplne programatori...

No potěš. Jako samozřejmě u mnoha one-shot projektů typu marketingová akce tohohle nebo tamtoho je to celkem ospravedlnitelné. Ale rozhodně se to nedá aplikovat na cokoliv, co má být trochu udržitelné.

A zatim to funguje prekvapive dobre.

Zatím bezpochyby

Ja to opravdu beru jako dalsi uroven abstrakce... zacinali sme s dernejma stitkama a prez asm, c, javu se dostavame az k anglictine.

Všiml sis, že kompiler a AI je v mnoha ohledech poměrně výraznej rozdíl?

[listoper]

To je dost zcestny... vubec me neznas a pritom si myslis, ze kdyz nejakej kod projde moji revizi tak mu to prida na kvalite  .

Tím bych se teda nechlubil už vůbec...

Ja nerikam, jestli to kvalitu zvysi nebo ne. Ja jen rikam, ze ty to nemuzes vedet.

Po pravde je to proof of concept. Je to neco co je schvalne vyvyjeno tim zpusobem ze ten kod vlasne ani cist nesmim...
Delam na tom zatim sam (kdyz nepocitam AI), ale mam to predavat behem nekolika mesicu. A plan je takovej, ze i ty co to preberou tak ten kod nikdy neuvidej. Nejspis to ani nebudou tak uplne programatori...

No potěš. Jako samozřejmě u mnoha one-shot projektů typu marketingová akce tohohle nebo tamtoho je to celkem ospravedlnitelné. Ale rozhodně se to nedá aplikovat na cokoliv, co má být trochu udržitelné.

Tohle asi nebude one shot... Uz ted se planujou dalsi integrace

Ja to opravdu beru jako dalsi uroven abstrakce... zacinali sme s dernejma stitkama a prez asm, c, javu se dostavame az k anglictine.

Všiml sis, že kompiler a AI je v mnoha ohledech poměrně výraznej rozdíl?

Vetsi nez ctecka dernejch stitku a kompiler?


Hele samozrejme si uvedomuju ten nederminismus, ale prave proto to kompenzuju opravdu podrobnou specifikaci a kvantama testu... Nemyslim jen unit testy.. myslim tim "business scenario" testy...
A opravdu s kazdym deployem do produkce (kterej se mimochodem dela sam a ja se ani nesmim moc zajimat o to jak se to deje  se nahrava do repositare sjetina z testu aby byl dukaz o tom, co vsechno funguje)

[Zdenek Henek]

To je dost zcestny... vubec me neznas a pritom si myslis, ze kdyz nejakej kod projde moji revizi tak mu to prida na kvalite  .

Tím bych se teda nechlubil už vůbec...

Ja nerikam, jestli to kvalitu zvysi nebo ne. Ja jen rikam, ze ty to nemuzes vedet.

Po pravde je to proof of concept. Je to neco co je schvalne vyvyjeno tim zpusobem ze ten kod vlasne ani cist nesmim...
Delam na tom zatim sam (kdyz nepocitam AI), ale mam to predavat behem nekolika mesicu. A plan je takovej, ze i ty co to preberou tak ten kod nikdy neuvidej. Nejspis to ani nebudou tak uplne programatori...

No potěš. Jako samozřejmě u mnoha one-shot projektů typu marketingová akce tohohle nebo tamtoho je to celkem ospravedlnitelné. Ale rozhodně se to nedá aplikovat na cokoliv, co má být trochu udržitelné.

Tohle asi nebude one shot... Uz ted se planujou dalsi integrace

Ja to opravdu beru jako dalsi uroven abstrakce... zacinali sme s dernejma stitkama a prez asm, c, javu se dostavame az k anglictine.

Všiml sis, že kompiler a AI je v mnoha ohledech poměrně výraznej rozdíl?

Vetsi nez ctecka dernejch stitku a kompiler?


Hele samozrejme si uvedomuju ten nederminismus, ale prave proto to kompenzuju opravdu podrobnou specifikaci a kvantama testu... Nemyslim jen unit testy.. myslim tim "business scenario" testy...
A opravdu s kazdym deployem do produkce (kterej se mimochodem dela sam a ja se ani nesmim moc zajimat o to jak se to deje  se nahrava do repositare sjetina z testu aby byl dukaz o tom, co vsechno funguje)

Zajimavý experiment. Asi bych s tim osobně nechtěl pálit čas a peníze. Jak to budeš předávat kolegům/zákazníkovi. Mohl by jsi sem napsat nějaké kratší nebo i delší post mortem?
Chápu, že pro zákazníka/objednatele tohoto experimentu je zásadní, že vývoj takto můžou škálovat a je možné, že to bude nezávislé na vývojářích, kteří budou přicházet a odcházet. Mít a nemít 3 lidi na vývoj je 6 lidí rozdíl

[Zdenek Henek]

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.

Zkouším používat LLM, mám Claude Code cli. Používám vždy nejvyšší model a začínam vždy plánováním /plan kde popíšu problém. Někdy je promt delší a někdy kratší. Záleží na tom jak se to rozhodnu nasekat. Celou aplikaci takto nepopisuju.
Snažím se držet co nejmenší kontext, aby LLM neutíkalo od zadání a neřešilo všechno a nic v jednom commit. Každá část je většinou jeden commit, který bych dělal i kdybych to psal celé sám, abych byl schopný popsat proč se ten kod přidal/změnil když se někdo v budoucnu zeptá. Třeba já sám sebe za 2 a více let.

Kde se mi opravdu daří používat LLM:
* codereview - najde zajímavé chyby, přes SKILLS se dají přidat třeba OWASP - to jsem zatím nezkoušel, ale je to v mém TODO listu "broušení" LLM
* upgrade knihoven - je mnohem rychleší v nahrazování kodu než já, když je v nové verzi knihovny něco jinak.
* nahrazování použití deprecated funkcí za jiný kod, než se provede upgrade, kde ty deprecated funkce už nemusí být k dispozici
* release notes projektu MCP jira , git commits v git repozitáři
* vysvětlování kodu ve kterém se snažím vyznat
* nejsem dobrej v psaní UI, jsem většinou na serverové straně aplikace, ale teď když musím nějaké UI dělat tak s LLM to jde mnohem lépe a rychleji
* unit testy generuje pěkně, chtěl bych podobně dělat i E2E testy, ale to bude asi hned tak nebude


Čeho se bojím:

* kod začne hnít mnohem rychleji
* kdo bude udržovat kod, kterého teď udělám i několikanásobně víc, snažím se toto minimalizovat viz začátek minimální kontext.
* že v časové tísni začneme generovat kod bez toho, abysme se na něj podívali a nebudeme v případě nějaké události na produkci schopni o tom problému mluvit, protože nebudeme znát kod. Něco jako jít na Book Club a mít přečtené jen dvě tři recenze knihy a první kapitolu ...

[Longin]

Používám LLM už půl roku a úplně cítím jak mi degeneruje z toho mozek. Prostě jak člověk necvičí kognitivní schopnosti, tak to jako sval atrofuje.
V tomhle vidím nejvyšší riziko pro lidstvo než to, že LLM někomu sebere práci lol