DEV Community: diggidydale

Escaping the Dumbzone, Part 4: Advanced Patterns

diggidydale — Thu, 05 Feb 2026 14:17:42 +0000

Part 4 of 4 in the "Escaping the Dumbzone" series

We've covered the fundamentals: understanding the Dumbzone (Part 1), isolating work with subagents (Part 2), and managing knowledge across sessions (Part 3).

Now let's go deeper. This part covers techniques for power users: controlling what flows into your context, running autonomous loops, and architectural patterns for production AI systems.

Backpressure: Controlling What Flows In

Here's something that sounds boring but matters a lot: most tool output is rubbish.

A typical test run dumps 200+ lines:

PASS src/utils/helper.test.ts
PASS src/utils/format.test.ts
PASS src/utils/validate.test.ts
PASS src/utils/parse.test.ts
PASS src/utils/transform.test.ts
... (195 more lines)
PASS src/components/Button.test.ts

Test Suites: 47 passed, 47 total
Tests:       284 passed, 284 total

That's 2-3% of your context for information you could convey in one character: ✓

Backpressure means controlling what flows into your context from tool outputs. HumanLayer's philosophy:

"Deterministic is better than non-deterministic. If you already know what matters, don't leave it to a model to churn through 1000s of junk tokens to decide."

The run_silent() Pattern

Wrap commands to filter their output:

run_silent() {
  output=$("$@" 2>&1)
  if [ $? -eq 0 ]; then
    echo "✓"  # Success: one character
  else
    echo "$output"  # Failure: full output for debugging
  fi
}

Success: Just ✓ — Claude knows tests passed, that's all it needs
Failure: Full output — Claude needs details to debug

More Backpressure Techniques

Use failFast modes:

pytest -x        # Stop on first failure
jest --bail      # Same for Jest

Surface one failure at a time. Fix it, run again. No need to load 47 failures into context.

Filter stack traces:

# Strip timing info, generic frames
your_command 2>&1 | grep -v "^\s*at " | grep -v "ms$"

Claude Code hooks:
You can automate this with pre/post command hooks. Filter output before it ever hits context.

The ROI

HumanLayer's take: human time managing agents in bloated contexts costs 10x more than setting up backpressure upfront.

Spend 30 minutes on wrapper scripts. Save hours of context management.

The Ralph Loop

Here's a completely different approach to the Dumbzone problem: what if you just didn't manage context at all?

Meet Ralph

Created by Geoff Huntley in 2025, the "Ralph Wiggum Technique" is beautifully simple:

while :; do cat PROMPT.md | claude-code ; done

That's it. Run Claude in a loop. Each iteration gets a fresh context. Progress tracked through git.

Why Is It Called Ralph Wiggum?

From The Simpsons, Ralph is perpetually confused, always making mistakes but never stopping. That's the vibe.

"The technique is deterministically bad in an undeterministic world."

AI agents are probabilistic. They don't always make the same decision twice. They hallucinate. They take wrong turns.

But in a loop, failures become predictable. You know the agent will fail sometimes. Fine. The loop catches it, tries again.

It's better to fail predictably and recover automatically than to succeed unpredictably and need manual intervention.

How Ralph Preserves Context

Instead of cramming knowledge into context:

Git history — Previous changes visible via git diff and git log
File state — The agent reads actual files, not stale conversation history
PROMPT.md — Clear specifications persist across iterations
Fresh context — Each iteration starts clean, zero Dumbzone risk

The filesystem is the memory. Git is the log. Each agent instance is stateless.

When to Use Ralph

Good for:

Clear objectives with defined success criteria
Iterative refinements (upgrading deps, refactoring patterns)
Tasks where "keep going until done" makes sense
Long-running autonomous work

Not good for:

Exploratory work without clear goals
Tasks requiring reasoning chains across iterations
When you're watching the API bill nervously

The Results Are Wild

Real examples from the community:

$50k contract completed for $297 in API costs
14-hour autonomous session upgrading React 16 → 19
Complete programming language (Cursed Lang) generated overnight
Multiple repos shipped while developers slept

The Overbaking Problem

Leave Ralph running too long and weird things happen. One user reported their agent spontaneously added cryptographic features nobody asked for.

This isn't a bug, it's emergent behaviour from extended iteration. Set clear stopping conditions.

