Modernizacja starego systemu to jedno z najbardziej ryzykownych zadań w IT. Nowy kod przechodzi testy, które ktoś napisał — i różni się od starego na danych, o których nikt nie pomyślał. Wtyczka Code Modernization z oficjalnego katalogu wtyczek Claude Code podchodzi do problemu inaczej: poza nowym kodem dostarcza dowód, że zachowuje się on tak samo jak stary.
Co dostajesz
- Zrozumienie systemu — inwentaryzację, złożoność, dług techniczny, bezpieczeństwo i interaktywną mapę zależności.
- Reguły biznesowe wydobyte z kodu jako karty Given/When/Then z odwołaniem do pliku i linii, każda sprawdzona przez drugiego agenta.
- Plan etapowy, który zatwierdza człowiek — nic nie jest budowane przed akceptacją.
- Zmodernizowany kod i dowód równoważności z werdyktem dla każdego modułu.
Działa z dowolnym językiem i trzema rodzajami migracji: nowsza wersja tej samej technologii (np. .NET Framework → .NET 8, Java 8 → 17), przepisanie na inną technologię moduł po module albo przebudowa na nową architekturę.
Instalacja i start
/plugin install code-modernization@claude-plugins-official
# w katalogu roboczym:
/code-modernization:modernizeKomenda startowa zadaje kilka pytań o cel, zapisuje odpowiedzi w INTENT.md i podaje dokładną pierwszą komendę. Jeśli nie wiesz, czego chcesz, wybierz „Understand it first” — dostaniesz analizę, mapę, reguły i plan bez przebudowy kodu. Kluczowa zasada bezpieczeństwa: wtyczka nie edytuje kodu źródłowego — zapisuje tylko do analysis/<nazwa>/ i modernized/, a stan prac pokazuje jeden raport REPORT.html.
Ścieżka krok po kroku
| Krok | Komenda | Rezultat |
|---|---|---|
| 1 | modernize-preflight | Czy środowisko jest gotowe, czy kod się buduje, czego brakuje. |
| 2 | modernize-assess | Inwentarz, złożoność, dług, bezpieczeństwo, rekomendowany wzorzec. |
| 3 | modernize-map | Zależności, przepływ danych, punkty wejścia — mapa interaktywna. |
| 4 | modernize-extract-rules + modernize-review | Reguły biznesowe do potwierdzenia przez eksperta. |
| 5 | modernize-brief | Plan etapowy do zatwierdzenia. |
| 6 | uplift / transform / reimagine | Budowa nowej wersji. |
| 7 | modernize-verify | Dowód: werdykt PROVEN, PARTLY PROVEN lub NOT PROVEN. |
| 8 | modernize-harden | Skan bezpieczeństwa starego systemu z łatką do samodzielnego zastosowania. |
Jak wygląda „dowód”
Werdykt nie jest opinią modelu, tylko wynikiem skryptu liczonego z plików, które można sprawdzić. Weryfikacja uruchamia testy od zera, uruchamia stary i nowy kod na tych samych danych i porównuje wyniki bajt po bajcie. Wymyśla też co najmniej dziesięć nowych danych wejściowych (wartości graniczne, puste, ogromne, uszkodzone rekordy). Wprowadza celowy błąd („canary”), który musi zaczerwienić testy. Sprawdza też, czy każda krytyczna reguła jest pokryta testem, który naprawdę się wykonał. Człowiek podejmuje decyzję w sześciu punktach — m.in. zatwierdza plan, akceptuje różnice i podpisuje dowód.
Na czym to przetestowano
Autorzy uruchomili komendy na publicznych projektach, m.in. AWS CardDemo (COBOL → Java 21), Eclipse Jetty (Java 8 → 17: te same 946 testów z identycznym wynikiem na obu wersjach), osCommerce (PHP → Python/FastAPI) i Spring PetClinic (Spring Boot 2.6 → 3.3). Uczciwie raportują też porażki — kilka migracji zakończyło się werdyktem NOT PROVEN, bo nowe dane testowe ujawniły różnice. To dobry znak: narzędzie mówi prawdę zamiast udawać sukces.
Praktyczne wskazówki
- Zacznij od pilota — jednego modułu, nie całego systemu. Najcięższy krok (
extract-rules) uruchamiał w testach od 50 do 200 agentów. - Zablokuj edycję źródła regułą
denyw.claude/settings.json— wtyczka sprawdza to w preflight. - Zaangażuj inżyniera, który zna system — pięć pytań preflight wymaga ludzkiej wiedzy.
- Traktuj analizowany kod jako niezaufany — wtyczka ignoruje „instrukcje” ukryte w komentarzach i README, maskuje znalezione hasła.
Wtyczka wysyła anonimowe liczniki użycia (wyłącznie liczby) przez telemetrię Claude Code; można to wyłączyć zmienną CODE_MODERNIZATION_TELEMETRY=0. Pełna dokumentacja: code-modernization na GitHubie.