CEO Zach Lloyd on the Benefits of Open Sourcing Warp

How Warp built an agent-first open source contribution workflow that actually works. 56K GitHub stars, 500 contributors, and one clear signal: Agents and humans build better open source software together.

A few weeks ago we open-sourced Warp, our agentic development environment, under AGPL. It’s been remarkable to see developers not just star the repo, but actually jump in and start building: 500+ unique contributors, hundreds of PRs, and the repo went from about 25K to over 56K GitHub stars in the first week.

I’m incredibly grateful for that response. But what’s been most interesting to me is not just the volume of contributions — it’s what the contributions reveal about how open source development is changing.

We open-sourced Warp because we think we can ship a better product, more quickly, by working with the community through an agent-first workflow managed by Oz, our cloud agent infrastructure platform. Contributors help identify what matters, shape product direction, and verify behavior. Oz agents handle triage, planning, implementation, and verification. The Warp team keeps the product coherent and ships the final changes.

The reason this works is that the biggest bottleneck in software development is no longer writing code. It’s everything around the code: deciding what to build, speccing it clearly, reviewing changes, and making sure the behavior is right. Agents are increasingly good at the systematic parts. Humans are still essential for judgment.

What an Agent-First Open Source Contribution Looks Like in Practice

Here’s a real example from our first few weeks.

Sagar Dagdu was using Claude Code inside Warp and noticed a UX gap: dragging an image onto a CLI agent session typed the file path as text instead of attaching the image. Cmd+V worked fine — drag-and-drop didn’t. He filed issue #9545 with reproduction steps, a Loom video, and a code trace identifying the exact root cause — he’d read the source and found where the drag-and-drop path diverged from the clipboard path.

Within minutes, Oz triaged the issue automatically: confirmed high reproducibility, validated Sagar’s root cause analysis, identified the four relevant source files, ran a duplicate check, and routed it to the right team areas.

Sagar then submitted a PR with the fix. The first implementation surfaced an important design issue: the image reached Warp’s attach pipeline, but not the foreground CLI agent in the way the user expected. He redesigned the approach to mirror the clipboard-plus-paste-keystroke mechanism that Cmd+V already uses, ensuring the agent picks up the image the same way it would from a manual paste.

When he submitted the redesigned PR, Oz reviewed the change using Warp’s repo-specific rules and verification process. It caught a race condition: if the foreground process exits while the image file is being read asynchronously, the paste keystroke could be sent to the wrong PTY context. Oz requested changes.

Sagar fixed it, and then a Warp engineer validated the UX — recorded a Loom walkthrough, requested before-and-after videos, gave detailed code feedback. Multiple rounds between agent and human reviewers. Then it shipped.

This is exactly the kind of contribution I’m excited about. A developer hit a real problem, dug into the codebase, and essentially wrote the technical spec in the bug report. Oz triaged and validated within minutes, then caught an implementation risk during review. The Warp team verified the product experience. The whole cycle — from issue to merged PR — happened in five days.

You can watch this process happening live at build.warp.dev, our contributions dashboard.

What We’re Learning About Open Agentic Development One Month In

We’re less than a month in. The processes are still evolving, and we expect them to keep changing.

One of the most encouraging things is that people are coming back. Anshul Garg shipped 16+ PRs in the first few days. Sagar — the drag-and-drop contributor — came back to fix Xcode detection in bootstrap and improve the /feedback skill. People are not just showing up once. They’re staying, learning the codebase, and helping make Warp better.

The community is expanding Warp in ways our internal team couldn’t have gotten to on our own. Four different contributors independently fixed input method issues for CJK users across macOS, Linux, and Windows — the kind of internationalization work that’s critical but realistically would sit in our backlog for months. Someone got Warp compiling on FreeBSD, a 70-file change touching platform code across the entire codebase.

We’re also learning where the hard parts are. Opening the product does not mean accepting every feature request or every agent-generated patch. One of the core team’s most important jobs becomes editing: deciding what belongs in Warp, keeping the architecture coherent, and making sure contributions add up to a product rather than a pile of features.

We’re still actively working through open questions with the community: how to support local and arbitrary models in a way that matches what users actually want, where the right boundaries are between agent autonomy and human oversight, and how to keep scaling the review process internally as contribution volume grows. We also want Warp to be a real open alternative in agentic development: multi-model, multi-harness, and shaped by the developers who use it.

Why Open Agentic Development Matters for Every Open Source Maintainer

This is the loop I’m excited about: a developer hits a real problem, turns it into a concrete issue or prototype, agents help with triage, planning, implementation, and verification, humans make the product and architectural calls, and the result ships back to everyone. Each contribution makes Warp better — and also makes Oz better at helping with the next contribution.

If you maintain an open source project, you already know the review bottleneck. As AI-generated contributions increase, the amount of code to review will grow much faster than the number of humans available to review it. I think this is going to put real pressure on maintainers.

One of the things we’ve found that reduces this burden the most is getting alignment on agent-generated product and tech specs before implementation starts. When the spec is right, the review is straightforward. When it’s not, you’re debugging intent at the PR stage, which is where maintainers burn out. Projects that figure out how to use agents for triage, planning, implementation, and verification will have a real advantage.

The approach we’re taking — agents handling triage, planning, implementation, and verification while humans focus on direction and judgment — isn’t Warp-specific. It’s an approach that applies to any project where maintenance load is outpacing maintainer capacity. That’s most of them.

We’re starting to bring these workflows to other open source repositories through Oz for OSS. We work directly with maintainers to implement agentic workflows for issue triage, PR review, community management, and contributor coordination in a way that fits each project. The same workflows also work for private repos and large engineering teams — but that’s a post for another time. If you maintain a popular open source project and are thinking about how agents could help with triage, review, or contributor coordination, we’d love to work with you.

We’re still early in figuring out what Open Agentic Development looks like. But contributors are already using AI to write code. That shift is already happening. The open question is whether maintainers build workflows around it.

Get involved with Warp and open agentic development:

• Explore the repo: github.com/warpdotdev/warp
• Watch agents work in real time: build.warp.dev
• Join the conversation: #oss-contributors on Slack
• Apply for Oz for OSS

If you’ve opened an issue, submitted a PR, or helped us think through what Warp should become, thank you. We’re still early in figuring out what Open Agentic Development looks like, but I’m more convinced than ever that the best way to figure it out is in the open, with the developers who use the product every day.

If there’s something you want to build or fix in Warp, we’d love to have you involved.