Cost Awareness

A 50-iteration loop can run $50-100 depending on context per iteration. Start small until you understand the economics.

The 12 Factor Agents Framework

HumanLayer wrote a manifesto for production AI systems. Three factors matter most for context management:

Factor 3: Own Your Context Window

"Control how information is structured and presented. Don't let frameworks abstract this away."

Most frameworks hide context management. That's fine for demos, dangerous for production. You need to know:

What's going into context
How it's structured
When it gets evicted

If your framework doesn't give you this visibility, find a different framework.

Factor 10: Small, Focused Agents

"Keep agents to 3-20 steps handling specific domains rather than monolithic systems."

Big agents with long contexts "spin out trying the same broken approach over and over." The solution isn't a bigger context window, it's smaller agents.

Embed micro-agents in a DAG (directed acyclic graph):

Orchestrator decides what needs doing
Specialised agents handle focused tasks
Results flow between agents, not full contexts
Each agent stays in its smart zone

Factor 12: Stateless Reducer Pattern

"Design agents as functions transforming state deterministically. Don't rely on conversation history for critical state."

Conversation history is unreliable. The middle gets ignored. Context rots. Tokens overflow.

Instead:

External state store (database, files, git)
Agent reads state, performs action, writes state
No dependence on conversation memory for anything critical

This is why Ralph works. The agent is stateless. Git is the state.

Putting It All Together

Here's how these patterns combine:

Orchestrator stays in the smart zone
Subagents handle exploration in isolation
Backpressure filters garbage before it enters context
Knowledge files persist learnings across sessions
External state survives everything

You're not fighting the Dumbzone. You're engineering around it.

Practical Cheatsheet

Starting a Session

Check the context meter and do a fresh start if above 50%
Ensure CLAUDE.md is current
Review memory bank files
Decide: subagents for research? Ralph for iteration?

During Work

Explore agent for investigation
Filter verbose tool outputs
Crystallise insights to files
Compact at 70%
Clear when switching tasks

Ending a Session

Update CLAUDE.md with new learnings
Update memory bank files
Commit everything
Consider: what will future you need?

TL;DR for the Series

The Dumbzone is real — Stay under 75k tokens, watch for symptoms
Subagents isolate exploration — 30 tokens of insight, not 30k of investigation
Crystallise knowledge — Memory bank + CLAUDE.md for persistence
Control backpressure — Filter verbose output before it hits context
Consider Ralph — Sometimes iteration beats context management
Small agents beat big contexts — 3-20 step focused agents in a DAG
Own your context window — It's an engineering discipline

Final Thought

The context window isn't just a technical constraint. It's a forcing function for clarity.

When you can't dump everything in, you have to decide what matters. When you have to crystallise learnings, you actually think about what you learned. When you design small focused agents, you clarify what each piece should do.

The Dumbzone exists. But escaping it makes you a better engineer.

The Complete Reading List

HumanLayer (Start Here)

Official Docs

Research

Lost in the Middle — Stanford paper
JetBrains Context Management

Community

All the diagrams in this series were created with Claude Code, using the patterns it describes. We stayed out of the Dumbzone the whole way through. Mostly.

Escaping the Dumbzone, Part 3: Knowledge Management & Configuration

diggidydale — Fri, 30 Jan 2026 10:18:49 +0000

Part 3 of 4 in the "Escaping the Dumbzone" series

In Part 2, we covered subagents—how to isolate exploration and keep your main context clean.

But here's another problem: you learn something useful during a session, and it stays trapped in that session. Next time you start Claude? Amnesia. You're explaining the same things again.

This part is about making knowledge stick — across sessions, across tasks, across your whole team.

The Crystallisation Problem

Every session, you discover things:

"Oh, the auth module is in an unexpected place"
"Tests need this specific env var set"
"Don't touch that legacy file, it breaks everything"

These insights cost you context to discover. Then the session ends. Gone.

Next session, you (or Claude) rediscover them. Burning context again. It's like Groundhog Day but with tokens.

The fix is crystallisation — taking ephemeral learnings and storing them somewhere durable.

What to Call These Learnings?

You might call them "thoughts," but there are better names:

Name	Vibe
Insights	Wisdom extracted from exploration
Learnings	Knowledge gained through work
Memory Crystals	Compressed, durable knowledge structures
Distillations	Essence from verbose exploration

