AI, programování a vibecodování

[LokiB]

Značnou část lidstva
Hele dobrý, ale než se to zvrtne, tak to snad raději oddělit a udržet AI ilustrace čistý ...

[Jezus]

Možná bude stačit k úspěchu být hodný a zábavný

Jakože obojí dohromady? Tak to je půlka fóra v řiti

[Zeloran_163]

Trochu odbočím od ilustrací - zajímalo by mě (hlavně u odpůrců AI tvorby), jak se stavíte k tvorbě programů a aplikací pomocí AI.
Jak jsou na tom profi programátoři ve srovnání s profi ilustrátory a proč?

Tady můžu přihodit osobní zkušenost, protože se programováním her živím a AI při práci používám.

Na debugování existujícího kódu je podle mě AI výborná. Procházení kódu a hledání, kde se něco rozbíjí, mi reálně šetří spoustu času. Taky je skvělé spolu s AI pomlouvat jiného kolegu stylem: „Chápeš, jak tohle mohl napsat?“

U nové featury nebo redesignu už hodně záleží na rozsahu. Když změnu omezím na pár souborů, pořád ji dokážu reviewnout a pochytat chyby. A AI dělá i dost zákeřné — třeba mi při dalších iteracích mimoděk prohodí pořadí vektorů ve vektorovém násobení, takže jednou je po promptu výsledek správně a podruhé ne. Neustále ho musíš prostě hlídat a opravovat s tou jeho protivnou submisivní odpovědí: „Jejda, máš pravdu, zase jsem to zkazil/zkazila...“

U velkých změn podle mě nastává problém ve chvíli, kdy už člověk není schopný celý výstup poctivě zkontrolovat. Pak nasadí reviewer svoje AI na kontrolu práce AI svého kolegy autora a interpretační šum se může začít násobit. Dostal jsem se už párkrát k diskuzi s kolegou, proč jeho AI něco nějak udělalo, a on mi to neuměl vysvětlit, protože to taky nechápal.

A co mi na AI kódu vadí překvapivě hodně, jsou komentáře. Má tendenci psát eseje k trivialitám, vymýšlet vlastní květnaté pojmy a naopak neokomentovat věc, která je pro člověka naprosto netransparentní. Někdy dokonce blatantně lže, čehož si právě při velikosti změn nikdo nemusí všimnout. Takže nejprve je reakce: „Hurá, konečně máme dokumentaci.“ A pak vystřízlivění: „Ale takovou?!“

Takže za mě je AI při programování skvělý nástroj, dokud její práci ještě dokáže zkontrolovat člověk. A ta kontrola je naprosto zásadní.

[Jerson]

Mně by se takový přístup líbil třeba i při tom kreslení, jen mám dojem, že to nějak nefunguje
Každopádně při své tvorbě hry do kódu vůbec nevidím a není šance, že bych ho dokázal pochopit, natož upravit, protože na to prostě nemám čas.
Psal jsem to spíše proto, že jsem si mnoho let říkat, jak by bylo skvělé moc tu svou představu světa vytvořit jako interaktivní aplikaci a případně hru, ale protože by měla jen velmi malý okruh uživatelů a přitom nebyla úplně triviální, tak na to můžu zapomenout, a s AI za zadkem jsem se dokázal dobrat k prvním funkčním prototypům během odpoledne, kdy jsem hlídal syna na hřišti. I když jsem tím nejspíš sebral práci nějakému programátorovi, který by to za sto táců udělal taky - jen bych mu je nikdy nemohl zaplatit.

[Zeloran_163]

Jasně, spíš jsem odpovídal, jak to funguje ve velkém studiu. U malého projektu s AI nevidím problém, spíš naopak.

[ilgir]

