Coding agents: why discipline matters more than the prompt
A coding agent can write thousands of lines in minutes. That doesn't change what a senior engineer still has to decide: what to build, how to verify it, and when to stop and think.
A well-directed coding agent can port a complete payment integration (integrity signatures, webhook HMAC verification, signed payment links) in an afternoon. That's real, I did it recently. But the interesting part isn't the speed: it's that the exact same criteria I apply reviewing a junior engineer's code apply, without exception, to reviewing an agent's. The speed changed. The acceptance bar didn't.
The real change isn't typing speed
What a coding agent removes is typing time: boilerplate, the second file that mirrors the pattern of the first, looking up the exact name of a function in a library you've already used before. That's real work, but it was never the hard part. The hard part is still the same as always: deciding what to build, what not to build, and where a system that "works" in the demo can fail silently.
An agent has no business context. It doesn't know that a payment endpoint needs idempotency because the gateway retries, or that an "optional" field is never actually empty in production. The engineer knows that, and will keep knowing it for as long as an agent doesn't have access to a business's full institutional memory, which is a while yet.
The mistake that accumulates debt fastest
The most expensive mistake I've seen, and made, isn't using an agent to write code. It's letting it decide architecture with nobody reviewing it. An agent optimizes for completing the task it was given, not for the system's health six months out. Ask it to "add a field to this table" and it adds the field, without asking whether that field belongs on a different table, whether it breaks an invariant the rest of the code assumes, or whether an equivalent field already exists under another name.
This looks exactly like ordinary technical debt: code that works, passes the tests that exist, and gets more expensive to change every time someone else touches that part of the system. It just accumulates faster now, because the volume of code produced per session is larger.
The practice that actually works
What works in practice is treating the agent like a call to a method: verifiable input, verifiable output, and a human in between who decides beforehand and confirms afterward. Before it writes a line, an explicit plan: which files it touches, which pattern it follows, what stays the same. After it's done, the same review I'd give any teammate's PR, diff by diff, not a surface-level "looks good."
That was literally the process behind this site's full redesign: brand palette, typography, icon system, navigation structure. Every change was planned before being written, and verified afterward (build, lint, real screenshots) before being accepted. The agent wrote most of the lines. The decisions about what to build and when to accept the result stayed mine.
The lesson
A coding agent doesn't change what it means to be a senior engineer: still responsible for a system that can't fail, even if you didn't type every line by hand. It changes how much code that responsibility can produce per hour. Confusing the two, treating speed as if it were a quality bar, is exactly how a team ends up with a system that's fast to build and impossible to maintain.