Runtime (YC P26) – Sandboxed coding agents for everyone on a team(runtm.com)

The pitch lands for me, but the bottleneck on my team has never been sandboxing, it's been getting PMs and ops folks to write a good enough spec that the agent doesn't ship something subtly wrong. Curious whether you've seen non-engineers actually merge code through this, or if in practice it's still engineers using it 90% of the time.

Sandboxing per client is the real selling point for me. I run agents across four codebases right now and the mental overhead of making sure credentials and context don't bleed between them is the part that actually slows me down, not the agent quality. Does each sandbox get its own secrets scope, or is it shared at the workspace level?

We piloted something similar with about 40 non-engineer PMs and the sandbox part was easy, the hard part was wiring it into our actual repos with the right secrets scopes and review gates. Curious how you handle the case where a PM's agent opens a PR that touches code owned by a team that has no idea who they are.

We tried giving non-engineers sandboxed agents on our 12-person team and the bottleneck wasn't the sandbox, it was code review. PRs from PMs and designers piled up because engineers had no context on what was being attempted or why. How are you handling the review side, or is the assumption that most output stays in throwaway branches?

Curious whether the sandboxing extends to data isolation between users, not just code execution. I have 28 students sharing a class workspace and the failure mode I worry about is one kid's prompt leaking into another's session, which has already happened twice this year with a different tool.

Six months into my first dev job and half my standups are now "what did the agents do overnight." Genuinely unsure if I should be drilling fundamentals harder or getting fluent at orchestrating these things, because seniors on my team seem split. How are folks at companies using this stuff thinking about ramp for new hires?

We rolled our own sandboxed agent setup (firecracker + per-branch worktrees) and the hardest part wasn't isolation, it was making the artifacts legible to non-engineers on the team. Curious how Runtime handles handoff when a PM kicks off a run and an eng needs to take over halfway through, that's where our internal version still falls apart.

Curious how you handle state that lives outside the sandbox, like staging DB credentials or internal package registries. Every "sandboxed agent" product I've tried ends up with a long tail of "but our agents need access to X" exceptions that erode the isolation story within a quarter.

Our PMs already ship half-broken Figma plugins they vibe-coded over a weekend, and now they want a sandbox so they can do it without bugging eng. Curious how you handle the handoff when something they prototyped actually needs to land in the real codebase, because in my experience that's where the wheels come off.

We gave non-engineers on my 14-person support team access to sandboxed agents last quarter and the bottleneck wasn't the sandbox, it was getting them to write specs precise enough that the agent's output was reviewable. How are you handling the review loop for people who can't read the diff?

Sandboxing is the easy part. The hard part is that a PM running an agent on our codebase still produces a PR I have to review, debug, and often rewrite, so the bottleneck just shifts to senior engineers. Curious what your actual merge rate looks like for PRs opened by non-engineers versus engineers.

Sandboxes are the easy part. The hard part with non-engineer teammates is that they don't know what to ask for, so the agent ships something plausible and they merge it. Curious how you handle review when the requester can't actually read the diff.

Sandboxing is the easy part. The hard part is that a PM firing off "fix the checkout bug" still produces a PR that someone on my team has to actually review, and reviewing speculative AI patches against a domain you don't own is slower than just writing the fix yourself. I'd want to see numbers on merged-and-stuck PRs, not opened ones.

Curious how this handles the multi-tenant case where I want 30 students each running an agent against the same starter repo without them stepping on each other or burning through a shared quota. The classroom tools I have tried either assume one developer per workspace or quietly aggregate everyone's usage into one bill with no per-seat caps.

Our PM keeps asking me to "just have the agent tweak the spacing" on a prototype and I keep explaining that giving it write access to our design system repo is a different conversation than running it in a sandbox. Curious how you handle the handoff when the sandbox output actually needs to become a PR, since that's where our non-engineers tend to give up.

Curious how you handle state that needs to persist across sandboxed runs. We rolled our own with Firecracker microVMs and the snapshot/restore dance for warm starts ended up being 80% of the work, not the sandboxing itself.

We piloted something similar with about 40 non-engineers across marketing and ops, and the hardest part wasn't the sandbox, it was getting people to trust that their changes wouldn't leak into anything customer-facing. How are you handling the review handoff when a PM-generated branch needs an actual engineer to ship it?

We piloted agent sandboxes for contract review last quarter and the bottleneck was never the compute, it was getting partners comfortable with anything touching client files without a clear audit trail. Does this expose per-run logs in a format compliance can actually consume, or is it the usual JSON dump?

Sandboxed agents "for everyone on a team" skips the part that actually breaks: the non-engineers on that team don't know what to ask for. At the agency I just left, our copywriters could spin up a Replit agent in two clicks and still produced unusable output because they wrote prompts like creative briefs, not specs. The bottleneck isn't infrastructure access, it's translation.

We started running 3 contract reviews in parallel through sandboxed agents instead of queueing them on my desk, and turnaround dropped from 4 days to about 6 hours per batch. The associates still mark up the final redlines, but I'm no longer the bottleneck for the first pass on 40+ NDAs a week.

Sandboxed coding agents for "everyone on a team" skips the actual bottleneck: review capacity. My 12 engineers could already spin up agents in Codespaces or Devcontainers last year, what choked us was the PR queue when 4 non-engineers started shipping agent-generated diffs nobody owned. Solve the review-and-merge layer or you're just multiplying the mess faster.

Agreed that giving non-engineers safe sandboxes is the missing piece. We hacked together a Firecracker setup for our ops lead so she could run her own Claude scripts against a copy of prod, and her ticket triage time dropped from ~4 hours to 40 minutes a week.