Adding a feature to an existing codebase is the most common use case — and the one where mistakes cost the most. The agent does not know your internal patterns, your unwritten conventions, your architectural compromises. If you do not explain them, it invents them. And when it invents them, the result looks correct but is out of sync with the rest of the code.

The challenge is not getting the agent to write code: it is getting it to write code that looks like your team wrote it.

When to use the agent for this case 🎯

• New feature in an existing module — API endpoint, UI functionality, business logic.
• Interface extension — adding fields, methods, parameters to an existing interface.
• Inter-module integration — connecting two subsystems with a new flow.
• Contextual bug fix — the fix requires understanding the architectural context before intervening.

When NOT to use the agent ⛔

• The project has no tests — without a safety net, every modification is a gamble. Add tests first, then delegate.
• You do not know the patterns — if you do not know how the target module handles errors, you cannot constrain the agent. Study first, delegate after.
• Tasks touching more than 5 modules — break into independent sub-tasks, each with its own context.

Opening prompt 📝

“Add [feature] to module [x]. CONSTRAINTS: use the same pattern as [reference file], do not modify [boundaries/y]. TARGET FILES: [list]. CRITERIA: [tests to pass].”

Concrete example:

“Add a POST /api/v2/orders endpoint in the orders/ module. CONSTRAINTS: use the same error handling pattern as payments/handler.go, do not modify the existing API contract. TARGET FILES: orders/handler.go, orders/service.go, orders/model.go. CRITERIA: all existing tests pass + new test for the endpoint.”

Context setup 🔧

1. Open reference files — the similar existing module, interfaces to respect, reference tests.
2. Explicitly indicate patterns — “use the same error handling pattern as payment.service.ts”, “follow the layered structure of the other Go handlers”.
3. Define boundaries — what must NOT be touched. The agent is a precise executor, not an autonomous architect.

Workflow 💡

1. Plan: the agent analyzes reference files and proposes a plan (modules involved, imports to update, tests to run).
2. Approve: review the plan before the agent writes code. This step prevents rushed or incorrect writes.
3. Execute in micro-increment: after each modified module, verify intermediate build and tests.
4. Reset context between tasks — do not carry refactoring residue into a bugfix.
5. Final review: generated code must be reviewed like any PR.

Plan approval is the most valuable moment of the cycle. It is where you prevent 90% of errors.

Acceptance criteria ✅

• Existing tests still green after each increment.
• New tests for the added feature.
• No out-of-scope files touched.
• Adherence to repository patterns (naming, structure, error handling).

Further reading 📚

• Understanding an existing codebase — before adding, understand what is already there. For large repositories, see the section on indexing and persistent indexing.
• Testing and TDD — the safety net before every modification.
• Blog: Question-driven specification — how to turn questions into executable specifications.