Getting to the Software Factory: Moving Up the EPD Hierarchy in the Agentic Age

If you're the CEO of a SaaS company, you've heard the pitch a hundred times. Adopt AI tools, ship faster, win. Your board wants it. Your customers want it. You probably have engineers using Claude or Codex already. Maybe throughput went up 35% or 40%.

‍

So why does it feel like the companies pulling away are playing a different sport?

‍

We spent the last six months working hands-on with software companies on their engineering, product, and design transformations. The finding is uncomfortable and consistent: the gap between the companies stuck at 35% and the ones at 5–10x comes down to how they reorganized. Not which tools they picked.

‍

There's a second-order effect that makes this urgent. The companies that transform their EPD organizations are also the ones shipping AI products to their customers fastest. Agentic engineering and agentic products share the same architectural underpinnings: context infrastructure, deterministic orchestration, governance models. A company that builds a software factory for internal development is already halfway to offering AI-native capabilities to its customers. The engineering transformation is part of the product strategy.

‍

This essay introduces four levels of transformation. They're not strictly sequential. A team can operate at multiple levels at once, and different parts of the org often sit at different levels. But later patterns generally depend on the foundations earlier ones create. Most companies are practicing Level 1 or 2: adopting tools, getting faster. A few have invested in Level 3: reshaping the codebase and its workflows so agents are first-class consumers of both. Level 4, the software factory, is where the system orchestrates itself, humans move from in the loop to on the loop, agents run cloud-hosted and generate their own work, and customers themselves become participants in the SDLC, filing structured feedback that the factory turns into shipped code. Very few companies have reached it. Several are not far off.

‍

We wrote this piece because we keep seeing the same failure mode. A SaaS CEO announces, "We're going all-in on AI." The team adopts tools. Throughput goes up a third. Everyone declares victory. Then a Native AI competitor with half the engineering headcount ships three products in the time it takes to ship one. Or worse, a foundation model company itself ships the feature in three days.

‍

The Four Levels

Level 1: Thinking Agentically

This is the most accessible level and the most underestimated. It costs very little. It requires no infrastructure changes. And it creates the demand-pull for everything above.

‍

The primary shift: engineers stop writing code and start directing agents that write code. The core skill becomes decomposition, breaking a problem into atomic tasks that are independently executable, testable in isolation, and reviewable in under 20 minutes.

‍

The companies that start here see something different. Engineers who learn to think agentically become the demand signal for infrastructure investment. They feel the walls, and they can articulate what's missing. They're the ones who say "I need isolated environments" and "I need the agent to understand our architecture" before anyone builds those capabilities.

‍

A few red-pilled ICs at a company will not, by themselves, raise that company. But they are the scouts. The right move is to listen to what they're asking for and invest in making their practices replicable across the team. Velocity gains need to be spread across the floor, not concentrated in outliers. This is especially important since demand for AI-native engineers far exceeds their supply.

‍

Level 2: Agent-Ready SDLC

This is the platform infrastructure layer. It's where most organizations should be investing right now, and where many are stuck. At its core, agentic engineering has to cover the full SDLC: code review, testing, and verification, not just code generation. And that full loop has a physical requirement: somewhere for agents to actually run it. A company can be cloud-native in production and still fail here, because running your product in the cloud and developing your software in the cloud are different things.

‍

Many companies still develop the old way: one hand-configured environment per engineer, half a day to set up, everyone pointed at the same shared backend database. That worked when one engineer meant one workspace. An engineer dispatching ten agents needs ten isolated workspaces, created in seconds and discarded when the work merges. We've seen the failure mode in practice: a company running parallel coding agents that kept corrupting each other's work because every agent was reading and writing the same shared state.

‍

The diagnostic at Level 2, at its core, is very simple. Can you spawn a fresh, fully isolated environment, clone the repo, and run the entire test suite with no human help? If that fails, you're not at Level 2, regardless of what your infrastructure looks like on paper. The fundamental unlock here is parallelism to scale beyond productivity unlocks on an individual developer’s machine, and all the investments here are in service of it.

‍

Level 3: First-Class Context Layer

