An Engineering Org of One: Software Engineering in 2026 and Beyond

The minimum viable team for shipping production software used to be 5-10 people. A product manager to scope it. A designer to shape it. Backend and frontend engineers to build it. QA to verify it. DevOps to deploy it. Each role was a concentration of knowledge that took years to develop and couldn't be shared.

That number is collapsing to one.

Not because the work disappeared. Every function listed above still needs to happen: scoping, design, implementation, testing, deployment, monitoring. What changed is that each of those functions can now be encoded, automated, and orchestrated by a single person operating what I'm calling a software factory.

Over the past several months, I've been building each of these capabilities individually: context engineering for thinking, specs for intent, agentic workflows for execution, skills for encoded expertise, and evals for quality gates. Each one solved a specific problem. This post connects them: the argument that these pieces form a coherent system, and that the system changes what's possible for a single person.

The software factory has seven layers. The bottom five (intelligence stack) handle thinking, specification, execution, expertise, and quality. The top two (infrastructure stack) handle delivery and monitoring.

In this post:

What is a software factory: the seven layers and how they connect
The SDLC evolution: from traditional to agentic to factory
The seven layers in detail: what each layer does and where it was introduced
What makes the factory different from agentic engineering: the key distinction
Pre-requisites: assembling the factory: the order that matters
What most orgs will get wrong: forward-looking failure modes
Where this is heading: the trajectory

What is a software factory

A software factory is a personal infrastructure stack that lets one person do what used to require a full EPD team. It's not a product or a framework. It's a set of layers, each handling a function that used to require a specialist, orchestrated through a single interface.

The seven layers:

Layer	Function	What it replaces
Context engineering	Teaches the AI your world: constraints, scale, domain, conventions	Senior engineer's institutional knowledge
Specs	Encodes intent with enough precision for agents to execute	PM's scope docs + architect's design docs
Agents	Execute implementation from specs, iterate against tests	Engineering team writing code
Skills	Encode repeatable expertise as slash commands	Specialists (QA, design review, security audit)
Evals	Measure and gate quality systematically	QA team + manual code review
CI/CD	Automate build, test, and deployment pipelines	DevOps/platform engineering
Observability	Monitor production, detect regressions, trigger self-healing	SRE/operations team

The first five layers are the intelligence stack: they handle thinking, specification, execution, expertise, and quality. The last two are the infrastructure stack: they handle delivery and monitoring. Together, they form a closed loop where a single person defines what to build, and the factory handles everything from spec decomposition through deployment.

This isn't hypothetical. Every layer exists today. I've built and used each one individually. The question I'm working through now is whether they compose into a coherent system where the whole is greater than the parts.

The SDLC evolution

The software development lifecycle has gone through two major shifts. The third one is happening now.

Dimension	Traditional	Agentic	Software Factory
Input	Ticket or user story	Spec with verification criteria	Product goal with constraints
Who writes code	Engineer	Agent, from the spec	Agent team, from decomposed specs
Quality gate	Peer review + manual QA	Tests loop the agent, human reviews approach	Evals gate autonomously, human samples outcomes
Cycle time	Days to weeks	Hours	Continuous
Team size	5–10 people	1–2 people	1 person + factory
Bottleneck	Implementation speed	Spec quality	Product judgment
Knowledge capture	Wiki pages, onboarding docs	CLAUDE.md, updated manually	Skills, evals, specs: encoded and compounding
Failure recovery	Debug, hotfix, post-mortem	Human redirects agent	System detects, triages, routes to agents

Three stages of the SDLC. Each stage shifts the bottleneck upward: from writing code, to writing specs, to making product decisions.

Stage 1: traditional (pre-2024). PM writes a ticket. Engineer designs the approach. Engineer writes the code. Engineer writes the tests. PR review by a peer. QA runs manual verification. DevOps deploys. The cycle takes days to weeks per feature, involves 4-6 people, and the bottleneck is implementation speed.

Stage 2: agentic (2024-2025). Engineer writes a spec instead of code. An agent implements from the spec. A verification gate (tests, lint, type checking) loops the agent until quality passes. A human reviews the approach, not line-by-line code. Deployment stays manual or semi-automated. The cycle compresses to hours, involves 1-2 people, and the bottleneck shifts to spec quality. I covered this workflow in detail in Agentic Engineering with Claude Code.

Stage 3: software factory (2026+). One person defines the product: what to build and why. The factory decomposes the spec into tasks, assigns agents, runs verification gates, deploys to production, monitors for regressions, and triggers fixes autonomously. The human sets direction, reviews outcomes (not individual diffs), and encodes learnings back into the factory. The cycle is continuous, not sprint-based. The bottleneck is product judgment.

