In a fully humming factory, the key characteristic is that it’s a closed loop, measurable, improvable system. This should be the goal. In such a system everyone is working from the same context, in public, in a fully-audited, observed way. Agents themselves are observing the skills and config that drive the system and suggesting improvements. Platform engineers are able to extend the system to integrate it into all internal systems. Engineering leaders can see productivity metrics and understand what changes are being made to improve them. The whole thing is running empirically, not on vibes.

The software factory approach is getting pretty popular, but it can be daunting to adopt all at once. Let's go through “crawl, walk, run” steps for making the transition from local, interactive agents to automated cloud development.

Our cost-per-PR keeps trending down. Now we're at $30. The biggest drivers: - Benchmarking models on our own data to find the most efficient cost/performance pick. GPT 5.6 Sol (high) today - Letting agents review past conversations and PR skill patches for bad instructions and adjusting our skills accordingly $30 still seems expensive on average though. I think we can get this to $10 or lower, and we are still figuring out what good looks like here. Obviously not all PRs are equal.

Software factories should be built on an infrastructure stack that is open, composable, and defined-in-code. This article lays out the principles that apply to anyone who is looking to move to a factory model.

We benchmarked the top models on our own coding tasks. The results: - GPT 5.6 Sol (high) won on performance - Grok 4.6 (high) was the runner-up - GLM 5.3 Flash won on cost at comparable quality All 50%+ cheaper than our previous default (Opus 5)

what's a good term for what software engineering is now? I like "meta-engineering." I'm spending most of my real engineering brainpower at this point architecting how our agent system runs, not guiding individual agents,

Powered by the skills backing our Warp Factories self improvement loop. We've merged 5 skill improvement PRs this past week written by these agents, several catching token burn cases that our engineers missed

It's time to apply a true engineering mindset to deploying coding agents. There’s too much hand-waving around what agents are best, which models to use, and how to optimize ROI from coding agents over time. The solution is to set up a closed-loop system in the cloud where all of your agents are tracked and measured against your own data and workflows, so you can adjust your setup based on actual data and not vibes. The emerging category of infrastructure that supports this approach is the cloud software factory. Software factories are automation loops around the SDLC, comprised of agents that triage, spec, implement, verify, review, monitor, etc. Done right, these factories allow for measurement, improvement and automation over time, and can help prove that you are doing agentic engineering the right way. Factories should follow these design principles: - Factories should be defined as code, version-controlled, and have their definitions editable by agents. - Factories must live in the cloud to support team access, central data storage, and automations. - Factories should have a runtime that is API driven, not UI first. - Factories should come with built-in evals, improvement loops and benchmarks so you can ensure improvement over time. - Factories should be inherently multi-model and multi-agent, so they can take advantage of improvements in models and harnesses. Your goal is getting to a “closed-loop” factory: one where all of the data, observability and improvement features are baked in, so that agents (and humans) can use that data to improve the factory over time. That last point on data collection and self-improvement is especially important to get right. If you’ve set up your factory properly, these agents take their learnings and propose changes to how the factory operates. They do this by creating diffs against the factory definition, which – assuming your factory is defined as code – is easy for them to change. The high-level flow for self-improvement comes in three steps: 1. Factory agents do triage, implement, verify, etc. – they build the product. 2. Scorer agents periodically grade that work along dimensions that you define, like cost, quality, verbosity, etc. 3. Self-improvement agents review scores and suggest improvements. Humans review those suggestions as PRs on the factory definition and merge improvements. The way to think about the factory approach is as meta-engineering. You should invest now in infrastructure that lets you measure, test and automatically improve the SDLC. The longer you wait, the more catch-up you will have to do and the more tokens you’ll burn in the meantime. Building this infra is possible, but a big endeavor, so as you evaluate factory platforms you should look for ones that have the right primitives to help you scale software development today. If you're team is building a software factory, let's get in touch:

Introducing /skill-doctor v1 Skill doctor is a skill that improves your skills: - Crawls your past CC, Codex, or Warp convos - Scores them for efficiency and code quality - Proposes diffs to your skills that you'd actually merge (STE-100 approved) 🔖

We're building a debugger for agents internally. Breaks down costs by agent + subagent tasks, shows agent processes on a timeline, tracks the exact dollar amount spent. Would you use it?

Introducing self-improvement loops. The concept is simple: what if agents could improve Skills by reviewing past conversations? Here's the three step loop: - Score conversations from criteria you define - Isolate failures - Generate skill improvements

we should be building infrastructure for automating development, not org structures of agents. infra means deterministic, reliable, measurable systems with guardrails around agentic behavior, defined in code, versioned, testable, etc Because agents seem so human in their communication we naturally think in human analogies, but the better approach IMO is to realize that at their core these agents are engines of automation and we should treat them as such

Our scorer agents noticed that our foreman was sometimes implementing changes directly, rather than passing them to our implementor (think of the foreman as our factory orchestrator). This isn't ideal because our implementor has special skills and model settings for coding. After this regression happened a bunch of times, our self-improvement agents noticed the pattern and suggested a fix to strengthen the prompt. We would have noticed this eventually, but having it happen automatically was magical.

This is an example of a productized self-improvement loop on code review in Warp Factories. You can see here that our observer agents are scanning PR comments for patterns and suggesting changes to our factory PR skills that we then review, merge, and improve.