JARDABEREZA: ja si tech biasu jsem vedom. Moje zkusenosti s AI tooly jakozto cloveka, co pozoruje vyvoj od GPT2 (kdy s tim lidi tehdy zkouseli generovat Javascript):
- Copilot a Copilot Chat: celkem fajn na rutinni kod (doplnovani nebo generovani kostry projektu) nebo u nekterych jazyku / frameworku pomoc (dobry u Reactu apod., nic moc u SwiftUI)
- code rabbit na code review: nic extra, ale obcas fajn komenty na styl kodu (vic pocitovy/slozity veci, na ktere se linter da tezko nakonfigurovat)
- Copilot Workspace: asi jsem to blbe pouzival, ale selhalo to i u trivialnich tasku v netrivialni codebase: zkousel jsem treba "prejmenuj vsechny UPPERCASE promenny na namespace::lowecase" v projektu, kde je nekolik propojenych knihoven v ruznych jazycich a trochu slozity build proces; po asi 30-60 minutach pokecu s AI jsem to vzdal… vygenerovalo to PR, prejmenovalo asi 50% tech promennych, ale byla to namaha a dal to neslo. Kdybych to delal rucne, tak to mam tak do 10-15 minut max (kvuli netrivialni codebase to nejde udelat jednorazove v IDE). Junior programatorovi by to trvalo dyl, ale vysvetlovanim stravim 5 minut a muze pracovat nezavisle, nemusim hodinu aktivne vysvetlovat, jak tu zmenu ma provest.
A to nemluvim o vic komplexnich taskach, kde to bylo naprosto mimo (napr. chybu v kompilatoru okolo typecheckingu to navrhlo opravit v parseru).

Verim, ze do par let to zvladne solidne resit ty netrivialne trivialni tasky. Pro ty komplexnejsi by byl potreba naprosto jiny pristup a kognitivni prulom, protoze ten soucasny (chain-of-thought + chytre vyhledavani v codebase pro kontext atd.) vypada jako slepa ulicka, co se s vice daty / rychlejsimi procesory kvalitativne nezlepsi (jen to nefunkcni PR nebude trvat vygenerovat nekolik minut, ale treba nekolik sekund).

Plus ten rozdil, ze ten AI agent si neumi ten kod otestovat, uvazovat nad nim (napr. pustit UI aplikaci a naklikat v ni, ze ta zmena funguje), vyzaduje mnohem vic aktivni a delsi vysvetlovani nez prumerny junior (jelikoz clovek ma dalsi kontext v hlave / z okoli mimo ten task)… proto si myslim, ze to jen tak i juniory kompletne nenahradi.

Jinak ještě k DRY. Ono je rozdíl copy pastovat a inlinovat výpočetní funkce alá potřebuju z cesty extrahovat file extension, spočítat kořeny kvadratický mocniny apod. Prostě něco, co je daná logická operace a výsledek bude vždycky stejný. Tady kopie jen trochu nafukuje zdroják nic moc horšího se neděje.

A pak jsou věci jako třeba visuální komponenty, kde je účelný mít jednodtný vzhled a chovaná. Takhle jsme měli v jednom projektu rozkopírovaný určitě vic než 10x kód pro Modal dialog. Markup pro title, close button a css k tomu. A bylo to docela neškovný. A sjednotit se to nikomu dlouho nechtělo protože ten copy paste nebyl jen copy paste, ale občas v tom byla nějaký změna. Příliš komplikovaný to řešit v rámci tasku a sahat na různý místa v aplikaci co potřeboval další modal. Takže ho člověk zase zkopíroval :)

Když to tady probíráte, tak já si teda Copilota nemůžu vynachválit. Dělám primárně Python, kde Copilot výrazně usnadňuje takový nějaký prototypování (vhodně pojmenuju funkci a on ji prostě vymyslí), případně refactoring, různý mechanický činnosti (třeba nejaký enumy - začnu, napíšu první dvě položky a on vygeneruje zbytek), dobře mu jde naopak i dokumentace už existujícího kódu i překlady v .po souborech...

Je toho dost, ale snažím se ho usměrňovat i opravovat, on se z toho poučí a pak na konkrétním projektu funguje líp a líp. Plus celkem fajn funguje na různých konfigurákách, to jsem byl docela překvapenej a hodně to používám. Kdo si má všechny ty opšny pamatovat :-)

Takže za mě dobrý pomocník, jo a máme nějakou takovou tu placenou verzi.

JARDABEREZA: když vís co chceš psát tak je to super a zrychluje to práci. V tohle má junior trochu nevýhodu.

