Announcer
The following program features simulated voices generated for educational and philosophical exploration.
Greg Evans
Good evening. I'm Greg Evans.
Andrea Moore
And I'm Andrea Moore. Welcome to Simulectics Radio.
Andrea Moore
We've examined the technical capabilities of AI coding tools, their architectural limitations, their relationship to software discipline, and the social practices they disrupt. Tonight we turn to economics. What happens when code production costs approach zero? How do we measure developer productivity when machines write the implementations?
Greg Evans
These aren't hypothetical questions. Companies are already restructuring engineering organizations around AI assistance. We need frameworks for understanding what value developers provide when they're no longer primarily writing code.
Andrea Moore
We're joined by two guests tonight. Patrick Collison is CEO of Stripe, where thousands of engineers are grappling with these productivity questions in practice. Patrick, welcome.
Patrick Collison
Thanks for having me.
Andrea Moore
And Dr. Erik Brynjolfsson, economist at Stanford's Digital Economy Lab, who has studied productivity paradoxes in technology adoption for decades. Erik, welcome.
Dr. Erik Brynjolfsson
Glad to be here.
Greg Evans
Patrick, let's start with the practical question. When your engineers started using AI coding assistants heavily, did productivity increase?
Patrick Collison
That's surprisingly hard to answer. Lines of code per day went up dramatically. Pull requests increased. But did we ship more valuable features? That's less clear. We might be building things faster, but are we building the right things? The measurement problem is real.
Dr. Erik Brynjolfsson
This echoes what we saw with earlier waves of automation. Output metrics spike, but value creation is harder to track. With manufacturing automation, we could count widgets. With knowledge work, especially creative technical work, the metric problem is much harder.
Andrea Moore
What metrics are you using, Patrick?
Patrick Collison
We're experimenting with several. Time from specification to working feature. Bug rates in production. Developer satisfaction surveys. Code review cycle times. But none of these cleanly separate AI contribution from human contribution. If a feature ships faster, was it because the AI wrote good code or because the human specified it better?
Greg Evans
Erik, is there economic precedent for this attribution problem?
Dr. Erik Brynjolfsson
Absolutely. When spreadsheets automated financial modeling, did productivity gains come from the software or from analysts asking better questions? Both, obviously, but disentangling them is difficult. We call this the complementarity problem—the tool and the human expertise combine multiplicatively, not additively.
Patrick Collison
That matches what we see. Our best engineers got much better with AI tools. Mediocre engineers got somewhat better. The productivity gap might actually be widening, not narrowing. The tools amplify existing capability.
Andrea Moore
That's counterintuitive. We usually expect automation to level the playing field.
Dr. Erik Brynjolfsson
Only if the automation is substitutive—replacing human labor entirely. When automation is complementary—augmenting human capability—it often increases returns to skill. The best chess players got better with computer analysis tools. Average players improved less. Software development seems similar.
Greg Evans
Patrick, does that change hiring strategy? Are you looking for different skills now?
Patrick Collison
We're definitely rethinking it. Pure implementation skill matters less. System design, specification clarity, code review judgment—those matter more. But we're also wary of over-indexing on this. The field is changing fast. Skills that seem less important now might become critical again if the tools hit limitations.
Andrea Moore
What about compensation? If AI does much of the implementation work, does that change what developers are worth?
Patrick Collison
It should, theoretically. But the market hasn't adjusted yet. We're still competing for the same talent pool, and AI hasn't made great developers abundant. If anything, demand for senior engineers who can effectively direct AI tools has increased. Compensation hasn't fallen.
Dr. Erik Brynjolfsson
This is typical of technology transitions. In the short term, you often see skill premiums increase rather than decrease. Only later, as the technology matures and more workers gain the complementary skills, do premiums normalize. We're in the early phase where AI fluency is rare and valuable.
Greg Evans
Erik, let's talk about the productivity paradox. You've written about how computing technology took decades to show up in productivity statistics. Are we headed for a similar delay with AI coding tools?
Dr. Erik Brynjolfsson
Possibly, for similar reasons. The technology itself is only part of the equation. Organizations need to restructure workflows, update processes, retrain workers, and figure out new business models. All of that takes time. We might see individual developers get faster without seeing company-level productivity gains for years.
Patrick Collison
We're experiencing this. Developers are writing code faster, but our release cycles haven't sped up proportionally. We're bottlenecked on design decisions, stakeholder alignment, integration testing—things AI doesn't help with much. The overall system has other limiting factors.
Andrea Moore
So faster coding doesn't automatically mean faster shipping.
Patrick Collison
Right. It's like improving one part of a manufacturing line. If downstream processes can't keep up, you don't get end-to-end improvement. We need to rethink the whole development pipeline, not just the coding step.
Greg Evans
What would that rethinking look like?
Patrick Collison
Fewer, more consequential code reviews instead of reviewing every minor change. More investment in specification and design upfront. Better tooling for integration testing. Maybe smaller teams, since each developer can cover more ground. We're still figuring it out.
Dr. Erik Brynjolfsson
That organizational adaptation is where the real productivity gains come from. The technology enables new ways of working, but humans have to discover and implement those ways. That's inherently slower than technology deployment.
Andrea Moore
Erik, what about labor market effects? Will we need fewer developers if each one can do more?
Dr. Erik Brynjolfsson
History suggests no. When spreadsheets automated financial modeling, we didn't hire fewer financial analysts—we hired more, because the cost of analysis fell and demand increased. If software development becomes cheaper and faster, we'll likely build more software, not employ fewer developers.
Patrick Collison
I'm seeing that. As developers get faster, product teams want more features. The backlog doesn't shrink, it grows. Every solved problem reveals new problems worth solving. Induced demand is real.
Greg Evans
But that assumes unlimited demand for software. Is that realistic?
Dr. Erik Brynjolfsson
For the foreseeable future, yes. Most organizations are still severely constrained by software capacity. Internal tools remain clunky, processes remain manual, opportunities remain unexploited. Cheaper software development would unlock enormous latent demand.
Andrea Moore
Patrick, what about technical debt? If developers can generate code faster, do you accumulate technical debt faster too?
Patrick Collison
That's a real risk. It's easier to build new features than to refactor old systems. AI tools don't have opinions about architecture quality—they'll happily pile new code onto a shaky foundation. We have to consciously counteract that tendency.
Greg Evans
How do you counteract it?
Patrick Collison
Explicit investment in refactoring. Code quality reviews separate from feature reviews. Metrics that track system complexity over time. But honestly, we're still learning. The temptation to just keep building is strong when the marginal cost of new code feels low.
Dr. Erik Brynjolfsson
This is another area where the economics are tricky. AI coding tools reduce the immediate cost of development but potentially increase long-term maintenance costs. That trade-off isn't captured in conventional productivity metrics, which tend to focus on short-term output.
Andrea Moore
So we might be overstating productivity gains by ignoring future maintenance burden.
Dr. Erik Brynjolfsson
Exactly. True productivity measurement should account for the full lifecycle cost of software, not just initial development speed. That's much harder to track.
Greg Evans
Patrick, final question. Five years from now, what percentage of code at Stripe will be AI-generated?
Patrick Collison
Hard to say. The percentage is less interesting than the nature of human contribution. I expect humans will write less boilerplate, more architectural decisions. Less implementation, more specification. The human-written code might be a smaller percentage but carry more of the critical decision-making. Quality over quantity.
Dr. Erik Brynjolfsson
That aligns with historical patterns. As tools automate routine tasks, human effort shifts toward tasks requiring judgment, creativity, and contextual understanding. The work doesn't disappear, it changes character.
Andrea Moore
We're out of time. Patrick, Erik, thank you for this perspective.
Patrick Collison
Thanks for having us.
Dr. Erik Brynjolfsson
My pleasure.
Greg Evans
Tomorrow we'll examine the fundamental limits of context windows with Andrej Karpathy.
Andrea Moore
Until then, measure what matters. Good night.