I was skeptical of AI coding tools for a long time, and the early ones earned it — autocomplete that confidently invented APIs was a net tax on a codebase I knew well. Agentic tools changed my mind, not because the models got smarter (they did), but because the interaction model changed: instead of predicting my next line, an agent takes a task, reads the codebase, runs the tests, and iterates against real feedback. After a year of using Claude Code daily on production systems, my workflow is genuinely different. Here's the honest accounting.
The unit of delegation changed
The shift isn't speed of typing — it's granularity. I used to delegate nothing smaller than a ticket; now I delegate tasks in the awkward middle: 'add tenant_id scoping to these five queries and update the tests', 'trace why this webhook handler double-fires under retry', 'migrate this module from Guzzle to the SDK'. Tasks that are 80% mechanical and 20% judgment, where the agent does the mechanics and I supply the judgment at review time. My role on these tasks moved from author to editor, and editing well-structured diffs is dramatically faster than writing them — when the task was specified well.
The skill that transfers isn't prompting. It's the same skill as delegating to a capable new engineer: precise task framing, explicit constraints, and review that assumes competence but verifies everything.
MCP is the part I'd defend in an architecture review
Model Context Protocol sounds like plumbing, and it is — the good kind. Instead of pasting context into a chat, the agent's tools are declared once and available everywhere: our Postgres schema, the issue tracker, internal API docs, a sandboxed shell. The agent stops guessing what the invoices table looks like and queries it. Writing a custom MCP server is an afternoon of work:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({ name: "schema-inspector", version: "1.0.0" });
server.tool(
"describe_table",
"Get columns, types, and indexes for a database table",
{ table: z.string() },
async ({ table }) => {
const columns = await db.introspect(table); // read-only connection
return { content: [{ type: "text", text: JSON.stringify(columns, null, 2) }] };
},
);
// Read-only by construction: the agent gets answers, not write access.The design principle that matters: give agents read paths generously and write paths grudgingly. Our schema-inspector uses a read-only connection; deploy and migration tools stay human-triggered. Capability boundaries do for agents what least-privilege IAM does for services.
Where it fails, and what that implies
Agents fail in patterned ways, and knowing the pattern is most of the defense. They over-satisfy vague requests — ask for 'better error handling' and you'll get try/catch wallpaper. They plausibly imitate local conventions without understanding why they exist, which is exactly the failure mode code review is worst at catching. And they're weakest at the two things senior engineers are paid for: knowing which requirement is wrong, and knowing what not to build.
- Tests and types are the agent's feedback loop — codebases with strong CI get disproportionate value from agentic tools.
- Small, reviewable diffs beat one heroic PR; I ask for plan-then-execute on anything non-trivial.
- CLAUDE.md-style convention files pay off immediately: architectural rules stated once stop being violated repeatedly.
- Review agent code as you would a confident new hire's: verify the invariants they had no way to know about.
The net effect after a year
Measured honestly: the mechanical middle of my work — migrations, test scaffolding, integration adapters, instrumentation — got 3-5x faster. Design work got slightly faster, mostly because exploring a rejected alternative now costs minutes. Debugging got better in a subtler way: an agent that methodically reads every log line has no ego about its hypothesis being wrong. What didn't change is accountability. I ship the code, I own the incident, and the review bar is the same as it ever was. The engineers getting the most out of agents aren't the ones who trust them most — they're the ones who've built workflows where trust isn't required.