Od ticketu k merge requestu: jak u mě AI vyřídí celou opravu sama

Ticket od zákazníka byl roky moje noční můra. Někdo si na něco stěžuje nebo má nápad — a ty to musíš přečíst, pochopit, naplánovat, naprogramovat, otestovat, a teprve pak nasadit. U každého ticketu znovu. Věčné přeskakování mezi úkoly, které ti rozseká celý den.

Takhle to nedělám už několik měsíců. Vyřizuje to za mě AI — celý ticket, od zadání po merge request.

Jak to vypadá v praxi

Zákazník napíše, co ho štve nebo co by chtěl jinak. To je celý můj vstup. Zbytek se stane beze mě:

1. Agent si to naplánuje. Rozloží požadavek na konkrétní kroky a najde v kódu místa, kterých se to týká.
2. Naprogramuje to. Napíše změnu — ne jeden řádek, ale celou úpravu napříč kódem.
3. Sám si to zkontroluje. Spustí build i testy, projde si vlastní výstup a opraví, co nesedí.
4. Otevře merge request. S popisem, co udělal a proč.

A tím jeho práce končí. Dál už je to na mně.

Co na tom dělám já

Přečtu si finální merge request. To je celá moje práce na tom ticketu.

Rozhoduju jedinou věc: líbí se mi to řešení? Dává smysl to, co zákazník navrhl, a sedí mi způsob, jakým to agent vyřešil? Když ano, sloučím to — a změna jde na testovací prostředí nebo rovnou do produkce. Když ne, řeknu agentovi, co je špatně, a on otevře nový merge request.

Nepíšu kód. Posuzuju ho.

Tenhle web jede přesně takhle

Nemusíš mi věřit na slovo. Web, na kterém tohle čteš, běží na stejném principu. Práci zadávám přes GitLab Issue — napíšu, co chci. Agent to naplánuje, naprogramuje a otevře merge request. A když to nepotřebuje zvláštní schválení, jakmile ho sloučím, samo se to nasadí do produkce. Žádné ruční nasazování, žádné „pak to někdy nahraju”.

A přesně takhle vznikl i článek, který právě čteš: zadání → agent → merge request → moje kontrola → produkce.

Kde to funguje a kde ne

Nebudu předstírat, že tohle jede všude. Nejede.

• Funguje to na ohraničených, opakovatelných změnách s jasným „hotovo”: oprava chyby, úprava chování, menší nová funkce, obsah. Tam, kde má agent rychlou zpětnou vazbu — build, testy, náhled — pozná sám, že je hotovo.
• Nefunguje to tam, kde je „hotovo” otázka vkusu, firemní politiky nebo kontextu, který agent prostě nemá. Velká architektonická rozhodnutí, citlivé zásahy do produkce, cokoli, kde chyba stojí měsíce — tam pořád rozhoduje člověk.
• A nikdy bych nepustil agenta do produkce bez té kontroly. To „mně se to líbí” není formalita. Je to ta hlavní pojistka.

Proč o tom píšu zrovna teď

Protože přesně tohle učím. Vypsal jsem workshop Stavíme AI agenty (25. 6., Praha) — pět hodin, kde si každý postaví vlastního agenta na svém vlastním zadání. A nejde jen o to agenta postavit. Dotkneme se i toho, jak ho provozovat: jak ho zapojit do reálného provozu (klidně přes issue → merge request), kde nechat lidskou pojistku a kde mu naopak dát volnost.

Pokud tě při čtení napadlo „tohle bych chtěl umět taky” — přesně na to je ten workshop.

Mohlo by tě zajímat

• AI agenti nejsou připravení pro tvůj byznys
• Skills vs. agenti: Kdy ti stačí recept a kdy potřebuješ kuchaře
• Loop: autonomní agent v terminálu