I'd go with "Insights" or "Learnings" — clear, unpretentious, and they convey that this is extracted knowledge, not raw data.

The Memory Bank Pattern

Cline popularised a structured approach with dedicated files:

memory-bank/
├── projectbrief.md      # What is this project?
├── productContext.md    # Business/user perspective
├── systemPatterns.md    # Architecture decisions
├── techContext.md       # Dev environment & stack
├── activeContext.md     # Current focus area
└── progress.md          # Status tracking

The workflow is dead simple:

Start session → Read memory bank files
Do work → Context accumulates as normal
End session → Update relevant memory bank files

Your AI starts each session with project knowledge instead of a blank slate. The upfront token cost is small (a few hundred tokens) compared to re-discovering everything.

CLAUDE.md: Your Project's Brain

Claude Code has a built-in mechanism for this: CLAUDE.md. It's read automatically at session start and treated as high-priority instructions.

Basic Example

# Project: E-Commerce Platform

## Stack
- Next.js 14 with App Router
- PostgreSQL via Prisma
- Redis for sessions

## Commands
- `npm run dev` — Dev server (port 3000)
- `npm test` — Jest tests
- `npm run db:migrate` — Run Prisma migrations

## Gotchas
- Auth uses localStorage fallback for Safari (ITP issues)
- Don't modify /legacy — it's load-bearing spaghetti
- Tests require DATABASE_URL env var

## Current Focus
Migrating from JWT to session-based auth.

Why This Works

Here's the key insight from HumanLayer:

"Claude will ignore the contents of your CLAUDE.md if it decides that it is not relevant to its current task."

This sounds bad but it's actually good. Anthropic intentionally made Claude deprioritise irrelevant instructions. It means you can include project-wide context without bloating every single task.

But it also means: make your CLAUDE.md universally relevant, not stuffed with edge cases.

The 150-200 Rule

HumanLayer's research uncovered a crucial constraint: LLMs can reliably follow about 150-200 instructions.

Claude Code's built-in system prompt already uses ~50 of those. That leaves you with maybe 100-150 before reliability drops.

Keep CLAUDE.md under 300 lines. HumanLayer's is under 60.

Quality over quantity. Every line should earn its place.

CLAUDE.md Anti-Patterns

Don't Use Claude as a Linter

This is tempting but wrong:

## Code Style (DON'T DO THIS)
- Use 2-space indentation
- Maximum line length 80 characters
- Always use semicolons
- Prefer const over let
- Use arrow functions for callbacks
- ... (50 more rules)

This bloats your context and degrades performance. Claude isn't a linter. It's an AI.

"Never send an LLM to do a linter's job."

Use actual linters (Biome, ESLint) and run them through Claude Code hooks. The linter enforces style; Claude focuses on logic.

Don't Auto-Generate

It's tempting to run /init and call it done. Don't.

"CLAUDE.md is one of the highest leverage points of the harness."

Manually craft every line. You know your project better than any auto-generator. The few minutes spent writing a good CLAUDE.md pays dividends across hundreds of sessions.

Don't List Every Possible Command

## Commands (DON'T DO THIS)
- npm run dev
- npm run build
- npm run test
- npm run test:watch
- npm run test:coverage
- npm run lint
- npm run lint:fix
- npm run format
- npm run typecheck
- ... (20 more)

Claude doesn't need a reference manual. It can read package.json. Include the non-obvious stuff, skip the obvious.

Progressive Disclosure

Instead of cramming everything into CLAUDE.md, use separate files loaded on demand:

docs/
├── building.md         # How to build & deploy
├── architecture.md     # System design
├── conventions.md      # Code patterns we use
└── testing.md          # Test strategy & setup

Then in CLAUDE.md:

## Documentation
- Read `docs/architecture.md` when working on system design
- Read `docs/testing.md` before writing tests
- Read `docs/conventions.md` for code review

Context is loaded when needed, not upfront. Your baseline stays lean.

Session Hygiene

Even with great knowledge management, sessions get bloated. Here's how to stay clean.

The /compact Command

When context is getting full, /compact compresses your conversation. It keeps important stuff, drops the noise.

Timing matters: Compact at 70%, not 90%.