An organization that passes Level 2 has reproducible cloud environments where agents can work; what it doesn't have is agents that know how your product works. Ten isolated workspaces are ten superintelligent strangers in your codebase. The gap is an effective harness: everything wrapped around the model that turns it into a worker, the context it reads, the skills it can invoke, the checks it must pass, and the loop that dispatches and collects work.

‍

Context is arguably the most important part of the harness to get right. Without it, agents are fast and wrong: code that compiles but fights the architecture. First-class context means a freshly spawned agent can orient itself before the first prompt: the command that runs the project, the tests that define correct, the conventions that govern the code.

‍

The organizing principle is to treat agents as first-class citizens of your repo: everything a new engineer would need to succeed, an agent should be able to find and trust. Most teams start their context layer with markdown. Agents like markdown, and it's the right container for instructions: conventions, standards, how work gets done here. It fails as a system of record, though. Nothing checks it, and nobody owns it, so state and progress drift into an unmaintained docs directory that agents write and no human reads. Take the API doc every company has: a file describing the endpoints, written by hand and wrong within six weeks. A structured format like YAML or JSON helps, because a machine can validate it and query it, but the real fix is changing who writes it: generate the spec from the code on every merge, and the doc can't disagree with the API because the same commit that changes one produces the other.

‍

The teams further along have moved past flat files entirely, mapping services, data models, and business rules into graphs agents traverse rather than keyword-search. That's the pattern across all of it: every step up, from prose to structured files to generated specs to queryable graphs, is another upgrade in the agent's citizenship. Each one hands over context an agent can use without a human vouching for it, and that's the whole game, because unsupervised trust is exactly what Level 4 relies on.

‍

Level 4: Software Factory

The difference between Level 3 and Level 4 is the control model. Through Level 3, humans are in the loop: directing each task, reviewing each PR, deciding what happens next. At Level 4, humans move to on the loop: they set direction, define constraints, and review results, while the system plans, executes, and verifies on its own. A human writes a ticket and agents decompose it, write the code, run the tests, and present the change for approval. Or production telemetry surfaces a regression, and agents fix it before anyone files a ticket.

‍

In practice, the factory is a set of background coding agents running in the cloud, and, importantly, that means anyone at the company can invoke it. A CEO we talked to describes it simply: "One of our customers was having a problem. I tagged our internal coding agent on the feedback in Slack. Fifteen minutes later, we had a PR with a fix."

‍

Two of the clearest examples of software factories are Stripe and Ramp. Stripe's Minions ship 1k+ agent-written pull requests a week: a Slack message spawns an isolated environment, the agent reads the docs, writes the code, runs the checks, opens the PR. Ramp's Inspect system grew from 30% of merged PRs toward 50% within months, and the system now mostly writes itself. Worth noticing, though: both companies still route changes through human review. They've built the factory, but they're still working through the trust model. The mechanism for that decision is a tiered trust model. Low-stakes changes ship without review. Mid-stakes changes get a human look. Core systems always require human approval. Companies that haven't mapped which parts of the codebase they trust agents with default to one of two traps: over-blocking, where the factory idles behind reviews nobody needed, or under-blocking, where it ships something it shouldn't have.

‍

It's no coincidence here that the companies furthest along have built a lot of their coding harnesses in-house. But building doesn't mean rebuilding everything, and it costs less than most teams assume. As Rishit Shah, Tidemark senior engineering advisor who led a major AI transformation at Podium (read more here), puts it: "There's no point rebuilding GitHub or Datadog. Buy durable infrastructure. Build or extend the agent-native workflow layer, where control and feedback loops create leverage." Off-the-shelf harnesses and orchestration tools will keep improving, and buying them is a great start. However, there’s an underlying shift to keep in mind: software development used to be a cost center, but in the agentic age, it's a source of differentiation. How fast the factory learns is how fast the company learns, and that's why the companies furthest along carry a bias to build at this layer.

‍

