Error-Driven Development

Your CI pipeline is red. There are 14 TypeScript errors, 3 failing tests, and a deprecation warning. Your instinct is to fix them yourself or to paste the whole error log into the AI and say “fix everything.” Both approaches waste time. Fixing them yourself ignores your AI’s ability to resolve mechanical issues. Dumping the entire log gives the AI too much to process at once and leads to cascading “fixes” that introduce new problems.

Error-driven development treats each error as a precise, machine-generated specification. An error message tells the AI exactly what is wrong, where it is wrong, and what the system expects instead. That is better than any prompt you could write from scratch.

What You’ll Walk Away With

• A systematic workflow for feeding errors to your AI assistant one at a time
• Prompts that extract maximum signal from error messages
• Strategies for breaking error cascades (where fixing one error creates three more)
• Techniques for using errors as learning opportunities that improve your CLAUDE.md, .cursor/rules, and AGENTS.md

The Error-Driven Loop

Instead of trying to prevent all errors, you lean into them as the fastest feedback mechanism available. The loop is simple:

1. Make a change (or let the AI make one)
2. Run the verification step (build, test, lint, type-check)
3. Read the first error
4. Feed it to the AI with targeted context
5. Let the AI fix the root cause
6. Repeat from step 2

The critical discipline is one error at a time. Error messages often cascade — a single root cause produces dozens of downstream errors. Fix the first one and half the others disappear.

Feeding Errors to the AI

The quality of the fix depends entirely on how you present the error. Do not just say “the build is broken.” Give the AI the exact error output, the file it occurred in, and what you expected to happen.

Cursor

Cursor’s integrated terminal makes error-driven development seamless. Run your build or tests directly in the terminal, then reference the error in Agent mode:

I ran npm run type-check and got this error:

src/services/notification.ts:42:5 - error TS2345:
Argument of type 'string' is not assignable to parameter
of type 'NotificationPayload'.

Fix the root cause. The function signature in @src/services/notification.ts
expects a NotificationPayload object, not a raw string. Check the caller
at line 42 and the type definition in @src/types/notification.ts.

Cursor’s agent can also read terminal output directly. After a failing command, just type in chat: “Fix the error in the terminal.”

Claude Code

Pipe errors directly to Claude Code, or run the command and let Claude read the output:

Run npm run type-check. For each error:
1. Read the file and line number referenced in the error
2. Understand the root cause (don't just suppress the error)
3. Fix the root cause
4. Re-run type-check to verify the fix
5. Move to the next error

Fix errors one at a time. Do not batch fixes.

You can also pipe error output directly:

npm run type-check 2>&1 | claude -p "Fix the first TypeScript error. Show me the root cause and your fix."

Claude Code’s agentic loop will run the command, parse the output, fix the issue, and re-run automatically until clean.

Codex

Codex’s sandbox environment runs verification automatically:

Run npm run type-check. Fix each error one at a time,
starting with the first one. After fixing each error,
re-run the check to see if downstream errors resolved.
Do not batch fixes -- address one root cause per iteration.

In the Codex App, you can paste terminal output directly as context. Codex will analyze the errors and work through them systematically. For CI failures, Codex’s GitHub integration can read the failing check output directly from the PR.

Copy-paste prompt: Systematic error resolution

Run [BUILD/TEST COMMAND]. Then fix errors using this process:

1. Read the FIRST error message carefully
2. Identify the root cause (not the symptom)
3. Read the referenced files to understand context
4. Fix the root cause
5. Re-run the command
6. If new errors appear, repeat from step 1
7. If the same error persists, try a different approach

Do not suppress errors with type casts, @ts-ignore, or empty catch blocks.
Fix the underlying issue.

Breaking Error Cascades

A common trap: the AI fixes error 1, which introduces error 2, which when fixed introduces error 3. You end up in a whack-a-mole cycle that burns through your context window without making progress.

The solution is to recognize cascading patterns and address them structurally.

Cursor

When you see the same file appearing in multiple errors, zoom out:

We've been fixing errors in notification.ts for three iterations
and new ones keep appearing. Stop fixing individual errors.

Instead:
1. Read the full file @src/services/notification.ts
2. Read the types it depends on @src/types/notification.ts
3. Read the test file @src/services/__tests__/notification.test.ts
4. Identify the structural problem causing the cascade
5. Propose a fix for the root architectural issue

Do not modify any files until I approve the approach.

Claude Code

Use /clear to reset context when caught in a loop, then restart with a broader view:

I've been fixing TypeScript errors in src/services/notification.ts
but they keep cascading. Take a step back:

1. Read the file and all its imports
2. Run npm run type-check and capture ALL errors related to this file
3. Identify the common root cause
4. Fix the structural issue rather than individual symptoms
5. Re-run type-check to verify

If Claude has been running for more than two correction cycles on the same error, the context is polluted with failed approaches. /clear and a fresh prompt will almost always converge faster.

Codex

Start a fresh thread when errors cascade. The clean context helps Codex see the structural issue:

The file src/services/notification.ts has cascading TypeScript errors.
Individual fixes keep introducing new errors.

Read the file and all its dependencies. Identify the structural
root cause and fix it holistically. Run type-check after your
changes to verify all errors are resolved.

Copy-paste prompt: Breaking out of an error loop

We're stuck in a cycle where fixing one error introduces another.
Stop making changes and analyze the situation:

1. List all current errors (run [COMMAND])
2. Group them by root cause
3. Identify which single change would resolve the most errors
4. Explain your reasoning before making any changes

I need to understand the structural issue before we proceed.

Turning Errors into Permanent Knowledge

The most valuable errors are the ones you never see again. When you encounter a non-obvious error, capture the lesson in your project’s configuration so the AI avoids the same mistake in future sessions.

Cursor

Add a project rule in .cursor/rules/errors.md:

---
description: "Common errors and their fixes for this project"
alwaysApply: true
---

## Known Error Patterns

- When modifying notification types, always update both
  `src/types/notification.ts` AND the Zod schema in
  `src/validators/notification.ts`. They must stay in sync.
- Redis connection errors in tests: run `docker compose up -d redis`
  before running the test suite.

Claude Code

Add the lesson to your CLAUDE.md or ask Claude to remember it:

Remember: when modifying notification types, always update both
src/types/notification.ts AND the Zod schema in
src/validators/notification.ts. They must stay in sync.

Claude’s auto memory will store this in ~/.claude/projects/<project>/memory/ and load it in future sessions. You can also add it directly to your project’s CLAUDE.md for team-wide benefit.

Codex

Add the lesson to your AGENTS.md:

## Known Error Patterns

- Notification types: always update both src/types/notification.ts
  AND the Zod schema in src/validators/notification.ts together.
- Redis must be running for integration tests: docker compose up -d redis

Codex reads AGENTS.md at the start of every session, so this guidance applies automatically to all future work.

Copy-paste prompt: Post-mortem after a difficult error

We just spent significant time fixing [describe the error]. Before moving on:

1. Summarize what the root cause was
2. Explain why it was hard to diagnose
3. Suggest a rule or check we can add to prevent this in the future
4. Add the prevention rule to [CLAUDE.md / .cursor/rules / AGENTS.md]

When This Breaks

The error message is unhelpful. Some error messages are genuinely opaque (segfaults, generic “internal server error”). In these cases, switch from error-driven to hypothesis-driven: ask the AI to add logging, reproduce the issue, and narrow down the cause through elimination.

The AI keeps suppressing errors instead of fixing them. If you see @ts-ignore, as any, empty catch blocks, or eslint-disable in the AI’s output, it is suppressing symptoms rather than fixing causes. Be explicit: “Do not suppress errors. Fix the underlying issue.”

Too many errors to process. If type-check produces 200+ errors, do not feed them all to the AI. Focus on the first 3-5 errors — they are usually the root causes that produce the rest. After fixing those, re-run and check how many remain.

The error is in generated code. When the error is in a file the AI generated from scratch, it is often faster to delete the file and regenerate it with a more constrained prompt than to patch the existing broken version.

What’s Next

Test-Driven Development Combine TDD with error-driven development for the fastest path to correct code.

Continuous Delivery Ship error-free changes incrementally instead of batching up risk.

Memory Patterns Store error patterns permanently so the AI learns from past mistakes.