Zní to banálně, ale byl to pro nás zlomový moment. Místo opravování výstupu jsme začali konfigurovat vstup.

Používáme Claude Code, který podporuje projektové instrukce přes soubor CLAUDE.md. Tam jsme sepsali pravidla, která v týmu dodržujeme, a která bychom jinak novému kolegovi vysvětlovali první dva týdny:

Konvence projektu

• Každá entita má interface v Domain vrstvě
•  Repository pattern - žádný přímý EntityManager v aplikační vrstvě
• Serialization groups: {module}:read, {module}:write
• ID typ: ULID
• Timestamps: vždy přítomné
• Tabulky: prefix app_{module}_{entity}

Nic složitého. Ale rozdíl ve výstupu je obrovský.

Bez těchto instrukcí dostanete od AI něco takového:

public function getUser($id)
{
   return $this->entityManager->find(User::class, $id);
}

Funkční? Ano. Ale u nás se to dělá jinak - interface, typovaný parametr, metoda v repository:

public function findById(string $id): ?UserInterface
{
   return $this->createQueryBuilder('u')
       ->where('u.id = :id')
       ->setParameter('id', $id)
       ->getQuery()
       ->getOneOrNullResult();
}

Jakmile AI tyhle instrukce dostane, generuje kód druhým způsobem. Jednou nastavíte, pak už se o to nestaráte. Princip funguje napříč nástroji - Cursor, Copilot, Claude Code - většina z nich nějakou formu projektové konfigurace podporuje.

Instrukce vyřeší konvence. Ale kdo zkontroluje, jestli je kód opravdu v pořádku? Na to máme review skills, krátké konfigurační soubory, které AI říkají co a jak má na vygenerovaném kódu zkontrolovat.

V praxi používáme dva typy a každý řeší něco jiného.

První skill je v podstatě to, co by dělal seniorní kolega na code review. Sepsali jsme věci, které v projektu vyžadujeme, do checklistu a AI ho prochází automaticky.

Co kontrolovat:

Entity & Repository

• Každá entita má interface
• Interface registrovaný v doctrine.yaml
•  UUID přes UlidIdEntityTrait
•  Timestamps přes TimestampableTrait
• Všechny Doctrine dotazy výhradně v repository

Architektura

• Providers - pouze načítání dat, žádná business logika
• Processors - pouze volání use-case
• Use-cases - veškerá business logika je zde

Exception handling

• Vlastní exception třída pro každý typ chyby
• Message v exception anglicky
• Odchytávání pouze v nejvyšší vrstvě

Spustíte jedním příkazem, dostanete výstup rozdělený podle závažnosti:
🔴 Kritické: Entity UserPreference nemá interface
🟡 Důležité: Handler obsahuje business logiku - přesunout do use-case
🟢 Drobnost: Zbytečný inline komentář na řádku 42
✅ V pořádku: Repository pattern, naming, timestamps

Nic převratného. Ale představte si, že tohle běží nad každým vygenerovaným kódem automaticky. Nemusíte si pamatovat dvacet pravidel – skill si je pamatuje za vás.
 

Druhý skill je zajímavější. Vznikl přirozeně z poznámek, které jsme si začali dělat pokaždé, když jsme na review narazili na stejnou věc potřetí za měsíc.

AI třeba ráda generuje volání metod s prázdnými parametry jen proto, aby se dostala k poslednímu argumentu. Nebo sahá po generických exceptions. Nebo zapomene, že u nás se serializace definuje v YAML, ne přes PHP atributy.

Opakované chyby - kontroluj vždy
─────────────────────────────────

Named arguments místo prázdných parametrů:

 ❌ Prázdné závorky jen kvůli poslednímu parametru
 $translator->trans('key', [], 'messages', 'cs');

 ✅ Named argument
 $translator->trans('key', locale: 'cs');

Specifické exceptions:

 ❌ Generická exception
 throw new \RuntimeException('Member not found');

 ✅ Vlastní exception třída
 throw new MemberNotFoundException($memberId);

U obou skills se nám osvědčilo hodnotit každý nález ve dvou dimenzích, jak těžké je to opravit a jak moc to reálně pomůže:

Nález: Chybí databázový index na často dotazovaném sloupci
⚡ Effort: 5%   |  🎯 Impact: 70%
→ Jedna řádka v migraci, výrazné zrychlení.

Nález: Chybí null check v API response
⚡ Effort: 10%  |  🎯 Impact: 50%
→ Jednoduchý fix, reálný dopad na klienty.

