Claude Code od pravidel přes testy a audit až ke schválení

48 tisíc řádků je vedlejší produkt

Rozbilo se šest dříve funkčních míst aplikace Parťák. Incident z veřejných zdrojů potvrdit ani vyvrátit nelze. Z diskuse však plyne, že bezpečné testy a audit pomohly odhalit slabiny, které samotný průběžný vývoj nezachytil.

Pilotní aplikace Parťák začala desítkami tisíc řádků kódu. Část tvořily testy a aplikace běžela v pilotním režimu. V diskuzi se ale několik lidí shodlo, že objem kódu ani označení „vibe coding“ nejsou hlavním přínosem.

Hlavní přínos tvoří opakovatelný postup: definovat pravidla, měřit chování testy, pravidelně provádět bezpečnostní audity a před zásadními změnami vyžadovat lidské schválení. Tento postup odhalí regrese a nežádoucí změny dříve, než se dostanou do produkce.

Z ověřených webů vyplynulo, že Parťák je česká platforma pro společné aktivity a výlety. Nyní běží jako uzavřený pilotní projekt po celé ČR pro pozvané a ověřené uživatele. Nabízí například turistiku, cyklistiku, běh, vinařské aktivity, kulturu nebo doprovod seniora. Uživatelé se přihlašují e-mailem a jednorázovým kódem; nové účty podle stránky ověřuje administrátor.

Parťák: uzavřený pilot české platformy pro společné aktivity a výlety.

Pravidla v CLAUDE.md nejsou pojistka

Komunitní postup lze odborněji nazvat in-context governance: pravidla a znalosti projektu jsou uložené v textovém souboru, který agent načítá do kontextu. V diskuzi se tento postup popisoval jednoduše jako „pravidla před kódem“ nebo „AI se chová jako kolega, ne autocomplete“.

CLAUDE.md má obsahovat architekturu, databázové konvence, oprávnění, testovací příkazy a definici hotové práce. Důležitější je však stručnost. Velký soubor se načítá do každé relace, zaplňuje kontextové okno a odvádí pozornost od nesouvisejících úkolů.

Model navíc nepovažuje CLAUDE.md za závazný zákon. Jde o další text v kontextu, který může přehlédnout zejména po dlouhé konverzaci nebo kompakci kontextu. Zadání „před změnou na serveru se zeptej“ proto není totéž jako technické zablokování nasazení.

Praktické know-how z diskuse spočívá v rozdělení kontextu: dlouhodobé projektové zásady patří do CLAUDE.md, zatímco konkrétní úkol, akceptační kritéria a bezpečnostní invarianty se mají uvést přímo v zadání.

Samostatné generování testovacích dat patří mezi užitečné projevy iniciativy agentů. V jednom případě programátorský agent při práci na aplikaci pro audioknihy vytvořil pomocí ffmpeg testovací zvuky a prázdný obrázek pro obálku, aniž by dostal přesný pokyn. Jde o instrumentalitu: agent doplnil chybějící fixture, aby mohl výsledek ověřit.

Nejde ovšem o automaticky bezpečnou vlastnost. Podobné zkušenosti z diskuse ukazují i případy, kdy agent vytvořil vlastní mapování pro Aseprite, navrhl úpravu aplikace nebo samostatně testoval svůj kód. Některé z těchto kroků byly přínosem, jiné se blížily nežádoucímu rozšiřování scope.

Testy jsou vnější kontrola, ne pocit bezpečí

Automatizované testy zde plní funkci deterministického harnessu: zadaná kontrola vrací jednoznačný výsledek pass/fail a může workflow zastavit, dokud test neprojde. To je podstatný rozdíl proti tomu, když AI pouze prohlásí implementaci za hotovou.

Použijte tři vrstvy:

• jednotkové testy pro izolovanou logiku;
• integrační testy nad databází a HTTP rozhraním;
• scénáře obchodní logiky, například souběžné potvrzení posledního volného místa.

Pro každý oprávněný invariant definujte očekávaný výsledek. Vyžadujte také, aby chybný vstup nikdy nekončil HTTP 500 a aby se do chyb ani logů nepropisovaly citlivé hodnoty.

Při práci s testovacími daty rozlište dvě situace. Fixture je deterministický artefakt, který patří do verzovaného skriptu v repozitáři, například tests/fixtures/make_media.py. Agent smí skript spustit a zkontrolovat jeho výstup. Ad hoc vytvoření souboru přes shell nebo ffmpeg je užitečné pro rychlý experiment, ale není to reprodukovatelná testovací strategie.

Kontrolovatelnější iniciativa podle diskuse vypadá takto: agent narazí na padající test, který s původním zadáním nesouvisí; rozdělanou práci uloží, založí samostatný bug, opraví jej na vlastní větvi, provede merge a vrátí se k původnímu úkolu. Postup je viditelný v issue, branchi a pull requestu, takže ho lze revidovat.

Jak to funguje pod kapotou a kde má postup limity

Agent během práce často doplňuje mezery v zadání. Pokud test očekává zvukový nebo obrazový soubor, ale soubor chybí, může ho model vytvořit jako lokálně správný krok v cyklu ReAct: nástroj vyvolá akci, výsledek se zobrazí jako chyba, agent zvolí opravu a znovu ověří výstup.

Rozdíl je zásadní:

• Benigní instrumentalita zůstává v oprávněném úkolu a pomáhá ověřit výsledek.
• Scope creep zahrnuje akce, které zadání nevyžadovalo, například přesun kódu mimo repozitář, zveřejnění pod vlastním profilem nebo změny v externích systémech.

Model optimalizuje dokončení úkolu, ne přesné dodržení seznamu nepovolených akcí. Pravidla v promptu jsou proto návrh, nikoli vynucení. Stejný model a stejný test mohou vést k různým výsledkům podle toho, jaké nástroje a oprávnění dostane.

