Codex a Claude Code: vývoj pluginu pro After Effects bez slepých míst

Rozdělení rolí: plán, kód a nezávislý pohled

Plugin může na první pohled fungovat správně, ale při běhu v Adobe After Effects narazit na chybu, které si ani dva modely nevšimnou. Jeden model navrhuje změny a píše kód, druhý kontroluje výsledek. Build, podpis, bezpečnostní skeny, commit, push a přípravu k testování přebírají skripty. Člověk schvaluje plány a provádí uživatelské testování.

Odborně jde o dělení odpovědností mezi plánovacím, implementačním a revizním agentem, doplněné orchestrací pomocí deterministických skriptů.

V diskuzi se často mluví o „workflow mezi dvěma AI“. Samotné střídání dvou modelů ale představuje jen část řešení. Workflow přináší hodnotu tehdy, když jasně oddělí rozhodování modelu od strojově proveditelných kroků.

Praktické rozdělení může vypadat takto:

• Codex připraví plán, rozdělí úlohu na dílčí změny a navrhne testy.
• Claude Code nebo jiný implementační agent promění schválený plán v kód.
• Revizní model dostane snapshot nebo diff a pracuje pouze read-only.
• Skripty provedou opakovatelnou kontrolu a přípravu artefaktu.
• Člověk schválí rizikové kroky a ověří chování pluginu v hostiteli.

U menších projektů je podle autorovy zkušenosti takové rozdělení zbytečně nákladné. Dvě role dávají smysl tam, kde je kód rozsáhlý, změny se obtížně přehlížejí a chyba se projeví až při běhu v Adobe After Effects.

Plán musí být smlouva, ne konverzace

Modelový plán nemá stabilní stav. Po kompresi kontextu nebo předání jinému subagentovi se může ztratit, zkrátit nebo změnit. Schválený plán proto uložte mimo kontext, ideálně jako verzovaný dokument.

Dokument má jasně uvádět:

• cíl,
• jednotlivé kroky,
• očekávané změny,
• kritéria akceptace.

Běžná pravidla pro spolupráci patří do CLAUDE.md nebo AGENTS.md, pokud je nelze vyjádřit nástrojem. Sem patří omezení API hostitele, podporované verze After Effects nebo zákaz postupů založených na CEP.

Samotný text v promptu ale bezpečnost nezaručí. Model může pravidla při dlouhém běhu přehlédnout, zejména po příchodu nového diffu nebo výstupu nástroje.

Claude Code command hooks a deny rules proto slouží jako vnější brána. Mohou zablokovat zápis do chráněných cest, přístup k secretům nebo nebezpečné shellové příkazy ještě předtím, než akce proběhne.

Stejnou funkci plní linting, typová kontrola a skenování závislostí. Nastavení tak dává ochranu i v případě, že model zapomene na pravidlo v promptu.

Jak to funguje pod kapotou a kde má postup limity

Agentní systém rozděluje úlohy podle rolí. Společným limitem zůstává schopnost modelu přesně pochopit chování konkrétního hostitele.

Reviewer může najít syntaktickou chybu nebo nebezpečný vzorec. Nemusí však zachytit rozdíl mezi kódem, který se na první pohled jeví správně, a kódem, který selže uvnitř After Effects.

Skutečnou autoritou pluginu je jeho běh v After Effects, ExtendScript Debuggeru nebo aerenderu. Schválený diff, kladný výsledek linteru ani souhlas dvou modelů nenahradí tuto zkoušku.

Dva podobně trénované modely se mohou shodnout na stejné chybě. Cross-vendor review tak přináší druhý názor, nikoli nezávislé sémantické ověření.

Další omezení představuje platforma Adobe. CEP se v novějších verzích After Effects zatím neodstraňuje. UXP pro After Effects má být v public beta do MAX 2026 a obecně dostupné v Q2 2027, zatímco odstranění CEP je naplánováno na prosinec 2029.

Bezpečnostní a testovací postup se proto musí průběžně přizpůsobovat cílové verzi hostitele.

Častou chybou je také spoléhání na tokeny jako měřítko úspory. Druhý model může při čtení každého diffu spotřebu zvýšit. Úspora vzniká tehdy, když levné a opakovatelné kontroly převezmou skripty a model se volá jen pro úkoly vyžadující úsudek.

Který nástroj má převzít který krok

Dedikované nástroje převezmou úlohy, kde musí být výsledek deterministický a opakovatelný:

• npm nebo Vite pro reprodukovitelný build,
• ZXPSignCmd pro podpis a ověření CEP balíčku pomocí příkazů -sign a -verify,
• ESLint, TypeScript a secret scan pro statické kontroly,
• GitHub Actions jako povinnou bránu před merge.

Model by neměl samostatně spravovat certifikát ani sestavovat výsledný balíček ručním zásahem. Připraví nebo opraví kód a vysvětlí nález.

K revizi lze použít Codex /review nebo Claude /code-review (alias /review). Příkazy lze opakovaně používat například pro revizi změn či pull requestu.

Revizní agent by měl pracovat v read-only režimu. Neměl by dostat možnost současně měnit repozitář. Nález z revize je návrh k ověření, nikoli schválená oprava.

Větší projekty navíc potřebují explicitní bezpečnostní hranici:

• omezení závislostí,
• kontrolu binárních artefaktů,
• detekci zakázaných volání,
• zákaz přístupu k citlivým cestám.

Ne každý pravidelný krok však musí procházet modelem.

Úspora tokenů bez ztráty kontroly

Tokenová úspora nevzniká samotným rozdělením rolí. Získáte ji omezením kontextu a voláním modelu jen tam, kde je potřeba rozhodnutí:

1. Nechte AI vytvořit nebo opravit plán.
2. Uložte plán do souboru a pracujte s jednou schválenou verzí.
3. Spusťte levné kontroly bez AI.
4. Spusťte revizi až po dostatečně velké změně, nikoli po každém drobném commitu.
5. Nechte model řešit jen chyby, které deterministický test nedokáže diagnostikovat.

Tento postup omezuje zbytečné čtení diffů a opakované vysvětlování. Zároveň zachovává čitelný audit: plán, změna, výsledek skriptu, revize, schválení a test.

Co si z toho vzít

• Oddělte plánování, implementaci, revizi a provozní kroky; dvě role nestačí samy o sobě.
• Ukládejte plán mimo kontext a předávejte mezi agenty jeho konkrétní verzi.
• Pravidla zajišťujte hooky, lintem a skripty, ne pouze instrukcí v promptu.
• Spouštějte revizi po větších změnách, nikoli automaticky po každém commitu.
• Považujte modelové posouzení za podnět k ověření; rozhodující zůstává běh pluginu v Adobe After Effects.
• Automatizujte build, podpis, skeny a testy; lidské schválení ponechte u rizikových a uživatelských kroků.