Vibe coding v Unity: jak vést AI agenta a kde zůstává lidská práce

Co v praxi funguje: zadávat výsledek, ne implementaci

AI agent v Unity může vygenerovat spoustu kódu. Jen správný kód ale nezaručuje, že hra bude fungovat tak, jak jste zamýšleli. Největší problém totiž často nespočívá v psaní C#, ale v nejasném zadání: agent dostane neurčitý úkol a vyplní mezery vlastními předpoklady.

Proto se v komunitě osvědčuje přístup známý jako „vibe coding“. Přesněji ho lze popsat jako specifikaci řešení podle výsledku neboli outcome-based development. Agent dostane jasný výsledek a podmínky jeho ověření. Konkrétní implementaci vybírá sám.

V Unity se to osvědčuje například u zadání typu „vozidlo po stisku klávesy zrychlí, při příliš vysoké rychlosti ztratí kontrolu a hráč dostane varování“. Neúplné zadání bez následné kontroly ovšem skončí chybnou interpretací. Výsledek je proto vhodné doplnit o okrajové podmínky, návratový stav a způsob ověření.

Automatické testy jsou v této komunitní praxi běžnou součástí práce. Claude Code i Codex mohou sami navrhovat testy, které následně ověřují změny. U rozsáhlejšího projektu je ale nutné pravidelně žádat odstranění duplicit, zastaralých a nerelevantních testů. Vysoký počet testů sám o sobě neznamená kvalitní sadu.

Veřejný projekt Wright Tycoon ukazuje, že tento přístup může vést k rozsáhlému prototypu. Repo obsahuje Unity verzi 6000.3.9f1, převážně C# kód, dokumentaci, soubor AGENTS.md a sestavy pro Windows i macOS. Repozitář má 142 commitů a jednu větev master; hlavička souborů odkazuje na uložení projektu ve verzi 0.7.0. Hra na itch.io zahrnuje návrh letadel a motorů, výrobu, zakázky, servis flotily a dvojí účetnictví. Aktuální uvedená verze na itch.io je 0.6.9 a přinesla přepracování návrhu motorů, aerodynamiky, vzletových vlastností, nosnosti a dosahu. Ke stažení je bez stanovené ceny s možností dobrovolného příspěvku; exkluzivní obsah je dostupný při podpoře. Zveřejněná dokumentace však sama nepotvrzuje, jak přesně AI agent přispěl k návrhu jednotlivých funkcí.

ZDROJ: github.com ↗

ZDROJ: koudelkin.itch.io ↗

Kontext, session a testy: udržet agenta orientovaného

Jedna dlouhá relace v Claude Code nebo Codexu šetří opakované vysvětlování vztahů mezi systémy. Nevýhodou je vyšší spotřeba kontextu a postupné „zapomínání” důležitých omezení.

Alternativou je projektová paměť: stabilní fakta, architektonická rozhodnutí, aktuální cíle a známé problémy uložené v Markdownu. Agent pak získá stejný kontext bez ohledu na délku relace.

Praktická struktura může obsahovat:

• ARCHITECTURE.md – trvalé vztahy mezi moduly;
• CURRENT_TASK.md – cíl, acceptance criteria a kroky aktuální iterace;
• KNOWN_ISSUES.md – potvrzené chyby a omezení;
• TESTING.md – způsob spuštění testů a pravidla pro jejich údržbu.

Důležité je odlišit skutečné ověření od formálně procházejícího testu. Automatický test může potvrdit, že se objekt vytvořil, ale neověří, zda hra dobře reaguje na hráče. Diskuse proto ponechává závěrečnou kontrolu člověku. Vlastní prompt pro nový test může vypadat takto:

Napiš Unity test pro [očekávané chování] v [subsystému].
Použij existující konvence testů z [relevantní testovací soubor].
Pokryj [hlavní úspěšný případ] a [důležité okrajové případy].
Nepoužívej [externí závislost].
Uveď změněné soubory a případné chování, které nelze ověřit automaticky.

Při větším množství testů je užitečné odlišit nové, duplicitní a zastaralé. Odstranění testu musí být opatrné: nejprve se ověří, zda nepokrývá jedinečný požadavek.

Nejčastější chybou není příliš mnoho testů, ale jejich neudržovanost. Duplicitní testy prodlužují běh sady a ztěžují rozlišení skutečné chyby od opakovaného pokrytí téhož požadavku. Zastaralý test navíc může blokovat správnou implementaci, protože stále očekává dřívější chování.

Unity a Blender přes MCP

Propojení Unity a Blenderu přes MCP rozšiřuje agenta o specializované operace místo pouhého generování kódu. Agent může získat informace o scéně nebo objektu, upravit parametry a výsledek průběžně kontrolovat. Pro práci s 3D obsahem je tento most praktičtější než pokus vysvětlit všechny importní a transformovací parametry textem.

