Názory k článku AI asistenti pro vývoj software: postupy vhodné pro programátory
-
v praci nas tlaci do pouziti agenta copilota na reseni uloh a taky na code review.
je pekne, ze opravdu sam vyresil zadanou ulohu, ale pritom si vsimnul nemeckych komentaru v kodu a zacal kazit prehlaskovane znaky :-)takze bez kontroly nejde nechat agenta, aby menil kod a nikdo to nehlidal.
takze zatim je to tak, ze senior musi prekontrolovat vysledek od ai, ktery pise jako medior.na co se mi to opravdu osvedcilo je psani nudnych parseru pro json, kdy jen zadam vstup a chci kod pro nasypani dat do struktur, to mu jde dobre.
takze beru to, je to pokrok, ale nevim, jestli ta energie, vyrobni procesy apod. za to stoji,
jestli lidsky junior neni levnejsi. -
Oni jsou to výkonné nástroje, když s dobře použijí. Jenom je potřeba nepodlehnout iluzi, že je to inteligentní to je, alespoň za mě, hlavní příčina problémů.
Mimochodem to nasazení v práci, máme tak korporátně hyperkorektní verzi, že na některých částech projektu zůstane půlka odpovědí nedokončených a druhá chcípne komplet. Tahle knihovna je fujky s tou se nebavím; jsou to sice signály, ale co kdyby někde vypadla nějaká písmenka, hned by to mohlo být něco ošklivého neee.
-
Velice zajímavé a aktuální téma.
Integrovaný AI v IDE (IntelliJ + copilot) mi nějak nevyhovuje, není tam historie sešen, ve kterých se dá dále pokračovat (IMO velice užitečné). Zatím jsem skončil u klasického github copilotu (pouze GPT 5 mi přišel dostatečně použitelný). Má spoustu much, ale docela pěkně vytahuje snippety do samostatného okna.
Mám skript, který přes inotify monitoruje změny v adresáři a následně concatuje všechny jeho soubory do společného souboru all.txt. Takže ten je vždy aktuální, po jakékoliv změně v editoru IDE. Takže stačí jej přes web copilotu nahrát, což už se (trochu) dá.
Změny generuji téměř vždy tak, že explicitně chci, aby vygeneroval celý soubor, ponechal stávající komentáře a udělal jen nezbytně nutné změny. Samozřejmě je dobré mít soubory malé, i z jiných důvodů, ale to např. v javě/androidu nebývá problém. Soubor zkopíruji do schránky a v IDE dám "diff with clipboard". GPT5 to dává překvapivě dobře včetně bílých znaků, defakto vždy jsou tam jen nutné změny.
Nenašel jsem cestu, jak by model uměl generovat spolehlivé diffy - správná čísla řádků prostě nedává ani GPT5 a zrovna diff v IntelliJ je na ně velice citlivý (viz mnou nedokončená diskuse https://intellij-support.jetbrains.com/hc/en-us/community/posts/28680995778450-Format-of-diff-patch-to-be-accepted-by-the-Git-Patch-Apply-patch-from-clipboard?page=1#community_comment_28705975368978 )
Samozřejmě je potřeba pravidelně dávat novou sešnu - ze jedné sešny vyleze jeden, max. dva tři (maličké) commity.
Moc rád si přečtu praktické zkušenosti, IMO je to pro všechny vývojáře velice aktuální.
13. 11. 2025, 08:14 editováno autorem komentáře
-
Jan HrachStříbrný podporovatel> Nenašel jsem cestu, jak by model uměl generovat spolehlivé diffy - správná čísla řádků prostě nedává ani GPT5
Pokud vím, tak se nikde nepoužívají čísla řádků, ale unikátní kontext. Viz třeba odkazovaný FileEditTool z Claude Code:
The tool will replace ONE occurrence of old_string with new_string in the specified file.
CRITICAL REQUIREMENTS FOR USING THIS TOOL:
- 1. UNIQUENESS: The old_string MUST uniquely identify the specific instance you want to change. This means
- Include AT LEAST 3-5 lines of context BEFORE the change point
- Include AT LEAST 3-5 lines of context AFTER the change point
- Include all whitespace, indentation, and surrounding code exactly as it appears in the file
- 2. SINGLE INSTANCE: This tool can only change ONE instance at a time. If you need to change multiple instances
- Make separate calls to this tool for each instance
- Each call must uniquely identify its specific instance using extensive context
- 3. VERIFICATION: Before using this tool
- Check how many instances of the target text exist in the file
- If multiple instances exist, gather enough context to uniquely identify each one
- Plan separate tool calls for each instance
- WARNING: If you do not follow these requirements
- The tool will fail if old_string matches multiple locations
- The tool will fail if old_string doesn't match exactly (including whitespace)
- You may change the wrong instance if you don't include enough context
-
Čísla řádků (rozsah řádků uvedený v tom řádku popisujícím chunk) obecně nejsou povinná, ale IntelliJ mi diffy bez toho nebrala. Pokud byly v rozsahu řádků chyby, potichu kusy chunků při patchování zahazovala. Vysvětluji v https://intellij-support.jetbrains.com/hc/en-us/community/posts/28680995778450-Format-of-diff-patch-to-be-accepted-by-the-Git-Patch-Apply-patch-from-clipboard?page=1#community_comment_28705975368978 , kde se ptám, zda lze právě do IntelliJ dodělat podporu chunků bez přesných čísel řádků.
-
Pavel TišnovskýZlatý podporovatelPár postřehů z oblasti, která se snaží být "AI first":
- klade to obrovské nároky na člověka, který dělá review (a gating). Toto není dobré podceňovat, protože jinak bude z projektu za pár měsíců naprostej hnůj, kterému nikdo nebude rozumět.
- snad ještě větší nároky to klade na toho vývojáře, který dělá PR (změny). Musí nebo by si měl uvědomit, že by měl odevzdat kvalitní PR, je to jeho práce, za to je placenej, nakonec je to i jeho vizitka. Hodně často se lidi nechávají unést a posílají strašný borčus s tím, že to jede, tak jako co je zaproblém (a to jsme u bodu jedna). A ještě je to chápáno jako vysoká produktivita.
- spíš osobní názor: mnohem líp se mi píše/upravuje kód, než čte kód někoho jiného. S AI nástroji se to hodně posouvá do té druhé oblasti.
- taky je dobré se zamyslet nad autorským zákoníkem atd. atd. Toto je dost neprobádaná oblast, ale vůbec bych se nedivil, kdyby se začaly objevovat žaloby z různých stran (takže vývojář by měl používat "posvěcené" nástroje a ne cokoli se na webu namane).
[tyjo dneska jsem nějak pesimistický, nechci kazit nadšení, ale...]
-
Nekazíte nadšení; to je naprosto aktuální problematika na řadě projektů.
Ještě bych k tomu doplnil, že ten vývojář nejenže by měl odevzdat kvalitní PR, ale taky by měl rozumět, co ten kód vlastně dělá. Vypadá to jako naprostá samozřejmost ale právě s AI se ukazuje, že to samozřejmost není. Z AI jsou v mém okolí zcela zcela typicky nejnadšenější buď lidé, co v životě nic nevyvíjeli nebo lidé, co -- diplomaticky řečeno -- nejsou jako vývojáří žádná světla. Ti druzí si u toho neuvědomují, že pokud AI má ambice někoho nahradit, tak samozřejmě jako první právě je. Ale to je jiná věc.
A u juniorů to dnes už vůbec není samozřejmost. Kolega -- co se, mimochodem AI zabývá -- teď dělal řadu pohovorů a ukázalo se, že skoro všichni se snaží používat AI a většina z těch lidí vůbec nerozumí tomu, co z ní padá ven natož aby to byli schopni sami napsat nebo nedejbože spravovat. A je to masový jev.
-
Pavel TišnovskýZlatý podporovatel
to je pravda. Dostával jsem od jednoho juniora PR - relativně dobrej kód se spoustou unit testů. A asi po měsíci se mě ptal, co jsou to mocky a jak se používají. Jsem mu říkal, že v jeho PR jich má napsaných asi sto :-)
-
že to takhle dopadne bylo jasné už před 3 roky - je to další z mnoha technologií, které mají zvyšovat produktivitu - nicméně neřeší primární problém, což je komplexita IT technologií. Myslet si, že AI pomůže s naučením čehokoliv - a) minimum lidí jede v učícím se módu - viz SQL buildery po Stack overflow, b) při výuce je potřeba znalosti podat ve správném pořadí a správném důrazu, c) bez lidského mentora AI pořád generuje příliš mnoho halucinací d) na výuku potřebujete čas, který v praxi mít nebudete - tuplem, když se budete snažit fixovat problém, kterému nerozumíte.
V podstatě to bude jenom horší. Nutíme lidi skákat do čím dál tím víc rozjetého vlaku.
-
Dneska se ti na pozici vyvojare prihlasi clovek, ktery nechape zakladni techniky lilbovolnyho kodu. Napriklad netusi co je to smycka a k cemu je to dobre.
A co se AI tyce, je to cca mesic co prisel zakaznikovi uchazec, a prvni cim se chlubil bylo, ze nepotrebuje aby ho nekdo zaskolil, ze na vse pouziva AI. Tak mu bylo receno, ze v tom pripade bude AI levnejsi nez on, a ze ho firma nepotrebuje.
-
Myslel jsem, že tato doba pominula. U pohovorů dávno nejsem, ale nezapomenu na chudák ženskou, která se po dlouhé mateřské někdy v roce 1998 chtěla vrátit do "oboru". Předtím pracovala jako obsluha sálového počítače. Hlásila se na pozici (tehdy se tomu tak říkalo) samostatný programátor - analytik v C. Nebyla schopna popsat algoritmus nalezení největšího čísla v posloupnosti, ne tak ještě napsat nějaký kód. (K největšímu číslu jsme dospěli nějak tak, že jsem chtěl kód v C pro seřazení, pak kód v C pro nalezení největšího, pak aspoň popis algoritmu. Nikde nic.) Nakonec se ještě rozčilovala, že bychom chtěli, aby uměla "všechno" už při nástupu. Až mi jí bylo líto. (Nevzali jsme ji.)
-
ženské po mateřské jsou kapitola sama pro sebe, zrovna tenhle týden jsem vysvětloval jedné (pracuje ve vývoji SW) po 8mi letech mateřské jak se zruší schůzka v kalednáři, bohužel návrat po tak dlouhé době je pro ně dost drsný a záleží na firmě, jak se k tomu postaví, u nás se snaží o začlenění, ale je to těžký pro všechny
-
Zatím se mi ovědčily dvě uplatnění kde mě LLM neirituje.
- Tvorba scaffoldingu. Když třeba píšu API service, mám už pár existujících endpointů a chci napsat další které budou sledovat stejné schéma, nechat si napsat jejich kostru a vygenerovat testovací requesty pro HTTP client v Jetbrains IDE je fajn, a zkontrolovat že je výsledek správně jde jen přelétnutím očima
- chytřejší autocomplete. Občas mi to už při psaní doplní zbytek řádky kterou stejně plánuju napsat, tam ten overhead kontroly generovaného kódu není nijak velkýPlný vibe coding přes agenty je spíš bolest a bere mi radost z práce.
-
Já je používám pro generování unit testů. Dokáže efektivně a rychle odhalit a pokrýt edge casy, navíc je to práce, která vyžaduje dost odlišný mindset od běžného vývoje (čili se mentálně úplně přepnout), je monotónní, zdlouhavá a naprosto nezáživná. AI v tom zdaleka není dokonalá ale vyhrává to, že je pořád méně nepříjemná, než psaní těch testů jako takových.
Vibe coding je skvělý na prototypy nebo na aplikace malého rozsahu, které neplánujete nějak podstatně udržovat. Skripty, malé tooly s UI i bez a podobně. Takhle jsem si tu doslova za hodinu vyrobil lepší ekvivalent textového prohlížeče souborů z Double Commanderu napsaný v Pythonu a GTK. Stál v tokenech asi tři dolary. Funguje, dělá to, co chci, kód je strašný ale vzhledem k tomu, k čemu je to je naprosto jedno. Tvořit takhle velké projekty bych ale fakt nechtěl. To je to, čeho se obávám víc, než že mě AI nahradí: tohle jednoduše není práce, ani výsledky, kterou bych chtěl dělat a které bych chtěl odvádět a proč jsem do IT přišel.
Už tak stačí, že se ten obor za posledních patnáct let lidsky poměrně dost proměnil a natáhla se do něj postupně spousta lidí, co mají dojem, že rozumí všemu, reálně toho neumí mnoho ale všude byli, od všeho mají klíče a masírují si hlavně vlastní ego. To dřív tolik nebývalo. A AI to ještě akceleruje.
-
Já je používám pro generování unit testů. Dokáže efektivně a rychle odhalit a pokrýt edge casy, navíc je to práce, která vyžaduje dost odlišný mindset od běžného vývoje (čili se mentálně úplně přepnout), je monotónní, zdlouhavá a naprosto nezáživná. AI v tom zdaleka není dokonalá ale vyhrává to, že je pořád méně nepříjemná, než psaní těch testů jako takových.
Tak tohle mi přijde naprosto šílený a výsledek je kolikrát stejný, jako kdyby tam testy nebyli. Fakt miluji procházet mraky testů co někdo vygeneroval a ani nezkontroloval a pak přemýšlet proč zrovna tenhle test padá a co tím autor myslel. Mě psaní testu přijde hodně důležité a to z několika důvodů: 1. člověk si ověří při psaní zda to dobře navrhnul a často zjistí, že by struktura chtěla upravit. 2. Si při tom může zaprogramovat, protože často implementace je třeba pár řádků, ale vymyslet a realizovat jak to rozumně otestovat již jiná věc. 3. Test by měl být udělaný tak, aby šel udržovat. Tim že na hrubou sílu nechám vygenerovat desítky testů tomu fakt nepomáhá.
13. 11. 2025, 22:17 editováno autorem komentáře
-
Pokud něco generujete AI a důkladně to neprojdete, jste pitomec. To je přece samozřejmost, ne? Ani mě to nenapadlo zmiňovat. Nemluvě o tom, že na řadě projektů je druhou alternativou tam ty testy nemít vůbec protože by vám je nikdo nezaplatil.
Já tedy nic podobného nezjišťuji; maximálně tak, že netestovatelný je celý návrh. Jestli to zjistíte až při psaní testů, děláte něco špatně. Ne, při testech si opravdu nezaprogramuji. Je to neuvěřitelně monotónní práce, z jejíhož vysledku radost opravdu nemám. A unit testy mají testovat malé jednotky kódu. Což je zrovna to, co AI dovede vytvořit spravovatelné a v rozumné kvalitě. Pokud nikoliv, je to zase vaše chyba. Ať už tak, že testujete něco, co nemáte nebo tak, že jste to vy nechal složité.
Takže mně zase přijde trochu šílený to, co píšete.
14. 11. 2025, 10:05 editováno autorem komentáře
-
Pokud něco generujete AI a důkladně to neprojdete, jste pitomec.
Já ne, ale je spousta lidí to takhle normálně dělá, navíc se k tomu ani nepřizná.Nemluvě o tom, že na řadě projektů je druhou alternativou tam ty testy nemít vůbec protože by vám je nikdo nezaplatil.
Jo tohle už jsem několikrát slyšel (u pohovorů), že mu ty testy nikdo nezaplatí (a nebudu ani zmiňovat co za typ lidí tohle říkal). Stejně jako vám nezaplatí spoustu věcí a děláte je např. mezery, komentáře, sestavení, nasazení atp. Je to jenom výmluva jak to celé ojebat nic víc nic míň. A jestli si mám vybrat mezi tam testy nemít nebo tam mít kupu nagenerovaného hnoje, který často nemusí být ani správný tak varianta bez testů je mnohem lepší, aspoň mi nedává falšený pocit, že to mám nějak otestované.Já tedy nic podobného nezjišťuji; maximálně tak, že netestovatelný je celý návrh. Jestli to zjistíte až při psaní testů, děláte něco špatně. Ne, při testech si opravdu nezaprogramuji. Je to neuvěřitelně monotónní práce, z jejíhož vysledku radost opravdu nemám.
Tohle je fakt komický. Už jenom ten přístup k tomu, že to je otrava ukazuje, že to naprosto nechápete. Jestli jste nikdy během testů nezjistil, že je něco blbě nebo by mohlo být mnohem lépe, tak gratuluji, ale z vašeho přístupu bych spíš řekl, že jste se na ty testy normálně vybodnul. Pak je jasné, že se vám to nestane. Ono totiž už ty testy by měli být součástí toho návrhu.A unit testy mají testovat malé jednotky kódu. Což je zrovna to, co AI dovede vytvořit spravovatelné a v rozumné kvalitě. Pokud nikoliv, je to zase vaše chyba. Ať už tak, že testujete něco, co nemáte nebo tak, že jste to vy nechal složité.
Jenže všechno nejsou jenom unit testy. Např. integrační jsou stejně důležité. Často teď vidím, že nad tím lidi ani nepřemýšlí a místo toho aby udělali test parametrizovaný, tak jim AI vygenruje ty testy pro každý case, se stejným kódem a lišící se jenom v jednom parametru. -
Příteli, vývoj platí ten, kdo vývoj projektu objednává a vede. I kdybych se stavěl na hlavu a chodil po uších, prostě by mi třeba na projektu, na kterém jsem několik let pracoval peníze na testy nikdo nedal. A ani ne tak proto, že by nechtěl. Ale prostě ty peníze neměl. Je úplně irelevantní co si o tom myslíte. A je dokonce úplně irelevantní, co jsem si o tom myslel a myslím já. A takových projektů jsou spousty. A stejně, jako evidentně nemáte představu o časté praxi, nemáte ani představu o tom, co AI co se testů týká vygenerovat dovede či nedovede. Což je typické.
Co chápu a nechápu naprosto nesouvisí s tím, co je a není otrava. To je další vaše kombinace sebestřednosti, arogance a demagogie. Dělám v životě spousty věcí, které jsou nutné ale jsou otrava. Ne, opravdu nepíšu testy s nadšením a je úplně jedno, co by mělo nebo nemělo být součástí návrhu. To je krásná teorie, která je automagicky pravdivá ale jaksi odtržená od podstatně zelenější praxe. Vy jste obecně takový teoretik, toho už jsem si všiml mnohokrát.
A co se týká typu testů, myslím celou dobu unit testy. Je to napsáno hned v prvním nebo druhém příspěvku v první větě.
-
Šokující novinka nikdo ti nikdy peníze explicitně na unit testy nedá. Nemít testy kvůli tomu, že ti na to někdo nedal explicitně peníze je jenom obyčejná výmluva. Psaní testů je prostě součást vývoje a jestli to někdo nedělá, tak to prostě ojebává. Fakt miluji když musím řešit, že má nějaký projekt problémy a zjistím, že nemají vůbec žádné testy. Pak začne kolečko, kdy začnou tvrdit, že na to nebyl čas a peníze a že dodělat to v současné situaci by bylo na dlouho. Takže se nic neušetřilo, jenom se problém posunul do budoucna a snad i na někoho jiného. Tímhle se liší senioři od juniorů, protože senior už si tímhle jednou prošel a je si toho dobře vědom. Jak by se vám líbilo kdyby vám např. u auta vyměnili kola a nezkontroloval, že jsou všechny šrouby dotažené a klidně se vsadím, že za to taky nikdo explicitně neplatí.
Představu jak vygenerované testy vypadají mám velmi dobrou, protože 1. to taky využívám a 2. spousta lidí najednou v posledním roce začalo psát hromadu testů i když to posledních několik let nedělali a nechali se za to při review buzerovat.
-
Humanoid č. 1264054 - poruchovýBronzový podporovatel
Já se musím kolegy zastat, protože jsem z oblasti "levně a ještě levněji", a tam není prostor ani na testy, ani na jakékoli chyby. Na vývoj je takový předepsaný rozpočet, že to prostě musíš napsat správně, rychle a na první dobrou. Když už si napíšu test, tak jde o nějakou kritickou sekci, která by to "levně a ještě levněji" dost prodražila, vše ostatní prostě musíš psát bez chyb. Tak to v této oblasti prostě chodí.
-
Pokud je to tvoje firma, tak to asi jde ještě pochopit - prostě honba za ziskem za každou cenu (myslím si o to své, ale pochopit se to dá).
Ale jako zaměstnanec bych se takto o******t nenechal, zaprvé to není profesionální, zadruhé snad máš nějaký zásady i trošku rovnou páteř ne?
Za třetí na první dobrou stejně nikdo nic nenapíše, pokud nejsi superčlověk (a potom se tedy vracíme k bodu dva - proč se nechat takto křivit kvůli ziskům někoho jiného?)
-
Humanoid č. 1264054 - poruchovýBronzový podporovatel
O honbě za ziskem se rozhodně mluvit nedá. Prostě jsou i chudší zákazníci, kteří potřebují jít trochu s dobou, a chudší kraje, ČR není jen Praha. Tak to prostě řeším(e) levně, rychle, bez chyb. Jo, chyby se dělají, ale jdeme tomu trochu naproti i výběrem nástrojů a postupů spíš než zpětným testováním, takhle nějak bych to popsal (je to jako si vybrat Rust spíš než Céčko, když s oběma splníte zadání ve stejném čase, ale první z principu brání dělat určitý typ chyb, pokud od něj nepotřebujete nic vyloženě za hranicí "safe". To je jen takový příklad, protože téma Rust vs. C je tu takový pěkný kolorit:-) ).
15. 11. 2025, 11:08 editováno autorem komentáře
-
Páteř? Pokud mi někdo zaplatí to, co za svůj čas požaduji, udělám mu v rámci vývoje to, co požaduje on potud, pokud je to legální. Takhle jednoduché to je. Neprofesionální je vymýšlet si dodatečné podmínky. Nechce testy? Nebude mít testy. Chce testy? Bude mít testy. Je to jeho odpovědnost, nikoliv moje, spolupráce je tak nastavená, za svůj osud je odpovědný on. Odemne se dozví názor pokud ho je ochoten slyšet, rozhodnutí je na něm.
Samozřejmě, že bych se mohl tvářit děsně odpovědně a řešit, jaké morální, filozofické a technické ohledy v rámci dějin světa a vesmíru to, co chce nebo nechce má. Ale přesně proto nedodávám žádná ucelená řešení a nepodnikám v tom projektovém smyslu. Aby mi tohle mohlo být úplně jedno.
16. 11. 2025, 15:22 editováno autorem komentáře
-
Nechce testy? Nebude mít testy.
Nechce validaci vstupu („co to je?“), tak ji mít nebude atd. :-) Máte celkem kliku, že (patrně) nedodáváte soukromým osobám, protože tam byste se z té odpovědnosti, tak lehce nevyvlíknul.
Ale jinak souhlasím, že na trhu je místo i pro obkladače, který ty dlaždičky oštípe a nalepí křivě :-)
-
Pokud mi výslovně sdělí, že ji nechce, mít ji nebude. Co vás na tom překvapuje? Běžně zákazníkům zdarma poskytujete na vlastní náklady to, co výslovně nechtějí? Když bude výslovně chtít naštípat dlaždičky špatně a nalepit je křivě, klidně mu to udělám.
Naštěstí ta nestojí tolik a i dost nesoudný člověk chápe, že potřeba je.
17. 11. 2025, 11:08 editováno autorem komentáře
-
DannyStříbrný podporovatelTesty nedelate pro zakaznika, testy delate pro sebe. Abyste vedel, ze to co jste vypotil opravdu dela to co ma - a to i behem ruznych naslednych zmen. No a nebo to holt delate systemem, ze ochotne dodavate zmetky a nasledne si mastite si kapsu na jejich opravach :)
-
To snad není možný. Vsadím se, že máte buď smlouvu o dílo nebo na vývoj. Ty testy neuděláte pro zákazníka, ale pro sebe. Je to podpůrný nástroj pro vývoj. Ale to bych čekal, že by měl vývojář vědět (ale pokud někdo tvrdí takové nesmysly, tak nevím jak ho nazvat).
Neřekl vám náhodou zákazník, že nechce testing resp. spíš myšleno jako QA? Ale to je úplně jiná disciplína než vývoj. Často se navíc dělá, že vývoj a QA dělá jiná firma (a dává to smysl).
Prosím hlavně už nikde veřejně nevykládejte, že vám zákazník zakazuje psát unit testy, protože se tím neskutečně ztrapňujete, protože každému zkušenému vývojáři je jasné, že je to jenom výmluva. Jestli chcete vyprávět pohádku jaký jste borec, že vše napíšete správně napoprvé bez testů, což určitě není pravda, tak to hlavně prosím nevykládejte začátečníkům. -
Trapný jste ledatak vy s tím blábolením. Ano, jeden třeba výslovně zakazuje. Protože na to prostě nemá. Představte si, že kdybychom třeba na tomhle jeho projektu psali testy, ten projekt už dnes dávno neexistuje. Ale pokrytcům a teoretikům jako vy, co to navíc ještě neplatí tohle vůbec nemá cenu psát :-D
Tak to prostě je. Co si o tom myslíte je naprosto irelevantní. A jak jsem psal, i co si o tom myslím já.
19. 11. 2025, 15:38 editováno autorem komentáře
-
Humanoid č. 1264054 - poruchovýBronzový podporovatel
No jo, vytrhávání z kontextu...
V sektoru "levně a ještě levněji", o kterém píšu, pochopitelně neřešíme složité algoritmické úlohy, jako pan Satai Nekola. Takže to, co platí pro tuto oblast, pochopitelně neplatí pro celek. Chtěl jsem jen podpořit názor předřečníka a přinést na světlo zdejším odborníkům (to je bez ironie, skutečně jsou tu jména, která jsou pojmem) i praktiky ze suterénu. -
Ondra Satai NekolaZlatý podporovatelMy vime, ze v nekterych pajzlech si kuchar nemyje ruce, jen je dobre k tomu napsat, jak moc se pak po...
-
Humanoid č. 1264054 - poruchovýBronzový podporovatel
Kuchaře nemáme, máme operátora výrobní linky smažáků, který má gumové rukavice a na hlavě síťku. Problémům předcházíme už v architektuře.
-
Chápu, že to nemilujete. Já to také nemiluji. Ale to vůbec nic nemění na té praxi. Když někdo peníze nemá (nebo nechce mít), tak vám to prostě nezaplatí. A charita nejsem. Jak jsem psal, co si o tom myslíte vy nebo já je úplně jedno. Nakonec vždycky rozhoduje ten, kdo to celé platí.
A ne, není to výmluva. Charita prostě nejsem. A vy také ne. To je jen vaše teoretizování a pokrytecké řeči.
16. 11. 2025, 15:30 editováno autorem komentáře
-
...ostatně fakt by mě zajímalo, jestli bys manželce a dětem až přijdeš domů s poloviční výplatou vysvětloval, že sorry jako, ale "nemít testy je jenom obyčejná výmluva" takže jsi na nich holt musel pracovat zdarma. To je na lidech jako ty nejlepší. Sorry, já jsem na to, abych po večerech zdarma někomu řešil jeho problémy a nevůli už poněkud starej. Právě proto, že už jsem se v tomhle ohledu párkrát spálil. A proto taky nevedu podobné řeči jako ty.
Mimochodem, u výměny kol je za to explicitně platím. To je hodně blbej příklad.
-
A jak se chodí vám domu a říká manželce, dneska jsem toho zákazníka oje...., protože jsem nedělal svoji práci pořádně?
Jestli ten váš kód nikdo jiný nevidí a nikomu ho nepředáváte (o čemž dost pochybuju), tak si to tak dělejte, ale jestli tomu tak není, tak mějte aspoň trochu soucitu s tím chudákem co to po vás bude řešit a ty testy prostě pište. Tohle jsou zkušenosti z praxe, fakt není nic horšího než přebírat projekt, který je totálně v háji a nemá žádný testy, ale tím si asi musí člověk projít aby mu to došlo. Evidentně to, že je někdo starý na tom nehraje roli. Jestli se někdo spálil kvůli psaní testů (navíc několikrát), tak je problém asi někde jinde a měl by se nad tím co dělá blbě zamyslet.Mimochodem, u výměny kol je za to explicitně platím. To je hodně blbej příklad.
Vážně chcete tvrdit, že když jdete na výměnu kol, tak máte ceník a v něm je utažení na předepsaný moment 100 Kč a následné překontrolování 50 Kč? Ale no tak. Stejně jako vy, který pečete na testy, se najdou mechanici, kteří na to pečou a budou tvrdit stejné nesmysly jako vy. A stejně jako u vás, když se pak něco pokazí jde to za nima. -
Zákazník ví co chce a pokud to neví, pak to ale není můj problém. Já mu názor řeknu a pokud ho neakceptuje, je to opět jeho problém. Takhle jednoduché to je. Vy jste jen obyčejný pokrytec, nic víc, co to rozvíjí dojemné řečičky. Protože to vás narozdíl od tohohle nestojí nic. Prostě diskuzní klasika :-D
A ano, chci to tvrdit. Kam jezdíte měnit kola vy je mi úplně jedno.
-
Humanoid č. 1264054 - poruchovýBronzový podporovatel
Podepisuji. Asi při vibe codingu mnohé programátory netrápí, co z toho leze, ale já jsem puntičkář a trpím u toho pořád řešit halucinace a balast, který nikdo nechtěl a je úplně k ničemu.
-
Je potřeba si uvědomit, že AI asistent je pouze nástroj, který může být používán různě - nezkušeným člověkem nesprávně (jak popisujete Vy), ale v rukou seniora je to pomocník, který skutečně šetří čas a generuje kvalitní kód nebo konfiguraci.
K zabezpečení kvality výstupu ale nestačí pouze chatování. Je potřeba přidat další úroveň znalostí pro AI - instrukce, které tu kvalitu zabezpečí (např. Github Copilot Custom Instructions). O tom zřejmě budou další části tohoto seriálu.
Vnímám to tak, že psaním instrukcí se trénuje AI pomocník na generování kódu, který dodržuje architekturu systému. Výsledek sice není vždy 100%-ní (a je závislý na denní době - odpoledne, když je vzhůru Amerika jsou výsledky horší) a kontrola je vždy potřeba. Během kontroly ale nečtu "kód někoho jiného", čtu "vlastní" kód vygenerovaný dle instrukcí.
Medior/senior se tím přesouvá do role "údržbáře" instrukcí, čím vlastně popisuje samotnou architekturu - něco ve stylu dokumentace, která se ale aktivně udržuje a používá (na rozdíl od 99% existujících dokumentací :) ). Současně může trénovat jiného juniora, jak v oblasti kódování tak i v údržbě AI instrukcí.
-
„spíš osobní názor: mnohem líp se mi píše/upravuje kód, než čte kód někoho jiného. S AI nástroji se to hodně posouvá do té druhé oblasti.“
Tohle je zajímavé, že je obecně taková tendence používat AI na psaní kódu, místo na review, kde třeba použití GitHubího Copilotu na code review je fakt super, hezky to ohlídá konzistence a podobný věci.
Možná si málo všímáme toho, na co je AI opravdu dobrý a používáme ho na to, o čem se tvrdilo, že v tom bude dobrý :)
-
Používá někdo AI na skutečné programování v praxi?
Můj přístup k programování je následující:
* Naučit a neustále si doplňovat něco jako "best practise" tedy vlastně jak psát dobrý kód (v daném jazyce).
* Učit se nové postupy - tady bych uvedl zásadní změnu myšlení, ke kterému mě přivedlo jednak sledování přednášek Joe Armstronga (Erlang), kdy v erlangu je každé volání funkce vlastně jen předání informací (message passing) do jiného threadu. Takže vlastně každá funkce může běžet ve vlastním threadu a volání fce je jen předání parametrů do nějakého inboxu.
* Takto to používám v golangu, kdy vše, co může být ve vlastní gorutině je automaticky psané jako gorutina (tedy předávání dat pomocí kanálů).
* A pochopitelně znalost knihoven.Nějak mi tady chybí prostor pro AI. Možná je to oblastí, ve které pracuju, ale vlastně vůbec nevím, kde přesně by mi mohla AI pomoci. Pokud mi poradí alg. který jsem neznal, tak se jej stejně musím naučit nebo si na to najít vhodnou knihovnu (a nebo jej prostě z různých důvodů odmítnout).
A tak jak vnímám například copilota, tak je to v podstatě něco, co mělo už před 30 lety Borland Delphi, tedy něco jako šablony. Pokud mám ve formuláři 10 políček s daty, tak systém fakt nepotřebuje AI na to, aby se "zamyslel" nad tím, že s těmi daty bude potřeba něco udělat. Tohle kupodivu už před 30 lety napadlo i autory těch komponent, takže každá komponenta měla vhodné rozhraní, jak předat data někam jinam. A copilot dělá přesně tohle, "jééé tady je struktura s daty, tady je databázový dotaz, tak navrhnu jak data poslat do toho prepared statementu" - tohle ale vůbec nepovažuju za umělou inteligenci, na tohle si napíšu generátor kódu klidně sám, stačí vzít struct, její exportované fieldy a udělat z toho insert nebo update do DB.
říct mu, že toto je moje upravená verze a teď se budeme bavit o ní, a že tam chci nějaké změny.
Nechci opravdu rýpat do každého odstavce, ale na tohle jsem četl návod už někdy v knížkách o refaktoringu (Martin Fowler), tedy že pokud je změna tak velká, větší než je položená otázka, tak by to mělo automaticky vést k zamyšlení se nad strukturou kódu. Takže pokud bych si měl s AI povídat o tom, jak upravit ten kód, tak to prakticky vždy udělám rychleji, než vůbec zvládnu vygenerovat vhodný dotaz a pokud tohle nezvládnu, tak je to indikátor mnohem většího problému v tom kódu.
kopírovali ze StackOverflow
Aha, a já jsem si vždy myslel, že to je vtip (napadá mě obal knížky Copying from StactOverflow - https://sl.bing.net/iKiOHOn9B3A)
Těším se na další díl, třeba se dostaneme k tomu, kde se to reálně používá a co nelze dělat jinak (a lépe).
-
Ano, používám to na skutečné programování v praxi (integrované v JetBrains IDE).
- autocomplete - výrazně psaní, ale také zanáší záludné chyby (když neví název proměnné, klidně si vymyslí neexistjící, třeba "oder" místo "ordering")
- super je to na self review před odevzdáním kódu - poradí mí lepší naming, navrhne extrahovat kód do samostatné metody pro lepší čitelnost apod.
- zrychluje/nahrazuje vyhledávání v dokumentaci a dokáže člověka navést na postup, který by ho nenapadl (nedávno jsem chtěl třeba navodit v dockeru situaci síťové latence a výpadků - poradil konkrétní docker image a přepínače pro "tc")
- případně i řeší konkrétní problémy - po upgrade Ubuntu mi VPN hodila nějakou chybu a AI mi řekla, že nějaký formát certifikátu přestal být podporován a hodila konkrétní přikaz pro zkonvertování
Pořád to ale beru jako nástroj a ne jako autoritu. Bohužel u mladších kolegů pozoruju mnohem větší tendenci brát rady AI jako autoritu a míváme občas abstraktnější debaty (typu řešit daný problém dědičností nebo kompozicí), kde někdo dá otázku do ChatGPT a odpověď bere jako větší argument než názor kolegy.
Navíc je to technologie jako každá jiná a k dobrým výsledkům je zapotřebí se ji dobře naučit používat (jak psát prompty apod.).
-
když neví název proměnné, klidně si vymyslí neexistjící, třeba "oder" místo "ordering"
Jo, u Golangu si Copilot občas vymýšlí neexistující metody a třeba umí ignorovat stringer, takže místo obyčejného printf("%s", obj) to vymyslí nějakou konverzi obj.GetData().String(), případně to ještě vezme přes hex, asi aby ten řádek byl delší - vypadá to na myšlenkový zkrat, kdy ono to sice ví, že potřebuje string, ale potom to udělá libovolnou konstrukci, ze které sice na konci vypadne string, ale ta optimalizace uprostřed té úvahy tam nějak chybí, takže to protáhne data přes 3 další filtry.
případně i řeší konkrétní problémy - po upgrade Ubuntu mi VPN hodila nějakou chybu a AI mi řekla, že nějaký formát certifikátu přestal být podporován a hodila konkrétní přikaz pro zkonvertování
Což se dá většinou poznat už jen z chybové hlášky a snadno najít na google.
No mě obecně chybí nadšení pro to, co se dneska nazývá AI. Neříkám, že je to špatná nebo nevhodná technologie, ale obecně mi vadí nadšené nasazování (nebo alespoň předstírání), že "to tady ještě nebylo" nebo "teď už to konečně jde" a použije se machine learning na vše, kde doslova stačí dva ify, kdyby data byla v pořádku, před čímž (nepořádek v datech) někdo varoval už v minulém století.
Právě proto jsem se ptal spíše na konkrétní použití u programování, protože mě jednak baví se dotýkat své práce, takže nerad používám nějaké nástroje tam, kde si to prostě můžu napsat (pokud to není vyloženě stovky řádek něčeho extra nudného) a taky mě baví si ty cestičky projít sám, takže pokud přijdu na nějakou novou techniku něčeho, tak z toho mám větší radost, než kdyby mi to napsalo AI samo.
A v kombinaci s tím, co jsem napsal v prvním komentáři prostě nevidím pro AI místo a upřímně řečeno, zatím to spíše vypadá na použití v nějakém legacy hrozném kódu, kde jsou všichni rádi, že mají nástroj, který jim v tom pomůže se vyznat. Protože v novém kódu tohle není potřeba, všichni se v tom vyznají a baví je to psát.
-
Je to nástroj.
Není to nástroj vhodný na všechno. Kdo ho chce rozumně využívat, měl by znát jeho klady, zápory, silné a slabé stránky, limity.Používají ho mí studenti, ale chci, aby generovanému kódu rozuměli, byli schopni ho samostatně modifikovat, ověřili funkčnost a ručili za to, že dělá to co má a nemá bezpečnostní díry. Někteří z nich pracují ve firmách kde je využití AI nástrojů o level až dva dál, než mám já a v podstatě je tyhle technologie živí. Bez nich by museli ještě pár let studovat, aby mohli dělat to co dělají s jejich dopomocí.
Používáme "AI" programování při výuce PyLadies v Plzni.
Proměnné, datové typy, podmínky, cykly, funkce jedeme klasicky a pak už se zaměřujeme na praktické úlohy. Vedeme je k tomu, aby kódu rozuměly.Analogie:
Od dovednosti "napsat knihu" je vedeme k tomu, aby dokázali popsat obsah knihy/kapitoly/odstavce. Aby rozuměly tomu co dostanou a doptaly se na to, čemu nerozumí.Osobně to vnímám pozitivně.
Sám jsem se chystal napsat engine, který by mi s využitím genetických algoritmů pomáhal vytvářet transformační funkce. V oblasti kde programuji je mnoho akcí typu:
- vezmu data
- provedu s nimi transformaci
- převezmu upravená data a pokračuji s nimi
V tomto typu úloh se dobře stanovují hodnotící kritéria a ověřuje funkčnost.
(Už to psát nemusím.)Kde mi AI pomáhají.
- při generování testovací dat a testovacích úkolů
- při psaní krátkého kódu v jazyce, který dobře neznám
- při brainstormingu technologií, které jsou vhodné
- při generování jednoúčelových BASH scriptů
- občasně při refaktoringu -
Autore nezapomeň zmínit: bmad-code-org/BMAD-METHOD a podobný frameworky...
BMAD-METHOD je otevřený framework, který z obyčejného „psaní promptů“ udělá řízený, agilní proces: místo chaosu dostaneš virtuální AI tým (analytik, architekt, produkták, QA), který ti pomáhá sepsat specifikaci, navrhnout architekturu, rozbít práci na úkoly a dotáhnout kód do produkční kvality – stačí npx bmad-method a najednou máš vedle sebe nadšeného, ale disciplinovaného parťáka pro celý vývoj. Sám si kontroluje zadání a to třeba z 10 úhlů (kvalita, zadání od šéfa, od zákazníka, ...)
Všechno co tady popisujes mi reálně přijde jako pravěk, vlastně jsme ve stavu kdy píšeme jen spec (respektive epics a stories) a agenti makají.
Když je něco špatně, je špatně spec a docs.Programuju 25 let - a dost to bolelo pochopit - že čumět do kódu je už de facto k ničemu...
Teda furt ho čtu, ale vždycky když mám touhu klepnout do něj, tak se plesknu přes prsty a nechám bmad udělat nový stories. Do kódu se prostě nesahá, tečka, fuj.Jasně objeviš hnusy, ale NIKDY je neopravuji napřimo, ale zlepšuji zadání v docs.
Zkusil jsem i extrém že projekt který jsme popsali 3 měsíce jsem smazal a nechal agenty jej dle docs napsat znovu. A představ si za 12 hodin to odevzdal funkční a stejný, rozdíl prakticky neviditelný - což značí že docs byl napsaný spravně.
Za překlepy se omlouvám.
-
Kdybych na několika projektech z poslední doby, na kterých jsem pracoval fungoval vámi popsaným způsobem, nepracuji na nich už ani já, ani nefungují ty projekty. Bohužel. Současná AI má problémy i s chápáním poměrně jednoduchých struktur. Kdybych ji nepoužíval denně... Takhle jednoduché to tedy obecně opravdu není. Lze to aplikovat na určitě spektrum projektů, o tom žádná, ale typicky na projekty na zelené louce a často hlavně na věci, které se opakují stále dokola a které, mimochodem, žádný zlatý důl nejsou už dost dlouho.
Ostatně ve vývoji tvoří vlastní tvorba nových features tak 30 % mé práce. A to i na nově vyvíjených projektech a to jsem programátor, ne analytik nebo projekťák. O maintenance ani nemluvě.
14. 11. 2025, 16:28 editováno autorem komentáře
-
Tohle mi přijde hodně zajímavé. Jasná mi není jedna věc - já vždycky vnímal jako ultimátní specifikaci právě kód, (pokud je dobře napsaný). Snažím se co nejvíc invariant zakódovat do typového systému. Tím pádem se stává, že až při kódování nějakého zadání se zjistí, že překladač křičí a ukáže mi, že tohle zadání koliduje s nějakou jinou částí systému a je třeba předělat zadání. Vývoj SW je v mých očí vlastně manageování komplexity - snažím se systém popsat na stovkách tisíc řádek tak, aby byl v rámci možností uchopitelný, srozumitelný, dobře dekomponovaný, funčnost ověřitelná.
Když budu mít specifikaci psanou - ve srovnání s kódem - volně, v BMAD, přijdu vlastně o jazyk, který mi umožňuje vyjádřit se zcela precizně (programovací jazyk), jazyk pro popis invariant systému (statický typový systém), strojové ověřování (unit testy) - jak hodně potom můžu věřit tomu, že když agentům řeknu, ať z BMAD specifikace udělají výsledek, dostanu potom opravdu to co chci? A že to zadání je vnitřně nerozporné?
-
Pozitiva:
* Rychlejsi hledani v prumerne rozesahle dokumentaci = Casto doda informaci jako kompilat z utrzku rozesetych po spatne clenene dokumetntaci.
* Generovani dokumentace = Necham vygenerovat vzdy jen pro maly scope a v drtive vetsine pripadu to skutecne sedi a struktura dava smysl.
* Jednoucelove veci - ad-hoc Bash skript pro slozitou filtraci dat; SQL pro ad-hoc slozity dotaz do DB
* Vysvetleni kodu - idealni cesta pro zacatecniky, jak pochopit i neidiomaticke kusy koduNeutralni:
* Pokrocilejsi "Intelli Sense" = Plati jen pro masove rozsirene jazyky + knihovny, umi vygenerovat i celou metodu. Uspesnost ale neni nijak super vysoka.
* Generovani testu = obcas funguje, ale obcas vytvori test o 100+ radcich, kdyz stacilo nejakych 15. Tim se absolutne ztrati zacileni testu.Negativni:
* Halucinace = Vytaci me, kdyz si vymysli syntakticke nesmysly nebo absolutne neexistujici funkce. Je schopen i dodat link na GitHub k vyhalucinovanemu kodu - link samozrejme vraci HTTP 404.
* Bruteforce pristup = Napr. kdy vygenerovany kod parsujici YAML/JSON data je zalozen na vcelku trivialnim regexu.
* Preoravani kodu = Obcas z nepochopitelneho duvodu meni mnohem vic nez je vyzadovano. Kriklavy priklad je zmena formatu dat vstupnich namisto zmeny zpusobu zpracovani. -
Co se testů týká, vždy je potřeba je projít a kdyžtak je nechat zjednodušit, případně lehce navést co má testovat a jak. Výsledkem je kupodivu často test, který testuje to, co má a přitom je podstatně lépe napsaný. LLM holt nejsou deterministické a bez korekce občas generují spousty šumu.
Ten "bruteforce přístup" je zajímavý ale celkem logický. Přesně odpovídá těm haldám mizerného kódu, kterého se po internetu valí gigabajty. Na čem, myslíte, se asi učila? A to přeorávání kódu omezuji výslovnými instrukcemi na co sahat smí a na co ne a co jsou danosti. To respektují. Tedy skoro vždy, ehm. Vyhnout se tomu naštěstí dá. Pravda je, že při generování těch testů je to jinak když člověk opomene dost zajímavé :-D
14. 11. 2025, 10:15 editováno autorem komentáře
-
Záleží na tom, jak kdo k AI přistupuje. Já ji mám za blbého otroka, který ale rychle píše. Tedy něco jako kalkulačku, sama nic nevypočítá, ale počítání usnadňuje a zrychluje. Nechci tedy po AI aby vyřešila nějaký problém, od toho jsem já, vím přesně jak a co chci řešit. Po AI chci, aby to za mě napsala, dodržela coding style, psala komentáře a doc stringy. Ty jsou mimochodem důležité, pomáhají AI se orientovat v kódu. Moje AI ví, že komentáře ## jsou trvalé instrukce pro příslušnou část kódu, které nesmí porušit.
Používám placený ChatGPT, a ten je dobrý v tom, že si umí ukládat zadané instrukce, když chci. Stačí abych mu řekl, tohle si pamatuj a on si to někam zapíše. Tuhle jsem se ptal, kolik má uloženo mých instrukcí, a bylo jich 92. Těmi si ji postupně otesávám, takže se chová poměrně slušně a dělá co chci, aniž by to bylo příliš únavné. Má tak třeba nadefinované významy mých příkazů. Takže ví, že když ji řeknu přidej, nesmí z kódu nic odstranit ani něco jiného měnit, čímž mě třeba dříve dost štvala a tak podobně. Takže mně AI pomáhá a produkuje ten samý kód, který bych napsal sám, ale dělá to rychleji a poctivěji dokumentuje a testuje.
Dále je skvělá na psaní ~/bin skriptů. Ty jsem byl vždy líný psát, abych si tím zautomatizoval opakovanou činnost. Teď jich mám už několik desítek. Zrovna tak jsem si takto nechal napsat desítky funkcí do Vimu. Můj vimrc si vytvářím už přes třicet let, ale poslední dobou nabyl na objemu, a má přes 85 kB a má parádní funkce. Třeba mám na jedno kliknutí vložení nového kódu od AI a spuštění diffu na starou a novou část kódu, takže hned vidím, co přesně kde AI změnila.
ČLÁNKY DO MAILU