Position software factories not as a “product,” but as an infra platform upon which everyone is expected to do “factory engineering.” Factory engineering is work to make internal factories better. That means improving the skills, models, and context that drive engineering throughput. It means encouraging engineers to build automations for their chore work. It means giving them the tools to score and benchmark factory workflows, and empowering them to use agents to build self-improvement loops. It means that everyone owns lowering factory costs and improving factory ROI. If you use a platform like Warp Factories, all of this tooling comes built-in, but beyond the tooling “factory engineering” is really a mindset.

We should stop keeping all of our agent conversations local. They should be stored in a shared place. This lets you do some powerful things: - Schedule self-improvement agents to review runs and pull out failure modes worth fixing - Replay past conversations against different models for benchmarking I met a team of devs zipping up Claude and Codex sessions from their computers and shipping them to a shared S3 bucket. That's... a start 😄 But really, all agent sessions should happen on a single source (like a cloud runner) so that conversation traces are stored together by default. It's why Warp Factories uses cloud sandboxes and makes sessions available via API. We also added an inbox view to see which conversations need your attention, which is quite convenient:

verification is the biggest bottleneck for coding agents right now according to @addyosmani. we @warpdotdev have put a lot of thought into building a good computer-use tool for Warp Factories. every agents gets a computer to navigate the apps they built, take screenshots and recordings, and post them back for human review. 3-4mins of activity get edited down to 15 clips stitched together with cursor clicks, mouse animations, and key presses. we've been able to dramatically cut our time to merge and unlocked faster iteration + review cycles, especially for projects that are hard to mock out locally!

Have an automation set up to explore and work on issues/PRs that haven’t been touched in a while There’s some stuff I’ve opened up weeks ago and never ended up driving to completion, but it’s nice to have your factory pick it up without asking A little bit of proactive magic goes a long long way

Three months since adopting software factories, we’re at 40% more PRs merged and 67% lower cost per PR. We got there by measuring agent quality, benchmarking models, and using self-improvement loops to make our factory better. Here's how you can do this too in Warp Factories:

Building Evals on Production Data: 🦄 AI That Works #79 xitter.cf/i/broadcasts/1oJMvNZWv…

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.