Something shifted at the end of 2025. Not gradually, the way model benchmarks usually improve. Abruptly.
Practitioners who had spent months correcting agent output started noticing the corrections were becoming unnecessary. Code chunks that used to require three rounds of editing came out right the first time. Prompts that would have produced hallucinated API calls six months earlier generated working implementations. Andrej Karpathy described going from an 80/20 ratio of hand-written code to fully agent-delegated, specifically in December 2025. Peter Steinberger, who had not touched a keyboard for three years after burning out, came back to building because the capability leap made it feel like a different activity entirely.
The intelligence bottleneck opened. And that made the next bottleneck visible.
Agents could reason through complex refactoring, design multi-table schemas, generate working API clients from documentation alone. What they could not do reliably was chain those capabilities across a twenty-step workflow without failing somewhere in the middle. Individual steps worked. Sequences did not.
That gap between per-step capability and end-to-end reliability is where the next eighteen months of agentic AI lives.
The maths of compound failure
Getting a single agent action to succeed ninety percent of the time feels like progress. It is not.
If a workflow has a hundred steps and each succeeds with ninety percent probability, the chance of the entire sequence completing is 0.9¹⁰⁰: roughly three thousandths of one percent. Not ninety percent reliable. Not even one percent.
Ninety-nine percent per step gets you to 36.6 percent end-to-end over a hundred steps. Ninety-nine point nine: 90.5 percent. Karpathy calls this the march of nines. Every additional nine of reliability costs roughly the same engineering effort as the last, and multi-step workflows need several nines before they become remotely useful.
Model intelligence advances in leaps. Reliability advances in nines. Each nine is earned through different engineering work: better tool schemas, tighter guardrails, verification after each step, recovery logic for the steps that fail anyway.
A team with a slightly less capable model but three nines of per-step reliability will outperform a team running a frontier model with one nine. Reliability work compounds. A model upgrade does not.
Agents compound where output is checkable
The tasks where AI agents improved fastest over the past year share a structural property: their output is automatically verifiable.
Code generation improved rapidly because every output faces immediate feedback. Does it compile? Do the tests pass? Does the type checker agree? These are automatic reward signals. The training loop has a clean gradient: the gap between expected and actual output is measurable, and the system can iterate against it.
Data pipeline validation improved for the same reason. A transformation that produces the wrong row count, violates a schema constraint, or fails a distribution check surfaces its failure automatically. The verification is structural, not subjective.
Contrast this with tasks where output quality depends on human judgement. Architecture decisions, user experience design, security review, naming choices. These improved too, but more slowly, because the feedback loop runs on human time, not machine time. A person has to evaluate the output, decide whether it is good enough, and communicate the correction.
Karpathy frames this as a predictive tool: capability spike equals verifiability multiplied by training attention multiplied by data coverage multiplied by economic value. If your task sits inside a region that is verifiable and heavily trained, the model will fly. If not, it may fail in ways that look surprising until you understand the verifiability gap.
For data engineering, this framing is useful. Pipeline correctness is verifiable. Schema compliance is verifiable. Data quality metrics are verifiable. The domains where agents compound fastest overlap with the domains where data platform teams already build verification infrastructure. Teams that invested in automated testing, data contracts, and quality gates are better positioned for agentic workflows than teams relying on manual review.
Closing the gap through engineering
Independent practitioners are converging on overlapping strategies for turning unreliable agents into production systems. The details differ. The structural pattern does not.
Verification loops
After every agent action, check the output before continuing.
This sounds obvious. In practice, most agent workflows skip it. The agent generates code, the code runs, the workflow moves on. Nobody checks whether the generated code does what was requested, only that it runs without errors.
Closing the verification loop means building checks that test intent, not execution. A data transformation that runs without errors but silently drops rows has executed successfully and failed completely. The verification loop catches the second failure.
The pattern is familiar to anyone who has built test harnesses for data pipelines: define expected behaviour, run the system, compare output to expectation, feed the delta back as a correction signal. The difference in agentic systems is that the loop runs continuously, not after deployment.
Steinberger makes the point directly: ‘Code works well with AI because it is verifiable. You can compile it, run it, test it. That is the loop. You have to close the loop.’ He structures every feature to be immediately testable, building test runners and synthetic user flows so agents validate their own work without human intervention.
Harness engineering
Verification loops catch failures after they happen. Harness engineering prevents classes of failure from happening at all.
Tool schemas with explicit parameter types and constrained enums eliminate ambiguous tool calls. Structured output formats (typed JSON, function call signatures) eliminate parsing failures. Routing logic that sends simple tasks to lightweight models and reserves frontier models for complex reasoning reduces both cost and error rate.
These are not prompt improvements. They are software engineering decisions about the system surrounding the model. The distinction matters because harness improvements persist across model upgrades. A well-designed tool schema works better with every model generation. A clever prompt may break when the model changes.
Both Anthropic and OpenAI publish detailed guidance on structuring tool definitions for predictable agent behaviour: precise parameter descriptions, explicit return types, constrained enums where the domain allows. The specific tooling matters less than the discipline: treat the harness as code, version-control it, review it in pull requests, test it against evals.
Agent-native infrastructure
Most software was built for humans navigating graphical interfaces. Agents cannot click buttons, interpret screenshots reliably, or parse marketing copy to find an API endpoint buried in a help article.
Agent-native infrastructure means surfaces designed for machine consumption: structured APIs, machine-readable documentation, CLI tools with predictable output formats, schema-described endpoints, and plain-text instructions an agent can follow without interpretation.
Karpathy illustrates this with a concrete example: an installation process that moved from bash scripts with platform-branching logic to a plain-text runbook. The agent reads the environment, diagnoses issues in-loop, and debugs its own setup. The installation ‘program’ becomes prose, not code. His framing: sensors convert world state into digital information, actuators let agents change things. The future stack is agents using sensors and actuators on behalf of people and organisations.
The compounding effect matters. Once a service becomes legible to agents, agent traffic finds it. A well-documented API with structured error responses attracts agent usage the way a well-documented library attracts developer adoption.
For data platform teams, this translates directly: metadata catalogues with machine-readable schemas, quality metrics exposed as structured endpoints, lineage graphs accessible via API rather than buried in a visual tool. The platform that an agent can query programmatically benefits from agent-driven automation. The platform that requires a human to click through a dashboard does not.
What stays human
The list of tasks agents handle competently grows monthly. Code generation, API integration, boilerplate, documentation, data transformation, test scaffolding, refactoring. Tasks that consumed most of an engineer’s week are becoming delegation targets.
What is becoming less scarce: implementation speed, API recall, first-draft generation, repetitive setup, format conversion.
What is becoming more scarce: specification design, evaluation criteria, security review, system boundary decisions, understanding why a working implementation is wrong, and recognising when a model operates outside its training distribution.
Karpathy admits he no longer remembers specific API signatures but retains the capacity to judge abstractions, design specifications, and spot subtle flaws in seemingly correct implementations. Steinberger describes the same shift: the bottleneck moved from typing to thinking. Not thinking about implementation. Thinking about what correct means in a specific context.
The shift is not from ‘engineer’ to ‘manager of AI.’ It is from ‘person who writes code’ to ‘person who defines what correct looks like and verifies that the system achieves it.’ The verification thesis again: the human contribution moves towards the parts hardest to automate, which are the parts requiring judgement about correctness in context.
This has practical implications. An engineer who can design an evaluation pipeline that catches the difference between ‘this transformation returns a result’ and ‘this transformation returns the right result for our specific revenue definition’ is harder to replace with an agent than an engineer who can write the transformation from scratch. Domain experts who define what ‘correct’ means for a specific business process become more valuable, not less.
Technical leadership here means building the verification and harness infrastructure that makes everyone else’s agent interactions more reliable. Not picking the best model. Not crafting the perfect prompt. Designing the improvement system around it.
The cost curve bends towards open models
A coding agent that generates and tests dozens of iterations per task can consume hundreds of thousands of tokens in a single session. At frontier model pricing, that is a material infrastructure cost.
Open-weight models (Llama, Qwen, Mistral, DeepSeek) are closing the performance gap on the tasks that matter for production agent workflows. Not on the hardest reasoning benchmarks, where frontier models still lead, but on structured output, code generation, tool calling, and domain-specific work. For a routing strategy that sends simple tasks to lightweight models and reserves frontier capability for complex reasoning, open models handle the high-volume tier at a fraction of the cost.
The longer-term shift is structural. Companies accumulating agent interaction traces (every correction, every successful completion, every failure) can fine-tune open models on that data. A model trained on an organisation’s own patterns and domain terminology outperforms a general-purpose frontier model on that organisation’s specific tasks. The fine-tuning infrastructure is still maturing, but the economic logic is clear: captured traces become a compounding advantage independent of any provider’s schedule.
Karpathy draws the analogy to open-source infrastructure: the industry needs an open platform layer the way it needed Linux, regardless of how capable the proprietary alternatives become. Not because open models are universally better, but because dependency on a single provider’s pricing and release schedule is a strategic risk that compounds.
Honest limits
Jagged intelligence is real. The same model that refactors a hundred-thousand-line codebase will confidently recommend a geographically impossible walking route. Karpathy’s framing: these are not animal intelligences shaped by evolution. They are statistical simulation circuits with reinforcement learning appendages. Brilliant in one moment, bizarrely wrong in the next, with no predictable boundary between the two. Every deployment needs guardrails calibrated to the specific task.
Non-verifiable tasks remain hard. Where output quality depends on subjective judgement (is this architecture sound? is this naming convention clear? is this user flow intuitive?), agent reliability improves slowly. The verification thesis cuts both ways: domains without cheap verification signals will see slower agent adoption.
Reliability engineering has diminishing returns. The first nine of per-step reliability is cheap. The second costs as much. The third costs as much again. At some point, the effort required to add another nine exceeds the value gained. Finding that threshold depends on the cost of failure in your specific context.
Agent traces are messy data. The fine-tuning path sounds compelling but requires clean, labelled data. Most agent traces are noisy: partial completions, abandoned paths, corrections that overwrite the original failure. Building the pipeline to clean and label traces for fine-tuning is itself a non-trivial data engineering problem.
The next eighteen months
Model capability will continue advancing. That is the baseline, not the differentiator.
The compounding advantage sits in three places. Verification infrastructure: the ability to check agent output automatically, continuously, against domain-specific correctness criteria. Harness engineering: the accumulated constraints, tool schemas, routing logic, and guardrails that prevent failure classes rather than catching them. Agent-native surfaces: infrastructure that makes your services, data, and documentation legible to machines, not to humans clicking through dashboards.
These are engineering investments with engineering payoffs. They persist across model upgrades. They compound with usage. They reward teams that treat agent reliability as a first-class engineering discipline rather than waiting for the next model release.
The question for the next eighteen months is not which model is best. It is whether your systems are built to make any model reliable.