The key difference between stage 2 and stage 3: in agentic engineering, the human is in the inner loop (review every diff, approve every merge). In the software factory, the human exits the inner loop. The factory runs autonomously. The human operates at the level of goals and guardrails, not tasks and PRs.

The seven layers in detail

Each layer was introduced in a prior post. Here's how they connect into the factory.

Layer 1: context engineering

This is the foundation. Before the factory can do anything useful, it needs to understand your world: your domain, your constraints, your scale, your conventions. Context engineering is the practice of structuring that understanding.

In practice, this means CLAUDE.md files that teach agents your architecture, coding conventions, and known pitfalls. It means briefing formulas that include role, business context, scale, and constraints. It means living documentation that accumulates institutional knowledge over time.

Without this layer: agents produce generic output that requires heavy human correction. With it, agents produce output calibrated to your specific context.

Covered in: Context Engineering > Prompt Engineering

Layer 2: specs

The spec is the contract between human intent and machine execution. It encodes not just what to build, but the constraints, edge cases, verification criteria, and exclusions that prevent the agent from making assumptions.

A factory without specs is just fast, undirected code generation. The spec is what makes the output intentional.

Without this layer: agents build plausible-looking features that miss edge cases, violate constraints, or solve the wrong problem. With it, agents build what you actually intended.

Covered in: Spec-Driven Engineering

Layer 3: agents

Agents are the execution engine. They read specs, write code, run tests, iterate on failures, and produce diffs. In a factory, agents operate as coordinated teams: backend agents, frontend agents, test agents, each scoped to a directory and working in parallel.

Without this layer: you're writing all the code yourself. The factory has no hands.

Covered in: Agentic Engineering with Claude Code

Layer 4: skills

Skills encode the expertise of specialists as reusable slash commands. /verify-sprint runs a pre-merge checklist. /audit-ui checks accessibility and design system compliance. /review-architecture applies a staff engineer's review criteria. Skills are what allow one person to operate across functions that traditionally required different specialists.

Without this layer: you either skip specialist functions (no accessibility audit, no architecture review) or do them manually. The factory is fast but shallow.

Covered in: Skills Are the New Org Chart

Layer 5: evals

Evals are the quality gate that makes autonomy safe. They measure agent output against criteria you define: accuracy, format compliance, behavioral correctness. Without evals, you can't trust the factory to run without constant oversight. With them, you can let agents iterate autonomously and review only the outcomes.

Without this layer: every agent output requires human review. The factory can't run unattended.

Covered in: Evals for AI Agents and Evals in Practice

Layer 6: CI/CD

The delivery pipeline automates build, test, and deployment. This layer isn't new, but its role in the factory is different. In traditional development, CI/CD runs after a human merges. In the factory, CI/CD is part of the autonomous loop: agents trigger builds, evals gate deployments, and failures loop back to agents for remediation.

Layer 7: observability

Production monitoring, error tracking, performance measurement, and alerting. In the factory, observability closes the loop: production regressions are detected automatically, triaged by the system, and routed back to agents for investigation. The factory is always running, always watching, always improving.

What makes the factory different from agentic engineering

This is the distinction that matters, and it took me a while to see it. When I wrote about agentic engineering, I was describing a workflow improvement: agents write code, humans review it. The software factory is a different thing entirely. It's an operating model where the system runs autonomously and the human operates at a higher level.

	Agentic engineering	Software factory
Human role	Review every diff, approve every merge	Set direction, review outcomes, encode learnings
Scope of autonomy	Single feature implementation	End-to-end: spec to production to monitoring
Cycle time	Hours per feature	Continuous
Quality gate	Human review	Evals + automated verification + human sampling
Knowledge capture	CLAUDE.md updated manually	Factory encodes learnings automatically
Failure recovery	Human diagnoses and redirects	System detects, triages, and routes to agents

The metaphor I find useful: agentic engineering is having a skilled assistant. The software factory is having an entire team that works while you sleep. You set the agenda in the morning, review results in the evening, and encode what you learned so tomorrow's run is better.

Pre-requisites: assembling the factory

You can't build the factory all at once. The layers have dependencies, and the order matters. This mirrors the adoption sequence from Making Engineering AI Native, but extended to the full stack.

Phase 1: context (weeks 1-2). Start with CLAUDE.md. Every time the agent makes a mistake, encode the correction. Within two weeks, you have a document that calibrates agent output to your codebase.

