Once engineers started working in public with a software factory, they typically had an aha moment on how it’s better. For instance, when you start work in Slack, you can easily tag a teammate in for their opinion and all the context is already there. You can continue that work on your phone from anywhere. You can search your team’s history, and use that work to inform the next prompt. There are a lot of non-obvious benefits that product engineers start to feel from the new way of working that make them want to stick with it.

At Warp, we are having fun tweaking our model mix and factory workflow to drive our cost per PR down. It’s gone from $80 → $20 using a factory approach, with a lower revert rate and 40% higher PR throughput than in the last month. Folks on the team are suggesting experiments to improve further, like reducing subagents and building model routers. As a startup founder who cares deeply about efficiency and burn, seeing us reduce costs while increasing velocity and quality is incredible.

On Friday, we became aware of what we believe to be an active and narrow-banded exploitation of a vendor in Warp's infrastructure. We detected the operation within hours and were able to remediate and mitigate the impact. We have been in touch with the vendor about the vulnerability. Everyone who uses Warp places a lot of trust in us and that’s not something we take lightly. I’m very sorry that this incident has occurred. The attack appears to have come from an agent swarm using a very sophisticated penetration and escalation technique, likely starting with a hole in a vendor dependency, and ultimately accessing a limited amount of agent trace and telemetry data. We have been working over the weekend and we have notified anyone who we have positively identified as impacted. As of today, we believe an upper bound of roughly 1% of Warp users may have been impacted. We are working closely with the team at Crowdstrike to do a more extensive and comprehensive investigation and have engaged law enforcement. Anyone who has been impacted will receive instructions from us on action they need to take. We will continue to post updates as we learn more.

You can’t build a software factory unless your team first does at least some of its product engineering through a factory as opposed to local coding agents. This means centralizing your agents into one shared configuration that the team can optimize together. Once work starts flowing through the factory infra, you’ll have a baseline to measure and improve.

If you track software factory metrics, don't celebrate the wrong signals. Bad: LOC written, tokens used Good: Cost-per-PR, cycle time from conversation start -> merge A factory leaderboard should take cost into account and champion shipped work, not token spend.

Every part of a software factory should be configurable as code. It means agents can suggest changes their own setup, and humans get both version control and code review on the other end. It's like Terraform, but for agents.

For agent PRs: Should agents use the engineer as the PR author, or should agents get their own identity? We've been making agents the author at Warp, and removed the need for a second engineer's review. Spoke to @cmhandel and @hudaman about this too. Curious where people land.

I don’t recommend starting with a full loop of agents fixing your backlog or auto-fixing new issues. It’s too likely the agents will generate PRs that never get reviewed and that will turn the engineering team off from a factory approach (“this thing is just a slop cannon”). Start small and focus on tasks where the outputs are likely to be right from the outset.

Best way to start with software factories is some small automation that's useful to everyone. One example is rolling your own PR review agent tuned to your setup, instead of something off the shelf. @cmhandel's team set this up at Faire recently

At @aiDotEngineer, I presented our skill called /skill-doctor. It's a skill to improve your agent skills. It aggregates your past agent sessions, grades their quality, and propose improvements to fix common failures.

I like @hudaman's framing on software factories from our recent discussion. It's systems-level engineering to tune agents to write better software. They call it a "code machine"

Getting software factories working is going to be one of the more interesting software engineering challenges in the next few years. Software engineering is becoming factory engineering. Organizations that can make their factories robust, dependable, and self-improving will be able to ship more at better cost and have a competitive advantage.

I've been thinking about what a true, closed-loop software factory will look like. One where agents know what to fix, what costs to optimize, and the big one: what features to actually build. We're not there yet. But maybe we're getting close...