Agentic Framework Migration

What I built

I designed an agent loop that migrated a decade-old Python/Tornado UI service to Next.js. It self-verified every change, paused only at real blockers, and logged every decision — a repeatable modernization pattern, not a one-off rewrite.

How it works

The loop ports one slice at a time — legacy request handlers become Next.js server-side data-fetching + routes — runs the full test suite on every commit, verifies the new page side-by-side against production, and escalates to a human only when it hits a genuine blocker.

How I built it

Porting mechanics: Tornado handlers → Next.js `getServerSideProps` / catch-all routes, commit by commit, each landing the full Jest suite green (~2,306 tests). To make that safe I fanned out worker agents to raise coverage first — from 26% to 97% — which surfaced four real latent bugs before the port even started.

The loop was built as a reusable blueprint — designed to apply across ~a dozen candidate services, not just this one.

Questions this project answers

How do you use AI in your daily engineering work? On this project AI was the primary way the work got done, not an assistant on the side. I designed an agent loop that ported the codebase one slice at a time, ran the full test suite on every commit, and checked the migrated page against production before moving on. My job shifted to designing the loop, setting the gates, and deciding at the blockers the agent surfaced, which is how one person carried a migration that would normally take a team.

With an agent driving a big refactor, how do you keep it from quietly breaking things? I made the existing test suite trustworthy before touching the framework. Worker agents raised line coverage from 26 to 97 percent first, which surfaced four real latent bugs, and then the thresholds were locked so coverage could not silently regress. During the port the full suite plus lint had to be green after every commit, and behavior-sensitive flows were verified side by side against the live production app, so a change was never called done on the agent's word alone.

What does it take to let an agent operate safely against a live production system? Every consequential decision paused for human approval; the agent executed and the human decided, and each decision was logged with its options, risk, and outcome so the run was auditable. I also held a strict lift-and-shift rule so no behavior changed under cover of the migration, which kept every diff legible as either a faithful port or a real bug. When the port surfaced an already-broken area, the call was to fix forward and document it rather than quietly paper over it.

Was this a real production migration, or a lab exercise? It ran against the real decade-old service that a working team depended on, through timed production test windows and a monitored, staged rollout rather than a single cutover. The point was never just this one app either; the loop was built as a reusable blueprint for the dozen or so similar services behind it.

Results

• ~70,000 lines migrated in ~8% of the estimated engineering time.
• Test coverage taken from 26% → 97% first, then held green (~2,306 tests) across the port.
• A reusable migration blueprint for ~a dozen candidate services.

Post-migration, the team could rapidly iterate on new core features agentically — shipping a redesigned, personalized home page and new planner tools on the modern stack.