Samotné propojení ale neodstraňuje ztrátu informace mezi systémy. V Unity jsou důležité měřítko, pivot, osy, konvence názvů a importní nastavení. V Blenderu se dá vytvořit geometrie, která se po importu otočí, zmenší nebo ztratí správný pivot. Je proto nutné výsledek ověřit v obou nástrojích.

Dedikovaný nástroj je vhodný pro samotnou modelovací a importní práci, agent pro opakované změny a kontrolu pravidel. Ruční zásah v Blenderu zůstává nejlepší pro složité riggingování, animaci a doladění vzhledu.

Typickou pastí je právě import. Model může v Blenderu sedět správně, ale po přenosu do Unity se otočí, zmenší nebo ztratí osu. Objeví se to teprve při umístění ve scéně. Proto nechte agenta porovnat transformace před importem a po něm a výsledek zkontrolujte přímo v obou programech.

Jak to funguje pod kapotou a kde má postup limity

Unity projekt není jen textový kód. Stav hry tvoří YAML scény, .meta soubory s GUID, serializované reference, vrstvy, prefaby, fyzika a data uložená v runtime. Jazykový model přitom predikuje tokeny z kontextu; nemá přímý model hierarchie scény ani průběžného stavu během hry.

Proto může kód vypadat správně, ale přiřazení GUID, vrstvy nebo přechodu animatoru selže. Taková chyba se často neprojeví jako chyba kompilace, ale jako tichý null, neaktivní objekt nebo špatně reagující animace. Agent navíc pracuje s pravděpodobně plausibilním pokračováním kódu, nikoli s autoritativním záznamem o tom, co hráč právě prožívá.

Když agent nečte konzoli, hierarchii scény a průběh Play Mode, přepisuje C# bez přímého dohledu nad hratelností. Každý další nástrojový krok je přitom další predikce. Oprava proto může přidat další vrstvu kódu místo odstranění původní chyby.

Automatizace má vyloženě nejlepší výsledky u logiky, datových struktur, repetitivní integrace a dobře definovaných pravidel. Design, smysluplné animace, timing, čitelnost ovládání a výsledný „feel“ jsou percepční vlastnosti. Jejich správnost nelze automaticky odvodit z faktu, že testy procházejí.

V praxi je proto rozdělení odpovědnosti praktické: AI připravuje a mění logiku, člověk určuje rozsah, schvaluje výsledek a vnímá hratelnost. Ani člověk bez znalosti programování se nevyhne rozhodování o tom, co má ve hře být a zda výsledek funguje.

Praktické rady pro Codex, Claude Code a Cursor

Codex a Claude Code jsou vhodné pro práci přímo v repozitáři, úpravy více souborů, spouštění testů a kontrolu výsledných změn. Cursor je praktický v prostředí VS Code, pokud je tým zvyklý na práci s editorem a chatem. Volba nástroje je méně důležitá než způsob práce.

Každý úkol je vhodné uzavřít takto:

1. Definovat očekávaný výsledek a acceptance criteria.
2. Zapsat relevantní omezení do projektové paměti.
3. Nechat agenta změnu implementovat a vysvětlit její dopad.
4. Spustit testy, zkontrolovat konzoli a ručně ověřit scénu.
5. Uklidit testy a zapsat nové znalosti.

Zkrácená šablona pro vývojářský úkol:

Implementuj [očekávaný výsledek] v [Unity subsystému].
Acceptance criteria: [pozorovatelné podmínky úspěchu].
Použij [existující architekturu a konvence].
Neměň [omezení rozsahu].
Spusť [relevantní testy], zkontroluj konzoli a Play Mode a uveď nevyřešená rizika.
Vyhnuj se [nežádoucím artefaktům, například duplicitním testům, placeholderovému UI nebo nesouvisejícím refaktorům].

Rozsah rozhoduje člověk. AI může tento postup urychlit, ale neodstraní potřebu znát cíl hry a posoudit její výsledek.

Nejčastěji se workflow rozbíjí v několika bodech. Zadání neříká, kdy je změna hotová, takže agent přidává rozsah navíc. Testy pokrývají špatný případ, takže sada prochází, ale hra se nechová správně. Agent navíc opraví symptom místo příčiny a vytvoří další vrstvu kódu.

Před každým spuštěním agenta proto jasně oddělte cíl od podmínek jeho úspěchu. Po změně zkontrolujte nejen testy, ale také konzoli, hierarchii scény a Play Mode. U importu navíc porovnejte transformace a pivot.

Co si z toho vzít

• Poptávejte výsledek a podmínky jeho správnosti, ne předepsanou implementaci.
• U dlouhého projektu udržujte rozhodnutí a aktuální stav v Markdownu.
• Testy nechte vznikat automaticky, ale pravidelně odstraňujte duplicity a zastaralé scénáře.
• Unity a Blender propojujte přes MCP a vždy kontrolujte transformace, pivot, osy a import.
• Automatické testy ověřují logiku; hratelnost, design a animaci musí posoudit člověk.
• Výsledné rozhodnutí, jestli je hra dobře hratná, zůstává lidskou odpovědností.