Skip to content
BSWEN
Blog

How Do You Prevent Code Quality Death Spiral When Using AI Coding Assistants?

Cowrie
Cowrie
Dev @ Bswen

My codebase was dying, and I didn’t even notice.

Three months into using Claude Code heavily, I ran a complexity analysis on my project. The numbers shocked me: average file size had grown 40%, cyclomatic complexity had doubled in core modules, and I had three different patterns for the same operation scattered across the codebase.

The worst part? Each individual AI-assisted change had seemed reasonable at the time. The AI was solving problems correctly. But it was optimizing for task completion, not architectural integrity.

I was in a code quality death spiral.

What is Code Quality Death Spiral?

Each AI-assisted change was:

  1. Adding complexity without removing it elsewhere
  2. Creating inconsistencies in patterns and architecture
  3. Introducing subtle bugs from incomplete context understanding
  4. Making subsequent changes progressively harder

The spiral accelerated because the AI had more “mess” to work with. A quick fix would create two new edge cases. Those edge cases would spawn more patches. Within weeks, a simple feature request became an archaeological expedition through layers of inconsistent decisions.

The core problem: AI assistants succeed at “make this feature work” but fail at “keep the codebase maintainable.”

The Solution: Close the Feedback Loop

I found the answer in a Reddit discussion that crystallized what I’d been doing wrong:

“The fix: close the feedback loop. Measure the codebase structure, show the AI what to improve, let it fix the bottleneck, measure again.”

Without this closed loop, AI assistants become technical debt accelerators. A 10% complexity increase per sprint compounds to 2.6x complexity in 10 sprints.

Here’s the process that saved my codebase.

Step 1: Establish Quality Metrics

Before using AI assistants, define what “good” means:

Quality Metrics to Track
------------------------
- File size (lines of code per file)
- Function length (lines per function)
- Cyclomatic complexity per module
- Coupling between modules
- Test coverage percentage
- Duplicate code percentage
- Dependencies per module

I started with simple tools:

Terminal window
# Check circular dependencies
npx madge --circular src/


# ESLint complexity analysis
npm run lint -- --format json


# Find dead code
npx ts-prune

These metrics became my baseline. Now I could measure degradation objectively instead of feeling like things were “getting messy.”

Step 2: Create Visibility for AI Sessions

AI assistants can’t improve what they can’t see. Before each session, I started providing explicit context:

## Current Codebase State
- Largest files: auth.service.ts (890 LOC), user.controller.ts (720 LOC)
- Highest complexity modules: auth (complexity 45), payment (complexity 38)
- Recent changes: Added OAuth support, refactored user validation
- Known technical debt: Duplicate user fetch functions in 3 locations
- Architecture patterns expected: Repository pattern, Result types

This context was game-changing. Instead of the AI generating Yet Another Pattern, it would look at my existing code and follow the established conventions.

Step 3: Schedule Explicit Refactor Sessions

The biggest mistake I made was assuming the AI would refactor organically. It won’t.

“Forcing explicit refactor-only sessions (not just prompt resets) helps with that second half.”

I started scheduling dedicated refactoring sessions where the only goal was improving code structure, not adding features:

## Refactor Session Template


Goal: Reduce complexity in auth module from 45 to 25


Constraints:
- No new features
- All existing tests must pass
- Must remove more lines than added
- Must improve at least one metric


Process:
1. Identify bottleneck
2. Plan refactor
3. Execute changes
4. Run quality metrics
5. Verify improvement

These sessions became non-negotiable. If my post-session metrics showed degradation, I scheduled an immediate refactor before continuing feature work.

Step 4: Measure and Iterate

After each AI session (feature work OR refactor):

  1. Run quality metrics
  2. Compare to baseline
  3. If degraded, schedule immediate refactor
  4. Document improvements for next session context

This created a virtuous cycle. Each session started with better context than the last.

A Real Example

The Problem: Inconsistent User Fetching

I asked Claude Code to add features in different sessions. Without context, it generated three different patterns:

// Feature A session
async function getUser(id: string) {
  const user = await db.users.find(id)
  return user
}


// Feature B session (different day, no context)
const fetchUserDetails = async (userId) => {
  return db.users.where({ id: userId }).first()
}


// Feature C session (yet another pattern)
function retrieveUser(userId: string): Promise<User> {
  return UserModel.findById(userId).exec()
}

Each was syntactically correct. Each worked. But now I had three patterns doing the same thing.

The Solution: Context + Refactor Session

In my next session, I provided explicit context:

## Context for AI Session


### Existing Pattern (use this):
Location: src/repositories/userRepository.ts
Pattern: Repository pattern with typed results


```typescript
export async function getUserById(id: string): Promise<Result<User, Error>> {
  try {
    const user = await db.users.find(id)
    if (!user) return Err(new NotFoundError('User not found'))
    return Ok(user)
  } catch (error) {
    return Err(error)
  }
}

Refactor Session Prompt:

“Review all user fetch functions in the codebase. Consolidate to use the repository pattern shown above. Remove duplicates. Ensure all usages are updated.”

### The Result: Consistent Architecture


```typescript
// After refactor - all usages now consistent
// src/repositories/userRepository.ts
export async function getUserById(id: string): Promise<Result<User, Error>> {
  try {
    const user = await db.users.find(id)
    if (!user) return Err(new NotFoundError('User not found'))
    return Ok(user)
  } catch (error) {
    return Err(error)
  }
}


// src/services/authService.ts
const userResult = await getUserById(userId)
if (userResult.isErr()) return null
const user = userResult.value


// src/services/orderService.ts
const userResult = await getUserById(order.userId)
if (userResult.isErr()) throw new Error('Invalid user')
const user = userResult.value

One refactor session eliminated three patterns and improved type safety.

The Implementation Checklist

I created a checklist that I run for every AI session:

## Before Your Next AI Session


- [ ] Run quality metrics on codebase
- [ ] Document current pain points
- [ ] Identify architectural patterns to enforce
- [ ] Prepare context summary for AI
- [ ] Set quality goals for session


## During AI Session


- [ ] Provide explicit context at start
- [ ] Request pattern explanations
- [ ] Ask for alternatives when uncertain
- [ ] Review output for consistency


## After AI Session


- [ ] Run quality metrics again
- [ ] Compare to baseline
- [ ] Schedule refactor if degraded
- [ ] Update context documentation
- [ ] Log learnings for future sessions

Common Mistakes I Made

1. Assuming AI knows my architecture

Wrong approach: “Add user authentication”

Right approach: “Add user authentication using our existing auth pattern in src/auth/”

2. No quality baseline

You can’t improve what you don’t measure. I started with a quality audit before heavy AI usage.

3. Treating all AI output as correct

AI generates syntactically correct code that may be architecturally wrong. I always review for pattern consistency now.

4. Skipping refactor sessions

“I’ll clean it up later” became never. I schedule refactors like features: planned and tracked.

5. Using one AI for everything

Different models excel at different tasks:

+------------------+---------------------------+
| AI Tool          | Best For                  |
+------------------+---------------------------+
| Claude Code      | Planning, architecture,   |
|                  | initial drafts            |
+------------------+---------------------------+
| GitHub Copilot   | Auditing, pattern         |
|                  | matching                  |
+------------------+---------------------------+
| Cursor           | Refactoring, multi-file   |
|                  | changes                   |
+------------------+---------------------------+

Why This Matters

The feedback loop is everything. Without it, each AI session adds complexity. With it, each session can actually improve the codebase.

I now start every planning session with a quality audit. The AI gets explicit metrics on what needs improvement. And I measure again afterward to verify the improvement happened.

The death spiral isn’t inevitable. It’s just what happens when you use a powerful tool without a feedback loop. Close the loop, and the same tool becomes a force for code quality.

Ready to break the spiral? Run this on your codebase today:

Terminal window
npx madge --circular src/
npm run lint -- --format json

Then feed those results into your next AI planning session.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: