Lark solves a new type of problem in the industry: AI coding agents write code faster than anyone can verify it works. Lark is an AI test engineer. It maps out a customer's product and workflows, writes a full suite of end-to-end tests, and keeps running them as the product changes. Customers run hundreds of these tests at once, and the load is spiky by nature: when a wave of pull requests merge at the same time, test volume spikes with it. Each test runs in its own sandbox against the customer's application, sometimes even with real customer data and credentials in play.
That latter part is what makes the infrastructure hard. Lark is running agents against customer systems, and the isolation between test runs has to hold every single time.
Testing Customer Environments
Lark's agents generate and execute test cases. This means launching browsers, calling APIs, running scripts, and validating actual user flows, then producing artifacts like screenshots and logs attached to tests. Early versions of the product ran this workflow on local dev machines and traditional CI runners. That worked until Lark's agents needed to run arbitrary workflows autonomously, at which point the team needed a secure environment to execute the code in.
Isolation Is Essential on Sensitive Data
Lark has to work within any customer's system — in live environments with user data and production credentials in reach. That raises the stakes on isolation. Every customer test needed to run in its own ephemeral environment, spin up clean, execute, and disappear, with zero chance of one run seeing another's data.
“They're testing their live environments with real customer data or real API keys, and so everything has to be securely isolated. We don't want an agent in one sandbox to be peeping into another sandbox. It's crucial to the security of our product.”
Docker Support Narrowed the Field Fast
Lark's tests sometimes need to spin up a customer's own development environment inside the sandbox to validate against it, which requires them to run Docker containers within the sandbox itself. That requirement ruled out most providers before the evaluation really started: most sandbox providers isolate agents using containers, and running Docker inside a container usually means either privileged mode, which breaks isolation, or no way to run it at all, since the sandbox doesn't expose the kernel features Docker needs to function.
“We did some cross-shopping with E2B and some other sandbox providers, but one of the things that stood out was that E2B allows you to run Docker containers within the sandbox, which is really important to us because we're actually testing our customers' development environments.”
Custom Templates Ready for an Agent to Test
A developer describes what they want tested in natural language, and Lark turns the request into an execution plan. It then spins up an isolated E2B sandbox from a custom template with the full testing environment already baked in, including browsers, testing frameworks, Python, and other language runtimes. Because dependencies do not need to be installed for every run, tests can start quickly and results return without disrupting the user experience.
To keep work and results flowing between its platform and each sandbox, Lark built an open-source project, runtimeuse. It handles bidirectional communication, pushing tests into the sandbox and streaming results back to Lark in real time so users can watch them execute. Once the test is complete, the sandbox is destroyed.
“Having the execution layer that E2B provides is a layer of infra we don't have to worry about. Everything is pretty streamlined once you hook that up to the Kubernetes tools on our side.”
Built for Running Tests Across the Whole Codebase
Lark is designed for many test executions running at once, particularly around CI pipelines, pull requests, and large batch validation jobs. That load spikes hard during active development hours and around large releases, which are the moments when a team most needs its tests to run. Having E2B handle sandbox provisioning meant Lark didn't have to build its own capacity planning for the burst traffic, letting them spin up thousands of concurrent sandboxes seamlessly.
Docker-in-Sandbox, Without Building It Themselves
Running Docker containers inside sandboxes limits the field to a handful of providers, and E2B's MicroVM isolation meant Lark didn't have to build and operate that isolation layer on its own, saving them at least several weeks of building out their own sandbox infrastructure.
“E2B has been a tried and true option. I would recommend them, especially against building anything yourself.”
Looking Ahead
As AI coding agents write more code, more of it will need to be continuously tested. Lark expects both its customer base and sandbox usage to grow, including among larger organizations with stringent data and security requirements. As it scales, the team plans to continue relying on E2B as its tried-and-true infrastructure for testing agents.