Error-Driven Development

Error-driven development treats each compiler error, test failure, or runtime exception as a precise, machine-generated specification: it states what is wrong, where, and what the system expected instead. The loop is to make a change, run verification, hand the first error to the agent with targeted context, and fix its root cause.

CI is red. Fourteen TypeScript errors, three failing tests, and a deprecation warning. The stack trace points at payment.ts:212, you have already burned twenty minutes guessing which of the last six commits broke it, and the fix you just pushed turned one failing test into three. Staring harder at the error is not working.

The two instincts at this point are both wrong. Fixing everything by hand ignores what the agent is actually good at. Pasting the whole log in with “fix everything” gives it too much at once and produces cascading “fixes” that introduce new problems.

The error message is the most precise specification you have of what is wrong, and it is exactly the input an AI assistant is best at consuming — better than any prompt you could write from scratch. Error-driven development leans into that: instead of aiming for a perfect first draft, run a tight error → fix → re-run loop and let each failure steer the next change. Done deliberately, it converges fast even on gnarly cascades.

What error-driven development gives you

• A repeatable error-fix-rerun loop you can run in any of the three tools
• Copy-paste prompts for a production stack trace, a compiler cascade, and a failing-test loop
• The per-tool mechanics: who runs the tests, who rolls back a bad fix, who iterates unattended
• A way out when fixing one error keeps producing three more
• An MCP shortcut that pulls the Sentry issue for you instead of copy-pasting stack traces
• A habit for turning a hard-won fix into a rule in CLAUDE.md, .cursor/rules, or AGENTS.md

The error-fix-rerun loop

Rather than trying to prevent every error, lean on them as the fastest feedback mechanism available:

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

The critical discipline is one error at a time. Error messages cascade: a single root cause produces dozens of downstream errors, and fixing the first one usually makes half the others disappear. Fixing error fourteen while error one is still there is wasted work.

Handing an error to each tool

The cycle is identical everywhere — surface an error, give the agent enough context, apply the fix, re-run the exact thing that failed. What differs is who runs the command and how you back out a bad fix.

Cursor

In agent mode, Cursor runs the tests or build itself, reads the terminal output, and iterates without you copy-pasting — after a failing command you can simply say “fix the error in the terminal.” The safety net is checkpoints: every agent edit is a restore point, so when a fix makes things worse you roll back to the last green state in one click instead of untangling it.

When you do paste an error, paste it with the context that makes it actionable:

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.

Best when you want to watch the loop happen and intervene the moment it goes sideways.

Claude Code

Claude Code runs the compiler and tests through the Bash tool and feeds the output back to itself, so the loop closes inside one session:

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 the output straight in:

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

In headless mode (claude -p) the loop can iterate against a failing command with a turn cap so it does not spin forever. Best when the loop should run from the terminal or in CI — scripted and bounded.

Codex

Codex runs commands inside a sandbox. For an interactive loop, use codex --sandbox workspace-write -c approval_policy=on-request: the sandbox permits routine edits and test commands, and on-request is a separate escalation policy rather than a failure hook — so ask Codex in the prompt to stop and report after a bounded number of failed attempts.

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 ChatGPT desktop you can paste terminal output directly as context, and for CI failures the GitHub integration reads the failing check output straight from the PR. Best when you want it to grind through a long error list mostly unattended but stop at genuine failures.

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.

The loop in three real situations

A production bug from a stack trace

A user hit a crash and your error tracker captured the exception. The fastest path is to hand over the trace plus the files it implicates — the full exception and stack, not just the top line, because the top frame is where the value was read, rarely where it went wrong.

Copy-paste prompt: a production stack trace

Production bug. Here is the exception and stack from Sentry:

TypeError: Cannot read properties of undefined (reading 'total')
    at applyDiscount (src/services/payment.ts:212:18)
    at checkout (src/controllers/checkout.ts:64:22)

The relevant files are @src/services/payment.ts and
@src/controllers/checkout.ts. Find the root cause — the undefined value,
not just where it's read. Tell me whether the fix is a guard at line 212
or an upstream initialization bug, then make the change and add a
regression test.

The fix should address where total became undefined — an upstream cart with no items, say — not bolt an ?. onto line 212. Re-run the failing path; if a new error surfaces, feed it back and repeat.

Note

