A z jakého důvodu píšete kód profesionálně vy? Samozřejmě se nebavíme o triviálních úpravách, kdy je prompt nutně delší než samostatná úprava.
Už i u jazyků jako je Racket nebo Smalltalk jsem schopen instruovat AI způsobem, který znatelně předbíhá mé prsty. Můj dotaz je upřímná zvědavost, já dnes už kód většinou píšu jen pro radost a z lásky k řemeslu.
> A z jakého důvodu píšete kód profesionálně vy?
(1) Vzhledem k tomu, že jsem OSVČ a za chyby ručím celým svým majetkem, tak do práce píšu prakticky všechno sám.
(2) Nedávno jsem zkoušel psát pár modelů pro cenu opcí pomocí Clauda a udělal v tom vcelku záludné chyby - program něco počítal, ale ve výsledcích byl bias - takže ceny byly systematicky o něco nižší.
(3) Některým jazykům modely pořád moc nerozumí. Např. u C3 většina modelů ani nechápe, že proměnné jsou by default inicializované 0.
(4) Mám hodně vlastních knihoven, které modely neumí používat.
(5) Když to nenapíšu sám, tak je to těžké upravovat. Často mi přijde těžší dělat review cizího kódu, než to napsat sám.
Myslel jsem, že třeba v situaci, co zmiňoval předřečník: "Samozřejmě se nebavíme o triviálních úpravách, kdy je prompt nutně delší než samostatná úprava."
Nebo, co dělat v situaci, když to ten bot nedokáže? Můžete zkusit zaplatit jiný model, ale co když to také nedokáže? Pak se stane, že spalujete čas a peníze zkoušením různých modelů a k výsledku se neblížíte.
A neni ta "profesionalita" treba take o tom, ze projekt neni one-man-show, tedy ze existuje nejaka zastupitelnost? Pokud by ta zastupitelnost existovala, tak by logicky musel existovat i kod, ktery jste san nenapsal. Produkty, ktere fakticky umrou se svym vyvojarem jde oznacit spise jako amaterske (hobby) reseni.
Také to má něco do sebe. Nicméně mi přišlo ze zkušeností z dřívějších firem, že čím víc lidí pracuje na jednom kusu kódu, tím je většinou horší a méně spolehlivý. Zvlášť, pokud se i odpovědnost za problémy rozdělí na mnoho lidí.
Ostatně podívejte se, co poslední dobou vydávají velké firmy jako MS nebo Apple. Po aktualizaci přestane fungovat tlačítko Start nebo kalkulačka spotřebuje 30 GB paměti. To bych také neoznačil jako profesionální řešení.
Zastupitelnost je dle mé zkušenosti, často možná jen do určitě míry.
Architektonicky se snažíme, abychom projektu rozuměli všichni, ale některé detaily necháváme na individuální odpovednosti. Konec konců, když by tam bude bug, tak ten vývojář co psal ten kód to fixne rychleji, než to předávat někomu, kdo na tom nedělal. Pokud odchází, holt se to předávat musí, ale to už je pak jiná situace.
Píšu z vlastního pohledu, malý startup s korporátními zákazníky. Máme také opravdu dost vlastních řešení, takže kdo přijde, musí se zorientovat v tom co máme a když odejde, může to v klidu zapomenout :D
> Produkty, ktere fakticky umrou se svym vyvojarem jde oznacit spise jako amaterske (hobby) reseni.
Pokud vydělali peníze, tak sotva. Všechno časem pomře i projekty se 100 vývojáři.
22. 2. 2026, 15:33 editováno autorem komentáře
1) Ja samozrejme stale kazdy kod prochazim a musim mu 100% rozumet, o tom rec nebyla.
2) Chyby to dela, o tom zadna. Ale jakmile to chybu udela, clovek vyrobi skills, nejake guardrails a hned jich je mene.
3) Ano, takove jazyky vyzaduji vice prompt engineeringu nez ostatni.
4) Vyrobte skill, je to nutne delat v podstate s kazdou knihovnou.
5) Ano, je to tak. Vzdy to bylo tezsi, proto si rikam, ze se v tomto diky AI mozna znatelne zlepsime, protoze budeme delat review neustale a psat mnohem mene.
Zrovna předevčírem jsem měl tu čest pozorovat při práci opraváře praček. Vadnou součástku hravě identifikoval , vyměnil, spustil testovací běh, a když seznal, že je vše v pořádku, jal se zase vše uzavřít. Celkem by to bylo 15 minut odborné práce...
...jenže si na pračku odložil potřebné šroubky, a ta se pustila do ždímání, takže šroubky hbitě zmizely v jejích útrobách. Hledání a lovení šroubků trvalo půl hodiny.
Neznal programátorskou zásadu: Nic neuzavírej, dokud nedokončíš testování!
;D
Úplně off topic, ale stejně... Na pračce často odejde ložisko bubnu. Mě takhle odešly už tři pračky. Svého času stačilo koupit ložisko za pár korun, vyměnit ho, a pračka dál fungovala. Nově (hmm, 15 let?) ale výrobci začali dělat svařované vany, kde se ložisko v podstatě nedá vyměnit. Je potřeba vyměnit celý buben, což je 50-150% ceny nové pračky. Nebo člověk může tu vanu rozříznout, pak vyměnit ložisko, a zkoušet ji slepit/sešroubovat, ale to se většinou finančně nevyplatí. Nehledě na to, že někdy odejde i "pavouk" (zadní část bubnu), který od výrobců se zavařenými bubny nejde koupit. Tuhle past používají Elektrolux, AEG, Bosch, Zanusi, AEG, Hotpoint, Beko, Ariston, Indesit a další. Asijští výrobci často mají vany pračky montované a dodávají ložiska i "pavouka", protože vědí, že jejich zákazníci si nemohou dovolit měnit pračku každých pár let.
Doporučení: před koupí pračky se ujistěte, že výrobce pro daný model dodává náhradní ložiska a "pavouka". Pokud ne, jděte o dům dál. Já osobně ke všem domácím spotřebičům vyžaduji i servisní manuál. Pokud není ke stažení a nedodá ho ani servisní středisko výrobce (zdarma), tak jdu jinam.
Manuály byly ten menší problém. Nejspíš kvůli chystané EU Right to Repair Directive, která vstoupí v platnost v půlce tohoto roku, už servisní manuály většina výrobců dává ke stažení. Nakonec jsem vybral Samsung, který bývá podle opravářů realisticky opravitelný. Někdo na Youtube dokonce rozebíral Samsung s tepelným čerpadlem, a komentoval jak je to ukázkově správně, protože se dá rozebírat a čistit (ačkoliv finančně to čerpadlo ani u Samsungu podle mě smysl nemá). Vybral jsem model WD11DB8B85GHU4. Výrobce dodává servisní manuál a seznam dílů, a ačkoliv jsem na seznamech nenašel ložisko a pavouk bubnu, tak je obojí k dostání.
po kratkym zjistovani jsem nasel ze consumer rights wiki ma dokumentovat jen prohresky. Na druhou stranu https://www.ifixit.com/Wiki/Service_Manuals se zda byt spravny misto. Doplnim tam tu Laelovo pracku co ma manual zde https://www.samsung.com/cz/support/model/WD11DB8B85GHU2/ . jen musim prijit na to jak tam nahrat dokument :)
Koupil jsem Samsung WD11DB8B85GHU4. Výrobce dodává servisní manuál a seznam dílů, a je k dostání pavouk bubnu i ložisko. Ovládání je z 21. století, a ta elektronika fakt funguje. Pomalé rozběhy a doběhy motoru, zpomalení a případně i zastavení s chybovou hláškou pokud je prádlo vysoce nesymetricky rozmístěné v bubnu, vůbec necestuje po podlaze, plynule reguluje teplotu sušení a má dvě pojistky (termometr+SW a přerušovací tepelnou pojistku), šuplík na prací prášek má manuální aretaci takže se neotevře v průběhu praní samovolně, má to zásobník na tekuté prací prášky ("nesmysl" který se ukázal velmi praktický), atd. Navíc kupodivu funguje i to ovládání přes SmartThings. Je to poprvé, co vidím skutečně funkční smart funkce pračky.
Minulá pračka byl Hoover, tj. značka italského výrobce Candy, kterého koupil čínský Haier (což jsem zjistil až s odstupem). Větší horror jsem nezažil. Bez ohledu na vyvážení nebo antivibrační podložku cestovala po podlaze, po pár týdnech technik měnil board (na druhý pokus) protože tam byl problém s firmwarem a nesušilo to, opakovaně vypadávala teplotní ochrana při sušení, uvnitř odpadaly plastové úchytky kabelů protože zkřehly při vysoké teplotě (byly zasazené zvenku do tunelu ve kterém se ohřívá vzduch pro sušení tuším 1.5kW topnou spirálou), jeden uvolněný kabel se časem vibracemi prodřel a pračka vyhazovala chránič, "smart" funkcionalita byla naprosto nepoužitelná, šuplík na prací prášek se za chodu samovolně otevíral a voda pak tekla kam neměla, nejspíš v důsledku toho se zamlžoval ovládací panel (což asi časem poškodilo i PCB), kapacitní tlačítka byla od začátku hrozivá a ke konci napůl nefunkční... Když přestal fungovat ventilátor kvůli zanesení textilním prachem, tak jsem zjistil, že ten tunel, ve kterém se ohřívá vzduch na sušení, je neskutečně netěsný. V podstatě fungoval jen díky opatlání spár vysokoteplotním tmelem, a nejspíš z toho utíkal horký vzduch do prostoru zařízení. No a samozřejmě nakonec odešlo ložisko, a oprava nebyla možná. Upřímně jsem měl chuť si s tou pračkou zopakovat tu scénku s tiskárnou z filmu Office Space. Přitom čínští výrobci dokážou udělat i kvalitní výrobky. Třeba čínský Ecovacs dělá velmi slušné robotické vysavače, Shokz slušná sluchátka, atd.
To, co popisujete byla ovšem katastrofa, ne standard. A naopak mi přijde, že standard je to, co popisujete v prvním odstavci. Netuším jak co se týká opravitelnosti, ale třeba LG je dost podobné a dost podobně funkční. Jen to "ovládání z 21. století" bych raději vyměnil za obyčejná tlačítka protože to je -- jako ostatně skoro vždy -- jen nesmyslná komplikace.
Robotické vysavače, mimochodem, Číňané dělají velmi dobré obecně.
Souhlas, že to co jsem popisoval byla katastrofa. Pokud jde o LG, tak nemám zkušenost. Než jsem koupil ten Hoover, koupil jsem Electrolux. Ten bohužel při sušení smrděl jako hromada pálících se pneumatik. Podle výrobce to mělo přestat po pár cyklech, ale nepřestalo, takže jsem ho vrátil. Možná to byl problém jednoho kusu, nevím.
Pokud jde o ovládání obecněji, tak klasická tlačítka jsou poměrně drahá, a k tomu ne zrovna dvakrát spolehlivá. U kapacitních tlačítek záleží na kvalitě provedení. Ta od Hooveru byla strašná, ale mám jich doma porůznu řadu od Samsungu, Panasonicu, Bosch atd., a všechna fungují uspokojivě či lépe. Zpětná vazba bývá zvukem a na displayi. Tenhle způsob ovládání je doma OK. Katastrofa to bývá v autě, je vysoce žádoucí najít ovládací prvky po hmatu, aby člověk nemusel spouštět oči z vozovky.
No a pokud jde o logiku ovládání toho Samsungu, tak za mě to mají velmi dobře udělané. Na videu níže je to vidět, ačkoliv asi na jiném modelu. Co tam není vidět je funkce tlačítka "prst plus", tedy options, kde se dá vybrat řada voleb pro daný program, včetně sušení, předpírky, bubble soak, dávkování prášku atd. Klasické ovládání množství options by bylo nepřehledné, takhle je to OK. A ve výběru programu můžete vidět třeba indikaci maximální hmotnosti prádla, která bere v úvahu options. Například při sušení je kapacita nižší než při prostém praní (obecná vlastnost praček se sušičkou), a tady to vidíte, takže pak nemáte prádlo skoro uvařené a neusušené.
https://youtu.be/Tz8hwQL_VUo?t=25
U robotických vysavačů mě trochu šokoval konec společnosti iRobot. A příběh čínských výrobců je klasika. Od západních partnerů získali know-how, pak začali vyrábět vlastní produkty, a ty západní výrobce na trhu nahradili. To byl plán čínské vlády od začátku, proto společné podniky musely mít nadpoloviční účast čínské strany. A západní výrobci viděli jen krátkodobý zisk. Příští rok budou nižší náklady, akcie půjdou nahoru, board mě pochválí a zahrne penězi... Dlouhodobě to sice firmu asi pohřbí, ale to bude až někdy později.
Takze se to vratilo do stavu ve kterem to bylo predtim nez to rozbili.. ale je z toho udelat hipsta gangsta post na socky, a trikrat obletet svet, ze jsme pouze s AI 60x lepsi, ze?
Primo odkazovana kernel diskuze ukazuje ze pokud se nepouzije iouring, tak je block device obstojne rychle.. a patch pro iouring to jenom dotahuje na podobnou uroven.
Za me je to na urovni umazanni delay(n) z nejake kriticke sekce :D
Takze takovej Hejl-aaaj tady to.
Stane se svět lepším, když se tohle zrychlí? Ano.
Stane se svět lepším, když si zanadáváš? Subjektivně možná.
Skutečnost je, že LLM nám jsou skutečně mocné nástroje a konečně můžeme pořešit spoustu věcí, na které nebyl čas, prostor, energie. Chápu, že nemáš rád hype, ale obecně je tohle velká věc.
21. 2. 2026, 09:24 editováno autorem komentáře
Suhlas.
Je to velka vec.
Najviac to citim na side projekte, na ktorom robim po veceroch/ked mam cas a nemat napomocnu LLM, tak urobim toho o dost menej/so stastim mozno polovicu.
Je to dalsi krok evolucie ako bol kedysi prichod googlu a jeho vyhladavania.
Ak clovek pouziva nieco kde je dost zdrojov, na ktorych sa mohla LLM natrenovat tak to dava pradne vysledky.
Tu ani nejde o to, ci to, co pisem uz niekto napisal ale o to kolko ludi ten dany jazyk uz predomnou pouzilo a aka je dobra dokumentacia.
Kedze to robim nepravidelne a prepinam z ineho programovacieho jazyka, tak LLM funguje u mna z velkej miery ako zdroj dokumentacie a analyzator.
To, co by som na googli alebo v dokumentacii hladal neviem aku dobu, to mi LLM da v priebehu sekund.
Je brutalne dobry v generovany SQL prikazov a podobnych veci.
Vie to velmi dobre a rychlo zanalyzovat kod a tym mi usetrit vela casu.
Ked clovek ma volny len obmedzeny cas a potrebuje riesit zlozitejsiu vec, tak to usetri mega casu. To, co som pred tym riesil napriklad 2-3 tyzdne, tak dnes som schopny urobit v priebehu niekolkych dni. To len vdaka pomoci pri analyze. Ak mas zlozitejsi problem, tak za 1-2 hodiny toho vela nezanalyzujes a do dalsieho volna cast z toho "zabudnes" a musis sa do toho znovu dostavat, co je velky zabijak casu.
LLM je u mna pomocnik. Nevymysla co a ako ma fungovat a v podstate ani nevie, co robi(m). Jeho uloha je mi pomahat s jazykom ako takym. Preto nezalezi, ci to, co pisem uz niekto napisal ale ako "rozumie" danemu jazyku(stacku). Ja som tam stale ten mozog, co tvori/vymysla a ako to pospaja.
Takze ak to pises v nejakom popualrnom jazyku, tak je "chyba" v tebe a nie v LLM :)
p.s. Dovolim si tvrdit, ze +-99% veci, ktore vznikaju uz niekto napisal. Ide len o to, ci mas k tomu pristup a ako sa na to pozeras.
Myslím si, že jeden z vás rozpráva o voze a druhý o koze. O užitočnosti LLM pri tvorbe prototypov a objasňovaní vecí asi nikto nepochybuje, ale čo sa týka vývoja úplne v réžii agentov, čo je aktuálny najviac diskutovaný trend, to môže v súčasnosti fungovať iba v najtriviálnejších a mnohokrát vyriešených prípadoch, pretože nie je vôbec žiadny problém overiť si, že AI sa dokáže stratiť veľmi rýchlo. A keď sa raz stratí, tak to žiadne opakovanie nevyrieši, bude sa točiť dookola a páliť tokeny. A aby to niekto rozsekol, musí to spozorovať a vedieť vyriešiť, na čo zas potrebuje byť dobrý vývojár.
Osobne veľmi-veľmi pochybujem, že by predrečník nevedel rozložiť problém na menšie časti...
Tato debata nieje o vyvoji uplne v rezii agentov. Ako si na nieco take prisiel?
Moja prva reakcia bola na toto "Skutečnost je, že LLM nám jsou skutečně mocné nástroje a konečně můžeme pořešit spoustu věcí, na které nebyl čas, prostor, energie. "
Z tej jednej vety sa neda urcit, co tym presne myslel. Preto aj tie rekacie.
Tato debata nieje o vyvoji uplne v rezii agentov. Ako si na nieco take prisiel?
Táto debata je o vývoji s pomocou umelej inteligencie, bez obmedzenia, a vývoj úplne v režime agentov do toho nepopierateľne patrí. Navyše tento článok patrí do širšieho kontextu vývoja s pomocou umelej inteligencie, tých článkov je tu viac a nejaké príspevky sú aj vo fóre. Je to možno najväčšia téma aktuálnej doby. Nechce sa mi veriť, že by ste si to nevšimli.
Ale to je úplne jedno, ak táto debata neobsahovala aj vývoj s pomocou agentov, nosná časť mojej odpovede sa týkala toho, že LLM ako také v problémoch, ktoré nie sú úplne triviálne alebo nie sú mnohokrát vyriešené, dávajú nedostatočné výsledky, prípadne rovno končia zlyhaním, a bez hlbokých znalostí problematiky vedú k strate času a peňazí.
Z tej jednej vety sa neda urcit, co tym presne myslel. Preto aj tie rekacie.
To možno platí pre vás. Ja tu ale nie som nový a mám trochu prehľad o tom, čo tu kto píše a čo prípadne publikoval inými spôsobmi. Takže som skoro presvedčený, že predrečník, ktorému ste s úsmevom napísali, že chyba je asi na jeho strane, s ohľadom na to, čo si myslím, že o ňom viem, pravdepodobne nepísal o tom, že sa mu nedarilo nechať vygenerovať nejaký triviálny príklad.
Jenže opravil chybu v QEMU, které IO uring používá. V souboru
https://gitlab.com/qemu-project/qemu/-/blob/master/util/fdmon-io_uring.c
a ani nadpis článku na ROOT.cz ani text článek nic o QEMU neříká, takže je to opravdu nepěkně zavádějící zprávička. Původní článek na Phoronix, který také proti LWN považuji kromě openbechmarking spíše za bulvární a honící se za senzacemi, je toto v pořádku popsané.
Na druhou stranu souhlasím s tím, že nalezení chybějícího buzení hlavního vlákna není triviální úloha a je zajímavé že se LLM modelu dohromady s nějakým systémem analýzy a možná i pouštění částí kódu povedlo chybu správně identifikovat.
Oprava se týká pouze AHCI (SATA) emulace. Nativní virtio (nebo i NVMe) bylo v pohodě a to se používá řádově častěji. U většiny hypervizorů je AHCI používaný maximálně na připojení virtuální DVD mechaniky pro ruční instalaci z ISO image nebo virtualizaci nějakého míň rozšířeného systému, co neumí virtio.
Takže určitě fajn, že na to Jens (s Grokem a Claudem) opravil, ale právě že to s AHCI až tak častý use-case nebude.. zvlášť na hypervizorech a virtuálech, kde si někdo zapne io_uring a řeší propustnost a latenci IO operací.
Pro mě jsou LLM dobré zejména v těchto věcech:
Přesnější definování problému, objevování doménového slovníku, pojmenovávání věcí (synonyma, antonyma). Úprava requirements/specifikace do jiného tvaru, návrhy na zlepšení dokumentace. Sumarizace toho, co si myslím, že je realita vs. skutečný stav. Objevování cizího kódu a testování hypotéz (variace řešení, what-if).
Co se týká kódu, klidně bych se rozepsal, ale nechci to tady zaplevelit.
Klidně se ohledně toho kódu rozepište.
Moje zkušenosti jsou omezené, ale za mě LLM dokáže zvýšit produktivitu i při psaní kódu. Dá se s ním diskutovat strategie implementace, a umí ji pak rozpracovat. Ne vždy to kompiluje, a v kódu bývají chyby, ale po nahlášení problémů je umí opravit. Kód vypadá relativně v pohodě. Příjemné je, že nemusím půl dne studovat několik knihoven, a dostanu hotový kód. Jenže člověk musí vědět co dělá. Optimální je, když vibe coding provozuje člověk, který by byl sám schopen úkol splnit. Ví totiž jak problém zadat, jak má vypadat výsledek, umí vyzkoušet jestli to funguje, umí vyžádat opravy a úpravy, a sám do kódu občas sáhnout. Úžasné je, že LLM dovede udělat i velmi rozsáhlé změny velmi rychle. Nefunguje framework A podle představ? OK, přejdeme na framework B. Není to na den práce, ale na pár minut.
A nevýhody? Za mě občasné halucinace. U mě ale jde většinou jen o utilitky, které sežerou data na vstupu, přežvýkají je, a někam naházejí výsledek. Do produkce bych se neodvážil nasadit kód, který nepsal člověk.
IMO by mu bylo celkem jedno, zda se to popíše textem, nebo algoritmem v nějakém pseudojazyce. Naopak na tom algoritmu by šlo rovnou stavět implementaci. Samozřejmě postupně bod za bodem, v závislosti na komplikovanosti. V podstatě to dělám s LLM stejně - po úvodní diskusi o zadání a možnostech řešení se vystaví kostra z prázdných high-level metod.