Add a feature to a codebase you did not write
Bring your own repo, or clone any open-source app you like. The worked example adds rate limiting to an existing API endpoint, but the shape applies to any feature in any brownfield system. Brownfield is where agents do the most damage, so the emphasis is on context, verification, and reversibility.
Prime the agent on the codebase
Follow the context-engineering skill. Read this repo and write a short rules file (CLAUDE.md or AGENTS.md) capturing its conventions: structure, patterns, test commands, and the things a newcomer would get wrong. The agent surveys the repo and records its conventions where every future session will read them.
An agent starts every session cold and fills gaps with confident guesses. Writing the conventions down once stops it re-deriving your project from zero and inventing patterns you do not use.
Ground the approach in the real docs
Follow source-driven-development. For adding rate limiting in this stack, verify the approach against the official docs of the framework and libraries in use, cite the sources, and flag anything you could not confirm. The agent checks the framework docs rather than pattern-matching from memory, and cites what it used.
Brownfield stacks pin specific versions. Source-cited decisions keep the agent from reaching for an outdated or wrong pattern.
Spec the feature against existing patterns
Follow spec-driven-development, but scope it to a change inside this existing system. Spec rate limiting for one endpoint: where it hooks in, config, limits, error response, and what must not change. The agent writes a focused spec that fits the current architecture instead of a greenfield design.
The spec now describes a change to a living system, including the invariants you must not break. You review the decision before it is built.
Doubt the plan before touching production code
Apply doubt-driven-development to this plan. In fresh context, extract every non-trivial claim about how the existing code behaves, try to refute each one against the actual source, and reconcile. A skeptical pass re-checks the plan’s assumptions about the existing code before any change lands.
In code you did not write, a confident wrong assumption is cheap to catch now and expensive to debug in production later.
Pin current behavior, then build in slices
Follow incremental-implementation and test-driven-development. First add characterization tests that pin the endpoint’s current behavior, then add rate limiting behind a feature flag in thin, committed slices. The agent locks in existing behavior with tests, then adds the feature incrementally behind a flag.
Characterization tests make change observable, and the flag makes it reversible. You are changing a system people depend on, so both matter.
When something breaks, find the root cause
A test broke after the change. Follow debugging-and-error-recovery: reproduce it, localize it, reduce it to the smallest failing case, fix the root cause, and add a guard so it cannot regress. The agent runs a systematic triage instead of guessing at fixes.
Brownfield failures hide in the corners. A disciplined reproduce-localize-reduce-fix-guard loop beats trial and error.
Review as a change to the system
Follow code-review-and-quality. Keep the change near ~100 lines, check that it fits existing patterns, and run security-and-hardening on the new limits and error paths. The agent reviews the diff for correctness and fit, and hardens the new surface.
The bar for brownfield is "does this improve the system and follow its conventions," not "is it how I would have written it from scratch."
Roll out behind the flag
Follow shipping-and-launch. Plan a staged rollout using the feature flag, add the monitoring you would want on a rate limiter, and write the rollback. Give me a go or no-go. The agent plans a gradual, monitored rollout with a clear rollback and a recommendation.
You flip the flag for a slice of traffic, watch the signals, and can turn it off instantly. That is how you change production without holding your breath.
A feature merged into a system you did not write, with the existing behavior pinned, the change small and reversible, and a rollout you can watch. The same sequence works for any brownfield feature.