Agent nemá jen tvořit aplikaci. Musí ji umět sám zkontrolovat

TL;DR:

• Praktický posun u agentského vývoje není jen rychlejší psaní kódu, ale vlastní kontrolní smyčka před předáním člověku.
• Nové nástroje v datasette-apps ukazují, jak může agent otevřít aplikaci v prohlížeči a ověřit její chování pomocí JavaScriptu, tedy programovacího jazyka pro webové stránky.
• Rychlý kontrolní test funkčnosti pomůže zachytit rozbité tlačítko, prázdnou obrazovku nebo špatně rozmístěné prvky dřív, než výsledek skončí u uživatele.
• Pro malé týmy je důležitý hlavně levný mezikrok: agent vytvoří změnu, provede základní ověření a člověk řeší až smysl a rizika.
• Sandboxovaný iframe, tedy oddělené vložené okno stránky, není náhrada bezpečnostní kontroly, ale může být užitečný pracovní filtr.

Představ si, že necháš agenta vytvořit malou interní aplikaci nad firemními daty. Zadání je jednoduché: zobraz seznam záznamů, přidej filtr, ukaž detail a umožni rychlou úpravu poznámky. Agent vrátí kód, textově popíše, že je hotovo, a na první pohled to zní použitelně.

Jenže práce nekončí tím, že něco existuje v souboru. Skutečná otázka zní jinak: otevře se obrazovka, funguje tlačítko, vejde se text do prvku, nezmizel obsah pod hlavičkou, nevznikla chyba až při běhu aplikace? Právě tady se láme rozdíl mezi agentem jako generátorem návrhů a agentem jako součástí pracovního procesu.

Teze je jednoduchá: agentské nástroje začnou být opravdu užitečné ve chvíli, kdy dostanou vlastní smyčku mezi vytvořením a předáním. Ne finální pravomoc. Ne slepou důvěru. Jen schopnost otevřít výsledek, udělat základní kontrolu a vrátit konkrétní chybu.

Kontrola v prohlížeči je jiná než hezký popis

U textových úloh se dá chyba často poznat čtením. U malé webové aplikace to nestačí. Agent může správně vypsat, co chtěl změnit, a přesto dodat rozhraní, které se v prohlížeči rozpadne. Chybí mu totiž kontakt s tím, co uživatel skutečně uvidí.

V nové verzi datasette-apps 0.2a0 přibyl nástroj app_debug() pro ladění aplikace. Ten umožňuje agentovi neviditelně otevřít aplikaci a testovat ji pomocí JavaScriptu. Technicky se stránka zobrazí v iframe, tedy vloženém okně stránky, které má nastavenou nulovou viditelnost a nejde na něj klikat. Agent pak uvnitř odděleného prostředí spustí dodaný JavaScript.

To je důležitý detail. Nejde jen o další textovou odpověď typu „vypadá to správně“. Agent může ověřit, že se stránka načetla, že hlavní prvky existují, že mají očekávané rozměry nebo že se po interakci něco opravdu stane. Taková kontrola není hluboké testování celé aplikace. Je to rychlý kontrolní test funkčnosti, který má odhalit zjevné chyby před ruční kontrolou.

Malý tým potřebuje levnou brzdu před předáním

Největší praktický dopad je u malých interních nástrojů. Tam se často netvoří velká testovací infrastruktura. Jeden člověk nebo malý tým chce rychle vyrobit pomocnou aplikaci pro data, provoz, obsah nebo podporu rozhodování. Agent dokáže dodat první verzi rychle, ale bez ověření se práce přesouvá na člověka: otevři, klikni, oprav, vrať, zopakuj.

Lepší smyčka vypadá střízlivěji. Interní datový tým nechá agenta vytvořit aplikaci nad databází. Agent si potom sám otevře hlavní obrazovku, ověří filtr, detail a základní rozložení stránky. Pokud najde prázdný výpis nebo tlačítko bez reakce, nehlásí obecné „hotovo“, ale konkrétní problém. Člověk pak nezačíná od nuly. Dostává výsledek, který už prošel hrubým sítem.

