On Sunday, Andrej Karpathy — one of the founding members of OpenAI, the former director of AI at Tesla, and now at Anthropic — posted some napkin math on X about how differently people now experience AI. He called it “a sharp funnel.” By his estimate, roughly 75% of the world’s population has barely come in contact with these models at all. Another 20% or so are casual users of free chatbots, who treat them “a bit like a better Google search” or a drafting and writing aid, and often come away disappointed with the results. And then there is a thin sliver at the bottom of the funnel, professionals using frontier models for math and code: “Somewhere around 20M people (0.2%) see first-hand that large, complex projects that used to take them weeks/months can now be completed by agents with a prompt.”
If you happen to be in that 0.2%, or even visiting it as a tourist, you know how addictive this feels. People who never touched a line of code are building tutorials, dashboards and working applications in plain English. A friend of mine who is a musician by trade has been building an application with Claude Code that would put some developers to shame. For anybody who has spent time with Claude Code or OpenAI’s Codex, the experience is nothing short of spectacular. And every time we build a demo for a client now, the dynamic flips: instead of telling them what we are going to build, or what their operations might look like, we can simply show them, right away. There is no excuse not to.
You see the same excitement on stage at AI events. Someone plugs in a laptop and shows you some kind of “system brain” for organizing your personal life, or an operating system for small businesses, or a tool that takes a company’s scattered procedures and turns them into a coherent operating manual.
Your first reaction is genuine delight. A few years ago that demo represented a team and at least a few months of development; today it represents one person, a weekend, and a lot of nerve. Software itself is being solved in front of our eyes. This is very exciting, as more and more of us become builders using plain English, creating cool stuff for ourselves and for others.
Yet every time I watch one of those demos, the same thought stays with me: the build was the easy half. When building gets cheap, the hard part does not disappear. It moves.
Take data scraping as an example. Let’s say you want to pull posts from a social network to see what people in your industry are talking about, to keep an eye on what competitors announce, or to build a list of sales leads. If you need that once, an AI assistant can often write you a working scraper in minutes; you run it, you get your spreadsheet, and you are done. For a one-off, it works great. Turn the same scraper into a tool that you, or your customers, rely on every week, and it is a different story. The social network changes how its pages are built, tightens who is allowed to see what, or caps how much anyone can pull in an hour. The scraper quietly starts bringing back less, or nothing. Somebody has to fix it, and then do it all again the next time. The build took an afternoon. The maintenance never ends.
And maintenance is only where the difficult half starts. The rest of it, as far as I can tell, comes in three pieces: understanding the work, the user interface, and change management.
Understanding the Work You’re Building For
If a founder walked into my office tomorrow and showed me a prototype built over forty-eight hours, I would focus these days on asking four questions, in this exact order:
What specific assumptions about your customer’s workflow and the user experience did you bake into this feature set?
Are those assumptions documented anywhere?
How, specifically, do you intend to test them?
Do you have an operating mechanism to integrate what the market teaches you?
Those questions are the ancient, stubborn disciplines of product design. They matter far more today than they did five years ago, precisely because the friction of building stopped acting as a natural filter.
To answer these questions and more, you will need to be spending hours interviewing management and frontline staff to understand the messy, unwritten exceptions in their workflow, and setting up real, objective measurements to track how the workflow performs before and after you touch it. Both still require a human touch.
The User Interface
This is the piece I believe is most dangerously underestimated.
Every business owner I have ever worked with runs their company by a handful of numbers, like capacity utilization, hourly rates, months of cash runway, lead times, yield or cost per unit, depending on the business. And what that owner wants from software has never been a huge executive dashboard, but the ability to ask a direct question in plain English: Why did we have a bad month last month? Is it an anomaly, or do I need to worry? And what should we do about it?
To be perfectly clear, building a system that can take a plain-English question and instantly spit out five paragraphs of plausible text is now easy. Building one that answers accurately, finds the real cause, and is honest enough to say “I do not have enough data yet to tell you whether this is an anomaly” is much more difficult.
To take matters even further, I have not seen many products designed for the way different people like to work. Some executives want a guided, conversational Q&A to test their assumptions aloud; others want three bold bullet points and zero small talk. Both are entirely valid, and modern models can do both. Deciding which one fits the work, and checking it with the person who actually uses it, is still a human job.
Do we really need to settle for generic interfaces that force human beings to bend to the machine, or can we build adaptive systems that flex to how each operator actually thinks?
Change Management
Even a perfect interface does not get used by itself; people have to actually change how they work. For a small or mid-size company, I suspect a fair budget is something like a dollar spent helping people change for every dollar spent on the AI itself. In BCG’s survey of nearly 12,000 workers this June, 42% of frontline employees who use AI regularly said it saves them a full workday or more every week — and 66% said they get limited or no guidance on what to do with that time.
Ethan Mollick made a related point last month: “Even if AI development stopped today, we’d have years of catching up to do.” His argument is that the gap between what current models can do and what almost anyone is using them for is already vast. I would take it one step further. I think that gap comes down to two things: the interface, and change management — bringing the rest of your organization along.
So who comes out ahead? The winners will be the teams that solve the user experience — software that meets an operator where they are, presents the right signal at the moment of decision, and gets out of the way.
And that is not even to mention system security, data privacy and data governance, which I will talk about in a separate piece.
None of this is meant to discourage you from building new prototypes. Build the prototype. Build it this weekend. Use Claude Code, Codex, or whatever agent you have at your disposal to bring your idea into the world. The collapse of production friction is an unreserved blessing, and visiting Karpathy’s 0.2%, even as a tourist, is a genuine thrill.
Just remember to send a postcard home. The 0.2% is a wonderful place to visit, and it is very easy to lose track of time there, swapping agent tips with the other tourists. Meanwhile the other 99.8% are right where you left them — including, unless you run a software company, almost everyone who works for you. Which is a little awkward, because if I remember the original pitch correctly, making their lives better was the whole point.