- In short
- Version control and code review for AI projects treat prompts, tool schemas, and configuration as first-class artifacts versioned alongside application code. Code review catches prompt regressions and unsafe tool configurations before release, and refactoring at small and large scale keeps the code maintainable, provided an eval confirms behavior is preserved.
Prompts are code, so treat them like code
The central idea of this Claude Certified Developer - Foundations (CCDV-F) knowledge point is a shift in status: in an AI project, prompts, tool schemas, and configuration are not incidental strings, they are first-class artifacts that determine how the system behaves, every bit as much as the surrounding application logic. A change to a system prompt can alter every response; a change to a tool schema can change what actions the model can take. Because those artifacts carry behavior, they belong under the same discipline you apply to code: version control, code review, and deliberate refactoring.
This builds directly on REST and JSON integration. Once you accept that the prompt and tool definitions travel in every request and shape the output, it follows that they must be versioned alongside the code that sends them. The alternative, prompts pasted inline and edited casually, produces a system whose behavior can change with no record of what changed or why. Software-engineering foundations exist precisely to prevent that, and task statement 2.4 asks you to apply them to the AI-specific artifacts.
- Version control and code review for AI projects
- The practice of treating prompts, tool schemas, and settings as first-class, version-controlled artifacts, reviewing changes to them for regressions and unsafe configurations, and refactoring them behind an eval that confirms behavior is preserved.
Version everything that shapes behavior
If an artifact can change how the model responds or what it is allowed to do, it belongs in version control alongside the application code. That means the system prompt and any templated prompts, the tool schemas that define available functions and their inputs, and the settings and configuration that steer the integration. Versioning them gives you the ordinary but essential benefits of source control: a history of what changed and when, the ability to revert a bad change, and a diff that a reviewer can actually read. It also connects to prompt versioning and plugin dependencies and CLAUDE.md and settings.json configuration, where these same artifacts are pinned and managed as the system evolves.
What code review catches in an AI project
Code review earns its place because the failure modes of an AI change are not visible by inspection alone, yet many are catchable by a second reader who knows what to look for. Two categories matter most. First, prompt regressions: a wording change that quietly degrades output quality, removes an instruction the system relied on, or reintroduces a behavior a previous fix had removed. A reviewer who reads the prompt diff against the intent can flag these before they ship. Second, unsafe tool configurations: a tool schema that grants more capability than the use case needs, exposes a destructive action without a guard, or loosens an input constraint. Reviewing tool definitions is a safety control, not just a style check, and catching an over-broad tool in review is far cheaper than discovering it in production.
The point for the exam is that review is where prompt regressions and unsafe tool configurations are caught before release. That framing tells you what a good AI-project review looks at, not only the imperative code, but the prompt wording and the tool schemas, because those are exactly where behavioral and safety regressions hide.
Refactoring keeps AI code maintainable, but needs a safety net
The third concept is that refactoring, at both small and large scale, keeps prompt and integration code maintainable. Prompts accrete: instructions pile up, examples duplicate, tool schemas sprawl. Small-scale refactoring tidies a single prompt or extracts a shared template; large-scale refactoring reorganises how prompts, tools, and integration code fit together. Done well, it keeps the system legible and changeable rather than a brittle tangle no one dares touch.
But refactoring AI code carries a specific hazard that leads straight to the second exam trap. With ordinary code, a passing test suite tells you a refactor preserved behavior. With prompts and integration logic, behavior is not obvious from the diff, and a change that looks purely cosmetic, reordering instructions, rewording a sentence, consolidating two prompts, can shift the model's output in ways you cannot see by reading. So you never refactor integration code without an eval to confirm the behavior is preserved. The eval is the behavioral baseline that stands in for a unit test: run it before the refactor to capture expected outputs, run it after to confirm they still hold. Without it, you are refactoring blind and trusting that a change you cannot fully predict did no harm.
Misconception
Prompts are just strings I tweak inline when needed; they do not need version control or review like real code.
What's actually true
Misconception
This refactor only rewords the prompt and reorganises the integration code, so it cannot change behavior; no need to test it.
What's actually true
Worked example
A team's Claude-powered assistant has grown a sprawling 2,000-word system prompt and three overlapping tool schemas, and an engineer proposes consolidating them.
Historically the prompt lived as an inline string edited directly in the handler, and tool schemas were pasted where needed. Changes shipped with no diff anyone reviewed, and twice a past fix silently regressed because someone reworded the prompt without realising it removed a guardrail. The first improvement is simply to move the prompt, the tool schemas, and the settings into version-controlled files so every change is a reviewable diff.
The engineer then proposes a large-scale refactor: merge the three overlapping tools into one, extract shared instructions into a reusable template, and trim the prompt. Under review, a colleague notices the merged tool would grant a broad delete capability the original narrow tools never exposed together, an unsafe configuration caught precisely because the tool schema was in the diff and someone read it. That gets scoped back before it ships.
Crucially, before merging the refactor the team runs an eval: a fixed set of representative inputs with expected-behavior checks. It captures the baseline on the old prompt, then re-runs on the refactored version. Two cases regress, the trimmed prompt had dropped an instruction that kept answers concise, so outputs are now verbose. Because the eval caught it, they restore the instruction and re-run until behavior matches, then ship. Same functionality, cleaner code, and no silent behavioral drift, because version control made the change visible, review made it safe, and the eval proved it preserved behavior.
How this is tested on the exam
Domain 2 questions on this knowledge point reward the mindset that AI-specific artifacts deserve real engineering discipline. Expect a scenario where prompts or tool schemas are edited casually with no history and something breaks; the correct answer is that these are first-class artifacts that belong under version control and code review. Or expect a refactor that "should not change anything" yet degrades output; the correct answer is that behavior is not visible from the diff and an eval was needed to confirm it was preserved.
Anchor on the three concepts and their two traps. Prompts, tools, and settings are versioned alongside code; review is where prompt regressions and unsafe tool configurations are caught before release; and refactoring keeps the system maintainable but must be gated by an eval. Treating prompts as throwaway strings, or refactoring without a behavioral baseline, are the mistakes the exam is built to surface, and avoiding them connects this knowledge point to configuration management later in Domain 2.
An engineer submits a pull request that reorganises a Claude integration: it consolidates two tool schemas into one and rewords the system prompt for clarity, describing it as a no-behavior-change cleanup. What should the review require before this merges?
People also ask
Should prompts be kept in version control?
What does code review catch in an AI project?
Why run an eval before refactoring an integration?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.