The Road to Software Factories

I’ve been talking to a lot of engineers and leaders lately, and there’s a lot of anxiety about the future of software development. If you follow today’s AI news, you’d think every engineer already has a team of autonomous coding agents running 24/7.

Agents breaking down tickets. AI managers dispatching AI workers. Production errors triggering agents. Code factories shipping features overnight while everyone sleeps.

That’s likely the destination, but many engineers are still in the AI-assisted stage (tab complete + basic prompts). The Pragmatic Engineer’s March 3 survey puts some numbers behind the gap. Among 900+ reader respondents, 95% used AI tools at least weekly, but only 55% regularly used AI agents. And regular agent use is still a long way from a software factory. We’re early.

So what should engineers focus on?

I think the most important shift is understanding that agentic engineering is the new baseline skill.

My seven AI coding maturity stages

That’s all about focusing your effort on the spec and verification, and less on the actual code. It’s critical to think through these questions: What should the code do? How do you know it’s correct? How will you verify it works as part of the broader system?

This isn’t vibe coding. It’s still engineering. System design and reliability are still the goals here. And the better you can describe the expected behavior and build reliable verification, the more confidently you can rely on that generated code.

There are two big reasons this matters right now.

1. The Work Moves to More Important Areas

For decades, improvements to developer tools kept code at the center: better IDEs, debuggers, and refactoring tools.

They were all in service of making it easier to explain to a computer what you wanted to accomplish.

But software engineering isn’t just about the code. It’s never been about the code. There’s a whole lifecycle that starts with understanding your users, figuring out requirements, deciding the UX design, thinking about architecture, and finally getting it out to your users.

So when agentic tools like Claude Code or Codex de-emphasize the actual code, that does change how we work but doesn’t change the job.

Less focus on the code puts pressure on the left side and right side of the “coding” step in the product development lifecycle.

The product development lifecycle still exists. Just the tooling changes.

On the left side, teams that are deliberate about defining the right inputs will get better outputs. Think better PRDs, better specs, and better exit criteria.

And on the right side, teams that are deliberate about validating the outputs will succeed in delivering more solutions faster. Think robust testing cultures, automated and comprehensive QA, and strong CI/CD practices.

OpenAI recently described a similar shift in an internal team’s work. Engineers spent more of their time defining requirements, building the environment agents work in, and creating feedback loops to verify the results:

The lack of hands-on human coding introduced a different kind of engineering work, focused on systems, scaffolding, and leverage.

The craft is changing.

Interestingly, it resembles the world of farming. In Think Like a Farmer, I wrote about preparing the ground for good engineering work. We’re going to need to obsess about the inputs, the architecture, the users, and then know how to verify that it works. And if it doesn’t, learn from what went wrong, adjust our inputs, and try again!

Or if you prefer a more modern analogy: software development is starting to resemble training a neural net. The generation process can feel like a black box, but you define the goals, evaluate the outputs, and adjust the inputs.

Late last year, Steve Yegge declared 2026 “The Year the IDE Died” in a talk with Gene Kim. He described a similar progression where engineers are going from hand coding to completions to chat to agents. Each step asks you to get better at describing work and checking what comes back.

This way of working can feel uncomfortable. Decisions you’d normally make while coding need to be explained upfront. But practicing it builds your skills. You get better, it gets easier. You got this!

2. This Scales Into the Multi-Agent Future

If you can reliably get great output from one agent, you can start running two. Then three. Then trigger them automatically with cron jobs, events, or automated reviewers.

That’s when you start moving toward agent teams and eventually code factories.

Each stage builds on the one before it. Getting reliable results from one agent gives you the foundation to scale.

It’s exciting to read about Ralph Wiggum loops, autoresearch, or projects like Gas Town and Antfarm. They explore different parts of this future: repeated attempts, measurable feedback, and coordinating specialized agents.

But most engineers shouldn’t try to jump straight there. If one agent keeps misunderstanding the task, running five won’t fix the problem. You’ll just have more work to untangle.

Make sure that one agent works before adding more 'Ralphs'.

And even reliable agents need coordination. Their changes have to work together. They need to record progress, handle failed checks, and know when to ask for help. You’ll want limits on retries and spending (especially while you’re asleep).

Start with one task. Write a clear spec, give the agent the context it needs, and build checks you can trust. Pay attention to where you keep stepping in, then improve that part of the process.

Forget the factories for a moment. Focus on better specs, stronger verification, and consistent output from a single agent. Do that well, and you’ll have something worth scaling.

« PREVIOUS Is Ralph Wiggum the Future of Coding?

NEXT » Building Super Truck Rally with AI