Legacy kódbázis migrálása coding agentekkel: strangler fig playbook

A legacy migráció a szoftverfejlesztés legkevésbé romantikus része: egy framework-frissítés négyezer fájlon át, egy nyelvi port, amit senki nem akar vállalni, egy API-változás, amit már három release óta halogatunk. 2025-2026-ban a coding agentek pontosan erre a munkára váltak használhatóvá. A Google arról számolt be, hogy 39 migráció során tizenkét hónap alatt a benyújtott kódváltozások 74,45%-át és az editek 69,46%-át a saját LLM-es eszköze generálta, a mérnökök pedig 50%-os teljes időmegtakarítást becsültek. Az Amazon azt állítja, hogy kódtranszformációs agentjével több tízezer Java termelési alkalmazást vitt át Java 17-re, és több mint 4500 fejlesztőévet takarított meg.

A csapda: a migráció nem gépelési probléma. Az agent hihető diffet gyárt olyan kódról, amit nem ért, a legacy kód pedig pont az, amit senki nem ért teljesen. Az agentes migrációt nem a jobb prompt teszi működőképessé, hanem az agent körüli állványzat: egy harness, amely megmutatja, változott-e a viselkedés, seam-ek, amelyek kicsiben tartják a változást, és review gate-ek, amelyek elkapják, amit a tesztek nem. Ezt a folyamatot használnám, és itt nem vetnék be agentet.

A szűk keresztmetszet elmozdult, de nem tűnt el

A Google számai gyakran úgy hangzanak, mintha a migráció megoldott probléma lenne. Ha elolvasod a tanulmányt, a kép konkrétabb: az eszköz a statikus elemzés és a mérnökök által talált helyekre mutatott, szimbólumhivatkozásokkal bővítette a fájlhalmazt, fájlcsoportonként diffet generált, fordított és unit teszteket futtatott, hiba esetén pedig repair loopot indított. A modell az editelést végezte. A mérnökök továbbra is kiválasztották a migrációt, megtalálták a fájlokat, review-zták a változásokat és kigördítették őket. Az 50% a teljes idő csökkenése, nem a rendszer megértésével járó munka csökkenése.

Az Amazon Java-története ugyanilyen alakú. Az agent a függőségek migrációját és a build-and-test ciklust automatizálja egy olyan alkalmazásnál, amelynek a határai már ismertek: egy Java 8-ról vagy 11-ről 17-re lépő Java-alkalmazásnál. Ez nagy, repetitív, jól specifikált transzformáció. Nem egy üzleti folyamat újraírása.

A használható állítás tehát szűk: az agentek a migráció repetitív közepének költségét csökkentik. Nem csökkentik annak költségét, hogy kiderítsük, mit tesz a régi rendszer, eldöntsük, mit tegyen az új, és bizonyítsuk, hogy a kettő megegyezik. A folyamatot erre a három feladatra kell tervezni.

Miért bukik meg a big-bang rewrite

Martin Fowler strangler fig patternje húszéves, és még mindig a jó alapértelmezés. A kudarcmódot kíméletlenül írja le: az egyszerű csereprogram „most of the time” lángokba borul, mert egy komoly rendszer lecserélése sokáig tart, a felhasználók nem várhatnak az új funkciókra, a meglévő viselkedés részleteit pedig nehéz specifikálni. A viselkedés egy része nem is kívánatos, így az újraépítése pazarlás.

A coding agentek olcsóbbnak mutatják a cserét, mint amilyen. Egy képernyő vagy egy endpoint újraimplementálása egy délután; a maradék 80% az a rész, ahol a számlák szökőnapon másképp kerekítenek, egy riport egy archivált táblától függ, és egy háttérjob olyan mezőt ír, amit három másik szolgáltatás olvas. Ebből semmi nincs a demóban.

