Most PMs can't touch production. Gus built a YC startup to change that.

Learnings from turning PMs into 10x product engineers

I’m excited to share a guest post from a person I’ve been lucky to work with in the last few months who has been helping more PMs get onboarded with Claude Code.

Today’s post is from Gus Trigos, founder of Runtime (YC). With his platform, Gus was able to unblock me within hours over the weekend, and we presented a live OpenClaw demo to hundreds of people the very next day. I’m super impressed by his ability to build an impressive YC backed startup (right after selling his last company), that solves a real problem for PMs and designers who just want to ship. Disclaimer: I am an investor in Runtime, but only because I’ve had this problem myself :)

I’m going to be sharing more real world posts like this from builders to help connect parts of the emerging agentic coding stack like compute environments (sandboxes), the harness layer + tools and more. Stay tuned!

Quick announcement: Eric Xiao and I are running a free lightning lesson on Friday at 9AM PT/12PM ET on how to get started with OpenClaw! The last one was a hit so we thought we’d run one again given how much has changed :) We’d love to see you there:

Now on to the post from Gus!

---

Six months ago, my first YC startup was acquired by a tech logistics company. I joined the acquirer as an AI Product Engineer, which meant I sat somewhere between the product and engineering teams. I’d been building with Cursor and Claude Code for two years at that point. In a few months I shipped four full products, end to end, using coding agents and not writing a single line of code. These weren’t prototypes. They had databases, auth flows, production environments, and most importantly real users getting transportation quotes, booking loads, and interacting with them on a daily basis.

I then set up to enable the rest of the team to ship at the same speed as I did.

The PMs, designers, and ops teammates understood the products better than I did. They had domain context in logistics I’d need months to build. Many of them had already tried Lovable or Replit on their own. But when I tried setting them up with the same local environments engineers were using, every attempt ended the same way: confusion with the terminal, docker, git conflicts, dependency hell, and agents not following best coding patterns.

A PM wanting to add a new input variable on the main product would create a lengthy PRD, and after approval, she’d send a slack notification with a Linear ticket to an engineer. One PM even mentioned they’d prioritize building up a good relationship with certain engineers so they’d prioritize their tickets.

I tried helping them cut this flow. The goal was to go from idea to a working product in as short of a time as possible. This meant then trying to turn a PM into a product engineer.

In adopting agentic coding, this is a pain every team I have spoken to has felt: it took a couple of hours of environment setup, and that’s assuming nothing broke along the way, which it did. Running the environment locally required a lot of RAM and memory, which would nuke some laptops. The PM had to clone the repo, install dependencies, set up environment variables, figure out which branch to work off of, and get the local dev server running. By the time the agent actually wrote the changes, the PM had already context-switched to something else.

This probably sounds very relatable, because it’s where most teams are today. The agent can write the code. The PM can describe what they want. But the gap between those two things and a pull request that’s safe to merge is filled with overhead like secrets management, environment setup, git workflows, deployment configs, MCPs, skills, and a dozen other things that have nothing to do with the actual change being made.

That gap is what pushed me to build Runtime.

Building Runtime

After a night out in CDMX, I returned to my hotel and read a bunch about sandboxes, observability, and coding agents. I woke up after a dream about what Runtime could be and grabbed my phone to jot everything down in my notes app before forgetting the details. That same day, I was on a flight back to SF and I couldn’t stop thinking about it. Architecture sketches, user flows, the long-term vision. How can someone go from idea to production and have software in the hands of customers? How would secrets work? What happens when two agents modify the same file? How do you get visibility into what every agent did? By the time I landed, I had enough to start building.

I locked-in in a cabin in Tahoe during the winter break shipping the first version nonstop. It was an open source CLI: it let your coding agents (cursor, claude code, codex, etc) deploy your app into a virtual machine (sandbox). You can think of sandboxes as a Mac Mini in the cloud. The agent could install packages, run servers, modify files, and if anything broke, you could threw away the sandbox.

I posted it on Hacker News on January 2nd. But there were only crickets.

But the handful of people who did try it gave me valuable feedback. Back then, people couldn’t understand why they’d let an agent deploy software on your behalf. It also quickly started to look like what I had built was a feature of a greater platform.

Second, the people who would benefit most from this (PMs, designers, marketers, support leads) weren’t going to open a terminal to use it. The CLI was a fine interface for engineers, but it recreated the same access barrier I was trying to remove.

So we added cloud sandboxes and built a web interface on top. Anyone could import a repo, prompt Claude Code or Codex in the browser, watch a live preview to ensure changes look as expected, and submit a PR. There was no terminal involved, no git commands, no environment configuration. That’s when users who had tons of ideas but weren’t used to building as an engineer actually started shipping.

One PM who’d never opened an IDE was submitting and merging PRs within a week. Runtime abstracted away the complexity and let her focus entirely on describing what she wanted. Setup time went from hours to minutes. She could spin up a sandbox and get a live preview of any codebase running in milliseconds.

To validate that we were heading in the right direction, we talked to over 40 CTOs and heads of product about how they were thinking about rolling out coding agents across their orgs. We kept running into two very different stances. On one end, leaders were already letting PMs ship PRs to their main codebases. On the other, they wouldn’t even let their own engineers use AI to code. Both positions made sense at the time given how fast the space is moving and how few established best practices exist. One CTO told me he’d love to let his product team ship PRs instead of PRDs, but couldn’t justify the risk of leaked secrets or having more technical debt. Another CPO said her whole org was already vibe coding in some way or another, but she had no visibility into what was being shipped.

