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?

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..

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.

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.

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

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.))

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.

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.

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.

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

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"

KOLCON: poslat AI PR ktery jsi dukladne neprostudoval je jako hodit kladu pod nohy, to fakt ne

KOLCON: asi bych manualne otevrel issu, popsal bug a poznamenal, ze nabizim AI reseni. A pak jako 2. zaznam bych prihodil ten "AI slop".