PISKVOR:

write-only vs. read-only, kontextové okno, a hackuje se to rovnákama na vohejbák

Jo, přičemž to, že se do toho zamotává a přestává tomu rozumět, a bylo by potřeba udělat krok zpět a investovat práci do vyčištění, nebo v prvý řadě ideálně nemergovat redundantní hacky, na to v tom nekonečným cyklu není prostor.

zaplavení krajiny spoustou jednorázových protodukčních nástrojů

Jo, SW bude nadále ještě větší sračka než doteď, to se máme na co těšit.

jednorázový nástroj lze ale dělat jen na malý, dobře definovaný a ohraničený problémy

Jo, přičemž jak píšu, zřejmě dost práce proběhlo před začátkem experimentu. Jak bude někdo psát pečlivou a důkladnou test suitu pro libovolnej problém, kterej není futrovanej +- jednoznačnýma standardama, bych rád viděl.

JANFROG: Já na ty backendy vůbec nekoukal, ale tak nějak když tam čtu, jak to produkuje pro real mode příliš velkej kód, tak tam nic takhle sofistikovanýho spíš nebude. Do lexeru jsem koukal, protože lexikální analýza je lehkej problém, a poté, co jsem to viděl, tak ta představa, jak po něm luštím x86_64 volací konvence, alokace zásobníku, atp., mě láká pramálo.

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.