A na konci souhrnná tabulka seřazená podle ROI (Impact ÷ Effort):

Žádné debaty o tom, co opravit první. Highest ROI nahoře - tím začneme. A hlavně - skill nezapomene zkontrolovat edge cases v pátek v pět odpoledne, když už chcete jít domů.

Tohle je ta část, která nám workflow posunula nejvíc. Instrukce a skills jsou skvělé, ale pořád vyžadují ruční spouštění - vygeneruj, zkontroluj, řekni AI co opravit, znovu zkontroluj. Klasický ping-pong.

Ralph Loop je plugin pro Claude Code, který tento ping-pong automatizuje. AI pracuje na úkolu, spouští testy, dostává zpětnou vazbu z Code Review a sama iteruje - dokud není všechno v pořádku, nebo dokud nedosáhne nastaveného limitu.

A spustíte to jedním příkazem:

/ralph-loop "Implement user registration endpoint
 with email validation, password hashing,
 and welcome email notification" --max-iterations

A pak se díváte, jak AI pracuje:

Iterace 1:
 → AI vygeneruje endpoint, DTO, use case, test
 → Testy: 2 FAIL – chybí validace emailu, špatný HTTP status
 → AI pokračuje...

Iterace 2:
 → Opravená validace, správný status code
 → Testy: PASS
 → Code Review: 1 MEDIUM - chybí rate limiting
 → AI pokračuje...

Iterace 3:
 → Přidán rate limiting
 → Testy: PASS
 → Code Review: žádné nálezy
 → ✅ Hotovo – kód připravený na finální review
 
Tři iterace, žádný manuální zásah mezi nimi. Vy přijdete k hotovému výsledku a uděláte finální review - architektura, business logika, věci, které AI z principu neřeší.

Pár věcí, které jsme se naučili za pochodu:

Vždycky nastavte limit iterací. My dáváme 3–5 na běžný úkol. Bez limitu se AI může zacyklit nad problémem, který neumí vyřešit a vy akorát pálíte tokeny.

Začněte jednoduše. CRUD operace, nové endpointy, rozšiřování testů na tom Ralph Loop funguje parádně. Složitější architektonické úkoly si nechte na přímou spolupráci.

Důvěřuj, ale prověřuj. Ralph Loop šetří čas tím, že eliminuje ruční iterace. Finální lidský review ale zůstává a měl by zůstat.

Nechci tvrdit, že jsme objevili svatý grál. Ale pár věcí se reálně změnilo:

Review je rychlejší. Když přijdu ke kódu, který už prošel Code Review skillem, nemusím lovit N+1 queries nebo zapomenuté null checky. Soustředím se na to, jestli to dává smysl z pohledu business logiky a architektury.

Kód je konzistentnější. Instrukce fungují jako „vždy-zapnutý linter na konvence”. Žádné „tentokrát to udělám jinak, protože spěchám”. AI dodržuje pravidla pokaždé.

Onboarding je jednodušší. Nový kolega v týmu nemusí mít všechny konvence v hlavě. AI je zná za něj a skills hlídají, že se dodržují.

Víme, kde zpřesnit. Data z Code Review skillů ukazují, jaké nálezy se opakují. Na základě toho ladíme instrukce a těch nálezů je pak méně.

A k tomu upřímně jsou věci, kde se na AI spoléhat nedá. Architektonická rozhodnutí, business tradeoffs, produktové myšlení. To zůstává na lidech. Ale všechno kolem generování, testování, kontrola kvality to AI zvládne, a zvládne to dobře.

My jsme taky začínali postupně.

První týden: Sepište konvence projektu do konfigurace pro váš AI nástroj. Uvidíte rozdíl okamžitě.

Druhý týden: Napište si jednoduchý review skill stačí seznam toho, co chcete kontrolovat. Bezpečnost a performance jsou dobrý start. A založte si Lessons Learned pokaždé, když na review narazíte na opakující se chybu, přidejte ji tam.

Třetí týden: Nainstalujte Ralph Loop a zkuste ho na jednoduchém úkolu nový endpoint, CRUD operace. Sledujte, jak AI iteruje, a laďte instrukce podle výsledků.

Každý krok sám o sobě přináší hodnotu. A dohromady tvoří systém, ve kterém AI dělá rutinní práci a vy se můžete soustředit na věci, které vyžadují lidský úsudek.