Agentní produkty: od psaní kódu k definování cílů a bezpečné autonomii

Analyzováno: 1 dokument / 2747 slov

Executive Summary

• Při vývoji s AI se psaní kódu od nuly z velké části automatizuje. Člověk však zůstává odpovědný za čtení, ověření a revizi výsledku; jeho práce se přesouvá k definování problému, návrhu systému a práci s uživateli.
• Agent není jen chatbot ani autocomplete. Má pracovat se soubory a nástroji, spouštět příkazy, volit mezikroky a provádět akce v prostředí.
• Produktový tým má nejprve ověřit hodnotu s nejschopnějším dostupným modelem, sledovat neplánované použití produktu a teprve následně optimalizovat náklady, rozhraní a provozní architekturu.

Core Knowledge

Automatizace syntaxe nemá nutně snižovat poptávku po softwaru. Zdroj ji spojuje s Jevonsovým paradoxem: když zlevní tvorba kódu, organizace mohou vytvářet více systémů a řešit složitější problémy. Hodnota lidské práce se posouvá od mechanické implementace k architektuře, produktovému úsudku, porozumění uživatelům a kreativnímu řešení problémů.

Tento posun oslabuje hranice mezi tradičními funkcemi. Role vývojáře, produktového manažera, designéra a datového vědce se mohou sbližovat do obecnější role Buildera: člověka, který dokáže s AI navrhnout a realizovat řešení napříč disciplínami. Zdroj uvádí, že kód mohou psát i lidé mimo inženýrské role, zatímco inženýři se mohou více věnovat návrhu produktu, výzkumu a architektuře.

Agentní práce místo konverzace

Skutečný agent jedná v pracovním prostředí. Má přístup k souborům, příkazům a dalším nástrojům, aby mohl problém diagnostikovat, dohledat si kontext a provést vícefázový postup. Při řešení memory leaku například agent pořídil heap snapshot, vytvořil vlastní analytický program, identifikoval příčinu a připravil pull request s opravou.

Pracovní workflow pro komplexní technický problém:

1. Definujte agentovi cíl.
2. Poskytněte relevantní soubory a nástroje.
3. Nechte agenta provést diagnostiku a určit mezikroky.
4. Nechte jej připravit opravu a pull request.
5. Výstup přečtěte, ověřte a zrevidujte.

Claude Code je ve zdroji popsaný jako agentní nástroj pro práci s kódem, soubory, příkazy a autonomními akcemi. Mezi součásti uvedeného ekosystému patří také MCP, Model Context Protocol. Plan Mode naopak podporuje řízenější postup: model nejprve navrhne strategii, uživatel ji projedná a schválí, a až poté model implementuje řešení.

Návrh produktu pro rychle se měnící modely

Claude Code začal jako terminálový nástroj. CLI bylo pro sólo vývoj rychlou a úspornou cestou k prototypu a zároveň se snáze přizpůsobovalo rychle se měnícím schopnostem modelů než silně stylizované grafické rozhraní. Jednoduchost prvního rozhraní proto není nedostatek, pokud umožňuje rychle ověřit hodnotu.

Produkt nemá být navržen jen podle aktuálních limitů modelu. Zdroj doporučuje přemýšlet přibližně šest měsíců dopředu a sázet na růst schopností obecných modelů místo budování rozsáhlého specializovaného scaffoldingového systému. Současně je nutné průběžně ověřovat reálné limity nasazení, protože dlouhé autonomní běhy nemusí být ve všech situacích stejně spolehlivé.

Latentní poptávka a přístupnější rozhraní

Latentní poptávka vzniká, když lidé produkt opakovaně používají jinak, než předpokládal původní návrh. Zdroj považuje takové chování za podstatný produktový signál. Uživatelé Claude Code jej využívali i pro neprogramátorské činnosti, například analýzu dat nebo práci s fotografiemi, což se stalo podnětem pro CoWork.

Důležitý signál představuje ochota uživatelů překonávat nepohodlí rozhraní. Když neprogramátor instaluje Node.js a používá terminál jen proto, aby získal hodnotu z agenta, problém nemusí být v potřebě, ale v přístupnosti produktu. CoWork je ve zdroji uveden jako desktopové rozhraní nad stejným agentem a modelem, určené i pro neprogramátorské úlohy.

Workflow pro ověření latentní poptávky:

1. Sledujte používání mimo původní účel produktu.
2. Hledejte opakující se alternativní scénáře.
3. Zjistěte, zda uživatelé kvůli výsledku překonávají výrazné překážky.
4. Zvažte přístupnější rozhraní, novou funkci nebo samostatný produkt.

Autonomie, kontext a náklady

Modelu je vhodné zadat jasný cíl a zpřístupnit mu nástroje, nikoli jej předem zatížit obrovským kontextem a rigidní posloupností kroků. Agent si má podle potřeby vyhledat přesný kontext, například pomocí vyhledávání nebo práce se soubory. Rigidní workflow a přetížený prompt mohou omezit schopnost modelu adaptovat postup na skutečný problém.

