Custom local dev CLI

We run a large, sprawling set of services, and getting them all running locally was a slog. Local setup was app-specific, so to run the full stack, you had to stand up several environments, keep 5+ processes alive, and hope nothing broke along the way. Putting each service in its own container wouldn’t have helped because machines would run out of memory.

So we built a CLI tool that uses devbox to inject dependencies, which keeps startup times fast and less resource-intensive than Docker. It lets engineers run our large infrastructure locally with one command, so the full stack comes up in 28 seconds.

Faster CI

Our frontend CI had been creeping up for years and began approaching 30 minutes. We tackled it in three ways:

• Build only what changed. We leaned into our Turborepo monorepo setup with affected-based builds, so CI only touches the packages that a change actually impacts rather than rebuilding everything. We also compiled packages so their outputs could be cached and reused, and paired that with TypeScript isolated declarations so type info is emitted per package without cross-package dependencies. Together, this gave us more cache hits, more parallelism, and fewer redundant rebuilds.
• Trade JavaScript tooling for Rust and Go. The single biggest lever was replacing our JS-based toolchain with native equivalents. Nearly every tool got roughly an order of magnitude faster.
  See the full toolchain

  • TypeScript type checking: tsc → tsgo (~10x faster)
  • Linting: ESLint → oxlint (~10x faster)
  • Formatting: Prettier → oxfmt (~10x faster)
  • Bundling libraries: tsc builds → tsdown (~10x faster)
  • Bundling apps: esbuild → rolldown (~2–3x faster)
  • Testing: Jest → Vitest + fixed flaky tests (~50% faster)
• Parallelize the pipeline itself. We restructured the CI pipeline to run independent stages concurrently rather than in sequence, squeezing out the remaining wall-clock time that faster tools alone couldn’t recover.

A pipeline that once ran at 30 minutes now finishes at a fraction of that time, with most changes clearing CI before an engineer has finished writing their PR description.

Automated legacy migrations

We pointed agents at the patterns that confused them most and let them run the migrations themselves. The largest migration was three competing design systems in one codebase: Ant Design, in-house Cerulean, and core-ui (Radix UI + CVA + Tailwind). We’re deprecating the first two and standardizing on core-ui. We did the same with i18n, reducing three translation systems into one. Then we codified the changes as agent rules and skills that are backed by lint checks, so agents (and engineers) don’t drift back into old patterns. These were migrations we’d written off for years, but agents finally made them possible.

Agent-generated code

Like most orgs, our engineers shifted from writing code by hand to steering Cursor, Codex, and Claude Code agents. Nearly all frontend code and most backend code is now agent-generated.

CI as our new dev environment

Once frontend CI dropped below 5 minutes, working locally was no longer the fast option. Engineers now push a branch, let CI run, and review it in GitHub. The CI went from the gate you clear after you build something to the new dev environment for most engineers.

This lets engineers parallelize their work. Because it runs in the cloud, they aren’t limited to one change at a time. They can kick off 20 PRs before logging off and review them the next morning. The only limit is knowing what to build, which is why a migration might hit 100 PRs, while feature development stays around 1 to 3.

Frontend previews

For a frontend change, we can add a label to the PR, and GitHub Actions builds the assets, pushes them to S3, and our frontend server loads them as a working copy of the app. It comes with dev tools to flip feature flags and settings, and a deep verification link that takes you straight to the page your change affects. The preview is ready in 30 seconds to 5 minutes, and checking a change takes 2 to 5 minutes of click-through with no local setup needed.

Backend ephemerals

Backend changes get validated through ephemerals. Add a label to a PR, and GitHub Actions spins up a throwaway copy of the full stack in the cloud with Argo. An engineer or an agent can then hit the APIs or run the feature end-to-end before it merges. It’s 2–3x faster than it used to be.

Automated code review

