Factories: The future of work?

Seems like everyone is talking about software factories these days. Sorry to pile on, but we’re here to talk about what matters today and where things are headed and right now the factory ticks both boxes.

I am on the record that “software factory” is not a descriptor I particularly like or find inspiration in. I’ve heard from a number of other people that feel the same way, but it’s the term we have for now so it’s the term we’ll use.

This is not, to be clear, the software factory that Marty Cagan coined 15+ years ago as a way to describe engineering orgs that were “optimized for coding rather than a collaborative partner for discovering and delivering successful products”. Nor does the the factory need to be “dark”, which implies that humans are entirely absent from the “manufacturing floor” and therefore lights are unnecessary.

For our purposes, let’s use this as the working definition:

A software factory is a shared system for building and shipping software that makes how the work gets done explicit and measurable, so improvements become part of how the whole team works.

You may notice that we didn’t say “agents” or “AI” anywhere in that definition. What are being called software factories today have existed for many years, pre-AI. Of course, in 2026 when anyone talks about software factories they definitely mean “with agents”; we would argue that’s not because a software factory needs agents to exist, but rather that any minimally optimized “shared system for building and shipping software” would recognize that, in addition to other activities, utilizing agents to generate code is measurably more effective than the alternatives.

The main difference between how your team probably works today and how it would work with a factory at its core is in the latter half of that definition: most teams historically have not built and delivered software in a way that is explicit or measurable. That doesn’t mean all teams need to work the same way. In fact, quite the opposite. Defining a “factory” for your team or codebase means that every team can work in subtly or significantly different ways as long as they’ve defined that way of working in a way that can be understood, analyzed, and measured (ideally programatically).

That act of defining your process, your SDLC, the way you build and ship software to be explicit and measurable has a number of advantages in the age of AI, which is why it’s gaining steam now. First, an explicit system, especially one that’s described in code, it makes it easier to plug agents in. Second, in a world where the software engineering landscape is in constant flux, it allows you to systematically evaluate changes and improvements. And finally, defining and constantly improving the system allows everyone, not just your most motivated engineers, to reap the benefits of AI.

Point being: software factories are not that complicated, and they’re not that scary. They are, in essence, the application of the engineering principles we hold so dearly to the system of work itself. And we promise you the factory concept will not be confined to engineering work, or even software delivery. But that’s a story for another day.

Here’s what we’re reading this week.

Software Factories for Skeptics

Josh Rosen hits all the notes in this one, from why a software factory may not be so different from how you’re already working, to the truly invaluable mountain of data that an instrumented factory can provide.

The term “software factory” is largely an expression of a set of useful design patterns that, when applied, might improve the way your company builds software. In that sense, it’s hard to argue with at least some of these patterns being valuable.

Tactics for rolling out software factories: human and organizational changes

Zach Lloyd, CEO of Warp.dev, is one of the most level-headed voices out there on software factories. Yes, he has a factory thing I’m sure he’d like you to buy, but he’s not pushy about it and instead he just drops article after article with industry-leading thoughts on what a software factory is or should be, and practical advice on how to move your team in that direction.

This week he writes about the messy human side of the shift to software factories, and lessons learned on how to approach it with your team. We could list them all out, or you could just go read it. You won’t be sorry.

The goal is to get the most out of coding agents at your organization so that you are shipping the highest quality software with the most customer impact as quickly and efficiently as possible

The Secure Software Factory: A Reference Architecture

Fair warning, this one’s a bit in the weeds. This is for the folks who want to build their own factory (or factory-like thing). If you’re not there yet, maybe skip this one; we won’t judge you. But if you are there, or even considering it, this is a great resource for skipping past some of the “how are other teams doing this” research and conversations.

How always-on agents work

This is a video of a talk from SpaceXAI’s Lee Robinson in a Stanford lecture. If you want to understand how always-on agents like Grok Bot or Meta Muse work, or if you just want to understand where the latest trend in AI seems to be heading, give it a watch. It’s approachable but full of useful detail.

And there are lessons to be had here about factories as well. Your factory will also be “always on” in a way, so many of the principles of designing always-on agents apply to always-on agentic systems like a software factory too. Don’t interrupt too much, but interrupt with necessary. Reacts to events. Remembers and learns.

How to be more ambitious: A tutorial for humans with models

Every day I learn about yet another feat accomplished with or by Claude that I hadn’t considered, didn’t think possible, or simply lacked the curiosity and time to try

Felix Rieseberg from the Claude team. He breaks down four types of ambition (we identified five) and even gives example prompts for how to get more out of Claude. It’s simultaneously very nod-your-head simple and scratch-your-head thoughtful.

“That’s not SOC 2 compliant”

So many people. That’s how many people bring up SOC 2 compliance when we suggest auto-approving PR with AI review. And we patiently describe to them how you actually get to define your Change Management and Access Control evidence, and you can update your criteria to match your new processes as needed. Now the Amp team gave us a real world example to point to (though if you’re looking for something to convince your compliance person we might start here).

One thing to try this week

For the hackers out there: Claire and Zach have both ordered digital photo frames with the hopes of rooting them and customizing them to their hearts content. It’s all the rage on X. If you try it let us know how it went!

Happy hacking!

— Claire + Zach