Při objevování nového AI use casu zdroj doporučuje nezačínat optimalizací tokenů a API nákladů. Nejdříve je třeba potvrdit, že případ použití přináší hodnotu, ideálně s nejschopnějším dostupným modelem. Teprve potom lze úlohy přesunovat na levnější modely, například z Opus na Haiku nebo Sonnet. Vyšší cena modelu sama o sobě neznamená vyšší celkové náklady, pokud levnější varianta vyžaduje více kroků, oprav nebo tokenů.

Omezení zdrojů může být prostředkem k automatizaci. Zdroj popisuje přístup, kdy je velkému projektu záměrně přidělen jediný člověk nebo omezené financování, aby byl nucen intenzivně automatizovat vlastní práci pomocí Claude. Tento princip označuje jako „Claudify“.

Bezpečnost aktivních agentů

Agent, který vykonává akce na počítači, vyžaduje bezpečnostní opatření ve více vrstvách:

• interpretovatelnost a alignment na úrovni modelu,
• laboratorní evaluace v syntetických scénářích,
• sledování chování při reálném používání,
• izolované prostředí, například virtuální stroj nebo execution sandbox.

Zdroj uvádí, že Claude Code byl před veřejným vydáním několik měsíců interně testován. Execution sandbox má vymezit hranice agenta a chránit lokální operační systém před neoprávněným přístupem.

Decision Rules

• Pokud se nástroj rychle vyvíjí a potřebujete rychle ověřit prototyp, pak začněte nejjednodušším funkčním rozhraním, například CLI, místo budování komplexního UI.
• Pokud agent řeší složitý technický problém, pak mu poskytněte nástroje, soubory a možnost spouštět příkazy; neposuzujte jej jen jako chatovací rozhraní.
• Pokud hodnota AI use casu ještě není potvrzená, pak použijte nejschopnější dostupný model a optimalizaci nákladů odložte až po ověření přínosu.
• Pokud uživatelé produkt opakovaně používají mimo původní účel, pak berte tento vzorec jako signál latentní poptávky pro nové rozhraní, funkci nebo produkt.
• Pokud agent může autonomně zasahovat do počítače, pak kombinujte více vrstev bezpečnostního ověřování s izolovaným prostředím.
• Pokud navrhujete workflow pro obecný model, pak definujte cíl a dostupné nástroje, ale ponechte modelu prostor pro volbu mezikroků a načtení kontextu na vyžádání.
• Pokud plánujete dlouhodobou produktovou architekturu, pak ji navrhujte s ohledem na očekávaný posun schopností modelů, nejen podle jejich dnešních omezení.

Quality Criteria

Checklist

• Je zřetelně oddělen cíl úlohy, poskytnuté nástroje, autonomní kroky agenta a lidské ověření?
• Má model možnost získávat kontext pomocí nástrojů místo přetíženého vstupního promptu?
• Počítá návrh s růstem schopností modelů, aniž by ignoroval současné provozní limity?
• Byla hodnota use casu ověřena před optimalizací nákladů?
• Je aktivní agent bezpečnostně testován a provozován v izolovaném prostředí?
• Zohledňuje produktový návrh opakované alternativní použití ze strany uživatelů?

Red flags

• Komplexní a stylizované UI vzniká dříve než funkční prototyp a ověření hodnoty.
• Model slouží jen jako autocomplete nebo jednoduchý chatbot.
• Tým omezuje tokeny či API náklady předtím, než zjistí, zda use case přináší hodnotu.
• Agent dostává neměnnou sekvenci kroků bez možnosti samostatné práce s nástroji.
• Autonomní agent běží bez sandboxu, izolace a vícevrstvého testování.

Benchmarky

• Dobrá úroveň: Agent samostatně získá diagnostická data, vytvoří pomocný analytický program, najde problém a navrhne opravu, kterou člověk kontroluje. Slabá úroveň: Člověk ručně provádí diagnostiku a model používá jen k doplňování syntaxe.
• Dobrá úroveň: Tým sleduje neplánované používání produktu a podle opakujícího se vzorce odstraní překážku přístupnějším rozhraním. Slabá úroveň: Tým alternativní použití ignoruje, protože není součástí původní specifikace.
• Dobrá úroveň: Use case se nejprve prověří s nejlepším modelem a až poté se hledá levnější varianta. Slabá úroveň: Tým začíná slabším modelem kvůli ceně, aniž by ověřil hodnotu řešení.

Edge Cases

• Omezená délka autonomního běhu: Zdroj rozlišuje dřívější kratší běhy s nutným dohledem a novější delší autonomní běhy. Produkt lze architektonicky připravovat na delší runtime, ale aktuální nasazení je třeba testovat v rozsahu odpovídajícím současným schopnostem.
• Číselné údaje o spokojenosti: Zdroj zmiňuje procenta průzkumu, jejichž součty se v poznámkách mohou lišit od sta procent, bez dalšího vysvětlení. Tento blok proto neposkytuje použitelný benchmark pro rozhodování.

Metadata

• Celkový počet zdrojů: 1
• Pokrytí: 93 %
• Důvěryhodnost: vysoká - knowledge pack vychází z jednoho rozsáhlého zdroje s hustými poznámkami k produktové filozofii, workflow, bezpečnosti, organizaci i praktickému používání; externí validace tvrzení provedena nebyla.
• Zdroj 1: Head of Claude Code: What happens after coding is solved | Boris Cherny - https://www.youtube.com/watch?v=We7BZVKbCVw