When the cost of code approaches zero, what does engineering leadership look like?

When code costs nothing, what becomes the bottleneck?

The core idea is simple: writing a line of code has never been cheaper, and that changes everything about engineering leadership. But not in the ways most teams expect. The hidden consequence is that the bottleneck doesn't disappear. It moves. It shifts from writing code to the messy, human process of deciding what to build. Eric Anderson, director of engineering at Intuit, says the real constraint is now the ideation to production pipeline. Roles between PMs, designers, and engineers are blurring faster than most organizations can handle. If you are an engineering leader, this conversation maps where your team's process will break first. And it shows why investing in human judgment, not just faster code generation, is the competitive advantage that compounds over the next 12 to 18 months.

The bottleneck has moved, and most teams haven't noticed.

For decades, the critical path in software development was clear: write the code. Schedule risk, rollout risk, rollback risk. All of it centered on the act of producing working software. That has flipped. Eric describes how his team started planning a quarterly roadmap and realized they could deliver everything on the backlog and more. The constraint was not coding capacity. It was everything upstream.

"Never before has the incremental cost of a line of code been cheaper. It essentially is about the most inexpensive thing of anything that we do in terms of software development is actually produce code."

The immediate effect is liberating. More experimentation. More optionality. But the downstream effect is uncomfortable. The process of constructing software becomes the new bottleneck. How do you know when a design is complete when you can change it tomorrow? Do you need detailed PRDs, or just sketches? Eric's team is now reimagining handoffs between design, product, and engineering. The teams that don't retool their process will find themselves generating code faster than they can decide what to build. That is a strange kind of productivity trap.

This is where systems thinking matters. The obvious solution is to keep doing what you are doing but faster. The hidden cost is that your process was designed for a world where code was expensive. In that world, you optimized for getting it right the first time. Now, the system rewards iterating quickly. The teams that adapt their rituals, standups, sprint planning, definition of done, will pull ahead. Those that don't will feel like they are running on a treadmill that keeps accelerating.

When PMs merge their own PRs, what happens to engineering culture?

Here is where the conversation gets genuinely weird. Eric mentions that Intuit has PMs now producing PRs that get reviewed by engineers and shipped as experiments. Designers are asking where to check in code. The boundaries between roles are dissolving.

"We have PMs now producing PRs that go into our code base and get reviewed by an engineer and they go out as an experiment. That's great. Like we don't actually, there's no engineers doing any work there other than a PR review and that's fine."

The immediate benefit is speed and shared understanding. PMs can prototype their ideas directly. Engineers learn product thinking. But the second order effect is subtler. Who owns quality? Who ensures the code is maintainable, instrumented, and operationally sound? Eric is clear. Engineers still own those things. The PM's PR still goes through review. But the system now demands that engineers develop a sharper judgment about what to accept and what to push back on.

The real hidden consequence is that the engineering manager's job gets harder. You are no longer just managing engineers. You are managing a blended team where everyone can generate code, but not everyone understands the operational implications. The competitive advantage goes to leaders who can build shared context across disciplines. Who can train their teams to think in terms of system resilience, not just feature velocity. This pays off in 12 to 18 months, when the teams that invested in cross functional understanding can move faster without accumulating technical debt that compounds.

The junior talent problem: why the apprenticeship model is breaking.

Eric's most sobering insight is about junior engineers. Senior engineers at Intuit are reporting 100x productivity gains with Claude Code. They know the system. They know how to structure prompts. They know what to reject. Junior engineers don't. And the traditional apprenticeship, learning by sitting next to someone who has written more code, is under threat.

"I grew up at a time where software engineering as a discipline was learned by the people sitting next to you, I think that had written more code than you. It's almost like being a cabinet maker or a plumber. And I think that's the thing we've got to figure out how do we teach that over time."

The immediate temptation is to hire only senior engineers. Why train juniors when seniors are 100x more productive? But the downstream effect is a talent pipeline that dries up. Senior engineers retire or move on, and there is no one to replace them. The industry faces a choice. Invest in structured mentorship and learning programs now, or accept a long term erosion of engineering depth.

This is where discomfort now creates advantage later. Teams that build deliberate onboarding paths, where juniors learn algorithms, modularity, and debugging despite the ease of code generation, will have a deeper bench in 2 to 3 years. Those that don't will find themselves fighting over a shrinking pool of senior talent. The system rewards patience here, but most organizations won't have it.

Code as cattle: the disposability mindset and its hidden costs.

Eric shares a provocative line from one of his principal engineers. "We're going to treat code like cattle, not children." The idea is that when code costs nothing to produce, you can afford to throw it away and start over. No precious attachment. Just rebuild.

The immediate appeal is obvious. No more legacy cruft. No more technical debt. But the hidden cost is institutional knowledge. Every rewrite discards not just code, but the hard won understanding of edge cases, failure modes, and customer behavior encoded in that code. The system responds by requiring better monitoring, better agents, and better human oversight. Eric notes that his senior engineers are now managing agents like direct reports. "Hey, what's my agent doing today?" That creates a new layer of management complexity.

The competitive advantage here goes to teams that can balance disposability with learning. Treat code like cattle, but treat the knowledge about that code like children. Invest in documentation, runbooks, and shared understanding that survives rewrites. That is a harder investment to make, and it pays off over years, not quarters.

Key action items.

Redesign your planning process now. Over the next quarter, audit where your team's bottleneck actually is. If it is not coding, shift your standups, sprint planning, and definition of done to reflect the new constraint. Likely ideation, design, or cross functional handoffs. The teams that don't will generate code faster than they can decide what to build.

Create structured mentorship for junior engineers. This pays off in 12 to 18 months. Pair juniors with seniors who can teach modularity, debugging, and system thinking. Skills that don't come from prompting. Build deliberate learning paths that include reading and reviewing AI generated code critically.

Establish clear ownership boundaries for blended roles. If PMs or designers are producing PRs, define what engineers still own. Operational excellence, instrumentation, performance, and maintainability. Make the review process explicit. This prevents the hidden cost of unowned code from compounding.

Invest in agents that monitor agents. As you deploy autonomous coding agents, build adversarial monitoring that checks their output. Eric's team is already doing this. The immediate discomfort of building monitoring infrastructure creates a lasting advantage when agents inevitably go off into crazy land.

Treat code as cattle, but knowledge as children. Over the next 6 months, invest in documentation, runbooks, and shared context that survive rewrites. The teams that can throw away code without losing learning will move faster over years.

Measure customer value, not lines of code. Eric is clear. The metric that matters is whether the technology generated customer value. Resist the temptation to celebrate code volume. Instead, instrument for outcomes. Experimentation velocity, customer satisfaction, and business impact. This is a long term investment that separates signal from noise.

Experiment with process, not just product. Eric's team reimagined their quarterly planning on the fly. Build a culture where process changes are treated as experiments with clear hypotheses. The teams that learn how to learn will adapt faster than those that cling to pre AI workflows.