Život programátorův

Vyšla mi sedmá kniha, trochu víc o programování a míň o elektronice, a souhra okolností tomu chtěla, že vůbec nemám čas se jí věnovat, protože vyvíjím.

Kdysi vyšla taková fajn kniha, jmenovala se “Z kodéra vývojářem”. Autor v ní popisoval cestu od “programátora” coby člověka, co píše příkazy v programovacím jazyce, k člověku, který vnímá programování jako proces, na jehož konci má být výsledek v podobě hotového programu.

Což není samozřejmé, bohužel. Spousta programátorů zkrátka miluje psaní řádků a příkazů a hrabání se v nich. Upřímně: míval jsem to taky, ale docela brzo mě to začalo štvát. Zhruba v době, kdy vyšla ta kniha, tedy někdy v roce 2007, jsem si říkal, že jestli budu psát ještě jeden CRUD pro tabulku zákazníků v MySQL, tak zešílím, nebo půjdu radši dělat něco jiného.

A co myslíte? Ano, zešílel jsem a šel jsem pracovat do médií. Ale programování mi zůstalo.

Chtěl jsem tvořit programy, ale nechtěl jsem furt dokola psát totéž. Přišlo mi to jako největší nuda na světě a nejmizernější část jinak velmi skvělého povolání. Chtěl jsem generátory kódu, scaffolding, něco, co napíše těch nudných 20.000 znaků za mne a já jen doplním to zajímavé. Blýskalo se na lepší časy, nové frameworky slibovaly, že nudu udělají za vás, ale pořád to bylo takové polovičaté.

No, letos jsem se konečně dočkal. Cursor IDE jsem otevřel naposledy někdy v březnu, od té doby jsem svůj kód neviděl.

Jasně že to nejde samo, nejsem vibecodér. Potřebuje to spoustu kázně a mantinely aspoň trojité. Potřebuje to harness, a nejen ten, co jim dají výrobci. Já jsem spokojený se svým dokumentačním systémem, který milerád odpovídá agentům na otázky “Jak řešíme toto?” a “Jaká jsou pravidla pro nasazení?”

Jo, pravidla pro nasazení. Udělal jsem si malý MCP, který běží tam kdesi na serveru a který dává agentovi do ruky (huby? Nebo co to agent vlastně má?) pár nástrojů: podívat se na docker compose, zavolat up, pull, přidat nějakou část, přečíst konfiguráky a .env (a tam mu zahvězdičkuje klíče), zavolat pár věcí, … Vše přísně whitelistováno. Nejsem takový hazardér, abych mu dal plné SSH. Já vím, že si může injektnout vlastní image a dělat zlé věci, ale zatím přínosy převažují nad negativy…

• Nasaď to!

• Nasadil jsem, skončilo to s chybou XYZmnp. Prověřil jsem to, příčina je tady, opravím to takto.

• Jo.

A když vyřeší problém, poznamená si ho do runbooku, aby příště netápal.

Proč? No protože mě nebavilo dávat do LLM divné chybové hlášky, žádat ho, ať někde najde řešení, pak to řešení aplikovat, narazit na jinou chybu, znovu mu posílat chybové logy, odpovídat na požadavky “pošli mi tail -n 20 /etc/kdesi/cosi.conf” a takhle si to s ním pinkat. Ať si to pinká sám, jsem snad nějaký ssh proxy?

Další věc, kterou jsem si udělal už na začátku roku, je Loom. Takový robot, co sedí na “Issues” v GitHubu, a jak přijde, tak si přečte obsah, stáhne si repo, analyzuje, připraví specifikaci opravy, druhý agent ji reviduje, když je bez chyb, tak z ní udělá plán, ten zase druhý agent reviduje, pak jeden napíše testy, druhý napíše kód, ve smyčce to odladí, připraví pull request a hotovo. Když potřebuje něco rozhodnout, hodí to jako komentář k issue. U větších věcí chce schválit i plán a specifikaci opravy, u menších to zvládne autonomně. A k tomu samozřejmě skill, kterému řeknu, co chci opravit, on se zeptá na podrobnosti a nejasnosti, z výsledku udělá strukturovaný popis té úpravy a založí issue.

