When everyone ships code, who owns production?
The rise of the builder mindset and its implications for engineering teams
Great engineering managers don’t just ship—they build organizations capable of shipping. But that meta-skill is rarely named, let alone taught.
Our book Engineering Manager’s Compass focuses on the unspoken rules of the role: how to read organizational structures, how to turn messy metrics into real decisions, and how to build teams that deliver without you holding everything together.
More and more companies are adopting a “builder” mindset. With Claude, Codex, and similar tools, software creation has become radically more accessible, and almost anyone in a company can now open a PR and ship internal or customer-facing tools.
Today, PRs are pouring in from all walks of life: product managers, customer support agents, the head of finance, and even CEOs. That cross-functional energy is exciting, and some of the best ideas do come from the intersection of disciplines. But this speed also shifts hidden work onto engineering through review load, operational risk, and long-term maintenance.
We’re optimizing for velocity, often as if it were the only metric that matters. If everyone can build, then one question matters more than ever: who owns production when things break?
A whole new world
PR volume is increasing fast, and PR size is increasing with it. Reviews that used to be manageable are now routinely 10–30k changed lines. The bottleneck is no longer writing code; it’s understanding and validating it. To keep up, engineers are increasingly using LLMs to review LLM-generated code. Even CI/CD becomes harder to trust when test logic and pipeline logic are also AI-generated. At that point, we’re often relying on one model to validate another model. But did we really think this through?
What happens when PRs exceed our context windows?
What happens when regressions are introduced far from the files under review?
What happens when our codebases reach 60 million lines?
What happens when token costs increase?
Coding was never the bottleneck
Now we have a fancy new tool running in production. But coding was always the easy part. Shipping was slightly more difficult. But operating it... That was always the hardest bit.
When these systems fail (and believe me they will), who owns the fix?
Who patches the ten new npm dependencies in the PR when zero-day vulnerabilities are disclosed?
Who handles rollback, feature flags, and customer impact if something breaks?
Teams are often told these are “small tools,” maybe not even customer-facing. But internal tools are production systems too: colleagues depend on them, and failures still cost time, trust, and money. If we vibe-code critical internal tooling without clear ownership, the burden defaults to engineering.
So who is on call?
Who monitors the dashboards?
Who is accountable when the system breaks at 2 a.m.?
I guess AI-native observability is going to be the next big thing.
Revolution
This isn’t a reasoning problem; it’s an incentives problem. When teams are rewarded mostly for shipping speed, ownership questions get deferred until incidents force them. We’ve seen the same pattern for years with testing and reliability work: if velocity is the only scoreboard, quality gets postponed. Without changing the system, more output just means more risk.
It’s just like quicksand: the harder we try to contain it, the faster we sink. So the only way out is to give in.
I urge all engineers to go back to their desks, write five PRDs this week, and submit them to their product counterparts for review. Just make sure they get reviewed quickly, since velocity is paramount. While your agents are busy handling comments from product folks, you can also start shaping next year’s company strategy to be submitted to the CPO, or help finance cut costs by replacing some tools with vibe-coded equivalents (just imagine how many millions of euros you’ll save once you retire Microsoft Excel and Google Drive).
Jokes aside, here’s what actually works:
Cap PR size so reviews remain meaningful
Require a named owner for every AI-built tool before merge
Add an operational-readiness gate (monitoring, rollback plan, and on-call ownership)
Track reliability metrics (defect rate and MTTR) alongside velocity
Treat internal tools as production systems when business operations depend on them
Conclusion
The future is bright, but we need to be careful about how we navigate it. It is important to experiment and embrace new tools, but we also need to be mindful of the implications and ensure that we are not overloading our teams or creating new problems in the process. More importantly, we need to measure the impact of our actions and be willing to course-correct when necessary.