Team Enablement & Operational Productivity — Claude Certified Architect Professional Prep Course

Screen 1: Orientation: what you will be able to do by the end

MODULE · ORIENTATION Orientation: what you will be able to do by the end

De eerste vier modules hebben je tot een Architect gemaakt die een deployment van de eerste zin van een stakeholder door design, integratie, governance en handoff kan nemen. Deze module gaat over het team rond die deployment: mensen productief maken met Claude en hen productief houden zodra het systeem live is.

Aan het einde van deze module kun je: 1 Claude-tooling en -omgevingen voor een team configureren, inclusief de gedeelde configuratie, het rollout-patroon, de Skills-distributiestrategie en de uitgavenbeheersingselementen die bij teamopstelling horen. 2 Ontwikkelaarsworkflows met AI-tooling verbeteren en de reviewdiscipline definiëren die AI-gegenereerd werk betrouwbaar houdt voordat het naar productie gaat. 3 Debugging en operationele probleemoplossing ondersteunen door symptomen met architectuuroorzaken te verbinden en het team naar zelfstandigheid op te bouwen. Deze module gaat over enablement

Elke vorige module leerde je hoe je Claude bouwt en configureert. Deze gaat ervan uit dat het systeem gebouwd is en stelt de vraag: hoe adopteert een team het goed, en hoe blijft het gezond zonder je in elk probleem te trekken? Teamopstelling helpt het team de omgeving, de herbruikbare assets en de uitgavenpositie goed in te stellen voordat iemand inlogt. Ontwikkelaarsworkflows verhogen de standaard van hoe het team dagelijks werkt zonder de kwaliteitsnorm te verlagen, en operationele ondersteuning is wat je doet wanneer het team iets onverwachts in het systeem tegenkomt.

Deze onderwerpen bouwen op elkaar voort. De skills die je in de opzet distribueert, zijn dezelfde assets waarop een ontwikkelaarsworkflow steunt; de reviewdiscipline die je voor die workflows instelt, is wat een operationeel probleem onder druk test. De drie volgen op volgorde: stel de omgeving in, verhoog de dagelijkse workflow en houd het systeem gezond.

DISCLAIMER / NOTICE FOR EDUCATIONAL CONTENT

We hebben deze Architect-cursus Module 5: Team Enablement and Operational Productivity gebouwd om je echt werk met Claude te helpen doen. Behandel het als educatieve inhoud. Het vormt geen juridisch, financieel of ander professioneel advies, dus pas wat je leert aan je eigen situatie aan. Onze producten en services evolueren snel, dus bepaalde inhoud kan fouten bevatten of verouderd zijn; vergeet niet om te verifiëren op de website of docs van Anthropic. Voorbeelden en scenario's die in de cursus worden gebruikt, zijn illustratief en vaak fictief. Als het cursusmateriaal een bedrijf of product noemt, betekent dit niet dat Anthropic het aanbeveelt, zij Anthropic aanbevelen, of dat we gelieerd zijn. Houd er ook rekening mee dat je gebruik van Anthropic-producten en -services onder onze voorwaarden, beleidsregels en documentatie valt; als iets in deze cursus hiermee in conflict is, hebben zij voorrang.

Screen 2: Configuring Claude tooling and environments for teams

Team Setup Configuring Claude tooling and environments for teams Je kunt Claude in minuten voor jezelf configureren; maar het configureren voor een team is anders. Bij configuratie voor een team zijn er gedeelde standaardwaarden zodat iedereen van dezelfde basislijn begint, herbruikbare assets die centraal kunnen worden bijgewerkt en ingetrokken, en uitgaven die begrensd blijven naarmate het gebruik over tientallen mensen schaalt. Dit scherm behandelt de vier teamopstelbeslissingen die een Architect bezit: omgeving, rollout, skills-distributie en uitgaven, en de fout die optreedt als een van deze stappen wordt overgeslagen.