A strangler fig válasz: az új rendszert a régi köré növeszteni. Egy viselkedés elé seam-et tenni, azt a viselkedést új kódba mozgatni, a forgalmat fokozatosan átirányítani, és a régi utat addig tartani, amíg az új ki nem érdemli a bizalmat. Fowler a ragasztót „transitional architecture”-nek nevezi, és megjegyzi, hogy pazarlásnak látszik; valójában annak az ára, hogy nem tesszük fel a vállalkozást egy cutover hétvégére.

Előbb a harness, aztán az első agent feladat

Michael Feathers characterization tesztje az az eszköz, ami lehetővé teszi a legacy munkát: olyan teszt, amely a meglévő kód tényleges viselkedését írja le, nem azt, amit a dokumentáció állít. Ez egy változásdetektor. Nem azt mondja, hogy a régi viselkedés helyes; azt mondja, hogy mikor változott meg. A golden master teszt ugyanez egy teljes válasz szintjén: rögzítsd a kimenetet egy bemenethalmazra, normalizáld a volatilis részeket, és hasonlítsd össze.

Egy migráció első agent feladata nem kódváltozás. Hanem az, hogy a rendszer futtatható és megfigyelhető legyen: build CI-ben, indítás valódi függőségekkel, reprezentatív kérések rögzítése, és annak feljegyzése, mit ad vissza a régi rendszer. Egy 2026-os environment-in-the-loop migrációs tanulmány szerint a kód és a környezet együtt mozog; a célkörnyezet statikus elemzése nem elég, a lassú visszacsatolás pedig újramunkát okoz. Az agent, amely nem tudja elindítani a régi rendszert, tippel.

Aztán építsd fel az orákulumot rétegenként. Az alábbi táblázat az általam használt sorrend; minden réteg kevesebbe kerül, mint az incidens, amit megelőz.

Ebben nincs semmi új: ugyanaz a harness-érv, mint aharness engineering cikkben, csak olyan kódbázisra alkalmazva, amit soha nem erre terveztek. De az agent készséggel generál ezer sort egy gyenge orákulum ellen, így a harness nem nice-to-have többé, hanem az, ami őszintén tartja a migrációt.

Egy seam, egy feladat

A kis hatókör melletti legerősebb bizonyíték egy 2026-os gyakorlati felmérés: 61 iparági válaszadóból 62,3% tartotta az LLM-segítséget legtöbbször vagy szinte mindig elfogadhatónak egyfájlos migrációnál, de csak 4,9% mondta ugyanezt teljes projekt migrációjára. A bizalom szemantikai helyességen, projektkontextuson, biztonságon, ellenőrzési bizonyítékokon és provenance-on múlott. A gyakorlati szakemberek nem utasítják el az agenteket; korlátok közé szorítják őket.

A GitHub Copilot cloud agent egyszerre egy branchen dolgozik, feladatonként egy pull requestet nyit, és a session hossza legfeljebb 59 perc. Az Anthropic hosszú futású harness-e feature listát ad az agentnek, egyszerre egy feature-rel dolgoztatja, és tiszta állapotot kér tőle committal és haladási feljegyzéssel. A közös szabály: egy feladat, egy ellenőrizhető eredmény, egy átnézhető diff.

Egy task kártya többet ér, mint egy hosszú prompt:

# migrate-invoice-total
scope: src/billing/invoice-total.ts + its tests only
goal: replace the legacy rounding helper with the new money library
invariants:
  - totals for existing fixtures are byte-identical
  - currency is never coerced to float
  - the public function signature does not change
out of scope: invoice PDF rendering, tax rules, database schema
done when: golden tests pass, contract test passes, no new lint warnings
evidence: test output, diff summary, list of intentionally changed fixtures

