When an agent writes the code, what does the engineer actually do?

Anthropic's 2026 Agentic Coding Trends Report confirms what most engineering teams already suspect: coding agents are writing a growing share of production code, and the teams getting real value out of them have redesigned their workflows around review, testing, and scoped autonomy — not just prompt quality.

That matches our experience. So it's worth being specific about what actually changes when an agent writes the code, and what doesn't.

What the agent is good at

Given a well-scoped ticket, an agent can produce a working implementation faster than a person can type. CRUD endpoints, form validation, migration scripts, wiring up a webhook to a queue, writing the first pass of tests. The boring middle of most projects.

It's also good at the parts engineers procrastinate on: documentation, changelog entries, cleaning up inconsistent naming, converting a Postman collection into integration tests. Work that's valuable but rarely the highest priority in a sprint.

IBM's writeup on agentic engineering frames this well: the agent handles plan-and-execute loops inside a bounded task. It doesn't decide what to build. It builds what you asked for.

What we keep humans on

Four things, without exception.

Scoping the work. Before an agent touches a repo, someone has written down what the system needs to do, what it doesn't need to do, and where the edges are. This is the step that determines whether the project ships in days or drags for a month. Skip it and you get very fast garbage.

Reviewing the diff. Every line an agent writes gets read by a human before it merges. Not skimmed. Read. This is where you catch the subtle stuff: an off-by-one in a billing calculation, a silent fallback that swallows an error, a query that looks fine but scans a table you can't afford to scan.

Testing against the business. Automated tests catch regressions. They don't catch "this workflow doesn't match how the ops team actually books an appointment." A person with the domain context has to sit with the working software and try to break it against real cases.

Owning the production system. When something goes wrong at 11pm, an agent doesn't get paged. We do. That responsibility shapes every earlier decision — what we deploy, what we log, what we monitor.

Why this matters if you're buying

CIO's outlook on agentic workflows in 2026 notes that the delivery speedup is real, but the risk profile shifts. More code, written faster, with more subtle failure modes if nobody's watching closely.

When you're evaluating anyone building software for you right now — us or otherwise — the question isn't "do you use AI." Everyone does. The question is what they've decided not to automate, and why. If they can't answer that clearly, that's the answer.

AI-assisted delivery is faster because the boring parts got faster. The judgment parts didn't. They still take the same person, the same care, the same afternoon spent reading the diff.