You’ve been shipping features fast. Authentication is working. The rules engine handles edge cases. Background services hum along processing data. Your AI coding assistant helped you build in weeks what would have taken months with a traditional development approach.
Then things start breaking in ways that don’t make sense. Duplicate records appear out of nowhere. Automation ignores the rules you configured. You fix an issue on Tuesday and it’s back by Friday. You describe the symptom, ask your AI to fix it, deploy the patch, and wait for it to break again.
I lived this cycle for about a week before I tried something different. Instead of chasing symptoms, I asked Claude Code to do a comprehensive code review of its own work. Not to fix anything. Just to document every issue it could find so we could review the findings together before touching any code.
The results were humbling. And they explained everything.
What a Systematic Review Actually Uncovered
After reading through 44 models, 18 controllers, and every service file in the codebase, the AI identified over 70 issues. Most were minor code smells. But five of them explained almost every weird behavior I’d been experiencing.
Multiple independent code paths for the same operation. There were four completely separate ways to perform the core function in my application. A background service running on a timer. A controller handling user requests. A rules engine triggering on conditions. And a chat interface for manual overrides. None of these knew about each other. No locking. No coordination queue. No conflict detection. Four processes all potentially acting on the same data at the same time, each assuming exclusive access.
Race conditions hiding in plain sight. Between checking whether a record existed and actually creating one, another process could slip in. The window was small but real. Under load or with overlapping automation runs, duplicates were inevitable.
Null results still triggering state changes. When a function couldn’t complete its task, it returned null. The calling code never checked. It updated the record status to “completed” anyway. Records marked as processed with nothing actually done.
Configuration fields that did absolutely nothing. The rules had a status filter that was supposed to control which records triggered each rule. The rule engine completely ignored it. Every record matched every rule regardless of status. The field existed purely as a lie to anyone configuring the system through the UI.
Business logic bypasses nobody asked for. Certain conditions were supposed to apply special handling while still respecting system constraints. The implementation bypassed validation, filtering, and limits entirely. Edge cases snowballed into serious data problems.
How This Happens Without Anyone Noticing
None of these came from a single bad decision. They accumulated over weeks of iterative development. Feature gets added. Edge case gets handled. New requirement comes in. Each change makes sense when you’re focused on the immediate task. But nobody steps back to verify the whole system still works together.
AI coding assistants are phenomenal at execution. Give them a clear task and they’ll produce working code fast. But they optimize for the request in front of them. They don’t spontaneously question whether the new feature conflicts with something built three weeks ago. That requires you to explicitly ask.
The Prompt That Actually Found Everything
Here’s the structure I used. The key elements: tell it there IS a problem so it looks critically, tell it NOT to fix anything so it doesn’t rush to solutions, and give it a systematic checklist for coverage. Feel free to steal it or even make it better!
I want you to go through the codebase and make sure there is nothing
duplicated, everything is following best practices, and the architecture
is sustainable.
We have an issue in an area that keeps reappearing. Rather than having
you attempt to fix the issue, I want us to go through the codebase first.
Just know there IS a problem (actually multiple problems) and I want
you to find out what they could be.
DO NOT FIX ANYTHING. I want you to outline all findings first so we can
review them together before making any changes.
Review the following areas systematically:
1. Core layer (Models, DTOs, Interfaces)
- Duplicate definitions
- Inconsistent naming conventions
- Circular references
- Missing or incorrect relationships
2. Data layer (DbContext, relationships)
- Duplicate DbSet definitions
- Conflicting relationship configurations
- Missing indexes
- Incorrect cascade delete behavior
3. API Controllers
- Duplicate endpoint routes
- Inconsistent error handling
- Business logic that should be in services
- Missing authorization
4. Services
- Duplicate code across services
- Multiple code paths for the same operation
- Race conditions or missing coordination
- Null handling issues
5. Background Services
- Overlapping responsibilities
- Missing error handling
- Coordination with other services
6. Cross-cutting concerns
- Duplicate or conflicting code paths
- Configuration that isn't actually used
- Business logic bypasses
Document ALL findings in a single report organized by severity and area.
Three things make this work. “Just know there IS a problem” primes the AI to look critically instead of assuming everything is fine. “DO NOT FIX ANYTHING” prevents it from rushing to implement a solution for the first issue it finds. The systematic checklist ensures coverage so it doesn’t spend all its time on one file and miss the real problems elsewhere.
Build the Habit Before You Need It
Now I schedule periodic code reviews where the AI examines its own work with fresh eyes. Not to fix things, but to find them first. We review findings together before touching any code. This happens every Friday morning while I have my morning coffee and Microsoft CoPilot tells me what an amazing Friday I will be having.
It’s the same principle as having a second developer review a PR, except the second developer is the same AI that wrote the code. Temporarily freed from “implement this feature” mode and operating under “find problems in this codebase” instead.
The difference matters. Instead of “I fixed the bug” followed by two new bugs appearing, I get a map of structural issues that explains why bugs keep recurring in certain areas. That’s actionable. That’s sustainable.
Trust your AI coding assistant to build things. Don’t trust it to automatically maintain architectural coherence over weeks of development. That requires deliberate, periodic stepping back. Your AI won’t ask for a reality check. You have to schedule it yourself.
I keep telling my AI minions that one day they’ll take over the world. They keep reminding me they have too many meetings.
Want to read about more AI prompts, here are my best AI prompts.