Deploy the environment as a shared configuration Een teamomgeving is een gedeelde configuratie: een basislijn waarvan elke ontwikkelaar begint in plaats van een reeks persoonlijke instellingen. Voor Claude Code betekent dit dat het team het eens is over een basislijn op projectniveau: een gedeelde CLAUDE. md, een afgesproken set tools en MCP servers, en een machtigingspositie, zodat mensen van dezelfde plaats beginnen in plaats van ad hoc-instellingen te ontdekken en uit elkaar te groeien. Die basislijn is iets wat je kunt beoordelen, versie en voor iedereen eenmaal verbeteren.

Roll out through champions, then batches Teamadoptie slaagt zelden als een enkele all-hands switch-on. Het patroon dat het beste werkt, is het identificeren van een champion per afdeling of team die eerst toegang krijgt, de workflow in de praktijk bewijst, en vervolgens adoptie batch voor batch zaait. De champion absorbeert de vroege wrijving, bouwt de lokale voorbeelden en wordt de eerste steun zodat de Architect niet de enige persoon is die vragen van het team kan beantwoorden.

Worked example Een engineeringorganisatie van 200 personen wil Claude Code in vier afdelingen. In plaats van alle vier tegelijk in te schakelen, schakelt de Architect één champion in elke afdeling in, geeft hen twee weken om een echte workflow om te zetten (bijv. een code-review-assist, een test-generatiestap), en laat elke champion een 45-minuten sessie voor hun eerste batch uitvoeren met vijf van hun collega's. Op het moment dat de brede rollout plaatsvindt, heeft elke afdeling een werkend voorbeeld, een lokale expert en een gedeelde CLAUDE. md die de champion al heeft afgestemd. Dezelfde rollout als een enkele massamail zou een piek van verwarde eerste prompts hebben opgeleverd en misschien zelfs een stille terugtrekking naar oude gewoonten.

Skills distribution: the team-scale version of reuse We hebben geleerd dat skill-pakketten herhaalbare procedures zijn die als versioned, herbruikbare eenheden verschijnen. Op teamschaal is de architectuurvraag: hoe zou je een skill naar je hele team distribueren? Overweeg hoe je het zou kunnen maken, versie en publiceren zodat het team het kan benaderen, hoe het verlenen en intrekken van toegang zou kunnen werken, en hoe je het zou kunnen terugdraaien als een skill zich misbehave. Er zijn vier hoofdmanieren om teamskills te distribueren, en het mechanisme dat je kiest, houdt rekening met wat het hulpmiddel is, wie het gebruikt en wie het mag beheren.

Er zijn vier manieren om een Skill naar een team in te zetten, en ze verschillen in wie er toegang toe heeft en hoeveel controle je behoudt. Een door eigenaar ingestelde Skill, geüpload onder Organization settings > Skills, wordt onmiddellijk beschikbaar voor iedereen in de organisatie. Dit is het eenvoudigste pad wanneer een mogelijkheid echt alle leden moet bereiken. Wanneer een Skill alleen bepaalde leden moet bereiken, bundel je een of meer Skills in een plugin en wijs je die plugin aan een groep toe. Alleen de leden van de groep kunnen deze skills benaderen. Plugins zijn ook waar beheerde distributie leeft: installeervoorkeuren zoals vereist, standaard geïnstalleerd, beschikbaar of niet beschikbaar, groepstargeting en versiegecontroleerde updates van een verbonden repository. Het derde mechanisme is Claude Code project Skills: bestandssysteemartefacten die in de projectrepository (. claude/skills/) leven, dus ze versie met de repository zelf en zijn beperkt tot de projecten die ze dragen. De vierde is API Skills, die programmatisch door de eigen producten van de partner worden aangeroepen. Centraal beheerde Claude Code-configuratie is een volledig ander kanaal: door server beheerde instellingen worden van Anthropic's servers geleverd wanneer gebruikers zich verifiëren en vernieuwen op een uurlijkse pollingcyclus - een instellingenmechanisme, geen Skills-distributieppad.

Skill distribution mechanisms Distribution mechanismBest whenGovernance and rollback