Két sor végzi a legtöbb munkát: a fájllista és az out-of-scope lista. Határt adnak az agentnek, és a review-nek módot arra, hogy visszautasítsa az elkóborolt diffet. Az Anthropic harness-e tovább megy: megtiltja az agentnek, hogy a feature listát vagy a teszteket szerkessze; ha egy teszt hibás, azt ember javítja külön commitban. Ez az egy szabály akadályozza meg a leggyakoribb hibát, amit agentes migrációkban láttam: az agent addig igazítja az orákulumot, amíg az egyet nem ért az új kóddal.

A ciklus: route, kiemelés, ellenőrzés, kivezetés

A mechanika elfér egy oldalon. Tegyél routert vagy facade-ot a legacy út elé. Válassz egy vertikális szeletet tiszta szerződéssel. Emeld ki ugyanazon interfész mögé, hogy a hívók ne változzanak. Irányítsd a forgalom kis részét az új implementációra, és hasonlítsd össze az eredményeket. Növeld az arányt, ahogy nő a bizalom. Amikor az új út egy teljes üzleti cikluson át vitte a szeletet, töröld a régi kódot.

Az összehasonlítás a fontos lépés, és többet kell összevetnie status kódoknál. Naplózd a régi és az új kimenetet ugyanarra a bemenetre, normalizáld az időbélyegeket és azonosítókat, a többit pedig diffeld. Ha eltérnek, döntsd el, hogy a különbség az új kód bugja, vagy a régi viselkedés bugja, amit szándékosan javítasz. Írd le a döntést; ez lesz a migráció specifikációja.

Fowler transitional architecture figyelmeztetése érvényes: a router és a dual-write kód ideiglenes, kell nekik tulajdonos és eltávolítási dátum. Az agent jó e ragasztó termelésében; abban is jó, hogy többet termeljen belőle, mint kell. Tartsd unalmasnak a ragasztót, és töröld határidőre.

Amiben az agentek tényleg jók

Az agentek ott a legerősebbek, ahol a munka széles, repetitív és lokálisan ellenőrizhető. API átnevezése több száz hívási helyen, importok és típusannotációk frissítése, tesztcsomag portolása, ugyanaz a hibakezelés húsz handlerben, vagy egy ismeretlen modul elolvasása és szerződéseinek összefoglalása: ezek gyors orákulumú, editenként kis robbanási sugarú feladatok.

A Google munkafolyamata a legvilágosabb példa: fájlcsoportonként diffet generálni, fordítani, teszteket futtatni, a hibákat visszatáplálni javításra. Az agentnek nem kell elsőre jónak lennie, ha a ciklus meg tudja mondani, hogy rossz. Ugyanez az elv magyaráz egy feltűnő belső eredményt az Anthropicnál: az újraírt ingestion pipeline 20-szor kevesebb memóriát fogyasztott és 4-szer gyorsabb lett, miközben megőrizte a sorrendre és adatszerkezetekre vonatkozó implicit invariánsokat. Ez egy szállító beszámolója, nem kontrollált vizsgálat, de a mechanizmus hihető: szoros helyességi ciklus és tiszta invariáns az a terep, ahol az agentek ragyognak.

A gyakorlati teszt: tudsz-e adni az agentnek egy parancsot, ami elbukik, ha téved? Ha igen, delegálj agresszívan. Ha az egyetlen visszacsatolás az ember, aki a diffet olvassa, tartsd kicsiben a feladatot.

Amit az agentek elrontanak a legacy kódon

Három hibatípus számít többet a benchmark pontszámoknál.

Először: az agent nem tudja, melyik viselkedés teherhordó. A METR 2025-ös randomizált vizsgálata szerint tapasztalt open-source fejlesztők 19%-kal lassabbak voltak AI-eszközökkel a saját érett repójaikban, pedig 24% gyorsulást vártak, és utólag azt hitték, gyorsabbak voltak. A feladatoknak implicit követelményei voltak: stílus, tesztek, dokumentáció és soha le nem írt konvenciók. A legacy migrációk pontosan ezekből állnak.

