Zach Lloyd

Zach Lloyd is the founder and CEO of Warp, where his work has progressed from redesigning the terminal to helping developers direct, supervise, and improve AI coding agents. A former principal engineer who led Google Sheets and engineering across the Google Docs suite, he emphasizes product-first engineering: judging technical decisions by whether they help people build useful, working software.

From collaborative applications to the terminal

Lloyd’s career has included running Google Sheets, co-founding SelfMade as CTO, and serving as interim CTO at TIME. His personal engineering handbook draws on those experiences to discuss product development, planning, coding, and hiring.

His product-first engineering philosophy gives those responsibilities a clear priority. Architecture, tests, and abstractions matter because they help software solve a user’s problem. Overengineering can delay useful features; insufficient structure and testing can make delivery harder. The judgment he values is knowing how much engineering a particular problem needs.

In his July 2021 introduction to Warp, Lloyd identified an everyday mismatch: developers worked in teams, but their command-line sessions remained largely solitary and ephemeral. Warp grouped commands and their outputs into navigable blocks and replaced awkward command entry with a familiar text editor. The redesign addressed both the immediate experience of using a terminal and the difficulty of preserving what developers learned there.

Warp’s public beta launched in April 2022. Built in Rust with GPU-accelerated graphics and support for existing shells, it combined a redesigned local interface with an ambition to make terminal knowledge shareable. Warp Drive, introduced in June 2023, made that ambition concrete: teams could save, annotate, share, and execute parameterized command workflows rather than repeatedly reconstructing them.

From operating commands to directing agents

With Warp 2.0 in June 2025, the company expanded the product into an agentic development environment. A shared input accepted commands and prompts; developers could run multiple agents, inspect their progress, and review or edit generated changes. The terminal’s reach across repositories, infrastructure, and deployment provided a starting point for work extending beyond a single code editor.

In August 2026, Lloyd introduced Warp Factories, infrastructure for connecting requests, specialized agents, execution environments, and human decisions into managed development workflows. This extended the product’s focus from individual agent sessions to the process by which a team produces software.

Engineering the system that builds the product

Lloyd’s factory-engineering argument is that engineers will increasingly build and manage the systems that produce software. He expects automated development workflows to become as routine for sizable projects as CI/CD. His proposals explain what those systems need and where human judgment remains essential:

• Software factories: Automation extends through triage, specifications, implementation, review, verification, and monitoring. Straightforward, unambiguous issues can proceed directly to implementation; harder work needs specifications. Product specifications describe intended behavior, while technical specifications describe architecture and the shape of the code. Human reviews provide decision points, and observations from shipped software feed subsequent work.

• Self-improvement loops: Repeated agent mistakes should lead to better instructions. When a senior engineer corrects an automated review comment, for example, an observer agent can use that correction to improve the review guidance for future runs. Lloyd also wants teams to measure shipped output against human effort and token cost, so they can improve the workflow rather than simply run more agents.

• Infrastructure and product-specific tuning: Lloyd distinguishes the infrastructure needed to operate a factory from the engineering needed to make it useful for a particular product. Teams may be better served by adopting shared infrastructure while concentrating their effort on domain-specific skills, review decisions, and whether the system builds the right thing.

Why Warp began building in the open

Lloyd’s position on open source changed as agentic development altered the cost of building software. In February 2024, he explained that competitive and monetization concerns informed the decision to keep Warp closed source. In April 2026, Warp released its client under the AGPL, arguing that community direction, verification, and agent-assisted contribution workflows could improve the product and strengthen the business.

His reasoning connects business strategy with engineering operations. As software becomes cheaper to build and clone, he argues, a great product alone provides less protection against competitors. Building in the open can develop an ecosystem, community, and brand. Automation can also reduce the maintenance burden of noisy issues, weak pull requests, code review, and verification—problems that had previously made opening Warp less attractive.

Warp’s public factory makes this approach visible by showing issues moving through the system and the agents and contributors working on them. In his factory-engineering talk, Lloyd described it as a working but imperfect implementation, rather than a finished model of autonomous development.

Lloyd finds satisfaction in shipping useful products and expects engineers to write less code as agents improve. He nevertheless treats customer understanding, product taste, architectural reasoning, and verification as essential responsibilities. An efficient factory that produces software nobody wants has failed its purpose. That conviction connects his earlier product-first philosophy with his work on agents: improving the machinery of development still requires people to decide what is worth making.