AI coding agents have changed the way we write software.
A developer can now describe a feature, give an agent access to a codebase, and watch it inspect files, understand relationships, write code, run tests and make changes that might previously have taken hours.
That is a huge productivity improvement.
But there is another side to this.
The more I work with AI-assisted development, the more I think we need to talk about something I would call Agentic Noise.
Not all unnecessary code is created by AI. Developers have been creating unnecessary code for decades. We have merge conflicts, duplicated logic, defensive code, abandoned implementations, formatting churn, unused helpers and code that nobody wants to touch because they are afraid of breaking something.
AI does not eliminate that noise.
It changes where some of it comes from, how quickly it can appear, and potentially how much of it can accumulate.
What is agentic noise?
I would describe agentic noise as:
Unnecessary code, changes, exploration or complexity introduced by an AI agent because of insufficient context, assumptions, excessive freedom, or repeated rework.
The important word here is unnecessary.
An agent generating a hundred lines of code is not necessarily creating noise. If those hundred lines are required by the architecture and the feature, they are simply code.
On the other hand, an agent can generate a perfectly valid abstraction, helper class or service that nobody actually needed.
The code can compile.
The tests can pass.
The implementation can even look clean.
And still be noise.
Human noise and agentic noise overlap
I don't think it would be fair to say that developers produce clean code and AI agents produce noisy code.
That's simply not true.
Even very good developers who consistently follow coding standards can introduce unnecessary changes.
A developer may leave some code untouched because removing it could create a conflict with another developer's work.
Another developer may add a small helper because it is safer than changing an existing component they don't fully understand.
Someone may save a file and their IDE reformats hundreds of lines even though they changed only five.
Two developers may modify the same area and spend time resolving a merge conflict.
Sometimes code is duplicated temporarily and never cleaned up.
Sometimes an old implementation remains because nobody is completely sure whether something else still depends on it.
This is all noise.
AI agents can create some of the same things.
The difference is that agents can create and modify code very quickly.
So I don't see agentic noise as a replacement for human noise.
I see it as another source of software-development noise that overlaps with the problems we already had.
The bigger the codebase, the more expensive ignorance becomes
One thing I have noticed is that the amount of agent work is not necessarily proportional to the size of the requested change.
In a small, new project, an agent may have very little to understand.
You ask it to add a feature and it may only need to inspect a handful of files.
In a mature application, the same apparently simple feature may require the agent to understand:
- several projects
- existing services
- interfaces
- dependency injection
- database access
- authentication
- configuration
- tests
- business rules
- frontend/backend contracts
- existing conventions
A five-line change can therefore require a huge amount of exploration.
This is one reason why agents can consume significantly more tokens in large projects.
The tokens aren't necessarily being spent writing code.
A lot of them are being spent trying to understand the system.
And this leads to an important observation:
Token consumption is sometimes a measure of uncertainty rather than coding difficulty.
A developer who has worked on a system for years may know immediately where a change belongs.
An agent may need to inspect dozens of files before reaching the same conclusion.
Familiarity with the codebase is less important than it used to be — but it is still important
AI agents have changed something fundamental for developers.
You don't necessarily need to remember how every part of your codebase works anymore.
An agent can help you navigate unfamiliar code.
It can explain an old service.
It can trace a call chain.
It can find similar implementations.
It can even implement something in an area you haven't touched for years.
That makes developers much more comfortable working outside their traditional comfort zone.
But there is a difference between being able to modify code and understanding the system.
Suppose your application works perfectly in development but fails in staging.
An agent might immediately start changing application code.
But an experienced developer may first ask:
Is the staging API URL different?
Is a connection string wrong?
Is an environment variable missing?
Is authentication configured differently?
Is there a certificate problem?
Is a feature flag different?
The problem might have nothing to do with the code that the agent is trying to modify.
AI reduces the amount of code we need to personally know.
It does not eliminate the need to understand what the system is supposed to do and where it can fail.
The danger of vague prompts
There is a temptation, especially after seeing how capable agents have become, to simply throw a problem at them.
"The API isn't working. Fix it."
Or:
"Add authentication caching."
Sometimes the agent will figure it out.
But when it doesn't have enough information, it has to make assumptions.
And those assumptions can lead to exploration, code changes, rewrites and eventually noise.
The developer may then respond:
"No, not there. Use the existing service."
Then:
"Actually, don't change that."
Then:
"We need to support another case."
Then:
"Wait, this already exists somewhere else."
The agent changes the implementation again.
Eventually the feature may work, but the repository can contain remnants of the journey:
- an abstraction that is no longer needed
- a helper that was part of an earlier approach
- an unused property
- duplicated logic
- a flag that no longer controls anything
- code that was introduced to support an assumption that turned out to be wrong
This is one form of agentic noise.
Few detailed prompts are often better than many short prompts
I increasingly think that a good agentic workflow is not about constantly talking to the agent.
It is about giving it a good description of the destination before it starts moving.
A detailed prompt should explain:
- what the business requirement is
- what already exists
- where the functionality belongs
- which projects are involved
- which patterns should be followed
- what must not change
- what the acceptance criteria are
- important edge cases
- testing expectations
- areas that require special care
This reduces the number of decisions the agent has to invent.
The goal isn't to make the prompt extremely long.
The goal is to make it precise where precision matters.
Don't make the agent guess
One of the most useful instructions I have found is surprisingly simple:
Research the codebase before implementing the task. If an important decision cannot be established from the code, configuration, tests, documentation or existing patterns, stop and ask me rather than making an assumption.
This changes the workflow.
Instead of:
Unknown
↓
Agent assumes
↓
Agent codes
↓
Developer corrects
↓
Agent rewrites
you want:
Unknown
↓
Agent investigates
↓
Still unknown
↓
Agent asks
↓
Developer provides context
↓
Agent implements
The second process is usually much cleaner.
And there is another important instruction:
Do not change existing behavior outside the scope of this task. If the requested change appears to require modifying shared behavior or an unrelated feature, pause and ask for approval.
That gives the agent a boundary.
The agent is not just being told what it can do.
It is being told what it should not assume it is allowed to do.
Give the agent the relevant projects
Modern applications are rarely contained in one project.
A feature may involve:
React / Next.js
↓
.NET / Node.js API
↓
Application services
↓
Database
↓
External services
If an agent can only see the frontend, it may have to invent an API contract.
If it can only see the backend, it may not understand how the API is actually consumed.
When a task crosses application boundaries, I prefer to give the agent access to the relevant projects together.
That gives it an opportunity to inspect what already exists rather than inventing something that looks reasonable from only one side.
But there is a balance here.
More context is not automatically better.
Giving an agent ten unrelated repositories doesn't necessarily make it smarter.
The principle should be:
Give the agent all the context relevant to the task, but don't give it the entire universe.
Tell the agent where code should go, And where it should not
Another source of noise is convenience.
Suppose one service already contains 2,000 lines of code.
The new feature is vaguely related to that service.
An agent may decide that adding another method there is the easiest solution.
Eventually that service becomes responsible for everything.
This is where architectural instructions become valuable.
A project can have a repository-level instruction file describing things such as:
- architectural boundaries
- coding standards
- project structure
- testing requirements
- business rules
- protected areas
- preferred patterns
- things that must not be changed casually
One increasingly common convention is AGENTS.md, a Markdown file specifically intended to give coding agents durable project context and instructions. It can also be scoped more narrowly in larger repositories.
The important point isn't the filename.
The important point is giving the agent persistent knowledge about the architecture instead of making it rediscover the same decisions on every task.
For example:
Reporting functionality belongs in the Reporting application layer.
Do not add reporting logic to CustomerService simply because it is convenient.
Before introducing a new abstraction, search for an existing component with the same responsibility.
These instructions can prevent noise before the agent writes it.
The agent should know when to stop
I think this is one of the most important differences between a good agentic workflow and simply letting an AI loose on a repository.
The agent should have permission to say:
"I need your decision."
For example:
"There are two existing patterns for handling this. The older implementation does X, while the newer reporting module does Y. The requirement doesn't specify which one should apply. Which should I follow?"
That's much better than silently choosing one.
Every assumption is a potential future rewrite.
Sometimes asking one question is cheaper than writing 500 lines of wrong code.
A real example: when a backend authentication problem wasn't a backend problem
I experienced a good example of this while working with a React reporting dashboard backed by an ASP.NET Core API.
The application had a legacy authentication bridge.
The simplified flow was:
React dashboard
↓
ASP.NET Core API
↓
Legacy authentication service
The API used HttpContext.RequestAborted as part of its cancellation flow, and that token eventually reached the legacy authentication HTTP request.
The exception appeared around:
await httpClient.SendAsync(
request,
HttpCompletionOption.ResponseHeadersRead,
cancellationToken);
The runtime exception was:
System.Threading.Tasks.TaskCanceledException
At first, that naturally looked like a backend problem.
Was HttpClient timing out?
Was the authentication service slow?
Was cancellation implemented incorrectly?
Was SQL involved?
Was there a networking problem?
The investigation went through several legitimate areas of the backend.
But the important question turned out to be much simpler:
Who cancelled the token?
Tracing it backwards produced:
HttpClient.SendAsync
↓
CancellationToken
↓
HttpContext.RequestAborted
↓
Browser cancelled request
↓
AbortController.abort()
↓
React effect cleanup
↓
React StrictMode
React StrictMode was intentionally performing an additional development-time effect setup/cleanup cycle.
The widget effect started the request.
StrictMode performed cleanup.
The cleanup called:
controller.abort();
The browser cancelled the request.
ASP.NET detected the disconnected/cancelled request.
RequestAborted was cancelled.
That cancellation propagated into the authentication bridge.
And eventually HttpClient.SendAsync threw TaskCanceledException.
The exception location was real.
The interpretation was wrong.
The backend wasn't necessarily failing.
It was responding correctly to a cancellation that had originated in the frontend lifecycle.
The interesting part: some of the investigation wasn't wasted
This is where things get more complicated.
The investigation uncovered several genuine improvements.
Authentication timeout handling was improved.
HTTP completion behavior was examined.
Request-scoped authentication caching was improved.
A cross-request single-flight mechanism was investigated.
Cancellation handling was made safer.
Some of these changes were useful engineering improvements.
But they were not the root cause of the repeated development-time exceptions.
The final root-cause fix was much smaller and was on the frontend: delaying the initial widget request so that the disposable StrictMode effect pass could complete its cleanup before the network request actually began.
This is an important distinction.
Technically good work can still be irrelevant work.
That is one of the things I mean by noise.
The lesson from the cancellation token
The most useful lesson I took from that investigation was:
When you see a cancellation exception, don't just investigate where the exception occurred. Trace where the cancellation originated.
The same principle applies to AI agents.
If an agent sees:
TaskCanceledException
and immediately starts modifying HttpClient, it may be solving the symptom.
A better investigation starts with:
Who cancelled the token?
Where was it created?
Who can cancel it?
What caused that cancellation?
This is a good example of why system knowledge still matters even when an AI agent can navigate the code.
The agent can follow the call chain.
The developer still needs to recognize which questions are worth asking.
AI can also reduce some human noise
There is another side to this discussion.
Developers themselves create a lot of development noise.
When several developers work on the same files, conflicts are common.
Resolving those conflicts takes time.
Sometimes it requires coordination between developers.
Sometimes developers avoid touching an area because someone else is working there.
Sometimes an editor reformats a large portion of a file when only a few lines were changed.
A developer may change five meaningful lines and accidentally produce a diff containing hundreds of whitespace or formatting changes.
That is noise too.
AI agents can reduce some of this coordination overhead.
They can make targeted changes.
They can work independently.
They don't have to wait for another developer to finish typing in a file.
They can also inspect the current code before modifying it rather than relying on someone else's verbal explanation.
So AI isn't simply creating more noise.
It can remove some old forms of human noise while introducing new ones.
Commit before starting a new task
One practice I think becomes especially valuable with coding agents is creating a clean Git checkpoint before starting a new task.
If the current work is complete, commit it.
Then start the next task.
Now there is a clear boundary:
Clean commit
↓
New task
↓
Agent changes
↓
Git diff
↓
Human review
The developer can immediately answer:
What exactly did the agent change for this task?
The agent also has a clear baseline.
If something goes wrong, you have a clean point to compare against or return to.
This isn't unique to AI development, of course.
But agents make it much more important because an agent can modify a significant amount of code very quickly.
Let another AI review the changes
I also like the idea of using AI to review AI-generated changes.
Not necessarily asking the same conversation:
"Are your changes correct?"
Instead, give another AI the requirements and the Git diff and ask it to review independently.
Ask it to look for:
- missing requirements
- unnecessary changes
- architectural violations
- security problems
- edge cases
- regressions
- unused code
- duplicated logic
- assumptions that aren't supported by the codebase
The interesting part is when the two agents disagree.
Agent A might say:
"This functionality belongs in CustomerService."
Agent B might say:
"This violates the existing reporting boundary."
That disagreement doesn't mean either agent is correct.
It means there is something the developer should investigate.
AI can therefore be useful not only for writing code, but also for challenging the reasoning behind code another AI has written.
Don't let the agent become a substitute for thinking
There is a trap here.
Some developers, especially developers who haven't enjoyed coding as much as others, can become extremely comfortable with agents.
The agent makes coding feel almost magical.
You describe a problem.
It writes code.
You ask for a change.
It changes the code.
You ask it to fix an error.
It tries again.
Eventually it becomes tempting to stop investigating the problem yourself.
That can work for simple tasks.
It becomes dangerous when the problem requires understanding the system.
A vague prompt such as:
"Something is wrong with staging. Fix it."
may cause the agent to spend a large number of tokens exploring the application and changing code without ever seeing the actual cause.
Maybe the problem is a connection string.
Maybe it is a URL.
Maybe it is an environment variable.
Maybe the deployment configuration is wrong.
The agent cannot reliably infer information that it cannot see.
So the developer still needs to do the diagnostic work.
I don't think the answer is to use AI less.
The better approach is:
Use AI as an amplifier of understanding, not as a replacement for understanding.
The new importance of context
This is perhaps the biggest change I see in agentic development.
A developer's value is shifting away from simply knowing how to type the code.
It is increasingly about knowing:
- what the system does
- why it is designed that way
- what the business rules are
- what must not change
- where a feature belongs
- what the actual problem is
- what evidence supports a proposed solution
The agent can do a lot of the mechanical work.
But the quality of its work depends heavily on the context it receives.
Better context produces fewer assumptions.
Fewer assumptions produce less exploration.
Less exploration generally means fewer unnecessary changes.
And fewer unnecessary changes mean less noise.
So what actually reduces agentic noise?
For me, the practical approach is becoming something like this:
Before the task
- Understand the requirement.
- Identify the relevant applications and projects.
- Make sure the current work is committed.
- Give the agent the architectural context it needs.
- Tell it what must not change.
- Provide business rules and constraints.
At the beginning of the task
- Ask the agent to research the existing implementation first.
- Let it find existing patterns.
- Ask it to identify uncertainties.
- Don't allow important assumptions to silently become architecture.
During implementation
- Prefer a few detailed prompts over continuous corrective prompting.
- Tell the agent when it must stop and consult you.
- Keep the scope narrow.
- Don't allow unrelated refactoring.
After implementation
- Review the Git diff.
- Ask why every significant change was necessary.
- Look for code that became obsolete during the implementation.
- Run the relevant tests.
- Consider an independent AI review.
- Remove anything that does not serve the final solution.
Agentic noise is not simply "AI writes too much code"
I think that definition is too shallow.
The more interesting problem is the relationship between context, assumptions and code generation.
An agent with poor context may spend a lot of time trying to understand the system.
An agent with vague requirements may invent behavior.
An agent with too much freedom may modify unrelated components.
An agent that is repeatedly redirected may leave remnants of several approaches.
An agent that cannot see the other application involved in a feature may invent interfaces that already exist.
And an agent that is never asked to stop and question assumptions can turn uncertainty into code.
All of these can create noise.
But the same thing can happen with humans.
The difference is that AI changes the economics.
It can explore faster.
It can modify more files.
It can produce more code.
It can repeat an approach almost instantly.
That makes controlling the process increasingly important.
The goal isn't less AI. It's less unnecessary work.
I don't think the answer to agentic noise is to return to writing everything manually.
Quite the opposite.
The productivity gains are real.
Agents can remove enormous amounts of mechanical work.
They can help developers understand unfamiliar code.
They can implement features across multiple projects.
They can investigate problems.
They can write tests.
They can review code.
They can make developers dramatically more productive.
But the best results seem to come when the developer provides something the agent cannot reliably invent:
context, constraints, judgment and direction.
The developer doesn't need to write every line anymore.
But the developer still needs to know what the lines are supposed to accomplish.
Final thought
Humans have always created noise in software.
AI agents haven't changed that fundamental fact.
What has changed is the speed and scale at which software can now be explored and modified.
That gives us a new responsibility.
We need to teach agents enough about our systems that they don't have to guess.
We need to give them enough freedom to be productive, but enough boundaries to avoid unnecessary changes.
We need to let them ask questions instead of rewarding them for confidently guessing.
And we need to review what they actually changed, not simply trust their explanation of what they changed.
Perhaps the most important question when working with an agent isn't:
"Can the agent write this code?"
It probably can.
The better question is:
"Does the agent have enough context to know what code should be written — and what code should not be written?"
That, to me, is where the difference between AI-assisted development and agentic noise begins.
