What can AI do, and what can't it? A predictive map

Most attempts to answer this question produce a list, and every such list is obsolete almost immediately. Something described as beyond current systems turns out to be solved by the time you read it, while something assumed trivial turns out to be stubbornly broken. The lists fail because they record outputs rather than causes. What does not expire is the underlying structure: the properties of a task that determine whether machines handle it well, which turn out to have very little to do with how difficult that task feels to a human being. **AI capability does not track human difficulty, so the useful question is never how hard a task is for a person but whether it can be precisely specified, whether an answer can be checked more cheaply than it can be produced, whether the task is densely represented in existing data, and whether an occasional confident error is tolerable, and because those four properties vary independently and cut across our intuitions, capability is jagged in ways nobody can predict from the outside.

This guide sets out those four properties, why the popular explanation for this pattern is only partly right, what the modern dividing line actually is, why the frontier is uneven rather than a clean boundary, and how to test whether a specific task falls inside it. The aim is to leave you with a model that keeps working as the systems change.

The mental model that fails

Almost everyone starts with the same intuition: AI will manage simple things first and difficult things later, with difficulty measured the way we measure it for people. Under that model, summarising a document is easy, writing a legal analysis is hard, counting objects in a photograph is easy, and composing music is hard.

The intuition is not slightly off. It is close to unrelated to what happens. Machines reach expert-level performance on tasks that take people years of training, while failing at things a young child does without effort. A system can produce a competent analysis of a complex text and then miscount the letters in a word. It can write functioning software and then lose track of an instruction given three paragraphs earlier.

This is not a temporary quirk of immature technology. It reflects a real difference between what makes something hard for a brain shaped by evolution and what makes something hard for a system that learns statistical structure from data. Until you replace the human-difficulty model with something better, every prediction you make about AI will be unreliable in both directions, and you will be alternately astonished and disappointed for no useful reason.

Moravec's observation

The classic articulation of this comes from robotics. In the late 1980s Hans Moravec observed that it is comparatively easy to make computers perform at adult level on intelligence tests or at games like checkers, and difficult or impossible to give them the perceptual and motor skills of a one-year-old. Others working in the field made the same point in different words around the same time: the hardest things to reproduce were the ones we do without thinking.

The usual explanation is evolutionary. Perception and movement were optimised over hundreds of millions of years and run on enormous dedicated neural machinery, which is precisely why they feel effortless: the effort is real but invisible to us. Abstract reasoning is recent, is not deeply optimised, and feels laborious because it is. So the tasks that feel hard are the ones we are worst at relative to their actual computational demands, and those turn out to be the ones machines find easiest.

As a first correction to naive intuition, this is useful. It explains why exam performance arrived long before reliable robots. But it should not be the end of the analysis, for two reasons.

What is wrong with Moravec's paradox

The first problem is that the observation may be partly an artefact of what we choose to find interesting. Think of tasks arranged on two axes, difficulty for humans and difficulty for machines. Tasks that are easy for both are boring, and tasks that are hard for both are ignored as intractable. Attention concentrates on the two remaining quadrants, and if you look only at those, you will see an apparent inverse relationship that is partly a selection effect rather than a law. Plenty of things are hard for people and also hard for machines, and plenty are easy for both. The paradox is a real pattern in the cases we attend to, not a general rule about the space of all tasks.

The second problem is that the physical framing has aged. Moravec's dividing line was perception and movement against abstract reasoning, and that maps poorly onto what current systems do. The sharp modern failures are not only robotic. Systems that produce competition-level mathematics can still be unreliable at operating ordinary software interfaces, a task requiring no physical body at all and one that people find unremarkable. The line clearly is not simply mind against body.

So the honest position is that Moravec identified something real and explained it in terms that no longer carve the space correctly. The useful move is to ask what the actual dividing line is.

The modern dividing line

A better description of the current pattern is this: machines are strongest in formal, structured, verifiable environments and weakest in open, unstructured, unverifiable ones.

Mathematics and programming are the clearest cases of the first kind. They are human-made symbolic systems with explicit rules, unambiguous notation, and, decisively, mechanical ways to check whether an answer is correct. A proof either verifies or it does not. Code either runs and passes its tests or it does not. These environments provide something rare and enormously valuable: a signal that says right or wrong without a human having to adjudicate.

Operating a real interface, coordinating a multi-step task in a messy environment, or exercising judgment in an ambiguous situation are cases of the second kind. There is no formal specification of success, no mechanical check, endless irrelevant variation, and consequences that unfold over time. People find these easy because we handle ambiguity and recover from small errors automatically, which is the same reason they resist the methods that work so well in formal domains.