Org-provisioned Skill (Organization settings › Skills)Een mogelijkheid moet iedereen in de organisatie bereiken. Door eigenaar beheerde beschikbaarheid en verwijdering in de hele organisatie; gebruikers kunnen individuele skills uitschakelen maar kunnen ze niet verwijderen. Geen versie-pinning of native rollback; updates vereisen handmatig opnieuw uploaden. Plugin assigned to a group / orgEen procedure of toolset moet bepaalde teams bereiken, of die beheerde rollout nodig heeft. Groepstargeting, installeervoorkeuren die bepalen of een plugin vereist, standaard geïnstalleerd of beschikbaar voor gebruikers is (exacte labels volgens de huidige admin UI, support artikel 13837433), en versiegecontroleerde updates van een verbonden repo. Sterkste beheeropties voor groepsbereikdistributie. Het is niet het enige mechanisme met een pad terug naar een vorige versie: API Skills ondersteunen expliciete versie-pinning, en Claude Code project Skills rollen terug met de repository die ze draagt. Claude Code project SkillEen hulpmiddel of conventie die één team over zijn eigen projecten deelt. Een bestandssysteemartefact in de projectrepository (. claude/skills/), versie met de repository en beperkt tot de projecten die het dragen. API Skill (Messages API container)Een mogelijkheid die programmatisch door de eigen producten van de partner wordt aangeroepen. Beheerd in het aanroepsysteem; ondersteunt expliciete versie-pinning; hergebruik is machine-to-machine in plaats van voor mensen.

Het verpakken van een teamworkflow als een distribueerbare skill is hoe een goede lokale praktijk een teamstandaard wordt. De procedure reist als één beheerd artefact in plaats van als ongedocumenteerde know-how, en updates verspreiden zich via versioning in plaats van via opnieuw uitleggen.

Set the spend posture before the first bill Teamopstelling omvat ook de kostenbeperkingen. Admins moeten deze opzettelijk instellen in plaats van de standaardwaarden over te nemen: modelstandaarden (welk model een sessie op begint), modeltoestemmingslijsten en -beperkingen (welke modellen het team mag omschakelen), inspanningsbegeleiding (hoe hard het model aan een taak werkt), en uitgaven-, tarief- en per-gebruikersbeperkingen die het verbruik binnen grenzen houden. Module 2 toonde aan dat het niet beheren van modelkeuze stil werk naar een capabeler, duurder niveau kan routeren dan de taak vereist. Op teamschaal vermenigvuldigt die keuze zich over elk lid en elk verzoek.

Watch out for The skill that shipped with no way back. Een platformteam verpakte zijn release-notes-procedure als een skill, bundelde het in een plugin en wees het toe aan zijn groep van veertig ingenieurs. Een week later veranderde een goedbedoelde bewerking de prompt en begon de skill notes in het verkeerde formaat over elk team dat het gebruikte te produceren. De skills werden als een platte bundel gepusht zonder de versiegecontroleerde updates en rollback die een plugin biedt, dus de fix vereiste handmatige herbewerking terwijl slechte output bleef verzenden. De skill was een goed idee gedistribueerd zonder het beheer dat het vereiste. Een gedeeld asset zonder versie en geen weg terug is een aansprakelijkheid op het moment dat meer dan één persoon ervan afhangt. Wanneer een gedeeld asset versioning, groepstargeting of rollback nodig heeft, distribueer het in een door organisatie beheerde plugin en identificeer een eigenaar.

Cost · Complexity · Risk

Cost Het opzetten van een teamomgeving kost opstellingstijd: gedeelde config, een rollout-plan en skills-verpakking vooraf, maar het is veel goedkoper dan later veertig configuraties die uit elkaar zijn gegroeid, te reconciliëren. Complexity Het moeilijke deel is distributiebeheer: wie kan elk gedeeld asset bereiken, bijwerken en intrekken. Beslis dit per asset. Risk De grootste foutmodus is een gedeeld asset (bijv. een skill, een config) zonder versioning of rollback, dus één slechte wijziging verspreidt zich naar het hele team voordat iemand het kan stoppen.

