Jak přepsat legacy aplikaci za týden s Claude Code

📺 Záznam přednášky Bekhzoda Masharipova a Martina Foldyny z Ackee Meets: Agentic Web Dev:

Přepsat aplikaci s desetiletou historií, 3 800 commity a 46 500 řádky kódu. Za jeden týden. Ve dvou lidech a s AI agentem, který má v terminálu klíče od všeho. Zní to jako sázka, kterou by rozumný člověk nepřijal – a právě proto se vyplatí popsat, jak dopadla.

📋 TL;DR

• Interní firemní systém o šesti modulech: deset let historie, 3 800 commitů, 46 500 řádků kódu, zastaralý tech stack a knihovny, které už nikdo neudržuje. Zadání: přepsat. Termín: jeden týden.
• Nástrojem se stal Claude Code. Backend šel první, starý frontend zůstal běžet jako živá validace, že nový backend opravdu funguje.
• Rychlost nedělaly lepší prompty, ale příprava: Claude Code v dev containeru, přepis v nové codebase, pravidla v souboru CLAUDE.md, dokumentace knihoven přes Context7 MCP.
• Ruční „babysitting“ nad prvním modulem jsme zabalili do Claude skills: rewrite → verify → E2E test, každý krok ve vlastním kontextovém okně.
• Frontend zpočátku selhal na naivním „překopíruj styly podle screenshotů“. Zabrala až kombinace v0 pro základ komponent a Figma MCP na dolaďování detailů.
• Billing přes Claude API vyletěl na 150 dolarů za tři dny. Předplatné by vyšlo výrazně levněji.
• Výsledek: všech šest modulů za sedm dní, nasazeno na dev prostředí, manuální testování odhalilo minimum chyb.

🧟 Výchozí situace: legacy, kterého se nikdo nechtěl dotknout

Vstupní situace byla učebnicová: aplikace, kterou celá firma používá každý den, s prvním commitem z roku 2016, na stacku, který dávno nebyl moderní, a s knihovnami, jejichž autoři se dávno vydali jinam.

Údržba takové aplikace není práce, je to vyjednávání. Každá změna nese riziko, každý upgrade otevírá tři nové otázky. V únoru 2026 proto padlo rozhodnutí, které v takové situaci padne skoro vždycky: přepíšeme to. Nezvyklé bylo až to, co následovalo – termín jeden týden a dva vývojáři, backendový a frontendový.

🤝 Claude Code jako parťák, který nespí

Do této role se postavil Claude Code – AI agent, který běží přímo v terminálu a celý týden makal bok po boku s vývojářem. Ne, developer se tím zbytečným nestal. Jen se role posunula: místo psaní kódu řádek po řádku je z vás architekt a reviewer. Což je, přiznejme si, práce, na kterou většina lidí není zvyklá o nic víc než na psaní testů.

Proč zrovna Claude Code? V době rozhodování měly modely od Anthropicu jasně navrch na SWE benchmarcích. Volba nástroje tedy nebyla ideologická, ale prostě pragmatická – sáhli jsme po tom, co v té chvíli mělo nejlepší čísla.

Rozdělení práce bylo od začátku jasné, se stejným cílem pro všechny kroky: nezbláznit se z toho.

• Začít backendem. Jasné rozhraní, jasná business logika, měřitelný výsledek.
• Nechat starý frontend žít. Napojíme ho na nový backend a máme okamžitou zpětnou vazbu, že věci fungují.
• Platit přes API. Za jeden týden reálné spotřeby to přece nemůže být moc. (Spoiler: tenhle bod si ještě probereme.)

🧱 Příprava terénu: Context7, dev container a context engineering

Než padl první prompt, přišly tři přípravné kroky. Zpětně jsou to právě ony, které rozhodly o tom, že se termín stihl.

Context7: aby si model nevymýšlel funkce

Všechny LLM generují kód podle trénovacích dat, která nutně stárnou. Výsledkem je halucinace, kdy model s naprostou jistotou použije funkci knihovny, jež v dané verzi vůbec neexistuje. Context7 je MCP server, který do kontextu dodá dokumentaci ke konkrétní funkci přesně v té verzi knihovny, kterou projekt používá. Agent tak rychle získá aktuální dokumentaci a nemusí halucinovat – a protože dostane jen to, co potřebuje, zároveň šetří tokeny.