Já nevím co s tím děláte vy, ale mě mě to na kontrolu vstupních parametrů nebo psaní chybových hlášek funguje dobře. U těch 1-3 řádkových věcí to často doplní stejnou věc, co bych dělal já. Občas i lepší. A když ne... stejně to píšu ručně, tak to dopíšu.

Zrovna včera jsem si třeba říkal: "To je blbost v tom CLI argumentu přeci musí být mezera, je to typo, dám jí tam". No a nebylo, když jsem jí smazal tak to začalo fungovat :-D

Na React a Redux mi to přijde dost dobrý... těch patternů je plný GitHub.

Ale třeba UXP je bída... Adobe k tomu nenapsalo ani pořádnou dokumentaci a fora jsou plná otázek, kde se ptají proč tenhle kod nefunguje, ale správných odpovědí je méně :-D

A jako někdo, kdo nikdy nedělal s C++ to bylo super. Potřeboval jsem jenom poslepovat pár hotových knihoven dohromady a ušetřilo mi to hodiny/dny času. Např. co kde nastavit ve Visual Studiu atd.

JARDABEREZA:

No zrovna u těch programovacích asistentů to je spíš vývoj od "wow" k "to jsem rád, že za tenhle shit platí fabrika a ne já".

LUDWIG_: Ono je to strašně zrádné ty odhady. Lidi jsou naučení posuzovat pokrok lineárně. Když dneska postavím jeden metr zdi, tak zítra to jsou dva metry, za týden 7, a za měsíc 30 metrů. Ale v technologiích jde vývoj spíše exponenciálně než lineárně.

Tři roky zpět jsem generoval první obrázky ve Stable Diffusion 1.0 a ty lidi vypadali většinou jako mutanti a nízký rolišení. Fakt špatný. Pak jsme s smáli, že mají deformované končetiny. Potom prsty a text. A dneska to kolikrát člověk nepozná jestli to je fotka nebo ne.

To samé pozoruji u videí. 2025 bude pro filmaře hodně zajímavý. To co tenhle týden ukazuje Sora jsem čekal o pár let později.

JARDABEREZA:
To jsou dve otazky: s tim videem ohledne problemu soucasnych abstrakci v programovani souhlasim. Odkazovany https://dl.acm.org/doi/abs/10.1145/3563836.3568723 je docela zajimavy smer.

Ohledne toho, jestli AI nahradi programatory: Pred 1-2 lety bych rekl, ze do par let mozna tak juniory. Po tom, co jsem zkousel
https://githubnext.com/projects/copilot-workspace ,
mohu rict, ze i junior programatori muzou byt v dohledne dobe v klidu :)

VOY: Jo jo, ja mam soukromy projekt "copycat" kde mam presne ty ruzne kousky (nekdy i cele tridy) co pak nekam jen pastnu a mam vymalovano :-)

VOY: jj, duplicitni kod nemusi byt nutne zlo; v linux kernelu taky je.
Pamatuji si, ze byly studie ohledne dopadu duplicitniho kodu jako https://dl.acm.org/doi/10.1155/2012/938296

Muze se treba stat, ze je duplicitni kod v ruznych castech slozity codebase; za pul roku je potreba zmenit neco v jedne casti a paradoxne muze byt jednodusi zmenit duplicitni kod v jedny casti, nez kdyby se to menilo v abstrahovany spolecny casti, co pak bude muset pokryvat ty budouci zmeny specificke pro nesouvisejici casti systemu.

Tim neobhajuji duplicitni kod jako takovy; v hodne pripadech je to spis prasarna a usetri cas to sloucit. Jen rikam, ze jsou vyjimky ci je to pripad od pripadu.

AMBIENTIUM: a bit of copy paste is sometimes better than a lot of dependency.

AMBIENTIUM: Videl bych tam urcitou miru volnosti. Proste uz tolik neziju nabozenstvim toho, ze zadny blok kodu se nesmi opakovat a vsechno musi byt odabstrahovany. Nekdy se to lip cte kdyz to tam proste inlinujes. To je taky hodnota. Zvlast ted s LLM bude, myslim si, mozny si v tomhle vic dovolit. Your mileage may vary.

VOY: Není spíš smysluplný porušit dry jen v momentě, kdy nechceš, aby ty dva kódy byly závislý na tom společným a byly upravovatelný a rozšiřitelný nezávisle na sobě?

Zaroven si uz taky uplne nemyslim, ze vsechno musi byt DRY. Nekdy je proste lepsi se radeji opakovat nez furt neco zobecnovat a abstrahovat.

TOOMIX: I to ovsem stoji na to, ze se tam kazdy podiva a vi o tom. To je proste uskali toho, ze mas na neco nejaky vylesteny tridy a helpery, musis mit tym kde je dobra komunikace a vsichni to vedou v patrnosti. Nevim o nastroji nebo metode co by tohle dovedla vynutit.