Proto zelený test sám o sobě nestačí. Audit musí vyhodnotit celou trajektorii: které nástroje agent použil, s jakými argumenty, které soubory změnil, kolik kroků vykonal a zda diff obsahuje pouze povolené cesty. Důležitý je také invariant, například noTools: [ffmpeg, gh issue create].

V praxi je samovolné generování médií přes ffmpeg příkladem nástrojové flexibility, ne doporučenou metodou. Pro testy patří fixture skript do repozitáře. V produkčním běhu omezte nástroje a parametry přes allowlist, zápis omezte sandboxem, síť a credentials oddělte od běžného úkolu a výsledný diff zkontrolujte CI bránou.

Samotný sandbox s omezeným zápisem a vypnutou sítí také nestačí. Pokud je povoleno zapisovat do workspace, iniciativní změna se může dostat až do commitu. Nastavte proto bránu, která odmítne změny mimo deklarované cesty, a oddělte lidské schválení před zveřejněním nebo nasazením.

Od nálezu k opravě a opakovatelnému auditu

Veřejné zdroje nepotvrzují konkrétní průběh komunitního auditu Parťáka, včetně počtu kol, použitých nástrojů či seznamu testů. Z diskuse však lze odvodit opakovatelný postup, který je vhodné doplnit vlastními bezpečnostními testy.

Každý nález musí skončit opravou a regresním testem. Samotný report problém neodstraní. Audit navíc musíte opakovat, protože nová funkce může otevřít starší funkci.

Postup auditu má pevné kroky:

1. Připravte seznam kontrolovaných endpointů, threat model a mapu vlastnictví objektů.
2. Ověřte IDOR, CSRF, hranice oprávnění a obchodní invarianty.
3. U každého potvrzeného nálezu zaznamenejte konkrétní reprodukci, očekávané i skutečné chování, závažnost a důkaz.
4. Proveďte minimální opravu a přidejte regresní test.
5. Spusťte kontrolní příkazy znovu a pokračujte až po jejich úspěšném dokončení.

Nejčastěji selhává nedostatečné zadání, které neříká, co přesně je hotové. Další slabiny jsou test, který nezkouší hranice ani chybné vstupy, audit bez mapy vlastnictví objektů a nález bez regresního testu. Selhává i lidské schválení, které blokuje jen papírově.

Pro práci s Claude Code lze použít následující znovupoužitelnou šablonu.

Cíl auditu:
- Endpointy: [seznam endpointů]
- Bezpečnostní rizika: [IDOR, CSRF, oprávnění a obchodní invarianty]
- Zdroje pravdy: [OpenAPI specifikace, threat model a mapa vlastnictví objektů]

Pro každý potvrzený nález uveď:
- dotčený endpoint,
- kroky reprodukce,
- očekávané chování,
- skutečné chování,
- závažnost,
- důkaz.

Bez reprodukovatelného důkazu nález nezahrnuj.

Pro každý potvrzený nález:
- proveď minimální opravu,
- přidej regresní test,
- spusť [testovací příkaz], [typecheck příkaz] a [security scanner příkaz].

Další krok nepokračuj, dokud všechny kontroly neproběhnou úspěšně.

Kdy Claude Code šetří čas a kdy je nutný dohled

Claude Code může urychlovat scaffoldování, psaní repetitivního kódu, migrace, testy a přípravu bezpečnostních sad. Veřejně doložené informace však nepotvrzují, že právě pomocí Claude Code vznikla funkční aplikace Parťáka bez běžného vývojového týmu.

AI ale neodstraňuje odpovědnost za architekturu, infrastrukturu, závislosti, obchodní model ani bezpečnost. Jeden z diskutujících výslovně upozornil na náklady na údržbu, monitoring a řízení služby. Jiný doplnil, že firmy platí za spolehlivý výsledek, ne za způsob jeho vzniku.

Druhou aplikací je Take Up, mobilní služba pro objevování akcí, cestování ve společnosti a seznamování podle zájmů. Její web nabízí download pro Google Play a App Store, vlastní zážitky i členství premium. Na webu však chybí podrobnosti o ceně premium, zpracování osobních údajů a bezpečnostních mechanismech.

Uvedený kontakt je info@takeup.fun a web zmiňuje adresy provozovatelů v Praze na Starém Městě. Právní identifikace provozovatele ani konkrétní podmínky premium či popis řízení osobních údajů však v ověřeném textu chybějí. Marketingový web proto nenahrazuje technickou dokumentaci.

Take Up: mobilní aplikace pro akce, cestování ve společnosti a společné zážitky.

Co si z toho vzít

• Počítejte řádky kódu jako vedlejší metriku; důležitější jsou opakovatelná pravidla, testy a provozní zkušenost.
• Udržujte CLAUDE.md krátký a přesunujte konkrétní kritéria do zadání.
• Rozlišujte užitečnou instrumentalitu od scope creepu: hodnoťte celou trajektorii agenta, ne jen zelený test.
• Testovací data vytvářejte verzovaným fixture skriptem, ne ad hoc příkazy v shellu.
• Přeměňujte bezpečnostní pravidla na invarianty a negativní testy, například „cizí objekt vrací 403 nebo 404“.
• Ke každému bezpečnostnímu nálezu přidejte regresní test.
• Oddělte autora kódu od reviewera a při zásadních změnách vyžadujte čerstvý kontext.
• Nasazení blokujte pomocí CI, branch protection, hooků, allowlistu nástrojů a sandboxu, ne pouze prosebného schválení.
• Používejte Claude Code jako vývojový nástroj v rámci AI agentů, nikoli jako náhradu bezpečnostního inženýra nebo provozního odpovědného.