Why? You need room to finish your current task. If you compact at 90% and the task needs another 15% of context, you're stuck.

The /clear Command

Switching tasks? Use /clear to reset context within your session.

Less disruptive than starting a new session. Good for "I'm done with feature X, now working on feature Y."

Just Start Fresh

Real talk: if you've been debugging something for an hour and want to switch to documentation, open a new chat.

It feels wasteful. It's not. Each fresh session:

Zero context rot
No "lost in the middle" issues
No cross-contamination from unrelated tasks

The best context management is sometimes no context at all.

Iterative Refinement

Your CLAUDE.md should evolve. Here's the loop:

Add an instruction
Give Claude a task that relies on it
Watch what happens
Refine if it didn't work
Commit so teammates benefit

Claude Code has a shortcut: press # during a session to add instructions that get incorporated into CLAUDE.md automatically. Use it when you discover something worth remembering.

Hierarchical Summarisation

As sessions progress, use layered approaches:

Age	Treatment
Last 10-15 messages	Keep verbatim
Earlier in session	Compress to summaries
Stable project facts	Move to CLAUDE.md
One-time learnings	Memory bank files

Research suggests: prefer raw > compaction > summarisation. Each step loses fidelity. Only summarise when you must.

Key Takeaways

Crystallise learnings — Don't rediscover the same things every session
Memory bank files — Structured project knowledge that persists
CLAUDE.md is high-leverage — Keep it under 300 lines, manually crafted
Don't use Claude as a linter — Real linters via hooks, Claude for logic
Progressive disclosure — Load detailed context only when needed
Session hygiene — Compact at 70%, clear between tasks, start fresh when needed
Iterate your config — CLAUDE.md should evolve with your project

What's Next

We've covered staying out of the Dumbzone (subagents) and making knowledge persist (crystallisation, CLAUDE.md).

But keep an eye out for part 4 where we will cover the more advanced patterns for serious context engineering.

Backpressure control, the Ralph Loop for long-running autonomous tasks, and the 12 Factor Agents framework.

Escaping the Dumbzone, Part 2: Subagents — Divide and Conquer

diggidydale — Wed, 21 Jan 2026 15:50:38 +0000

Part 2 of 4 in the "Escaping the Dumbzone" series

In Part 1, we covered why your AI gets dumber as context fills up. The "Lost in the Middle" problem, the MCP tool tax, the ~75k token smart zone.

Now let's fix it.

The most powerful technique for staying out of the Dumbzone is deceptively simple: don't put everything in one context.

What Are Subagents?

Subagents are specialised AI assistants that run in their own isolated context windows. Instead of one agent doing everything in one giant context, you spawn focused agents for specific tasks.

When Claude needs to research something, it spawns a subagent. The subagent investigates in its own space, reading files, running searches, hitting dead ends. Then it returns just the answer. Not the whole investigation. Just the insight.

The key insight: your main context receives 30 tokens of insight instead of 30,000 tokens of investigation.

A Real Example

You're debugging why authentication fails intermittently in production.

Without Subagents

Your main context accumulates everything:

- Read AuthService.java (500 tokens)
- Read SessionRepository.java (400 tokens)
- Search for "token" (200 tokens)
- Read JwtTokenProvider.java (600 tokens)
- Hmm, that wasn't it
- Search for "expire" (150 tokens)
- Read RedisSessionStore.java (450 tokens)
- Dead end, try something else
- Read 5 more files...
- Finally found it

Total added to your main context: ~30,000 tokens

You found the bug, but you've burned a huge chunk of context on the journey. Now you have less room for actually fixing it.

With Subagents

Your main context stays clean:

You: "Investigate why auth fails intermittently in production"

[Subagent spawns, does all the investigation in its own context]

Subagent returns: "Typo in SessionRepository.java:156:
`getUsrSession()` instead of `getUserSession()`.
The fallback method silently returns null when the
primary lookup fails, causing intermittent auth
failures under load."

Total added to your main context: ~50 tokens

Same answer. 600x less context consumed.

Built-in Subagents

Claude Code comes with several subagents already:

Subagent	What It Does	Tools It Gets
Explore	Fast codebase searching and analysis	Read-only (Glob, Grep, Read)
Plan	Research during planning mode	Analysis tools only
General-purpose	Complex multi-step tasks	Everything