Dev container: klíče od domu si radši necháme

Otázka, kterou dostalo publikum na přednášce, zní nevinně: kdo z vás pouští AI agenta přímo na svém stroji? Ruce se zvedly téměř všude. Je to pochopitelné, je to pohodlné a je to riziko.

Namítnete, že Claude Code se přece na každý příkaz ptá. Ptá. Jenže po dvacátém potvrzení – a obzvlášť když vám běží víc agentů paralelně – vypadá schvalovací proces asi takhle:

Ruční schvalování tedy jako bezpečnostní opatření nefunguje. Fungujícím řešením je dev container – Docker kontejner nakonfigurovaný jako plnohodnotné vývojové prostředí, tedy s editorem, extensiony a SDK. Připojíte se do něj přes IDE a pracujete, jako byste seděli na svém stroji. Rozdíl je v tom, že agent za hranici kontejneru nedosáhne.

Dev container vyřešil tři věci současně: bezpečnost (izolované prostředí, žádný přístup na host), hands-off režim (agentovi můžete v rámci kontejneru dát širší práva a nepotvrzovat každý příkaz) a kontrolu (kdykoliv se přes IDE připojíte a převezmete řízení).

Context engineering: existující kód je součást promptu

Poslední přípravný krok bylo rozhodnutí přepisovat v nové, čisté codebase. Důvod je nenápadný, ale zásadní: existující kód je součástí každého promptu, a pravděpodobně jeho nejvlivnější částí. Agent se přizpůsobí tomu, co vidí kolem sebe. Kdyby přepis běžel ve starém repozitáři, s železnou pravidelností by přebíral staré konstrukty – a celý přepis by tím ztratil smysl. Starý kód v projektu zůstal, ale jen jako read-only reference: aby agent věděl, co přepisuje, ne jak to bylo napsané.

K tomu přišla pravidla v souboru CLAUDE.md: popis projektu, cíl, odkaz na styleguide, konvence, architektura, odkaz na starou codebase. Zkrátka všechno, co si agent nedokáže jednoduše zjistit sám. A nakonec tooling – nastavený linter a formatter, které má agent pustit po každé změně kódu.

🔁 Workflow na backendu: od babysittingu ke Claude skills

Samotný přepis se odehrál ve třech krocích, které se pro každý modul opakovaly.

Krok 1: graf závislostí. Claude Code analyzoval starý kód a vytvořil dependency graph modulů. Z něj vyplynulo pořadí, ve kterém se má přepisovat.

Krok 2: specifikace, paralelně. Spustili jsme víc agentů současně, každý dostal jeden modul. Agent prošel legacy kód, pochopil business logiku a napsal detailní specifikaci. Ta pak posloužila jako zadání pro přepis. Zpětně to byl nejcennější artefakt celého týdne – právě specifikace zajistily, že se při přepisu nevynechaly důležité věci.

Krok 3: babysitting. U prvního modulu psal Claude Code kód a vývojář nad každým výstupem stál, procházel ho a dával zpětnou vazbu. Každou chybu nechal agenta zapsat do CLAUDE.md jako pravidlo, aby se neopakovala. Fungovalo to výborně a trvalo to celý den. Šest modulů tímhle tempem se do týdne nevejde.

Claude skills: zabalený workflow

Řešením byly Claude skills – zabalený workflow, který si agent spouští sám nebo na vyžádání. Ideální na rutinu, kterou jste jednou ručně odladili a nechcete ji odlaďovat znovu. Takže: „Zapiš si všechny kroky, které jsme spolu udělali, a udělej z toho skill.“

Skill je obyčejný markdown soubor. Nahoře popis, podle kterého agent pozná, kdy ho použít, pod ním kroky. Zjednodušeně vypadal takhle:

---
name: rewrite
description: Detailed instructions how a module must be rewritten.
  Use it when rewriting a module based on specification
---

## Steps

1. Read the module specification
2. Create an implementation plan
3. Write the tests first - they must fail
4. Write the minimal implementation that makes them pass
5. Refactor the implementation
6. Repeat until the whole plan is done

Jádrem je TDD, a to ne z ideologie. Když agentovi řeknete „napiš modul“, vymyslí pět abstrakcí, které nikdo nepotřebuje. Když mu řeknete „splň tenhle test“, napíše přesně to, co je potřeba.

