Problem Scarcity: AI Makes Building Cheap, Not Judgment
We are drowning in a glut of AI-generated solutions, yet making little progress. Why? Because we've forgotten that the most valuable work isn't finding the answer, but forging the question. In the new economy, the only real scarcity is a well-defined problem.
The bottleneck in engineering used to be execution. You had the problem. You needed the team, time, budget, and infrastructure to build the answer. That constraint is dissolving. Modern coding agents can scaffold services, write tests, summarize research, and generate product variants faster than organizations can decide what is worth building. And yet many companies are not moving faster. They are moving sideways: producing more implementation, with less certainty that the work matters.
The bottleneck has shifted. The scarce resource is no longer implementation capacity. It is problems — specifically, problems worth solving. I call this The Principle of Problem Scarcity: as the cost of generating answers falls, the ability to formulate the right problem becomes the dominant source of value.
- AI has made implementation dramatically cheaper. The bottleneck has shifted from "can we build it?" to "should we build it?"
- Problem formulation requires three capabilities that are hard to delegate: distinguishing real from imagined constraints, sensing which outcomes matter to actual humans, and knowing when a problem has been solved "enough".
- Controlled experimentation work, including Microsoft research by Kohavi, Deng, and Frasca, showed that shipped features often fail to move their intended metrics. Execution speed was not the only bottleneck.
- The Semantic Compression of a well-formulated problem statement is one of the highest-impact artifacts in engineering because it eliminates work that should never begin.
The Inversion
For most of software engineering history, the economic model was straightforward: problems were comparatively cheap and implementation was expensive. Every methodology — Agile, Lean, DevOps — optimized the implementation side. Faster sprints. Shorter feedback loops. Continuous delivery. All of it aimed at reducing the cost and latency of turning a problem into working software.
AI inverted this. When an agent can scaffold a microservice, generate tests, and draft documentation from a short specification, implementation is no longer the same constraint. The person who types "build me an auth service with JWT and refresh tokens" gets one. It compiles. It might even be decent. But whether that auth service is what the organization actually needs — whether the real problem is authentication at all, or whether it is a trust architecture problem, a session management problem, or an organizational boundary problem masquerading as a technical one — that question remains expensive.
The cost of generating a wrong answer used to be high enough to force careful problem formulation. With AI, wrong answers are cheap — and the forcing function is weaker.This is the inversion. When implementation was expensive, bad problem statements got filtered by resource constraints. You could not afford to build the wrong thing, so you thought harder about what to build. Now you can afford to generate far more candidate answers. The economic pressure to formulate the right problem has weakened, even as the strategic importance of doing so has increased.
What Problem Formulation Actually Requires
Problem formulation is not "writing a good prompt". A prompt is an instruction to a machine. Problem formulation is an epistemic act — it requires understanding what you do not know, what constraints are real versus inherited, and what "solved" would look like for specific humans in a specific context.
Three capabilities sit at the core, and none of them are easy to delegate wholesale:
Constraint discrimination. Every project inherits constraints from its organizational context. Some are real: regulatory requirements, physics, budget. Many are inherited habits: "we always do it this way", "the VP wants microservices", "our users expect a dashboard". The person who can distinguish real constraints from institutional habits can eliminate unnecessary work before a single line of code is written. This is the skill that separates a staff engineer from a senior engineer — not technical depth alone, but the ability to see which walls are load-bearing and which are drywall.
Outcome sensing. An LLM can generate many product specs. It cannot reliably tell you which one maps to a change in human behavior that your business needs. Outcome sensing requires Optimal Estrangement — enough distance from the problem to see its structure, enough proximity to feel its texture. A product manager who has watched users struggle with a workflow has a compression of that experience that no context window can fully replicate.
Sufficiency judgment. Knowing when a problem is solved "enough" is perhaps the hardest skill in engineering. Perfectionism is a failure mode. So is premature shipping. The judgment of sufficiency is a function of taste, experience, and an internalized model of the user's tolerance — none of which are fully legible in a prompt.
Problem formulation requires three capabilities AI lacks: constraint discrimination (which walls are load-bearing), outcome sensing (which changes matter to humans), and sufficiency judgment (when to stop).The Organizational Implications
If problem formulation is the bottleneck, then the org chart has the wrong shape. Most engineering organizations are pyramids: few architects, many builders. That geometry was correct when building was expensive. In a world where an agent can scaffold a service from a spec, the pyramid should flatten. You need more people who can formulate problems and fewer handoffs dedicated only to implementation throughput.
Microsoft's controlled experimentation work, including research by Kohavi, Deng, and Frasca, found that many shipped features did not measurably improve the metrics they targeted. The features shipped. They worked. They were technically sound. But the problem they solved was not a problem users actually had, or not the problem that moved the business metric. The lesson predates generative AI: execution speed was never sufficient.
The hiring implication is direct. The most valuable engineer in an AI-rich organization is not merely the person who can build fastest. It is the person who can identify which candidate work will move a metric and articulate why the rest is noise. This is not a technical skill in the narrow sense. It is a Cognitive Weaving skill — the ability to synthesize customer data, business context, technical constraints, and organizational dynamics into a problem statement that is both precise and correct.
The Problem Formulation Stack
I think of problem formulation as having three layers, each requiring different skills and operating at a different timescale:
| Layer | Question | Timescale | Who Owns It |
|---|---|---|---|
| Strategic | What game are we playing? | Years | CEO / Founders |
| Structural | What system would solve this class of problem? | Quarters | Architects / Staff+ |
| Tactical | What is the smallest change that moves this metric? | Weeks | Product / Senior Engineers |
AI is eating the tactical layer from the bottom. Code generation, automated testing, and basic product analytics are becoming cheaper. The structural layer is where the acute shortage exists today. The person who can look at a messy organizational challenge and extract a clean technical problem — who can apply Semantic Compression to turn a sprawling set of symptoms into a precise problem statement — becomes unusually valuable.
The strategic layer remains mostly human. Choosing which game to play is a values decision as much as an analytical one. No model can tell you whether to optimize for growth or profitability, whether to build a platform or a product, whether to serve enterprises or consumers. These are problems of identity, not information.
The question worth sitting with is not "how do I use AI to build faster?" That question is increasingly answered. The question is: "Am I solving a problem that matters?" And if you cannot answer that with specificity — with named users, measurable outcomes, and real constraints — then all the implementation capacity in the world is just a faster way to build the wrong thing.
Related Reading
For adjacent angles on problem formulation and engineering judgment, see The Law of Epistemic Decay, The Law of Semantic Compression, and Cognitive Weaving vs AI Copilot.