The Person Who Succeeds with AI Is Not Who You Think
Everyone assumes the best programmer gets the best results from AI. I believed that too. But after a year of watching people use these tools in production, I've seen the opposite.
Speed Is Proven — But Faster at What?
4–5x faster coding is proven. Maybe even 10x. That's no longer controversial.
But a programmer running at 10x speed still delivers within the same working hours, the same scope, the same understanding. The coding got faster. The outcome didn't change. Speed without direction is just faster waste.
Three Things That Must Be Present
The people who get extraordinary results have three things at once:
Technical understanding — they don't need to code, but they need to understand what's happening.
History — they know the domain, the systems, the context. They've seen what worked and what broke.
Business outcome understanding — they care about the result. Not the code, not the tool — but what actually happens for the customer, for the organization, for the end user.
The third factor is the multiplier. Without it, the other two produce faster waste. With it, the same tools, the same LLM — become something else entirely.
The Developer Who Understands the Business
The best AI practitioner I've seen is the developer who has all three. They code, they know the system — and they care about the business outcome. An operations person who builds a diagnostic tool in ten minutes that replaces a full day's work. Not because the tool was magical — but because they knew which question to ask. They had lived with the problem for years and cared about the outcome.
That's the ultimate combination. Technology, history, and business outcome in a single person.
But there's another dimension — one I didn't include in the original list. The ability to see what doesn't exist yet. Not just understand what the customer needs, but imagine a solution nobody asked for. A process that doesn't exist. A connection nobody sees. That's the creative direction that separates the person who delivers what was requested from the person who changes what's possible. In a team I follow, a project manager with a verbal, improvisational style consistently delivers better and faster than a methodical, documentation-focused colleague — not because process is absent, but because he sees the goal, not the steps.
But those people are rare. And that leads to a more important question.
What About the Other Smart People?
There are people in senior positions with marginal programming backgrounds who get better results from AI in an afternoon than a developer managed in a week. Not because they could prompt better — but because they knew exactly what they wanted to achieve.
Project managers who understand the delivery. Business developers who know where the friction lives. Consultants who have done twenty migrations and know which questions always come up. They have the business outcome. They have the history. The technical understanding doesn't need to be deep — it just needs to be sufficient.
And their raw material isn't code. It's text. Transcripts. Conversations. Meetings. Customer dialogues. That's their code. When you start treating that text with the same discipline developers bring to code — with context windows, with domain knowledge, with structure — something completely different happens.
The Entry Point Is Verbal
I've written about this before — about messy and crisp, about how voice input carries more information than any written prompt. When you talk freely about a problem you've lived with for twenty years, the associations come, the nuances — everything that gives AI something to actually work with. The messy input isn't carelessness. It's raw material that only someone with experience can produce.
The tools are already there. Teams records meetings. Your phone records calls. But most organizations have recording turned off by default — not for technical reasons, but out of habit. Customer service records every call. The strategy meeting that concentrates the organization's most expensive hours disappears without a trace.
And yes — Teams' own meeting summary exists. But it's skimmed milk. A generic summary that doesn't understand what mattered and what was a tangent. Without putting in your own time to reflect on what actually happened — what you heard, what you interpreted, what stood out — the summary becomes a flat list that nobody acts on. The tool does the job. But only if you do yours first.
The Investment Nobody Has Made
It's natural to start with the development team. That's where the tools land first, where speed is easiest to measure. But 12–18 months into the hype, a different pattern is starting to emerge.
The business powerusers have Copilot, sure. They have Teams summaries. But that's not what I'm talking about. Nobody has invested in showing them what happens when their twenty years of experience meets these tools for real — not as a generic summary, but as systematic treatment of text with the same rigor that developers bring to code. Developers got the investment. The business got a Teams license and a hope.
But the day they start — the day someone actually puts the tool in the hands of the person who understands the business, who has lived with the customers, who knows where the friction sits — we're not talking about 4–5x faster. We're talking about world-class. Ten times more value. Not because the tool got better, but because the right person finally got to use it.
The person who succeeds with AI is not who you think. That's worth sitting with.
I wrote in entry 16 that it doesn't start with the prompt — it starts with you. This is the follow-up: which "you" is that?
See also: You Can't Validate What You Don't Understand (entry 6) and One Person, A Thousand Deliverables (entry 7).
Mindtastic on why domain knowledge multiplies AI output — Domain knowledge multiplies AI output.