Is AI overhyped? Start with the work people are actually doing

On October 11, 2026, Andrej Karpathy argued that the gap in people’s experience of AI was widening. His model is a funnel: many people have little contact with language models, fewer use them casually, a much smaller group uses advanced models professionally, and a tiny group has access to internal systems.

He calls the population figures “Napkin math.” His estimates include roughly 6 billion people with little exposure, 1–2 billion casual users, about 20 million professional users of advanced systems in coding and math, and around 5,000 people with internal access. These are his rough estimates, not a measured adoption survey or independently verified population counts.

The stronger part of the argument is the distinction between experiences. A person asking a chatbot to rewrite an email is testing a different task, environment, and level of autonomy from someone asking an agent to work through a software project. Neither experience, on its own, measures what AI can do across every kind of work.^[2]

The idea, explained

Karpathy points to three drivers: the ambition and length of the task, the domain, and access to the system. They help explain why upgrading the model is only one part of changing the experience. Giving a more capable tool a trivial task may reveal little about its strengths; giving it a difficult task without a way to judge the answer may reveal little about its reliability.

Consider a hypothetical software task: adding a search filter to a small application. One setup asks a chatbot for a code snippet, leaving a person to place it, run it, and diagnose errors. Another gives an agent the project files and tools to edit and test the change. Even with similar models, those setups distribute the work differently. This is an illustration of the distinction, not a test performed for this article.

Coding also offers checks such as running the application and testing expected behavior. Passing a few tests does not prove the whole change is correct, but it provides feedback that a polished paragraph alone cannot. Karpathy’s argument is that capability develops unevenly across domains, especially where outputs can be checked and the work is economically valuable.

That helps explain divergent reactions without turning the funnel into a hierarchy of whose opinion counts. An impressive result in coding does not establish equal reliability in research, judgment, or a task with ambiguous success criteria. A disappointing chatbot answer does not measure every agent workflow either.^[2]

“So, the next time someone tells you what AI can or can't do, ask yourself which part of the funnel they're standing in and where you are.” Watch at 2:08 ↗

Before accepting either enthusiasm or skepticism about AI, I want to know which tool, which task, and which working conditions produced that view. A sweeping claim becomes easier to assess once the actual work is clear.

The point is to make the comparison more specific. Someone who has saved time on a repeatable coding task has evidence about that task. Someone who spends longer correcting an unreliable output has evidence about theirs. Both observations matter; neither needs to become a verdict on all of AI.^[1][2]

What to take away

Choose one real task you understand and define what a successful result looks like before starting. For the search-filter example, that might mean correct results, a working empty state, keyboard access, and no broken existing behavior. Use the same requirements when comparing your usual process with an agent-assisted one.

Record the tool and model, access tier, instructions, time spent preparing the task, time spent checking and correcting it, and any remaining errors. Count the whole job rather than only the generation time. This is a suggested evaluation method, not a claim that we have run the experiment.

That gives you a better question than whether AI is overhyped: did this workflow finish this job at an acceptable standard, with less total effort? Repeat the comparison on another task before generalizing. The funnel explains why experiences differ; your own evaluated work tells you which differences are useful to you.^[1][2]