How I’m Using Agent Harnesses, TDD, and the Seam Model to Improve Development in Legacy Systems

Over the past few months, I’ve been investing a lot of time building agentic development workflows for real production environments.

Not only prompts.

Actual operational environments around agents.

Things like skills, execution tooling, validation layers, testing flows, memory handling, Git integrations, and constrained execution paths.

One thing became very clear very quickly.

Using agents in legacy or mission critical systems without a proper harness can become dangerous surprisingly fast.

Especially in financial systems.

Even with specification driven development (SDD), detailed tasks, and explicit instructions, I noticed a recurring problem.

The agent would correctly implement the requested functionality, but at the same time introduce large unintended changes across the codebase.

Not because the model was “bad”.

But because the environment still gave it too much freedom.

A small business change could suddenly trigger a massive refactor in tightly coupled parts of the application.

The functionality worked.

But reviewing the pull request became painful.

Risk analysis became harder.

The blast radius became unpredictable.

And in highly sensitive systems, this matters a lot.

The Shift That Changed Everything

To address this, I started combining a few ideas together:

• TDD
• Harness Engineering
• The Seam Model from Michael Feathers
• Constrained execution environments for agents

This changed the workflow completely.

Instead of letting the agent freely reshape large parts of the codebase, I started designing the environment to naturally constrain behavior.

The agent now operates through a harness I built around it.

This harness provides structured skills and controlled capabilities such as:

• Reading specific files
• Analyzing code diffs
• Running tests incrementally
• Validating architectural constraints
• Checking impacted dependencies
• Generating isolated implementations
• Blocking risky operations

One of the biggest improvements came from applying the **Seam Model **mindset.

Michael Feathers famously defined a seam as:

a place where you can alter behavior in your program without editing in that place.”

Instead of modifying deeply coupled code directly, the agent identifies stable seams where behavior can be isolated safely.

Then new functionality gets introduced incrementally behind those seams.

This dramatically reduces unintended side effects.

Practical Example

Imagine a legacy financial reconciliation service.

A new business rule needs to be introduced into the settlement calculation flow.

Without constraints, the agent might attempt to “improve” the architecture while implementing the feature.

Suddenly:

Shared abstractions get rewritten

Core flows get reorganized

Multiple services are refactored together

Dozens of unrelated files change

Technically impressive.

Operationally dangerous.

With the harnessed approach, the flow becomes very different.

The agent:

I

• dentifies stable seams in the codebase
• Creates isolated extension points
• Implements behavior incrementally
• Runs targeted tests after every step
• Validates architectural boundaries
• Restricts modifications outside approved scopes

The final result is much smaller, easier to review, safer to deploy, and significantly more predictable.

The Most Interesting Part

What surprised me most is that the value was not only personal productivity.

The biggest impact came after I shared these agents, skills, and harness environments with the engineering teams I lead.

Now the entire team benefits from the same operational guardrails.

Developers can leverage the toolkit to:

Reduce risky refactors

Improve reviewability

Increase delivery confidence

Work more safely in legacy systems

Move faster without increasing instability

This starts creating organizational leverage, not just individual acceleration.

And honestly, this is where I believe a huge part of software engineering is heading.

The conversation is moving far beyond prompt engineering.

The real challenge is designing reliable operational environments where agents can safely participate in software delivery pipelines.

Especially in systems where reliability matters more than raw speed.

Final Thoughts

I don’t think agents replace engineering discipline.

Actually, I think they amplify the importance of it.

The better the engineering foundations, the more powerful these systems become.

TDD becomes more important.

Architectural boundaries become more important.

Observability becomes more important.

Validation becomes more important.

Harness design becomes more important.

The model is only one part of the system.

The environment around it is what determines whether the outcome is production ready or operational chaos.