Rewrite → verify → E2E test

Jeden skill na přepis modulu ale nestačí. Chyběla verifikace, a tak vznikly další dva.

Verify nejdřív ověří, že implementace odpovídá specifikaci (jsou tam všechny endpointy, sedí business logika), a pak provede klasické code review – hledá zranitelnosti, kontroluje soulad se styleguidem a s definovanými pravidly. Každý nesoulad reklamuje zpět agentovi, který kód psal.

E2E test vytočil starý frontend, napojil ho na nový backend a přes Playwright proklikal hlavní scénáře ze specifikace. Nalezené chyby zaloguje a pošle zpátky. Kolečko se opakuje, dokud vše neprojde.

💸 Kolik to stálo: Claude API vs. předplatné

Billing přes API jsme zmínili už v TL;DR, ale stojí za to u něj zůstat o odstavec déle. Uprostřed týdne přišla od kolegy zpráva ve smyslu koukals na ten usage?. Nekoukal. Za tři dny 150 dolarů – a to práce ještě nebyla hotová.

Samo o sobě to není tragédie, ale měsíční předplatné vyššího tarifu stojí kolem stovky dolarů. Poučení je nudné a platí obecně: pokud budete s agentem pracovat intenzivněji než jeden den, jděte do předplatného a náklady si spočítejte dopředu.

🎨 Frontend s v0 a Figma MCP: dvakrát měř, jednou generuj

Frontendovou část, na starosti Martina Foldyny, čekalo stejné zadání, ale jiné problémy. Design totiž nejde ověřit testem.

První pokus byl, řekněme, odvážný: tehdy nejsilnější dostupný model v plan mode, překopírování stylů z původní aplikace do nové codebase a k tomu přiložené screenshoty, jak to má vypadat. Očekávání versus realita byly dvě velmi odlišné obrazovky.

AI buildery: v0 nebo Lovable

Druhý pokus začal u nástrojů, které jsou na generování UI přímo stavěné. Krátký research zúžil výběr na dvě jména:

Volba padla na v0 právě proto, že výstup měl posloužit jako základ, na kterém se dál staví. Vygenerované komponenty se zkopírovaly do vlastní Next.js šablony, zbytek stránek dopsal Claude Code. Finální UI nebylo perfektní, ale ve srovnání s prvním pokusem to byl skok o kategorii.

Figma MCP: magie, ale s hvězdičkou

Celý design žije ve Figmě, takže Figma MCP vypadal jako spása. A z velké části byl – na dolaďování konkrétních detailů, aby layout sedl a grafy se zobrazovaly tam, kde mají, je ideální.

Háček je v tom, že oficiální plugin je poměrně osekaný a rate limit má na Pro tarifu přísný, řádově dvě stě volání na den. Při dolaďování designu je to strop, do kterého narazíte před obědem. Alternativou se stal neoficiální Figma Context MCP (Framelink), který jde přes API s výrazně štědřejšími limity. Podle srovnání z jeho dokumentace vrací navíc menší a lépe strukturovaný výstup – popisný JSON místo předžvýkaného Reactu a Tailwindu, se zachovanými názvy stylů.

Napojení logiky, protože hezké UI samo nic nedělá

Doladěné UI je pěkné, dokud na něco nekliknete. Napojení logiky pak vypadalo podobně jako na backendu – frontend je taky modulární, takže se postupovalo modul po modulu. Agent nejdřív vygeneroval specifikaci modulu, k tomu dostal sepsané konvence a best practices, definici stacku, seznam použitých knihoven a jejich dokumentaci přes Context7.

Nový modul se pak přes Playwright CLI porovnával s tím starým. Prošlo to, modul hotový. Neprošlo, jde to zpátky do kolečka. A protože se tento postup ukázal jako funkční, skončil – jak jinak – zabalený do skillu.

Code review zůstalo lidem

Jedna věc se nezautomatizovala. AI vygenerovaný kód nešel na dev prostředí bez toho, aby ho viděl člověk. Code review vždycky dělal senior frontend vývojář, agent si pak sám stáhl komentáře z merge requestu, zapracoval je a poslal to na další review. Dokola, dokud nebyl merge request schválený.

