Still Building: Not An Expert
This is the first of three essays on building. The second is for the people doing it anyway. The third is for the maniacs.
For the last few years, I have been trying to build things with AI in domains that are not mine. Every time the work has gotten close to something that actually matters, someone considerably smarter than me has reminded me that I am not an expert.
They are usually right.
The problem is too contextual. The domain knowledge is too specialized. The edge cases are too numerous. The system is too large. The workflow depends too heavily on human judgment. The stakes are too high. The existing process evolved for a reason.
What makes these objections difficult to dismiss is that many of them are technically true. The problems are contextual. The domain knowledge is specialized. The edge cases are real. The systems are large. Human judgment matters. The stakes are high.
Modern society is built on specialization. We trust surgeons to perform surgery, pilots to fly airplanes, economists to think about economics, and security researchers to think about security. This arrangement works extraordinarily well because the world has become too complex for any one person to understand more than a tiny fraction of it. Specialization is not a flaw in how we organize knowledge. It is the only way we have found to make progress at scale.
But there is a paradox hidden inside it.
If expertise becomes the primary source of legitimacy, then nobody is qualified to create anything genuinely new. The expert in today's system is, almost by definition, an expert in the current system. They understand why things are the way they are. They understand the constraints, the history, the failed attempts, the political realities, the technical debt, and the countless edge cases that outsiders cannot see. This is not a criticism. It is a description of what expertise actually is — a deep, earned familiarity with the way something currently works.
This makes experts invaluable for operating the present. It does not necessarily make them the best people to imagine the future.
That distinction feels important, and it is more uncomfortable than it first appears. Because the implication is not that experts are wrong. The objections are often accurate. And yet, if those objections were always sufficient to stop the work, very little that is genuinely new would ever get built.
The builder is making a different bet — that the current system will eventually be replaced regardless, and that the question is not whether to wait for someone with full credentials to arrive, but whether to start now with incomplete knowledge and improve from there. These are not compatible priors. That is why the conversation tends to end the same way: the builder is reminded they are not an expert, and the expert is confident the reminder is sufficient.
I remember the first time someone walked me through everything that was wrong with what I was building. They were thorough. They understood the domain in ways I did not. Some of what they described, I had already encountered. Most of it, I hadn't. What struck me afterward was not how much they knew — it was how complete the picture felt when they described why the thing wouldn't work. The system they were defending was coherent, well-understood, and clearly the product of hard-won experience.
What they couldn't describe — because they had no reason to — was what the system looked like from the outside. From a position of not-yet-knowing. That is not a lesser vantage point. The expert sees the system so completely that its edges become walls. The outsider sees the same edges and wonders, with genuine curiosity, what is on the other side. That wondering is not ignorance. It is the only place certain questions ever get asked. And asking them — even badly, even without the vocabulary the domain has built up over years — is where new things begin.
I have never found "you are not an expert" to be a satisfying conclusion. It is useful information. It raises real questions worth sitting with. But there is a difference between the fact and the implication, and for a long time I did not have language for that difference.
For years, I walked into rooms where the default assumption was that someone else was more qualified to shape the future than I was. Sometimes that is true. Sometimes they have been in the domain longer. Sometimes they have credentials you don't. Sometimes they have organizational authority. Sometimes they have simply been there first.
And yet, almost everything meaningful gets built by people who ignored the implication of that fact. Not the fact itself. The implication.
The fact is: someone knows more than you do.
The implication is: therefore you should not try.
I have never found a good reason to accept the second.