The Skill That Matters Isn't Coding. It Never Was.
Simon Willison showed up to Social Science FOO Camp last weekend without a presentation. He grabbed a slot that morning for a talk titled "The State of LLMs, February 2026 edition" and decided he wanted something special.
So the night before, he built an app.
Not a rough prototype. A fully functional macOS presentation tool he'd been wanting for years: every slide is a URL, keyboard navigation, full-screen mode, and a remote control running on his phone via a web server. He built exactly the thing he'd always wanted. In 45 minutes.
Here's the detail that matters: he built it in Swift. A language he doesn't know.
That detail is the whole point
For years, the constraint was: "I'd build this myself, but I don't know [language/framework/platform]." The knowledge gap was the bottleneck. You either learned the thing, found someone who knew it, or went without.
AI has removed that bottleneck. What remains is the part AI can't replace: knowing exactly what you need and why.
Simon didn't prompt Claude with "build me a presentation app." He specified precisely what he needed: store presentations as ordered sequences of URLs, navigate with keyboard arrows, run full-screen, serve a mobile web page over a local server so his phone could control slide transitions. He knew every feature because he'd been doing presentations for years. He understood the failure mode he was solving (a browser crash mid-talk losing his entire deck). He knew what "done" looked like.
The AI supplied the Swift. Simon supplied the judgment.
The bottleneck has moved
This is what most conversations about AI and skill development miss.
Old bottleneck: technical implementation. Getting from idea to working thing required learning specific tools, languages, and frameworks. That took time most domain experts didn't have.
New bottleneck: knowing what to build. Articulating the problem precisely. Understanding the edge cases. Knowing when "good enough" is good enough and when it isn't.
AI is very good at the first thing. It is not good at the second.
Which means the people best positioned to use AI effectively aren't necessarily the best coders. They're the people with the deepest understanding of a domain, a problem, and what a good solution looks like.
The marketing director who knows their workflow inside out. The clinic manager who has lived with the same inefficiency for three years. The operations lead who has been building workarounds in spreadsheets forever. These people have always known what needed to be built. Now they can build it.
What I've found in my own work
I'm a digital marketer, not a software engineer. When I started building my multi-agent marketing system - content monitors, SEO pipelines, publishing workflows - I had the domain knowledge, but not the time or expertise to build sophisticated automation from scratch.
AI changed that calculation.
The agents that work well in my system work because I understood the problem deeply before writing a single prompt. I knew what good output looked like. I knew the edge cases. I knew what needed human review and what could run unsupervised.
When I gave agents vague instructions, they produced vague results. When I gave them the precise, specific context that comes from actually living with a problem, they performed well.
Simon's story is the same pattern: years of doing presentations, deep knowledge of the failure modes, precise specification, then AI handles the implementation. The expertise runs the whole thing. AI just removes the language barrier.
What this means for your team
If you're thinking about AI strategy, here's the reframe: you're not just trying to make your developers faster. You're trying to identify everyone in your organisation who has deep domain knowledge and give them the capability to act on it.
That's a different conversation.
The finance person who knows exactly what their reporting process is missing. The customer service lead who has mapped every failure point in the support workflow. The ops manager who carries a mental model of the entire supply chain but has no way to build tools around it. These people have been constrained by the gap between knowing and building. That gap is closing fast.
Practically, try this: list the tools, automations, or reports your non-technical team members have been asking for. Things described as "it would be so useful if we had something that..." - things that never made it onto the development backlog because they were too small or too specific to justify a sprint.
Those are AI projects now. Not because AI will magically understand what's needed. Because the person who knows what's needed can now be the person who builds it.
The caveat worth keeping
Simon was direct about something at the end of his write-up: "This doesn't mean native Mac developers are obsolete. I still used a whole bunch of my own accumulated technical knowledge to get this result, and someone who knew what they were doing could have built a far better solution in the same amount of time."
He's right. A professional developer would have built something more robust, more secure, more maintainable.
But Simon didn't need a production-grade presentation platform. He needed something that worked, solved his specific problem, and was ready the next morning. He got exactly that.
This is the frame for evaluating AI-assisted work: not "is it perfect?" but "does it solve the actual problem?" The bar shifts depending on context. Simon's app had one job. It did that job. Everything else was irrelevant.
For SMEs, this is genuinely freeing. The standard isn't "enterprise-grade software built by a professional team." The standard is "the specific thing this team needs, working well enough to improve how we actually work."
A lot more things clear that bar than most people think.
The question to sit with
Simon Willison built the tool he'd wanted for years, in a language he'd never used, in the time between dinner and bedtime.
What tool have you wanted for years? What process has been asking for automation? What report is someone on your team building manually every week because nobody ever built the thing that would make it automatic?
Those projects just got a lot more achievable. The question isn't whether you can build them. It's whether you know the problem well enough to specify what good looks like.
If you do, the implementation is the easy part now.
Simon Willison's original article "I vibe coded my dream macOS presentation app" was published on simonwillison.net on February 25, 2026.