Intuit Rolled Out Claude Code Company-Wide. Now PMs Are Merging Their Own PRs

When the marginal cost of writing a line of code approaches zero, the entire shape of software engineering shifts. That was the premise behind a recent Leaders of Code conversation on the Stack Overflow Podcast, where host Eira May and Stack Overflow engineering director Ben Matthews sat down with Eric Anderson, director of engineering at Intuit, to talk through what his teams are actually seeing after deploying Claude Code across the whole organization.

The headline detail: product managers at Intuit are now opening pull requests that land in the production codebase, get reviewed by an engineer, and ship as experiments. No engineer writes the feature. The PM does, and the engineer signs off on the review. That single workflow change captures most of what the episode is about.

The cheapest thing we do now is produce code

Anderson framed the change in economic terms. "Never before has the incremental cost of a line of code been cheaper," he said. "It essentially is about the most inexpensive thing of anything that we do in terms of software development."

That inversion matters because for decades, coding was the constraint. It was the thing engineering leaders worried about on every axis: scheduling, risk management, rollout, rollback. When that constraint loosens, the questions that used to be secondary move to the front. What does it actually mean to build a feature? What is system design when the design can be rebuilt tomorrow? Which skills make someone a strong engineer when raw coding throughput is no longer the differentiator?

Anderson was blunt that being a fast typist of code is not the same as being a strong software engineer anymore. "If you're a rockstar programmer, that's not necessarily the thing that is going to make you a rockstar software engineer in this new day and age."

The counterintuitive consequence is that the demand for software has gone up, not down. Anderson pointed to a recurring observation from Intuit CTO Alex Balazs: the backlog never shrinks. "The minute that we feel like we can do all this work with fewer people, that's a conversation worth having. But today we actually see the explosion of ideas." Matthews put the same point from the leadership chair: if you think you need fewer engineers now, the real problem is that you cannot think of enough things to build.

The bottleneck moved to ideation

With code generation no longer the limiting factor, where does the work actually slow down? Anderson's answer was the process itself, specifically the path from "here's a cool idea that solves a customer problem" to "here's something running in production."

He described a planning exercise where his organization sat down to build a standard quarterly roadmap and then deliberately threw it out. Looking across team backlogs, he realized they were thinking too small. The harder questions were about handoffs and working relationships: Do we still need exhaustively detailed PRD documents with every nuance specified? Or do we need sketches that a PM and an engineer co-develop into several working scenarios for a feature?

The experimentation angle is where this gets concrete. Intuit runs a lot of A/B testing, and Anderson's point was that teams no longer have to pick between two variants. "Can we do two experiments? Can we do five experiments? Can we do nine experiments? Can we do 900 experiments?" The optionality of experimentation has expanded dramatically, which pushes the pressure onto having the right metrics and instrumentation in place to actually learn from all those variations.

He drew a direct line back to the Scrum transition. Moving from waterfall to agile was its own retooling of product owners, Scrum masters, and iteration cadence. This is another such moment, except nobody has the playbook yet. "We don't really know how to do it well, I would say. We're experimenting and learning through the process."

The shape of the answer also depends on what a team builds. A frontend store experience can iterate almost endlessly. A backend team running large-scale data pipelines and mission-critical ingestion has to think about it very differently. There is no single new normal.

Roles are blending, and that builds empathy

The story Anderson told about a designer walking into his office captures the cultural moment. The designer had set up Claude Code and asked, "Where do I check in the code now?" Anderson's response was to ask what problem they were trying to solve. The designer didn't have one. They just knew they now had the tool and wanted to know where the output went.

That is the awkward middle of a rollout: the capability arrives before the workflow does. Anderson's framing is that the tools are opening pathways between disciplines. PMs can act as engineers. Engineers learn product thinking. Designers learn enough code to prototype interactions they can actually put in front of people.

The payoff he emphasized was shared empathy. When a PM hits the operational constraints of shipping code, or a designer sees why a particular change is genuinely hard, conversations accelerate. "Oh, now I get why that's super hard. Okay, let's do it this way." He compared the shift to earlier tooling jumps, from Emacs and vi to Eclipse and IntelliJ, except more capable. The ownership doesn't change: code still goes through CI/CD pipelines, still has to be supportable, maintainable, instrumented, and measured.

Matthews added the practical version of this from his own work. Instead of translating business requirements into a spec and hoping engineering builds the right thing, a PM or designer can now whip something together and show the actual interaction. He was clear he probably wouldn't ship that code to production, but as a shortcut to something concrete that people can touch, it's enormously valuable.

The skills that still matter

Anderson splits hiring evaluation into two independent axes: functional skills and how you do the work. The "how" includes things like diving deep into problems, owning outcomes when things go wrong, being customer obsessed, and unblocking yourself. He called these orthogonal to any particular CLI or tool.

