Agents

AI coding agents have shifted from novelty to daily utility faster than most of us expected. I’ve been using one as my primary coding interface for months now, and a few things have become clear — some encouraging, some humbling.

The best single description I have: the agent is a junior pair programmer with infinite patience and terrible judgment.

Where they shine

The tasks that used to eat my afternoons are gone. Migrations, boilerplate, exploring an unfamiliar codebase, writing the tedious version of a thing before I make it elegant — the agent does this faster and often better than I would, because it doesn’t get bored.

• Pattern-matching work. “Convert this callback API to async/await across the codebase.” Done in minutes, correctly.
• Exploration. “Where does this config get read, and who depends on it?” A question that used to be a fifteen-minute grep tour is now one prompt.
• First drafts. The agent writes a competent version, and my job becomes editing — which I’m much faster at than writing from scratch.

The productivity gain on these tasks is real and large. Anyone still doing them by hand is leaving hours on the table.

Where they break

The failure modes are consistent. The agent struggles with anything that requires holding the whole system in your head at once:

• Novel architecture. If the right answer depends on a trade-off nobody has written about, the agent will confidently produce the wrong one. It has seen a thousand blog posts; it has not seen your system.
• Bugs that cross abstraction boundaries. A bug that lives in the interaction between your ORM, your caching layer, and your deployment config is where the agent flails. It fixes the symptom in one layer and breaks the contract in another.
• Taste. The agent produces the median solution to any problem. If you want something better than median, that part is still on you.

The agent is strong where the problem is well-trodden and weak where the problem is genuinely new. Most of the hard parts of software are the genuinely new parts.

The workflow that actually works

The thing I had to unlearn: treating the agent as an oracle. Ask it a question and it will answer, whether or not it knows. The useful frame is a tight loop:

1. Describe intent, not steps. Tell it what you’re trying to achieve and let it propose an approach.
2. Review the output like a PR. Don’t trust, but don’t rewrite either. Read it critically, catch the wrong assumptions.
3. Refine in small steps. Correct one thing at a time. The agent handles incremental feedback far better than wholesale redirection.

The cycle is fast — sometimes minutes — and that speed is the actual superpower. A senior engineer running this loop ships at a pace that wouldn’t have been possible two years ago.

Where this is going

The gap between “tasks the agent does well” and “tasks that require a human” is closing, unevenly. The boilerplate layer is already gone. The exploration layer is going next. What stays — for now — is judgment: deciding what to build, recognizing when the elegant solution is the wrong one, knowing which abstraction boundary actually matters.

My current guess: the skill that compounds is not “writing code” but “directing code-writing” — the ability to hold a system’s shape in your head, spot when the agent has drifted, and steer it back. It’s a real skill, it’s learnable, and it’s quietly becoming the most valuable one in the field.

The agents aren’t taking the interesting part of the job. They’re taking the part that was never that interesting to begin with.