Tři páky, které nikdo neřeší

Budiž vám upřímnost dovolena. Pravděpodobně jste někdy vyzkoušeli code agenta, sledovali, jak napíše funkci nebo dvě, a řekli si „To je v pohodě." Pak jste ho ale zkusili použít na něco skutečného – na něco, na čem záleží – a narazili na zeď.

Třeba začal vymýšlet API, která neexistují. Možná opravil bug na jednom místě a rozbil tři další. Nebo prostě jen seděl, točil se a čekal, až mu vysvětlíte, co vlastně chcete. Známé?

Tady je ta nepříjemná pravda: agent není rozbitý. Jen ho prostě nepoužíváte správně.

Konkrétněji – pravděpodobně taháte jen za jednu páku, když máte k dispozici tři.

Tři páky, o kterých se nemluví

Každý code agent, ať už používáte Claude Code, Cursor, Copilot nebo cokoliv jiného, funguje na stejném základním principu. Přijímá informace, něco s nimi dělá a pak dostává zpětnou vazbu. A to je celé. Stroj jako takový.

Ale tady je místo, kde většina lidí chybuje – optimalizují jednu nebo dvě z těchto pák a třetí úplně ignorují. A v produkčním inženýrství se z té chybějící páky stává váš strop.

Rozepišme si to.

VIDĚT: Co váš agent ve skutečnosti ví?

Z výroby váš agent vidí váš kód a shell. Nic víc. Neví nic o编码 standardech vašeho týmu. Neví o tom zvláštním workaroundu, který váš seniorní inženýr přidal před třemi lety pro legacy integraci. Neví, jak vypadá "hotovo" pro váš konkrétní projekt.

Když mluvím s týmy, které se potýkají s AI-asistovaným vývojem, problém je téměř vždy kontext. Agent létá naslepo. Napíše kód, který technicky funguje, ale neodpovídá patternům vaší codebase, ignoruje vaše konvence pojmenování nebo znovu vynalézá kolo, které váš tým už dávno vyřešil.

Oprava? Zabalte svůj kontext, jako byste předávali práci novému juniorskému developerovi. Jaké soubory by měl číst jako první? Jaké konvence jsou důležité? Jak vypadá vaše architektura? Většina nástrojů má způsoby, jak toto injektovat – system promptsy, reference na dokumentaci, skill soubory. Používejte je.

JEDNAT: Co váš agent ve skutečnosti může dělat?

Tady to začíná být zajímavé. Základní agent umí editovat soubory a spouštět testy. Nakonfigurovaný agent umí dotazovat API, kontrolovat CI status, číst Slack vlákna nebo interagovat s vaší cloudovou infrastrukturou.

Čím víc akcí má váš agent k dispozici, tím méně musíte manuálně přemosťovat mezery. Chcete, aby váš agent ověřil, že deployment skutečně fungoval, než zavře ticket? Potřebuje přístup ke cloudové konzoli. Chcete, aby komunikoval s kolegy? Potřebuje přístup ke komunikačním kanálům.

Tady nejde o stavbu sci-fi AI overlorda. Jde o odstranění manuální práce při přepínání mezi nástroji. Každý alt-tab je hand-off, kde se ztrácí kontext. Čím víc může váš agent dělat autonomně v rámci vašeho workflow, tím těsnější ta smyčka je.

OPRAVIT: Jak agent pozná, že udělal chybu?

Toto je páka, kterou většina týmů úplně zanedbává, a je to důvod, proč jejich agenti působí ненадёжно.

Váš agent potřebuje zpětnou vazbu. Ne jen "tento kód nefunguje", ale nuancované signály o kvalitě, stylu a záměru. Lintery chytají syntaktické problémy. Testy chytají funkční selhání. Code review chytá architektonické problémy. Ale váš agent nemůže reagovat na zpětnou vazbu, kterou nikdy nedostane.

Nechte si to vysvětlit jinak: každá automatická oprava, se kterou se váš agent setká, je learning moment. Každá ignorovaná chyba je promarněná příležitost. Čím těsnější vaše feedback loops, tím rychleji se váš agent zlepšuje.

Tady mnoho týmů pokulhává. Spouštějí testy manuálně, kontrolují linty sporadicky a reviewují kód, když si vzpomenou. Ale aby byl váš agent spolehlivý, tyto kontroly musí být automatické a rychlé. CI pipeliny, které trvají 45 minut, jsou pro produktivitu agenta smrtící. Okamžitá zpětná vazba? Tam se děje kouzlo.

Princip nejslabšího článku

Tady je mentální model, který změnil můj pohled na věc:

Představte si tři sloupce. Jeden pro Vidět, jeden pro Jednat, jeden pro Opravit. Celková schopnost vašeho agenta je omezena tím nejkratším sloupcem.

Viděl jsem týmy, které nalily zdroje do toho, aby jejich agenti psali lepší kód (Jednat), ale nikdy agentovi nedali správný kontext (Vidět), takže pořád dělali stejné chyby. Viděl jsem týmy, které postavily propracované feedback systémy (Opravit), ale agent neměl přístup k informacím, které potřeboval, aby tu zpětnou vazbu aplikoval (Vidět). V každém případě byl bottleneckem ten článek, o kterém nikdo neuvažoval.

Toto není jen intuice. Je to strukturální omezení jakéhokoliv systému, který vnímá prostředí, jedná na základě něj a přizpůsobuje se. Pomyslete na reinforcement learning systémy – potřebují observaci (VIDĚT), action space (JEDNAT) a reward signals (OPRAVIT). Odeberte jakýkoliv jeden a systém degraduje. Váš code agent je na tom stejně.

Co to znamená pro váš tým

Pokud hodnotíte code agenty pro produkční práci, netestujte je jen na ukázkových příkladech. Prožeňte je scénáři, které zatěžují všechny tři páky:

• Umí agent získat kontext, který potřebuje k pochopení vaší codebase?
• Umí agent provádět akce, které zapadají do vašeho reálného workflow?
• Dostává agent zpětnou vazbu dostatečně rychle na to, aby mohl korigovat kurz?

Pokud je odpověď na kteroukoliv z těchto otázek "vlastně ne", tam směřujte svoji investici.

Pro engineering leady a architekty: nejde o nalezení správného nástroje. Jde o stavbu správného systému. Nástroj je jen motor. Páky jsou převodovka, palivový systém, chladicí systém. Ferrari s chybějícím kolem není supersport – je to rozbitý vůz.

Větší obrázek

Stále jsme early stage éry AI-asistovaného vývoje. Týmy zjišťují, že hodit code agent na problém nestačí. Týmy, které získají největší hodnotu, nejsou ty s nejnáročnějšími modely – jsou to ty, které postaví nejtěsnější smyčky mezi viděním, jednáním a opravováním.

Takže než budete vinit nástroj za zklamání výsledky, podívejte se poctivě na svoje páky. Která je nejkratší? Tam je vaše příležitost.