Coding Agents: Where Autonomy Actually Helps

For the first five years of my career I wrote every line of production code I shipped. Somewhere in the past eighteen months that quietly stopped being true. Most of what gets written about coding agents is either panic or marketing, so here is the honest map as it looks from my desk in mid-2026.

The short version: agents are exceptional at work that is wide and shallow, and still unreliable at work that is narrow and deep. Almost everything else follows from that.

Where agents genuinely earn their keep

Four kinds of work I now hand over without hesitation:

• Migrations. Framework upgrades, dependency bumps, moving a module off a deprecated library. I recently had an agent carry an aging Angular codebase across two major versions, touching a couple hundred files. The work is mechanical but wide: hundreds of small, similar edits, each one boring, each one a chance for a tired human to slip. The agent grinds through them, and the test suite plus a careful review catches the stragglers.
• Test scaffolding. Not test design, scaffolding. Fixtures, mocks, factory functions, the arrangement code around the one assertion that actually matters. I describe the behaviors I care about; the agent builds the harness around them.
• Boilerplate. CRUD endpoints, DTOs, Dockerfiles, CI config. Anything with one obviously correct shape and no interesting decisions inside it.
• Codebase archaeology. This one surprised me most. Point an agent at an unfamiliar repo and ask why a retry wrapper exists and what breaks if you remove it. It will read more code in ten minutes than I could in a day, trace the call sites, check git blame, and come back with a genuinely useful answer. I have inherited enough undocumented codebases over six years to know exactly how many afternoons that saves.

The common thread is that the task is verifiable. There is a compiler, a test suite, or a concrete question with a checkable answer at the end of it.

Where I still don't let go

Architecture, tradeoffs, and taste.

When we built an M2M SIM analytics platform at Byanat, roughly 300,000 devices pushing telemetry, the decision that mattered most was how to partition the time-series tables in PostgreSQL and which queries we were willing to make slow. That call depended on knowing what an operations engineer actually types at two in the morning during an outage. No agent has that context unless you hand it over, and by the time you have written all of it down, you have already done the hard part yourself.

Tradeoffs are similar. An agent will give you a beautifully argued case for either side of "cache this or recompute it". What it cannot do is own the consequence. When a regulator calls because a national dashboard is showing stale numbers, the agent is not in that meeting. Accountability keeps the decision human.

And taste. Agents optimize for plausible, and plausible is exactly the failure mode senior engineers are paid to catch. They will happily add a fourth abstraction layer because your prompt vaguely implied one. Knowing that a plain 40-line function beats three elegant indirections is still a human instinct, and you earn it by maintaining your own past cleverness.

The bottleneck has moved from typing speed to the quality of your specification and the rigor of your review.

From writing every line to directing and reviewing

My days changed shape. I write more prose than code now: task briefs with constraints, edge cases, and a definition of done that a machine cannot weasel out of. Then I review, and I review harder than I ever reviewed human colleagues, because agent mistakes are confidently wrong. They compile. They pass the shallow tests. They look like the code around them.

So the skill that matters in 2026 is really a pair: specifying and verifying. Specifying means saying precisely what you want, including what you do not want, before any code exists. Verifying means reading diffs fast, designing checks the agent cannot game, and knowing when a green pipeline proves nothing.

Junior engineers sometimes ask me whether this makes their path harder. Differently hard, I think. Typing was never the career; judgment was. The difference is that you now get to practice judgment earlier, on more code than any previous generation could touch. Engineers who treat agents as an excuse to stop reading code will stall. The ones who treat them as a reason to read more of it, faster, and with sharper questions, are going to be very hard to compete with.