Integrating Claude into an Existing SDLC for the Developer Exam

Fitting Claude work into an established process

The final knowledge point in task statement 2.2 of the Claude Certified Developer - Foundations (CCDV-F) exam is about integration: how Claude development fits into the version control, review, testing, and release process an organisation already runs. It follows from systems development life cycle phases, which established that Claude work maps onto the normal life cycle rather than replacing it. Here you apply that principle to the day-to-day engineering process, and because it is an apply-level knowledge point, the exam expects you to take a described process and either fit Claude work into it correctly or spot where a team has failed to.

The whole knowledge point rests on one reframing: the AI-specific artefacts of a Claude system, its prompts, its tool definitions, its configuration, and the model it runs on, are not special exceptions that live outside engineering discipline. They are code and configuration like any other, and they belong inside the same version control, the same review, the same tests, and the same release controls as the rest of the system.

Prompts, tools, and config are code artifacts

The first pillar is that prompts, tools, and configuration are code artifacts and must be treated as such. A prompt that governs production behaviour is as consequential as a function, and a tool definition is an interface contract. Both deserve to live in version control, move through pull requests, and be reviewed before they change what users experience. This overlaps closely with version control and code review for AI projects, which goes deeper on the mechanics; the point here is the integration principle that these artefacts belong in the same repository and the same review flow as application code.

The corresponding exam trap is editing production prompts outside version control and review. It happens because prompts feel like text you can just tweak, especially through a console or a settings panel, and the change appears to take effect instantly. But an out-of-band prompt edit has no history, no reviewer, and no rollback path, so when it degrades behaviour there is no record of what changed or how to undo it. On an apply-level question, a scenario where someone hand-edits a live prompt to fix an issue is describing this anti-pattern, and the correct move is always to route the change through version control and review like any other code change.

Evals are the test suite

The second pillar answers a question every SDLC has an answer for except, too often, AI projects: what gates a change before it ships? For conventional code it is the test suite. For a Claude system it is the evaluations. Evals play exactly the role unit and integration tests play elsewhere: they run against a change to a prompt or a model and decide whether it is good enough to proceed. Integrating Claude into an SDLC means wiring the evals into the same gate the tests already occupy, so a prompt change or a model bump cannot reach production without clearing them.

This is why the second trap is shipping a prompt or model change without an eval gate. A team that would never merge untested code will sometimes push a prompt edit or swap a model with nothing checking the result, because the change does not look like code. But a prompt change alters behaviour just as a code change does, and on a probabilistic system the only way to know whether it improved or regressed things is to measure it. The eval gate is what turns "it seemed better when I tried it" into a defensible release decision, and it is the same gate that revalidation runs through during maintenance, connecting this knowledge point to operating and maintaining Claude systems.

Pinned model versions make releases reproducible

The third pillar is reproducibility, and the lever is model version pinning. A release process should specify an exact model version rather than a floating alias, so that the same deployment produces the same behaviour and a build is not silently changed underneath you when a new model becomes the default. This is the release-process side of the drift problem from the previous knowledge point: because behaviour can shift across model versions, a reproducible deployment must pin the version it was validated against. The deeper treatment lives in model version pinning, but the integration principle is that the release artefact names its model version the way it names any other dependency version.

Put the three pillars together and the picture is a single, ordinary pipeline. A change to a prompt, tool, or configuration enters version control as a pull request, gets reviewed, passes the eval gate, and is released against a pinned model version, producing a reproducible deployment. Nothing about that flow is AI-specific in shape; what is AI-specific is only what fills each slot, evals instead of unit tests, a model version among the pinned dependencies, prompts among the reviewed artefacts. That is the essence of integrating Claude into an existing SDLC.

A worked example

Common misreadings to avoid

How this is tested on the CCDV-F exam

As an apply-level knowledge point, questions present a team's engineering process and either ask you to fit Claude work into it or to diagnose where the integration broke. The two failures the exam trips candidates on are the out-of-band prompt edit, changing production prompts outside version control and review, and the ungated release, shipping a prompt or model change with no eval to gate it. The correct answers put prompts, tools, and configuration under version control and review, gate changes with evals, and pin model versions for reproducible deployments. If a distractor treats AI artefacts as exempt from the normal pipeline, it is wrong for the same reason in every case.

This completes task statement 2.2. Taken together with systems development life cycle phases and operating and maintaining Claude systems, it establishes that a Claude system is engineered, run, and evolved with the same discipline as any production software, with evals and pinned model versions filling the AI-shaped slots.