Podobně může produktový nebo provozní tým používat agentský postup pro rychlé prototypy přehledových obrazovek. Agent změří, jestli se prvky nevejdou mimo plochu, zkontroluje viditelnost důležitých hodnot a upozorní, že se něco chová jinak, než zadání očekávalo. Přínos není v tom, že by agent nahradil úsudek. Přínos je v tom, že ruční kontrola nemusí chytat úplné základy.

Oprávnění jsou součást pracovního návrhu

Druhý nový prvek, nástroj app_list() pro výpis editovatelných aplikací, působí méně efektně, ale pro praxi je stejně důležitý. Agent potřebuje vědět, které aplikace smí upravovat. Bez toho by práce snadno sklouzla do ručního kopírování odkazů, nejasných oprávnění a hádání, co je správný cíl změny.

Ve zdravém agentském procesu má být jasné, kam agent smí sahat. Vývojář může nastavit krok, ve kterém agent získá seznam povolených aplikací, vybere tu správnou podle zadání, provede změnu a ověří ji v sandboxovaném iframe. Tím se zmenšuje prostor pro omyl. Ne proto, že by systém byl najednou bezpečný ve všech směrech, ale proto, že proces má konkrétní hranice.

Tohle je dobrý vzor i mimo konkrétní nástroj. Pokud dáváš agentovi právo měnit interní aplikace, neměl by pracovat v mlze. Potřebuje seznam povolených cílů, jasně omezený prostor pro test, výstup s nalezenými chybami a následnou lidskou kontrolu.

Sandbox není razítko bezpečnosti

Je lákavé přecenit slovo sandbox. Oddělené vložené okno stránky pomáhá izolovat testovací běh a brání běžné interakci uživatele s neviditelným obsahem. To ale samo o sobě neznamená, že je vyřešená bezpečnost, oprávnění, práce s citlivými daty nebo dopad špatně navrženého agentského kroku.

Proto má lidská kontrola zůstat ve hře. Agent může najít rozbité rozhraní, změřit prvky a ověřit základní chování. Člověk má rozhodnout, jestli aplikace dává smysl, jestli zobrazuje správná data, jestli je vhodné ji ukázat dalším lidem a jestli agent neudělal změnu, která je sice technicky funkční, ale pracovně špatná.

Rozumné pravidlo zní: agent smí automaticky kontrolovat mechanické věci, které jsou levné na ověření. Člověk má držet rozhodnutí, která mění význam práce, přístup k datům nebo odpovědnost za výsledek.

Jak tenhle princip použít už teď

Nemusíš čekat na dokonalou agentskou platformu. Vezmi jeden interní postup, kde agent vytváří nebo upravuje malý nástroj, a doplň mezi vytvoření a ruční kontrolu povinný ověřovací krok. Napiš tři až pět kontrolních otázek: načte se hlavní obrazovka, existuje hlavní tlačítko, reaguje filtr, jsou vidět klíčové hodnoty, nevznikla chyba při běhu?

Potom chtěj po agentovi konkrétní výstup. Ne „aplikace funguje“, ale seznam provedených kontrol a nalezených problémů. Pokud používáš prostředí, které umí spustit kontrolu v prohlížeči, přidej ji. Pokud ne, začni aspoň tím, že agent musí popsat, co přesně by mělo být ověřeno ručně. I to posune práci od slepé důvěry k ověřitelné smyčce.

Důležitý není název konkrétní funkce. Důležité je pracovní pravidlo: agent, který něco vytváří, má nést část odpovědnosti za první kontrolu. Ne aby nahradil člověka, ale aby člověk nemusel dělat práci, kterou může levně a opakovaně udělat stroj.

Zdroj

Simon Willison: datasette-apps 0.2a0 https://simonwillison.net/2026/Aug/1/datasette-apps/#atom-everything