Coding agents should be used by programmers, not instead of programmers

From automation gains to the trap of code overproduction

The new generation of AI tools for software development is no longer limited to autocomplete or quick code suggestions. Coding agents can inspect a repository, propose a plan, edit files, run commands, execute tests, and help move changes toward deployment. That makes them powerful, but it also creates a dangerous misunderstanding. Because they can generate more code, many organizations are starting to assume that they should generate more code all the time. The result is a culture where speed becomes the primary metric, output becomes a proxy for value, and software teams are pushed toward permanent acceleration.

That is the wrong lesson. The purpose of software engineering is not to maximize code volume. It is to build reliable, maintainable, secure systems that solve real user problems. When coding agents are treated as autonomous production engines, the main risk is not only that they will introduce bugs. The deeper risk is that teams begin optimizing for visible activity rather than durable quality. More pull requests, more features, more rewritten modules, more apparent momentum, but not necessarily more usefulness. In that environment, software drifts toward what might be called “busyware,” code produced because it is easy to generate, not because it is necessary.

Why programmers must remain in control

Coding agents should be used by programmers precisely because software engineering is not a purely mechanical task. It requires architectural judgment, memory of past technical decisions, awareness of system constraints, understanding of user needs, evaluation of tradeoffs, and accountability for long term maintenance. These are not incidental skills. They are the core of the profession. A coding agent may help execute parts of the work, but it does not remove the need for someone who understands what should be built, what should be rejected, and what consequences a change will have six months later.

This is why the programmer’s role becomes even more important, not less. The programmer is no longer just the person who types every line manually. The programmer becomes the person responsible for intent, prioritization, review, validation, and technical responsibility. They define the task, challenge the assumptions, inspect the output, test the consequences, and decide whether the generated solution belongs in production. Without that layer of judgment, a coding agent can become a multiplier of technical debt rather than a multiplier of engineering capacity.

Used well, these tools are valuable. They can accelerate repository exploration, draft tests, propose refactors, generate first-pass documentation, and reduce time spent on repetitive engineering work. Used badly, they flood teams with changes that still require human review, debugging, and correction. In other words, they do not eliminate human work. They often change its shape, shifting effort from writing to supervising, verifying, and fixing.

Real productivity means restraint and governance

The productivity debate often ignores an obvious fact. If an agent produces more code, humans must still evaluate whether that code is correct, safe, useful, and maintainable. If organizations forget this, programmers do not become freer. They become custodians of an endless stream of machine-generated changes, carrying greater cognitive load while having less time for design, reflection, and deep problem solving.

That is why the right conclusion is not to reject coding agents. It is to place them inside disciplined software engineering practices. They need clear permission boundaries, code review, testing gates, architectural standards, and human sign-off for important decisions. The organizations that will benefit most will not be the ones that force agents to run nonstop. They will be the ones that know when to let them accelerate work and when to slow them down.

Coding agents are useful when they extend the reach of programmers. They become harmful when managers start treating them as substitutes for programmers. Good software still depends on human judgment. The faster the tools become, the more important that judgment is.

Sources:
Bloomberg, Claude Code and the Great Productivity Panic of 2026: A timely analysis of how coding agents are feeding a culture of always-on software production and turning speed into a management obsession: https://www.bloomberg.com

Anthropic, Claude Code overview / security / permission modes: Official product documentation showing that Claude Code is built around repository access, file editing, command execution, and configurable supervision, which supports the argument for programmer-led use rather than unsupervised autonomy: https://code.claude.com

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developers: Experimental evidence suggesting that AI tools do not automatically make experienced developers faster in real open-source work, underscoring the importance of context, workflow design, and human oversight: https://metr.org/