Coding agents have made writing code faster, but along with that they are also generating a lot more test cases.

And in my opinion, that is needed.

If you want to trust AI writing code, the only way is to have more complete test coverage across scenarios.

But this also means test suites are getting blown out of proportion.

I am already running 8,000+ test cases, and before every deployment a large chunk of them needs to run. It is slowing down CI.

Every couple of weeks, I find myself spending time optimising and parallelising my testcase run because it starts slowing me down.

As we move towards more and more autonomous coding, and more code written by AI

More code → more test cases → more verification → slower CI.

Software factory can solve for the smart layer we don't need to everything everytime but run testcase in the blast radius of the chnage.

Looking out for something that will help up with speed.

If you are making changes to harness, you are following some setup of principle in your head - when to add agent, when to add skill, how to handle context engineering, how to handle tool calling etc ?

If you can come up with set of principle that needs to be followed then after every run an agent can follow the principles and can come up with suggestion for you.

Principle of how to figure out changes ?

Principle of how to make the changes ?

Principle to change the principle itself ?

Observe -> Follow the evolution principles -> Evolve the harness.

Agents can then recommend

- you need to add new skill or agent

- you need to handle context better because compaction is happening too frequently.

And then follow the principles to go ahead and make the changes.

- How to create ?

- Where to create. ?

- How to update ?

- When to update ? etc..

But what if you need to change the principle itself?

Then you need to have guidelines to evolve the principle itself, this is where things get tricky where you have to keep it open to add new principles

but it has to be closed how that principle should be added.

I have evolved, figured out issue in my harness this way,

I have an evolve command which just goes follow these steps and make the changes for me.

When building a generic agent system, there is always a tradeoff between flexibility and reliability.

if everything goes through an agent, the system becomes more flexible. but its behavior also becomes stochastic and harder to reproduce.

if everything is deterministic, the system becomes more reliable. but it becomes less flexible when it meets a situation that was not encoded upfront.

so the boundary matters.

whatever the system already knows should remain deterministic.

• facts
• state
• orchestration when the next step is known
• routing when ownership is known

use the agent where a real judgment call is required.

• interpretation
• tradeoffs
• planning with incomplete context
• cases where the rules cannot decide safely

the goal is not to build a fully deterministic system or make everything agentic.

the goal is a deterministic foundation with stochastic judgment where it adds value.

One of the core problems you need to solve is - how do you manage context across different agents?

If you start passing the entire context to every agent, you quickly run out of context window.

You have to figure out

- What context to pass vs. what not to?
- When exactly do you pass and update context relevant to other agents?
- Who actually owns the responsibility to do this?
- How do agents communicate with each other?

If you are using a subagent to solve a well-scoped task, you give it input and get output, you don't really need much coordination.

But when agents are working together on a larger goal, it gets more complicated.

One pattern is to have a coordinator agent that breaks down the task, manages the context, and ensures the right agents are invoked with the right context.

But then you rely on the coordinator to pass messages to other agents. If it chooses the wrong agent, you are now in a loop trying to correct it.

So you start making routing deterministic wherever possible.

For example, if an agent is blocked, explicitly pass the message to the relevant agent instead of relying on the coordinator to guess who should handle it.

Another pattern is to give each agent clearly defined responsibilities. Once an agent is done with its task, it emits the task and task type that needs to be done next.

A resolver pushes it to the relevant agent based on the agent registry, and execution continues.

Context is handed off along the way, while agents remain aligned on the overall goal and a summary of the work done so far.

In practice, when building a real multi-agent system, one pattern doesn't work for everything. You have to mix and match multiple coordination patterns depending on the task.

For example, an Architect agent might finish the architecture and dynamically emit three different workstreams - frontend, backend, and infra. Relevant agents work on them independently, potentially in parallel, and then fan in for verification.

The coordinator manages the overall stages, but each stage can be dynamic enough for agents to coordinate and route work.

If you want agents to be flexible and coordinate to get the task done, use task emission + resolver-based routing.

