• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    Diskuze o obzive programovanim pro starsi a pokrocile.
    rozbalit záhlaví
    JANFROG
    JANFROG --- ---
    JARDABEREZA: Teziste te myslenky spociva v motivaci (core) vyvojaru to vyvijet v open source smyslu (pokud dam na GH kod, prilepim k tomu MIT licenci a jen si jedu svoje a co delaji jini me nezajima a nehodlam se o tom bavit, pak to neni "open source projekt", ale "projekt s verejnym kodem" - samozrejme muzeme se o tom bavit, ja jen rikam z ceho vychazim ja).

    Troufam si tvrdit, ze zdrojem motivace pro open source vyvojare je i "uznani komunity"
    (nebo jak prelozit recognition) a s tim spojeny socialni kapital - budovani kontaktu, track record z jedne strany, z druhe strany vedomi ze problem je tak komplexni, ze je lepsi spolupracovat i za cenu bolestnych a komplikovanych kompromisu - a to jak na urovni jednotlivcu tak firem velikosti Intel nebo NVidia.

    Predstava (obcasneho) prispevatele ze kdyz do open source projektu posle opravu chyby ktera ho pali nebo novou featuru kterou chce je pro open source projekt z pohledu core maintainera cisty zisk je neuplna. Realita obvykle je ze core maintainer by stravil mene casu kdyby to udelal cele sam nez stravi tim ze to projde, pochopi co za problem to resi, domysli nasledky apod. Navic - a to si malo lidi uvedomuje - pokud jsem maintainer a prijmu nejaky kod, pak se ten kod stava jeho problemem, on ho musi udrzovat, testovat a tak dale. Takze investice z hlediska maintainera je vysoka, neni bez rizika, je to prace ktera je extra nebavi, nicmene na druhou stranu, maintainer ziska kontakt, uznani a mozna potencialniho budouciho maintainera, mozna dokonce i dobrej job. Ted jde o to, je posoudit to riziko a rozhodnout jestli do toho ma maintainer investovat svuj cas. Mira usili kterou do toho (obcasny) pripevatel vlozil na to ma vliv.

    Pokud rozbijes tyhle interakce, co z toho budou open source vyvojari mit. Co je bude motivovat v te praci?
    SPIKE411
    SPIKE411 --- ---
    JARDABEREZA: Asi můžeš začít u klasik
    Free Software, Free Society - Wikipedia
    https://en.wikipedia.org/wiki/Free_Software,_Free_Society
    The Cathedral and the Bazaar - Wikipedia
    https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
    Homesteading the Noosphere - Wikipedia
    https://en.wikipedia.org/wiki/Homesteading_the_Noosphere
    JARDABEREZA
    JARDABEREZA --- ---
    JANFROG: Můžeš mi ten sociální řád trochu přiblížit? V čem je těžiště té myšlenky?
    JANFROG
    JANFROG --- ---
    (nyx spadl, tak znova :-)

    JARDABEREZA, KOLCON: Ano, takhle to muze vypadat z pohledu konzumenta open source projektu. Ja se na to divam z pohledu vyvojare open source.

    Open source neni jen nejaky kod nekde pod nejakou "open source licenci". Dnes je to hlavne o modelu vyvoje, nejake spolecenske smlouve nebo socialnim radu, nebo jak to rici. Ne ze by open source jako socialni model nemel problemy pred LLM, ale LLM ty problemy prohlubuje a akceleruje. A jak kdysi poznamenal Jeremy Bennett - "Compilers don't write themselves". Open source prestane existovat pokud prestanou existovat open source vyvojari.
    QWWERTY
    QWWERTY --- ---
    JARDABEREZA:
    "2) napíše místo ní něco od nuly"
    tam prestava existovat #3 a s ni rozvoj soucasnych FOSS projektu
    kazdy si pak s ruzne kvalitnim LLM-modelem pise 10000x tu stejnou vec, kazdy vyrabi vlastni N-hranne "kolo", kazdy prochazi tou stejnou serii bugu, edge-cases, vulnerabilit, ...
    ....zatimco ty svoje startupy rushuje do produkce a nechava zakazniky do tehle neodladenych polotovaru sypat data a provadet transakce

    "4) vývojář dá pokyn AI udělat hard-fork opuštěného projektu a dokončit ho"
    a nebo treba taky aktivniho...
    LLM-Driven Large Code Rewrites With Relicensing Are The Latest AI Concern - Phoronix
    https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense

    a 3) udělá stovky PR do existujícího projektu
    viz
    KOLCON: "v obou případech mi maintainer vysvětlil, proč se AI tak trochu netrefilo..."
    a to je uz velmi dobre zdokumentovana soucast smrt open-source. uz ted to byly neadekvatne ohodnoceni maintaineri a ted je navic lidi zacali zasypavat AI slopem.
    jak pak cekame, ze budou mit cas, chut a energii na rozvoj puvodniho projektu?

    https://thenewstack.io/ai-slop-open-source/
    Jannis Leidel, the lead maintainer and Python Software Foundation chairperson, writes that the “flood of AI-generated spam PRs and issues” made his project unsustainable.

    https://thenewstack.io/ai-generated-code-crisis/
    Remi Verschelde, who maintains the Godot game engine, has described triaging AI slop as draining and demoralizing.
    KOJA
    KOJA --- ---
    JANFROG: Souhlasim. Hlavne si to predstavuju u projektu kde maji ruzny prispevatele ruzny potreby a konsensus se buduje pracne.
    KEJML
    KEJML --- ---
    JARDABEREZA: Používám v práci IntelliJ s Githib Copilot pluginem a před pár dny mě překvapilo, že ten už tohle umí. Něco s nim chci debugovat a najednou se mě začne ptát, jestli si může dát breakpoint tam a tam a celkově problém více méně samostatně zanalyzoval.
    KOLCON
    KOLCON --- ---
    JANFROG: Tak ne nutně. Zase může AI časem psát kvalitní PR ("oprav to a udělej PR") a zase nechceš vibecodovat všechny knihovny sám znova... Zatím jsem to zkusil 2x a v obou případech mi maintainer vysvětlil, proč se AI tak trochu netrefilo...
    JARDABEREZA
    JARDABEREZA --- ---
    JANFROG: Tady se to taky pěkně větví. Možnosti jsou:
    1) AI šáhne po open source dependency
    2) napíše místo ní něco od nuly
    3) udělá stovky PR do existujícího projektu
    4) vývojář dá pokyn AI udělat hard-fork opuštěného projektu a dokončit ho

    U sebe jsem pozoroval, že rádo dělá věci od nuly. Občas ho přesvědčím pro použití dependency. Ale líbí se mi, že pro jednoduché věci to dělá kód od nuly. Lepší kontrola, méně problémů se závislostmi. Menší problém se supply chain attack. Umí vychrlit stovky testů. Má kapacitu pomoci s údržbou. U složitějších závislostí to už nedává tolik smysl.

    Líbilo se mi, že mi to třeba umělo udělat PSD/PSB binary parser pro vytažení specifických hodnot v C++ s tím, že to čte pouze nezbytně nutné údaje, co chci, a nemusí to ani načíst celý soubor do paměti.
    JANFROG
    JANFROG --- ---
    JANFROG: Tedy za predpokladu, ze povazujeme open source za dobrou vec. Pokud ne, je to samozrejme vitany vedlejsi efekt :-)
    JANFROG
    JANFROG --- ---
    JARDABEREZA:
    Snižuje to závislost projektu na původním autorovi.

    Presne. Takze ke vsem tem "externalitam" co jmenoval QWWERTY muzeme jeste pridat zniceni open source :-)
    NAVARA
    NAVARA --- ---
    Potřebujeme markdown support na nyxe :\
    NAVARA
    NAVARA --- ---
    Nechával jsem zpracovávat nějaké texty a fable dostal za úkol to jenom orchestrovat a použít opus/sonnet/haiku podle toho, na co jsou nejvhodnější. Haiku rychle vyhodnotil jako ztracený případ, že lepší jsou python skripty (deterministické, auditovatelné). V ostatních to po sobě kontrolovali a i opus udělal semtam chybu; což pak řešil fable aby se už neopakovalo.

    I pulled the per-agent token records from all 39 workflow outputs still on disk for this session. The numbers reconcile exactly (per-model sums match the grand total). Orchestrator (Fable 5 main loop) tokens are not metered in these records, and the Python scripts cost zero agent tokens.
    
    ORCHESTRATOR (MAIN LOOP) COST
    +------------------+-------+----------+-------------+----------------+-----------+
    | Model            | Turns | Fresh in | Cache write |     Cache read |    Output |
    +------------------+-------+----------+-------------+----------------+-----------+
    | Opus 5           | 1,510 |    2,852 |  11,067,667 |    723,041,429 | 1,771,768 |
    | Fable 5          | 1,035 |    1,937 |  14,903,932 |    541,967,725 | 1,283,564 |
    +------------------+-------+----------+-------------+----------------+-----------+
    | TOTAL            | 2,545 |    4,789 |  25,971,599 |  1,265,009,154 | 3,055,332 |
    +------------------+-------+----------+-------------+----------------+-----------+
    
    - **Output tokens are the real "thinking" cost: 3.06M total**, of which the Fable 5 stretch (B1 fold through campaign completion) produced 1.28M across 1,035 turns — that covers all the ratifications, seam rulings, gated appliers, source verifications, and commit work.
    - **Cache reads dominate raw volume (1.27B)** but that is just the conversation context being re-served from cache on every turn of a very long session - it is the cheapest token \\type by an order of magnitude. Fresh (uncached) input was nearly zero — the prompt cache did its job almost perfectly.
    - **Cache writes (26M)** are tool results entering context for the first time: transcripts read for verification, checker reports, screen outputs.
    - Put against the subagent fleet: the orchestrators 3.06M output tokens steered 90.85M of subagent work, so orchestration ran at roughly **3.4% of the fleet it directed** — and the Fable 5 half alone, which orchestrated all of Phase B (B1-B6, 21 workflows, ~200 agents), cost 1.28M output, about 1.9% of the ~68M of subagent tokens it dispatched in that stretch.
    
    BY MODEL
    +---------------------+-------------+--------+---------------------------------------------------+
    | Model               |      Tokens | Agents | Used as                                           |
    +---------------------+-------------+--------+---------------------------------------------------+
    | Sonnet 5            |  64,985,636 |    202 | extraction + Phase B drafting, revision passes    |
    | Opus 5 (1M context) |  20,028,766 |     75 | checkers, confirmers, adjudication, B4, B6 review |
    | Opus 5 (standard)   |   5,718,443 |     24 | C1 aggregate backfill, wiki name verification     |
    | Haiku 4.5           |     113,634 |      1 | B0 registry collation (its only appearance)       |
    +---------------------+-------------+--------+---------------------------------------------------+
    | TOTAL               |  90,846,479 |    302 |                                                   |
    +---------------------+-------------+--------+---------------------------------------------------+
    
    BY METHOD
    +--------------------------------------------------------------+---------------+-------------+
    | Method                                                       | Model         |      Tokens |
    +--------------------------------------------------------------+---------------+-------------+
    | Phase A extraction drafting (121 episodes, 11 waves)         | Sonnet        |  41,446,109 |
    | Phase A wave checking (2 checkers per wave)                  | Opus 1M       |   5,272,119 |
    | C1 aggregate backfill + wiki name verification               | Opus std      |   5,718,443 |
    | B0 setup (arc proposal, registry, wiki)                      | mixed + Haiku |     673,126 |
    | Phase B drafting (B1 pages, B2 slices, B3 layer, B5 hub)     | Sonnet        |  19,037,108 |
    | Phase B revision passes (verify-before-apply)                | Sonnet        |   4,502,419 |
    | Phase B checking, confirmation, proposal adjudication        | Opus 1M       |   6,013,922 |
    | B4 shared-entity continuation (drafting AND checking)        | Opus 1M       |   6,103,224 |
    | B6 independent review + remediation confirms                 | Opus 1M       |   2,737,940 |
    +--------------------------------------------------------------+---------------+-------------+
    | TOTAL                                                        |               |  90,846,479 |
    +--------------------------------------------------------------+---------------+-------------+
    
    ## Notable line items
    
    - The single most expensive method by far was Phase A extraction: each wave ran ~4.2-4.8M tokens (twelve Sonnet drafters reading full transcripts, ~350k each), and its Opus checker pairs cost a steady ~500-575k per wave, about 11% of each wave.
    - **Lost work from infrastructure kills: 1,744,221 tokens** with nothing on disk (the wave-7 session-limit kill at 1,397,701 and B1s rate-limit kill at 346,520). Both relaunched fresh; the checkpoint discipline meant nothing else was ever re-paid.
    - The B6 reviews four Opus reviewers cost 1,674,392, and the cheapest consequential unit of the whole project was the B3 partition proposal: one Opus agent, 200,247 tokens, whose ratified output steered ~15M tokens of downstream drafting.
    - The revision layer (Sonnet, 4.5M) plus the confirm layer (inside the Opus figures, roughly 1.5M) together cost about 6% of the total, and caught the ten wrong checker claims and every silent skip, which is the best ratio in the ledger.

    Nebyl to tedy coding, ale i na to dojde :)
    JARDABEREZA
    JARDABEREZA --- ---
    KLEINZACH: Mě mile potěšilo, že jsem tam nahrál screenshot mého wireframe pro UI s poznámkama, všechno jako bitmapu. Pak jsem řekl ať si projde projekt a dokumentaci a udělá z toho odpovídající UI a logiku, ale ať je to UI víc kompaktní, a ono to fakt dost dobře fungovalo a zapadlo.

    Já teď dělám debugger do VSCode a chci si tam přidat nějaké MCP aby AI vědělo že si může:
    - nastavit breakpoint
    - spustit kod v konzoli
    - číst proměnné
    - trasovat kod

    A jsem fakt zvědavý jestli a jak to bude fungovat :-D Aktuálně si musí napsat test, spustit, pak přečíst výstup z terminálu, co se užil do souboru. Přijde mi, že to kolečko je delší než je nutné.
    KLEINZACH
    KLEINZACH --- ---
    helejte a co to google ai? je to k necemu

    ted to chvili zkousim (ale nechci po tom zatim kod), je to celkem pricetny a vypada ze za to nic nechtej?

    --

    v praci mame opus a fable a jako musim uznat ze je to fakt dobry - jak na review, tak na opravy/zlepseni (i kdyz obcas vybleje nejakou veselou kravinu), tak na veci jako "napis izolovanej benchmark na todle a zmer to a vyblij report s grafama. ne ty debile, kazdou krivku v grafu jinou barvou."
    co je naprosto bozi: "udelej UML z tydle casti kodu".
    na hledani bugu mi prijde ze je to stejne blby jako ja, ale kdyz ho nasmeruju tak to po par iteracich zvladnem. ("je tam chyba protoze je tam celou dobu 0. ne ty debile, je to cely ve smycce" :) )

    co me teda mrda, kdyz je to drzy. onehda me to pokaralo ze uz bych si mel vazne udelat branch, ze ty zmeny uz dela potreti (2x prisli testeri ze chtej binarku beze zmen na testovani, tak sem to shelvnul a zapomel odshelvnout). rek sem tomu na "keep it to yourself, smartass", ono to prej "fair" :))
    CERMI_FOX
    CERMI_FOX --- ---
    VITEX: jasný, to je ale problém korporátu :-)


    JARDABEREZA: "hey, please fix bug#123456 and incorporate findings into the review agent md so it won't happen again"
    VITEX
    VITEX --- ---
    CERMI_FOX: Nojo ale ty je musíš všechny platit darmožrouty dementní. Jak dvě opice co si navzájem vybíraj z blechy z kožichů a házejí je mě na talíř...
    JARDABEREZA
    JARDABEREZA --- ---
    VITEX: To je dobrá pointa. Kdo si odnese to ponaučení? Bude to člověk nebo AI? :-D Mně to teď přijde, jako bych měl zaměstnance/podřízené. Z chyb, které jsem neudělal já, se nepoučím. Viz CERMI_FOX
    VITEX
    VITEX --- ---
    JARDABEREZA: Já už to na sobě pozoruju teď.Je to stejný pocit jako když nechceš tahat těžkou tašku. Sice víš že bys jí bez problému odnesl z bodu A do bodu B možná s nějakou přestávkou ... ale za chvíli tu bude auto co to odveze za tebe ...
    VITEX
    VITEX --- ---
    JARDABEREZA: Chybama se člověk učí ... a až toho posereš tolik co já, tak budeš fakt dobrej!
    CERMI_FOX
    CERMI_FOX --- ---
    JARDABEREZA: už teď jeden agent hlídá a dělá review druhýmu a ten si to pak po sobě opraví. Tedy jeden agent ... vlastně je jich už víc - jeden na security, jeden na privacy/compliance, jeden na code smells atd :)
    JARDABEREZA
    JARDABEREZA --- ---
    QWWERTY: Korporát bude zřejmě "speciální oříšek k rozlousknutí". Ale co se týče akcelerace vývoje, tak to umožňuje nové přístupy.

    - Když máš nápad na startup a na projekt. Uvádí se, že pouze 1 z 10 startupů uspěje. A podnikatelé obvykle neuspějí s první firmou a pokračují s dalšími nápady. Můžou najít ten úspěšný problém dříve. Pokud si na sebe projekt nevydělá nebo ho nikdo nepotřebuje nemá cenu to dotahovat do konce. Za určitých okolností pocit z dokončení nějaké práce je psychologická past. Mozek má rád úplnost. Problém je, že ostatní to budou AI používat taky a bude tak jednodušší úspěch okopírovat.

    - Potom pokud mi stačí 10% času z toho co by to trvalo dřív, tak mám větší šanci na dokončení.

    - Mění to taky perspektivu opuštěných projektů. Před AI bylo velmi těžké porozumět složitejším open source projektům, které nemají nějakou lepší dokumentaci. Dneska mi to Fable všechno projde, sepíše high level architekturu, nakreslí diagramy, napíše testy a hned vím s čím mám tu čest a případně může to rozšířit a přidat nové funkce snadněji. Snižuje to závislost projektu na původním autorovi.

    Na kongitivní degradaci jsem zvědavý, jak u mě bude probíhat. Jaké budu pozorovat projevy a za jakých okolností se rozhodnu změnit způsoby, jakými budu outsourcovat svoje přemýšlení :-D Pro mě celkem jasný příklad s kalkulačkou. Když s ní všechno počítám, neumím si to spočítat bez ní. Ale v současné situaci to nepovažuji za dostatečně velký problém, abych to chtěl řešit.
    Kliknutím sem můžete změnit nastavení reklam