JANFROG: Měl jsem podobné uvažování. Dělám pluginy do Photoshopu. A oni fakt nemají dobrou dokumentaci. Prostě to pro ně není priorita. ...jenže když chceš obrázek, napíšeš AI co chceš a ona to udělá. Teď Omnigen umí chápat i textové úpravy typu: vymaž auto, přidej modré sluční brýle nejstarší osobě atd. Takže lidi možná nebudou potřebovat Photoshop. Adobe sice dělá svoji AI, ale je to teď extrémě konkurenční obor. Možná AI nebude nikdy umět pluginy do Photoshopu, ale může zničit trh a důvod, proč by je někdo chtěl :-D

ALMAD: Taky mě to občas trošku ruší... ale hlavně u psaní komentářů ke kodu. Protože tam píšu důvody proč to tam je. A ty důvody by člověk většinou nečekal. A nečeká je ani AI :-D Jednou jsem psal anglický komentář napíšu "ko" a AI hned "kokotina" :-D

JANFROG: Job safety by obscurity.

VDFLAT: Jinymi slovy, umi dobre to, co delaji mrte lidi. Veci co dela par lidi to neumi. To je super zprava, hned jsem vic v klidu...

FARIN: Jo podle me o tom je DRY, ne? Ze se pouziva tam kde _chces_, aby se zmena v implementaci zpropagovala do vsech mist, kde se to pouziva.

Podle kontextu to muze bejt hodne nebo malo :)

Co se tyce AI, tak ja s Erlangem narazim na naprostou neznalost. U prakticky jakyhokoliv dotazu odpovida AI (Gemini v1.5/v2 nebo ChatGPT) naprosty kokotiny. Asi je AI pouzitelny jen u mainstreamu.

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.