Přepsat starý systém není těžké. Těžké je dokázat, že nový dělá přesně to samé. Každý, kdo někdy přepisoval COBOLový job nebo monolit v PHP 5, zná ten scénář: nový kód je hezčí, testy nějak prošly, a stejně nikdo netrefí, co se rozbije až po nasazení. Modernizace legacy kódu s oficiálním pluginem code-modernization pro Claude Code tenhle problém řeší jinak — místo slibu „bude to fungovat" dostaneš důkaz, který si ověříš skriptem.
Plugin pochází přímo od Anthropic, je zdarma jako součást Claude Code a podle marketplace má k 14. říjnu 2026 kolem 5 900 instalací. Ukážu ti, jak workflow vypadá, kde jsou jeho limity a proč je ten „důkaz" zajímavější než samotný přepis.
Co plugin code-modernization umí
Nainstaluješ ho jedním příkazem v Claude Code:
/plugin install code-modernization@claude-plugins-official
Pak na něj ukážeš legacy kód a dostaneš čtyři věci:
- Porozumění — co systém dělá, jaké má závislosti a byznysová pravidla.
- Plán ke schválení — nic se nepíše, dokud plán nepodepíšeš.
- Modernizovaný kód — ve zvoleném cílovém stacku.
- Důkaz — nezávislé ověření, že nový kód se chová jako starý, s verdiktem PROVEN / PARTLY PROVEN / NOT PROVEN.
Funguje na jakýkoliv jazyk. Anthropic ho podle dokumentace testoval na COBOLu (CICS + JCL → Java 21), Javě 8 → 17, PHP 5 → Python/FastAPI, AngularJS → React, Pythonu 2 → 3, Perlu, C, .NET Framework 4.7.2 → .NET 10, Rails 3.2 → 7.1 i Jenkins pipelinech → GitHub Actions. Licencován je pod Apache 2.0.
Pokud už Claude Code používáš a chceš si pluginy psát sám, mrkni na návod jak vytvořit plugin pro Claude krok za krokem — code-modernization je ukázka toho, jak daleko se dobře navržený plugin dá dotáhnout.
Workflow krok za krokem: modernizace legacy kódu v praxi
Celý proces je řetěz příkazů, kde každý krok jde zkontrolovat dřív, než pustíš další. Stav se drží v souborech (INTENT.md, PREFLIGHT.md, BUSINESS_RULES.md…), ne v chatu — takže v práci může pokračovat kolega nebo nová session.
1. Zadání a preflight
/code-modernization:modernize sepíše, co chceš, do INTENT.md. Pak modernize-preflight ověří prostředí: položí ti 5 otázek, které umí zodpovědět jen člověk (kde je zdroják, co je produkce, co je testovací prostředí), a dokáže, že jde projekt sestavit.
2. Mapování a byznysová pravidla
modernize-assess udělá inventuru — velikost, složitost, dluh, bezpečnost — a doporučí cestu. modernize-map vykreslí závislosti, toky dat a entry pointy jako interaktivní mapu.
Nejzajímavější je modernize-extract-rules: z kódu vytěží byznysová pravidla jako testovatelné karty Given/When/Then s citací soubor:řádek a každou kartu nechá přepočítat druhým nezávislým agentem. Pozor — tahle fáze spouští 50–200 agentů najednou, takže na větším systému poznáš na spotřebě. Začni jedním modulem jako pilotem. Pochybná pravidla pak člověk potvrdí nebo opraví v modernize-review.
3. Brief — brána, kde rozhoduješ ty
modernize-brief vytvořte fázový plán pro steering committee. Dokud ho neschválíš, nepostaví se nic. To je jedna z šesti lidských rozhodovacích bran, které plugin nikdy neobejde — od preflight otázek přes schválení plánu až po podpis finálního důkazu.
4. Tři cesty buildu
Podle typu modernizace vybereš jednu ze tří cest:
- Uplift — stejný stack, novější verze (.NET Framework → .NET 8, Spring Boot 2 → 3). Plugin jede podle katalogu breaking changes, které tvůj kód skutečně zasahují, a první jednotku udělá jako pilot.
- Transform — přepis do nové technologie po modulech. Starý systém mezitím běží, starý i nový kód se pouští na stejných vstupech a skript porovná výstupy.
- Reimagine — greenfield rebuild na nové architektuře. Specifikace se vytěží ze starého kódu, architekturu schvaluješ, služby se scaffoldují rovnou se spustitelnými akceptačními testy.
5. Verify — ten slíbený důkaz
modernize-verify je nezávislá re-kontrola, ideálně v čisté session. A je to důkaz z evidence, kterou ověří skript, ne názor modelu:
- Testy se smažou a pustí znovu z čista; počty se čtou z výsledkových souborů runneru. Nula spuštěných testů = selhání.
- Starý a nový systém běží na stejných vstupech a skript porovnává výstupy bajt po bajtu; maskují se jen pole, která se lišit musí (timestamps, generovaná ID), a každé maskované pole je vypsané.
- Plugin vymyslí aspoň 10 nových vstupů (hraniční hodnoty, prázdné, obří, poškozené záznamy), aby neprošly suity, které fungují jen na vstupech vybraných modelem.
- Kanár: záměrná jednořádková změna musí testy zčervenat. Pokud ne, testům se nevěří.
- Každé kritické (P0) byznysové pravidlo musí mít pojmenovaný test, který proběhl a prošel — ne přeskočený.
Výsledek je verdikt na modul: PROVEN, PARTLY PROVEN (se seznamem, co chybí) nebo NOT PROVEN. Když starý systém nejde spustit lokálně (mainframe, produkce-only), nejlepší možný verdikt je PARTLY PROVEN — a plugin to rovnou říká.
Kdo pracuje s většími autonomními běhy, zná podobný princip z článku o Chief of Staff patternu pro řízení dlouhých běhů Claude Code — tady je verifikace ale zabudovaná přímo do workflow.
Co ukázaly reálné testy
Anthropic plugin testoval na veřejných kódech a výsledky dokumentuje v README (stav k říjnu 2026):
- osCommerce (PHP 5 → Python/FastAPI): 97 byznysových pravidel, řez produktovou stránkou, 17 957 testů prošlo, 17 727 porovnání identických, dvě záměrné změny testy zčervenaly. Verdikt: PROVEN. Cestou se našly 2 kritické chyby v původním kódu (expirované slevy se zobrazovaly dál, lock při zápisu do DB).
- Eclipse Jetty (Java 8 → 17): pilot na
jetty-util, stejných 946 testů na obou verzích, 6 nepředvídaných změn chování, po doplnění 50 testů žádný rozdíl. - AWS CardDemo (COBOL → Java): přepis jobu pro měsíční výpočet úroků, 213 testů. Finální kontrola s 15 poškozenými vstupy našla 7 dalších rozdílů → NOT PROVEN. Přesně takhle má důkaz fungovat — nezdařilo se to a plugin to řekl.
Ta poslední ukázka je důležitá: důkaz není razítko, které se dává vždy. Když něco nesedí, dostaneš seznam rozdílů a člověk každý z nich schválí nebo opraví.
Bezpečnost: legacy kód je nedůvěryhodný vstup
Plugin pracuje se starým kódem jako s nedůvěryhodnými daty — instrukce zasazené v komentářích nebo README se nevykonávají, jen se vypíšou v reportu. Další garance:
- Nikdy needituje legacy zdrojáky. Zápis hlídá
.claude/settings.jsondeny pravidly (např.Edit(/legacy/**)), analýza běží přes symlinky a scratch kopie. - Nalezené secrets maskuje (
AKIA****) a inventarizuje do gitignorovanéhoSECRETS.local.md. - Produkce a třetí strany jsou off-limits, dokud je schválený plán výslovně nejmenuje.
- Telemetrie posílá jen zaokrouhlená celá čísla, nikdy kód, názvy souborů ani prompty — a jde vypnout přes
CODE_MODERNIZATION_TELEMETRY=0.
Cena za to všechno? Plugin je zdarma, platíš jen běžnou spotřebu Claude Code — a ta u fan-out fází není malá. Pokud řešíš rozpočet, pomůže přehled kolik stojí Claude Code v roce 2026 a triky na model routing pro úsporu tokenů. Pro týmové nasazení se hodí i pravidla z článku o AI coding governance.
Na co si dát pozor
- Čas a spotřeba: na systémech v řádu desítek tisíc řádků počítej s minutami na fázi (preflight 3–4 min, extract-rules 5–15 min, build jednoho modulu 15–30 min). Na milionech řádků pracuj po modulech — jinak agenti dojedou kvótu dřív, než se dostaneš ke důkazu.
- Důkaz má podmínky: bez toolchainu pro starý stack (nejde sestavit/spustit lokálně) spadneš na slabší variantu s nahranými výstupy a verdikt PARTLY PROVEN.
- Je to workflow, ne kouzlo: 6 lidských bran znamená, že někdo musí plány číst a podepisovat. Plugin šetří práci, ne rozhodování.
- Vyžaduje Claude Code a Python 3.8+ na stroji.
Víc o nástroji najdeš na stránce Claude Code v našem katalogu AI nástrojů.
Časté otázky
Je plugin code-modernization zdarma?
Ano, plugin samotný je zdarma pod licencí Apache 2.0. Platíš jen za běž používání Claude Code podle svého tarifu — a protože fáze jako extract-rules spouštějí 50–200 agentů najednou, na větším systému je spotřeba citelná. Proto se doporučuje začít jedním modulem jako pilotem.
Umí plugin modernizovat COBOL nebo jiný starý jazyk?
Ano. Podle oficiální dokumentace byl testován na COBOLu (CICS + JCL → Java 21), Perlu, C, PHP 5, Java 8, .NET Framework, Rails 3.2 i AngularJS. Jazyk není podmínkou — důležitější je, jestli starý systém jde sestavit a spustit, protože bez toho je nejsilnější důkaz (starý a nový na stejných vstupech) nedostupný.
Co když se chování nového kódu liší?
Dostaneš verdikt PARTLY PROVEN nebo NOT PROVEN se seznamem konkrétních rozdílů. Každý rozdíl musí člověk buď schválit se zdůvodněním (zaznamená se do výsledku), nebo nechat opravit. Plugin rozdíly nikdy nezametá pod koberec — i záměrná jednořádková změna v testu se kontroluje jako kanár.
Musím přepsat celý systém najednou?
Ne, a ani bys neměl. Workflow je navržený na práci po modulech: nejdřív pilotní jednotka end-to-end včetně důkazu, pak dávky. Starý systém u cesty Transform běží dál, dokud nepřepíšeš všechno.
Čím se liší od běžného „přepiš mi to" v chatu?
Třemi věcmi: strukturovaným plánem s lidskými schvalovacími branami, bezpečnostními garancemi (legacy kód se nikdy needituje, secrets se maskují) a hlavně nezávislým důkazem behaviorální ekvivalence — skriptem ověřitelnou evidencí, ne tvrzením modelu, že „to vypadá dobře".
Závěr
Modernizace legacy kódu s pluginem code-modernization není o tom, že AI napíše nový kód rychleji. To zvládne lecjaký prompt. Hodnota je v tom, že dostaneš proces, kde plán schvaluje člověk, starý kód zůstane nedotčený a na konci je důkaz, který si můžeš přepočítat — včetně kanáru, který ověří, že tvoje testy vůbec umějí selhat.
Máš v ruce legacy systém? Zkus jeden modul jako pilot: modernize-preflight, assess, brief a teprve po schválení build. Nejjdřív poznáš spotřebu i kvalitu výstupu na něčem, co nezabolí. Zdroje: oficiální README pluginu na GitHubu a záznam na Claude marketplace (obojí ověřeno 14. 10. 2026).
