Codebase-Migration über Tage statt Minuten
Eine Framework-Migration über 4.000 Dateien ist kein Prompt, sondern ein Betriebsvorgang: tagelange Laufzeit, tausende Checkpoints, Pull Requests in verdaulichen Blöcken. Das Erfolgskriterium ist unbestechlich — die Tests laufen durch oder nicht.
Eine agentengestützte Codebase-Migration arbeitet eine große Zahl gleichartiger Änderungen über Tage ab. Der Lauf ist zustandsbehaftet und überlebt Neustarts, jede Datei wird einzeln geprüft, und die Ergebnisse gehen als thematisch gruppierte Pull Requests in die Review. Erfolgskriterium ist die Testsuite, nicht die Einschätzung des Modells.
1. Ausgangslage
Ein internes Fachverfahren, gewachsen über neun Jahre. Die Migration auf eine neue Major-Version des Frameworks steht seit zwei Jahren im Backlog und wird jedes Quartal verschoben, weil sie niemand am Stück stemmen kann.
| Kennzahl | Wert | Anmerkung |
|---|---|---|
| Dateien im Repository | 4 100 | davon 2 600 betroffen |
| Testabdeckung | 64 % | Zeilen, Kernmodule höher |
| Geschätzter Aufwand manuell | 45 PT | Schätzung des Teams |
| Bisherige Anläufe | 2 | beide nach zwei Wochen abgebrochen |
Die letzte Zeile ist typisch. Migrationen scheitern selten an der Schwierigkeit einzelner Änderungen, sondern daran, dass niemand den halbfertigen Zustand über Wochen tragen will.
2. Agent-Design
- survey-agent — erstellt zu Beginn ein Inventar: betroffene Dateien, Muster, Abhängigkeiten, geschätzte Schwierigkeit je Datei. Ergebnis ist eine Arbeitsliste, die versioniert im Repository liegt.
- migrate-agent — arbeitet Datei für Datei ab. Je Datei: ändern, betroffene Tests ausführen, bei Fehlschlag maximal zwei Korrekturversuche, danach als „braucht Menschen“ markieren und weitergehen.
- batch-agent — gruppiert fertige Änderungen thematisch und erzeugt Pull Requests von höchstens 400 geänderten Zeilen — groß genug für Fortschritt, klein genug für echte Review.
Guardrails: Der Agent arbeitet ausschließlich auf einem Branch, hat kein Recht auf main und kann keine Pipelines auslösen, die deployen. Kein Zugriff auf Produktionsgeheimnisse. Tests laufen in einer isolierten Umgebung ohne Netzwerkzugang nach außen.
Weil das Erfolgskriterium maschinell prüfbar ist. Eine Datei gilt als migriert, wenn die zugehörigen Tests grün sind — nicht, wenn das Modell zufrieden ist. Bei Dateien ohne Tests fällt diese Prüfung weg; sie gehen deshalb grundsätzlich in die manuelle Review.
3. Architektur
4. Code
import { defineAgent, step } from "@hostspezial/agent-sdk";
export default defineAgent({
name: "framework-migration",
// Tage statt Minuten: Der Lauf darf lange leben und muss
// jeden Neustart der Plattform ueberstehen.
budget: { eur: 180, wallClockMs: 72 * 3_600_000 },
async run(ctx) {
const files = await step(ctx, "survey", () => ctx.tools.repo.scan({ pattern: "**/*.ts" }));
const done: string[] = [], manual: string[] = [];
for (const file of files) {
// step() ist der Checkpoint. Nach einem Absturz setzt der Lauf
// bei genau dieser Datei auf — bereits erledigte werden
// uebersprungen, nicht erneut bearbeitet.
const r = await step(ctx, `migrate:${file}`, { retry: { attempts: 2 } }, async () => {
await ctx.tools.repo.edit(file, ctx.plan(file));
return ctx.tools.ci.runTests({ scope: file }); // das Erfolgskriterium
});
(r.passed ? done : manual).push(file);
// PRs in Review-Groesse statt eines 2 600-Dateien-Monsters.
if (done.length % 25 === 0) {
await step(ctx, `pr:${done.length}`, () => ctx.tools.git.openPr(done.slice(-25)));
}
}
return { migrated: done.length, manual: manual.length, manual };
},
});5. Ergebnis
Die verbleibenden 9 Personentage sind fast vollständig Review-Zeit — und das ist richtig so. Der Agent hat 78 Prozent der Dateien bearbeitet und für jede den Testlauf als Nachweis geliefert; die restlichen 22 Prozent hat er als solche markiert, statt sie zu raten. Die dritte Zahl ist die eigentlich relevante: Ein Vorhaben, das zweimal abgebrochen wurde, ist abgeschlossen.
… Codebasen ohne nennenswerte Tests. Ohne maschinelles Erfolgskriterium verschiebt sich die gesamte Prüflast in die Review, und der Nutzen kippt ins Negative. … Änderungen, die fachliche Entscheidungen erfordern — ein neues Datenmodell ist keine Migration, sondern Design. … Repositories mit stark verflochtenen Modulen, in denen jede Änderung fünf andere berührt; dort scheitert die Aufteilung in kleine PRs. Und die Kosten sind nicht null: Ein Lauf dieser Größe liegt im dreistelligen Euro-Bereich an Modellkosten.
Verwandte Seiten
Erst das Inventar, dann die Entscheidung
Wir lassen den survey-Agenten über Ihr Repository laufen und liefern eine Arbeitsliste: betroffene Dateien, geschätzte Automatisierungsquote, erwartete Modellkosten. Danach entscheiden Sie, ob sich der Lauf lohnt.