On the functional side, he kept software engineering as a real, distinct skillset organized around three categories:

• Algorithms. Database queries, big data ETL pipelines, and similar problems still demand algorithmic thinking. You still need to understand what an O(n) complexity means across different implementations.
• Technical problem solving. The general mindset captured by classic interview problems, like the best-time-to-buy-and-sell-stock question, still has to be there.
• Modularity and decomposition. This one Anderson elevated. If an agent generates a 12,000-line PR, it cannot be 12,000 lines in a single class. Breaking a problem into smaller component parts, understanding how they interrelate, and reasoning about dependencies and error paths is now more important, not less.

His line on the foundation was direct: "If you can't understand algorithms, you're not going to be successful. There's no Claude CLI that's going to help you be successful with that. We're not there yet."

The junior engineer problem

The most candid part of the conversation was about who gets left behind. Anderson reported that one of his principal engineers described being a hundred times more productive than before, and he believes it, because that engineer already knows how everything fits together.

The worry is the other end of the seniority curve. Anderson learned engineering the way many did: by sitting next to people who had written more code than he had, in something close to a craftsman or apprenticeship model. That transmission mechanism is exactly what AI tooling disrupts. "How do we make our best developers 100X more productive, which is great, and how do we make sure that the folks that are new in career are able to ramp into this experience in a way that is healthy and productive for their career development?"

Matthews raised the ownership angle with a story from a university visit. A student presenting their work was asked about a questionable choice in their code and answered, "Well, that's just what Claude outputted." The dismissal of ownership is the mindset both of them flagged as the thing to fight. You still own what you build. You are still responsible for what ships. And as Matthews pointed out, senior engineers come from junior engineers, so organizations that decide they only want seniors are quietly defunding their own future pipeline.

Anderson's optimistic counterweight is that the aperture of who can become an engineer has widened. A graphic designer who wants to build graphic software now can start, and the moment they need to reason about 3D object collision or the physics of how a mesh moves, they're doing real engineering. He sees this as a path to engineers arriving from new disciplines and backgrounds, drawn in by the same "this is super cool and I understand it" feeling that pulled him in as a teenager messing around with Visual C++.

A note on Python

For readers who live in the Python world, there's a relevant aside. Matthews made the case for Python as the welcoming on-ramp it has always been: readable, powerful enough to build a whole career on, and forgiving of the intimidation that keeps people out of programming. Anderson agreed that an easier language is a legitimate entry point, while drawing the distinction that learning Python is very different from building your own data structures in C, which exercises a different level of understanding.

The through line is that the language is not the hard part. "The languages themselves are hokey anyways, honestly. None of them are amazing, but solving problems is amazing."

Cattle, not children

The episode closed on agents and a provocative analogy. Intuit is moving past code generation toward agents that own specific parts of the engineering process: take a corpus of data, run the code, identify bugs, fix them, run again, in a self-improving loop. Anderson was candid about the failure mode. Those agents "go off into crazy land" and produce output that technically satisfies the fitness function but doesn't actually help. His teams are now thinking about adversarial agents that monitor other agents, and about senior engineers becoming something like software managers who ask their agents, "What are you working on right now? How are you doing on that?"

That raises the measurement question again. If a person is managing an agent, how do they demonstrate the agent is making progress versus producing garbage? Anderson expects new efficacy metrics to evolve naturally out of this management-of-agents structure.

One of his principal engineers offered the line that became the episode's most quotable moment: treat code like cattle, not children. Be less precious about it; you can start from scratch whenever you want. Anderson's own reaction was to pump the brakes ("Cool your jets there, my friend"), but he admitted it's an interesting thought experiment. When the incremental value of a line of code approaches zero, why not rebuild everything every day?

Matthews supplied the counterargument. Any software that meets a real customer for the first time finds problems and has to evolve. If you rewrite from scratch on every iteration, you may lose the accumulated sharpening that real-world feedback produces. There's also a prediction worth holding onto: a Stack Overflow staff engineer expects that in two or three years, the industry will hit a wall built from prompting gaps, because models optimize for the task you put in front of them and do not reason about flexibility or portability the way a human does. When teams try to build on top of those foundations and discover they have to rewrite, that may be exactly where junior engineers cut their teeth, and where understanding how the code works finally shines through. Anderson thinks that reckoning is closer than two years out.

Neither of them pretended to have the answers. The recurring phrase across the whole conversation was "we're figuring it out." The tooling got genuinely good only about four or five months ago, by Anderson's reckoning, and whether it plateaus, expands, or becomes too complex to fully understand is still open. That uncertainty, he argued, is precisely where human judgment earns its place.

You can connect with Eric Anderson on LinkedIn and find more episodes on the Stack Overflow Blog. Topic and guest suggestions go to [email protected].