A product pivot rarely starts with a slide. It usually starts with a complaint that will not go away.
For Stitch, the complaint was latency. Even when v1 worked perfectly, the feedback cycle was still a pipeline round trip. We dressed it up, we documented it, we made peace with it. Users did not. The people who tried Stitch and liked it still pushed the same question back at us: why am I waiting for my CI to find a missing import when I could have run the same linter in one second on my machine?
The answer we kept giving ourselves was “because the agent needs the CI environment.” The honest answer, once we wrote it down, was “because we decided the agent should live there.” Those are not the same thing.
The observation
Developers are already running AI agents locally. Claude Code sits inside the terminal. Codex does too. Both are authenticated, both are configured, both already have access to the repository the developer is currently editing.
None of that is in the CI environment. To get it there, you have to rebuild a subset of it, badly. API keys, image registries, cached dependencies, mounted secrets. All to approximate, on a runner, a thing the developer already has sitting in front of them.
The shift, when we finally said it out loud, was embarrassingly simple. Stop building the agent into the pipeline. Run the pipeline locally, next to the agent the developer already owns. Let them talk directly.
What this unlocks
Once you say “Stitch runs locally,” a lot of v1’s problems stop being problems.
Latency collapses. Jobs run on the same machine as the editor. A lint job that used to wait ninety seconds for a queued runner runs in half a second. The fix that used to take three pipeline cycles to verify takes three local runs. Feedback measured in seconds, not minutes.
API keys disappear. The agent is already authenticated through the developer’s Claude Code or Codex subscription. Stitch does not need its own key, does not store one, does not ask for one. Onboarding is npx stitch-agent run claude and that is the whole thing.
Your existing CI config is the config. There is nothing to add to .gitlab-ci.yml or .github/workflows/*.yml. Stitch reads the file you already wrote and runs the same jobs on your machine. The pipeline you keep in your repo stays the source of truth.
Infrastructure jobs stay remote. Deploys, publishes, image pushes, none of that should run on a laptop. v2 detects those by job name and skips them. You get local execution for the verify jobs, your CI keeps the infra jobs. Nothing duplicated, nothing broken.
Privacy stops being a sales slide. Local execution means your logs, your source, your fixes never leave the machine unless you configure a notification channel that sends them somewhere. There is no Stitch backend to leak anything through because there is no Stitch backend.
What this constrains
Local-first is not a free win. It means Stitch runs where your tools run. If your CI requires a specific Docker image to compile a binary, your local machine needs to be able to do the same thing, or the job cannot be verified locally. In practice this is fine for typical language toolchains and painful for exotic build environments.
It also means Stitch is a per-developer tool, not a team service. There is no shared dashboard, no org-wide metrics, no central control plane. That is a deliberate trade. The trade is “your CI, your machine, your agent, your pace.” If what you want is a managed fix-on-merge service, Stitch is not the shape for you.
The second insight
The smaller, quieter insight that came out of this pivot was about who Stitch is for.
v1 kept assuming a team with a pipeline budget. v2 works just as well for a solo developer on a weekend project. The code does not care. The same npx command, the same agent-in-a-terminal experience, the same zero config. We had been optimizing for the customer we wished we had instead of the developer we kept watching try Stitch and bounce off.
Local-first made the product accessible to anyone who already had a repo and an agent. Which, increasingly, is everyone.
The next post is a smaller, more technical one: a classifier we spent three months building and then deleted in an afternoon.