Laurie Voss has a provocative thesis about where software development is headed, and it’s not more coding.

“The cost of writing code collapsed, and the cost of reviewing, fixing and operating it is following, and I’m assuming it gets there,” Voss wrote recently. “What’s left of making software is finding out what people actually want, defining it precisely, and making it pleasant to use.”

His conclusion: “That cost is per piece of software and doesn’t transfer, so as the amount of software goes to infinity, which it will because there’s no ceiling on demand, that cost becomes the whole job.”

It’s a clean framework for thinking about what changes when LLMs can generate working code from a decent prompt. The code itself gets cheaper. The understanding of what to build doesn’t.

The product engineer thesis

Voss calls this “We are all Product Engineers” in his original piece. It’s not just that developers need to care about product. It’s that as implementation costs approach zero, implementation stops being the differentiator.

You can already see this playing out. Teams that clearly understand their users’ problems ship useful features with AI assistance. Teams that don’t understand their users ship more bad features faster.

The skills that don’t compress are the ones that require judgment. What does this user actually need? What’s the simplest solution that solves the real problem? How do we make this not terrible to use?

Those questions don’t have a GitHub Copilot autocomplete.

What doesn’t transfer

The key insight in Voss’s framing is that last bit about costs that don’t transfer. If you figure out how to build a great authentication flow, that knowledge doesn’t help you build a great checkout experience. Every piece of software has its own set of product questions.

But code patterns absolutely do transfer. Authentication libraries, payment integrations, form validation. All the implementation details that used to eat up sprints are increasingly commoditized.

When the transferable work gets automated, what’s left is the non-transferable work. Understanding users. Making decisions. Saying no to bad ideas.

The infinite software problem

Voss assumes the amount of software goes to infinity because there’s no ceiling on demand. That’s probably right. As soon as building custom software gets cheap enough, everyone wants it.

Internal tools that were never worth building become trivial. Custom workflows for tiny use cases become feasible. The long tail of software gets very, very long.

Which means the bottleneck isn’t “do we have enough developers to build this?” It’s “is this actually worth building, and if so, what exactly should it do?”

Those are product questions, not engineering questions. And they’re hard.

What this means for developers

If Voss is right, the developer who thrives isn’t the one who can implement a feature spec the fastest. It’s the one who can figure out what the spec should say in the first place.

That’s a different skill set. It requires talking to users. Understanding their workflows. Noticing when a feature request is actually a workaround for a deeper problem.

It also requires taste. AI can generate infinite variations on a solution. Someone still has to decide which one doesn’t suck.

The good news is that developers are often better positioned to do this work than anyone else. You understand the constraints. You know what’s possible. You can prototype fast enough to test assumptions.

The adjustment is realizing that the code is the easy part now.