Every week I see posts like these, usually framed as evidence that AI itself is the quality problem:
“AI wrote 70,000 lines of code and I had to refactor 70% of it.” “Developers now have to maintain AI-generated slop.”
I have one response: that’s not an AI problem. That’s a you problem. I have a production application with 360,000 lines of generated code across C#, JavaScript, CSS, and CSHTML, and I have personally touched maybe 1% of it. The architecture is consistent, the patterns are predictable, and code reviews are fast because there is nothing surprising to find. The difference is not the model I am using. It is the structure I built around it.
The Real Diagnosis
When AI generates inconsistent code, there are two possible explanations. Either the model is broken, or it has never been shown what good looks like in your codebase:
- The AI is broken.
- You haven’t told it what good looks like.
It is almost always the second one. If your codebase has ten different styles, ten different ways of handling errors, and ten different approaches to data access, you have an architecture and standards problem. AI did not create that mess. It inherited it, amplified it, and handed it back to you.
If you’re refactoring 70% of AI-generated code, that’s a signal that the AI has no clear definition of what “done” looks like in your codebase. You’re leaving critical design decisions to the model’s defaults, then complaining when those defaults don’t match your expectations.
What You Actually Need to Do
Three Essentials
A solid instructions file. Every major AI coding tool supports project-level instruction files: claude.md, copilot-instructions.md, .cursorrules. These are how you tell the AI what kind of engineer to be on your project.
Your instructions file should point to your architecture, define your tech stack, and establish non-negotiable behaviors. Think of it as an onboarding document for a very fast, very literal new hire who will do exactly what you say and nothing else.
Architecture and code standards, in writing. If your standards only exist in people’s heads, they do not exist at all. Write them down. What does a well-structured service look like? How do you handle exceptions? What does a properly scoped repository pattern look like in your stack?
Your instructions file links to these. The AI loads them before generating anything.
CLEAN / SOLID / DRY: enforced, not assumed. These are constraints that make AI-generated code reviewable and maintainable. Without them, every file the AI touches becomes a negotiation. With them, you know exactly what you are getting.
Scaling It to a Team
Individual standards help you. Team standards are what prevent your codebase from drifting into chaos when six developers are all using different AI tools with different instructions.
Here’s the pattern that works: every repo gets a standard instructions file that loads your company’s shared coding standards. The standards are modular. The AI pulls in only what’s relevant to the task at hand.
An API endpoint loads the API standards, data access loads the ORM conventions, and cloud functions load the infrastructure standards. That keeps instructions focused instead of overloading the AI with irrelevant context, while allowing the standards to remain composable. You can update one module without touching everything else.
Team-Level Results
- Consistent architecture across every repository, regardless of who wrote it or which tool they used
- Faster code reviews because reviewers aren’t re-litigating design decisions that should have been pre-decided
- Far less drift between services, which means less cognitive overhead when moving between them
- AI that behaves like a trained team member rather than a contractor who just showed up
At my current organization, the first standards modules targeted a .NET suite of applications. When we brought in a dedicated PHP developer for applications previously handled by a third party, he reviewed the standards and proposed additions that became part of the shared set. The third-party developer now loads the same standards for AI-assisted work. The codebase has improved measurably under the same rules, rather than each team inventing a separate definition of acceptable code.
The Mental Model That Changes Everything
Stop thinking about AI as a code generator. Start thinking about it as a new engineer who knows how to type faster than anyone you’ve ever hired, but arrives with no knowledge of your codebase, your standards, your architecture decisions, or your team’s values.
You would not hand that engineer a Jira ticket and walk away. You would give them context, establish expectations, and review their first few PRs carefully with specific feedback. Agentic coding works the same way. You are doing the thinking upstream, before execution, so execution can be fast and consistent.
The teams that are struggling with AI-generated slop are the teams that skipped the upstream work. They handed the model a vague request, got a vague result, and blamed the tool.
The teams shipping clean, consistent, maintainable AI-assisted code did one thing differently: they taught the AI how they build software. That is good engineering leadership applied one layer upstream, not a prompt-engineering trick.
Receipts
- Measured adoption: The shared standards have produced thousands of automatically generated unit tests in new code. New code built with the instructions regularly scores sixes and sevens for architecture in the team’s code scorecard.
- Cross-team use: The standards began with .NET, then gained PHP-specific additions from a dedicated PHP developer. Internal developers and a third-party developer now load the same shared modules for AI-assisted work.
- Delivery result: Two developers used the standards and AI assistance to build a data-comparison tool in three days, work that would ordinarily have required much more design and testing time.
- Implementation pattern: The public agentic coding standards example shows the modular instructions approach described here.