PES: AI-rovnák na AI-vohejbak. :)

SH_PANDA: Zalezi na tom, co vsechno povazujes za "skodu". Pokud za tu "skodu" beres i vsechny negativni externality, pak se obavam, ze to neni jen skill issue :-)

SH_PANDA: také to oproti lopatě umí napáchat mnohem větší škody...

PES: akurat ze je to bagr :)

ANT_39: Kdyz jsem to cetl (ten blog post) tak jsem si nemohl nevzpomenout na to co psal Gregory Chaitin ve sve retrospektive (2003) ke svemu (legendarnimu) clanku Register Allocation and Spilling via Graph Coloring (1982 !):

So I regard the success of this approach, which has been the
basis for much future work, as a triumph of the power of a
simple mathematical idea over ad hoc hacking. Yes, the real
world is messy and complicated, but one should try to base
algorithms on clean, comprehensible mathematical ideas...

Vlastně ta hlavní chyba, která nás bude kousat do zadku už furt, je antropomorfizace. "Model říká, počítač si myslí, agent chce" - ano, užitečný způsob, jak o tom vzájemně komunikovat (a taky super způsob, jak to prodávat), ale taky zákeřný: nastavuje v hlavě očekávání, jaká máme u lidí. Leč ten model se bude, každý a pokaždý, chovat jinak, z principu.

#eliza

ANT_39:

- ano, všichni provideři to těžce dotují; co by se stalo, kdyby to nebylo za půlku? třetinu? nákladů, to uvidíme asi v příštím FY.

- vysypat write-only kód na zelený louce je easy (a vypadá to SKVĚLE na prezentacích - "ó, zrušíme mzdový náklady: kůň Hans umí počítat do pěti, takže určitě umí počítat i do sta, i odmocňovat, integrovat a derivovat, to dá rozum!")

- ale zrada, většina kódu je read-only (ve smyslu "upravuje se vždy jen malá část"). To je problém veškerého vývoje, ale zejména u agentů je to problém "nevejde se kontext do vokna" a hackuje se to rovnákama na vohejbák.

- ano, možnost "vždycky si udělám jednorázový prototyp a pak ho zahodím a udělám si nový jednorázový nástroj" se zřejmě dost rozšíří. (z čehož i zaplavení krajiny spoustou jednorázových protodukčních nástrojů, který ale to svoje nedělají úplně blbě, a tak se na ně každý bojí sáhnout)

- jednorázový nástroj lze ale dělat jen na malý, dobře definovaný a ohraničený problémy - větší codebase reprezentuje zejména paměť instituce: "tohle nech bejt, ač to vypadá divně: když budu tady násobit dva floaty a dělit to DPH, přijde na nás berňák; když tady nepošleš dva dummy bajty navíc, tak to protějšek neschroupe, ač je to dle specky". Tyhle věci při zahození a úplném rewritu zmizí.

- vposledku je i ten postup "menežuju agenty" je jen metajazyk: "definuju naprosto přesně a striktně zadání, vstupy, výstupy, očekávané chování, řešení chybových stavů, neprogramuju, kdepak, jen transformuju požadavky do jazyka, který je srozumitelný strojům! To přece...není...programování! Že ne....?!!" Neboli ano, hlavní role vývojáře byla vždycky MYSLET, jestli to převádí do spustitelné podoby děrováním štítků, psaním ve VBScriptu, popisem v angličtině, nebo výrazovým tancem, to je nakonec buřt.

(jistě, některé z těch postupů otevírají dveře k vývoji i lidem, který bych ani já, ani oni, nenazval vývojáři. To bylo pokaždý: "assembler není opravdovej jazyk, to je hračka pro děti!!!" "Makra v Excelu nejsou opravdovej jazyk..." etc)

ANT_39: Jo, na me taky dela dojem, kolik se da dosahnout veci ktera je v principu autocomplete. Ale da se na to divat i z opacneho pohledu, ze to odhaluje, jak malo komplikovane vlastne je lidske vedomi a inteligence a to je vlastne trochu depresivni

QWWERTY: jo, bavi. Pochopitelne si odpustim psani boilerplate typu getteru/setteru nebo porad stejnych textboxu, takovy kod ale nastesti pisu vyjimecne.

ZAHRADKAR: prave me prekvapuje kolik lidi z oboru vlastne psani kodu nema rado a radsi se prepne na manazera, tomu ja se branim celou karieru a treba tady v 40+ bych cekal ze uz lidi budou mit v tehle otazce davno jasno :)

