Stop Dumping Your Entire Codebase Into Claude—It's Making Your AI Worse

I spent three weeks last month fighting with a multi-phase feature build using AI assistance. Phase 1 went clean: authentication scaffolding, user model, database schema. Twenty-three files, well-structured, solid foundation. Then Phase 2 started, and I panicked.

I had this voice in my head saying: "The AI won't remember what you did. Better give it everything." So I ran Repomix on the whole codebase, fed the 180K token dump into the context window, and expected Phase 2 to pick up seamlessly. Instead, the AI hallucinated database schema I'd already designed, forgot about type constraints I'd established, and made me rewrite the same validations twice. I was debugging against my own previous work—the opposite of what was supposed to happen.

That's when I realized: I was solving the wrong problem. The issue wasn't that the AI needed more information. It was that I was giving it all information equally, and burying the signal in noise.

The Generational Garbage Collection Analogy Actually Works

The original article nails something I've been feeling for months: context management in AI-assisted development mirrors memory management in the JVM. When you dump your entire heap onto disk, you can theoretically preserve everything. But the cost of parsing through dead objects to find the ones you need is exactly the problem.

In my Phase 2 disaster, I was treating every line of code like it was critical. But here's the truth: 90% of what I wrote in Phase 1 didn't matter for Phase 2. The exact SQL migration script? Don't care. The temporary seed data I used for testing? Definitely not needed. The type definitions and invariants? That mattered.

I should have been selective. I should have promoted only what survived Phase 1 as genuinely important knowledge, not compressed everything hoping the AI would filter it.

What Actually Survives Between Phases

After reading this framework, I started thinking about my codebase differently. Not as "everything I wrote" but as three categories:

Eden code is your scaffolding. Migration files, test fixtures, experimental branches. It dies fast and should never carry forward. When Phase 1 ends, leave it behind.

Survivor code is what earned its place. Your core domain models, interfaces, validated assumptions. The User type with its email invariant. The Book entity with its status enum. These get promoted explicitly to the next phase's context.

Tenured code is rare but precious. Your business logic that barely changes. If you have to reference it, you tag it—don't embed it.

The insight that hit me: I wasn't doing this filtering. I was just... forwarding everything.

My Take: Promotion Over Compression

I agree completely with the core thesis, but I want to be honest about the implementation friction.

In practice, this requires discipline at phase boundaries that most development workflows don't enforce. You need to be intentional about asking: "What from this phase is worth keeping?" You need to document invariants, log broken assumptions, tag technical debt explicitly. That's overhead that feels unnecessary when you're on deadline.

But here's what I've started doing that actually works: three-section handoff notes.

## Phase 1 Core Domain (Promoted)
- User: { id, email, hashedPassword, displayName }
  Invariant: email globally unique, enforced on create
- Session: { id, userId, tokenHash, expiresAt }
  Invariant: one active session per user, invalidated on logout

## Phase 1 Assumptions That Broke
- PostgreSQL ILIKE is fast enough for search ❌
  → Implemented FTS instead in P1 end
- Redis not needed yet ✓ (remains true)

## Phase 1 Known Debt
- [ ] Auth provider refactor from JWT to OAuth2
  Reason: MVP first, third-party required in Phase 2

When Phase 2 starts, I paste this—about 300 tokens—instead of a 180K dump. Plus the 3-5 files I'm actually changing. The AI stays focused. No forgotten types. No hallucinated schema.

The Real Question

Here's what I'm still uncertain about: Does this discipline scale? I've tested it on two-phase projects. But what about a month-long project with seven phases? Does the promotion strategy work when you're doing hundreds of phase boundaries, or does it become bureaucratic?

I suspect the answer is: you need to automate the filtering. Write a script that extracts type definitions only. Parse comments for assumption logs. But that's not something most of us are doing yet.

The real win here isn't the analogy to JVM GC—it's the permission to stop trying to fit the entire world into context. You don't need Repomix to fail before you accept this. You just need to try it once, see your AI actually remember what you told it, and never go back.

Source: This post was inspired by "Don't Compress, Promote" by Dev.to. Read the original article