First Principles Are the New Scarce Skill

Last month we shipped a feature in an afternoon that would have taken a small team two weeks.

The model wrote most of it. It was clean. It worked.

We turned it off three days later, because we’d built the wrong thing.

The Bottleneck Moved

For most of my career, the constraint was building.

You knew what you wanted. Roughly. The hard part was the months between the idea and the working thing. Hiring. Coordinating. Debugging. The “how” ate the calendar. You could be vague about the “what” because reality would force precision out of you eventually. The build was slow enough that you’d notice you were wrong before you’d gone too far.

That buffer is gone.

The model builds at a speed that outruns your ability to be wrong slowly. You ask for a thing, you get the thing, and you get it before you’ve finished thinking about whether you wanted it. The cost of producing the wrong answer has collapsed. The cost of choosing the wrong question has not.

So the bottleneck moved. It used to live in execution. Now it lives in framing.

Cheap Building Punishes Vague Thinking

Here’s the part nobody warns you about.

When building was expensive, expensive building protected you. The friction was a filter. A half-formed idea died in the planning meeting because someone asked “who’s going to build that?” and the room went quiet. Cost killed bad ideas before they shipped.

Take the friction away and the bad ideas ship.

The model doesn’t push back. It doesn’t ask whether the feature should exist. It doesn’t notice that you’re solving a symptom. It takes your framing as gospel and executes it with terrifying competence. If your thinking is sharp, you get leverage. If your thinking is muddy, you get a beautifully engineered version of your confusion, faster than ever.

AI is an amplifier. It multiplies what you feed it.

Feed it clarity, it returns leverage. Feed it confusion, it returns more confusion, polished, plausible, and shipped.

Most “What” Decisions Are Actually “Why” Decisions

When we killed that feature after three days, the post-mortem was short.

The feature did exactly what we asked. The problem was upstream. We’d asked for a thing that addressed a complaint, not the cause of the complaint. We’d optimised the surface. The bedrock was untouched.

That’s the trap. Most teams think they have a “what” problem. They don’t. They have a “why” problem wearing a “what” costume.

First-principles thinking is the discipline of refusing the inherited answer. You don’t ask “how do we build the dashboard?” You ask “why does anyone need to look at a dashboard?” And often the honest answer is they don’t. They need a decision made, or an alert, or for the underlying thing to stop going wrong. The dashboard was a solution someone reached for before they’d decomposed the problem.

Decompose to bedrock. Ask why until the answer stops being inherited and starts being load-bearing. Most features die at that depth. The ones that survive are worth building.

This is the same instinct as systems-first design: you don’t add another tool to a problem you haven’t actually framed.

What Gets Scarce, What Gets Cheap

The market is repricing skills right now, fast, and not in the direction most people expect.

What’s Getting Cheap	What’s Getting Scarce
Writing the code	Deciding the code is worth writing
Knowing the syntax	Knowing which problem to point it at
Producing the first draft	Judging whether the draft solves the real thing
”How do we build this?"	"Should this exist at all?”
Speed of execution	Quality of the question

The left column used to be the job. It was what you hired for, paid for, measured. It’s collapsing in value because the model does it on demand.

The right column was the soft stuff. The “vision” you couldn’t put on a Jira ticket. It’s now the entire game. The person who can frame a problem cleanly is worth more than the team that can build any solution quickly, because the building is no longer the constraint.

Not my opinion. Watch where the leverage goes.

The Founder Who Frames, Wins

I’ve watched two kinds of operators meet this moment.

The first treats AI as a faster horse. More output, same thinking. They ship more features, more docs, more decks. They confuse motion for progress. Six months in, they’ve built a sprawling, capable system that solves problems nobody had. They optimised the “how” and never interrogated the “what.”

The second treats AI as a forcing function on their own clarity — something that, by removing the excuse of slow execution, forces the real question into the open. They know the model will execute whatever they ask, so they get ruthless about what they ask. They spend their scarce hours on framing, not typing. They decompose. They cut. They build less, and what they build is load-bearing.

The second kind is pulling away. Not because they have better tools. Everyone has the same tools now. Because they have better questions.

Your edge used to be what you could build. Now your edge is what you choose to build. That’s a smaller surface and a sharper one.

First Thing Tomorrow

Stop optimising your output. Start auditing your inputs.

Take your current roadmap and ask “why” five times per item. For each feature, keep asking why until you hit bedrock or the item collapses. The ones that collapse were never worth building. You just couldn’t see it under all the execution.
Find the last thing you shipped fast and check if it was right. Speed of build tells you nothing about correctness of choice. If you can’t say what underlying problem it solved, you optimised the surface. We had to learn this on ourselves: we measured three days of our own pipeline before building more of it, and the bottleneck wasn’t where we’d assumed.
Separate “what” from “why” on every decision this week. Write the surface request, then write the actual outcome you want. If they don’t match, you’ve been building costumes.
Spend an hour framing before you spend a minute building. With the model this fast, the cheapest place to be wrong is on paper, in your head, before a single line exists. Front-load the thinking. It’s the only expensive part left.
Kill one thing you’re proud of. Find the feature that works beautifully and serves no one. Turn it off. The discipline of subtraction is the muscle this moment rewards.

The Bottom Line

For decades, the scarce skill was building. You hired for the “how.”

The model took the “how.” What’s left is the part that was always hardest and always undervalued: deciding what’s actually worth doing, and why.

The hard part was never the implementation. We just couldn’t tell, because the implementation was loud enough to hide behind.

It’s quiet now.

Need help deciding what’s actually worth building? We frame problems before we build solutions. First principles, then execution. Let’s talk.