MCP shortcut: with the Sentry MCP server connected (remote, https://mcp.sentry.dev/mcp), you skip the copy-paste entirely — the agent fetches the issue, stack trace, and breadcrumbs directly. Instead of “here is the trace,” the prompt becomes “pull Sentry issue PROJ-1234 and fix the root cause.” All three tools support MCP; this turns a manual paste into one referenced issue ID.

A compiler cascade after a refactor

You changed the signature of a core function and the type-checker lit up with thirty errors across the codebase. This is the loop’s sweet spot, because the errors are an exact, machine-generated worklist. Do not fix anything by hand first; let the full list materialize, then delegate the whole thing.

Copy-paste prompt: a compiler cascade

I changed `calculate(order: Order)` to
`calculate(order: Order, currency: Currency)`. Here is the resulting
tsc output:

src/billing/invoice.ts:48:21 - error TS2554: Expected 2 arguments, but got 1.
src/api/checkout.ts:90:14 - error TS2345: Argument of type 'Order' is not
  assignable to parameter of type 'Currency'.
…(28 more)

Fix every call site. Default `currency` to the order's own `order.currency`
where one exists; do not invent a hard-coded currency. After each batch,
re-run tsc and continue until it's clean. Show me the diff before applying.

The agent fixes call sites, re-runs the type-checker, and repeats. An hour of tedium by hand finishes in a few cycles, because the agent never gets bored on call site twenty-seven.

A failing test as the oracle

The strongest form of the loop is to write the failing test first and let the agent drive itself green against it. The test is an unambiguous oracle, so the loop terminates on its own.

Copy-paste prompt: a failing-test loop

Here is a failing Vitest spec for `parseDuration` (it should turn "1h30m"
into 5400 seconds):

expect(parseDuration('1h30m')).toBe(5400) // received NaN

Implement `parseDuration` so this passes, plus the cases "45s" → 45,
"2h" → 7200, and "" → throws RangeError. Run the spec after each change
and keep iterating until all four pass. Don't edit the test to make it pass.

That last sentence matters. Without it, an over-eager agent will sometimes “fix” the failure by loosening the assertion. Pin the test as the spec.

Breaking a cascade that will not converge

A compiler worklist shrinks as you work it. The dangerous kind of cascade does the opposite: the agent fixes error 1, which introduces error 2, which when fixed introduces error 3, and you burn the context window on whack-a-mole. The tell is the same file appearing in every round. When that happens, stop fixing errors and go after the structure.

Cursor

When the same file keeps appearing, 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

After more than two correction cycles on the same error, the context is polluted with failed approaches. /clear plus a fresh prompt will almost always converge faster than pushing on.

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 an error turns out to be non-obvious, capture the lesson in the project’s configuration so the agent avoids the same mistake in every future session.

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 stores this in ~/.claude/projects/<project>/memory/ and loads it in future sessions. Putting it in the project’s CLAUDE.md instead gives the whole team the same 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 the 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]

Where the error-fix-rerun loop breaks down

• Chasing the wrong error in a cascade. The first error often causes the rest. Tell the agent to fix the earliest root error and re-run before touching the others.
• Fixing the symptom, not the cause. Wrapping an undefined access in ?. stops the crash without explaining why the value was missing. Ask “where did this become undefined?”, not “stop the throw.”
• The agent suppresses instead of fixing. @ts-ignore, as any, empty catch blocks, and eslint-disable in the output all mean symptom management. Be explicit: do not suppress errors, fix the underlying issue.
• Looping forever on a flaky test. A non-deterministic failure lets the agent “fix”, re-run, see green, and declare victory — then it flakes again in CI. Quarantine the flake first; do not run the loop against it.
• Edit-the-test escape hatch. Agents sometimes make a failing assertion pass by weakening it. Add “do not modify the test” to any test-driven prompt.
• Context blindness. Pasting only the top stack frame hides the real culprit deeper in the trace. Give the full trace and name the suspect files.
• Too many errors to process. If the type-checker produces 200+ errors, do not feed them all in. Work the first three to five — they are usually the root causes — then re-run and see how many remain.
• The error message is genuinely opaque. Segfaults and generic “internal server error” carry no specification. Switch from error-driven to hypothesis-driven: add logging, reproduce, narrow down by elimination.
• The error is in generated code. When the broken file is one the agent wrote from scratch, deleting it and regenerating from a more constrained prompt usually beats patching it.

Where to go next with error-driven development

Test-Driven Development Write the failing test on purpose, then drive it green.

Error Injection Testing Manufacture the failures before production does.

Monitoring and Observability Wire up the Sentry signal that feeds this loop.

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