You Can Do Anything, If You Dare
The barrier isn't expertise. It's willingness.
I am not on the bleeding edge. I am not writing LLMs. I am not publishing research papers on transformer architectures or fine-tuning models.
Where I am pretty cutting edge is in applying LLMs to actual business. Taking real problems from real clients and building real solutions. Not demos. Not proofs of concept. Working software that people use.
I keep noticing something: patterns I develop through practice show up in the tooling a couple of months later. Not because anyone is copying me. Because when you actually do the work, you arrive at the same conclusions the tool makers arrive at. They just have to build it for everyone. I only have to build it for the problem in front of me.
Your Client Is the Expert
This is the part most technical people get backwards.
A doctor who's frustrated with their EHR knows exactly what's wrong with it. They've been living with it for years. They know which workflows are broken, which screens waste their time, which data they need that the system buries three clicks deep.
They are the expert. Not me.
A teacher who knows exactly what their classroom needs. A small business owner who's been told "that would cost $200K to build." A nonprofit director who's been settling for the closest off-the-shelf tool for a decade. They all have the domain expertise. What they haven't had is someone who will listen long enough to understand what they actually need, and then build it.
The old model forced them to compromise. Development shops are expensive. Enterprise software is rigid. Every intermediary between the expert and the solution dilutes their intent. By the time the requirements doc gets translated into user stories and the user stories get translated into sprints and the sprints get translated into code, the thing that gets built barely resembles what they described.
They don't have to compromise anymore if they don't want to. They CAN have what they want.
But they have to be able to work with someone who will listen long enough without thinking they have it figured out in order to do it.
The Exchange
It's not one-directional. They're not just handing me requirements and waiting for a deliverable.
I borrow their expertise. But they borrow the patterns I have learned the hard way.
Twenty years of "here's what kills projects." Twenty years of "here's what actually ships." Twenty years of "here's the question you haven't asked yet." They get patterns they'd never encounter in their domain. I get domain knowledge I'd never develop on my own.
That's a partnership, not a vendor relationship.
Patience Is Hard to Teach
Most developers hear the first 30 seconds of a client's problem and start architecting. They think they have it figured out. They don't.
I spent 20 years in rooms where the first thing someone said was never the actual problem. You have to keep listening. You have to be comfortable not knowing. You have to let the client finish thinking out loud before you start building.
That patience is what gets you to the thing they actually need instead of the thing they thought to ask for.
AI is infinitely patient with code and infinitely impatient with ambiguity. It wants a clear prompt. I'm the person willing to sit in the unclear space long enough for the clear prompt to emerge.
That's the whole stack. The client's expertise. My patience. AI's execution speed. Remove any one and it falls apart.
The DeepSeek Lesson
Liang Wenfeng, the founder of DeepSeek, built his AI lab almost entirely with fresh graduates from top Chinese universities. In a 2023 interview with 36Kr, he explained why: "If you look at the long-term, experience is not that important. Basic skills, creativity, and passion are much more important."1
He didn't want experienced engineers telling his team what couldn't be done. He was willing to accept the risk of them messing up and learning. "Having done a similar job before doesn't mean you can do this job," he said. By 2024, his selection criteria had distilled to two words: "passion and curiosity."2
I have 20+ years of experience to mitigate the risk he was willing to absorb with juniors. But the nature of what I do now is very similar to when I was directing teams of developers. I used to orchestrate human engineering teams to build what I wanted. Now I orchestrate teams of AI agents to build what I want. The role didn't change. The execution layer did.
The advantage of that history is knowing what kills projects, what actually ships, and where the real risks are. The advantage of the new execution layer is that most of what people call impossible is just expensive. And expensive just changed.
The Dare
The gap between "I wish this existed" and "here it is" collapsed. Not gradually. Suddenly. The cost of building dropped by an order of magnitude. The barrier to entry shifted from credentials and tooling to willingness and clarity.
Machine language was abstracted into programming languages. Programming languages are being abstracted into natural language. Which means the barrier between "I have an idea" and "I have working code" is now just the ability to articulate what you want clearly.
Every professional already does that in their domain. They just don't realize it's the same skill.
I believe I will be able to take complicated work that would previously require large specialized shops. Not because I am an expert in every domain. Because I listen, can work through complexity, doubt, and uncertainty. Willingness to try, to risk, is core to the new world.
People are naturally chance-averse. That's rational. You weigh what you'll lose against what you'll gain and make the safe call. But the math here is not symmetric. The loss is bounded: some time, some money, maybe some pride. The gain is exponential.
Once you build one thing, you know you can build another. Once you solve one client's "impossible" problem, every future conversation starts from a different place. The first project teaches you the pattern. The second one is faster. The tenth one is a different career. What you lose from a failed attempt is a few hundred hours. What you lose from never attempting is the compounding trajectory of everything that would have come after.
People stay stuck because they see the downside clearly and discount the upside heavily. They plan. They research. They prepare. They tell themselves they're being careful. But planning has no value without execution. All of the planning in the world isn't as valuable as a single iteration. One real attempt teaches you more than a year of preparation. The plan doesn't survive contact with reality. The iteration does, because now you have data.
You have to start. Not when you're ready. Not when you're certain. Not when the risk is gone. The risk is never gone. You start anyway.
You can do anything. If you dare.