ANT_39: Dalsi celkem vaznej caveat je, ze v tom zrejme Claude sam neni schopnej delat dalsi vylepseni, protoze si pri implementaci rozbiji existujici funkcionalitu.

Na tohle při hraní s AI narážím obecně dost často. Možná to ale jen špatně používám ¯\_(ツ)_/¯

Kdyz tu resime ten vibe coding. Ted probehl na HN nasledujici link: https://www.anthropic.com/engineering/building-c-compiler

Borec nechal tym Claudu udelat prekladac C, vicemene bez supervize. Vysledek zrejme funguje a je schopnej vybuildit a nabootovat Linuxovej kernel. Jsou caveats: optimalizovany kod z toho prekladace je horsi, nez -O0 z gcc, a ma to nejaky dalsi omezeni. Na druhou stranu to podporuje nekolik architektur.

Dalsi celkem vaznej caveat je, ze v tom zrejme Claude sam neni schopnej delat dalsi vylepseni, protoze si pri implementaci rozbiji existujici funkcionalitu.

Koukal jsem namatkou na kod lexeru, a Claude se moc nesere s nejakejma "nice to have" helperama typu skip_over('.'), skip_over_whitespace atp., proste to vsechno inlinuje. Volaci konvence u lex_binary_number() je jina, nez u lex_octal_number(), a ty dve funkce nevolaji nejaky spolecny helpery, proste je to cut'n'paste a upravit pro jinou mnozinu znaku a tu arbitrarni zmenu ve volaci konvenci. A pak znicehonic: helper parse_simple_float_suffix(), kterej vraci 0/1/2 podle toho, jestli je float literal napsanej se suffixem "f" nebo "L", pricemz ale je ten helper pouzitej na jednom miste, a volani je stejne nasledovany match-rozstrelem podle toho, co se vratilo, takze zisk nulovej. Jestli takhle vypada zbytek jeho kodu, tak se nedivim, ze implementace novych featur rozbiji to, co driv fungovalo. Je to holt napsany celkem prasacky.

IMHO je impresivni, ze neco natolik slozityho jako prekladac vubec jde AIckem relativne unsupervised napsat. Na druhou stranu to ukazuje limitace toho pristupu -- veci tehle slozitosti AI sice napsat dokaze, ale sotva, ne moc dobre, dulezity featury ve finale chybi a dopsat je uz nedokaze, protoze na tom kodu se bez dukladnyho refaktoringu neda moc stavet.

Napsat ten prekladac trvalo dva tydny a stalo $20K, coz vypada velice lakave. Furt je tam teda ten jeden inzenyr, kterej kolem toho poskakuje, nakrmil to spoustou kvalitnich testu, atp. A on sice pise, ze pak od toho dal ruce pryc, ale zaroven pise, ze jak u spousteni testsuity, tak u prekladu kernelu musel dodelavat nejakou relativne slozitou instrumentaci kdy jednotlivym agentum predhazoval ruzny deterministicky nahodny casti, aby se paralelne bezici Claudove nezasekavali na te same veci. Navic: tusite nekdo, jestli ty ceny, co si uctuji, jsou... trzni? Celej ten AI trh jede na investorskejch penezich, a vlastne nevim, jestli i ty drahy plany vubec pokryvaji naklady na provoz tech AI. Tak jako tak, i kdyz tech $20K vynasobime vhodnym fudge faktorem, je to v porovnani s lidskym tymem pakatel.

Priznam se, navzdory celkem skeptickemu tonu meho prispevku, udelalo to na me dojem.

PJOTRIK: bavi te psat kod? me treba fakt ne, a psani kodu pro me neni odmena. ja potrebuju primarne funkcni a udrzitelny reseni
pro vsechny moje (v kontextu oboru vyvoje primitivni) ukoly, k tomu pristupuju stejne jako k junior pozici - zadas ukol, definujes scope, nastinis architekturu, urcis success/fail podminky
nad implementaci tomu nechas volnou ruku, pak udelas review a otestujes, ze se to chova jak ma, nebo ze tam neudelal nejaky sileny antipattern, ktery bude pain udrzovat v budoucnu

+ akcelerace prototypingu a boilerplate
+ nejsem primarne vyvojar - uz jsem se z toho naucil par novych postupu pro resenich svych problemu, ktere LLM odkoukalo z jinych projektu, protoze ja sam bych nikdy nesel z dlouhe chvili zkoumat cizi codebase a jak to tam resi

JIMX: "hlavně JAK funguje" .. je na tobe, aby jsi overil v ramci review, viz vibe-coding vs ai-assisted programmer - [E2E4 @ Programovani 40+]