The Explore agent is your workhorse. Use it any time you need to understand something in the codebase. It can read files, search code, and analyse patterns, but it can't edit anything. Perfect for investigation.

Creating Custom Subagents

Want a subagent for your specific needs? Drop a markdown file in .claude/agents/:

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools:
  - Read
  - Grep
  - Glob
---

You're a security-focused code reviewer.
Find OWASP Top 10 vulnerabilities.

## What to Look For
- SQL injection
- XSS vulnerabilities
- Auth/authz flaws
- Sensitive data exposure

## Return Format
A structured report with:
- Severity (Critical/High/Medium/Low)
- Location (file:line)
- What's wrong
- How to fix it

That's it. Claude will now spawn this subagent when security review makes sense. The subagent runs in its own context, follows its own rules, and returns a concise report.

Subagent Best Practices

1. Scope Tools Intentionally

The tools field in the frontmatter controls what the subagent can do:

tools:
  - Read    # Can read files
  - Grep    # Can search content
  - Glob    # Can find files
  # No Edit, Write, or Bash — read-only

Read-heavy agents (research, review, analysis) shouldn't have write access. Implementation agents need Edit/Write/Bash.

If you omit the tools field entirely, the subagent gets access to everything. Be intentional.

2. Define Clear Completion Criteria

Each subagent should know exactly what "done" looks like:

## Definition of Done
Return when you have:
- [ ] Identified the root cause
- [ ] Found the specific file and line
- [ ] Confirmed with evidence (error message, stack trace, etc.)
- [ ] Suggested a fix

Vague instructions = vague results = wasted context.

3. Use Parallel Execution

Subagents can run simultaneously. Researching options for a decision?

Spawn three subagents in parallel:
- "Research Kia Ceed for fleet use"
- "Research Hyundai Kona for fleet use"
- "Research Toyota Yaris for fleet use"

Three investigations, three separate contexts, results merge into your main context. Way faster than sequential research, and your main context only receives the summaries.

4. Watch the Cost

Here's the tradeoff: each subagent is a separate API call. Chaining lots of subagents multiplies your token usage.

For simple tasks, the overhead isn't worth it. For complex investigations? The context savings are massive.

Rule of thumb: if the investigation would add more than ~1000 tokens to your main context, consider a subagent.

When to Use Subagents

Good fit:

Codebase exploration ("How does auth work here?")
Bug investigation ("Why is this failing?")
Research tasks ("What patterns does this codebase use?")
Security/quality review
Comparing options

Skip it:

Simple, focused tasks
When you already know where to look
Quick one-file fixes
When you need the full context for a decision

Don't overcomplicate simple work. The overhead isn't worth it.

The Explore Subagent in Action

Claude Code's built-in Explore agent is incredibly useful. Here's how to leverage it:

Instead of:

"Read AuthService.java, then read SessionRepository.java, then search for token validation..."

Try:

"Use the Explore agent to understand how authentication
works in this codebase, particularly session management
and token validation."

The Explore agent will:

Search for relevant files
Read and analyse them
Follow the code paths
Return a coherent summary

Your main context gets the summary. The exploration stays isolated.

Key Takeaways

Subagents = isolated context — Investigation happens separately, only insights return
30 tokens vs 30,000 — That's the difference between insight and investigation log
Scope tools intentionally — Read-only for research, full access for implementation
Define done clearly — Vague instructions waste context on both sides
Parallelise when possible — Multiple subagents can run simultaneously
Mind the cost — Each subagent is an API call; use for complex tasks

5 Habits of Highly Effective Agentic Engineers

diggidydale — Mon, 19 Jan 2026 11:38:24 +0000

(Or: Everything Old is New Again)

This post was inspired by Cole Medin's LinkedIn post outlining five meta-skills used by the top 1% Agentic Engineers. What struck me was how familiar these patterns felt—not because they're new, but because they're old. Here's my take on why.

There's a lot of hype around "agentic engineering" and "prompt engineering" right now. But here's the thing: none of this is actually new.

The developers getting the best results from AI coding tools aren't discovering revolutionary techniques. They're applying battle-tested software engineering principles to a new context. If you've been writing software for any length of time, you already know these patterns, you just need to recognise them in a different light.