Já dělám tahovou hru na mobil. Není to úplně jednoduchá věc, těch mechanik, návazností i grafiky tam je dost, ale není to zase žádný "velký projekt". Přijde mi, že čím jsem dál, tím víc dělá chatbot chyb, nebo spíš opomenutí. Každopádně mě pořád fascinuje, jak komplexně je schopen "přemýšlet". A psaní kódu, (které po něm nejsem schopen efektivně zkontrolovat) zvládá velmi dobře, a to i včetně průběžného odstraňování potenciálnách konfliktů. Zatím jsem nenarazil na problém, který by se nevyřešil obratem, takže zdárně pokračuju.

[MarkyParky]

Díky LokiB, který mě nasměroval na repozitáře a stabilní governance v nich.

Driftování kleslo o parník a začíná se mi dařit vibecódovat větší věci než jednorázové skripty.

[Antharon]

Já dělám tahovou hru na mobil. Není to úplně jednoduchá věc, těch mechanik, návazností i grafiky tam je dost, ale není to zase žádný "velký projekt". Přijde mi, že čím jsem dál, tím víc dělá chatbot chyb, nebo spíš opomenutí. Každopádně mě pořád fascinuje, jak komplexně je schopen "přemýšlet". A psaní kódu, (které po něm nejsem schopen efektivně zkontrolovat) zvládá velmi dobře, a to i včetně průběžného odstraňování potenciálnách konfliktů. Zatím jsem nenarazil na problém, který by se nevyřešil obratem, takže zdárně pokračuju.

Chatbot ma tzv. Context, je to v podstate taka externa pamat ktoru tvoj agent pouziva. Vacsinou sa snazi nejakym sposobom tento context udrzovat pod kontrolou a teda casom z neho zacne mazat data ktore povazuje za zbytocne. Ked sa dostane na limit kontextu, vsetko sa to este zhorsi, zacne robit chyby, zabudat a celkovo je zmateny.

U agentickeho programovania existuju rozne aposoby ako okolo toho chodit. Rozne funkcie ktore maju byt opakovatepne vies agentovi definovat pomocou skillov, vseobecne spravanie agenta pomocou agent.md, knowledge base si mozes udrzovat v externych md filoch a agent samotny si koze rozsirit svoj kontext tak, ze veci si bude ukladat do md filov a bude si len zbezne pamatat kde ma co hladat.

[LokiB]

Proto se také v agentském programování nejede stále v jednom vlákně, ale naopak používáš v rámci projektu celkem krátká vlákna (protože to, co je v jednom vlákně on neustále používá jako preprompt pro další postup, což žere víc a víc tokenů a kontextu s narůstající délkou).
To, co nechceš, aby zapomínal, máš v agents a skills a md podkladech, a šetříš tím jednak tokeny a druhak nedochází k přetékání z dostupného kontextu.

[ilgir]

Njn, projekt sice mám, ale dělení chatů jsem podcenil. Tak to holt budu muset udržet v hlavě já, když to neudrží on.

Používám paušální předplatné, tak nevím, jestli se mám snažit "šetřit tokeny".

[LokiB]

Tady je rozdíl, jestli to (v případě ChatGPT) používáš v módu chat, nebo work... Nebo přímo v Codexu lokální aplikace.
Projekty v Codexu (nad tvou lokální složkou s programovým projektem) jsou něco jiného než Projekty v chatu ChatGPT, které jsou nějakým sdružením vláken chatů.
Pro programování, i vibecoding je ten první způsob. A ještě i ideálně si rozjet lokální git, to se pak hodí pro verzování.
A tady šetřit chceš, protože když ti "tokeny" dojdou, musíš čekat než se obnoví.

[MarkyParky]

K těm tokenům (a ChatGPT).

Pokud vibecoduješ tak jeden člověkoden týdně, nemusíš to IMHo řešit. V pohodě ti vystačí i když všechnu práci necháš dělat Sol.

Pokud máš intenzivnější týden a děláš víc, tak už to trochu teče a je dobrý přemýšlet o tom, co děláš:

