We had ~70 legacy Go API endpoints that needed migrating to a modern framework. Instead of doing it manually ticket by ticket, I built a multi-agent AI system that grouped, delegated, and executed migrations autonomously — including running overnight while I slept.
The agents coded all ~70 migrations in just 2 days. The remaining weeks were spent on code review, feedback cycles, and merging PRs into the codebase.
Results: ~30 PRs opened. Most merged or in review. Code quality: 8/10.
This entire article was vibe-coded during a morning walk using voice chat, then lightly edited. That's the world we live in now.
Tools Used
MCP Integrations (Model Context Protocol):
- Jira MCP — connects directly to the project board, pulls all migration tickets with descriptions, acceptance criteria, and links to legacy code
- Git MCP — branch creation, commits, pull request management
- Filesystem — direct access to the codebase for reading and writing
Claude Code CLI — the runtime that orchestrates everything. Previously I used Claude inside Cursor, but switched entirely to Claude Code CLI — it handles larger changes and runs multi-step workflows autonomously.
Skills Hierarchy
Skills are reusable workflow templates. I built a hierarchy where each level calls the next:
migrate-batch ← INPUT: list of ticket IDs
└─ for each ticket:
└─ migrate-fullstack ← runs FE + BE together
├─ migrate-backend ← backend migration
└─ migrate-frontend ← frontend migration
migrate-batch — takes a list of tickets, groups similar ones into logical PRs (e.g. all User endpoints in one PR), then kicks off migration for each group. This turned 70+ tickets into ~20 focused PRs instead of 70 scattered ones.
migrate-fullstack — splits work into backend and frontend streams running in parallel. Each stream knows its own context and patterns.
migrate-backend / migrate-frontend — the actual migration workers. They're pre-loaded with codebase standards, test patterns, and target framework conventions.
Custom Agents (The Team)
Inside each migration, specialized agents handle different layers of the codebase. Think of them as a dev team where everyone is an expert in their area:
Orchestrator — the tech lead. Reads the ticket, delegates to specialists, tracks progress, collects results. Never writes code itself — only coordinates.
Code Researcher (read-only) — the analyst. Digs into the legacy Go code, traces the full request flow, documents all dependencies, business rules, edge cases, and the request/response contract.
Store Agent — the database specialist. Writes the data access layer and tests. Knows the project's SQL patterns, handles null checks, parameterized queries.
Service Agent — the business logic expert. Wires up store calls and external APIs into endpoint handlers. Implements all business rules identified by the researcher.
External API Agent — handles integrations with third-party services. Knows retry patterns, error handling, timeout configs.
Reviewer Agent (read-only) — the senior reviewer. Checks correctness, pattern compliance, test coverage, security. Returns specific feedback with file and line references.
Execution order: Researcher → Store → External API → Service (assembles everything) → Reviewer → fixes if needed → PR ready.
Each agent has its own context window, its own tools (some are read-only for safety), and its own system prompt with detailed instructions.
Key Principle: Atomicity
The most important insight: learn the first migration manually, then scale the pattern.
I spent 2–3 days setting up the system:
- Did the first migration hands-on, understanding every step
- Encoded each step into an agent with specific instructions
- Compiled agents into skills with clear input/output contracts
- Tested on a few more migrations with manual review
- Once confident — launched batch migration
Without this upfront investment, the agents would produce inconsistent, low-quality code. The 2–3 days of setup paid for themselves on the first batch run.
Running Overnight — 2 Days of Agent Coding
The entire batch of PRs was generated in roughly 2 days of agent runtime. Here's how:
Claude Max has usage limits — I hit them multiple times during heavy migration runs. The limits reset approximately every 4 hours.
My solution: when the system hits a rate limit, it automatically pauses and retries after the cooldown period. I launched the batch migration on my laptop, went to sleep, and woke up to completed PRs. Between the active coding sessions and overnight runs, all migrations were coded within ~2 days.
The weeks that followed? That was the human part — code review, feedback from the team, fixes, and merging. The AI was literally working while I was sleeping.
Results
| Metric | Value |
|---|---|
| Total tickets migrated | ~70 |
| Pull Requests opened | ~30 |
| Batch-generated PRs | ~25 |
| Agent coding time (all batch PRs) | ~2 days |
| Review & merge period | ~3 weeks |
| Code quality (self-assessed) | 8/10 |
| Setup time | 2–3 days |
Conclusion
The agents wrote all the code in 2 days. The humans spent weeks reviewing, refining, and merging it. That's the real takeaway — AI doesn't eliminate the human, it compresses the mechanical work so you can focus on the parts that actually need your brain.
Was I satisfied with the code quality? 8 out of 10. This was an experiment, but the results are real — PRs have been reviewed, approved, and merged into the codebase.
Does it still need a human in the loop? Yes. Every PR goes through review. The AI handles the boilerplate and repetitive structure, but a developer still validates the business logic and edge cases.
Can it get better? Absolutely. With more investment in agent prompts and codebase-specific training, this system can approach near-autonomous migration quality. Each iteration gets more accurate.
My recommendation: start small. Take one ticket. Build one agent. See how it works. Then scale. The tooling is ready — MCP integrations, custom agents, skills, batch processing. The question is not whether AI can help with your migrations. The question is how much time you're willing to invest upfront to make it work.
Try it. Test it. Iterate.
Top comments (0)