• ú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í
    ALMAD
    ALMAD --- ---
    JANFROG: “ Co je bude motivovat v te praci?”

    Lidi si holt malo pamatujou casy, kdy na “seriozni praci” bylo uznatelny pouzivat jenom nejakej closed source compiler ke kterymu sis musel koupit dokumentaci a zaplatit tejdenni skoleni, a na seriozni ukladani dat platit licenci per procesor na serveru kde se muselo klikat.

    A pak jsou taky takovi, co si ty casy pamatujou a chtej aby se vratily…
    JARDABEREZA
    JARDABEREZA --- ---
    JANFROG: V tom případě uznávám, že se oba bavíme o něčem jiném. Já se v rámci svých zájmů spíše setkávám s tím případem "projekt s veřejným kódem". A dává smysl s oběma přístupy zacházet rozdílně.
    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?
    E2E4
    E2E4 --- ---
    obecně.. ono s tím AI je to složitý.. záleží jak kvalitní AI se použije, jak kvalitní je zadání a jestli se vůbec AI pro danou věc hodí.

    Ale je dost lidí, který jsou v poloze "když nevíš co, použij AI" a nedohlédnou důsledků..

    pak jsou tu ti co to řídí - vrcholový vedení žije v pohádce, jak AI všechno vyřeší. na střední je tlak používat AI zeshora a "měřitelný" výsledky. technický dluh neřešil nikdo nikdy, teď je to s AI jako force multiplierem. hlavně je potřeba deliverovat, nyní díky AI 10x rychleji.

    pak je tu hranice, kdy AI už nestačí na to co sama vygenerovala, ať už se se v kódu přestane orientovat, nebo že high-level design byl špatný a ukáže se, že to není opravitelný.

    do toho drobný problémy typu Opus v klidu vytvoří 10k znaků regex nebo přesto, že si napsal test, kód ve skutečnosti race condition neřeší.

    nebo "jejky vím že jsi mi říkal ať nedeplojuju ale deploynul jsem". overthinking a neužitečná složitost.

    plus se to celý posouvá a zlepšuje, iluze "teď už AI programovat umí", přitom ten pokrok jen posouva hranici, od který to už nejde, takže se AI používá na čím dál složitější věci a naráží na všechny ty problemy výše..
    AXTHEB
    AXTHEB --- ---
    MUXX: A teď si ven, že tohle byl před půl rokem, rokem vlastně absolutní peak. Ten pokrok je neuvěřitelnej.
    E2E4
    E2E4 --- ---
    SUCHRE: mění se to za pochodu, no... ale regrese se dají dost slušně mitigovat testy..
    E2E4
    E2E4 --- ---
    KRAMERIUS: jenže tohle je jiná situace, ten proces tvorby open-source je založený na osobních příspěvcích s jejich ručním vyhodnocení. dřív to bylo tak, že někdo kdo byl schopnej prospět přispíval aspoň nějakou kvalitou.

    teď jsou maintineri zahlcení AI příspěvky lidí co si to chtějí dát do životopisu, jaký jsou velký open source přispěvatelé. těch může být menšina, AI slop PR spam může dělat každý.. Eternal slopember.
    SUCHRE
    SUCHRE --- ---
    Nevim, jestli je to jen subjektivni dojem, ale zda se mi, ze doslo tak pred mesicem az mesicem a pul k nejaky zmene ve Fable 5 a generuje mi ted vic kodu, kde dost halucinuje - a hlavne mam regresni bugy.
    MUXX
    MUXX --- ---
    Ja mam jedno repo, ktere je hromada starych skriptu co kdysi dali dohromady sysadmini jako copy pasta internet + vlastni neprogramatorska invence, zadna dokumentace. Tam teda claude pridava kod ve stejnym stylu jako uz tam je. Zadna struktura, zadny testovani. To me dycky pobavi co z toho vyleze. Az tam jsem pochopil co je to ten AI slop.
    JARDABEREZA
    JARDABEREZA --- ---
    KRAMERIUS: U mě si po každé změně dělá build projektu a pak si ještě spustí testy. Posledních pár dní to Sonnet 5.0 nevynechal snad ani jednou :-D
    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?
    Kliknutím sem můžete změnit nastavení reklam