This reframing keeps what was right about Moravec, since perception and movement happen in the least structured environment of all, while explaining cases his version cannot. It also points at the deeper variables, because "formal and verifiable" is doing several distinct jobs at once. Pulling them apart gives the four properties that actually predict performance.

Property one: can success be specified?

The first question about any task is whether you can say precisely what a correct output would be.

Some tasks have crisp definitions. A translation preserves meaning. A number is right or wrong. A program satisfies its tests. Other tasks are irreducibly matters of judgment: is this the right strategic priority, is this design appropriate for this audience, is this the moment to raise a difficult subject. There is no specification, only better and worse answers that competent people disagree about.

Machines do very well where success is specifiable, because training and evaluation both depend on being able to say what good looks like. Where the target is contested, the system can produce something plausible and there is no ground truth against which to improve it. This is the difference between a task with an answer and a task with a stance, and it explains why systems appear far more capable in domains with settled criteria than in domains that consist mostly of trade-offs.

Property two: can an answer be verified more cheaply than produced?

This is the most powerful of the four and the least intuitive, so it is worth stating carefully. For many tasks, checking whether an answer is correct is far easier than producing a correct answer in the first place. Anyone can confirm a proposed solution to an equation. Running a test suite is cheap compared with writing the program.

That asymmetry is the engine of modern progress. When verification is cheap, you can generate many candidate attempts, keep the ones that pass, and train on those, which converts an unreliable generator into a reliable one. It is the mechanism behind synthetic training data and behind the recent leaps in reasoning, and it is why improvement has been so much faster in mathematics and code than in domains where nothing can be checked automatically. The signal comes from the verifier, not the generator.

Where verification is as expensive as production, the loop breaks. If judging whether an answer is good requires an expert reading it carefully, you cannot generate a million attempts and filter them, and you cannot measure progress reliably enough to optimise against it. This single property explains a large share of the variation in how fast different domains have advanced, and it predicts which ones will advance next better than any measure of their apparent difficulty.

Property three: is the task densely represented in data?

These systems learn from what exists. A task performed constantly and documented extensively is one they will have encountered in innumerable variations. A task that is rare, private, tacit, or simply never written down is one they will have seen little of, regardless of how simple it is.

This produces effects that look bizarre under the human-difficulty model. Systems can be strong at specialised professional writing, because a great deal of it exists in text, and weak at describing something ordinary but undocumented, because nobody writes it down. The relevant question is not how complicated the task is but how much of it made it into the record.

The property also has an important corollary. Much of the most valuable human knowledge is tacit: acquired through practice and never articulated, because the people who have it cannot fully explain it. Knowing when a situation calls for departing from the usual approach is exactly this kind of knowledge, and it is systematically underrepresented in training data for the same reason it is hard to teach. Data density therefore tracks something quite different from difficulty, and it is why competence at documented professional work coexists with weakness at the undocumented judgment that surrounds it.

Property four: is an occasional confident error tolerable?

The fourth property is about deployment rather than capability, and it decides more real-world outcomes than the other three combined.

These systems fail in a specific way: they produce confident, fluent, plausible output that is wrong, with no internal signal marking the difference, because the same process generates correct and incorrect answers. That failure mode interacts with tasks very differently depending on what an error costs.

Where mistakes are cheap and visible, a high rate of usable output with occasional errors is transformative, because the human catching them spends far less effort than producing everything from scratch. Where a mistake is expensive, hard to detect, or irreversible, the same performance is unusable, because the verification burden falls back onto a person and consumes the benefit. The capability is identical in both cases; the value is completely different.

This also explains why systems that perform impressively in demonstrations disappoint in production. A demonstration samples the common case. Production includes the tail, and the tail is where confident errors live. Tasks that tolerate the tail get automated; tasks that do not stay human-supervised regardless of average performance.

Why this produces a jagged frontier

Here is why nobody can predict this reliably from the outside. The four properties vary independently of each other and of human intuition, so tasks that feel equivalent to a person can differ enormously on the dimensions that matter.

Researchers studying professionals using these tools named this the jagged frontier: the boundary of capability is not a smooth line but an irregular edge, with systems dramatically improving performance on some realistic tasks while providing no benefit or actively degrading results on others of apparently similar difficulty. The important finding was that practitioners could not tell in advance which tasks fell on which side. More recent work on characterising this jaggedness makes the same point in terms of ability profiles: a system may show strong spikes in some domains alongside deficiencies in others, and a striking gap between headline capability and reliability on simple operations is a recurring pattern rather than an anomaly.