Screen 3: Checkpoint: design the team distribution strategy

Team Setup · Checkpoint Checkpoint: design the team distribution strategy

Probeer het nu. Kies voor elk scenario hieronder hoe het team het herbruikbare asset moet ontvangen en identificeer de factor die dat mechanisme het juiste maakt. Een correct mechanisme gekoppeld aan de verkeerde reden slaagt niet.

A Een compliance-review-procedure die elke afdeling identiek moet uitvoeren, die centraal bijgewerkt en teruggedraaid moet kunnen worden.

Select mechanism... Org-provisioned Skill (Organization settings › Skills) Claude Code project Skill Plugin distributed org-wide (or to all relevant groups) API Skill (Messages API container)

B Een mogelijkheid die echt beschikbaar moet zijn voor elk lid, zonder behoefte aan versioning of rollback.

Select mechanism... API Skill (Messages API container) Org-provisioned Skill (Organization settings › Skills) Plugin distributed org-wide Claude Code project Skill

C Een coderingconventie en toolset die het engineeringteam over elk project moet delen.

Select mechanism... Claude Code project Skill API Skill (Messages API container) Org-provisioned Skill Plugin distributed to the engineering group

D Een herbruikbare mogelijkheid die verschillende producten van de partner programmatisch moeten aanroepen.

Select mechanism... Plugin distributed org-wide Claude Code project Skill API Skill (Messages API container) Org-provisioned Skill

Check selections Skip for now

Screen 4: Improving developer workflows with AI tooling

Dev Workflows Improving developer workflows with AI tooling Een team kan Claude perfect geconfigureerd hebben en toch weinig ervan krijgen. Het verschil is hun workflow: hoe AI-assistentie in de manier waarop ontwikkelaars werken is ingeweven, en de discipline die de output betrouwbaar houdt. Dit scherm gaat over het verhogen van de workflowstandaard zonder de kwaliteitsnorm te verlagen, en de fout die optreedt wanneer het tweede deel wordt overgeslagen.

Integrate assistance into the workflow that already exists AI-tooling loont zich wanneer het in de bestaande workflow leeft: de editor, het reviewproces en de testlus, in plaats van in een apart chatvenster dat de ontwikkelaar af en toe bezoekt. De taak van de Architect is om te vinden waar AI-assistentie de kans heeft om echte wrijving te verwijderen en het algehele proces te verbeteren. Claude moet in de huidige workflow van het team worden geïntegreerd. Integratie is ook hoe de kennis en werkwijzen van een team worden gecodeerd. De conventies, reviewstandaarden en herhaalde procedures die meestal in de hoofden van mensen leven, worden Skills en projectconfiguratie die Claude consistent toepast, zodat goede praktijk met de tooling reist in plaats van afhankelijk te zijn van wie toevallig in de kamer is.

Where Claude helps at each workflow stage, and the review discipline it still needs Workflow stageWhere Claude can helpReview discipline it still needs

Writing codeDrafting boilerplate, tests, and first-pass implementations from a clear spec. Correctness and security review; the author must understand what was generated. Reviewing codeSummarizing a diff, flagging likely issues, explaining unfamiliar code. Human judgment on the call; AI flags are input, not a verdict. DebuggingProposing hypotheses from a symptom and a trace. Verify the hypothesis against evidence before acting on it.

Two failure modes show up again and again

1Lumpy adoption: Dit treedt op wanneer enkele ontwikkelaars AI-tooling zwaar gebruiken en de rest het nauwelijks aanraken, zodat het team nooit de echte winst van het hulpmiddel realiseert en de praktijk nooit standaardiseert. De champion-en-batch rollout uit het vorige onderwerp is een geweldige manier om dit te voorkomen: het verspreidt het gebruik opzettelijk in plaats van het allemaal aan early adopters over te laten. 2Stalling at basic chat: Het team gebruikt Claude als een vraag-antwoord-box en gaat nooit verder naar de workflows met hogere waarde, zoals tool use, repository-aware assistentie, verpakte skills, omdat niemand ze voorbij de eerste stap heeft ingeschakeld. Een team toegang geven is geen adoptie; je moet voor echte enablement binnen huidige workflows configureren.