A built-out software factory is a system that starts to compound without scaling the humans who maintain it. Agents detect regressions and heal them. Telemetry triggers improvements nobody scheduled. And run the factory long enough and it stops waiting for instructions entirely: structured bug reports route straight to it, support conversations get tagged into agent queues, and in the most advanced cases customers build their own agents inside the product. The factory generates its own work from customer reality, and the gap between what customers need and what gets built, the gap the entire roadmap process existed to manage, starts to compress on its own.

‍

What Changes in the Organization

The transformation described above doesn't stay inside engineering, which is why we call it an EPD transformation and not just an engineering one. When producing code stops being the bottleneck, the pressure moves downstream: to product and design first, then out to the customer-facing functions. Some consistent themes we've seen:

‍

Role Boundaries Are Dissolving 

The best teams have designers committing code, PMs building prototypes, and engineers making design decisions. The boundaries blur but the ownership doesn't. Someone still owns the design system, someone still owns the roadmap, someone still owns what ships to production. What's changed is that owning something no longer means being the only one who can touch it.

‍

Some companies are going further and rethinking what the org chart exists to do in the first place. Block's "From Hierarchy to Intelligence" essay, by Jack Dorsey and Roelof Botha, makes the most aggressive version of the argument: hierarchy is an information routing protocol built around the limitation that a leader can manage three to eight people, and AI can now perform that coordination function. Block is normalizing down to three roles: ICs who build, DRIs who own cross-cutting problems for fixed periods, and player-coaches who combine building with developing people. No permanent middle management. A continuously updated "world model" of company operations replaces the information that used to flow through layers of management.

‍

You don't need to adopt Block's model. But the question it raises applies to every company in this essay: how much of your middle management's time is spent routing information that a self-describing system (Level 3) already answers?

‍

Measure the Right Things for the Right Level

Most companies measure Level 1 metrics and wonder why their Level 3 investments aren't showing results.

‍

At Level 1, you're measuring adoption and individual speed. Lines of code, PRs merged per engineer, token usage, AI tool adoption rate. These tell you whether engineers are using the tools and getting faster. They don't tell you whether the organization is ready for what comes next.

‍

At Level 2, the question shifts to infrastructure readiness. DORA metrics matter here: deployment frequency, lead time for changes, change failure rate, time to recovery. Add environment spin-up time and test suite reliability.

‍

At Level 3, you're measuring agent autonomy within context. Agent-initiated PRs as a percentage of total. Agent eval pass rates. The size and usage of your internal skill library. How many systems feed context to your agents. The question is no longer "are engineers faster?" but "can agents operate independently given the right context?"

‍

At Level 4, the metrics flip to system performance and business outcomes. One-shot PR rate: what percentage of agent-generated PRs pass review without human rework. Self-healing rate: issues detected and resolved without human initiation. Time from customer signal to shipped fix: how fast the factory turns a bug report or support conversation into merged code. Agent escalation rate: how often the factory hands work back to a human because it can't proceed. And ultimately, the ratio of features shipped or ARR to R&D headcount.

‍

Moving Bottlenecks

As build costs collapse, the constraint shifts from engineering capacity to organizational judgment. When three engineers can build in nine weeks what used to take a team of 12 a quarter, the bottleneck is no longer "can we build this?" It's "should we ship this?" Product differentiation, market fit, GTM readiness, production risk: these are the gates that matter when the factory is running.

‍

Adding engineering capacity is getting easier. Developing the product thinking to decide what's worth building, and the organizational muscle to sell, support, and operate what you ship, is becoming the scarce resource.

‍

CEO Ownership Is the Forcing Function

Every company we've seen climb the hierarchy has a CEO who took personal ownership. One CEO told the entire company its current product wouldn't be relevant in three to five years. That statement drove adoption, not the tooling budget that followed. Another took back product leadership, accepted engineer churn, and moved to daily planning. That company is now operating close to Level 4 and generates millions in AI agent revenue.

‍

This hierarchy is a diagnostic. It tells you where you are, but moving up requires a decision it can't make for you. If you're a CEO trying to move up this hierarchy, Tidemark partners with portfolio companies in three ways: bootcamps and events to learn from peers in real time, an SDLC maturity assessment that pinpoints your two to three highest-leverage interventions, and senior technical advisors plus embedded Forward Deployed engineering to help action your roadmap.