Software Factory: Build Factories, Not Features

You are not the engineer who ships the feature. You are the engineer who builds the system of agents and code that ships it for you.

That is the thesis. IndyDevDan calls it the software factory in his talk on agentic engineering. I call it the only strategy that scales.

I built an orchestrator that runs agentic pipelines against this codebase. It picks issues from the backlog, implements them with TDD, simplifies the code, runs quality gates, opens PRs, and merges them. Some pipelines run with a human watching. Some run fully autonomous. The system ships daily without me touching a terminal.

This article is about what that factory looks like and why building one is the highest-leverage move for senior engineers in 2026.

The Feature Mentality

Most developers think in features. The mental model is: there is a task, I write code, I open a PR, I move to the next task. Each cycle starts from scratch. Each cycle produces a single output.

This works when features are rare and complex enough to need full attention. But as AI agents get better at writing code, the bottleneck shifts. You can now produce feature-level output in minutes. The limiting factor is not how fast you can code. It is how fast you can manage the pipeline: defining the spec, reviewing the output, catching regressions, deploying safely.

When you think in features, each cycle is an island. You invest the same overhead every time. The spec writing. The context gathering. The review. The deploy. Each cycle costs the same marginal overhead whether you ship one line or a thousand.

The factory mentality inverts this. You invest the overhead once, in the pipeline itself. Then every feature that runs through it costs almost nothing.

The Dark Factory

Manufacturing has a concept called the dark factory. It is a fully automated production line. Robots build the product. Humans oversee the system. Lights are optional because nobody works there.

Software factories work the same way. You build a pipeline of agents that take a spec and produce near-production-quality output. Humans do not touch every output. They design the pipeline, handle exceptions, and improve the system over time.

I did not set out to build a dark factory. I set out to automate the parts of my workflow I found repetitive. But once the first pipeline worked, the pattern became obvious. Each new pipeline was just a variation of the same stages. The factory built itself.

The ADW Pipeline

The factory runs on a structured pipeline. I call it the ADW, or AI Developer Workflow:

1. Plan -- Take a spec or issue and turn it into a detailed implementation plan. Define acceptance criteria. Identify risks.
2. Scout -- Search the codebase for relevant context. Existing patterns, similar implementations, configuration files, tests.
3. Build -- Implement the plan. Write the code. Run the tests. Iterate until green.
4. Validate -- Run the full validation suite. Type checks, lint, tests, build, security scan.
5. Review -- Code review by another agent. Check for style, edge cases, security issues, consistency with the codebase.
6. Release -- Open a PR, classify risk, and either auto-merge or flag for human review.

Each stage is a separate agent with its own prompt, tools, and context. This sub-agent architecture, where each phase has its own focus, is covered in detail in Claude Sub-Agents. The output of one stage is the input to the next. No human touches the pipeline unless a stage fails or the risk gate flags the PR.

The key design decision is the boundary between stages. Each stage should produce something verifiable before the next can start. The planner produces a plan file. The builder produces passing tests. The validator produces a green CI result. The reviewer produces an approved diff. The release produces a merged PR.

This is not a theory. This is how my orchestrator works today, built on the agent loop system I described in How I Build Software With Agent Loops. The pipeline runs on a schedule. It picks the next AFK issue from the backlog. It implements, validates, and ships. I get a notification when the PR lands. Sometimes I read the diff days later.

The One-Prompt Ceiling

A single prompt produces a single result. No matter how good the prompt is, the output is bounded by what one conversation can hold.

A factory produces consistent, reproducible results. Each run follows the same pipeline. Each output meets the same quality bar. The first run costs more because you build the pipeline. The hundredth run costs the same as the first, but the output quality is higher because the pipeline has improved.

This is the compounding effect that matters. One investment in the factory pays dividends on every feature it produces. The return on that investment grows with each pipeline run. It does not degrade.

The one-prompt ceiling is where most teams get stuck. They write better prompts instead of building better pipelines. A better prompt improves one output. A better pipeline improves every output that runs through it.

Building Your First Factory

Start with one pipeline. Pick a repetitive task you do regularly. Bug fixes. Dependency updates. Documentation. Template the pipeline for that task.

My first pipeline was for adding new pages to this site. The pattern was always the same: create a route file, write the component, add tests, export it. I built a single agent pipeline that automated that flow. It took a few hours to build. It saved me hours on every page I added since.

The template is the critical piece. Each pipeline needs a template that defines the stages, the tools available to each stage, the quality gates, and the output format. Once you have a template, you can create new pipelines by configuring the template for a different task.

What Makes a Good Factory

A good software factory has four properties:

Clear stage boundaries. Each stage has a single responsibility and a defined output. The builder builds. The reviewer reviews. The validator validates. No stage should do the next stage's job.

Idempotent steps. Running the same pipeline twice on the same input should produce the same result. If the builder creates a file and the file already exists, it should update it, not duplicate it.

Quality gates at each stage. Each gate is code, not a prompt instruction. The validator runs actual tests. The reviewer checks actual diffs. A prompt says "check the tests pass." A gate runs the test suite and blocks if it fails.

Feedback loops. Every pipeline run produces data. What failed? What was slow? What did the human review catch? That data feeds back into the pipeline design. The next run is better because the last run happened.

The last one is the most important. A factory that does not learn from its outputs is just automation. A factory that learns becomes a platform.

What Happens to the Engineer

When the factory ships features, the engineer's job changes.

You are no longer measured by how many features you ship. You are measured by how fast the factory ships features and how rarely it needs a human to intervene. Your output is the pipeline, not the feature.

This is uncomfortable for engineers who take pride in their craft. Writing code is tangible. Building a pipeline is abstract. The reward shifts from "I built this feature" to "the factory built this feature and I never touched it."

But the leverage is real. One week building a factory can automate months of feature work. The engineer who builds the factory compounds their output. The engineer who ships features one at a time does not. This is the divergence I explored in What Happens to Developers Who Don't Adapt to AI.

IndyDevDan put it well: the gap between the top engineers and everyone else is widening every week. The top engineers are compounding their advantage on the one opportunity that matters. Building the factory.

You Already Have the Raw Materials

If you are reading this and thinking "I am not building an agentic pipeline," look at what you already have. CI scripts. Deployment pipelines. Code review checklists. Issue templates. These are factory components. You already have stages, gates, and outputs. The step that is missing is connecting them into a pipeline that runs without you.

Start with CI. If your CI pipeline catches regressions automatically, you already have a validation gate. Add a builder that creates the PR before CI runs. Add a planner that writes the spec before the builder starts. Connect the stages and you have a factory.

The factory does not need to be complex. My first one was a shell script and a prompt file. It grew from there.

Conclusion

The software factory is the natural evolution of everything we have learned about automation. CI automated the build. CD automated the deploy. The factory automates the development.

The question is not whether you should build one. The question is which pipeline you will build first.