Two practical consequences follow. First, a system's peak performance tells you very little about its floor, so benchmark results describing what it can do at its best are a poor guide to what it does reliably. Second, because the boundary is irregular and invisible, the only dependable method is empirical: test the specific task rather than reasoning about it by analogy with a similar-seeming one.

What follows about strength and weakness

With the properties in hand, the pattern becomes predictable rather than surprising, and can be stated without naming any particular capability that might change.

Machines tend to be strong where the task is well specified, verifiable, richly documented, and forgiving of occasional error. That combination describes transformation of material from one form into another, production of drafts in well-established formats, work in formal symbolic systems with mechanical checking, retrieval and synthesis across large bodies of text, and generation of many candidate options for a person to select among. In each case the four properties line up favourably, which is why these uses became valuable quickly and quietly rather than dramatically.

Machines tend to be weak where success is contested, verification requires expert attention, the relevant knowledge is tacit, or errors are costly and hard to spot. That combination describes sustained multi-step work in unstructured environments, judgment under ambiguity where the hard part is deciding what the problem is, situations requiring reliable knowledge of one's own limits, and anything where the correct action depends on context that was never written down. The recurring theme in these failures is not that the task is intellectually demanding but that nothing external can tell the system whether it is on track.

Notice that the second list contains things people find easy and the first contains things people find hard. That inversion is the whole point, and it is why the intuitive model misleads so consistently.

Testing a task instead of guessing

Because the frontier is jagged, the reliable method is to evaluate rather than reason. A short procedure works for most cases.

Write down what a correct output would be, precisely enough that two people would agree on whether a given attempt qualified. If you cannot, the task is weakly specified and you should expect plausible output you cannot validate. Then ask how you would check an answer, and how much that costs relative to producing one. If checking is cheap, you are in favourable territory and can use the system aggressively with verification. If checking requires the same expertise as doing the work, the benefit will be smaller than it appears. Then ask how much of this kind of work exists in written form, since a task performed constantly and documented heavily behaves very differently from one that is common but never recorded. Finally, ask what a confident error costs, and whether it would be noticed, because that determines whether the output can be used directly or needs a person in front of it.

Then run a representative sample rather than a demonstration. Include the awkward cases, not the typical ones, because the typical case is where systems look best and the tail is where they fail. Whatever you conclude applies to that task and does not transfer to a task that merely resembles it, which is the practical meaning of jaggedness.

What would move the line

The map above describes structure rather than a moment, but it is worth being clear about what would change it, since the properties are not permanent laws.

Extending verification into new domains is the most consequential possibility. Wherever an automatic check can be constructed for something previously judged only by people, the generate-filter-train loop becomes available and that domain can move quickly. Much current research is an attempt to do exactly this. Expanding the data frontier into tacit knowledge is another, since capturing what practitioners know but never write down would address a structural gap rather than an incidental one. Improvement in self-knowledge would matter enormously, because a system that reliably knew when it did not know would transform the fourth property, converting confident errors into flagged uncertainties and making many currently unusable applications viable. And progress in unstructured environments, where success is not formally defined, would attack the modern dividing line directly.

What would not change the picture is raw scale alone. The four properties are about the task, not the model, so a more capable system moves the boundary outward without altering its shape. This is the same reason the general capability question resists a simple answer: generality would require strength across all four properties at once, including the ones where progress has been slowest, and current strength is concentrated where verification is cheap.

The short version

Lists of what AI can do expire quickly, but the properties that determine capability do not. Human difficulty is a poor predictor, since machines reach expert level on tasks requiring years of training while failing at things a child does effortlessly. Moravec's classic observation captured this by contrasting abstract reasoning with perception and movement, but that framing is partly a selection effect from ignoring tasks that are easy or hard for both humans and machines, and it no longer carves correctly, since sharp failures now occur in tasks needing no physical body. The better modern line separates formal, structured, verifiable environments from open, unstructured, unverifiable ones. Four task properties predict performance: whether success can be precisely specified, whether an answer can be verified more cheaply than produced, whether the task is densely represented in existing data, and whether an occasional confident error is tolerable. Verification is the most powerful, because cheap checking enables generating many attempts and keeping the good ones, which is why mathematics and code advanced fastest. Because the four properties vary independently of each other and of intuition, capability is jagged: systems help dramatically on some tasks and not at all on others of similar apparent difficulty, and practitioners cannot tell in advance which is which. The reliable method is therefore to test the specific task, including its awkward cases, rather than reasoning by analogy.