We use Cursor’s Bugbot on every PR in CI. It comes out of the box, and we add context when it misses things. So far, it catches bugs that most humans used to let through. Even though we’ve tripled the PRs we ship, bug reports have fallen by more than half (from 715 a month to 319), and high-priority issue reports have also dropped. More code hasn’t meant worse code, and Bugbot is a large reason why.

Risk-based auto-approval

We introduced a risk model that scores each change on size, scope, what part of the codebase it touches, test coverage, and whether it modifies public APIs or data models. If a change is low-risk and review comments are resolved, it merges on its own without a human in the loop. When someone catches a change that shouldn’t have merged, it goes into an eval suite, and we tune the risk model to prevent it from happening again.

SOC2 compliance

How does auto-approval pass a SOC2 audit? Turns out, SOC2 doesn’t need a human to click approve. What it does need is demonstrable controls: documented criteria, logged decisions, and a way to override. So we documented all of it, including what qualifies for auto-approval, what still needs a human, and how to escalate. Approval and validation are logged as separate signals, so every decision can be audited after the fact. We brought compliance in early so we didn’t have to redesign it later.

Start with the leaders

Leader ambition can be one of the biggest drags on organizational velocity. You can’t ask engineers to hand their work to an agent if their own leaders won’t. So we made them go first, literally. Amplitude’s chief engineering officer asked senior leaders to vibe code in front of the entire engineering, product, and design org. Leaders experienced the highs and lows of agentic building (and breaking) live on stage. They then took that live-coding exercise back to their own teams to repeat it. This made it feel like leaders were co-developing with their teams, rather than simply talking at them.

Let anyone ship

The biggest positive was handing over the keys to the kingdom and letting non-engineers ship code. Designers, PMs, and even marketers use Claude and Cursor to ship anything from bug fixes to product improvements. Non-engineers make up about 5% of our PRs, but they’re high-value changes, and that number continues to grow.

The best part is that these changes happen much faster because there’s no more handoff to eng. And the fixes are often better because the person closest to the problem makes the fix. Jingshu Zhao, one of our principal designers, started with a small PR to address a button alignment issue. Soon after, she used Claude Code to reorganize our navigation and sunset sections with low usage. It was a change the broader team wanted to make but was never able to prioritize, so she did it herself.

Jingshu’s changes go beyond the UI. While testing our agent-creation templates, she noticed the agents were guessing instead of asking, like picking a funnel name on their own instead of asking which one the user meant. She used Claude Code to trace it across both the template and tool definitions, and shipped consistent fixes across every template.

Getting non-engineers to code was only possible with the setup, validation, and review changes we made to our software factory. Standing up the whole stack only takes 10 to 15 minutes (down from 1 to 4 days), so there’s no barrier to getting started. Preview links let them check a change without running anything locally, and each PR deep-links to the exact page that changed, so verification is only a short click-through.

Our advice for getting non-engineers on board is to make it wildly easy for them. That means strong documentation and training on things like first-time setup and choosing an environment. We also have an internal marketplace for shared skills that anyone can access.

Spend where it counts

We don’t cap what people spend on AI. If anything, we encourage more of it. But we’ve also learned that the model you pick matters just as much as how you run it, so we pay attention to high bills and see whether a lighter model would work. A less expensive model lets you run two or three times as much with the same budget, so you aren’t limited on how much you can justify doing. We recently refactored a major backend to have proper typings for only $500. We used a cheaper model and a well-planned script that was run locally. That same work could have easily cost tens of thousands of dollars. So our guidance is to not feel constrained by tokens, but also to choose the right model for the job.

It’s never perfect

We made some mistakes early on (and will make more…). The first was spreading the effort too thinly across the org (the peanut butter approach). We eventually shifted to a tiger team model and embedded AI-pilled engineers across teams to share their knowledge.

Another mistake was trying to bite off more than we could chew and build agents before we had any of the infrastructure in place. But there was no need for us to jump to the end. Prioritizing our foundational DevEx is what ultimately helped us move faster.