Long-Running Coding Agents: A 6,000-Line Migration

Summary

A large Python-to-TypeScript migration (~6,000 lines) completed with an AI coding agent without losing coherence or introducing regressions across multiple sessions. The core pattern: treat the model as a stateless executor and the human as the high-level planner, and keep the plan in an external progress file the agent re-reads each session.

The problem

Capable coding models still degrade on long-running, multi-session work. Three failure modes recur:

• Lost-in-the-middle — details buried in a long context stop influencing the model’s output.
• Plan/execution drift — each step is locally optimal but slowly diverges from the goal.
• Session volatility — an in-memory plan evaporates when the CLI crashes or the terminal closes.

Why it mattered

A migration of this size spans many sessions. Without external scaffolding, resuming becomes “archaeological reconstruction” — inferring intent from half-finished code — which is exactly where regressions and wasted effort come from.

Constraints

• No behavior changes — a port, not a rewrite.
• Work had to survive crashes and span days/sessions.
• Quality had to be verifiable, not assumed.

Role

I acted as the planner and architect: decomposed the work, owned the target design, and reviewed output. The agent executed steps against the plan. This human-as-planner / agent-as-executor split is the central idea, not an afterthought.

Architecture

An external progress file functions as persistent memory: the current plan, what’s done, what’s next, and constraints that must not be forgotten. Each session begins by re-injecting that file, so the agent re-anchors to the global goal instead of drifting toward local coherence. State lives outside the model, the way a web server keeps sessions in external storage rather than memory.

Key decisions

• Externalize state rather than trust the context window to retain the plan.
• Re-inject the plan every session to counter drift and the lost-in-the-middle effect.
• Keep the human as planner — the model executes decomposed steps; it doesn’t own the design.

Tradeoffs

• Maintaining the progress file is manual overhead — deliberately accepted as the price of coherence across sessions.
• Smaller step sizes mean more iterations but far less rework from drift.

Testing / evaluation

Quality was verified with tests — regressions were guarded by the test suite and step-level review against the progress file, rather than a single end-of-run check.

Outcome

The migration completed without losing clarity or introducing regressions (as described in the companion post). More durably, it produced a repeatable pattern for long-running agent work.

What I learned

The reliability of a long-running agent comes from the surrounding workflow — external state, re-anchoring, and human planning — more than from raw model capability.

What I’d change next

Automate progress-file upkeep (generate/update it from diffs and test results) so the pattern needs less manual bookkeeping.