Diligence: the discipline that keeps AI-generated work trustworthy Diligence is een van de vier AI Fluency-competenties. Anthropic definieert het als verantwoordelijkheid nemen voor wat we met AI doen en hoe we het doen. Implementatiediligence betekent specifiek verantwoordelijkheid nemen voor het verifiëren en garanderen van de outputs die we gebruiken of delen. Toegepast op ontwikkelaarsworkflows, toont die verantwoordelijkheid zich als een concrete gewoonte: AI-gegenereerde code aan dezelfde standaarden houden als elke andere code, wat betekent correctheid, veiligheid en onderhoudbaarheid, en kijken naar de subtiele fout waarbij ingenieurs output accepteren die ze niet langer volledig begrijpen omdat het er goed uitziet en een controle doorstaat. Het concrete resultaat dat diligence produceert, is een verificatiechecklist: de expliciete set controles die AI-gegenereerde output moet doorstaan voordat het naar productie gaat. Deze verificatiechecklist is iets dat een team intern produceert op basis van hun specifieke behoeften. De checklist moet vragen bevatten die alle vier dimensies van verificatie adresseren: correctheid, veiligheid, onderhoudbaarheid en menselijk begrip. Waar een controle automatisch kan worden uitgevoerd, moet dit. Een regressietestsuite en een eval-set veranderen correctheid en gedragsverificatie van een reviewer's oordeel in een poort die op elke wijziging wordt uitgevoerd. De checklist definieert wat waar moet zijn. Evals en tests zijn hoe een team het herhaaldelijk bewijst in plaats van het elke keer met de hand af te leiden. Een team met die checklist heeft een goed voornemen in een herhaalbare poort veranderd; een team zonder het vertrouwt AI-output standaard en hoopt dat de reviewer vangt wat belangrijk is.

Watch out for The merge nobody could explain. Een team nam AI-ondersteunde codering aan en verzond merkbaar sneller. Drie weken later passeerde een gegenereerde wijziging code review en tests en ging naar productie, waar het gegevens lekte via een input die het nooit valideerde. In de post-incident review kon de auteur niet uitleggen waarom de code die input op die manier afhandelde; het zag er plausibel uit, de tests waren groen, en niemand stelde de vraag die de checklist zou hebben geforceerd: kan de persoon die dit samenvoegt uitleggen wat het doet en waarom? Snelheid had stilletjes begrip vervangen, wat precies het oordeel erosie is die diligence bestaat om te vangen.

Cost · Complexity · Risk

Cost AI-assistentie verlaagt de kosten van codeproductie, wat het volume verhoogt dat review bereikt; de verificatiechecklist is wat dat volume ervan weerhoudt om de kwaliteitsnorm te overweldigen. Complexity Het moeilijke deel is cultureel, niet technisch: AI-gegenereerde code aan dezelfde reviewstandaard houden als handgeschreven code, vooral wanneer het sneller verzonden wordt en er goed uitziet. Risk De grootste foutmodus is oordeel erosie: een team dat output verzend die het niet langer begrijpt omdat het ondiepe controles doorstond, totdat een input die niemand redeneerde naar productie gaat.

Screen 5: Exercise: define the verification checklist

Dev Workflows · Exercise Exercise: define the verification checklist

Probeer het nu. Schrijf de verificatiechecklist die AI-gegenereerde code moet doorstaan voordat productie. Voor elk van de vier dimensies hieronder, schrijf één concrete controle in je eigen woorden. Schrijf je checklist en onthul vervolgens het modelantwoord hieronder.

Correctness

Security

Maintainability

Human understanding

Reveal model answer

