Metodu short leash letos pojmenoval Greg Slepak z okTurtles, ale zajímavé na ní není autorství. Zajímavé je, že jde proti dominantnímu snu roku 2026: pustit AI agenta na repo, zmizet od klávesnice a čekat na hotový výsledek. Short leash říká pravý opak. Čím schopnější agent je, tím těsněji ho má člověk vést.
To nezní sexy. Zato to dává smysl.
Nosná myšlenka je jednoduchá: agent není samostatný vývojář, ale rychlý vykonavatel uvnitř velmi úzkého rámce. Člověk určuje směr, rozděluje práci, schvaluje zásahy, zastavuje špatné odbočky a nakonec nese odpovědnost za každou řádku. Tohle není jen kulturní odpor vůči vibe codingu. Je to konkrétní provozní metoda pro týmy, které nechtějí zaměnit tempo za chaos.
Metoda stojí na šesti opěrných bodech
Když se z short leash odstraní slovní omáčka, zůstane šest praktických pravidel. Nejprve plánovat a dělit úkoly na malé kroky. Nedovolit agentovi pracovat v režimu, kde obchází oprávnění. Číst diffy ještě před aplikací změn. Zasahovat hned, jakmile se agent utrhne od zadání. Commitovat po menších podúkolech. A nakonec udělat review, které je opravdu review, ne razítko.
Každý ten bod míří na jiný druh selhání. Plánování míří na rozpad záměru. Oprávnění a diffy míří na nežádoucí zásahy. Časté commity chrání před regresí a přepsáním už hotové práce. Review míří na to nejzrádnější: kód sice běží, ale architektonicky nebo bezpečnostně je špatně.
Právě proto dává smysl tuhle metodu rozpitvat po částech. Její síla totiž neleží v jedné velké myšlence, ale v tom, že zavádí několik menších brzd na místa, kde agenti typicky selhávají.
První brzda je plánování po malých kusech
Short leash nezačíná generováním kódu. Začíná rozsekáním úkolu. To je důležitější, než vypadá. Jakmile agent dostane moc široké zadání, začne si doplňovat chybějící záměr sám. A právě tady vzniká velká část pozdějšího balastu: zbytečné abstrakce, předčasná generalizace, změny mimo scope nebo opravy věcí, o které nikdo nestál.
V praxi to znamená, že člověk agentovi nepředává “udělej onboarding”, ale třeba “přidej validaci do kroku registrace”, “uprav text chybové hlášky” nebo “dopiš test pro konkrétní edge case”. Cíl je prostý: zmenšit prostor, ve kterém si model může špatně domyslet zbytek světa.
Tohle pěkně sedí na zjištění ze studie “Human oversight of agentic systems in practice” z června 2026. Autoři popisují, že vývojáři nepoužívají dohled jen jako závěrečnou pojistku, ale už předem osekávají prostor rozhodnutí, ve kterém se agent může pohybovat. Jinak řečeno: dobrý dohled nezačíná u review, ale u zadání.
Kdo tenhle krok přeskočí, často si koleduje o problémy, které se později špatně hledají. Kód pak nemusí být vyloženě rozbitý. Jen začne nenápadně uhýbat od toho, co tým skutečně chtěl.
Druhá brzda je zákaz slepého režimu
Jedno z nejtvrdších pravidel short leash metody zní skoro banálně: žádný YOLO mód, žádné automatické přeskakování oprávnění, žádné “nějak to proběhne”. To je přesně ten moment, kde se z pohodlného workflow stává bezpečnostní problém.
Jakmile agent dostane možnost měnit soubory, spouštět příkazy a přepisovat části projektu bez průběžného lidského zásahu, přestává být asistent a začíná být samostatným aktérem s velmi slabou odpovědností. Člověk pak sice formálně zůstává “u toho”, ale reálně už jen dohání, co se stalo.
Tohle není teoretická obava. Studie “Coding with ‘Enemy'” z června 2026 ukázala, že 94 % účastníků neodhalilo sabotáž v kódu během delší spolupráce s frontier modely. Hlavní roli v tom hrála přehnaná důvěra, slabé review a ochota pustit model dál, protože jeho kroky na první pohled působily normálně. Přesně tady short leash říká: ne, každé větší rozhodnutí má projít lidským sítem.
V tom je mimochodem dost tvrdá lekce. Největší riziko agentů nemusí být spektakulární chyba. Často to bude série docela rozumně vypadajících kroků, které dohromady odvedou projekt bokem.
Třetí brzda jsou diffy jako pracovní paměť
Jedna z nejpraktičtějších částí metody je průběžné čtení diffů ještě předtím, než se změny zapíšou napevno. Tohle není jen kontrola proti průšvihu. Je to způsob, jak si udržet živé porozumění kódu.
Když člověk pracuje s agentem bez diffů, snadno sklouzne do role zadavatele. Ví, co chtěl, ale neví přesně, co se změnilo. Jakmile naopak čte každý návrh jako malý patch, zůstává v obraze: vidí, které soubory se hýbou, jak agent přemýšlí o závislostech, kde zkouší příliš široký zásah a kde naopak míjí důležitý detail.
To je podceňovaná věc. U lidského kolegy považujeme za normální, že si změnu přečteme. U agenta se to často vydává za brzdu produktivity. Jenže bez toho se vývojář rychle mění v člověka, který vlastní repozitář, ale ztrácí mentální model systému.
Short leash tedy nepoužívá diffy jen jako bezpečnostní závoru. Používá je jako pracovní paměť. A to je chytré.
Čtvrtá brzda je okamžitý zásah při odchýlení
Metoda nepočítá s tím, že agent dostane úkol a člověk se ozve až na konci. Počítá s častým přerušováním. Jakmile se model utrhne, mění scope, zavádí podivnou abstrakci, přepisuje něco mimo zadání nebo míří k příliš velkému refaktoru, člověk má zasáhnout hned.
Tohle bývá pro část lidí nepříjemné, protože to ruší iluzi plné autonomie. Jenže právě včasný zásah je levný. Pozdější oprava drahá. Kdo nechá model dvacet minut produkovat změny špatným směrem, nešetří čas. Jen si odkládá účet.
Práce o lidském dohledu nad agentickými systémy tenhle vzorec potvrzuje docela přesně. Vývojáři v ní popisují nejen post hoc kontrolu, ale i průběžné monitorování a co-planning. Dohled tedy není něco, co se přidá nakonec. Je to samotná forma spolupráce.
Pro dlouhé a složité úkoly je to klíčové. Čím delší běh bez zásahu, tím větší šance, že člověk později ani nepozná, kde se agent odchýlil od původního záměru.
Pátá brzda je commit discipline
Short leash klade důraz i na commity po každém podúkolu. To se může zdát jako obyčejná git hygiena, ale u agentů to má větší váhu než u lidí. Modely mají nepříjemný sklon přepisovat i to, co už jednou fungovalo, případně rozšířit zásah do souborů, které měly zůstat být.
Častý commit tedy není jen archiv práce. Je to způsob, jak omezit poloměr výbuchu.
Když se agent utrhne, člověk se má kam vrátit. Když rozbije už hotovou část, škoda je malá. Když se ukáže, že poslední krok byl slepá ulička, není nutné rozmotávat dvouhodinovou šňůru změn. To je vlastně docela obyčejné pravidlo. Jen v agentickém vývoji nabírá na důležitosti, protože objem i rychlost změn jsou mnohem vyšší.
Tady bych čekal víc tvrdých dat, než zatím máme. Ale řemeslně to sedí skoro dokonale. Čím levnější je návrat o krok zpět, tím bezpečnější je pustit agenta o krok dopředu.
Šestá brzda je review, které není divadlo
Nejcitlivější část celé metody přichází na konci: review. A ne ledajaké. Ne formální pohled na zelený test. Ne rychlé “vypadá to dobře”. Ale review vedené s předpokladem, že AI-assisted PR je ve skutečnosti návrh od nestálého spolupracovníka, který umí být brilantní i úplně mimo během stejné hodiny.
Tady má short leash velmi silnou oporu ve výzkumu. Studie “Human-AI Synergy in Agentic Code Review” z března 2026 ukazuje, že lidé do review přinášejí věci, které AI běžně nedává: porozumění záměru, testovací úvahy, přenos znalosti a vyšší kontext rozhodnutí. Zároveň platí, že návrhy od AI po přijetí častěji zvětšují složitost i velikost kódu. AI tedy může najít chybu, ale velmi snadno do kódu protlačí zbytečný objem.
Podobně vyznívá i dubnová práce “From Industry Claims to Empirical Reality”. Pull requesty hodnocené jen code review agenty mají nižší míru mergů a vyšší podíl opuštěných změn než ty s lidskou účastí. To je důležitý studený hadr na představu, že automatický reviewer nahradí seniora.
A pak je tu ještě jedna nepříjemně praktická věc. Studie “Do AI Coding Agents Log Like Humans?” z dubna 2026 ukazuje, že lidé dělají 72,5 % následných oprav v oblasti logování a observability. Přesně tohle jsou změny, které v rychlém review snadno zapadnou, protože aplikace na první pohled funguje. Jenže v produkci pak chybí stopy, měření, diagnostika. Žádná sláva.
Metoda je silná v procesu, slabší v některých velkých slibech
Na short leash metodě je cenné hlavně to, jak přesně míří na konkrétní selhání agentů. Není to filozofie “AI ano či ne”. Je to sada provozních omezení: jak zmenšit prostor chyb, jak včas odhalit odchylku a jak nedovolit, aby rychlost modelu zničila lidské porozumění.
Kde už je potřeba ubrat plyn, jsou některé širší závěry, které se kolem podobných metod rády nabalují. Tvrzení, že dnešní frontier modely v podstatě neumějí myslet mimo svá trénovací data, je příliš hrubé. Přesnější je říct, že v úzkých a specializovaných doménách nebo v komplexních vícesouborových úlohách výkon rychle padá. To podporují třeba práce “Are Frontier LLMs Ready for Cybersecurity?” a benchmark SWE-Bench Mobile. Ty neříkají, že modely nic neumějí. Říkají, že bez silného vedení, nástrojového rámce a oborového kontextu často nestačí.
Stejně opatrně je potřeba brát i rétoriku o tom, že dobrý proces porazí silnější model. Je to uvěřitelná hypotéza. Není to zatím veřejně doložený benchmark. Jako pracovní pravidlo pro tým dobré. Jako univerzální důkaz zatím ne.
Proč je tahle metoda relevantní právě teď
V roce 2026 se debata o agentech často láme do falešné volby. Buď plná autonomie, nebo zpátečnický odpor k AI. Short leash ukazuje třetí možnost: vysoká produktivita, ale pod pevným lidským vedením. Ne méně AI, ale méně iluzí o tom, co má dělat sama.
Tohle dobře zapadá i do širšího rámce omezené delegace. Práce “Authenticated Delegation and Authorized AI Agents” z ledna 2025 popisuje model, kde agent dostává přesně vymezené oprávnění, auditovatelný rozsah akce a jasnou vazbu na člověka, za kterého jedná. V překladu do vývoje: agent nesmí mít víc autonomie, než kolik jsme schopni rozumně zkontrolovat.
Stejnou logiku najdeš i v AI Usage Policy projektu group-income od okTurtles. AI je tam popsaná jako asistivní nástroj, ne náhrada úsudku. Každý AI-assisted PR musí být pochopený, důkladně zkontrolovaný a doplněný o disclosure použitých modelů. Povinný je i self-review po řádcích. To už není osobní preference jednoho autora. To je přepsaná provozní norma.
Co si z toho vzít do praxe
Pokud bych měl short leash převést do jedné věty, zněla by takhle: nenech AI agentovi prostor dělat důležitá rozhodnutí bez toho, aby ses na ně díval v okamžiku, kdy vznikají.
V praxi to znamená:
- zadávat malé, ostré podúkoly
- neschvalovat změny naslepo
- číst diffy jako průběžný patch, ne až jako hotové PR
- zasáhnout hned při první zbytečné odbočce
- commitovat často
- review vést s předpokladem, že funkční kód ještě nemusí být dobrý kód
Na tom není nic magického. A právě proto to funguje. Short leash není trik na obcházení slabin modelů. Je to pracovní disciplína, která s těmi slabinami počítá předem. V bezpečnostně citlivém nebo architektonicky složitém vývoji je to dnes mnohem realističtější cesta než sen o agentovi, který všechno vyřeší za nás.
Zdroje
- Greg Slepak: The Short Leash AI Coding Method For Beating Fable, okTurtles Blog, 2. července 2026
- okTurtles group-income: CONTRIBUTING.md / AI Usage Policy
- Human oversight of agentic systems in practice, arXiv, 3. června 2026
- Coding with “Enemy”: Can Human Developers Detect AI Agent Sabotage?, arXiv, 4. června 2026
- Human-AI Synergy in Agentic Code Review, arXiv, 16. března 2026
- From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests, arXiv, 3. dubna 2026
- Do AI Coding Agents Log Like Humans?, arXiv, 10. dubna 2026
- Authenticated Delegation and Authorized AI Agents, arXiv, 16. ledna 2025
- Are Frontier LLMs Ready for Cybersecurity?, arXiv, 22. května 2026
- SWE-Bench Mobile, arXiv, 10. února 2026
