AI Writes The Code. You Still Own The Quality
TL; DR:
Delegate code, not your quality bar.
Turn recurring mistakes into automated checks.
Use telemetry, not just code familiarity.
The Demo Works. Do You Understand The System?
Hey folks!
I came across a post on the ExperiencedDevs subreddit about maintaining quality when agents are writing more of your code. What caught my attention wasn’t someone saying that AI produces terrible code.
It was almost the opposite.
They could get a demo working quickly. The code looked reasonable. But as the application grew, they felt increasingly disconnected from it. When something needed fixing, they weren’t sure how to direct the agent because they didn’t really know what had been built.
I think that’s a much more interesting problem than arguing about whether AI can write a function.
Getting something operational and knowing how to keep it healthy are different things.
I’ve been talking about how AI changes the reasons we choose programming languages. I think there’s a related shift here: if we spend less time personally writing every line, we need to be deliberate about how we maintain our standards.
You can check out my full thoughts on this in the video below:
This Feels Familiar From Engineering Management
As an engineering manager, I don’t know every line of code my team writes.
That wasn’t always the case. Earlier in my career, I was managing people and writing code alongside them. As I spent more time managing and less time in that codebase, I became more detached from its implementation.
Does that mean I can’t help the team build good software?
Of course not. But it changes how I help.
I can discuss the problem, question a design, and help establish the patterns we want to follow. If someone needs help with a specific implementation, though, there comes a point where I need to roll up my sleeves and read the code with them.
I see a similar pattern with agents.
If an agent keeps failing to fix a behavior, repeating “make it better” isn’t much of a strategy. At some point, I need to understand the relevant part of the system well enough to ask a better question.
Delegation changes where I spend my attention. It doesn’t remove my responsibility.
That’s also part of what I’ve been exploring while building a game with AI agents. Having something generated doesn’t mean I can stop judging whether the result is what I actually wanted.
Leave Better Breadcrumbs
So what do we do when we need to investigate code we didn’t personally write?
One thing I’d ask an agent to do is walk me through the relevant path. Where does the request enter? What makes the decision? Where does the data get written?
Then I’d check that explanation against the code. A confident summary is useful as a starting point, not proof.
Consistent patterns help here, too. If similar operations follow the same structure, I have fewer surprises to untangle. If every feature introduces another way of doing the same thing, navigating the code becomes harder. This is of course a tax that humans pay when reading code, but I feel convinced that this adds overhead and complexity to agents working in codebases as well.
This isn’t some special AI-only discovery. It’s a reason to care about cohesive software in the first place.
Actionable Tip: When an investigation is painful, don’t stop at fixing the immediate bug. Ask what made the code difficult to navigate. An existing pattern worth reusing or a short explanation of a non-obvious constraint might save you from repeating the whole investigation.
Instructions Are Direction, Not Enforcement
Imagine investigating a slow write operation and discovering that it makes a separate database round trip for every item.
That’s an example to investigate, not a claim that every loop involving a database is wrong. The actual calls, provider, and workload matter.
But suppose you’ve confirmed the problem. You’ve measured it, found an appropriate batching approach, and fixed it.
What happens the next time an agent touches that area?
I want to capture the lesson somewhere it can use. Not “write performant code.” Something more useful: follow this repository’s established write pattern, avoid unnecessary round trips, and preserve the required transaction behavior.
Include the reason. Include where the existing pattern lives.
Repository instructions can give an agent that direction. They’re part of the practical workflow I discuss in my GitHub Copilot CLI guide for .NET developers.
But here’s the important distinction: telling an agent what to do is not the same as proving it did it.
We already understand this with people. You can explain a convention to someone and still need to check for it in review. Instructions help steer the work. They aren’t a guarantee.
Dev Leader Weekly is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Stop Reviewing The Same Mistake Forever
If a rule matters enough that we keep looking for violations, can we check it automatically?
As a .NET developer, one option I think about is a Roslyn analyzer. Analyzers inspect code for particular patterns and report diagnostics. If the relevant rule runs during the build and is configured as an error, a violation can fail that build.
That configuration matters. An analyzer suggestion isn’t automatically a blocked change.
Not every concern fits an analyzer, either. Some rules need information that isn’t available from static analysis. Some checks would take more effort to build and maintain than they’re worth.
For those cases, I might use a test instead:
An architectural test for a dependency boundary we don’t want crossed.
A configuration test for a setting the application requires.
A behavior test for an outcome we need to preserve.
And the tests need to check the actual requirement, not just produce a green result. My article on testing a processing pipeline is one concrete place to explore that kind of thinking.
There are tradeoffs. Instructions are relatively cheap to change, but they don’t enforce themselves. Automated checks provide a repeatable signal, but someone has to design and maintain them. Human review can consider context that a narrow check misses, but I don’t want to spend every review rediscovering the same mechanical violation.
I’d rather combine those approaches than pretend one replaces the others.
Actionable Tip: Pick one recurring problem from your recent reviews. Write down the desired behavior, then decide whether a build check or a test can reliably catch it. Don’t start by trying to encode every preference you’ve ever had.
Your System Needs To Tell You What’s Happening
There’s another piece that becomes more important to me as I know fewer of the specific lines: logging and telemetry.
When you’ve written a feature yourself, you can sometimes recognize a symptom and think, “I know which code path would do that.”
When you don’t have that familiarity, what tells you the story?
With BrandGhost, I want signals I can inspect when something isn’t working. In the larger systems I work with at Microsoft, that need is even more obvious. There are many service instances and dependencies involved. Remembering how one method works isn’t enough to understand what’s happening across them.
Logs, metrics, and traces give us different views of system behavior. They don’t magically explain every failure, but they give us evidence to investigate instead of relying entirely on memory.
If you’re working in .NET, structured logging with OpenTelemetry is a concrete area to explore.
I wouldn’t take that as “log everything.” I’d start with the questions I need answered: Which operation failed? Where did the time go? Can I follow the work across the relevant components?
If I understand less of the implementation from memory, I want better signals, not fewer.
Dev Leader Weekly is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Keep The Bar. Improve The Feedback.
I don’t think the answer is that you must personally memorize every line an agent produces.
I also don’t think the answer is to trust it because the demo worked.
The approach that makes sense to me is to keep improving the feedback around the work:
Give the agent useful direction about the patterns you want.
Check important, repeatable requirements automatically where practical.
Review the decisions those checks don’t cover.
Make sure you can investigate the system when it behaves unexpectedly.
When something slips through, use that failure to improve the process. Maybe an instruction was vague. Maybe a check was missing. Maybe you need to understand that part of the code more deeply.
None of this guarantees perfect software. Human teams don’t get that guarantee, either.
But I’d much rather build a process that helps me catch mistakes than keep asking an agent to “make no mistakes.”
That’s the quality bar I want to keep.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
[email protected]
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!
© 2026 Nick Cosentino
548 Market Street PMB 72296, San Francisco, CA 94104