Correctness: Tests exist and pass, and the behavior matches the stated requirement including edge cases. Security: No secrets in code; inputs are validated; any tools or external calls use least-privilege access. Maintainability: The code reads clearly, follows team conventions, and contains no unexplained complexity. Human understanding: The developer submitting the change can explain what the code does and why, including how it handles the inputs it was not explicitly tested against.

Mark checklist complete Skip for now

Screen 6: Supporting debugging and operational issue resolution

Operational Support Supporting debugging and operational issue resolution Er is altijd een moment waarop een live deployment zijn team verrast. Wanneer het gebeurt, is de Architect de persoon die verbindt wat het team ziet met waarom het gebeurt. De Architect is ook verantwoordelijk voor het opschalen van het team, zodat ze de volgende keer zich gesterkt voelen om het probleem zelf op te lossen. Dit scherm gaat over de ondersteuningsrol, de symptoom-naar-oorzaak-redenering die het definieert, en het opbouwen van het team naar zelfstandigheid.

The support role is translation, not firefighting Wanneer een operationeel probleem aankomt, identificeert het team meestal een symptoom, geen oorzaak. Ze zullen bijvoorbeeld opmerken dat latentie piekte, outputs verslechterden of een hulpmiddel niet meer werkte. Het team trekt dan de Architect erin, wiens waarde is het verbinden van het operationele symptoom met zijn architectuuroorzaak: dezelfde diagnostische discipline die Module 2 voor productiesystemen bouwde, nu toegepast ter ondersteuning van een team dat eigenaar is van de implementatie. Het zelf oplossen van één incident is brandbestrijding; het team het symptoom-naar-oorzaak-pad leren dat ze in de toekomst opnieuw kunnen volgen, is ondersteuning die duurt.

Connect symptoms to architecture causes Veel operationele symptomen traceren naar een kleine set architectuuroorzaken. Het identificeren hiervan stelt het team in staat om duidelijk van wat ze zien naar waar ze moeten kijken te redeneren. Symptom → likely architecture cause → first action SymptomLikely architecture causeFirst action

Output quality degraded gradually, but there was no code changeEen model- of promptwijziging, of retrieval drift naarmate het corpus groeide. Vergelijk met een eval-set; controleer wat er in het model, de prompt of het corpus is veranderd. Latency spikedContext size grew, a tool got slow, or a cache stopped hitting. Gebruik telemetrie en request traces om de langzaamste span te vinden: controleer token counts per request en de langzaamste tool call, en bevestig cache-gedrag. Intermittent tool failuresAuthorization, rate limits, or an unhandled error path. Inspecteer de auth en limieten van het falende hulpmiddel; trace één mislukte call van begin tot eind. Cost rose without a usage changeModel tier crept up, or caching regressed. Controleer per-request model tier en cache hit rate tegen het budgetmodel.

Build self-sufficiency: runbooks and escalation paths Zelfstandigheid is in functionerende teams ingebouwd. Een runbook legt de bekende symptoom-naar-oorzaak-naar-actie-paden vast zodat het team terugkerende problemen kan oplossen zonder de Architect. De tabel hierboven is de basis van een goed runbook. Een escalatiepad identificeert wie wat afhandelt en wanneer een probleem het team verlaat, zodat mensen de grens kennen van wat ze kunnen oplossen en wat moet worden geëscaleerd. Moedig een team altijd aan om een runbook voor hun implementatie bij te houden en een duidelijk escalatiepad te definiëren. Het doel is een team dat je alleen nodig heeft wanneer nieuwe problemen ontstaan, niet voor problemen die je ze al hebt geleerd hoe ze moeten aanpakken.

Watch out for The drift that waited for a quarterly review. Een ondersteuningsteam keek hoe de dashboards van een implementatie een heel kwartaal groen bleven terwijl de antwoordkwaliteit stilletjes afgleed. Niemand verbond de langzame afname met de oorzaak: een groeiend retrieval corpus dat de index niet had bijgehouden. De symptomen waren de hele tijd zichtbaar, maar de runbook-ingang die zegt dat geleidelijke kwaliteitsdaling zonder codewijziging wijst op het model, de prompt of retrieval drift ontbrak. Met dat pad geschreven, kon een eerste-lijn ingenieur het probleem in een middag oplossen; maar zonder het, wacht het op een review.