Fable 5 si vynutil další úpravu workflow. Jasně že jsem četl všechny ty “destiluj pracovní postup” a tak, ale jako nejužitečnější věc se ukázala definice tří agentů, jmenovitě “deep-reasoner” (Opus), “fast-executor” (Sonnet) a “git-clerk” (Haiku). Samotný Claude Code běží s Fable a session začíná instrukcí, aby analyzoval problém, navrhl řešení a rozdělil práci mezi subagenty. On sám pak jen dohlíží.

A já? Já jen říkám, co se má stát a jak se to má stát. Typicky začíná vývoj tím, že si povídám s nějakým šikovným modelem. Co chci udělat, jak to udělat, jak to integrovat. Když máme jasno, požádám ho o zadání. Pak ho nechám zapsat ideu, zadání i rozhodnutí k němu do dokumentačního systému a předám to kodérům.

Teď si tak říkám, že bych i tohle mohl nějak zautomatizovat, ať to nedělám ručně…

No a po několikahodinové přípravě a revizích je věc ve stavu, kterou kdysi trefně pojmenoval kolega Marcel: Je to hotové, už to jen naprogramovat!

Nestěžuju si. Naopak. Baví mě to. Baví mě probírat nové technologie, diskutovat o nich, řešit možné přístupy, zkoumat, co by se ještě mohlo udělat, aby to bylo ještě lepší, … To samotné psaní kódu už mě vlastně ani nezajímá; když to může za sto korun udělat tým mediorů, tak ať to udělají, já nepotřebuju ke spokojenosti psát další a další řádky kódu.

Ne, nechybí mi to. Když mi to chybí, ponořím se do assembleru nebo do céčka pro jednočipy.

A líbí se mi, jak jdou věci dopředu. Před dvěma měsíci jsem řešil, jak zařídit, aby si Claude Code dokázal zavolat Codex kvůli revizi kódu, protože jsem to nechtěl kopírovat, a psal jsem si pro to wrapper. Dneska už existuje skill přímo od Anthropicu, který umí Codex volat. Smyčky, co jsem před měsícem řešil externě, jsou dneska už v agentech. Předpokládám, že brzy do agentů dorazí i můj Loom a budou mít autonomní řešení issues na jeden příkaz.

Pro někoho tím mizí kouzlo programování. Hlavně pro lidi, co u programování milovali kód, příkazy programovacího jazyka, struktury, ladění, … Znám ten typ programátorů a chápu, že z toho musí být nesví a že se jim to nelíbí. Jsou to programátoři, co mají radši programování, než programy. Já měl posledních patnáct či kolik let čím dál raději výsledek než samotné psaní.

Myslím, že nás čeká posun k tomu, co jsem před patnácti lety věštil na Zdrojáku: Vývojář nebude kvalifikovaný odborník tím, že bude znát programovací jazyk, ale tím, že bude rozumět návrhu systému, bude vědět, jak udělat věci, ale hlavně tím, že bude umět požadavky od klientů přeložit týmu kodérů. Před pěti lety ten tým kodérů tvořili lidi, a jako vývojář jste mohli říkat “já tomu nepotřebuju rozumět, já jsem odborník, protože vím, jak zadání převést na kód”. Tak tahle doba v roce 2026 skončila. Buď budete umět vytvořit dobré zadání, nebo si budete muset hledat niku, kterou AI kodér neumí obsloužit. A těch bude čím dál míň.

Je to posun od psaní kódu k psaní pokynů, od kladení cihel k architektuře, a pokud patříte k vývojářům, kteří stále věří, že jim budou firmy platit za to, že píšou kód, tak jste přesně tou ohroženou skupinou.

Možná najdete místo tam, kde je potřeba ruční práce, kde se dělají aplikace, co musí být vysoce optimalizované, vysoce spolehlivé a tak, ale ruku na srdce - to jen ti nejlepší. Ostatní čeká velmi škaredé procitnutí ze snu jménem “Umím programovat, to mi vystačí na celoživotní pohodlnou a dobře placenou kariéru”. Obávám se, že posun od kodéra k architektovi a teamleadovi je pro většinu včerejších vývojářů nevyhnutelný.

Nebojte. Není to nemožné. Jen je to jiné. Snad v tom naleznete zalíbení, jako já. Držím palce.

A pokud se vám bude stýskat po drcení instrukcí, jsou tu pořád ještě jednočipy!