Intelligence is being commoditized, at least for some tasks. The cost of reaching a given level of performance on standard AI benchmarks has fallen sharply. I expect that trend to continue. I would not assume it will proceed evenly.
Most conversations about AI start with the wrong question. Executives ask, "Can AI do this task?" The question I find more useful is: "Can we verify that AI did this task correctly?"
That distinction matters more than most people realize.
The Commoditization of Intelligence
Think about what the Industrial Revolution did to physical strength. Before mechanization, the strongest person in the village had real economic advantage. After? Strength became table stakes. Anyone could rent a tractor.
We are watching the same thing happen to certain types of cognitive work. The ability to synthesize information, draft documents, analyze data, write code . . . these are becoming commodities. Not worthless, but no longer scarce.
The implications are significant, but they are also uneven. Not all tasks are affected equally. Which brings me to what I have started calling the "jagged edge."
The Jagged Edge
AI capability is not a smooth surface. It is jagged.
The models are remarkably good at some things and surprisingly bad at others. They perform well on many competition math problems and certain types of coding. They can still struggle with tasks that seem trivial.
More importantly, different tasks improve at different rates. Strong results on competition math benchmarks do not mean mathematics is solved. Translation between widely used languages can be useful, but that does not establish reliability in languages with little training data.
The pattern is easier to understand if you look at the conditions around the task.
AI tends to improve faster when the task is digital (not physical), data is abundant, and the task is similar to things humans find tractable.
AI may improve more slowly when the task requires physical manipulation, data is scarce or proprietary, or the task involves edge cases with limited examples.
I do not expect a single moment when "AI takes over." I expect a gradual, uneven transformation. Software development is already being augmented. Hairdressing and plumbing require physical work in changing environments, which makes the path to automation less clear. The economic returns to skilled trades may increase relative to some knowledge work. That is a possibility, not a forecast I would rely on.
The practical question for any institution is: where do your critical tasks sit on this jagged edge?
Verifier's Law
Here is the framework I find most useful for evaluating AI projects.
There is an old idea in computer science called asymmetry of verification: for some tasks, it is much easier to verify a solution than to find one. Sudoku is the classic example. Solving it is hard; checking if a solution is correct takes seconds.
I have started calling this principle "Verifier's Law" when applied to AI adoption. I mean it as a working heuristic, not a mathematical relationship:
AI is easier to deploy responsibly when its output is easier to verify.
This sounds simple, but the implications are profound.
Consider a simple matrix. On one axis: how easy is it for AI to perform the task? On the other: how easy is it for a human to verify the result?
The best projects sit where AI performs well and verification is practical. Examples include bounded code changes checked against requirements and relevant tests, document drafts checked against their sources, and form fields compared with source records.
The dangerous projects demand verification that is expensive or difficult to provide. Insurance claims adjudication at scale, medical diagnosis without physician review, and legal document analysis with no human checkpoint all raise this concern. The stakes make verification demanding even when the output appears convincing.
I was recently in a conversation where someone mentioned a lawsuit against a major insurer for AI-driven claim denials. What stayed with me was the asymmetry: processing decisions at scale is one problem; checking each decision is another. The cost of verification belongs in the deployment decision.
Practical Application
So how do you use this framework?
First, map your candidate AI projects on both dimensions. For each potential use case, ask: Where does this sit on the jagged edge? Is AI currently good at this, or are we hoping it will get good? How easily can we verify the output? Is there an objective check, or does verification require as much effort as doing the task manually?
Second, start where verification is cheap. The boring projects are often the best starting points. Form auto-completion. Document summarization with human review. Code suggestions that developers can accept or reject. These will not make headlines, but they offer a practical place to test the framework.
Third, be honest about verification costs. If you are considering a project where AI can easily perform the task but verification is expensive, slow, or subjective . . . proceed with extreme caution. This is where the lawsuits come from. This is where trust erodes.
Fourth, build verification infrastructure before you need it. One insight that has emerged from recent conversations with healthcare CIOs and state technology officers: you can sometimes move a task from "hard to verify" to "easy to verify" by investing in verification infrastructure upfront.
Code is easier to verify if you have comprehensive test suites, although passing tests does not establish correctness beyond what they cover. Claims processing is easier to verify if you have clear decision trees and audit trails. Form rejection provides immediate feedback on acceptance, but an accepted form can still contain incorrect information.
The institutions that will do best with AI are those that invest in verifiability before they deploy AI at scale.
A Note on Synthetic Data
One more tactical point. If you are exploring AI in a regulated environment, consider what I call the "special projects" approach: use synthetic data to test and iterate before touching production systems.
This does two things. First, well-designed synthetic data can reduce exposure to real personal information, though it does not remove every privacy or compliance concern. Second, it gives you a controlled environment to explore where AI sits on the jagged edge for your use cases. The results still need to be checked against production conditions before deployment.
The goal is to fail cheaply, in a sandbox, rather than expensively, in production.
What This Means
I do not think AI will replace most knowledge workers in the next few years. I also do not think it is a passing fad that can be safely ignored.
What I do think is that institutions which adopt a disciplined framework (understanding the jagged edge, respecting Verifier's Law, investing in verification infrastructure) will navigate this transition better than those chasing headlines or paralyzed by uncertainty.
The question is not "Should we do AI?" The question is "Which AI projects can we verify well enough to use responsibly?"
Start there.