• ú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í
    KOLCON
    KOLCON --- ---
    SPIKE411: Jsem si ten fix samozřejmě taky ověřil, jen neřešil úplně root cause
    KRAMERIUS
    KRAMERIUS --- ---
    SPIKE411: Ano, PR který neprošel žádnými testy je opravdu AI slop.
    Ale na druhou stranu i tohle se u Ai agentů postupně mění - vidím rozdíly mezi stavem před půlrokem a dnes, Claude si u mě věci sám funkčně testuje, případně, pokud něco nemůže otestovat (credentials), požádá o otestování mě. Pro web aplikace si sám proaktivně stáhl playwright a pro reálné testy používá browser. Pro odchyt možných chyb používá také code review skill.
    Možná se to naučil jen u mě, že mu blbosti neprojdou a jinde se chová jinak :-D
    JARDABEREZA
    JARDABEREZA --- ---
    SPIKE411: Ano, ale já doufám, že tohle je jenom takové přechodné období. Tzn. Bude konsensus mezi vývojáři a vývojáři AI agentů, že tyhle opravy chyb musí mít jasný repro case, pokud je možný, a testy proti návratu chyby. S AI je ten extra krok lehčí než dřív. A kdo to nedodá, nebude brán vážně.

    A upřímně si myslím, že u nějakých menších projektů např. kolem 1000 - 5000 stažení týdně ten vývojář jako první stejně copy pastne ten problém do AI agenta a dostane z něj podobný slop pro začátek a pak na to naváže. Možná jeho vstupní prompt bude lepší s víc kontextem.

    U projektů s miliony stažení, kde se o každé řádce vedly hodinové diskuze, u síťových věcí, linuxového jádra, kryptografie apod. už ten benefit tolik nečekám.

    Větší potíž vidím s feature requesty. Kde autor se chce držet nějaké svojí vize a uživatelé řeší jenom svoje momentální potřeby.
    SPIKE411
    SPIKE411 --- ---
    KRAMERIUS: Ty jsi to řešení ověřil, že funguje (aspoň pro ten tvůj případ). Jedna z potíží jsou kobercové nálety pull requestů, kde se třeba ani nikdo neobtěžoval ověřit, že to funguje, nerozbije to testy apod.

    (Další jsou pak teda asi nějaké možné potíže z hlediska licencování kódu.))
    PJOTRIK
    PJOTRIK --- ---
    KRAMERIUS: troufam si rict ze komercni "tvurce co na zkoumani nema cas" neni totez, jako open source maintainer, kterymu na jeho projektu zalezi.
    Plus sam pises ze ti byl zpusob opravy jasny a asi jsi zkontroloval, ze to reseni dava smysl.
    KRAMERIUS
    KRAMERIUS --- ---
    PJOTRIK: Může to tak být, ale obecně to neplatí.
    Zrovna nedávno jsem dostal v práci za úkol vyřešit problém u naší prodávané služby/aplikace, kde se stávalo, že se Azure kontejner 1-2x za den restartoval, a tvůrce na zkoumání neměl čas.
    Stáhnul jsem si z gitu zdrojáky, popsal AI problém, za 15 minut jsem měl 4 možné příčiny. Přidal jsem AI přístup k logům toho kontejneru a potvrdila se jedna z těch příčin - způsob opravy jasný, také delegováno AI.
    Po nasazení opravy problém potvrzený jako vyřešený a ušetřena spousta času na studování detailů projektu.
    Díky AI znám příčinu, znám způsob vyřešení - dal bych to asi dohromady i bez AI, ale u cizího projektu určitě ne za 2 hodiny času.
    KLEINZACH
    KLEINZACH --- ---
    QWWERTY: aka ja jsem ted narazil na bug, takze i kdyz se v tom neorientuju, tak jsem ti zeslopil nejaky fix, protoze ti to urcite "pomuze"

    todle mi trosku pije krev, pac nam dali v korporatu AI jako mandatory reviewera (dokonce dva ruzny). takze ta zasrana vec se pousti do nachazeni chyb o ktery ho _nikdo nezadal_. a ja nemam na vyber - musim se tomu venovat, protoze mi to nepusti dal PR. tak dik.
    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
    QWWERTY
    QWWERTY --- ---
    KOLCON: a ted se na to podivej z pohledu maintainera
    - "na to abych ten kód studoval nemám čas a asi ani znalosti" - nemas know how na implementaci fixu a overeni, jestli ti z LLM nevypadla hovadina, ktera opravdu funguje spravne a neprinese dalsi problemy
    - "může být i správně a/nebo ušetřit čas při psaní správného"
      - palis cas maintainera, protoze review ciziho kodu je vzdycky kognitivne narocnejsi, nez kdyz si to pises sam from scratch a mas predstavu, jak a proc ta ten kod vznikl
      - nizsi barrier to entry - najednou maintainerovi neprijde na review 1-2 PR od uzivatelu, kteri meli know-how daneho jazyka a projektu, ale 100 PR plnych AI slopu od lidi kteri "to zkusili, protoze jim to LLM vygenerovalo"

    tzn. tam neni ani uspora prace, ani uspora casu. a vzhledem k tomu, ze spousta FOSS (obzvlast novych/minoritnich) jsou passion projekty par jedincu, kteri to delaji ve volnem case bez jakekoliv kompenzace, tak tim ze je utopis ve slopu, v nich tak akorat naprosto spolehlive zabijes zbytky nadseni a vule na tech vecech pracovat



    on to samozrejme neni problem jenom FOSS/SW vyvoje. obecne je tenhle pristup variace na
    The Problem with Unsolicited Advice: When Helping Isn’t Helpful
    https://www.oakandstonetherapy.com/blog/on-unsolicited-advice-and-unwanted-help
    unsolicited advice usually says more about the giver’s need to alleviate their own discomfort than it does about what the recipient actually needs
    aka ja jsem ted narazil na bug, takze i kdyz se v tom neorientuju, tak jsem ti zeslopil nejaky fix, protoze ti to urcite "pomuze"
    PJOTRIK
    PJOTRIK --- ---
    KOLCON: poslat AI PR ktery jsi dukladne neprostudoval je jako hodit kladu pod nohy, to fakt ne
    MARASAN
    MARASAN --- ---
    KOLCON: asi bych manualne otevrel issu, popsal bug a poznamenal, ze nabizim AI reseni. A pak jako 2. zaznam bych prihodil ten "AI slop".
    KOLCON
    KOLCON --- ---
    QWWERTY: Chápu. Otázkou je jestli je lepší když narazím na bug 1) nedělat nic, 2) otevřít jen issue nebo 3) poslat AI generováné PR které může být i správně a/nebo ušetřit čas při psaní správného? (na to abych ten kód studoval nemám čas a asi ani znalosti, nemůžu znát každý jazyk a studovat strukturu každého projektu, od toho mám AI)
    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 :)
    Kliknutím sem můžete změnit nastavení reklam