Developer productivity and operational enablement
Three objectives, 7% of the marks — the smallest domain, and a design question rather than a feature tour: how does an organisation make AI-assisted tooling a team capability instead of forty private setups? This page covers configuring Claude tools like Claude Code for teams, the workflows where AI assistance pays first, and the debugging and operational support that keeps the whole thing alive.
The domain’s quiet premise: developer tools that each engineer configures privately produce private wins, no compounding, no governance, and an audit problem. The professional move is managed enablement — a standard baseline the team inherits, freedom inside it, and a support loop around the whole. Claude Code is the named example because it is the tool whose configuration is designed to be shared.
01Configuring tools for teams
The configuration layers the exam expects you to reason about, from most to least shared: managed settings an organisation enforces centrally (policy, permissions — the guardrail layer from Domain 5 reaching the developer’s terminal); project-level configuration committed to the repository (CLAUDE.md instructions, shared slash commands and Skills encoding team procedures, hooks that enforce checks, the MCP servers the project legitimately needs); and personal configuration each developer keeps (their own preferences and scratch tooling). The design judgment is what lives where: procedures and standards belong at project level so everyone inherits them and improvements compound; security-sensitive permissions belong at managed level so nobody can opt out by accident; everything else stays personal. The rollout questions are enablement questions: a standard setup that installs in minutes, Skills for the team’s real recurring procedures (release, incident, review — Domain 2’s progressive disclosure, applied to team knowledge), and an evaluation of what tools fit which environments, including the data-classification boundaries from Domain 5 — confidential codebases get the confidential-code treatment.
02Workflows where AI assistance pays first
The enablement strategy the exam rewards is sequencing: start where value is immediate, risk is contained and measurement is easy. The canonical first wins: code review assistance (a first-pass reviewer that never tires — drafts flagged by a human who decides); test generation (high-variance, easily verified by running them — the verification is mechanical, which makes it a safe automation lane); migration and refactoring grunt work (mechanical changes with strong checkers underneath); documentation drafts (the chore nobody does that AI does willingly, with humans correcting); and onboarding Q&A over the codebase (Domain 3’s progressive discovery, pointed at a repository). Each has the same shape: AI drafts, a deterministic check or a human verifies, and the verification was already part of the process. Measurement discipline comes from Domain 4: define the metrics before the rollout — cycle time, review turnaround, change-failure rate, adoption per team — or the programme will be judged anecdotally, and anecdotes cut both ways.
03Debugging and operational support
Enablement survives its first bad month or it does not survive at all, so support is designed in advance. The escalation path: self-service first (the runbooks and Skills the team wrote — “how we investigate a stuck deploy” is a Skill, not a Slack DM), a named owner for the tooling (the person who gets pinged when the MCP server is down or permissions fight the workflow), and a feedback channel whose output lands somewhere real — issues into a tracker, recurring problems into updated Skills and configuration, and the whole loop reviewed on a cadence. Two operational realities worth exam-ready status: the tooling itself needs observability (which MCP servers are failing, which hooks slow every session, what the tooling costs — the same Domain 3 discipline turned inward); and AI-assisted debugging changes the failure modes (bugs introduced by generated code must be caught by the deterministic layers — tests, review — which is why the safe-lane sequencing above put checkers underneath every automation).
04The traps
- —“Everyone picks their own setup.” Forty private configurations produce no compounding, invisible costs and an ungovernable audit surface.
- —“Adoption equals licences distributed.” Adoption is measured in workflow change (review turnaround, cycle time), not seats.
- —“Support is informal.” Without a named owner and a channel that feeds the configuration, every incident re-derives the same diagnosis.
- —“The tools are exempt from governance.” Managed permissions, data-classification boundaries and cost visibility apply to the tooling itself.
Where should a team’s “how we cut a release” procedure live so every developer’s Claude Code follows it?
- AIn project-level shared configuration — a Skill (or CLAUDE.md section) committed to the repository, improved by anyone, inherited by everyone
- BIn each developer’s personal notes, copied by hand
- CIn a central wiki the model cannot read
- DIn a managed policy file that only security can change
→Check your answer
Team procedures are project artifacts: versioned, shared, inherited — and Skills are the mechanism built for exactly this (metadata always available, body on demand). Personal copies (B) drift; a wiki (C) is outside the tool’s context; managed policy (D) is the right layer for enforced permissions, not for improvable procedure.
Which workflow is the safest first automation lane for a team new to AI-assisted development?
- AAutonomous merging of pull requests
- BRewriting the database schema overnight
- CTest generation — drafts verified mechanically by running them, with humans reviewing the final set
- DDirect customer communication
→Check your answer
Safe lanes pair AI drafting with verification that already exists: tests are run, so generated tests are checked by construction. Autonomous merges (A), unattended schema rewrites (B) and customer-facing sends (D) lack the deterministic checker — they are blast-radius mistakes from Domain 5 wearing tooling names.
A team’s MCP servers fail intermittently and every developer debugs it privately. Which design element is missing?
- AA bigger model
- BTooling observability plus a support loop: a named owner, a channel feeding a tracker, recurring fixes landing in shared configuration
- CMore MCP servers, for redundancy
- DA monthly retrospective
→Check your answer
The tooling itself needs the same operational treatment as any production system: visible health, an owner, and a loop that turns repeated diagnoses into durable configuration. Retrospectives (D) without a channel and an owner are ceremony; redundancy (C) multiplies an ungoverned surface.
How should the success of an AI-tooling rollout be established?
- ABy the number of licences distributed
- BBy the vendor’s case studies
- CBy anecdote from the most enthusiastic user
- DBy metrics defined before the rollout — cycle time, review turnaround, change-failure rate, adoption per team — on the workflows the rollout targeted
→Check your answer
Domain 4’s discipline applied internally: define the measurement before the intervention, or the programme is judged by whoever speaks loudest. Licence counts (A) measure procurement; anecdotes (C) and vendor stories (B) are not evidence about your team.