With those learnings, we iterated toward the current version of Runtime: a mission control for coding agents. At its core, Runtime lets you set up sandboxed sessions with coding agents that follow your team’s best practices. Anyone on the team can spin up a live environment with all the integrations, secrets, dependencies, and skills required to build great products. On top of that, we invested heavily in the auditing that lets engineering leaders have visibility on what did each agent do and how much it costed. And the key part is we made Runtime accessible through multiple interfaces, whether it is through our web UI, Slack, Linear, Github, or APIs.

The framing that resonated most with engineering and product leaders was this: instead of gatekeeping productivity of your team by saying no, you enable them by setting up one shared workspace with your company’s best practices.

Around the same time, some of the best engineering orgs in the world started publishing what they’d built internally. Ramp wrote about how Inspect, their internal system, now accounts for more than 30% of their merged PRs. Stripe built Minions. Harvey built Spectre. And so did other companies like Spotify and Block.

They all arrived at the same conclusion from different angles. You need a way to manage agents before you can safely expand access to them. And they all built it in-house with dedicated platform teams, because nothing existed off the shelf.

We got into Y Combinator in early March. And today we’re working with companies from Series A to a unicorn, across use cases that range from using Runtime as an alternative to Cursor or Lovable to calling it directly from Slack for answering and fixing support questions.

What actually changes when you do this

The product iterations matter, but the part I care about most is what happens on the other side. What does it actually look like when everyone on your team becomes a builder?

There’s a PM I worked with who used to file tickets for small tweaks on one of our main repos. Things like updating a button label, fixing a typo in an error message, or rewording a dashboard status. Each ticket would sit in the backlog for three to five days because engineers had higher-priority work. That was totally reasonable from a prioritization standpoint, but it meant a change that should take five minutes end to end was taking a full week.

With Runtime, that same PM submitted a PR in about 5 minutes. They tagged Runtime from slack and would ask it to add the changes. Runtime orchestrated a sandbox with an agent, implemented the changes, ran tests, and generated a preview back to showcase its work. An engineer reviewed the PR and approved it in five minutes instead of building it from scratch. The total cycle went from days to under an hour.

This loop works for designers too. A designer on another team started prototyping UI changes directly in the production codebase instead of mocking them up in Figma. The conversation with engineering shifted from “here’s what I want” to “here’s a working version, what do you think.” That’s a much faster feedback loop. The designer can iterate in minutes instead of going through another round of mockup-to-spec-to-implementation. And the engineer gets a concrete starting point.

When you zoom out, as more team members start shipping their own PRs, engineering shifts from being the execution bottleneck to being the quality gate. Engineers spend less time on routine implementation and more time on architecture, code review, and harder problems that agents still can’t solve effectively. The net effect is that total team throughput goes up. Specifically because the work is distributed to the people closest to the problem.

This is where the conversation about AI and product teams gets interesting to me. Most of the discourse right now is framed around whether AI will replace human builders. I think the more immediate shift is that AI lets more people across the team do things that previously required many engineers. That in turn frees engineers up to focus on the work that actually needs engineering judgment. Nobody loses their job. The team just becomes a lot more effective because the operational bottleneck moves upstream.

The gap between “I have Claude Code on my laptop” and “I can safely contribute to production” turns out to be almost entirely an operational problem. The models are already good enough. The infrastructure around them isn’t.

There’s a joke in Silicon Valley that PMs exist because engineers are too lazy to talk to customers, and engineers exist because PMs are too lazy to learn to code. Coding agents are blurring that line, but only if the infrastructure lets them. Right now, for most teams, it doesn’t.

Where this goes

The cost of going from idea to production is collapsing toward zero. Every company I talk to has a backlog of things they’d build if engineering capacity were infinite. As agents close the gap between intent and execution, that backlog starts to move, and the scarce resource stops being implementation. It becomes knowing what to build, how it should behave, and whether it holds up alongside everything else your team has shipped.

The best PMs I’ve worked with already think like builders. They’ve just been blocked by a translation layer that takes weeks to clear. Once that layer thins out, the feedback loop between having an idea and watching real users interact with it collapses from weeks to hours. Product work stops being “write the spec, hand it off, wait” and starts being “try it, see how it behaves, iterate.”

Getting started

If you want to try this yourself, start small. Aman’s Personal OS and skills system is a good place to begin. Get comfortable prompting on your own projects first so you can build up the muscle memory and learn what agents are good at and where they fall apart. From there, try building a side project end to end with a coding agent. You’ll run into the same environment and deployment problems I described earlier, and that firsthand experience will make you a much more effective user once you have a tool that removes those problems for you. Those same patterns translate directly into tools like Runtime when you’re ready to start working in a production codebase and collaborating with your team.

I built Runtime because I wore both hats and wanted to give my teammates the same tools I had. We’re in YC’s current batch and working directly with early customers to shape the product. If you want to try it, you can find us at runtm.com. And if you just want to talk about how your team is thinking about increasing product throughput, connect with me. Would love to chat.

Back to building.

---

This is actually a good time to let you know that we are running another Claude Code for PMs Cohort! This is Cohort 3, and we’ve been able to manage and maintain a perfect five-star ⭐⭐⭐⭐ rating through the last two cohorts. This cohort an opportunity for you to up level yourself and your org in using coding agent tools to manage context and get real work done. If you’re interested, check it out and let me know if you have questions.

Notes

[1]: Ramp open-sourced the spec for Inspect in January 2026, with about 30% of merged PRs coming from it. Stripe built Minions, Harvey built Spectre, and Spotify disclosed background agents running against their codebases. Anthropic began running managed agents internally as well.