Software Engineering Is Becoming Factory Engineering — Zach Lloyd, Warp

Zach Lloyd, Warp’s founder and a former Google principal engineer who led engineering on Google Docs, opens with a striking change in his own work: he still ships frequently, but has not written a line of code in six months. Warp has changed alongside that shift. It began as a terminal, added agents, and is increasingly focused on automating development beyond an interactive session.

The progression runs from chat and autocomplete tools such as Cursor and Copilot to interactive agents such as Claude Code and Warp. In the interactive model, a developer sits at a computer and tells an agent what to do. Automation extends that arrangement: work can move through several development stages without a person initiating every handoff. Lloyd predicts that transition will accelerate over six months to a year, while acknowledging that its pace is hard to predict.

The room’s show of hands makes the gap concrete. Almost everyone is using agents and running several at once; fewer than half appear to be running them in the cloud, and only some have automated the whole development life cycle. Using several coding agents is already familiar. Connecting triage, specification, implementation and review into a working system is the next step.

A software factory follows the familiar development loop. Ideas enter; agents triage them and write specs for complicated work; humans review those specs; agents implement; humans and agents review the code; agents verify; humans review the product; the change ships and gets monitored. The factory metaphor shifts the engineer’s responsibility toward building and managing the system that performs those steps.

Warp’s move to open source provides the first application of that idea. After five years of building closed, the company wanted to build a public factory. Its public view shows issues moving through the system, their current states, and the agents and contributors working on them. Lloyd describes it as a working proto-factory at scale, with imperfections still to resolve. Earlier in the talk, he reports over 60,000 GitHub stars, a couple hundred contributors and over 800,000 active developers using Warp.

The business motivation starts with a cost problem: cheaper software development also makes competing products easier to clone. A great product remains necessary, but Lloyd’s judgment is that it becomes harder to capture value through the product alone. Distribution, an ecosystem, brand, proprietary data or capital can provide additional advantages. A startup may have little of any of them.

Building in the open offers a way to grow an ecosystem, community and brand while developing the product. Lloyd’s deliberately modest version of the reputational benefit is going from “hated on Hacker News” to “tolerated.” The obstacle is maintenance: more participation can bring noisy issues, sloppy pull requests, lengthy code reviews and expensive verification.

Automation changed Warp’s decision because it could take on some of that maintenance work. The company built a set of automations around managing the open-source project, making the public factory both a development system and a way to handle contributions. That is the causal link between the open-source digression and the engineering thesis: opening the project brings work in, and the factory helps move that work through.

An effective factory needs automations, context and skills, ways to bring humans in when necessary, and mechanisms for improving itself. Those requirements apply beyond open source: agents can help contributors contribute and maintainers maintain, but an internal product team has the same underlying problem of moving work through development. Lloyd expects factories eventually to become as routine as CI/CD.

The factory floor is a graph of steps. Its inputs are ideas from a team or its users, arriving through task trackers, communication channels such as Slack, a terminal or IDE, or monitoring systems. Defining that graph means deciding how this particular product gets built and where work should pause for another decision.

Triage supplies the first consequential branch. An agent examines an incoming issue: if it is easy and unambiguous, it can go directly to implementation. A harder issue should produce specs first. This gives a team a small starting point for automation without requiring every task to pass through the same amount of planning.

Warp separates the specification work into two complementary outputs:

• Product spec: Describes the product properties the change should establish or preserve—the behavior the implementation is meant to achieve.
• Tech spec: Describes the architecture and the shape of the code that will implement it.

Human review of the spec provides a chance to correct the intended result before the implementation agent starts producing a diff.

The implementation agent is a coding agent running in the cloud. Its output is a diff, which then enters review. Lloyd recommends an agent review first, followed by human review where the risk warrants it. The human review step remains available; the engineering decision is when to use it, especially as reviewing large amounts of weak agent output becomes a bottleneck.

