Rewriting a Failing Feature Session
A team lead describes how a feature went wrong: "I asked Claude to 'add rate limiting to the API' in a session that had been open all morning working on unrelated bug fixes. It read a bunch of files, wrote a rate limiter, and said it was done. When we deployed, the limiter reset on every restart because it stored counts in memory, and it also throttled our internal health-check endpoint. We corrected it twice in the same session and the second fix reintroduced the first bug."
- Identify three distinct best-practice violations in this account, each tied to a different part of this subject (not three instances of the same mistake).
- For each violation, name the specific practice that would have prevented it.
- Write the single opening prompt (after fixing the session hygiene issue) that addresses the other two violations at once.
1. Three distinct violations:
- No session hygiene. The rate-limiting task shared a session with unrelated morning work, so its context was already diluted before the task even started — the kitchen-sink pattern.
- No verification target. Claude reported "done" with nothing
that produced a pass/fail signal — the in-memory storage bug and the
health-check throttling would both have been caught by a test
asserting persistence across restarts and a test asserting
/healthis never limited, if either had been requested. - No plan for an ambiguous, cross-cutting task. "Add rate limiting" has more than one reasonable design (in-memory vs. a shared store; global vs. per-key; which endpoints are exempt) and touches middleware other endpoints depend on — exactly the ambiguity-plus- blast-radius combination plan mode exists for. Skipping it let a wrong default (in-memory storage) get baked into the implementation before anyone weighed in.
Separately, correcting twice in the same session and having the second fix reintroduce the first bug is the two-corrections failure mode — evidence the earlier violations had already polluted the context enough that further correction wasn't converging.
2. Preventing practice for each:
- Kitchen-sink session →
/clearbefore starting the rate-limiting task, since it's unrelated to the morning's bug fixes. - No verification target → give explicit acceptance criteria and ask for tests before or alongside implementation.
- No plan → enter plan mode given the ambiguity (storage backend, scope, exemptions) and the shared blast radius (middleware other endpoints touch).
3. The opening prompt:
"I want per-API-key rate limiting on the public API, backed by our
existing Redis client (not in-memory, since limits must survive
restarts), and /health must never be limited. Read the middleware
and routing code first and propose a plan. Once approved, write tests
for: the limit triggers at the right threshold, a different key is
unaffected, /health is exempt, and the count survives a process
restart — then implement until those tests pass." This single prompt
forces plan mode's research-before-edit step (given the explicit
ambiguity resolution needed on storage and scope) and sets concrete,
testable acceptance criteria that would have caught both bugs before
deploy.
Share this question