How Coinbase Wallet built an agent-first product development lifecycle

Coinbase Wallet paused shipping for nearly three weeks and asked engineers to delete their IDEs to force an agent-first product development lifecycle, according to Chintan Turakhia, who leads product engineering for the wallet. The experiment cut simple mobile bug and feature delivery from 20–25 days to about 1.8 days, reduced security reviews from three days to five minutes, and enabled a Slack request to produce a pull request and testable build in 12 minutes. Turakhia shared the results at Arize Observe 2026, emphasizing that the new bottleneck is deciding what to build.

For most engineering teams, AI adoption begins inside the IDE or CLI. Coinbase Wallet chose a more disruptive experiment, though. It stopped shipping for nearly three weeks and asked engineers to delete their IDEs. The pause was designed to force an agent-first reset. Chintan Turakhia, who leads product engineering for Coinbase Wallet, framed the experiment at Arize Observe 2026 https://arize.com/observe/ . The difficult part, he argued, was cultural. Coding agents had already become capable enough to generate meaningful software. The team still needed to replace the processes, infrastructure, and habits built around code being expensive to produce. According to Chintan, the results were substantial. Simple mobile bugs and features that once took 20 to 25 days now take around 1.8 days, a request in Slack can produce a pull request and testable build in 12 minutes, and security reviews that previously took three days can now run in five minutes. The most useful lesson, however, came from what broke next. Once code generation accelerated, pull request review, CI, build infrastructure, validation, and eventually product decision-making became the constraints. How to measure time from intent to production Chintan’s north-star metric is time from intent to production . Intent begins when someone identifies a bug, proposes a feature, or develops a product hypothesis. The clock stops when users can experience the result. This metric prevents teams from celebrating local optimizations. More generated code, pull requests, or agent runs mean little when changes still spend days waiting for builds, reviews, test environments, and approvals. Teams adopting coding agents https://arize.com/blog/closing-the-loop-coding-agents-telemetry-and-the-path-to-self-improving-software/ should measure: - Time from an idea to an executable prototype. - Time from a prototype to a validated build. - Time spent waiting on CI, infrastructure, security, or human review. - How often a human must intervene in the implementation. At Coinbase, faster code generation immediately transferred pressure downstream. Builds that took 30 to 40 minutes were moved to cached cloud environments and reduced to less than a minute. Once that bottleneck improved, the team could focus more heavily on validation. Now, Chintan said, the limiting factor is increasingly the input: deciding what to build and why it matters. Inside Coinbase’s AI agent harness for product development Giving every engineer an AI coding assistant was only the first step. Coinbase Wallet built an internal agent harness https://arize.com/blog/what-is-an-agent-harness/ that could carry work across planning, implementation, review, testing, and release. Workflow | Role in the development loop | What humans review | |---|---|---| Forge | Turns requests from Slack into code, pull requests, and testable mobile builds | The working product | Sail | Reviews changes for security issues and assigns a risk level | Risk hotspots and high-impact changes | Tracer Bullet | Moves a specification through implementation, simulator testing, validation, and internal release | Whether the result matches the original intent | Together, these systems create an end-to-end feedback loop https://arize.com/blog/from-human-operated-agent-development-to-systematic-agent-improvement/ . An agent can gather context, develop a plan, work across multiple repositories, create pull requests, launch mobile simulators, compare the resulting behavior against the specification, and then return the evidence to Slack. Instead of beginning with a diff, engineers can begin with a working build, a risk assessment, logs, and before-and-after recordings. Human review remains central for consequential changes, though. Coinbase operates in a regulated environment, and anything affecting the movement of money still receives thorough human testing and approval. Lower-risk changes can move through agent review councils, while engineers concentrate their attention on the places where failure would matter most. How to plan work for AI coding agents The first principle behind Coinbase Wallet’s workflow is simple: plan, don’t prompt . A prompt asks an agent to perform a task. A plan defines the outcome, constraints, implementation context, and evidence required to prove the work is complete. Chintan described the plan as a contract. When an implementation fails, engineers are encouraged to update that contract and rerun the workflow instead of opening an IDE and manually patching the code. Fixing the plan preserves the learning for future agent runs. A useful implementation plan should include: - The intended user outcome. - The current behavior that needs to change. - The repositories, services, or interfaces involved. - Explicit acceptance criteria. - Known edge cases and risk areas. - The tests, logs, screenshots, or recordings the agent must return. Spending twenty minutes clarifying these details can prevent hours of steering an agent through ambiguous requirements. It also creates a reusable artifact that multiple agents can execute against in parallel. Why AI coding agents need context, observability, and fast CI/CD “Let the agent cook” only works when the agent can observe what it is doing. Agents need access to the same operational evidence a developer would use: application logs, build output, test results, runtime behavior, design-system components, and production constraints. Without those inputs, generated code remains an unverified hypothesis. Coinbase’s verification workflow launches fleets of mobile simulators across different device configurations. The agents run the implementation, capture before-and-after videos, compare the behavior to the original specification, and report which cases passed or failed. When validation fails, the team updates the specification and runs the loop again. That is the same shape as evaluation-driven development https://arize.com/blog/evaluation-driven-development-ai-agents-production/ : specify the outcome, evaluate the result, then change the spec instead of patching by hand. This moves observability and evaluation https://arize.com/blog/improve-ai-agents-traces-evals-harness/ into the development process itself. The agent writes the implementation, observes its behavior, evaluates the result, and returns evidence that a human can assess. Production teams typically capture that evidence as traces and evals in Arize AX https://arize.com/products/ax/ . Chintan said improvements to the build and validation environment contributed to a 73% increase in pull requests merged without human implementation work. How agent-first development changes sprints, PRDs, and handoffs Agent-first development also forced Coinbase to reconsider the rituals surrounding software delivery. The team removed sprints, daily standups, project kickoffs, traditional PRDs, and Figma handoffs as mandatory stages. Work now begins with an idea or specification, moves quickly into a working prototype, and reaches internal users as soon as possible. Teams dogfood hundreds of prototypes, but only the ideas that demonstrate value earn the additional engineering and design work required for production. Copying that process wholesale would miss the larger lesson. Every team should audit its existing workflow against the bottlenecks that agents create. For each meeting, document, approval, or handoff, ask: - Does this step clarify product intent? - Does it give the agent necessary context? - Does it improve validation or reduce meaningful risk? - Does it help users evaluate working software sooner? Processes that satisfy none of these conditions may be preserving a constraint that no longer exists. Run a one-day roadmap compression test Chintan’s recommendation for engineering teams is to take the most ambitious item on the roadmap and try to build it in one day. The exercise is designed to expose constraints, even when the result never reaches production. Here’s a simple process to follow: - Choose an ambitious but bounded product outcome. - Write a detailed plan with acceptance criteria and validation requirements. - Execute the plan through agents without manually editing the generated code. - Require a working build and evidence that it behaves as intended. - Record every place where the workflow slows down or fails. At the end of the day, classify the bottlenecks. The agent may have lacked context, CI may have been too slow, the evaluation criteria may have been vague, the test environment may have been inaccessible, or the product idea itself may have been underspecified. Coinbase ran a more extreme version of this experiment by asking two engineers to rebuild its application in one week. They completed roughly 85 percent, but the final 15 percent kept the application out of production. Reliability, security, validation, and product judgment still determined whether the work was ready to ship. Agent-first engineering compresses the implementation phase so that humans can spend more attention on those decisions. Then, planning becomes the work. And sometimes, the most valuable place to begin is by deleting the processes that no longer serve the loop.