• Sol používat na všechna koncepční rozhodnutí, implementaci velkých kroků, vibe-promoting governance a datové analýzy,prostě věci, které chcete udělat jednou, ale pořádně. Pouští žilou rychle, ale efektivně.
• Terru používat na menší úpravy, prototypování, iterace, případně nějaké dílčí analýzy, zejména tak, kde čekáte, že to bude chtít několik pokusů, než dostanete co chcete. Momentálně je asi 10x levnější než Sol a je to znát. Ale už má tendenci driftovat, takže vždy dodělat jeden problém a založit si na další nové nezávislé vlákno.
• Lunu v podstatě nepoužívám. To je tupej chatbot, co vám říká to, co chcete slyšet a nepamatuje si, co se dělo 3 posty zpátky, natož aby spolehlivě plnil nějaké úkoly.

Samozřejmě, na dveře klepe Astra, tam zas bude všechno jinak.

[Eleshar_Vermillion]

A AI dělá i dost zákeřné — třeba mi při dalších iteracích mimoděk prohodí pořadí vektorů ve vektorovém násobení, takže jednou je po promptu výsledek správně a podruhé ne.

Taky nás do toho v práci tlačí. Opouštíme funkční low-code/no-code nástroje výměnou za vibe-code nástroje s neexistující kontrolou, a už při experimentování jsem tam přesně viděl tohle. Vyrobí mi to dost solidní prototyp, ve kterém ale potřebuju něco změnit, dodělat, i třeba poměrně bezvýznamné věci jako korporátní barvičky, ale přitom to drobně upraví i celou řadu dalších věcí. Samozřejmě tam ani není žádná version control a deployment pipeline zatím je "zadej stejné prompty v provozním prostředí a modli se, aby to vylezlo nějak podobně".

[Antharon]

na vibecoding malych samostatnych appiek odporucam gsd: https://github.com/open-gsd/gsd-core

Je to wrapper, ktory vezme vasho oblubeneho coding agenta (claude code, codex...) a manazuje v nom vas vyvoj. Na zaciatku je najlepsie specifikovat si nejaky zakladny dokument, ktory stanovi technologie, vzhlad, funkcionalitu, shipovane platformy a podobne. No a potom rozdeli development na fazy a subfazy, pocas ktorych sa uzivatela pyta otazky, Najprv vzdy faza zacne tym, ze AI diskutuje s uzivatelom o tom, co to vlastne ma robit a vyjasnuje si medzery. Potom nasleduje planovacia faza, kde si k tomu urobi research a naplanuje si vyvoj a potom je tu development kde uz to vie pomerne jednoducho nakodovat. Potom vyrobi testy a kontrolne scenare pre uzivatela, ktory to overi a potom sa pokracuje dalsou fazou. Su tam nejake moznosti ako do procesu zasahovat ale lepsie je to mat naplanovane uz v uvodnom dokumente.

[Passingby]

Taky nás do toho v práci tlačí. Opouštíme funkční low-code/no-code nástroje výměnou za vibe-code nástroje s neexistující kontrolou, a už při experimentování jsem tam přesně viděl tohle. Vyrobí mi to dost solidní prototyp, ve kterém ale potřebuju něco změnit, dodělat, i třeba poměrně bezvýznamné věci jako korporátní barvičky, ale přitom to drobně upraví i celou řadu dalších věcí. Samozřejmě tam ani není žádná version control a deployment pipeline zatím je "zadej stejné prompty v provozním prostředí a modli se, aby to vylezlo nějak podobně".

To zní skoro tak, jakoby se na ty "AI" a vibe-coding nástroje přecházelo ne proto, že ušetří práci, ale proto, že v nich bude k dispozici komplet log toho, co po nich zaměstnaneci chtěli a oni sami nebudou moct v kódu dělat žádné změny a něco tam propašovat (sice existuje správa verzí a code review, příp. vyžadované procesy, ale není to všude a i tam, kde to je, se můžou najít mezery).