Why software factories are not enough

The hot topic of 2026 is software factories: the ability to ship code at unprecedented speed. Almost every organization I know is striving to build theirs, and the numbers back it up.

Cursor’s agent swarm now peaks at around 1,000 commits a second, up from roughly 1,000 commits an hour when it built a web browser earlier this year.

At Uber, more than 70% of pull requests are attributed to local or cloud agents, and weekly agentic requests grew 9.4x between February and August.

Sounds great right? Until the board asks the most important question:

What’s the revenue impact from your software factory?

Atlassian’s State of Teams 2026 surveyed 173 Fortune 1000 executives: 89% say AI increases speed, and only 6% are sure they have clear examples of organization-wide AI ROI.

So, where’s the gap?

Your customers aren’t asking for more software. They need something to solve their problems. And products solve problems, not software.

Pendo’s 2019 Feature Adoption Report, drawn from usage across 615 of its customers’ products, found that 80% of features in the average software product are rarely or never used.

So, there’s still a gap between pumping out software and shipping things that customers love. It’s not new or novel, it’s simply good product management.

But product focus is the missing seat in the agentic engineering conversation.

To graduate to the next level of AI-native work, companies need processes to build, deploy, and iterate on products faster, not just software. They need to close the feedback loop with their users to figure out what solves their problems.

The companies that build this capability, going beyond the software factory, are the ones that will discover what works, productize it, and iterate their way to a moat other companies can’t replicate.

Product factories are how AI native companies can build long term differentiation.

How does a product factory differ?

Most software factories focus purely on the engineering workflow: getting clear technical requirements, then going through the SDLC of build, review, test, and deploy.

The factory scales the engineering workflow with swarms of agents that can parallelize work 24/7, even while people sleep.

A product factory goes further. It connects the software getting built with the surrounding context and efforts in a business, so the acceleration is cross-functional.

More importantly, a product factory speeds up the time to customer validation, helping teams identify what’s going to move their business, not simply ship more software.

Bringing in product

The first step is connecting the software work with product context.

It starts with the PRD that clearly articulates the problem to be solved, why it matters, and the use cases to prioritize. Without this, the agent will guess, and you’ll ship a mediocre feature.

This sounds obvious, but I’ve noticed that many product engineering teams go straight into building without spending enough time clarifying the problem and documenting it.

Using Fable and Astra reveals this need even more. The top frontier models perform better with context on why, not with detailed instructions on how.

Anthropic’s own prompting guide says: “Providing context or motivation behind your instructions… can help Claude deliver more targeted responses.” You give these models the problem to be solved and the context around it, not a bare to-do list.

For Moda, we have a PM agent that drafts PRDs to cover all these bases, and it talks with the engineering agents via CLI so that the PRDs are optimized for downstream tech designs.

It’s not just about a PRD-writing agent in isolation, but we need a teammate for the engineering agent so that the two can collaborate and build in sync with each other.

And it doesn’t stop with PRDs.

As your team builds more products, generates more PRDs, and makes real decisions about the product, that context needs to get captured.

This critical context is your product principles. It’s what drives your best PM’s decision making.

These principles span products, and they reflect how your organization makes decisions and weighs tradeoffs.

Codifying them and giving them to your agents creates the feedback loop: each subsequent PRD matches your company’s principles more closely, and the product factory’s loop gets shorter, requiring less review and human override.

Bringing in design and data

Beyond the PM function, the product factory also needs to pull in design and data to keep features aligned as they continue shipping.

A design agent must weigh in with perspective on the company brand, visual identity, usability, and use of common components. Like the product principles, the design principles dictate what’s important from a UX perspective and drive consistency across features.

I’ve seen this firsthand building Baohua, a bilingual family storytelling service for Chinese American families.

When I don’t have my design agent weigh in, the engineering agent creates new patterns it doesn’t need and strays from our visual language.

That leaves me, the human, diligently catching all these errors and correcting them. Or worse, I miss one on a review, and we’ve started shipping features with design issues.

For data, there needs to be a feedback loop that captures whether the feature is delivering.

This part of the factory covers everything from instrumentation to data normalization, and eventually to analysis and reporting. It’s how you find out whether a new feature is solving a problem or joining the 80% nobody uses, and what it learns becomes input to the next PRD.

The key is codifying the HOW and the WHY

Take a step back from the software factory, and two things jump out for agent-first work: writing down both how the job gets done and why we make certain decisions.

The agent definition, its workflows, and the flows for generating artifacts (PRDs, designs, analyses, etc)... that’s how the job gets done. Most teams are doing a variation of this today with their agent MD and skills files.

The principles for decision-making are the why, and they’re the crux of every company brain right now.

The hard part is creating and maintaining a clean file that articulates how each department evaluates tradeoffs and makes decisions. the product principles behind every PRD, the design system and visual language, what engineering design excellence looks like.

Implementing these principles alongside the agent definitions is what lets the factory scale.

Where to start

Product factories take us to the next level of AI-native building.

It goes beyond engineers, PMs, and designers using coding harnesses and Claude design on their local setups. It’s a coordinated effort across departments, using agents to update and maintain the critical sources of truth: your PRD, your design system, your tech design.

Start with one bet.

Find your best AI teammates across functions, put them together on a new project, and get out of their way.

The goal of that first project is a win: one new AI opportunity built and validated, with the team using and refining the agentic systems that make it possible.

Try to ship and validate your bet within 90 days.

From there, refine how your factory works. Improving the factory requires iterating on the agent design, but also your organizational processes - how you’re aligning on key designs, codifying principles, and updating them as you learn.

And make sure the team documents your principles, decisions, and learnings along the way. This is how the team builds its AI native capabilities that create long term differentiation.