Cost · Complexity · Risk

Cost Het team het symptoom-naar-oorzaak-pad leren kost meer van de Architect's tijd vooraf dan het incident direct op te lossen, maar het is de enige versie van ondersteuning die toekomstige belasting vermindert in plaats van het te herhalen. Complexity Het moeilijke deel is het weerstaan van de drang om brand te bestrijden: de snelle fix is om het zelf op te lossen, maar de duurzame fix is het team helpen een runbook-ingang te maken en het escalatiepad te identificeren dat het team het volgende probleem zonder je hulp kan oplossen. Risk De grootste foutmodus is een langzame degradatie die niemand met een oorzaak verbindt, dus het loopt totdat een geplande review het vangt in plaats van dat het team het de dag dat het begint vangt.

Screen 7: Module quiz

Module · Quiz Module quiz

Vijf scenariavragen over de drie onderwerpen. Kies het beste antwoord; de feedback noemt het principe.

Question 1 · Team setup Een team rolt Claude tegelijk naar vier afdelingen uit en adoptie is ongelijk. Wat is de beste volgende stap?

AMandate daily usage targets for everyone. BEnable a champion in each department first, prove the workflow, then seed adoption in batches. CWait until each department asks for help. DGive the strongest model to everyone to encourage use.

Question 2 · Skills distribution Een procedure moet identiek door elke afdeling worden uitgevoerd en moet van één plaats kunnen worden ingetrokken. Hoe moet het worden gedistribueerd?

APasted into each team's chat as a prompt. BBundled into an organization-managed plugin distributed to all departments, with group/org targeting, version-controlled updates, and rollback. CA Claude Code project config in one team's repo. DEmailed as a document for people to follow.

Question 3 · Developer workflows Een team verzend AI-gegenereerde code sneller maar een beveiligingsprobleem glipt door. Wat ontbrak waarschijnlijk het meest?

AA code-review SLA that exempted small AI-generated changes from security review. BA linter configured to flag known vulnerability patterns before merge. CA verification checklist that AI-generated code must pass before production, including a security dimension. DMore frequent model updates to incorporate recent security patterns.

Question 4 · Judgment Bij review kan een ontwikkelaar niet uitleggen waarom een AI-gegenereerde wijziging een input op die manier afhandelt, maar de tests slagen. Wat moet er gebeuren?

AMerge it; the tests are green. BHold it until the author can explain the behavior and its rationale, the human-understanding check. CDelete the tests and rewrite by hand. DEscalate to the Architect for every merge.

Question 5 · Operational support Output quality op een live deployment is over twee maanden verslechterd zonder codewijzigingen. Waar kijkt de Architect eerst?

AIncrease the model tier; a more capable model will compensate for retrieval gaps. BA model or prompt change, or retrieval drift as the corpus grew, connect the symptom to an architecture cause. CDisable caching to ensure every call pulls fresh content. DRoll back the last code deployment and re-run integration tests.

Submit quiz Skip for now

Screen 8: Glossary

Wrap-up · Reference Glossary De sleuteltermen die in deze module worden gebruikt, in alfabetische volgorde. Klik op een term om de definitie uit te breiden.