Másodszor: az agentek a lokális mintát optimalizálják, és megsértik a rendszerszintű megkötést. Az Anthropic beszámolója a source control migrációról szokatlanul őszinte: az agentek néha úgy próbáltak megfelelni egy mintának, hogy közben eltörtek egy alapvető invariánst, és a mérnököknek nemet kellett mondaniuk. Az adversarial review ezt ronthatja, túlmérnökölt védelmet gyártva hipotetikus problémák ellen. A csapat továbbra is minden change requestet review-zott, de a szándékot, nem minden sort.

Harmadszor: a benchmark nem a te kódbázisod. 2026 februárjában az OpenAI leállította a SWE-bench Verified jelentését, mert egy audit a 27,6%-os minta legalább 59,4%-ában hibás teszteket talált, és a modellek a training adatból reprodukálni tudták a gold patcheket. A magas pontszám azt jelenti, hogy a modell sok kicsi, jól specifikált Python issue-t látott. Nem azt, hogy tudja, milyen volt a számlakerekítési szabályod 2013-ban.

A legacy-specifikus veszélyek: még ütemezett holt kód, szolgáltatások közötti implicit szerződések, nem visszafordítható adatmigrációk, concurrency- és sorrend-feltevések, és olyan teljesítmény, amely egy konkrét query plantől függ. Az agent mindezt magabiztosan megváltoztatja. Hogy biztonságos volt-e, csak a harness és a reviewer tudja megmondani.

Review gate-ek, amelyek elkapják a migrációs hibákat

A review az agentes migráció átbocsátóképességének korlátja, és a rossz review folyamat a gyorsulást várakozássá változtatja. A gate-jeim:

• Egy seam pull requestenként, diff budgettel. Ha a diff túllépi a budgetet, a feladatot oszd fel, ne a review-t.
• Semmilyen tesztmódosítás a migrációs commitban. A tesztek külön commitban változnak, írásos indoklással.
• Két kulcs mindenhez, ami pénzt, identitást vagy törlést érint. Az agent javasolhat; ember hagyja jóvá.
• Bizonyíték a pull requestben: a lefuttatott parancs, a golden diff, a shadow összehasonlítás, a szándékosan megváltoztatott viselkedések listája.
• A szándékot review-zd, ne a formázást. Kérdezd meg, mit kell megőriznie a változásnak, és hogy a diff bizonyítja-e.
• Rollback útvonal, amit a forgalom átirányítása előtt kipróbáltok, nem az incidens után.

A GitHub saját dokumentációja kimondja, hogy az agent session logok nem helyettesítik a saját review-t és tesztelést. A review szűk keresztmetszete valódi, és rosszabb lesz, ha az agentek több diffet termelnek, mint amennyit a reviewerek fel tudnak dolgozni; a megoldás kisebb batchek és jobb bizonyítékok, nem a gyorsabb gumibélyegzés. A queue problémáról külön cikket írtam areview szűk keresztmetszetről.

Ellenőrzés a zöld teszteken túl

A zöld tesztcsomag azt bizonyítja, hogy a meglévő tesztek továbbra is átmennek. Nem azt, hogy az új út ugyanúgy viselkedik, mint a régi, olyan bemenetekre, amikre nem gondoltál. Három technika zárja be a rést.

Replay: rögzíts valódi kéréseket és a régi válaszokat, futtasd őket az új implementáción, és diffeld a normalizált kimenetet. Ez a legolcsóbb nagy értékű ellenőrzés, és elkapja a kódolási, null- és kerekítési eltéréseket, amelyeket a unit tesztek kihagynak.

Shadow: élő forgalom másolatát küldd az új útra anélkül, hogy a válaszát kiszolgálnád. Hasonlíts aszinkron. Ez elkapja a sorrendi, concurrency- és volumeneffektusokat, amiket a replay nem.

Invariánsok: olyan tulajdonságokat állíts, amelyeknek mindenképp teljesülniük kell, például „a tételek összege a végösszeg” vagy „egy számla nem megy ki kétszer”. Az invariánsok túlélik az implementációváltást; a golden fájlok nem.

