Last week the agent wrote a 200-line CSV-to-JSON normalizer with edge cases I'd have spent forty minutes on, in about ninety seconds. The same afternoon, on a multi-tenant billing edge case, it confidently produced a query that was subtly wrong in a way that would have leaked one customer's invoice totals into another tenant's dashboard. I caught it because I knew the invariant. It didn't, because the invariant doesn't exist anywhere in its training data — it exists only in my schema and my head.
Same tool. Same hour. One task it crushed; one it would have quietly broken. That contrast is the whole article.
The popular framing of AI vs senior developer is a contest of intelligence: is the model smarter or dumber than a person? That question produces nothing useful, because the honest answer is "depends," and "depends" is not a decision rule you can use at 10 a.m. with a backlog in front of you. The better question is not about the model's intelligence at all. It's about the class of task. On which kinds of work does delegating to an AI agent pay off, and on which does it cost more than just doing it yourself?
That's a different axis from the one I've written about before. Why AI Coding Widens the Senior–Junior Gap is about the level of the person holding the tool — AI as wind that feeds a fire or snuffs out a candle. This article holds the person constant. Assume a senior who knows what they're doing. The question here is: given that person, which types of task are worth handing to an agent, and which aren't? Skill level is one axis. Task type is another. This is the second one.
Strip away the marketing and there's one mechanism underneath everything that follows. A language model is an interpolation engine. It is extraordinarily good at producing the most plausible continuation inside a space that its training data covered densely. It is unreliable the moment the right answer requires extrapolation beyond that space, verification against a reality it can't see, or a model of consequences it was never given.
Almost every "is AI good at this?" question resolves once you ask: is this task interpolation inside a well-covered space, or is it extrapolation, verification, or consequence-modeling?
Hold that lens up to a task and the answer usually falls out before you've written a line of prompt. Everything below is that one distinction applied to the kinds of work a backend and SaaS engineer actually does day to day.
These are the tasks where the bottleneck was never thinking. It was typing. The right answer is well-defined, densely represented in training data, and cheap to verify by eye. Here the agent isn't competing with my judgment — it's competing with my keyboard, and it wins.
Boilerplate and scaffolding. A new CRUD endpoint when ten similar ones already exist. A new service skeleton that should look like the existing services. The shape is known; reproducing it accurately just takes time I'd rather not spend. Point the agent at two examples, ask for the third, read the diff. This is interpolation in the most literal sense — the answer lives between examples the model has already seen.
Translation between formats and languages. CSV to JSON, an API response reshaped into the internal type, a Bash script ported to a Node one-off, a jq pipeline for a log file. These are well-defined input-to-output mappings with no ambiguity about what "correct" means. There's nothing to decide. There's only the work of writing it down, and the model writes faster than I do.
Well-trodden patterns with millions of training examples. Regular expressions used to cost me twenty minutes of writing-and-testing in a REPL; now they cost two, and the model produces more readable patterns with named groups than I would by hand. First-draft SQL against a schema I describe. A standard third-party integration that thousands of repositories have already implemented the same way. The denser the example coverage, the more reliable the output.
Tests against a specification I've already written in prose. If I've described the behavior — inputs, edge cases, expected outputs — the model turns that description into test cases well. (This is different from asking it to test code it just wrote, which tests the implementation's bugs rather than the intended behavior. I covered that trap in the vibe-coded patterns piece.)
Explained code and documentation. JSDoc for code that's already readable, a narrated walkthrough of an unfamiliar file, idiomatic usage of a library I haven't touched before. The model has read more example usage of any popular library than I ever will. It collapses the search cost of "how is this normally done."
"I know exactly what I want, I just don't want to type it." This is the honest one-line summary of the whole category. The decision is already made. The model is a faster hand, not a second brain.
The thread connecting all of these: the cognitive work was already done — by me, by convention, or by the millions of examples baked into the model. What remained was mechanical, and mechanical is exactly what the model accelerates. On these tasks I'm 2–3× faster, and on unfamiliar-library work sometimes more.
Now flip it. These are tasks where the typing was never the bottleneck — the understanding was. Here the model's speed is irrelevant, because producing the answer fast doesn't help when producing the right answer was the hard part.
Novel domain invariants that aren't in the training data. The multi-tenant billing example from the opening. The model can write a flawless JOIN
. It cannot know that in this system orders are soft-deleted, scoped by tenant_id
, and that a missing tenant filter is a data-leak rather than a bug. That constraint exists in my schema and my head, nowhere in its training corpus. The work isn't writing the query — it's knowing which query is correct, and that knowledge is local and unlearnable from public code.
Architectural forks with long-range consequences. Where the module boundary goes. Whether to denormalize this field now or pay for the JOIN later. Whether this becomes a queue or stays synchronous. The model will happily pick one and implement it — locally coherent, globally arbitrary. The cost of these decisions shows up months later, in a part of the system far from where the choice was made. Modeling that distance is exactly what interpolation can't do.
Debugging that requires a causal model of the whole system. During a live production incident I turn the agent off. It generates plausible hypotheses based on general patterns, and plausible-but-wrong is the most expensive thing you can have when something is on fire. I want logs, metrics, and my own model of how this specific system fails — not a confident guess assembled from how systems fail in general.
Tasks where an invisible error is expensive. Payments, security boundaries, data migrations. The model can write a Stripe flow or a migration faster than I can. It cannot weigh the cost of the failure path, because it has no stake in the outcome and no view of the production data the migration will run against. On this code, speed is not the objective; not being wrong is, and being wrong here is often irreversible.
Taste: naming, API design, the interfaces people read for years. The model produces names that are fine. "Fine" is a problem for a public API or a core abstraction that a team will read a thousand times. The difference between a good name and a fine one is invisible on day one and compounds for years. That's a judgment call rooted in how humans will read this, which is precisely the kind of context the model doesn't carry.
Contradictory or incomplete requirements, where the first job is asking the right question. Half of senior work is noticing that the spec is wrong before writing any code — that two stated requirements conflict, that the real need is different from the stated one. The model takes the prompt at face value and builds it. It will not stop and tell you that what you asked for shouldn't exist. Someone has to do that, and it isn't the interpolation engine.
The pattern, again, is the same single distinction: every task in this list requires extrapolating past the examples, verifying against a reality the model can't see, or modeling a consequence it was never given. That's where the senior's years of failure-shaped judgment are doing the actual work — and where the keyboard was never the bottleneck.
Here is the part the productivity tweets leave out, and it's the most important caveat in this article. "Generated fast" is not "shipped fast." Between the two sits verification, and on high-stakes tasks verification is where the time actually goes.
When the agent writes a CRUD endpoint, I read the diff in thirty seconds and merge. When it writes a billing calculation, I read every conditional, test every rounding behavior, trace every failure path, and run it against real edge cases. The generation took the model ninety seconds; the verification takes me twenty minutes — and it has to, because the cost of an invisible error here is real money.
For some tasks, the math inverts entirely: verifying the model's output is slower than writing it myself would have been. When I already hold the full solution in my head, reviewing someone else's version of it — checking it line by line for the subtle deviation from what I intended — can cost more than just typing my own. On those tasks, delegation is a net loss even though it feels faster, because the visible part (generation) is quick and the invisible part (review) is where the hours hide. Recognizing which tasks those are is itself a senior skill. This is the honest counterweight to the productivity numbers. The speedups in the first section are real. They're also concentrated entirely in the category where verification is cheap. The moment verification gets expensive, the headline speed of generation stops mattering — and on a few tasks, it goes negative.
slug="technical-consultation" text="Deciding where AI belongs in your workflow — and where handing it the wheel quietly costs you more — is exactly the kind of call a short, focused consultation is built to settle."
/>
Strip the taxonomy down to something you can run in your head before each task. Before I delegate, I ask five questions:
If you want the operational version of how I act on these answers day to day — what I delegate freely, what I read line by line, what I never hand off — that's how I actually use AI coding. And the question of how to review what the agent produces is a whole discipline of its own, separate from the decision to delegate in the first place. This heuristic is about the decision. Reviewing the result is another conversation — my checklist for reviewing AI-generated code. Every line above describes a boundary that moves. Models improve, context windows grow, tooling gets better at verification. Tasks that sit firmly in the "senior only" column today drift toward "AI is fine" over time, and the drift is one-directional — work moves from the second list to the first, not back.
Two years ago, "write me a non-trivial regex with edge cases" lived in the careful-review column for me. Today it's in delegate-freely. I expect first-draft SQL against a described schema to make the same migration. The taxonomy in this article is a snapshot of where the line sits in 2026 — useful now, not permanent.
What I don't expect to move much is the root distinction. As long as these systems are interpolation engines, the categories that depend on extrapolation, on verification against a reality the model can't see, and on modeling consequences will stay hard — even as the specific tasks inside each category shift. Better models will push more individual tasks across the line. They won't erase the line. So re-run the five questions periodically; the answers change as the tools change, but the questions don't.
There's also a domain caveat I'll keep honest about: everything here is grounded in backend and SaaS work, where I actually practice. In safety-critical, embedded, or hard-realtime systems, "plausible-looking" output isn't just expensive — it's dangerous, and the boundary sits much further toward "delegate nothing load-bearing." If that's your world, this taxonomy applies more strictly, not less.