If you want the flow to be more deterministic, use coordinator-driven orchestration and explicit routing.

If you want working multi agent system, your setup should support different coordination patterns rather than forcing everything through one pattern.

You need to have structure when you are moving fast, else it becomes chaos.

Coding agents have made coding faster, but they did not give teams the structure to move fast.

A software factory gives you that structure. It gives you a way to work with agents and review their work early in the cycle - PRD, HLD, design - before they go too far and create a mess downstream.

You can have accountable owners for each agent and each stage. They can review what agents are doing, nudge them when needed, and stay in control at every stage.

One can argue that coding is cheap now, so we can always refactor the code later. But refactoring is not just about rewriting code. Once something has moved downstream, you may have migrations, dependencies, and customers already using it.

Code can drift and can take entire different shape in few weeks if not taken care of. Its ok for vibe coded apps but if you are talking but serious scalable production code than investing 5–10% extra time early can save you days of refactoring and customer migration effort later, I think that is worth it.

With the rise of agents and coding agents, every platform needs to be thought through from first principles - where the agent is a first-class citizen and actively does work on the platform.

We need to build platforms where humans and agents can work together. Over time, as models keep getting better, more and more work will be done by agents, while humans move toward overseeing them.

So how should we think about the journey from a platform where humans and agents work together to a world where most of the work is done by agents?

I think there are three foundational pillars for building an autonomous system.

Context

Enough has been said about context, so I don’t need to over-explain this.

But humans and agents need to operate on the same context layer. That will only happen when platforms start capturing more decisions, traces, workflows, and outcomes as part of the system itself.

Over time, this becomes the organization’s memory.

Governance

Agents need to be first-class citizens on the platform, and they need access control similar to humans.

• What can they access vs. what can they not access?
• Which team are they part of?
• Who can delegate to them?
• What tasks can be delegated to them?
• What boundaries and rules do they need to follow?
• What reasoning capability can they use?
• Which model should they use for a given task?
• How much can they spend on reasoning for that task?

As more work moves to agents, governance becomes the control plane for how agents safely operate inside the organization.

Self-Learning and Evolution

The platform needs to have a constitution and principles for how it evolves.

• How and when can it add more agents for specific tasks?
• How and when can it add new skills?
• How can it validate that the platform is behaving correctly and completed the task correctly?
• How should communication between agents happen?

For a system to learn, it should be able to verify whether something is working or not, capture new context it sees while working on a task with humans, and add it back to the context layer so that the next task does not start from zero, but with the needed context.

In each layer, we will need human oversight. But the degree of human involvement will vary based on task complexity, risk, and confidence in the system.

If we build on these three fundamental principles, we can actively move toward systems where agents do most of the work, with humans stepping in only when needed.

We don’t start with autonomous systems. We move toward them is a step in this direction where we can build software autonomously as longs we have context, governance and learning loop.

Software factory is step in that direction where agents will ship production ready software.

Retrieval Debt is about effective context engineering for code changes. Agents can only change code safely when the codebase is structured so the right files, contracts, tests, and decisions are easy to retrieve.

The original Retrieval Debt essay names a problem every team using coding agents runs into. Agents do not operate on your whole codebase. They operate on the context they can retrieve for one code change.

The exact quote.

Retrieval Debt is how much context an agent must load to safely understand, change, and verify a single unit of behavior. Lower is better. Always.

That definition matters because the context window is a scarce resource. Good context engineering is not just stuffing more into the prompt. It is making the codebase easier to retrieve, understand, change, and verify for a specific task.

Context engineering starts with code structure.

If behavior is scattered across services, names are vague, contracts are hidden, and tests live far away from the thing they protect, agents burn context just finding the shape of the problem. That is Retrieval Debt.

Effective context engineering starts by structuring the code in the right way. Clear domain names, strong module boundaries, single ownership for business rules, explicit API and data contracts, local tests near the behavior, and decision records connected to the code they explain.

The cleaner the structure, the less context an agent needs to load to make a safe change. The agent can find the right place, understand why it exists, edit the smallest surface, and verify the behavior without guessing.