const cases = await loadRecordedRequests("invoices/2026-q2");
for (const c of cases) {
  const before = normalize(await legacyTotal(c));
  const after = normalize(await nextTotal(c));
  expect(after, `case ${c.id}`).toEqual(before);
}

Normalizálj agresszívan: időbélyegek, id-k, sorrend, whitespace, locale formázás. Minden normalizált mező olyan mező, amelyet úgy döntöttél, hogy nem ellenőrzöl; tartsd rövid listán, és nézd át. Ha egy diff szándékos, jegyezd fel a migráció viselkedés-changelogjában, és adj hozzá tesztet, amely az új viselkedést állítja.

Amikor nem érdemes agentet használni

Az agent rossz választás, ha az orákulum hiányzik és nem építhető olcsón. Egy 15 éves rendszer tesztek, forgalomrögzítés, staging és befagyasztott szabályozási határ mellett nem migráció, hanem régészet; az első szállítható dolog a harness, nem a diff. Rossz választás egy egyszeri, 200 soros változtatáshoz is, ahol a scope és a review több munkával jár, mint maga a változtatás.

Rossz választás akkor is, ha a valódi feladat döntés: melyik rendszer birtokolja az adatot, maradjon-e a szállító, változzon-e a folyamat. Az agent implementálja a promptba tett választ, és nem figyelmeztet, hogy rossz volt a kérdés.

Végül légy szkeptikus a szállítói aritmetikával. A 4500 fejlesztőév és az 50%-os csökkenés konkrét programokból származik, konkrét határokkal. Nem előrejelzés a te repódra. Mérd a szeletenkénti cycle time-ot, a kiszökött hibákat, a review órákat és a rollbackek számát. Ha az agent megduplázza a diff mennyiségét, a review idő pedig nem változik, nem gyorsítottad a migrációt, hanem áthelyezted a sort. A trade-off szélesebb ökonómiája azAI-assisted development economics cikkben van.

Migrációs playbook kilenc lépésben

1. Írd le az eredményt és a határt: melyik viselkedés költözik, melyik nem, és honnan fogod tudni.
2. Tedd futtathatóvá a régi rendszert CI-ben, valódi függőségekkel.
3. Rögzíts reprezentatív bemeneteket és kimeneteket; maszkold a titkokat és a volatilis mezőket.
4. Tegyél characterization teszteket az első seam köré; fogadd el, hogy a jelenlegi viselkedést írják le, nem jóváhagyják.
5. Tegyél routert vagy facade-ot a seam elé.
6. Szeletenként task kártya fájlokkal, invariánsokkal, out-of-scope-pal és bizonyítékokkal.
7. Az agent branchen dolgozzon; ahol lehet, először bukó tesztet kérj.
8. Review diff budgettel, no-test-edits szabállyal és explicit rollbackkel.
9. Növeld fokozatosan a forgalmat, hasonlíts, majd töröld a régi utat és a ragasztót.

Források

1. Martin Fowler: Strangler Fig (2024)
2. Wikipedia: Characterization test
3. Google Research: Accelerating code migrations with AI (2024)
4. Ziftci et al.: Migrating Code At Scale With LLMs At Google (arXiv 2504.09691)
5. Anthropic: Effective harnesses for long-running agents (2025)
6. Anthropic: Redesigning source control at Anthropic (2026)
7. METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
8. Chand et al.: Why Industry Migrates and When It Trusts LLMs (ESEM 2026)
9. Li et al.: Environment-in-the-Loop: Rethinking Code Migration with LLM-based Agents (arXiv 2602.09944)
10. AWS: Amazon Q Developer just reached a $260 million dollar milestone (2024)
11. OpenAI: Why SWE-bench Verified no longer measures frontier coding capabilities (2026)
12. GitHub Docs: About GitHub Copilot cloud agent