Where agents earn their keep
The payoff is real in the parts of the job that are well-specified, bounded, and checkable. It's close to zero everywhere the actual work is judgment under ambiguity.
Two tickets. Same week, same agent, same engineer supervising.
The first: upgrade this service from Node 16 to Node 20 and fix whatever breaks. Forty minutes later there's a clean PR, the suite passes, and a human spends fifteen minutes confirming it.
The second: figure out why signups dropped after Tuesday's release. The agent produced four plausible, confident, wrong theories in a row. The engineer found the answer themselves, eventually, by reading a dashboard nobody had pointed the tool at.
Same tool. Same week. Wildly different outcomes.
The variable wasn't the model. It was the nature of the task.
The pattern underneath
Tasks that go well share three properties.
The goal is specific enough to check mechanically. These tests pass. This file matches this pattern. This endpoint returns the same structure as before. The blast radius is contained: one service, one migration, one file. And the answer, once produced, is verifiable by something other than a person's gut. A test suite, a type checker, a diff against a known-good example.
Tasks that go badly are missing at least one.
The goal is fuzzy. Make onboarding better. The scope touches everything. Refactor the auth system. Or the only available check is a human's judgment about whether the result is any good, which is exactly the check an agent can't run on itself.
That's the whole map.
Everything below is an application of it.
Where it's real
Migrations are the cleanest case. Also the most underrated, because they're unglamorous.
Framework version bumps. Renaming a method across four hundred call sites. Moving off a deprecated API, converting a suite from one runner to another. Precise definition of done, bounded scope, mechanical check. They're also the work engineers avoid, which makes them a strange kind of gift.
Test writing is the second, specifically characterisation tests against existing behaviour. Pin down what a function currently does before you touch it.
The agent doesn't need to know whether the behaviour is right. Only what it is. Much easier bar. Regression coverage on legacy code nobody wanted to write by hand fits the same description.
Boilerplate is the third. A new service following an existing pattern, a CRUD endpoint that looks like the last six, the stuff a senior engineer could write in their sleep and resents writing.
The pattern already exists somewhere in the repo. The agent's job is closer to interpolation than invention.
First drafts against a genuinely well-specified ticket, one with clear acceptance criteria and a narrow surface, also work. The tell is that a good junior engineer, handed the same ticket, would come back with roughly the right thing on the first try. If a strong junior would come back confused, the agent will too, just faster and with more confidence.
Where it's thin
Debugging unfamiliar systems under real uncertainty is the most seductive false positive. Agents are fast at reading code and will produce an explanation whether or not it's correct.
Speed of explanation and correctness of explanation are unrelated variables. The gap between them is where you lose an afternoon, chasing a plausible theory nobody checked against the actual failing request.
Architecture and anything involving a genuine tradeoff, consistency versus availability, build versus buy, which of three reasonable designs to commit five engineers to for a year, is thin for a structural reason: there's no mechanical check for "good judgment." The agent can lay out options fluently. It cannot tell you which one your organization can actually execute, because that's a fact about you, not about the code.
Incident response under time pressure is the sharpest case.
Stakes are highest exactly when the situation is most ambiguous, which is the precise combination this class of tool handles worst. A wrong guess acted on at 3 a.m. costs far more than the ten minutes it took to generate.
The mistake I made first
I assumed the killer application would be greenfield feature work, an agent building an entire feature from a product brief, because that's the demo that gets the crowd to gasp. It's also the task with the fuzziest goal, the widest blast radius, and the weakest available check, which makes it close to the worst fit on the list above. The actual value concentrates in the boring middle. Migrations, tests, boilerplate, well-specified first drafts.
None of it demos well. All of it is real.
What to do with this
Before rolling agentic tools out, sort your own backlog against the three properties. Specific goal, bounded scope, checkable outcome.
Tickets scoring high on all three are where the fast, legible win is. And a fast win is what buys the credibility to take the tooling into riskier territory later.
The tickets that score low on all three are not off-limits forever. They're just not where you start, and they're not where you point a tool with no supervision.