Phase 2: specs (weeks 3-4). Write specs instead of tickets. Start with one feature. The spec should include problem statement, constraints, verification criteria, and exclusions. The quality of your specs determines the quality of everything downstream.

Phase 3: agents (month 2). Configure sub-agents for different domains (backend, frontend, tests). Run your first parallel implementation. The time savings sell themselves.

Phase 4: skills (month 2-3). Encode your top 5 repetitive tasks as skills. Start with verification checklists and scaffolding patterns. Each skill you create is one less function that requires your manual attention.

Phase 5: evals (month 3). Build eval suites for your most critical paths. Start with deterministic scorers (format compliance, test pass rates), then add model-graded scorers for subjective quality. Evals are what let you trust the factory to run unattended.

Phase 6: CI/CD integration (month 3-4). Wire agents into your deployment pipeline. Evals gate deployments. Failures trigger agent remediation loops before alerting you.

Phase 7: observability (month 4+). Close the loop. Production errors are detected, triaged by severity, and routed back to agents for investigation. You review the diagnosis, not the raw error.

The factory loop. The human defines goals. Everything else runs autonomously: decomposition, execution, verification, deployment, monitoring. Learnings feed back into context and evals, making each cycle better.

The entire assembly process takes 3-4 months for a solo practitioner working on a real project. Each phase builds on the previous one. Teams that skip to phase 5 without establishing phases 1-2 get inconsistent results and lose confidence in the approach.

What most orgs will get wrong

This is a forward-looking section, informed by the failure modes I've already hit while building the individual layers. The software factory model is emerging now, and most organizations will stumble in predictable ways.

Treating the factory as a tool purchase. The factory isn't a product you buy. It's an operating model you build. The layers are infrastructure that accumulates over months of encoding knowledge, writing specs, building eval suites, and iterating on failures. Teams that expect to "adopt" the factory by installing a tool will be disappointed.

Skipping the spec layer. This is the most common failure I see in agentic engineering, and it will be worse in the factory context. When agents are fast, the temptation is to skip specs and just prompt. This works for trivial changes but produces chaos at scale. The factory amplifies whatever you feed it. Feed it vague intent, and you get vague output at high velocity.

Building the infrastructure stack before the intelligence stack. Teams with strong DevOps culture will be tempted to start with CI/CD and observability (layers 6-7) because those are familiar. But the infrastructure stack is only useful once the intelligence stack (layers 1-5) is producing reliable output. Automating deployment of unreliable code is worse than deploying manually.

Not encoding failures. The factory's value compounds through learning. Every failure that gets encoded as a rule in CLAUDE.md, a check in an eval suite, or a constraint in a spec makes every future run better. Teams that fix problems without encoding them will hit the same failures repeatedly.

Confusing speed with quality. The factory can produce code at a rate that overwhelms human review capacity. This is the point: you're not supposed to review everything. But the transition from "review every diff" to "review outcomes" requires trust in your evals and verification gates. Teams that skip the eval investment will either over-review (negating the speed gains) or under-review (shipping bugs).

Fear of the single point of failure. "What if the one person gets hit by a bus?" This is a real concern, but the factory actually mitigates it better than traditional teams. When knowledge lives in CLAUDE.md, skills, specs, and eval suites, it survives personnel changes. When knowledge lives in someone's head, it doesn't. The factory is the most documented, transferable form of institutional knowledge that exists.

Where this is heading

Three predictions for the next 2-3 years.

The factory becomes the unit of production, not the team. Today, companies staff projects with teams. Tomorrow, they'll staff projects with factories: one person plus a configured stack. Team size will be determined by product complexity and trust tolerance, not by the functions that need to be covered.

Skills marketplaces emerge. The Skills post described encoding expertise as slash commands within a team. The next step is trading skills across organizations. A security consultancy publishes /pen-test-review. A design agency publishes /brand-audit. Expertise becomes a distributable artifact, not a consulting engagement.

The bar for "engineer" rises. The engineer who thrives in the factory model isn't the one who writes code fastest. They're the one who thinks clearest about what to build, writes the sharpest specs, builds the most comprehensive evals, and encodes the most useful skills. The factory is a force multiplier on clarity of thinking. It produces nothing useful without it.

The org of one isn't a prediction. It's already happening. I'm assembling my own factory now, layer by layer, and every post in this series has been a piece of that process. The question isn't whether this model works. It's whether you assemble the factory deliberately or discover it through trial and error.

This post builds on the entire series: Context Engineering (how to think with AI), Spec-Driven Engineering (how to encode intent), Agentic Engineering (how to execute), Skills (how to encode expertise), and Evals (how to measure quality). For the organizational playbook, see the AI-Native EPD series.