Software engineers have been through a lot of change in the past two years, transitioning from writing code by hand to steering agents via local interactive prompting, the current paradigm. The next paradigm, software factories (where agents do more and more autonomous work) is particularly challenging.

The metaphor of “factory” is kind of a bummer. It feels like your job as an engineer is either working on an assembly line, or building the assembly line that obviates the need for your talents. If you use the “AI teammate” metaphor (which I also dislike), then it feels like engineers are becoming managers of sycophantic and somewhat inept junior engineers. For folks who take pride in the craft of building, this all feels like commoditization of software creation.

I disagree with this outlook. On our team, engineering involves two very important challenges today: building the product, and now, building the factory that builds the product.

First, our engineering team is still responsible for the quality and usefulness of the product – this cannot be delegated to agents. Humans are uniquely positioned to know what to build, how the pieces should fit together, what the product experience ought to be, what constitutes good design.

There are two caveats: Some types of product work that don’t need any human input at all and can be purely automated. (Fixing server crashes, simple bugs, dependency upgrades, etc.)

The second caveat is that product engineering will work differently. Rather than engineers working locally with their own bespoke setups, they will hand off as much of the software lifecycle as possible to the factory. All of this work will be inherently visible and measurable, and that’s a feature, not a bug.

Developers should expect to measure and iterate on other aspects of how they use the factory, including how much their agents ship and at what cost. Engineers could view this as a drag, but they also can view it as a game, and winning that game means shipping more for less, using an engineering mindset to improve.

This brings me to the second job of the engineer, which is to design the factory itself. We call this factory engineering. It consists of measuring the performance of your factory. This needs to be done with an engineering mindset – you don’t adjust your factory on vibes; you measure, test, benchmark and then improve.

At Warp we make it explicit that the expectation of engineers is not just to build products, but to improve factories. We envision both jobs as being the responsibility of all engineers to make it clear that factory engineering is now part of software engineering.

On our team, the folks who like it most are senior engineers who love hard systems problems, who enjoy optimizing and debugging performance issues. It requires a lot of thought and testing and patience. We lean into it as a new skill to learn. Ultimately, this lets us ship better products more quickly, which has always been our mission.