Tak jeden programátor by něco takového dělal několik desetiletí. OK, možno jen let, než by jej odvezli na psychinu. Tady si šlo o něco jiného - ukázat, v jakém stavu je AI a jestli je už možno jí něco takového svěřit, nebo ještě ně. No a výsledek je, že ještě ne. A že to stálo prachy? Někdo si vyhodnotil rizika a řekl, že ty prachy na to dá. Tak kde je problém?
Přiznám se, že můj odhad opravdu kvalifikovaný nebyl. Máte nějakou konkrétnější představu, kolik člověkodnů může trvat, řekněme, ruční napsání kompilátoru jazyka C na jednu platformu v kvalitě, která by umožňovala nasazeni aplikace na produkční prostředí? Třeba "jen" pro mikrokontrolér? Bez knihoven, opravdu "jen" dobře otestovaný kompilátor?
Dobrá otázka. Možná je dobré si ujasnit zadání. Ono to totiž není "ruční napsání kompilátoru" ale spíše "tady máš naprosto všechny zdrojové kódy z celého světa, které jsme získali, kašli na licenci, klidně z toho použij cokoli a nějak z toho zamixuj výsledek"
Překladač od nuly a kvalitní je určitě práce na hodně dlouho, jenže nikdo to od nuly asi psát nebude. Kdybych to dostal na stůl, tak minimálně bych asi použil obdobu Yaccu a Lexu (dneska už je určitě něco lepšího), všechny možné a dostupné optimalizace (asi nad LLVM IR) atd. Určitě ne psaní od nuly (to by i té AI trvalo léta nebo spíše desetiletí nebo století stylem pokus-omyl).
Díky za odpověď. No jo, v dané době je dobré používat nástroje, které jsou v té době dostupné. Takže je asi opravdu nesmysl dnes psát kompilátor od nuly. A ano, yacc a lex mě také napadly. Holt, stará škola... Dnes už jsou zase jiné nástroje, dokonce jakýsi generátor generátorů - někdy před půl rokem jsem něco hledal a narazil na něj, bohužel si už jméno nepamatuji, jen že to bylo nějaké strašně složité. Možná jsem se měl zeptat AI, jak na to.
Nemyslím si, že AI dokáže oklamat roky vývoje ani matematiky, ani programování. Naopak si myslím, že MOŹNÁ v (brzké?) budoucnosti dokáže navázat a přijít s něčím novým. Specializované AI už něco takového dělají, ale masové nasazení to zatím není.
Starou školou bylo myšleno použití lex-u a yacc-u.
Já si vůbec nemyslím, že AI v dnešní podobě nahradí profíky. Když bych měl parafrázovat, co bylo řečeno i zde v diskusi, testovat je třeba každopádně, ať už kód od AI, profíka nebo amatéra. Samozřejmě je pak rozdíl, jak ten kód vypadá z pohledu bezpečnosti (tady bch AI věřil možná i na 50%, viz zprávy z poslední doby o nálezech bezpečnostních děr v letitém SW - a fakt nemyslím aféru s automaticky generovanými PR), udržitelnosti (když vypadne AI, měl by zde být někdo, kdo ten kód pochopí a dokáže udržovat. Zatím. Obávám se však, že se blíží doba, kdy budou výsledky AI perfektně funkční, ale člověk už nepochopí, proč.) a rozšířitelnosti (viz předchozí bod). Ale to jsou jen mé názory, to je nezajímavé. Zajímavější je pozorovat, jak schopnosti AI při designu i kódování SW rostou. A i v testech.
Když děláš nějaký transpiler, tak máš z počátku takové idealistické představy, že ten výsledný kód má být jako od programátora. Jenže pak zjistíš, že to nikdo nečte a nikoho nezajímá. A tak to vzdáš.
Jiná věc je ta, že v drtivé většině případů nepotřebuješ, aby si rozuměl Assembleru. Tím spíše, že cílových platforem a cílových Assemblerů může být více. A tak stačí jeden specialista na tisíc? vývojářů?
Tak jestli ten transpiler překládá do assembleru, bylo by rozhodně dobré tomu assembleru rozumět aspoň natolik, abych dokázal vyhodnotit, jestli dělá co má a pokud možno i jestli je výsledný kód efektivní, ne? Mám tady skrytý předpoklad, že chci, aby byl výsledek použitelný. Čímž se dostáváme na začátek ke sdělení článku, na který reagujeme.
12. 2. 2026, 07:32 editováno autorem komentáře
====
ale spíše "tady máš naprosto všechny zdrojové kódy z celého světa, které jsme získali, kašli na licenci, klidně z toho použij cokoli a nějak z toho zamixuj výsledek"
====
Autor v blogu (který je IMO velice poučný, zajímalo by mě, kdo z diskutujících si jej celý přečetl) uvádí, že modely neměly přístup k internetu, celý vývoj proběhl offline, nez jakýchkoliv dalších materiálů. Takže vzhledem k použitému Rustu se domnívám, že až tak moc "vykradených zdrojáků" tam nebude, protože rustích kompilátorů moc natrénovat nemohl.
Autor celkem detailně popisuje, jakým způsobem vývoj probíhal, jak si agenti (částečně) rozdělili role, jak to bylo především o obrovském množství testů (a failů). Jo, lidi by pracovali systematičtěji, ale uvidíme, jak to bude vypadat ještě za pár dalších iterací modelů. Osobně bych nebyl optimista, že to nebude mít zásadní vliv na práci lidských vývojářů.
Píše
====
This was a clean-room implementation (Claude did not have internet access at any point during its development); it depends only on the Rust standard library.
====
Takže měl k dispozici akorát natrénovaný model ve více instancích + rust knihovnu, bez ničeho dalšího. Žádné hotové implementace čehokoliv, na čem by mohl dál stavět.
Samozřejmě že všechno, co šlo sehnat. Někdo brání profesionálovi, aby přečetl všechno, co jde sehnat? Samozřejmě nemluvím o nelegálním přístupu k ukradeným zdrojům. Pokud někdo něco zveřejní, musí počítat s tím, že si to někdo/něco přečte a zaktualizuje si tím své synapse/parametry. A pak tu "znalost" využije v další činnosti. Ať je to člověk nebo LLM. Já v tom až tak velký rozdíl nevidím. V obou případech použije akorát znalosti získané učením. Já to nepovažuji za "obšlehnuté zdrojáky". Ale každý to vidí jinak, což je taky v pořádku.
Samozřejmě že to běží jednou, na všech těch vstupních datech, které jsou v daném čase k dispozici (je nepodstatné, zda trénink provádí samo LLM, nebo nějaké obslužné nástroje). Pak naučený model spustí, dají mu k dispozici znalosti ovládání svých agentů přes popisy v nějakých promptech (ani nemusí být lidsky čitelné, ale pořád jsou to návody), příp. nějaké programátorské postupy/prompty - tedy to co tvoří ten Claude Code. A dalším promptem tomu modelu s přístupem k pomocným nástrojům dali za úkol napsat ten kompilátor. Takže to co měl ten celý model k dispozici se pořád jenom to, co získal ve fázi učení + ty "vývojářské best practice" prompty. V čem se to liší od toho, co jsem napsal?
Nebo má Claude Code k dispozici nějakou lokální (bez přístupu na net) obrovskou databázi zkopírovaného ("obšlehnutého")/přechroupaného knowhow, kterou by přes RAG průběžně konzultoval? To bych se divil, protože tam už by si dost zahrávali s autorskými právy, ale třeba jo... Tak jak to je?
9. 2. 2026, 19:45 editováno autorem komentáře
Jak s touto diskusí souvisí velikost trénovacích dat? Nikdo tu nerozporuje, že se při tréninku (tj. ladění parametrů modelu) používá vše, co je v daný čas dostupné (ať při prvním tréninku, nebo někdy později při "dotrénování" - možná je desetinné číslo modelu verze dotrénování, nevím, ale není to zde důležité).
Ale je. Zapomínáte totiž na embedding. Dál je tam typicky několik různých attention heads (takže vlastně několik neuronek v jedné), pak ještě výběr z nich a deembedding.
Takže sice je to prediktor dalšího tokenu, ale té abstrakce je tam tolik, že se to už klasickým markovovým řetězcům moc nepodobá.
Nicméně u starších modelů se opravdu stávalo, že to zvládlo replikovat i kus originálního textu.
Jak napsali už jiní. On ten text není ani v těch vahách. V těch váhách jsou zobecněné vztahy mezi něčím, čo byste mohl nazvat koncepty (embeddings). Je to vektor příznaků, ne to konkrétní slovo.
Prostě se ta NN naučila, že takto se píše smyčka. A zvlášť se naučila, že pro nějaký jazyk se používá konkrétní klíčové slovo. Člověk to dělá podobně.
já nepsal natvrdo "obšlehnuté zdrojáky", ale ano, i tak by se to asi dalo hodnotit (jenže do těch modelů nevidíme, navíc současné modely nerady označují zdroje).
Pořád čekám, kdy se v IT objeví někdo, kdo na tom bude vydělávat po analýze zdrojáků (a teď se nebavím o morálce okolo celé genAI, to je na delší povídání někde u piva :-).
Tohle je komplikované, protože se to teoreticky vztahuje na jakýkoliv generovaný obsah. A ještě v každé zemi jinak.
A nemusí to být jen AI. Co takhle rendering 3d modelu? Model udělal člověk, ale ten finální render do fotky (včetně světel, odlesků atd.) dělal stroj. Nebo binárka programu, dneska je to taky možná víc práce překladače, než programátora (různé optimalizace atd). Zdrojáky jsou pochopitelně jasné.
A pak nastává problem s tím, když je součást vývoje nejenom to generování zdrojáků, ale i code review. Je plně zkontrolovaný kód práce AI nebo člověka? A bylo by to stejné, i kdybych ten kód nechal vyrobit třeba bashem nebo by hodně částí bylo upraveno pomocí tradičních, ale stále automatických nástrojů (třeba ten lex)?
Nedávno jsem zaznamenal tu přetahovanou o selfie makaka - https://en.wikipedia.org/wiki/Monkey_selfie_copyright_dispute - fotograf nachystal situaci, foťák, nastavení atd, ale makak stiskl spoušť.
Ty zdrojové kódy patří normálně autorovi. Tedy tomu co použil AI jako nástroj k jejich vytvoření. Stejně jako jakýkoli jiný nástroj, například štětec při malování obrazu. Za to zda tyto zdrojáky generované AI neporušují autorský zákon odpovídá autor. Tedy tomu co použil AI jako nástroj k jejich vytvoření. Jen je tu ještě licence konkrétního AI nástroje, na to pozor.
Tak ono to s tím autorstvím je obecně divné. Když někdo napíše prompt na vygenerování obrazu, je to opravdu jeho autorské dílo? Občas si nechávám něco nakreslit za peníze od živých umělců. Napíšu svou představu, upřesním po dodání hrubého skeče, a zaplatím za hotové dílo. Můžu říkat že je to teď můj obraz? Ano. Můžu říkat že ze mě sepsání zadání dělá autorku? Těžko.
Na druhou stranu, jak se to liší od renderu nebo kompilace? Tam je taky většina výstupu vypočítaná nějakým nástrojem.
A třeba u editace fotek a různých retuší se dnes AI používá hodně. Či je pak ta finální fotka?
Tohle se právě hodně zajímavě řešilo u toho případu s makakem. Podle soudu v USA tradičně stačil netriviální vstup od člověka. Už vize nebo finální úprava stačila. U AI najednou copyright neplatí, pokud je tam netriviální vliv AI? To je najednou úplně obrácená implikace.
A co třeba takový Alexandre Dumas a jeho "továrna na romány"? Je autorem, nebo to jsou ti jeho ghostwriteři? Co mistři jako Michelangelo a další? Rozdal skici a my obdivujeme výtvory jeho bezejmenných dělníků. O software jakožto zaměstnaneckém díle ani nemluvě - de iure jsem autorem a náležejí mi osobnostní autorská práva, ale jak bych to prakticky dokazoval a vymáhal? Když zaměstnanci zadám úkol a popíšu mu algoritmus, jsem autorem já, nebo on, kdož to pouze převedl do konkrétního programovacího jazyka? Je na tabulkovém procesoru či Norton Commanderu podstatná implementace, nebo nápad? Co všechny ty unixové klony - nápad, nebo implementace? Co Sacherův dort - nápad, nebo konkrétní "implementace"? (kuchařské recepty jsou nejstarší doložené nehmotné statky podléhající právní ochraně - už ve starověku)
U zaměstnaneckého díla je to u nás v práci snadné, máme verzovací systém :D Ale osobnostní práva jsou celkem k ničemu, protože výhradní práva na užívání má ten zaměstnavatel.
Implementace vs. nápad je taky jednoduché rozhodnout. Autorské právo chrání pouze zdrojáky (jako literární dílo) a binárky (speciální případ v AZ pro software). Nápad se případně chrání patenty.
Ale diskuze je o problému s ochranou "mezivýstupů" - prompt samotný je chráněný (jako literární dílo), ale mezivýstup (zdrojáky) už někdy je a někdy není, i když tam autor dělal review, změny atd.
Ta argumentace prostě nepočítá s tím, že LLM nejsou jen další "kompilátor" z promptu (mezivýsledky z GCC nebo LLVM taky určitě chránit nejdou). Je to spíš asistent pro psaní kódu, který člověk dále upravuje (to samé foto a video).
Jistě. A pokud je ta abstrakce dobře udělaná, tak je to stejné jako náš mozek. Číst a učit se Vám taky nikdo nezakázal, jen nesmíte přímo kopírovat. Přepis do jiného jazyka nebo napodobení algoritmu je tudíž legální (dokud ta podobnost nepřekročí celkem vysokou míru).
Pak to tedy ještě trošku komplikují patenty, ale to už je jiný problém.
Proč několik desetiletí? Máte nějakou zkušenost se psaním překladače? Pro amatéry/samouky je překladač téměř kouzelný kus software, a právě proto se na odborných školách zadávají (zadávaly?) semestrální projekty typu "napište překladač jazyka podle následující specifikace, generovaný lexer ani parser se nepřipouští." Podobně "napište v Assembleru program podle následujícího zadání." Slouží to k jisté demýtizaci něčeho, co se nezasvěcenému oku jeví jako těžko přístupný problém, bez nějaké teoretické průpravy.
Konkrétně - viz třeba PL/0. Napsat překladač něčeho takového je v podstatě víkendový projekt. A jazyk C, ač to tak na první pohled nemusí působit, je také poměrně dosti jednoduchý jazyk. Tak byl i vymyšlen, aby byl jednoduchý a aby bylo nenáročné napsat i jeho kompilátor. Na kompilátorech je nakonec zdaleka nejsložitější částí optimalizátor.
A nasadil byste program přeložený takovým překladačem do produkčního prostředí? Tím myslím otázku, jak dobře byl ten překladač otestován? Ale ano, nerozporuji, že to nakonec není nic stašně složitého. Jen si myslím, že je za tím obrovská spousta práce v tom dotáhnutí do konce.
A také jsem výše přiznal, že můj odhad nebyl kvalifikovaný.
A teď pohled z jiné strany. GCC je zde od roku 1987. Ano, není to je překladač C, to by těch 15 milionů řádký bylo opravdu podezřele mnoho. Pro C++ jsou v optimalizaci chyby, které generují chybný kód (ne optimální, ale vyloženě chybný) - Google it yourself. Další zajímavé info je zde: https://www.sciencedirect.com/science/article/abs/pii/S0164121220302740
Frontend pro GCC údajně zabírá cca 30 000 řádků. AI naopak tvrdí, že funkční kompilátor C dle C99 zabere cca 77000 řádků. (Nezkoumal jsem, kde k tomu AI přišlo.)
Shrnuto - tohle je rozdíl mezi produkční kvalitou a zápočtovým projektem. I kdyby se mé informace lišily od reality o 50%, o něčem to vypovídá. I informace, jak dlouho jsou chyby v GCC neřešeny a je na to armáda dobrovolníků (díky za ně!) ukazuje, že každá nalezená chyba nemusí mít z lidského pohledu rozumně implementovatelnou opravu.
Samozřejmě se můžu plést a váš zápočtový projekt může dosahovat kvality GCC třeba před dvaceti lety. To se pak velmi omlouvám, sypu si popel na hlavu a gratuluji.
Tak tohle mě pobavilo: https://www.root.cz/zpravicky/linuxove-jadro-zvysuje-o-12-vykon-pri-zpracovani-udp-diky-vlozeni-casovace/hodnoceni/
Není to nic jiného, než potvrzení toho, co jsem napsal, protože:
Ruční vložení těchto dvou funkcí se provádí, protože optimalizace řízené zpětnou vazbou kompilátoru (FDO), optimalizace v době propojení (LTO) nebo optimalizace řízené profilem (PGO) nedokázaly správně zasáhnout.
Takže zápočťák, jo?