📈 Výsledek po sedmi dnech

Všech šest modulů přepsáno. Nový backend nasazený na dev prostředí, napojený na původní frontend, funkční. Manuální testování od QA týmu odhalilo minimum chyb – k čemu nepochybně přispělo, že původní aplikace měla slušné pokrytí testy, protože interní i klientské projekty tady míří na devadesátiprocentní pokrytí.

Nejvíc času nakonec spolykaly dvě věci, a ani jedna nebyla samotné generování kódu: babysitting prvního modulu na backendu a fine tuning designu na frontendu, kde se detaily dolaďovaly do podoby jedna ku jedné s původní aplikací.

❓ FAQ

Co je Claude Code?

AI agent od Anthropicu, který běží v terminálu, čte a upravuje soubory v projektu, spouští příkazy a testy. Na rozdíl od doplňování kódu v editoru pracuje s celým repozitářem. Víc o tom, jak s ním pracovat v praxi, najdete v článku o agentním vývoji a ADLC.

Proč pouštět AI agenta v dev containeru a ne přímo na svém stroji?

Agent na hostu má stejná práva jako vy: soubory, klíče, přístupy, databáze. Dev container je Docker kontejner nastavený jako plnohodnotné vývojové prostředí, takže agent nemůže nic rozbít za jeho hranicí. Bonus: můžete mu dovnitř dát širší práva a nepotvrzovat každý příkaz.

Co je Context7 a proč ho při přepisu použít?

Context7 je MCP server, který modelu dodá aktuální oficiální dokumentaci knihoven přímo v momentě dotazu. Tím zabrání halucinacím typu „použiju funkci, která v téhle verzi neexistuje“ a zároveň šetří tokeny.

Co jsou Claude skills a čím se liší od promptu?

Skill je markdown soubor s názvem, popisem a kroky, tedy zabalený workflow. Prompt zadáváte znovu a znovu, skill si agent vyvolá sám podle popisu. Ideální na rutinu – v tomhle případě přepis modulu, verifikaci proti specifikaci a E2E testy.

Vyplatí se Claude API, nebo předplatné?

Při krátkém experimentu API. Při intenzivní práci předplatné: 150 dolarů utracených na API za tři dny je víc než měsíční tarif vyššího předplatného.

Oficiální Figma MCP, nebo Figma Context MCP od Framelinku?

Oficiální Figma MCP je funkční na dolaďování detailů, ale má přísnější rate limit (na Pro tarifu řádově dvě stě volání denně) a je osekanější. Neoficiální Figma Context MCP jde přes API s vyššími limity a vrací popisný JSON se zachovanými názvy stylů.

V jakém jazyce psát prompty?

Oba řečníci promptují v angličtině. Podstatnější než jazyk je ale kontext: cesty k souborům, které se mají měnit, screenshoty, seznam použitých knihoven a jejich dokumentace. A celé věty místo odrážek.

Je potřeba vygenerovaný kód po AI agentovi ručně upravovat?

Drobnosti ano, ale cíl je nesahat na kód vůbec. Když agent chybuje, dostane instrukci, jak to udělat jinak – místo aby to člověk opravil za něj. Souvisí s tím i to, jak se mění role QA a testování; o tom je článek Jak AI změnila softwarové testování.

🎯 Co si odnést

Přepis za týden nebyl výsledkem toho, že by AI psala kód rychleji než člověk. Byl výsledkem přípravy, která na první pohled vypadá jako zdržování: izolované prostředí, čistá codebase, pravidla v CLAUDE.md, aktuální dokumentace v kontextu a hlavně detailní specifikace jako zadání. Teprve nad tím má smysl zabalit rutinu do skillů a nechat kolečko přepis → verifikace → E2E testy běžet samo.

Na lidech zůstalo definovat, co se má vlastně postavit, a podepsat se pod to při code review. Zbytek je delegovatelný – a ten skok mezi „AI mi doplňuje řádky“ a „AI přepisuje moduly, zatímco já dělám review“ je větší, než se z benchmarků zdá.

Celý příběh i s dotazy z publika najdete v záznamu přednášky. Termíny dalších Ackee Meets sledujte na Eventbritu a přihlaste se k newsletteru – příští takový obsah vám přijde přímo do schránky.