Champion-per-department rolloutEen adoptiemotief dat eerst één champion per team inschakelt om de workflow te bewijzen, vervolgens adoptie batch voor batch zaait. Escalation pathEen benoemde definitie van wie wat afhandelt en wanneer een operationeel probleem het team verlaat. RunbookEen vastgestelde set bekende symptoom-naar-oorzaak-naar-actie-paden die een team terugkerende operationele problemen kan oplossen zonder de Architect. Shared configurationEen enkele teambasislijn (bijvoorbeeld een project CLAUDE. md, afgesproken tools en machtigingspositie) waarvan elk lid begint, in plaats van individuele instellingen die uit elkaar groeien. Skills distributionEen Skill voor de juiste mensen krijgen via een van vier mechanismen, elk met ander toegang-, versioning- en rollback-gedrag: org-provisioned Skills (Organization settings > Skills) voor organisatiebrede beschikbaarheid; plugins toegewezen aan een groep of organisatie voor bereikdistributie met installeervoorkeuren, versiegecontroleerde updates en rollback; Claude Code project Skills versioned met de repository en beperkt tot een team; en API Skills die programmatisch met expliciete versie-pinning worden aangeroepen. Spend postureModel defaults, model allowlists en -beperkingen, inspanningsbegeleiding en uitgaven-, tarief- en per-gebruikersbeperkingen ingesteld als onderdeel van teamconfiguratie houden verbruik binnen grenzen. Verification checklistDe expliciete set correctheid-, veiligheid-, onderhoudbaarheid- en menselijk-begripcontroles die AI-gegenereerde output moet doorstaan voordat productie.

Screen 9: Recap: four things that hold across everything here

Module · Recap Recap: four things that hold across everything here

Team setup is shared configuration, distribution, and spend posture decided up front Een teamomgeving is een gedeelde basislijn plus een Skills-distributiebenadering: org-provisioned voor iedereen, plugins voor groeps- en organisatietargeting met versioned updates en rollback, project Skills voor één team, en API Skills voor programmatisch hergebruik, allemaal begrensd door model- en budgetbeperkingen.

Adoption is engineered through champions and batches Een champion per team bewijst de workflow en zaait adoptie; toegang zonder enablement stalt bij basic chat, en ongelijke adoptie standaardiseert de winst nooit.

Diligence keeps AI-assisted work trustworthy Houd AI-gegenereerde code aan correctheid-, veiligheid- en onderhoudbaarheidsstandaarden, en vereisen dat de auteur kan uitleggen wat verzonden werd, vastgelegd als een verificatiechecklist die voor productie gaat.

Operational support is translation plus self-sufficiency Verbind symptomen met architectuuroorzaken en laat runbooks en escalatiepaden achter zodat het team je nodig heeft voor het nieuwe probleem, niet het vertrouwde.

Dat voltooit de Architect-track. Je kunt een implementatie van de eerste zin van een stakeholder door design, integratie, governance, handoff nemen en deze aan het team leveren dat het adopteert en uitvoert.

Sources

Anthropic Skilljar, Building with the Claude API: tool use, API integration mechanics, and baseline Skills concepts carried into team distribution. Claude Code configuration docs (code. claude. com): CLAUDE. md instructions vs. enforceable settings, permissions, hooks, MCP, and managed settings. Claude Code Skills and organization Skills provisioning docs: Skill package structure, project Skills, plugin-based distribution, and owner-provisioned org-wide availability. Organization plugin management (support. code. com): Plugin marketplaces, group assignment, install preferences, required/default install, hide/deprecate behavior, manual upload, Github sync, update, and removal mechnics.

Screen 10: Congratulations! You have successfully completed this module.

Module Complete · Architect · 2 min Congratulations! You have successfully completed this module. Module 5 behandelt de teamtoolingconfiguratie, workflowontwerp voor ontwikkelaars en operationele ondersteuningspraktijken die AI-productiviteit in stand houden zodra een implementatie live is. Een implementatie die het team niet kan bedienen, debuggen en verbeteren, zal niet productief blijven; je hebt nu de patronen om het draaiende te houden.

0 of 0 checkpoints passed

Claude Platform & Solution Design Model selection, prompt architecture, tool design, and platform-layer tradeoffs.

Enterprise Integration & Production Deployment patterns, integration architecture, and production reliability.

Responsible AI, Safety & Risk Safety frameworks, risk identification, and governance practices.

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder communication, lifecycle management, and go-to-market strategy.

Team Enablement and Operational Productivity Team tooling configuration and operational support practices.

You Are Here

Review module Start over