DEV Community

Paramanantham Harrison
Paramanantham Harrison

Posted on AI-assisted

Building a Software Factory Around Coding Agents

Coding agents can write a surprising amount of code.

But getting them to reliably work on a real codebase is a different problem.

The mistake I see is treating the agent as the whole system.

A better approach is to design the system around it.

The 6 layers

I think about a Software Factory as six layers:

1. Boundary

Define where the agent can work.

This includes workspace isolation, permissions and sandbox boundaries.

For example, an ephemeral Git worktree gives an agent its own workspace instead of letting multiple tasks collide in the same working tree.

2. Context

Give the agent the context it actually needs.

Instead of continuously growing a mega-prompt, route relevant repository knowledge, engineering rules and task-specific information to the agent.

3. Skills

Separate reusable engineering workflows from individual prompts.

A skill can describe how a particular type of engineering task should be performed and reused across many tasks.

4. Execution

Give agents a controlled environment for doing the work.

This is where the execution harness becomes important. It can create the workspace, run the agent, execute commands and manage the task lifecycle.

5. Verification

Don't rely on the agent to decide whether its own output is correct.

Use automated checks such as static analysis, tests and holdout tests.

One useful pattern is:

Doer → Tester → Doer

The agent produces the change, an independent verification step checks it, and failures can feed another iteration.

6. Delivery

The final output should fit into the engineering workflow.

For me, that means getting from:

Issue → Agent → Isolated workspace → Verification → Pull Request → Human review

The goal isn't to remove engineers from the process.

It's to move engineers toward the parts where their judgment matters most.

Why this changes how we use coding agents

Once you think in layers, a lot of agent problems become easier to reason about.

Poor results aren't always a model problem.

Sometimes the agent has the wrong context.

Sometimes it has too much access.

Sometimes there is no verification layer.

Sometimes the execution environment is the problem.

And sometimes the missing piece is simply a clear delivery boundary.

That's what I've been exploring with the Software Factory approach.

I'm running a free live series on Maven covering the architecture, execution harness, automated verification and background coding agents.

The first two sessions are already available:

Design a Software Factory for Your Coding Agents
https://maven.com/p/d3588f/design-a-software-factory-for-your-coding-agents

Build Your First Software Factory Execution Harness
https://maven.com/p/aa77d5/build-your-first-software-factory-execution-harness

If you're already using coding agents on real projects, I'd love to hear how you're handling isolation, context and verification.

Top comments (0)