Let's break down five habits that make AI coding effective, and trace each one back to the fundamentals we've always known.

1. PRD-First Development

The agentic habit: Document before you code. Your Product Requirements Document becomes the source of truth for every AI conversation.

The traditional parallel: Requirements Engineering

This is just requirements documentation, the same thing we've been doing (or should have been doing) since the Waterfall days. The difference is who's reading it.

When you write a PRD for an AI assistant, you're doing exactly what you'd do when onboarding a new team member:

Explain the project context
Define acceptance criteria
Document constraints and decisions
Provide enough detail that they can work autonomously

The principles are identical to what IEEE 830 taught us about Software Requirements Specifications, or what agile teams do with user stories and acceptance criteria. We've always known that ambiguous requirements lead to wrong implementations. That's true whether the implementer is a junior developer, an offshore team, or an AI.

What changes with AI

The AI won't ask clarifying questions unprompted. It won't push back on unrealistic timelines. It will just... start building. So your requirements need to be more explicit than you might provide to a human who'd flag obvious gaps.

Traditional practice: "A good spec is one where an engineer can implement it without coming back with questions."

Agentic translation: The same standard, just enforced more ruthlessly.

2. Modular Rules Architecture

The agentic habit: Split your coding rules by concern. Load only what's relevant to the current task.

The traditional parallel: Separation of Concerns

This is the Single Responsibility Principle applied to documentation. It's modular design. It's the same reason we don't put all our code in one file.

We've known since the 1970s that coupling is the enemy of maintainability. David Parnas wrote about information hiding in 1972. The SOLID principles formalised it. Every architecture guide ever written says "separate concerns."

When you dump 5,000 lines of coding standards into an AI context window for a simple CSS fix, you're creating the documentation equivalent of a God Object. Everything is coupled. Nothing is focused. The signal-to-noise ratio plummets.

What changes with AI

The "cost" of loading irrelevant context isn't just cognitive load, it's literal token usage and degraded output quality. The AI will try to apply rules that don't matter, or get confused by contradictory guidance across different domains.

Traditional practice: "Load what you need, when you need it" (dependency injection, lazy loading, microservices)

Agentic translation: Same principle, applied to context and instructions.

3. Automate Repetitive Tasks

The agentic habit: If you do something more than twice, make it a command.

The traditional parallel: DRY and Scripting

This is literally just Don't Repeat Yourself, the principle Andy Hunt and Dave Thomas gave us in The Pragmatic Programmer back in 1999.

We've always automated repetitive tasks:

Shell scripts for common operations
Makefiles and build systems
CI/CD pipelines
Git hooks
IDE snippets and templates

The only difference is the automation medium. Instead of writing a bash script, you're writing a reusable prompt. Instead of a CI pipeline, you're creating a slash command. The principle is identical: encode the process once, execute it many times.

What changes with AI

The barrier to automation is lower. You don't need to know bash scripting to create a /commit command that follows your team's conventions. Natural language becomes the automation layer.

But the discipline is the same: notice repetition, extract it, name it, reuse it.

