AI-assisted development has crossed an important boundary.
The first generation of tools mainly accelerated typing. They completed methods, suggested tests, and answered questions in a chat window. Useful, certainly, but the developer still managed every step of the workflow.
Coding agents operate differently. Given a bounded objective, they can inspect a repository, plan a change, edit several files, run commands, interpret failures, and iterate. The important change is not that a model can generate more code. It is that the tool can participate in a complete engineering loop.
After working with these systems regularly, my view is neither that they replace developers nor that they are simply better autocomplete. They are a new execution layer, and they are most effective when directed with the same care we would apply to any other powerful system.
From suggestions to delegated work
A useful distinction is the amount of workflow a tool can own.
Autocomplete owns a few tokens. A chat assistant may own an explanation or a code sample. An agent can own a bounded task with multiple dependent steps:
- Inspect the relevant code and documentation
- Form a plan based on the repository as it exists
- Make coordinated changes across files
- Run the appropriate tests or build
- Diagnose failures and revise the implementation
- Present the result for review
This does not make the process autonomous in an organisational sense. A human still defines the objective, constraints, acceptable risk, and completion criteria. What changes is the level at which that human works.
Instead of directing every edit, I can focus on the problem boundary and the quality of the result.
Where agents create real leverage
Agents perform best when the task is clear, the feedback loop is executable, and the repository contains enough context to evaluate a result.
Examples include:
- Applying a known refactoring pattern across several files
- Adding tests around established behavior
- Migrating repetitive API or framework usage
- Tracing a well-defined defect through logs and code
- Producing documentation from an existing implementation
- Building a first version of a bounded feature
Compilation, tests, linters, and static analysis are valuable because they give the agent objective feedback. The more of the acceptance criteria that can be checked by tools, the more useful the agent becomes.
The inverse is also true. A vague request, an undocumented codebase, and no automated verification create the conditions for confident but unreliable output.
Context is an engineering concern
Prompt quality matters, but prompt writing is only a small part of the problem. Agents need access to the same contextual layers that experienced developers use:
- Repository structure and conventions
- Architecture decisions and technical constraints
- Domain terminology
- Build and test commands
- Operational boundaries
- Examples of accepted implementations
- Clear rules for actions that require approval
This context should not depend entirely on a long instruction written for one task. Durable knowledge belongs in the repository: contributor documentation, architecture records, tests, schemas, and well-named code.
An agent exposes weak engineering documentation very quickly. If the intended design exists only in one person's memory, the tool has no reliable way to infer it.
MCP and tool access
The Model Context Protocol, or MCP, provides a standard way for an agent to interact with external tools and data sources. The conceptual flow is straightforward:
The value is not merely convenience. A standard tool boundary can make inputs explicit, validate parameters, centralise authentication, and record what was called.
For enterprise use, those controls are essential. Giving an agent access to a database or deployment system is not only an integration task. It is a permissions, audit, and failure-handling problem.
I prefer narrow tools with clear contracts over broad access. A tool named get_deployment_status is easier to govern than unrestricted shell access to a production environment.
One agent is often enough
The current market encourages increasingly elaborate agent configurations. In practice, more agents do not automatically produce a better result.
My default is to start with one capable agent and a small set of tools. I add parallel or specialist agents only when the workflow contains genuinely independent work or when a clear separation of responsibility improves verification.
Every additional agent introduces coordination cost:
- More state to share
- More output to review
- More opportunities for duplicated work
- More complex failure recovery
- Higher latency and cost
Multi-agent design should be an architectural response to measured constraints, not a feature selected in advance.
What still requires senior judgment
Agents are increasingly competent at implementation. They remain much weaker at decisions that depend on incomplete, conflicting, or organisational context.
That includes:
- Choosing an architecture under business and operational constraints
- Deciding which technical debt is safe to carry
- Understanding where a requirement should be challenged
- Balancing security, performance, cost, and delivery pressure
- Recognising when the correct decision is not to build something
- Managing an incident when the available evidence is ambiguous
These are not gaps that disappear simply by generating better syntax. They require accountability and an understanding of consequences beyond the current task.
Senior engineers also provide taste: the ability to distinguish a solution that passes from one that fits the system.
A working model for using agents responsibly
I treat an agent as a highly capable collaborator operating inside explicit boundaries.
For each substantial task, I define:
- Objective: What outcome should exist when the work is complete?
- Context: Which parts of the system and domain matter?
- Constraints: What must remain unchanged, and which actions are prohibited?
- Verification: Which tests, builds, or manual checks prove the result?
- Review: Which decisions still require human judgment?
This structure improves results more reliably than asking the model to be clever. It also makes failures easier to diagnose.
The role is changing, not disappearing
Coding agents reduce the cost of producing and transforming code. That changes where engineering value sits.
The differentiating skills are increasingly problem framing, system design, verification, communication, and judgment. Developers who understand how a system behaves in production can use agents to move faster without surrendering responsibility for the outcome.
That is the shift I find most significant. The developer is not removed from the loop. The developer moves to a higher-leverage part of it.
The best way to develop judgment about these tools is to use them on real, bounded work, review the output carefully, and measure where they help. Neither enthusiasm nor scepticism is a substitute for that experience.
