Look Under the Hood

Why the tech-first operator wins the AI era — and why “hire engineers who can spec” is only half the answer.

I’ve been a techpreneur for over twenty-five years and a CTO across multiple companies. I’ve watched four computing eras turn over: floppies and CD distributables, dot-com and the rise of internet-enabled software, the App Store and mobile, and now AI.

The AI era is unlike anything that came before. Not because it’s bigger — every era says that — but because of the velocity of change and the number of players in the arena. This is no longer only the tech crowd’s game. The business side is in the thick of things now too, and that changes everything about who wins and how.

Here’s the call I’m making, in one line: the tech-first operator who learns to think product wins this era over the product-first operator who learns to ship code. Both sides are climbing. Only one side has the advantage that matters once the AI is doing the typing.

Let me explain why.

Two camps, both upskilling

When AI tooling went mainstream, the field had two extremes.

On one side: pure tech operators — strong on systems, weak on business. On the other: hardcore business operators — sharp commercial instincts, no real grip on what software actually does under it. Both are upskilling, but along very different paths.

The business side started with vibe coding — tell the AI what you want, get a thing back, ship it. That’s where it begins. From there, the sharper ones move further: they start asking how the data is stored, where the business logic actually lives, how the frontend talks to the backend, which model is doing what, what’s local versus remote, where the trust boundaries are. They’re working their way down the stack, one layer at a time.

The tech side is going the other direction. Tech operators are learning to take their hands off the wheel — to stop writing code line-by-line and start telling the AI what to build, then reviewing what comes back. That is a genuinely different skill from what most engineers grew up doing. For two decades the contract was: business writes the spec, engineers build it. Now engineers write the spec — to the AI — and spend their day reviewing, testing, hardening, and asking “did it really do the right thing?”

So both sides are running uphill. The question is who reaches the summit with the better view.

The race car analogy

Imagine you’ve built a self-tuning race car. It tweaks its own configuration, runs its own laps, finds its own faults, fixes them, runs again. You step back and let it go.

Looks great on paper. It is great — until something starts behaving wrong, or the marginal lap-time gets stuck, or the car does something it shouldn’t and you can’t tell whether it’s a config drift, a sensor lying, or a deeper design flaw.

If you don’t know what’s under the hood, you cannot extract the maximum out of either the car or the automation. You’ll never be on top of what’s actually making it tick. The system will keep running, but the gap between you and the product widens every day.

The same is true of an AI-driven engineering org. AI can write code, review code, write tests, run tests, deploy, monitor. Fine. But unless someone in that loop genuinely understands what the machine is doing — at the level of architecture, security model, data permissions, scalability assumptions, edge cases — the operator and the system drift apart. You stop being a builder. You become a spectator at your own product.

This is the era where you have to look under the hood harder than ever, precisely because you are no longer typing the code yourself.

The “hire engineers who can spec” trend is half-right

I keep seeing the same line on tech LinkedIn: in the AI era, hire engineers who don’t just write code — hire engineers who know how to spec.

I half-agree. Yes, you have to be able to spec. The engineer who can articulate what they want will outperform the one who can’t, every time. But that line is being used to argue something stronger — that spec-writing is now the primary skill, and code review is a residual one. That’s the part I disagree with.

Given the choice, I’d take the engineer whose first spec to the AI is mediocre but who can read the output, see exactly what’s wrong, iterate, and converge — over the engineer who writes a textbook-perfect spec but can’t tell whether the AI delivered the right thing.

The first engineer’s spec gets better with reps. The second engineer’s review never gets better, because the bottleneck isn’t iteration — it’s understanding. They are flying blind on the part of the work that decides whether the system is actually safe, performant, and correct.

In production, on systems that handle real customer data, you cannot afford an engineer who is one model upgrade away from being unable to verify their own output.

Convergence is real. The edge is under the hood.

We’re heading toward a very fuzzy line where the biz guys roll out apps and the tech guys roll out businesses, and the labels we used to lean on stop carrying weight. That’s a good thing. The constraint that “you need a tech co-founder” is melting. The constraint that “you need a business co-founder” is melting too. Solo operators are going to do things that previously required a small company.

But inside that fuzzy zone, the edge goes to the people who can look under the hood. Not in a “I read every line of code” way — almost no one will do that, and they shouldn’t. In a “I know what I’m looking at, I know what good looks like, I can spot when the AI shipped something structurally wrong” way.

If you can do that, you compound. Every iteration, every model upgrade, every new tool makes you faster. If you can’t, you are at the mercy of whatever the AI happened to produce, and the gap between you and your product widens until you don’t actually own it anymore.

The bet I’m making is on operators who stay technical on purpose. Hands off the keyboard. Eyes very firmly on what’s under the hood.

That’s where this era is going to be won.