Making AI Coding Agents Production-Ready

The situation

An early-stage startup was building a platform where AI agents could run code on arbitrary codebases. The idea was sound, the product vision was clear, and the team was strong. What they needed was the infrastructure to actually make it work.

Sandbox execution. CI/CD pipelines. A security model. An orchestration layer that could take any repository a developer pointed at and make it ready for an agent to run code against. None of that existed yet.

They brought us in to build it.

The bottleneck

The sandbox tooling itself was a solved problem. E2B handles isolated execution well, and after evaluating the alternatives we were confident it was the right choice. Spin up an environment, run code, tear it down. That part works.

The gap was everything around it.

Getting a real codebase running inside a sandbox is not just a matter of cloning a repo and hitting run. Real projects have dependencies. Build systems. Configuration quirks. Assumptions baked in about the environment. npm, vite, webpack, uvx, Python wheels, installers that expect things to be in specific places. Demo repos are clean. Production codebases are not.

The team had something that worked on the repos they controlled. They needed something that worked on the repos their customers brought.

What we built

We designed the full infrastructure architecture from scratch. Sandbox tooling with E2B, CI/CD pipelines and automation for onboarding any codebase without manual intervention, and a security model that held up to scrutiny.

The orchestration layer was the more substantial part of the work. We built the GitHub Apps integration that let the platform trigger actions, capture events, and respond to repository activity. We built the setup logic that could detect what a codebase needed and get it running inside E2B reliably, across the full range of package managers and build tools that real-world projects actually use.

We worked alongside their existing engineering team throughout, part staff augmentation, part advisory. The goal was always to leave them owning the system, not dependent on us.

The real challenge

The sandbox spins up fast. The hard part is what happens before the agent runs a single line of code.

Every codebase makes different assumptions. A Python project might rely on a specific version of a package that conflicts with something else. A JavaScript monorepo might have a workspace setup that breaks standard install commands. A project built on vite expects a certain directory structure that uvx doesn’t know to create. These aren’t edge cases. They’re the normal texture of real software that real teams have been building for years.

We spent significant time on the setup layer: detecting what each codebase needed, handling failures gracefully, building fallback paths for common breakage patterns. The logic that looks straightforward in isolation gets complicated fast when you have to support every combination of toolchain a developer might bring.

GitHub Apps integration added its own complexity. Managing app installations, handling webhook events reliably, making sure actions triggered correctly across different repository configurations. Each piece worked. Getting them to work together without fragile assumptions took care.

The outcome

The platform moved from zero to working. That was the first milestone and it mattered.

The more meaningful shift was the second one. The platform went from working on controlled demo repositories to working on arbitrary, real-world, messy codebases that their customers actually used. That’s the version of the product that can ship. That’s what production-ready means in this space.

The infrastructure is built to scale. Any codebase can be onboarded without manual intervention. The security model is defined. The pipelines run. The team owns it.

What started as “we need sandbox infrastructure” became a platform that holds up when real developers point real projects at it.