The idea to hold onto is that capability follows the structure of the task rather than its difficulty, so ask whether success can be defined, whether answers can be checked, whether the work exists in writing, and whether a confident mistake would be caught, because those four questions predict performance far better than any judgment about how hard the task seems.

Common questions

What can AI do well? Rather than a list that dates quickly, the durable answer is a pattern. Systems are strong where four properties line up: success can be precisely specified, an answer can be verified more cheaply than it can be produced, the task appears abundantly in existing written material, and an occasional confident error is tolerable because it will be caught or is cheap to fix. That combination covers transformation of material between forms, drafting in established formats, work inside formal symbolic systems with mechanical checking, synthesis across large bodies of text, and generating many options for a person to choose among. Where those properties hold, performance is often at or above expert level.

What can AI not do? Systems are weak where success is contested rather than definable, where checking an answer requires the same expertise as producing it, where the necessary knowledge is tacit and never written down, and where a confident error is costly or hard to detect. In practice that includes sustained multi-step work in unstructured environments, judgment under real ambiguity where the hard part is deciding what the problem actually is, reliably knowing the limits of one's own knowledge, and acting correctly on context that was never recorded anywhere. The recurring feature is not intellectual difficulty but the absence of anything external that can tell the system whether it is on track.

What is Moravec's paradox? It is the observation, made by roboticist Hans Moravec in the late 1980s, that it is comparatively easy to give computers adult-level performance on intelligence tests or board games and extremely difficult to give them the perceptual and motor skills of a one-year-old. The usual explanation is evolutionary: perception and movement were refined over hundreds of millions of years and run on vast dedicated neural machinery, so they feel effortless while being computationally enormous, whereas abstract reasoning is recent, unoptimised, and feels laborious. It remains a useful corrective to the assumption that AI will find the same things hard that we do.

Is Moravec's paradox still accurate? Partly, with two important qualifications. It may be somewhat a selection effect, because tasks that are easy for both humans and machines are uninteresting and tasks hard for both are ignored, so concentrating on the remaining cases creates an apparent inverse relationship that does not hold across all tasks. And its physical framing has aged, since systems that produce competition-level mathematics can still fail at operating ordinary software interfaces, which requires no body at all. The better modern distinction is between formal, structured, verifiable environments, where machines are strong, and open, unstructured, unverifiable ones, where they are weak.

What is the jagged frontier of AI? It is the finding that the boundary of AI capability is irregular rather than smooth: systems dramatically improve performance on some realistic tasks while providing no benefit or even degrading results on others of apparently similar difficulty. The term comes from a field experiment studying professionals using these tools, and the significant part was that participants could not predict in advance which tasks fell on which side. The practical consequences are that peak performance is a poor guide to reliability, and that the only dependable approach is to test the specific task rather than infer from a similar-seeming one.

Why is AI good at hard things and bad at easy things? Because the properties that make a task hard for a person are different from those that make it hard for a machine. What matters for a machine is whether success can be specified, whether answers can be checked cheaply, how much of the task exists in written form, and whether occasional confident errors are tolerable. Professional work that takes people years to learn is often highly documented and has clear criteria, which is favourable on every count. Everyday competence is often unspecified, unverifiable, undocumented because it is too obvious to write down, and unforgiving of error, which is unfavourable on every count. The inversion is a consequence of the properties, not a paradox.

How can I tell whether AI will be good at a specific task? Test it rather than reason about it, because the frontier is jagged and similar-seeming tasks can differ sharply. Before testing, answer four questions. Could you write down what a correct output looks like precisely enough that two people would agree? Could you check an answer more cheaply than producing one? Does this kind of work exist abundantly in written form? Would a confident error be caught, and what would it cost? Then run a representative sample including the awkward cases rather than the typical ones, since typical cases are where systems look best. Treat the result as applying to that task only.

Will AI eventually be good at everything? The properties described here are about tasks rather than about models, so a more capable system extends the boundary without changing its shape, and raw scale alone does not address the structural gaps. What would really change the picture is extending cheap automatic verification into domains currently judged only by people, capturing tacit knowledge that has never been written down, and improving systems' knowledge of their own limits so that confident errors become flagged uncertainties. Each of these is an active research direction rather than a solved problem, and general capability would require strength across all four properties simultaneously, including the ones where progress has been slowest.