Verification asks whether the resulting product works. For a UI, computer use can exercise the code and produce videos and screenshots; CI/CD still performs its established role. Human product review precedes shipping in the initial loop. After shipping, agents should observe crashes and usage, then feed that information back into the factory as new work.

Where does work branch, and how does a shipped change generate the next task? The diagram follows the triage decision through implementation and review, then closes the loop through monitoring. Human checkpoints sit at decisions about intended behavior, code risk and the resulting product.

A simple factory is approachable; a factory that scales brings a larger infrastructure burden. Lloyd points to an internal system at Uber as an example, but advises most organizations to consider whether building that infrastructure would distract from their own product. Either a built or purchased system still needs several layers underneath its workflow.

• Work intake: Provides the ways tasks enter the factory.
• Control plane: Decides how work gets distributed across the factory floor.
• Execution: Runs work in cloud sandboxes and selects the agent harness and model.
• Data plane: Lets agents remember what they have done and supports learning and improvement over time.

The workflow describes the development steps; these layers provide the machinery for running them.

Operating that machinery requires measuring its efficiency. Lloyd names shipped software, human time and token time as quantities to track. More generated code alone does not describe the factory’s performance: the useful comparison is what gets shipped and what it costs to get there. Those measurements give the team something to improve over successive runs.

Self-improvement adds another loop around the agents doing the work. Factory agents apply skills; observer agents examine how those skills are used, look for failures and try to improve them. The feedback concerns the development process itself, rather than only the product being developed.

The concrete example is a code-review agent leaving comments that a senior engineer then corrects. Without a skill loop, those corrections help the current review but may have no effect on the agent’s next run. With an observer, the corrected comments become input to improving the review skill. The intended change is that the next review uses the revised skill instead of repeating the same approach. This is a proposed feedback mechanism; the talk does not establish a measured improvement or specify how skill revisions are evaluated.

How does a human correction travel beyond the current pull request? The diagram makes that path visible: the observer connects corrected review output to the skill used on the next run. That connection is what turns an individual intervention into a possible improvement in the factory.

This changes where engineering effort goes. Building the product now includes building the thing that builds the product: arranging agents, improving their skills and finding where the process needs human intervention. Lloyd calls this “meta engineering.” His forecast of coding less and shipping more has a personal tradeoff: it may appeal to people whose satisfaction comes from shipping, while taking away some of the work enjoyed by people who love writing code.

For a practical starting point, Lloyd introduces an open-source GitHub repository for building factory agents, including triage and spec-writing agents. It uses Warp’s agent platform, though he says using that platform is optional. The repository is meant to bridge the gap between drawing a factory loop and setting up its individual workers.

The first audience question challenges an apparent contradiction: why become a factory engineer if building factory infrastructure is a distraction? The answer separates deploying the infrastructure from tuning it for a product. Even with a purchased system, engineers must decide whether its skills fit their domain and whether it builds their product in the right way. Some organizations can build the infrastructure themselves; Lloyd’s default advice is to keep attention on the core product while doing the tuning that makes the factory useful.

Asked where a graduating student should spend their time, Lloyd emphasizes adaptability, critical thinking and the speed of learning. Systems knowledge remains valuable because someone must understand the architecture, reason about generated code and assess the specs agents write. The desired engineer can solve product problems while the tools underneath the work keep changing.

Warp’s hiring experience, he says, has involved hiring more people than ever, rather than cutting hiring because of AI. That is an observation about Warp, not a conclusion about the whole labor market. The qualities he is looking for are adaptable, product-focused thinkers who can understand and solve problems as the underlying technology changes.

The final question puts discovery, ideation, design, vision and taste back into the picture. A factory metaphor can sound mechanizing or dehumanizing, but its output still has to be useful. A factory producing things nobody cares about has missed the purpose of the work, regardless of how efficiently it runs.

Human taste, input and product sense remain essential at the points that cannot be automated. Lloyd describes his own work here as figuring out what customers want and what will be valuable to them. The factory can organize how a change gets built; people still have to guide it toward something worth building.