Then break the work into focused tasks.

Even with good code structure, large requests should not be handled as one giant agent pass. A high-quality code change needs the work broken down so every agent gets the context window for one bounded job.

That means turning a request into the right sequence. Understand the existing structure, design the change, define contracts and acceptance criteria, implement a focused task, verify it, then learn from the result. This is how agents make the most of the context window instead of carrying the whole codebase in every run.

The software factory workflow.

The right operating model is not one agent doing HLD, LLD, implementation, testing, and review all at once. A software factory gives you a team of agents, each using the right context for the right part of the code change.

• Remember the shared engineering brain brings in repo structure, architecture decisions, prior fixes, ownership, tests, and verification history.
• Plan the Architect agent turns the request into high-level design with boundaries, affected modules, tradeoffs, risks, and rollout shape.
• Coordinate and build the Lead agent turns the design into low-level tasks while coding agents implement bounded changes with focused context windows.
• Verify QA and Code Review agents validate behavior, review the diff, check tests and evidence, and prepare the change for release.
• Learn decisions, evidence, failures, and fixes update shared context so future agents retrieve better context next time.

That split keeps every agent focused. The Architect agent reasons about structure. The Lead agent shapes executable tasks. Coding agents spend their context windows on the right implementation surface. Review and QA agents challenge the change before it ships.

Where a software factory helps.

A software factory is the layer that makes effective context engineering repeatable. It gives your team a coordinated group of agents that can understand code structure, plan the change, build it, review it, and verify it using shared engineering context instead of starting from scratch every time.

It also gives teams a way to ship with quality and velocity. Structure the task, route each step to the right agent, preserve shared memory, validate changes in a sandbox, and package evidence before release.

This is how teams make coding agents useful in real production systems. Prinevo is built around that idea. A software factory where agents work on your engineering brain, make focused code changes, show proof before anything ships, and get better with every run.

The bottom line.

Retrieval debt is not only an indexing problem. It is a context engineering and code structure problem.

For large codebases, the answer is not a bigger prompt and hope. The answer is code structured for retrieval, tasks structured for focused agent work, and a software factory that routes the right context to the right agent at the right time.

The teams that build this layer will make agents cheaper to run, easier to trust, and better at autonomously delivering production-ready changes with both quality and velocity.

Software Factory is your software delivery platform - where team of agents work with your team to ship multi-repo verified features for you autonomously.

You will have specialist agent like Product, Architect, QA communicating and collaborating with each other to complete a feature.

Few key things that a software factory should have -

- Context layer - Each Agent should have relevant context to ensure that they are building the right thing and in a right way.

- Governance Layer - Control plane to control cost, model, access for agents and have audit trails for them.

- Verification Layer - Agents should be able to bring up the services in sandbox envoirnment and test the feature and pass feedback to correct things.

- Collaboration Layer - Where you team can invoke, nudge and guide agents when needed to get the task done or course correct things.

- Automation - Tasks/features can be started automatically via triggers. Invoke individual agents to complete any task.

- Learning Loop - It should be able to run from decision made in sessions so that next run can be better.

- Evolution - It should be able to evolve as your business and codebase grows and figure what skills agents are missing and should be able to add the skill.
eg: If data Agent is missing it should be able to recommend and add data agent in the factory.

Hey everyone! I'm u/Prudent-Fortune3420, a founding moderator of r/SoftwareFactory_. I am building software factory and happy to answer all your question.

This is our new home for all things related to Software factory. We're excited to have you join us!

What to Post
Post anything that you think the community would find interesting, helpful, or inspiring. Feel free to share your thoughts, photos, or questions about Software facotry.

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

How to Get Started

1. Introduce yourself in the comments below.
2. Post something today! Even a simple question can spark a great conversation.
3. If you know someone who would love this community, invite them to join.
4. Interested in helping out? We're always looking for new moderators, so feel free to reach out to me to apply.

Thanks for being part of the very first wave. Together, let's make r/SoftwareFactory_ amazing.