When Exploration Becomes Free, Judgment Becomes Scarce
Companies are cutting people faster than they are proving what AI can replace.
Across the economy, companies are cutting headcount while spending billions on AI. The premise is that AI will transform work so fundamentally that many roles become unnecessary, and that a new AI-powered operating model will more than make up the difference.
But that operating model is still mostly theoretical.
The early signs are already visible. Companies that encouraged broad AI experimentation are now trying to understand what all that usage actually produced: which workflows improved, which costs scaled, which outputs could be trusted, and which systems were reliable enough to replace human work.
That marks the end of the easy phase of AI adoption.
For the last two years, usage itself could stand in for progress. Tokens were measurable. Dashboards could show which teams or employees were using AI the most. The logic was tempting: more usage meant more experimentation, more experimentation meant more learning, and more learning would eventually turn into productivity.
But a token is an input, not an outcome. High usage may mean an employee is building something valuable. It may also mean they are running unnecessary agents, writing bloated prompts, automating the wrong task, or using an expensive model to answer a simple question.
Most organizations have not yet built the systems that would justify the cuts they are making. They have pilots. They have copilots. They have individual contributors who are faster at certain tasks than they were eighteen months ago. What they do not have, in most cases, is a transformed operating model: a system that combines machine intelligence with human context, judgment, verification, and accountability.
That system still needs to be built.
The conceptual mistake is assuming that cheaper output means less need for human judgment. The operational mistake is sequence: companies are making irreversible people decisions before they have built the systems that would make those decisions safe.
When AI makes production cheap, judgment becomes the binding constraint. First, judgment is needed to decide what to automate, how to verify it, where humans belong in the loop, and how to make the system reliable. Then comes the larger question: once those systems exist, what becomes worth building that was previously too expensive, too slow, or too complex to justify?
Most companies are still early in the first step. That is why treating AI as settled replacement capacity is so dangerous. The companies that come out ahead will not be the ones that cut fastest. They will be the ones that learn how to build reliable systems first, then use those systems to expand what the organization is capable of producing.
The Easy Move and the Harder One
There are two ways companies can approach the current moment.
The subtraction mindset uses AI to do the same or more with fewer people. This is a rational move. Headcount is often the largest controllable cost, the savings are immediate and visible, and in a tight market a leaner cost structure is a defensible strategy on its own.
But cost reduction and capability growth are different goals. A company can become cheaper to run without becoming more capable. It can automate pieces of existing work without learning how to build the systems that make new kinds of work possible.
That is where the expansion mindset begins. Instead of asking only how AI can reduce the cost of today's workflows, it asks what becomes possible when teams can explore, prototype, analyze, and operate at a scale that was previously out of reach.
Subtraction improves the cost structure. Expansion moves the frontier.
But the frontier does not move simply because output gets cheaper. It moves when people apply judgment to the whole system of work: what outcome the organization is trying to improve, how the workflow actually produces that outcome today, which parts of the workflow are suitable for automation, where reliability matters most, and what new capability becomes possible if the system works.
That is why the early enterprise AI results have been so uneven. The problem is not that the models are useless. It is that building with AI at organizational scale is difficult. Many companies have rolled out copilots, pilots, and internal tools, but the value has often stayed trapped at the individual level: faster drafting, faster summarization, faster analysis, faster coding. Turning those gains into organizational value requires workflow redesign, measurement, integration, verification, and trust.
MIT's Project NANDA made this gap visible in The GenAI Divide. Despite $30 to $40 billion in enterprise spending, the report found that 95% of organizations had not yet seen measurable return from generative AI. The companies that did capture value were not simply using better models. They were adapting AI to specific workflows, measuring it against business outcomes, and embedding it into how work actually got done.
That is the difference between adopting AI and becoming AI-native. Adopting AI means giving people tools. Becoming AI-native means rebuilding the work around judgment, verification, and outcomes.
The mistake is treating AI like fertilizer: spread it across the organization and assume value will grow. AI does not create leverage by being present. It creates leverage when it is connected to real workflows, shaped by judgment, constrained by verification, and pointed at problems worth solving.
Because the best use cases are still being discovered, AI opens a genuine frontier. But frontiers do not navigate themselves. They need people who can do two different kinds of work.
The first is mapping work. This is the diagnostic work of understanding how an organization actually functions before trying to automate it. It identifies where information flows, where decisions get made, where handoffs break, where incentives distort behavior, where teams are already drowning in options, and where choosing well is the real bottleneck.
The second is operating work. This is the constructive work of turning that diagnosis into a reliable system. It redesigns the workflow, decides where the model belongs, builds the harness around it, defines what a good output looks like, and measures whether the system can be trusted at scale.
This work is not reserved for any one professional background. Engineers, designers, product managers, salespeople, support leads, and other domain experts can all learn both sides of it: mapping the real terrain of work, and operating the systems that make AI useful in practice.
Technical fluency helps. An engineer’s ability to read code, understand systems, and reason through implementation is a real advantage. But the deeper skill is broader than technical execution. It is knowing how a workflow produces value, where judgment enters, what good looks like, how trust should be measured, and whether the system can hold under real conditions.
That kind of judgment can come from many directions.
The people getting there first are not necessarily the most technically credentialed. They are the ones curious enough to understand how the work really happens, and deliberate enough to make the new systems trustworthy.
AI commodifies exploration
AI commodifies exploration. This is the real shift.
Drafts become cheap. Prototypes become cheap. Code becomes cheap. First attempts become cheap. Dead ends become cheaper to test. A founder can explore product directions before hiring a team. A product manager can prototype a workflow before asking engineering for cycles. A designer can generate a working version of an interface instead of stopping at a mockup. A researcher can test more hypotheses in a week than was previously possible in a quarter. A developer can build in languages they barely know because the model can translate intent into implementation well enough to get started.
This is the moment of the generalist. When a platform is new and the rules are still being written, breadth beats depth. Eventually the tooling will solidify, organizations will restructure around it, and specialization will return. But right now the advantage belongs to whoever can learn fastest and go deepest where it matters most. The catch is that AI fluency alone is not enough. Domain knowledge is still what makes output evaluable. Someone who knows the field but not the tools is slower. Someone who knows the tools but not the field cannot tell good from bad. The person who knows both can move the capability frontier for their entire team. For teams that have the domain knowledge but not the fluency, the move is not to wait. It is to find someone willing to learn the domain alongside them, not just build on top of it.
For companies, this means teams can be smaller without doing less. Some roles will absorb work that previously required a separate function. But it does not mean there is less work to do. The opposite is closer to the truth.
Economists call this the Jevons Paradox: when a resource becomes cheaper, consumption tends to go up, not down, because efficiency unlocks demand that did not previously exist. Steam engines did not reduce coal consumption. They made steam power viable in so many new applications that coal use exploded. AI is doing the same to cognitive work. The frontier of what is worth attempting expands. Teams take on more ambitious roadmaps. Companies run analysis on every customer interaction instead of a sample. The volume of work that needs to be directed, reviewed, and acted on grows alongside the volume that can be produced.
The work does not disappear. It compounds.
That changes how teams are built. It also changes where individual contributors create value.
The valuable person is the one who knows what good looks like. Domain knowledge, taste, and judgment do not become less important when a person can project them across more surface area. They become the whole point.
The leverage is real. One person with AI can now explore more options in a day than a team could have explored in a week. But when exploration becomes cheap, the bottleneck moves to the human operator.
The scarce work is no longer producing the first version. Cheap production does not reduce the demand for discernment. It expands it. The more options AI can generate, the more judgment is required to select, evaluate, and act on them. What matters now is deciding what deserves a second version: which problem is worth solving, whether the output is actually good, and whether the result can be trusted.
A model like Claude or ChatGPT can generate options: code, plans, summaries, classifications, analyses, workflows. But the target is set by a human.
Models are powerful readers and writers, but both depend on human judgment. As readers, they can process far more text than a person can hold in mind, but only what they are given: someone has to decide which context matters, which source to trust, what to leave out. As writers, they can produce the memo, the plan, the prototype, but always toward a goal a human supplied, and every output still has to be judged against that goal, edited, rejected, or acted on. The model collapses the time required to produce a first version. It can also expand the volume a human has to evaluate.
That is why AI can make a person more powerful without making their day feel lighter. The bottleneck moves from production to discernment.
Better models improve the quality of exploration. They do not decide what is worth exploring.
That is why the human role in this transformation is structural, not transitional.
Navigating the Jagged Frontier
The frontier is jagged.
That phrase comes from a 2023 Harvard Business School study with Boston Consulting Group that tested how consultants performed when using AI across different kinds of tasks. The researchers found that AI helped on some work and hurt on other work, even when the tasks looked adjacent. But the jagged frontier has become more than a research finding. It is how AI actually behaves when applied to real problems.
AI is strong on some tasks and weak on adjacent ones. Tasks that are difficult today may become routine tomorrow. But AI does not automate jobs. It automates tasks, and it does so unevenly. The boundary runs through individual workflows, not around whole professions.
A human job is not a single task on paper. It is a bundle of tasks, decisions, relationships, context, judgment, and accountability. AI advances through that bundle unevenly.
In software, AI can generate code quickly. But there is a difference between code that works and code that is good. Working code may solve the immediate problem, but if it does not fit the system, it can create new problems as the system grows. Good code fits within the system: it is secure, maintainable, testable, observable, and understandable by the next person who has to change it. As generation gets cheaper, knowing what good code looks like is the difference between producing code that works once and engineering a system that provides lasting value.
In customer support, AI can summarize tickets, suggest replies, and handle routine issues. But a generated answer is not a resolution. Good support reads the customer's history, the real source of frustration, and the risk of escalation, and knows what has to happen next, not just what reply to send.
In sales, AI can prepare account briefs, summarize calls, draft follow-ups, and surface deal risks. But a generated artifact is not a sales motion. Good selling reads the buyer, the politics of the deal, the real blocker, and the next move that builds trust rather than simply generating activity.
This is why the sequence matters. AI is advancing through tasks, not jobs. Some roles will change. Some will disappear. But companies that cut headcount at scale before their own AI workflows have proven out are making irreversible people decisions based on reversible assumptions. The data does not yet support treating that bet as settled.
Some tasks become automated. Some become augmented. Some become more valuable because the surrounding work got cheaper. When companies cut the whole role, they risk removing the person who understood how those pieces fit together.
They are deleting the bundle before understanding what the bundle contains.
The frontier moves where verification gets cheaper. But verification is uneven too.
In software, failure detection is often direct. The code crashes. The workflow times out. The response is empty. A test fails. A deployment breaks.
In sales and support, the signal is messier. Did the AI-generated reply actually resolve the customer's problem, or did the customer give up? Did the account brief help the rep move the deal forward, or was the buyer already ready to act? Did the suggested next step create trust, or did it simply generate activity?
Failure can be obvious. Correctness is harder. Is the answer true? Is it complete? Is it safe? Is it grounded in the right sources? Is it appropriate for this customer, this account, this case, this moment?
The same research that named the jagged frontier found something else worth noting. When consultants used AI on tasks outside the frontier, tasks the model was not equipped to handle well, they performed worse than consultants who used no AI at all. The authoritativeness of the output made them stop evaluating. The risk is falling asleep at the wheel: the system appears capable enough that people stop doing the judgment work around it.
There is a structural reason this happens. When a model is trained, feedback is automated: labeled data and benchmarks tell it whether it got the answer right at scale. In deployment, that loop mostly disappears. Whether an output is correct, useful, or trustworthy depends on business context, user intent, and real-world outcomes that no benchmark captures. Evals help, but evals have to be designed, interpreted, and acted on by people. Without human judgment in the loop, a deployed system has no reliable way of knowing when it is wrong. The human is not just the end user. The human is the feedback loop.
This is where the harness matters.
The model is the capability layer: it generates the answer, summary, classification, plan, code, recommendation, or next action. The harness is the reliability layer: the system around the model that decides what context it receives, what tools it can use, how its output is checked, when a human reviews it, what happens when it fails, and whether the workflow actually produced the intended outcome. Tests, evals, logs, traces, cost controls, permission boundaries, review queues, fallbacks, routing, monitoring, workflow design, and outcome measurement are all parts of that harness. It is not QA bolted on afterward. It is the feedback architecture that turns model output into trusted work.
This distinction matters even more as companies move from copilots to agents. An agent is not a harness. An agent is a participant inside one. Agents can take actions, call tools, chain steps, and operate with some degree of autonomy. But an agent still needs evals to measure whether it is doing the right thing, monitoring to catch drift, fallbacks for failure, and human judgment to decide what it should optimize for in the first place. An agent without a harness is just automation with more surface area for failure.
That is why this is ultimately a systems problem. Donella Meadows’ core insight in Thinking in Systems is that a system’s behavior comes less from its individual parts than from the relationships, feedback loops, incentives, delays, information flows, rules, and goals that connect those parts. To change the outcome, you have to change the structure that generates it.
That maps directly onto AI. The model is one part. The system is the workflow around it: context, data, routing, evals, permissions, review loops, escalation paths, incentives, and human judgment. Output quality comes from the whole system, not the model alone.
Dropping a better model into an existing workflow changes a component. Building the harness around it changes the structure of the work.
But the harness is not something a company builds once and leaves alone. The work changes. The model changes. The users change. The failure modes change. The incentives change. The business goal changes. So the harness has to keep changing too.
Deciding what the system should optimize for is a human role. Agents can help monitor, summarize, test, and surface anomalies. But humans decide which failures matter, where the thresholds should move, when automation has gone too far, and what tradeoffs the company is willing to accept.
What gets measured? What gets escalated? What gets blocked? What gets learned? What happens when the model is wrong? What outcome proves the workflow worked?
The harness is the answer to those questions made concrete, and then kept alive through human judgment.
It is also what makes the frontier movable. A task that is unsafe with raw model output may become safe with retrieval, source citations, structured outputs, confidence thresholds, human review, and monitoring. A workflow that once required an expert at every step may become usable by a broader group if the expert's judgment is partially embedded into the system: into the evals, the prompts, the escalation rules, the review criteria.
The harness takes judgment that lived in people's heads and gives it structure. The repeatable parts become process. The rote parts become automation. The scarce judgment becomes easier to apply repeatedly.
Expertise does not disappear. It moves into the system.
What Building with AI Taught Me
The argument is not theoretical. I spent the past year building Backdrop, an AI pipeline that tracks high-signal news and turns fragmented coverage into trackable narratives and analyst-level briefings.
Building with AI can make it feel like the hard part is prompting the model. It is not. The hard part is knowing what the system should do, what good looks like, and how to keep it working reliably while maintaining visibility into what it was actually doing.
The problem I was using AI to solve was simple: keeping up with news narratives manually was too slow. Information was fragmented across sources, published continuously, and difficult to correlate in real time.
A basic summarizer would have made the old workflow faster. But the more interesting opportunity was to build a system that could continuously ingest articles, extract entities, cluster narratives, detect signals, and generate briefings around the clock. That was not just automation. It was new capability at a cadence and quality I could not have matched on my own.
That choice is the part the reliability story leaves out, and it is the second shift this essay is really about. There were two questions in front of me, not one. The first-order question was whether I could make a system like that trustworthy. The second-order question is the one that is easy to miss: once continuous ingestion and narrative clustering were cheap enough to even attempt, what was worth building that I would never have proposed a year earlier? A faster summarizer was the old job, accelerated. A system that watches every source continuously and surfaces narratives as they form was a capability that did not exist for me at any price before the cost of exploration collapsed. Cheap production did not only lower the cost of the thing I already did. It changed what was worth doing at all.
But that new capability did not arrive all at once, and this is the order that matters. The second-order opportunity only becomes real once the first-order problem is solved. A system has to be reliable enough to trust before its new capability is worth anything.
AI made that exploration possible. But the useful system was not just API calls to models wrapped in a website. It was an architecture designed to constrain the models it used: each model call had a specific job, structured inputs, structured outputs, and boundaries the rest of the system could verify.
Every automation created a new control loop. Costs had to be tracked. Models had to be routed by capability tier, with lighter methods handling simpler tasks and stronger models reserved for steps that required them. Outputs had to be structured precisely because one model call's output became the next step's input. Bad formats broke the pipeline. Bad briefings had to be caught before they surfaced. Duplicate narratives had to be merged. Failures needed fallbacks. Traces had to show what happened and why. The system needed trust boundaries between what a model could infer, what the system could verify, and what a user should trust.
Early on, I treated the model as the solution to every step in the pipeline. Costs spiraled fast. The useful question turned out to be not which model to use, but whether to use a model at all. You cannot answer that from first principles. You have to build evals, benchmark outputs against defined quality criteria, identify where a lighter method holds, and reserve the model for the steps that actually require it. Classification and keyword extraction could run on lighter, faster methods. Narrative construction, where multiple threads had to be pulled into a coherent briefing, required the stronger model. That process is what turned a collection of API calls into something closer to a harness.
The work did not vanish. It moved up.
I was no longer manually reading articles. I was designing control loops, writing evals, debugging enrichment pipelines, building cost monitors, and deciding what confidence threshold warranted surfacing a result.
The ceiling of what I could attempt rose. So did the complexity of making the system reliable.
Models are stochastic by design. The same input does not always produce the same output. They can return something that looks right but is not, and costs can grow before you notice. In any real deployment, reliability and cost predictability are not nice to haves. They are requirements.
That is the part the "AI replaces work" frame misses. AI can collapse the cost of generating output, but that cost does not disappear. It shifts. Reliability and observability are requirements of any AI system, and they do not come with the model. They have to be designed, instrumented, and maintained by humans. The model creates possibilities. The harness turns some of those possibilities into trusted work.
News was a useful test case because it behaves like many knowledge workflows. Information streams in at a scale no human can match. AI can filter at machine scale. But a human is what builds the filter. In any knowledge workflow, the value is not in processing every input. It is in deciding what the system should look for, how it should cluster what it finds, and what should rise to the surface as something a person can act on.
That is the pattern at organizational scale too.
A workflow can cost dramatically different amounts depending on context size, retries, model choice, failure rates, and how much output gets corrected or discarded. Token spend shows consumption. It does not show whether value was created. That is why AI cost has to be measured at the workflow level, not the token level.
The honest metric is cost per completed outcome compared against what it replaced. An AI-resolved support ticket compared with a human rep handling the same issue. An account brief researched and qualified by AI compared with a sales rep manually pulling customer data before a call. Everything else follows the same logic.
That number connects model usage to business reality. And over time, the data behind it becomes something more than a cost metric. The traces, the corrections, the escalations, the thresholds that got adjusted: together they become a system of record for how the organization actually decides. That is the beginning of an intelligence layer that scales institutional knowledge and moves the capability frontier.
Backdrop taught me this at small scale. Uber is working through a version of the same problem at enterprise scale. After encouraging adoption with an internal leaderboard that ranked teams by total AI tool usage, the company burned through its entire 2026 budget for AI coding tools in four months. Nearly all of its engineers were using the tools and most committed code was AI-generated. And yet its COO said publicly that the link between that usage and improvements customers could feel was "not there yet." The input maxed out. The outcome it was supposed to produce did not automatically follow.
The pattern is the same at every scale. Exploration is cheap. A $20 monthly subscription buys near-infinite iteration: drafting, researching, prototyping, asking hard questions, and getting instant answers in a browser chat window. That phase costs almost nothing. But moving from exploration to building changes the cost curve entirely. Token spend scales with every pipeline step, every retry, and every model call that has to be corrected or discarded. The gap between generating output and producing trusted, reliable, cost-predictable outcomes is exactly where the harness lives. The bill can arrive before the value is proven.
The Rational Trap
Companies are not failing at AI because the technology is not ready. They are failing because the organization is not.
They are spending heavily on copilots, assistants, agents, and transformation programs, but many still evaluate AI through the old business logic: productivity, cost reduction, headcount leverage, faster versions of the same workflows. It makes sense. There are customers to serve, margins to protect, and quarterly results to report, and AI can make the old business more efficient quickly and visibly. The temptation is to stop there.
The local logic is sound. A company looks at a workflow and sees tasks it can automate: the model summarizes the ticket, the agent drafts the reply, the system generates the brief. The cost of the human doing that work is visible. The savings from removing it are visible. Taken individually, none of these decisions is irrational. Taken together, they misread how AI works, because the cost that is hardest to see is the cost of building and maintaining the system that replaces the human.
That system still needs an owner. A person has to define quality, maintain the evals, watch the traces, tune the thresholds, handle the edge cases, and decide when the agent is creating value rather than simply generating activity. And it cannot be one AI expert brought in from outside. Each system touches multiple domains, and the knowledge and context are distributed across the business, so the work of maintaining them has to be distributed too.
This is how rational choices accumulate into strategic failure. Each local decision looks disciplined. A task was automated. A cost was removed. A margin improved. But across the company, the people who understood the workflow, carried the context, and could maintain the harness have been thinned out. The company becomes smaller, cheaper, and more efficient, and less capable of exploring new products, entering new markets, or even maintaining the systems it now depends on.
They become short-term winners with long-term vulnerability.
The point is not that every job survives. Some are already becoming unnecessary, and more will. The point is that the work only humans can do does not disappear. It moves. Automating rote work is table stakes. Moving the frontier outward means realizing outcomes that were previously impossible, and that takes imagination, which belongs to humans.
The real test of the AI-native company is not whether it can reduce headcount, deploy copilots, or announce agents. Those are inputs. The real test is whether the company becomes more capable. Can it see more of its own work? Can it explore more ideas? Can it turn expert judgment into repeatable systems? Can it verify outputs that once depended on trust alone? Can it attempt products and workflows it could never have justified before?
The model does not know the goal. The model does not own the customer. The model does not understand the tradeoff the business is willing to accept. The model does not decide what failure matters. The model does not carry accountability.
People do.
That is why the future of work is not simply a story about replacement. It is a story about where human judgment moves.
AI-native should not mean humanless; it should mean that human judgment travels farther than it could before.