What the verified research supports

An adaptive codebase agent should not be presented as a magic chatbot that understands an entire repository automatically. The verified material points to a more specific design direction. A short course on Building Adaptive AI Agents describes three techniques: convert agent traces into reusable skills that receive human approval; build a code knowledge graph to improve retrieval in large codebases; and consider when to adapt the model itself. These are complementary approaches, not interchangeable features.

A separate Microsoft Research paper, “Supercharging Coding Agents with Interactive Debugging Capabilities,” studies the addition of a dedicated Debug Subagent and a recommended debugging workflow. Its reported tools include Python’s built-in PDB debugger and PyTest-based test execution. For Java, the research describes JDB and support for Maven and Gradle, with the build system detected from project files and incremental build settings used. The paper reports improvements of more than 20% relative to baseline in some cases. That result belongs to its evaluated approach and should not be treated as a guaranteed outcome for a different agent or repository.

This tutorial therefore specifies a source-aligned design and implementation plan, rather than claiming to provide a tested, copy-and-run OpenAI application. The verified sources do not establish a particular OpenAI Python SDK workflow, code indexer, storage layer, prompt, or API configuration. Treat those decisions as engineering work to validate in your own environment.

Step 1: Define the research task and the evidence boundary

Begin with a narrow engineering question. Examples include locating the code involved in a reported defect, identifying which tests are relevant to a behavior change, or finding the modules that should be inspected before a proposed modification. A question with a verifiable answer is a better starting point than a request to explain an entire application.

Write down what would count as a useful result before building retrieval. For a research question, the result might identify relevant repository elements and explain why they matter. For a debugging task, it might include a hypothesis that can be checked with a test or debugger. These are project-level acceptance criteria, not capabilities guaranteed by a language model.

Keep research and execution as distinct phases in your design. First identify evidence. Then investigate or test a hypothesis. If you later add an action that changes code, treat that as a separate capability with its own review and validation requirements. The verified research describes debugging support and agent workflows; it does not establish that an agent should make unreviewed changes to a developer’s working tree.

Make the evidence boundary explicit. Decide which repository or project materials the agent may examine, and how the team will review the evidence behind its conclusions. The verified sources do not prescribe a privacy, retention, or secret-handling implementation, so do not represent any such safeguards as already provided by this design. Establish those requirements with the policies and infrastructure that apply to your environment.

Step 2: Design retrieval around a code knowledge graph

A code knowledge graph is one of the verified strategies for improving retrieval in large codebases. The provided source does not specify a graph schema, parser, database, or ranking algorithm. Those choices must be made and evaluated for the project rather than inferred as established features.

At the design stage, describe what relationships matter to the questions your team expects to ask. A graph-based approach is useful only insofar as the relationships it represents help find relevant evidence. For example, a team can decide which connections between code elements and research questions are meaningful, then test whether retrieving through those connections surfaces the expected material. Do not claim a particular relationship is supported until the chosen indexing process actually extracts and validates it.

Build an evaluation set before tuning retrieval. Collect representative questions and have engineers identify the repository evidence they expect to be relevant. Compare graph-based retrieval against the team’s chosen baseline. Record whether expected evidence appears in the results, and review failures manually. This turns “the graph improves retrieval” from an assumption into a claim that can be checked for the selected codebase.

Start with a manageable codebase or a bounded part of a larger one. Inspect the graph’s outputs and the evidence returned...