Harvey Built a Software Factory. You Can Too.
Harvey AI - the 11B company - just revealed the infrastructure every AI-powered team will need. Here's why you don't have to build it yourself.
Last week, Harvey AI - the $11B legal AI company - published a detailed technical blog about their internal platform for running coding agents in the cloud. It’s one of the most honest pieces of engineering writing I’ve read this year.
The core insight is deceptively simple:
“Local coding agents break down at the organizational boundary.”
If you’ve ever used Cursor, Claude Code, or Copilot on a team of more than one person, you already know this is true. You just might not have had the words for it yet.
The Laptop Problem
Here’s what happens today at most companies using AI coding agents:
An engineer opens their laptop. They spin up an agent. The agent writes code, creates a branch, maybe even opens a PR. It’s fast. It’s impressive. It works.
Then a second engineer asks: “What did the agent do?” And the answer is... go read the diff? Check Slack? Hope someone wrote it down?
The agent ran on one person’s machine, with that person’s credentials, in that person’s terminal. There’s no shared record. No audit trail. No way for a PM to see what happened without interrupting someone. No way to hand off a half-finished task without re-explaining all the context.
Harvey’s engineering team called this out directly. Desktop agents inherit ambient access to SSH keys, browser sessions, and local files. Security analysis becomes nearly impossible. Collaboration becomes a game of copy-paste and screen shares. This is fine for a solo developer. It’s a disaster for a team.
What Harvey Built
Spectre solves this with five architectural decisions that I think will become standard for any serious engineering organization:
1. Durable runs, not ephemeral sessions. In Spectre, the run record — not the worker process — is the primary object. If a worker crashes, the run survives. If someone wants to follow up on a task from last week, they pick up the same run. This works whether the request came from Slack, a web app, or a cron job.
2. Sandboxed execution. Every agent runs in an isolated environment with scoped access. Repository access is temporary. Tool configuration is injected at startup. When the run ends, the capabilities disappear. Harvey’s framing: “make the worker powerful inside the sandbox and strictly define the boundary.”
3. A harness layer. The gap between “a model that can use tools” and a functioning system is enormous. Spectre’s harness assembles context, manages provider adapters, translates events into stable formats, handles cost accounting, and enforces execution states. This is the unsexy infrastructure that makes everything else possible.
4. Collaboration as a runtime feature. Slack threads, web dashboards, PR comments — these aren’t separate integrations bolted on after the fact. They’re surfaces into the same durable run. An engineer starts a task in Slack. A PM checks progress on the web. A reviewer sees the output in a PR. Same run. Same context. No re-explaining.
5. Scheduled runs on the same rails. Automated cleanup passes, test suites, and verification loops use the identical infrastructure as interactive work. No shadow systems. Everything is visible and reviewable.
This is exactly what we are building at LightSprint.
The Pattern Is Everywhere
Harvey isn’t alone. Look around:
Stripe published their one-shot coding agents producing over 1,000 pull requests per week. They built custom infrastructure for feedback loops, testing, and guardrails.
Ramp built this rather than using off-the-shelf local agents. Same conclusion: local agents don’t scale to teams. Junaid Rahim’s essay on laid out the theoretical framing months ago — software production is becoming factory-like orchestration, and the tooling hasn’t caught up.
The pattern is clear. Every engineering organization that gets serious about AI agents ends up building the same infrastructure: sandboxed execution, durable task records, shared visibility, multi-provider support, and automated pipelines.
It’s the CI/CD moment all over again. In 2012, every serious team was building their own continuous integration pipelines. Then GitHub Actions, CircleCI, and GitLab CI turned it into a commodity. The teams that built their own CI weren’t wrong — they were early. But eventually, build-vs-buy tilted decisively toward buy. We’re at that same inflection point for agent infrastructure.
The Build-vs-Buy Question
Harvey can afford to build Spectre internally. They have hundreds of engineers and billions in valuation. The ROI on custom infrastructure makes sense at their scale.
But most companies aren’t Harvey.
Most startups have 2-10 engineers. Most agencies have designers and PMs who need visibility into what agents are doing but can’t read terminal output. Most non-technical founders (and I talk to these people every day) are using Claude Code or Cursor alone on their laptops, hitting exactly the ceiling Harvey described, with no engineering team to build a Spectre of their own.
This is why we built LightSprint.
LightSprint is the product version of what Harvey built internally. A collaborative platform where AI coding agents run in the cloud, tied to a shared task board, with preview environments for every PR and real-time visibility for the entire team.
The architectural parallels aren’t a coincidence — they’re convergent evolution. When you solve the problem of “how do teams work with AI agents,” you end up in the same place:
Durable tasks instead of ephemeral terminal sessions
Cloud sandboxes instead of laptop-bound execution
Shared surfaces (task board, previews, reviews) instead of private terminals
Multi-provider support (Claude, Codex, Cursor) instead of vendor lock-in
Automated pipelines on the same infrastructure as interactive work
Harvey built this for Harvey. We’re building it for everyone.
What This Means For Your Team
If you’re a technical founder running agents locally and feeling the friction of coordination — you’re not doing it wrong. You’ve just outgrown the tools.
If you’re a non-technical founder using AI to build your product and struggling to get visibility into what’s happening - the problem isn’t you. The problem is that coding agents were designed for individual developers, not teams.
If you’re an engineering leader watching your team spin up agents on their laptops with no audit trail, no shared context, and no way to hand off work - Harvey just validated that this is a real problem worth solving.
The software factory isn’t a metaphor anymore. It’s an architecture. Harvey proved it works. The only question is whether you build it yourself or use something off the shelf.
We are building LightSprint to democratize access to software factories. Reach out to benong@lightsprint.ai if you would like to chat more about how software factories can increase the engineering velocity for your organization.