For years, artificial intelligence tools helped developers complete lines, explain errors, and generate small functions.
AI agents represent a change in scale.
They can explore a repository, locate related files, modify different parts of a system, run commands, create tests, fix failures, and open a pull request for review.
Instead of suggesting the next line, they receive an assignment.
“Implement this feature.”
“Update this dependency.”
“Investigate why the tests are failing.”
“Fix this vulnerability.”
The developer no longer asks only for an answer. They delegate a sequence of actions.
This creates a powerful promise:
producing more software with less human execution time.
But it also creates a proportional risk.
An agent capable of working across dozens of files can accelerate a good decision.
It can spread a bad decision with the same efficiency.
The question, therefore, is not only whether agents increase productivity.
The correct question is:
Do they increase our ability to deliver sustainable software, or merely bring forward the moment when we will have to pay for the speed?
An agent is not simply better autocomplete
Traditional assistants work close to the developer.
They suggest a line.
Complete a function.
Explain a section.
The professional continues to conduct almost every step.
Agents receive more autonomy.
They can decide which files need to be read, which commands should be executed, and which changes are required to complete a task.
On platforms such as GitHub, agents can already work in their own environments, explore a repository, run tests, modify code in restricted branches, and create pull requests for human review. GitHub Copilot’s official documentation describes these capabilities and warns that this kind of agent has access to code, can perform changes, and requires permission controls, traceability, review, and security protections.
The difference may sound small in a product presentation.
In practice, it is enormous.
A poor suggestion affects a line until someone accepts it.
A poorly delegated task may affect dozens of files before anyone notices that the initial interpretation was wrong.
The agent expands the unit of work.
It consequently expands the unit of error.
The productivity is real
It would be a mistake to treat the gains as an illusion.
Agents can execute repetitive tasks, create initial structures, update dependencies, write tests, fix simple problems, and investigate parts of a system at remarkable speed.
They can also reduce interruptions.
Rather than abandoning an important task to perform a mechanical change, a developer can delegate the work, monitor the result, and keep their attention on more complex decisions.
The 2025 DORA report found AI usage among approximately 90% of the technology professionals surveyed. More than 80% perceived productivity gains.
However, the report’s central conclusion was more important than those percentages: AI acts as an amplifier.
It magnifies the strong practices of mature organizations and also magnifies the problems of disorganized ones.
This means that an agent introduced into a team with strong tests, understandable architecture, appropriate documentation, and effective review processes may significantly increase delivery capacity.
The same agent placed inside a confusing codebase with no tests or clear criteria may simply produce confusion faster.
The technology does not replace engineering maturity.
It multiplies its effects.
Producing more does not mean delivering better
Many companies measure the impact of AI through convenient indicators:
more code produced;
more pull requests opened;
more tasks completed;
less time between the beginning and end of implementation.
Those numbers may demonstrate activity.
They do not necessarily demonstrate value.
A team can increase the number of pull requests while increasing rework.
It can complete tasks faster while creating more incidents.
It can produce more code while making the system more difficult to maintain.
It can save two hours during implementation and spend two days investigating an unexpected consequence.
Productivity in software engineering is not the amount of code entering a repository.
It is the ability to transform a need into a reliable solution while maintaining a sustainable cost over time.
Code represents only the beginning of that cost.
Once created, it must be understood, tested, operated, corrected, updated, and eventually removed.
An agent makes creation cheaper.
It does not guarantee that the remainder of the lifecycle will also become cheaper.
Technical debt at high speed
Technical debt does not simply mean poor code.
It appears when a decision makes delivery easier today while creating an additional cost for the future.
Sometimes, that decision is conscious.
The team knows it is using a temporary solution to meet a deadline and intends to revisit it.
The problem is invisible debt.
The solution appears correct.
The tests pass.
The pull request is approved.
But the agent introduced duplication, unnecessary dependencies, inconsistent abstractions, incomplete error handling, or decisions that do not fit the wider architecture.
A preprint released in March 2026 analyzed 304,362 commits identified as having been produced by five AI coding assistants across 6,275 repositories.
The researchers found 484,606 issues attributed to the analyzed changes. Code smells represented 89.1% of the total. Across every tool evaluated, more than 15% of commits introduced at least one issue, and 24.2% of the tracked issues remained in the latest version of the corresponding repository.
Because this is a preprint based on static analysis and methods for identifying AI-produced code, the results should not be treated as a definitive measurement of every use of coding agents. They nevertheless demonstrate a plausible risk: part of the cost introduced by generated code is not corrected quickly and can remain in the codebase.
The agent accelerates delivery.
When controls do not evolve at the same pace, it also accelerates accumulation.
Incorrect code is not the only problem
The most dangerous debt may not appear in a static-analysis tool.
It emerges when the system contains working code that few people understand.
Imagine that an agent modifies fifteen files to implement a new rule.
The tests pass.
The feature works.
A developer quickly reviews the differences and approves them.
Months later, the rule needs to change.
The team discovers that no one completely understood why certain decisions had been made.
The code exists.
The knowledge that should accompany it does not.
This phenomenon has been described as comprehension debt or knowledge debt.
A 2026 qualitative study based on 621 reflective diaries from 207 students identified patterns including black-box acceptance of AI code, context mismatch, tool dependency, and bypassed verification. The authors define comprehension debt as the growing gap between what a team knows about its codebase and what it needs to know to maintain it effectively.
Because the study followed students rather than professional teams, its findings should not be generalized directly to the entire industry. The mechanism it describes is still relevant: tool dependency can reduce the effort invested in independent comprehension and create knowledge debt even when the resulting code remains technically acceptable.
A team does not merely need to own the software.
It needs to own an understanding of the software.
The agent knows patterns, not your history
A codebase consists of more than files.
It contains old decisions.
Constraints that do not appear in documentation.
Dependencies preserved for specific reasons.
Apparently strange solutions that exist to prevent problems previously encountered.
Agreements between teams.
Legal requirements.
Operational limitations.
Customers who depend on undocumented behaviour.
The agent works with the context it can access.
When that context is incomplete, it fills the gaps using general patterns.
The outcome may be technically reasonable and locally wrong.
It may create a new abstraction without realizing that the company already has another one for the same purpose.
It may replace unusual behaviour with a more elegant solution and reintroduce an old failure.
It may select a popular library that conflicts with internal restrictions.
It may create an architecture suitable for a hypothetical organization but excessive for the real team.
The worse an organization’s documentation is, the greater the distance between the actual system and the system the agent believes it is modifying.
The problem is not that AI lacks infinite context.
It is that many companies never organized the context their own professionals needed.
Almost-correct code is especially dangerous
An obvious error is usually identified quickly.
The system does not compile.
The test fails.
The application does not start.
Almost-correct code is more dangerous.
It works in the demonstration.
Passes expected scenarios.
Appears consistent during a superficial review.
But fails under a rare condition, higher load, a different permission, or an integration that was not mentioned in the task.
This type of error does not stop delivery.
It reaches production.
Agents are particularly effective at creating plausible solutions.
Plausibility, however, is not correctness.
An agent may confidently propose a nonexistent library, misunderstand a requirement, or change behaviour that needed to remain compatible.
The more convincing the answer appears, the greater the temptation to reduce the review.
That is precisely when review becomes more necessary.
Greater autonomy requires greater security
When a model only suggests text, its power is limited.
When it receives access to files, terminals, dependencies, services, and credentials, it can perform actions.
That capability creates risks extending beyond code quality.
The OWASP Top 10 for LLM Applications describes excessive agency as a combination of excessive functionality, excessive permissions, or excessive autonomy.
An agent may perform a damaging action because of an incorrect response, an ambiguous instruction, or a prompt injection encountered in external content.
Agents should therefore not automatically receive every permission held by the person using them.
The principle should be the same one applied to any system:
the minimum access necessary to complete the task.
GitHub’s documentation on risks and mitigations describes some protections applied to its agent: restrictions to specific branches, human review before merging, credential limitations, controls over workflow execution, CodeQL analysis, dependency checks, and secret detection. It also acknowledges risks involving injection, information leakage, and incorrect generated code.
Those protections reveal something important.
Even the organizations developing these agents do not consider it safe to treat them as unrestricted autonomous professionals.
Human review cannot become a ceremony
Many tools claim to keep a human in the process.
But there is a difference between a human being present and a human exercising meaningful control.
A pull request containing three files can be reviewed carefully.
A pull request containing fifty files, hundreds of changes, and extensive explanations increases cognitive load.
The developer may begin looking only for obvious signs of failure.
Did the tests pass?
Does the code compile?
Does the description appear coherent?
Then they approve it.
In that situation, human review exists formally.
In practice, the agent becomes the main authority over the change.
Reviewing AI-generated code requires more discipline, not less.
Changes should remain small.
The intention should be clear.
Important decisions must be explained.
Tests must cover behaviour, not merely lines.
The reviewer must be capable of describing what changed without depending on the summary produced by the agent itself.
Otherwise, the human is not reviewing.
They are merely authorizing.
The agent can also generate the wrong tests
A common strategy is to ask the agent to implement a feature and write the tests.
That appears efficient.
But it creates an independence problem.
The same incorrect interpretation can appear in both the implementation and the tests.
When the agent misunderstands the requirement, it may produce a system and a test suite that are perfectly consistent with the same mistake.
Everything is green.
The problem remains unsolved.
Acceptance criteria should therefore not emerge only after the code has been generated.
They need to exist beforehand.
Tests covering critical behaviour should be derived from user needs, risks, and business rules.
Sensitive systems also require different verification mechanisms:
automated testing;
static analysis;
dependency checks;
security review;
integration testing;
observability;
human validation.
No single technique provides sufficient confidence.
Not every task should be delegated in the same way
Agents perform best when a task has clear boundaries.
Updating a specific dependency.
Adding tests for known behaviour.
Fixing a reproducible bug.
Migrating a well-documented API.
Changing an interface according to an existing pattern.
In these situations, objective criteria exist for evaluating the result.
Risk increases when the task is ambiguous.
“Improve the architecture.”
“Optimize the system.”
“Fix the security problems.”
“Modernize this module.”
“Make the code cleaner.”
These requests require decisions involving priorities, compatibility, cost, risk, and organizational context.
An agent may produce impressive changes.
But it does not necessarily possess the authority or knowledge to decide which compromises the company should accept.
The broader the task, the lower the initial autonomy should be.
Specification quality determines the radius of error
Delegating to an agent does not eliminate the need to specify.
It increases it.
A vague instruction given to a person creates a conversation.
The person asks questions.
Negotiates.
Notices contradictions.
A vague instruction given to an agent may produce hundreds of lines before the ambiguity becomes visible.
A well-designed task therefore needs to describe:
the problem that must be solved;
the expected behaviour;
what must not be changed;
the technical constraints;
the known risks;
the required tests;
the boundaries of the agent’s work.
The greater the autonomy, the clearer the boundaries must be.
Prompts do not replace specifications.
They are simply a new interface for them.
How to use agents without accelerating debt
The answer is not to prevent their use.
It is to build a working system in which speed and control grow together.
The first principle is to limit the task.
Agents should begin with small, reversible, and easily validated changes.
The second is to limit permissions.
An agent does not need unrestricted access to production, every repository, or every secret to modify a function.
The third is to define criteria before execution.
What does completing the task mean?
Which behaviours must remain unchanged?
Which tests must pass?
The fourth is to preserve genuine human review.
Whoever approves the work must understand the change and assume responsibility for it.
The fifth is to automate verification.
Tests, static analysis, dependency checks, secret detection, and architectural policies need to run consistently.
The sixth is to maintain traceability.
It should be possible to identify what was produced by the agent, who requested the change, which instructions were provided, and which checks were performed.
The seventh is to measure consequences, not volume.
Cycle time matters.
But so do rework, failures, vulnerabilities, review time, complexity, and maintenance costs.
The eighth is to preserve knowledge.
Important decisions need documentation, and professionals should be able to explain the code they approve.
The best use of an agent is not eliminating the developer
It is eliminating parts of the work that consume time without requiring the developer’s best abilities.
An agent can prepare a change.
Investigate related files.
Create an initial version.
Run checks.
Identify inconsistencies.
The professional can focus their attention on requirements, architecture, risk, quality, and impact.
That combination is more valuable than attempting to turn the agent into a complete replacement.
The agent has speed.
The developer must provide context and judgment.
The agent explores alternatives.
The developer decides which compromises are acceptable.
The agent produces.
The developer remains accountable for what enters the system.
When each side performs the appropriate role, the productivity can be real.
When a company uses the agent only to increase volume, the short-term gain may conceal a growing bill.
Real productivity or accelerated technical debt?
Both possibilities exist.
Agents can reduce repetitive work, accelerate investigations, expand test coverage, and allow small teams to perform tasks that were previously impractical.
They can also introduce inconsistent code, increase the attack surface, hide decisions, and create systems no one completely understands.
The difference does not lie only in the quality of the model.
It lies in the maturity of the team using it.
An organization without tests does not become disciplined because it adopts AI.
A codebase without architecture does not become understandable because an agent can modify it.
A team without review does not become secure because the tool produces a convincing summary.
AI does not automatically solve engineering problems.
It enables us to produce them at a different scale.
Agents should not be evaluated by how much code they can write.
They should be evaluated by how much sustainable work they help complete.
Speed is one form of productivity.
Being able to continue moving forward after that speed is another.
An agent may deliver today what a team would have needed a week to produce.
The question is who will understand, maintain, and correct that delivery a year from now.
When that question has a good answer, we have productivity.
When no one can answer it, we are probably only generating debt faster.