Case Study How Laurel brings production-ready validation to AI-native development while cutting change failure rate by 82%
Laurel logo

How Laurel Brings Production‑Ready Validation to AI‑Native Development

Laurel, a leading AI-native company building AI timekeeping and work intelligence software for professional services, faced a validation problem most engineering organizations will meet soon enough: coding agents were authoring an ever-larger share of its code, and every one of those changes needed production-grade validation before merge, without code or customer data leaving Laurel’s own cloud.

Across a team of approximately 60 engineers, agents now author 76% of Laurel’s engineering pull requests, and the team merges about 9 PRs per engineer per week. With a rising volume of code changes moving through the pipeline, Laurel needed a dependable way to validate multi-service changes with production-like fidelity before they merged.

Two constraints made the usual options hard. Laurel’s previous approach, using Vercel preview environments, could not accurately replicate the full application stack and production infrastructure, which caused regular issues. And because many of Laurel’s clients are law and accounting firms, sending code or customer data to an external vendor’s cloud meant subprocessor reviews and compliance friction the team wanted to avoid.

With Signadot, automation owned by Laurel’s infrastructure team stands up per-PR sandboxes directly on its own Amazon EKS cluster, managed with infrastructure as code and GitOps, and never leaving Laurel’s AWS account. Demand for this capability was high and the configuration work was light, so adoption at Laurel has been fast.

Agent-Authored PRs
76%
up from 55% three months earlier
Change Failure Rate
−82%
1.1% → 0.2%
Throughput
9 PRs
merged per engineer, per week, across ~60 engineers

The Challenge: Validating a Flood of AI-Generated Changes, Without Leaving Their Own Cloud

Laurel runs a Kubernetes stack on Amazon EKS: roughly 40 backend services (mostly Node.js, with some Python services for data enrichment) plus a single front-end monorepo of four services, which is its largest Signadot use case. Data lives in MongoDB Atlas and Postgres on AWS Aurora, messaging runs on Kafka, and observability is OpenTelemetry-based. The team runs no service mesh.

The demand for validation came from three directions at once: engineers wanting to spin up a change and preview it manually, a push to run automated end-to-end tests in CI, and, most importantly, a need to give coding agents a tight, realistic validation loop. As a frontier AI-native engineering team, Laurel was generating more change than a divergent preview setup could safely absorb.

“We were using Vercel for preview environments, and it was just different enough from our production, staging and development environments that it caused regular issues.” Naomi Klein · Lead Infrastructure Engineer, Laurel

The deeper issue was where that validation could run. Serving law and accounting firms, Laurel keeps customer data inside its own AWS environment wherever possible, and every external vendor that touches that data is another subprocessor conversation the team would rather avoid. So the selection criteria were strict: run inside their own AWS, work with GitOps, and build directly off their own development Kubernetes cluster. Signadot met all three, which made it the only obvious choice.

The Solution: Per-PR Sandboxes on Their Own EKS Cluster

Instead of duplicating environments, Signadot forks only the changed services into a sandbox, a lightweight ephemeral environment, and uses routing keys to send the relevant traffic to them, while every other dependency is served by a stable shared environment, all running in Laurel’s own cluster. Sandboxes are provisioned per pull request, and everything runs on their EKS cluster, owned by the infrastructure team and provisioned using the same GitOps, infrastructure-as-code approach as the rest of their platform.

Laurel's AWS account
dev EKS cluster · GitOps managed
PR #241
PR #242
+ every PR
changed services only · routed by routing key via DevMesh
stable shared environment · every other service
No code or customer data leaves Laurel's AWS account

Because Laurel hasn’t adopted a service mesh, Signadot’s DevMesh filled that gap directly. To coordinate changes that span multiple repositories, the team ties a routing key to each Linear ticket, so a single key can bring up matching sandboxes across the front-end monorepo and the backend services a change touches.

“We regularly create Signadot environments on every PR for almost every microservice. Our engineers can build and test changes across multiple services directly on top of our development environment, both locally and through our CI tooling.” Naomi Klein · Lead Infrastructure Engineer, Laurel

Testing and Coding Agents on the Same Path

Two of Laurel’s biggest use cases run on this foundation. On the testing side, Laurel rebuilt its E2E suite on Signadot, carrying over some parts of its existing Playwright logic, using Signadot’s Smart Tests and routing keys.

“We have built a new suite for end-to-end testing on top of Signadot, work that would have been significantly more complex beforehand. Multiple engineers have discussed how Signadot helped significantly in uncovering bugs in their changes or in validating their features.” Naomi Klein · Lead Infrastructure Engineer, Laurel

On the agentic side, Laurel is seeing an influx of fully AI-generated PRs alongside AI-assisted and human-written ones. Because every PR gets its own production-like sandbox automatically, all three go through the same validation path. The coding agents, Claude Code, Codex, and others, wired in through Laurel’s own CLI tooling and AI skills, get the same isolated, realistic environment a human engineer would. That is the point: one place to validate a change, whoever or whatever wrote it.

engineerengineer + AIcoding agentsClaude Code · Codexpull requestper-PR sandboxon Laurel's EKSmanual previewPlaywright e2e suiterun as Smart Testsmerge · 0.2% change failure rate
Every change, human- or agent-written, gets the same per-PR sandbox and the same validation before merge.
engineerengineer + AIcoding agents · Claude Code · Codexpull requestper-PR sandboxon Laurel's EKSmanual previewPlaywright e2e suite · Smart Testsmerge · 0.2% change failure rate
Every change, human- or agent-written, gets the same per-PR sandbox and the same validation before merge.

The Results: More AI-Written Code, Fewer Failures

The qualitative wins landed first: easier end-to-end testing, a new test suite built on Signadot, and engineers catching bugs and validating features earlier than they could before. The numbers now back them up.

For context on the scale Signadot now supports: over a recent 30-day window, Laurel’s team of roughly 60 engineers merged 2,873 pull requests. Setting aside automation traffic, about 20% of the total, that is roughly 2,300 engineering PRs: 538 per week, or about 9 merged PRs per engineer, per week.

Metric
Before
After
Change
Agent-authored engineering PRs
55%
76%
+21 pts
Change Failure Rate
1.1%
0.2%
82% reduction

The change failure rate is what makes the throughput credible. Over the same three months in which the agent-authored share of engineering PRs climbed from 55% to 76%, change failure rate did not just hold under the added volume. It fell from 1.1% to 0.2%. That was the whole point of the investment: push a higher volume of increasingly AI-generated changes without a matching rise in incidents. Laurel is shipping more AI-written code and breaking production less.

Conclusion

For an AI-native team carrying the compliance obligations of serving law and accounting firms, Signadot gave Laurel what the other options couldn’t: production-grade validation it could own and run entirely inside its own AWS and Kubernetes, scaling per PR, covering nearly every microservice in its most critical repos, and providing a single validation surface for both engineers and coding agents.

“Signadot is making it easier for our developers to build and test microservices using deployments that are incredibly similar to production. This has made both human and AI-written code easier to validate and test.” Naomi Klein · Lead Infrastructure Engineer, Laurel

To see how Signadot can help your team ship safer agent-written code at scale, sign up for free or book a demo.

Stay in the loop

Get the latest updates from Signadot

Validate code as fast as agents write it.