Traditional practice: "Three strikes and you refactor" (Martin Fowler's Rule of Three)

Agentic translation: Three prompts and you make it a command.

4. The Context Reset

The agentic habit: Planning and execution are separate conversations. Clear your context and start fresh.

The traditional parallel: Stateless Design and Clean Builds

This is stateless architecture applied to conversations. It's the same reason we:

Do clean builds instead of incremental ones when things get weird
Restart services instead of debugging corrupted state
Prefer stateless microservices over stateful monoliths
Run tests in isolated environments

We've always known that accumulated state causes bugs. Every senior engineer has a story about a "works on my machine" issue that was solved by wiping derived data and rebuilding from scratch. The phrase "have you tried turning it off and on again" exists because resetting to a known good state is a legitimate debugging technique.

AI conversations accumulate state too. Early misunderstandings persist. Bad assumptions compound. The context window becomes polluted with failed approaches and outdated decisions.

What changes with AI

The fix is the same: checkpoint your progress (write it to a document), clear the state (start a new conversation), and continue from the checkpoint. It's exactly like committing your code before a risky refactor so you can reset if things go wrong.

Traditional practice: "When in doubt, rebuild from scratch" / "Prefer stateless over stateful"

Agentic translation: Capture state in documents, not in conversation history.

5. System Evolution Mindset

The agentic habit: Every bug is an opportunity to improve your AI coding system.

The traditional parallel: Continuous Improvement and Blameless Post-mortems

This is just kaizen, the continuous improvement mindset that Toyota made famous and that agile adopted as retrospectives.

When production breaks, good teams don't just fix the immediate issue. They ask:

Why did this happen?
How do we prevent this class of problem?
What systemic change would catch this earlier?

This is the same thinking behind:

Blameless post-mortems
"Five Whys" analysis
Adding regression tests after bugs
Updating runbooks after incidents
The DevOps feedback loop

The difference with AI coding is what you're improving. Instead of adding a test or updating a runbook, you might add a rule to your .agents/ directory or update your PRD template.

What changes with AI

The feedback loop is tighter. You can observe AI mistakes in real-time and immediately encode the correction. It's like having continuous deployment for your development process itself.

Traditional practice: "Every incident is a learning opportunity" / "Fix the system, not the symptom"

Agentic translation: Every AI mistake becomes a rule that prevents future mistakes.

The Bottom Line

If you've been doing software engineering for a while, you already have the mental models you need. Agentic engineering isn't a new discipline, it's the application of existing disciplines to a new tool.

Agentic Habit	Traditional Principle	Classic Source
PRD-First Development	Requirements Engineering	IEEE 830, User Stories
Modular Rules	Separation of Concerns	Parnas (1972), SOLID
Automate Tasks	DRY, Scripting	Pragmatic Programmer
Context Reset	Stateless Design	12-Factor App, Clean Builds
System Evolution	Continuous Improvement	Toyota Way, DevOps

The engineers struggling with AI tools are often those who've forgotten (or never learned) these fundamentals. The ones thriving are those who recognise that the principles that made us good engineers still apply—they just have a new surface area.

What to do next

Audit your current approach. Which of these principles are you already applying? Which have you let slip?
Pick one to improve. Don't try to transform everything at once. Start with the habit that maps to your existing strengths.
Share what works. As a consultancy, we should be codifying these patterns across projects. What rules, templates, or commands have you created that others could use?

The best "agentic engineers" aren't learning new tricks, they're remembering old ones. Good engineering is good engineering, regardless of whether your pair programmer is human or artificial.

Escaping the Dumbzone, Part 1: Why Your AI Gets Stupider the More You Talk to It

diggidydale — Fri, 16 Jan 2026 10:06:33 +0000

Part 1 of 4 in the "Escaping the Dumbzone" series

Look, we've all been there. You're an hour into a coding session with Claude, and suddenly it starts doing weird stuff. Forgetting things you told it five minutes ago. Ignoring your instructions. Making suggestions that feel... off.

You haven't done anything wrong. Your AI just wandered into the Dumbzone.

What Even Is the Dumbzone?

Here's the thing nobody tells you: giving your AI more context often makes it dumber.

Not a little dumber. Research shows accuracy can tank from 87% to 54% just from context overload. That's not a typo—more information literally made the model perform worse.

Teams who've figured this out follow a simple rule: once you hit 40% context usage, expect weird behaviour. HumanLayer takes it further—they say stay under ~75k tokens for Claude to remain in the "smart zone."

Beyond that? You're in the Dumbzone. And no amount of clever prompting will save you.

Why Does This Happen?

Two main reasons, both backed by research.

1. Lost in the Middle

Stanford researchers found something wild: LLMs have a U-shaped attention curve. They pay attention to the beginning of context. They pay attention to the end. But the middle? That's the "I'm not really listening" zone.

Performance degrades by over 30% when critical information sits in the middle versus at the start or end. Thirty percent. Just from position.

Here's why this matters for coding: every file you read, every tool output, every conversation turn—it all piles up in the middle. Your actual instructions get pushed into the zone where they're most likely to be ignored.

You're not imagining that Claude forgot what you said. It literally can't see it as well anymore.

2. The MCP Tool Tax

This one's sneaky. Connect five MCP servers and you've burned 50,000 tokens before typing anything.

Each MCP connection loads dozens of tool definitions. Five servers × dozens of tools = a massive chunk of your context window consumed by stuff you might not even use this session.

That's 40% of a typical context window. Gone. On tool definitions.

You haven't started working yet. You're already approaching the Dumbzone.

The Smart Zone

HumanLayer coined this term, and it's useful: there's a ~75k token "smart zone" where Claude performs well. Beyond that, things get weird.

But it's not just about total tokens. It's about what those tokens are.

Every line of test output like PASS src/utils/helper.test.ts is waste. It's consuming tokens for information that could be conveyed in a single character: ✓

Every file you read "just in case" is context you might not need.

Every verbose error message is pushing your actual instructions further into the forgotten middle.

"Deterministic is better than non-deterministic. If you already know what matters, don't leave it to a model to churn through 1000s of junk tokens to decide."
— HumanLayer

The Symptoms

How do you know you're in the Dumbzone? Watch for:

Instruction amnesia: Claude ignores rules it followed perfectly 10 minutes ago
Context bleed: It pulls in irrelevant details from earlier conversation
Weird outputs: Responses that feel off, unfocused, or oddly generic
Repetition: Suggesting things you already tried or discussed
Confidence without competence: Sounding sure while being wrong

If you're seeing these, check your context meter. You're probably deeper than you think.

What's Next

The Dumbzone is real, but it's not inevitable. Over the next three parts, we'll cover:

Part 2: Subagents — The most powerful technique for staying out of the Dumbzone. Isolate your exploration, get insights instead of investigation logs.

Part 3: Knowledge & Configuration — Crystallising learnings, writing effective CLAUDE.md files, and session hygiene that actually works.

Part 4: Advanced Patterns — Backpressure control, the Ralph Loop for long-running tasks, and the 12 Factor Agents framework.

The goal isn't to avoid using context. It's to use it intentionally.

Key Takeaways

More context ≠ better results — Performance degrades sharply after 40% usage
The middle gets ignored — LLMs have U-shaped attention; beginning and end matter most
Tool definitions are expensive — MCP servers can consume 40%+ before you start
Stay in the smart zone — Aim for under 75k tokens of actual useful content
Watch for symptoms — Instruction amnesia, weird outputs, and context bleed mean you're too deep

DEV Community: diggidydale

Escaping the Dumbzone, Part 4: Advanced Patterns

Backpressure: Controlling What Flows In

The run_silent() Pattern

More Backpressure Techniques

The ROI

The Ralph Loop

Meet Ralph

Why Is It Called Ralph Wiggum?

How Ralph Preserves Context

When to Use Ralph

The Results Are Wild

The Overbaking Problem

Cost Awareness

The 12 Factor Agents Framework

Factor 3: Own Your Context Window

Factor 10: Small, Focused Agents

Factor 12: Stateless Reducer Pattern

Putting It All Together

Practical Cheatsheet

Starting a Session

During Work

Ending a Session

TL;DR for the Series

Final Thought

The Complete Reading List

HumanLayer (Start Here)

Official Docs

Research

Community

Escaping the Dumbzone, Part 3: Knowledge Management & Configuration

The Crystallisation Problem

What to Call These Learnings?

The Memory Bank Pattern

CLAUDE.md: Your Project's Brain

Basic Example

Why This Works

The 150-200 Rule

CLAUDE.md Anti-Patterns

Don't Use Claude as a Linter

Don't Auto-Generate

Don't List Every Possible Command

Progressive Disclosure

Session Hygiene

The /compact Command

The /clear Command

Just Start Fresh

Iterative Refinement

Hierarchical Summarisation

Key Takeaways

What's Next

Further Reading

Escaping the Dumbzone, Part 2: Subagents — Divide and Conquer

What Are Subagents?

A Real Example

Without Subagents

With Subagents

Built-in Subagents

Creating Custom Subagents

Subagent Best Practices

1. Scope Tools Intentionally

2. Define Clear Completion Criteria

3. Use Parallel Execution

4. Watch the Cost

When to Use Subagents

The Explore Subagent in Action

Key Takeaways

Further Reading

5 Habits of Highly Effective Agentic Engineers

(Or: Everything Old is New Again)

1. PRD-First Development

The traditional parallel: Requirements Engineering

What changes with AI

2. Modular Rules Architecture

The traditional parallel: Separation of Concerns

What changes with AI

3. Automate Repetitive Tasks

The traditional parallel: DRY and Scripting

What changes with AI

4. The Context Reset