Claude Code Wiki

The 'AI Will Replace Programmers' Narrative

Mon, 01 Jan 0001 00:00:00 +0000

The “AI Will Replace Programmers” Narrative#

What’s actually happening vs. what people think is happening, based on conversations with colleagues, observations from local meetups, and the steady stream of hot takes online.

The Claim#

Non-technical people are building personal tools with AI and concluding:

We don’t need programmers anymore
Anyone can vibe-code an application
SaaS is dead because why pay for something you can build yourself

What’s Actually True#

The barrier to building personal tools has genuinely collapsed. Someone who couldn’t code two years ago can now build something that solves their specific problem. That’s real and worth taking seriously.

Amazon Bedrock Fundamentals

Mon, 01 Jan 0001 00:00:00 +0000

Amazon Bedrock Fundamentals#

What Is Amazon Bedrock?#

Bedrock is AWS’s managed API gateway for foundation models. Instead of going directly to Anthropic for model access, Bedrock gives you a single AWS-native service that brokers access to foundation models through the same IAM, billing, networking, and compliance infrastructure you already use for everything else in AWS.

Analogy for Cloud Foundry practitioners: If Cloud Foundry abstracts away infrastructure for app developers, Bedrock does the same for model inference. Developers don’t think about where Claude is running – they just call the API. The platform team controls the networking, access, cost, and compliance layer underneath.

Audit and Compliance -- Three-Layer Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Audit and Compliance – Three-Layer Architecture#

Layer 1: AWS CloudTrail#

Captures every Bedrock InvokeModel call with IAM principal attribution.

What it records:

Timestamp of every API call
IAM principal (which user/role made the call)
Model ID invoked
Source IP address
Request parameters (not prompt content by default)

Configuration:

Enable CloudTrail in the dedicated Bedrock AWS account
Send logs to a centralized S3 bucket with immutable retention policy
Set up CloudWatch Alarms for unusual patterns (e.g., API calls outside business hours, unexpected model IDs)

Limitation: CloudTrail records that a call was made but not what was asked or returned. It’s an access log, not a content log.

Build-Out Timeline -- 12-Week Implementation

Mon, 01 Jan 0001 00:00:00 +0000

Build-Out Timeline – 12-Week Implementation#

Week-by-Week Schedule#

Weeks 1–2: Discovery and Infrastructure Design#

Infrastructure Workstream

CISO alignment meeting: define “no code leaves network” (Level 1, 2, or 3)
Design AWS account structure for Bedrock isolation
Design VPC endpoint + PrivateLink architecture
Evaluate LLM gateway options (LiteLLM vs. Kong vs. Portkey)
Begin Terraform for VPC endpoint and networking

Platform Engineering Workstream

Inventory top 5 codebases by developer count
Interview 2–3 senior engineers per codebase: “What do you always tell new developers? What patterns do people consistently get wrong?”
Identify Cohort 1 candidates (25 power users)

Change Management Workstream

Phased Rollout -- Cohort Strategy

Mon, 01 Jan 0001 00:00:00 +0000

Phased Rollout – Cohort Strategy#

Principle#

Don’t light up 500 developers at once. Each cohort discovers different classes of issues and builds institutional knowledge for the next cohort.

Cohort 1: Power Users (25 developers, Weeks 5–6)#

Selection Criteria#

Hand-picked across 3–4 teams representing different technology stacks
Mix of senior engineers (who know the patterns) and enthusiastic mid-levels (who’ll push boundaries)
At least one developer per major codebase
Include developers who are already CLI/terminal-native

Objectives#

Validate infrastructure end-to-end (Bedrock routing, gateway, PrivateLink)
Test managed-settings.json enforcement – do the deny rules work? Does bypass mode stay disabled?
Write the first project CLAUDE.md and agent_docs/ files for their repos
Co-create the initial 5–8 org-wide skills based on real workflows
Become internal champions who can support Cohort 2

Expected Discoveries#

Bedrock inference profiles required for on-demand usage (common first gotcha)
Prompt caching behavior differs from direct API
Some model versions lag behind on Bedrock
Specific CLAUDE.md instructions that Claude follows well vs. ignores
MCP servers that are most valuable for the org’s toolchain
Skills that need more or fewer steps than initially designed
Edge cases in deny rules (false positives blocking legitimate work)

Success Metrics#

All 25 developers able to use Claude Code through the enterprise infrastructure
At least 3 project CLAUDE.md files written and reviewed
At least 5 org-wide skills tested and iterated
Zero security policy violations (deny rules holding)
Qualitative feedback: “This makes me faster” vs. “This gets in the way”

Platform Team Commitment#

Daily Slack channel for issues during first week
30-minute stand-up twice per week with Cohort 1
Same-day turnaround on configuration issues

Cohort 2: Full Teams (100 developers, Weeks 7–9)#

Selection Criteria#

Expand to complete teams (beyond individual developers)
Include at least one team that’s skeptical – they’ll surface real objections
Include the team with the most complex codebase

Objectives#

Stress-test the LLM gateway’s rate limiting and budget model
Validate that team-level CLAUDE.md and skills work across a full team
Discover the actual cost model (tokens per developer per day)
Instrument OpenTelemetry metrics

New Infrastructure Requirements#

Gateway rate limiting tuned based on Cohort 1 usage patterns
Per-team token budgets configured
CloudWatch dashboards showing per-user token consumption, latency percentiles, error rates
Cost allocation tags in AWS for team-level billing

Expected Discoveries#

Real-world token consumption rates (expect 50K–200K tokens/developer/day depending on usage intensity)
Teams that use Claude Code very differently (some use it for code gen, others for review, others for documentation)
Teams that need different model access (Opus for architecture work, Sonnet for routine coding)
Edge cases in project CLAUDE.md that only surface with diverse usage patterns

Success Metrics#

Gateway handles 100 concurrent developers without latency spikes
Per-team budgets prevent runaway costs
At least 80% of developers reporting increased productivity
Zero infrastructure outages
Cost model validated and predictable

Platform Team Commitment#

Slack channel continues, monitored 8am–6pm
Weekly office hours for questions
Bi-weekly feedback surveys

Cohort 3: Full Organization (375 developers, Weeks 10–12)#

Prerequisites (Must Be True Before Launching)#

Gateway proven at 100-developer scale
Managed-settings.json deployed to all developer machines via Mobile Device Management (MDM)
Internal documentation written by Cohort 1 champions
Onboarding guide tested with Cohort 2 (developers who weren’t hand-picked)
Cost projections validated and approved by finance
CISO sign-off on the security architecture still current

Rollout Approach#

Department-by-department, not all-at-once
Each department gets a 15-minute onboarding session led by a Cohort 1/2 champion
Self-service documentation available for async onboarding
Platform team monitors gateway metrics for capacity issues

Expected Discoveries#

Long-tail support issues from developers with non-standard setups
Teams that need custom skills not anticipated during Cohort 1/2
Organizational patterns in how different teams use Claude Code
Real productivity data at scale for leadership reporting

Success Metrics#

90%+ of developers have used Claude Code at least once within 2 weeks of access
Weekly active usage rate > 60% after first month
Support ticket volume declining (not growing) after first 2 weeks
Total cost within 10% of projection
No security incidents

Rollback Plan#

Principle#

Rollback is cohort-level, not all-or-nothing. If a cohort encounters serious issues, pause that cohort while earlier cohorts continue operating.

Developer Path

Mon, 01 Jan 0001 00:00:00 +0000

Developer Path#

A structured progression from basic Claude Code usage to advanced workflows. Each module builds on the previous one – work through them in order.

Module	Focus	Prerequisites
1. Prompting Foundations	Writing requests that produce correct code	None
2. The Verification Loop	Building feedback into every task	Module 1
3. Test-Driven Development	Using tests as requirements for Claude	Module 2
4. Debugging with Claude	Systematic troubleshooting when things break	Modules 2-3
5. Context Management	Understanding what Claude sees and remembers	Modules 1-4
6. Extending Claude Code	Subagents, skills, MCP servers, and custom tooling	Module 5

Exercise Materials#

Clone the exercise repo for hands-on practice alongside each module:

Effective Prompting: Getting Better Results from Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Effective Prompting: Getting Better Results from Claude Code#

Executive Summary#

The quality of your results from Claude Code depends heavily on how you structure your requests. Claude Code’s latest models (Opus 4.6, Sonnet 4.5) follow instructions precisely – which means vague prompts get vague results and specific prompts get specific results. Understanding a few key patterns dramatically improves outcomes.

Principle	Impact	Effort
Be explicit, not vague	Biggest single improvement in result quality	Low
Action over suggestion	Gets implementation instead of recommendations	Low
Provide context (“why”)	Helps Claude generalize and make good choices	Low
Reference specific code	Eliminates guesswork and speeds up responses	Low
Decompose large tasks	Reduces errors, enables course correction	Medium
Use CLAUDE.md well	Persistent rules applied to every message	One-time
Manage multi-window work	Enables tasks that span beyond a single session	Medium

Table of Contents#

Effective Prompting: Getting Better Results from Claude Code

How Claude Code Processes Your Messages#

Every message you type becomes part of an API call that includes the full system prompt, entire conversation history, and your new message. Claude reads all of this – the system prompt instructions, your CLAUDE.md rules, the skill catalog, every previous turn – before generating a response.

Executive Summary

Mon, 01 Jan 0001 00:00:00 +0000

Executive Summary#

The Engagement#

A 500-developer engineering organization with strict security requirements needs to adopt Claude Code as an enterprise-wide AI-assisted development tool. Their core constraint: no code can leave their network.

This document describes a 12-week implementation across three workstreams:

Infrastructure (30% effort): Cloud LLM service (AWS Bedrock / GCP Vertex AI / Azure Foundry) + private networking + LLM Gateway
Platform Engineering (40% effort): Managed configurations, CLAUDE.md architecture, skills library, developer environments
Change Management (30% effort): Phased rollout, champion program, productivity measurement

The Architecture in One Paragraph#

Developer workstations connect through the corporate network to an internal LLM gateway (LiteLLM or Kong AI Gateway), which routes requests through a VPC endpoint via AWS PrivateLink to Amazon Bedrock. Bedrock hosts the Claude models within AWS’s data boundary. No traffic touches the public internet. No code is retained or used for training. The LLM gateway provides per-user token budgets, centralized authentication, and audit logging. Managed settings enforce organization-wide security policies that individual developers cannot override.

Subagents, Skills, and MCP Servers: Architecture Deep Dive

Mon, 01 Jan 0001 00:00:00 +0000

Subagents, Skills, and MCP Servers: Architecture Deep Dive#

Executive Summary#

Claude Code extends capabilities through three distinct mechanisms with different isolation models, memory characteristics, and context window implications:

Aspect	Subagents	Skills	MCP Servers
Purpose	Task delegation with reasoning	Knowledge/workflow injection	External tool/API access
Reasoning	Full AI (isolated instance)	Inherits main instance	None (deterministic)
Memory	Session-based, resumable	Shared with main	Stateless per call
Context	Own isolated window	Injected into main	Minimal overhead
Invocation	Explicit (Task tool)	Auto-discovered	Explicit tool calls
State	Fresh but resumable	Part of main conversation	Truly stateless

Table of Contents#

Subagents, Skills, and MCP Servers: Architecture Deep Dive

Subagents (Task Tool)#

What They Are#

Subagents are specialized AI assistants spawned via the Task tool. Each operates as an independent Claude instance with its own conversation context.

Managed Settings and Security Policy

Mon, 01 Jan 0001 00:00:00 +0000

Managed Settings and Security Policy#

Overview#

The managed-settings.json file is the enterprise-level configuration that sits at the top of Claude Code’s settings hierarchy and cannot be overridden by any developer or project-level setting. It’s deployed to every developer machine via Mobile Device Management (MDM) or configuration management tooling.

Baseline Enterprise Configuration#

{
 "env": {
 "CLAUDE_CODE_USE_BEDROCK": "1",
 "ANTHROPIC_BEDROCK_BASE_URL": "https://llm-gateway.internal.corp.com/bedrock",
 "CLAUDE_CODE_SKIP_BEDROCK_AUTH": "1",
 "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
 },
 "cleanupPeriodDays": 14,
 "permissions": {
 "disableBypassPermissionsMode": "disable",
 "deny": [
 "Read(**/.env)",
 "Read(**/.env.*)",
 "Read(**/secrets/**)",
 "Read(**/.ssh/**)",
 "Read(**/credentials*)",
 "Bash(sudo:*)",
 "Bash(su:*)",
 "Bash(curl:*)",
 "Bash(wget:*)",
 "Bash(ssh:*)",
 "Bash(rm -rf:*)"
 ]
 },
 "allowManagedPermissionRulesOnly": false,
 "allowManagedHooksOnly": false,
 "strictKnownMarketplaces": []
}

Key Design Decisions#

Bedrock Routing (env section)#

CLAUDE_CODE_USE_BEDROCK: Routes all requests through Bedrock instead of api.anthropic.com
ANTHROPIC_BEDROCK_BASE_URL: Points to the internal LLM gateway, not directly to Bedrock
CLAUDE_CODE_SKIP_BEDROCK_AUTH: The gateway holds AWS credentials, developers don’t need them

Telemetry Lockdown#

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC bundles four flags into one:

Product Thinking for Engineers

Mon, 01 Jan 0001 00:00:00 +0000

Product Thinking for Engineers#

Executive Summary#

Most engineers build what they’re told to build, and build it well. The gap is that “well” usually means technically sound – correct algorithms, clean architecture, good test coverage – while the thing being built may not solve the problem it was meant to solve. Product thinking is the discipline of questioning what you’re building and why, before optimizing how.

Article	Focus	What You’ll Get
Product Thinking (this page)	Why engineers should care about product work	A concrete example of product-blind vs. product-aware engineering, and how the section fits together
User Research & Validation	Discovering what users need	Interview techniques, assumption mapping, validation methods
Requirements & Specifications	Turning research into buildable definitions	Spec writing, acceptance criteria, traceability
Prototyping & Iteration	Building to learn, not to ship	Throwaway prototypes, feedback loops, iteration discipline
Prioritization & Trade-offs	Deciding what to build next	Impact vs. effort, RICE scoring, opportunity cost, cost of delay, saying no

The Gap Between Building and Solving#

Engineers optimize. Given a problem, they reduce latency, improve throughput, eliminate edge cases, and harden failure modes. This is valuable work. It is also, frequently, the wrong work.

Enterprise Claude Code Adoption -- Skill Gaps

Mon, 01 Jan 0001 00:00:00 +0000

Enterprise Claude Code Adoption – Skill Gaps#

The Meta-Gap#

Enterprises treat Claude Code adoption as a training problem (“teach developers to use the tool”) when it’s really a platform engineering problem (“build the scaffolding so the tool works well for everyone by default”).

Six Key Gaps#

1. Prompt Engineering as a Development Discipline#

Most enterprise developers treat Claude Code like a slightly smarter autocomplete. They haven’t internalized that the skill system, CLAUDE.md files, and structured context injection are where the actual value is. The gap isn’t “can you use the tool” but “can you make the tool consistently produce enterprise-grade output.”

Implementation Support Landscape

Mon, 01 Jan 0001 00:00:00 +0000

Implementation Support Landscape#

Layer 1: AWS (Infrastructure Plumbing)#

AWS Solutions Architects (Free)#

Every enterprise account gets assigned SAs who can help design networking. They’ll walk through VPC endpoint setup, Direct Connect integration, and IAM policy design. Excellent at the infrastructure layer.

AWS Professional Services (Paid)#

Hands-on implementation engagements. Now have people specifically focused on Bedrock deployment patterns. The “Guidance for Claude Code with Amazon Bedrock” reference architecture implements proven patterns deployable in hours – ProServ uses this as a starting point.

The System Prompt: What Claude Reads Before You Say Anything

Mon, 01 Jan 0001 00:00:00 +0000

The System Prompt: What Claude Reads Before You Say Anything#

Executive Summary#

The system prompt is the hidden instruction text sent to the model on every API call, before any conversation messages. It defines Claude’s behavior, available tools, safety rules, and injected knowledge. In Claude Code, it’s assembled from multiple sources and re-sent with every message – making it the single largest factor in per-message token overhead.

Component	Source	Typical Size
Core instructions	Claude Code built-in	~3,000-5,000 tokens
Tool definitions	Built-in + MCP servers	~3,000-5,000 tokens
CLAUDE.md files	User, project, enterprise scopes	~2,000-4,000 tokens
Skill catalog	Enabled skills + plugins	~2,000-5,000 tokens
Subagent catalog	Plugin subagent descriptions	~1,000-2,000 tokens
Environment + git context	Auto-detected	~200-500 tokens
Typical total		~12,000-20,000 tokens

Table of Contents#

The System Prompt: What Claude Reads Before You Say Anything

What the System Prompt Is#

Every API call to Claude has three parts: system prompt, conversation history, and the current message. The system prompt is the first part – instructions the model reads before seeing any conversation.

Architecture Overview

Mon, 01 Jan 0001 00:00:00 +0000

Architecture Overview#

End-to-End Request Flow#

┌─────────────────────────────────────────────────────────────────────┐
│ CORPORATE NETWORK │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ Developer 1 │ │ Developer 2 │ │ Developer N │ │
│ │ claude CLI │ │ claude CLI │ │ claude CLI │ │
│ │ │ │ │ │ │ │
│ │ managed- │ │ managed- │ │ managed- │ │
│ │ settings.json│ │ settings.json│ │ settings.json│ │
│ └──────┬────────┘ └──────┬────────┘ └──────┬────────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ LLM GATEWAY │ │
│ │ (LiteLLM / Kong AI) │ │
│ │ │ │
│ │ • SSO authentication │ │
│ │ • Per-user/team budgets │ │
│ │ • Rate limiting │ │
│ │ • Request logging │ │
│ │ • Model routing │ │
│ │ • Holds AWS credentials │ │
│ └───────────┬──────────────┘ │
│ │ │
└──────────────────────────┼──────────────────────────────────────────┘
 │ (Direct Connect / Site-to-Site VPN)
 │
┌──────────────────────────┼──────────────────────────────────────────┐
│ AWS ACCOUNT (Dedicated) │
│ │ │
│ ┌───────────┴─────────────┐ │
│ │ VPC ENDPOINT │ │
│ │ (PrivateLink) │ │
│ │ │ │
│ │ com.amazonaws.{region} │ │
│ │ .bedrock-runtime │ │
│ │ │ │
│ │ Policy: InvokeModel, │ │
│ │ InvokeModelWith │ │
│ │ ResponseStream ONLY │ │
│ └───────────┬─────────────┘ │
│ │ │
│ ┌───────────┴─────────────┐ │
│ │ AMAZON BEDROCK │ │
│ │ │ │
│ │ Claude Sonnet/Opus │ │
│ │ (primary model) │ │
│ │ │ │
│ │ Claude Haiku │ │
│ │ (fast model) │ │
│ │ │ │
│ │ • No data retention │ │
│ │ • No training use │ │
│ │ • CloudTrail audit │ │
│ └─────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ OBSERVABILITY │ │
│ │ • CloudTrail → every InvokeModel call with IAM principal │ │
│ │ • CloudWatch → token usage, latency, error rates │ │
│ │ • Cost Explorer → per-account Bedrock spending │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘

Note: This diagram shows AWS Bedrock deployment. Equivalent architectures for GCP Vertex AI (VPC Service Controls, Private Service Connect, Cloud Logging) and Azure Foundry (Private Endpoints, VNet integration, Azure Monitor) are documented in the Phase 0 infrastructure guides.

Building Custom Subagents & Skills: Extending Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Building Custom Subagents & Skills: Extending Claude Code#

Executive Summary#

Claude Code’s capabilities can be extended through custom subagents (autonomous task executors with isolated context), skills (injected instructions that guide behavior), and plugins (packages that bundle everything together). This article covers how to build each from scratch – file structures, YAML configuration, tool permissions, model selection, and the architectural patterns that make extensions effective.

Extension	What It Is	File Location	When It Runs
Subagent	Isolated AI worker	`.claude/agents/*.md`	When Claude delegates a task
Skill	Injected instructions	`.claude/skills/*/SKILL.md`	Auto-discovered or `/invoked`
Plugin	Packaged bundle of all three	Plugin marketplace or local	When plugin is enabled

Table of Contents#

Building Custom Subagents & Skills: Extending Claude Code

Subagents#

What Subagents Are#

A subagent is an isolated AI worker that Claude delegates tasks to. Each subagent gets its own context window, its own system prompt, and a defined set of tools. When Claude spawns a subagent, the main conversation’s context is protected – the subagent does its work, returns a result, and that result is all that enters the main context.

Cloud Foundry to Claude Code Analogy Map

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Foundry to Claude Code Analogy Map#

For consultants coming from a Cloud Foundry background, these analogies help translate platform engineering concepts into the Claude Code domain.

Core Concept Mapping#

Cloud Foundry	Claude Code	Explanation
Org/Space structure	Settings hierarchy (managed → project → user)	Multi-level configuration with inheritance and isolation between teams
Buildpacks	Skills and CLAUDE.md conventions	Opinionated frameworks that encode best practices – developers get patterns by default
Service Broker catalog	Approved MCP servers	Curated set of external integrations available to developers, centrally managed
App manifest (manifest.yml)	Project `.claude/settings.json` + `CLAUDE.md`	Declarative configuration checked into the repo that defines how the tool interacts with the project
Platform operator	Platform engineering team managing `managed-settings.json`	Central team that owns the platform layer, sets policies, and enables developer self-service
`cf push`	Developer runs `claude` with everything pre-configured	The developer experience is simple because the platform handles complexity underneath
Stemcells / base images	Devcontainers / Coder workspace templates	Standardized environment that ensures consistent tooling across all developers
Diego cells	LLM Gateway + Bedrock	The compute layer that actually runs workloads, abstracted from the developer
UAA (User Account and Authentication)	SSO + gateway authentication	Centralized identity and access management
Quota plans	Per-team token budgets via LLM gateway	Resource limits that prevent any single team from consuming disproportionate capacity
App security groups	Deny rules in managed-settings.json	Network/access restrictions that define what the workload can and cannot reach
Route services / service mesh	LLM Gateway (LiteLLM / Kong AI)	Intermediary that handles routing, auth, logging, and policy enforcement
BOSH releases	Skills packaged as plugins	Versioned, distributable packages of capability
Cloud Controller API	Claude Code CLI + MCP protocol	The interface through which developers and automation interact with the platform
Logs / Loggregator	CloudTrail + gateway logs + CloudWatch	Multi-layer observability stack for audit, debugging, and cost tracking
Ops Manager tiles	MCP server integrations	Pre-built integrations that extend the platform’s capabilities

The Core Insight#

Claude Code without platform engineering is like giving 500 developers raw cf push access with no buildpacks, service brokers, or app manifests.

Context Management: Working Within the Token Budget

Mon, 01 Jan 0001 00:00:00 +0000

Context Management: Working Within the Token Budget#

Executive Summary#

The context window is Claude’s working memory – everything the model can reference when generating a response. In Claude Code, it fills with the system prompt, conversation history, tool results, and file contents. Managing this space is the single most important factor in maintaining effective sessions as they grow longer.

Model	Standard Window	Extended (Beta)	Long Context Pricing
Claude Opus 4.6	200K tokens	1M tokens	2x input, 1.5x output above 200K
Claude Sonnet 4.6	200K tokens	1M tokens	2x input, 1.5x output above 200K
Claude Sonnet 4.5	200K tokens	–	–
Claude Sonnet 4	200K tokens	–	–
Claude Haiku 4.5	200K tokens	–	–

The 1M token context window is currently available in beta on the API only. Standard claude.ai and Claude Code users access the 200K window unless the beta header is explicitly enabled.

Cost Tracking and Budgets

Mon, 01 Jan 0001 00:00:00 +0000

Cost Tracking and Budgets#

The Cost Challenge#

Bedrock bills per-token. 500 developers using Opus for everything can cost $50K–$200K+/month depending on usage intensity. Without controls, costs are unpredictable and can spike when developers discover long-running agentic workflows.

Model Tiering Strategy#

The LLM gateway is the control point for cost management.

Use Case	Model	Approx. Cost	Access
Routine coding, quick edits	Sonnet	Lower per-token	Default for all developers
Architecture, complex reasoning	Opus	Higher per-token	Gated to senior engineers or by request
Summarization, classification	Haiku	Lowest per-token	Claude Code uses automatically as fast model

Implementation#

Configure the LLM gateway to:

Developer Environment Standardization

Mon, 01 Jan 0001 00:00:00 +0000

Developer Environment Standardization#

The Problem#

Without standardization, 500 developers debug 500 different environment configurations. Claude Code needs Node.js 18+, correct environment variables, network connectivity to the LLM gateway, and managed settings in the right filesystem location. Every permutation is a support ticket.

Option A: Managed Devcontainers (Recommended for VS Code/Codespaces Orgs)#

If the org uses VS Code or GitHub Codespaces, create a standard devcontainer with everything pre-configured.

// .devcontainer/devcontainer.json
{
 "name": "Enterprise Dev Environment",
 "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
 "features": {
 "ghcr.io/devcontainers/features/node:1": { "version": "20" }
 },
 "postCreateCommand": "npm install -g @anthropic-ai/claude-code",
 "containerEnv": {
 "CLAUDE_CODE_USE_BEDROCK": "1",
 "ANTHROPIC_BEDROCK_BASE_URL": "https://llm-gateway.internal.corp.com/bedrock",
 "CLAUDE_CODE_SKIP_BEDROCK_AUTH": "1",
 "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
 },
 "mounts": [
 "source=/Library/Application Support/ClaudeCode,target=/etc/claude-code,type=bind,readonly"
 ]
}

Developer opens repo → devcontainer starts → Claude Code just works.

The AI Disruption Speed Problem

Mon, 01 Jan 0001 00:00:00 +0000

The AI Disruption Speed Problem#

Comparing Dario Amodei’s macro predictions with what practitioners are seeing on the ground – and where both perspectives agree that the speed of AI disruption is the real concern.

This piece draws on Amodei’s Feb. 2026 interview with Ross Douthat and the observations in The “AI Will Replace Programmers” Narrative.

Where the CEO and the Practitioner Agree#

Software is getting hit first. Amodei says software might be disrupted faster than other white-collar work because developers adopt quickly and are “socially adjacent to the AI world.” The practitioner perspective confirms this: code production is already not the constraint. The disruption is already here for devs.

Google Vertex AI Fundamentals

Mon, 01 Jan 0001 00:00:00 +0000

Google Vertex AI Fundamentals#

What Is Vertex AI?#

Vertex AI is Google Cloud’s managed AI platform. Anthropic’s Claude models are available as partner models through Vertex AI, giving you a GCP-native API that uses the same IAM, billing, networking, and compliance infrastructure you already use for everything else in Google Cloud.

Analogy for Cloud Foundry practitioners: Same abstraction as Bedrock – developers call an API, the platform team controls networking, access, cost, and compliance underneath. The difference is which cloud’s control plane you’re working with.

Market Opportunity Analysis

Mon, 01 Jan 0001 00:00:00 +0000

Market Opportunity Analysis#

The Gap in the Implementation Landscape#

Layer 1: AWS (Infrastructure Plumbing)#

AWS Solutions Architects (free with account): VPC endpoint setup, Direct Connect, IAM policy design
AWS Professional Services (paid): Hands-on implementation. Reference architecture “Guidance for Claude Code with Amazon Bedrock” deployable in hours
AWS Partner Network consultancies (Accenture, Deloitte, Slalom): Routine networking/security work
Gap: Excellent at infrastructure plumbing. No depth on Claude Code configuration, skills architecture, or developer experience.

Layer 2: Anthropic (Product Expertise)#

Claude for Enterprise plan: SSO, domain capture, RBAC, Compliance API, managed policy settings for org-wide Claude Code configs
Enterprise sales team: Contractual/compliance side – DPAs, security questionnaires, Compliance API
Gap: Model company, not consulting firm. Won’t Terraform your VPC or deploy your LLM gateway.

Layer 3: Strategic System Integrators (Enterprise Relationships)#

Accenture: Accenture Anthropic Business Group, ~30,000 trained professionals, full-stack transformation
Cognizant: Deploying Claude to 350,000 employees, engineering platform integration, industry blueprints
IBM: Claude integration into software portfolio, contributing enterprise reference architectures and open-source MCP tooling
deepsense.ai: Official Anthropic Service Partner, “Jumpstart Packages” for regulated sectors
Gap: Sweet spot is $2M+ full-stack transformation. Many “trained professionals” completed certification, not production deployment.

Layer 4: LLM Gateway Products#

LiteLLM: Enterprise cloud with SOC 2/ISO 27001 – or self-hosted open-source
Kong AI Gateway: Enterprise support contracts, existing Kong customers
Portkey: Managed gateway with observability focus
Gap: Products, not consultancies. Enterprises self-host with platform engineering team or hire separately.

The Unserved Middle Layer#

Nobody is doing the middle layer well – the consultant who understands:

Platform Engineer Path

Mon, 01 Jan 0001 00:00:00 +0000

Platform Engineer Path#

A structured progression for platform engineers deploying Claude Code to teams and organizations. Each module covers one layer of the deployment stack – work through them in order.

Module	Focus	Prerequisites
1. Architecture	Request flow, control points, configuration hierarchy	None
2. Infrastructure	Bedrock/provider setup, VPC endpoints, LLM gateway	Module 1
3. Configuration and Policy	Managed settings, CLAUDE.md hierarchy, distribution	Module 2
4. Permissions and Security	Permission rules, sandboxing, compliance controls	Module 3
5. Cost Management	Budgets, model tiering, observability dashboards	Modules 2-4
6. Phased Rollout	Cohort strategy, success metrics, rollback triggers	Modules 1-5

Exercise Materials#

Clone the exercise repo for hands-on practice alongside each module:

Common Customer Requests -- Pushback Recommendations

Mon, 01 Jan 0001 00:00:00 +0000

Common Customer Requests – Pushback Recommendations#

Things the customer will probably ask for that should be redirected.

“Can we run Claude locally on-prem?”#

Answer: No. Anthropic doesn’t offer self-hosted model deployment. The Bedrock/Vertex path with PrivateLink is the closest you get – data stays within the cloud provider’s private backbone and never touches the public internet.

If they truly need on-prem inference: The conversation shifts to open-source models (Code Llama, DeepSeek-Coder, StarCoder) via Ollama or vLLM. Quality drops significantly for agentic coding tasks. This is a fundamentally different engagement.

User Research & Validation with Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

User Research & Validation with Claude Code#

Executive Summary#

Engineers skip user research because it feels like a separate discipline – interviews, surveys, affinity diagrams, personas. Most of that overhead is mechanical: reading, categorizing, synthesizing. Claude Code handles the mechanical parts, which means you can do useful research in 20 minutes from your terminal. This article shows you how.

Research Method	What It Tells You	Claude Code Technique
Support ticket analysis	Where users get stuck right now	Feed ticket exports, extract patterns and frequency
Interview transcript synthesis	What users say they need (and what they reveal accidentally)	Load transcripts, pull out themes and contradictions
Competitive analysis	What alternatives exist and where they fall short	Describe competitor features, identify gaps
Usage data interpretation	What users actually do (vs. what they say)	Feed metrics, generate hypotheses for observed behavior
Survey design and analysis	Targeted answers to specific questions	Generate questions from assumptions, analyze response data
Feasibility prototyping	Whether a solution is technically viable	Build proof-of-concept scripts to test core mechanics

Table of Contents#

Why Engineers Skip Research
Support Ticket and Bug Report Analysis
Synthesizing Interview Transcripts
Competitive Analysis
Usage Data Interpretation
Validation Before Commitment
When to Stop Researching

Why Engineers Skip Research#

Research feels slow because it’s unstructured. Writing code has a tight feedback loop – write, run, see results. Research has no compiler. You read a stack of support tickets and come away with vague impressions. You interview three users and get three different stories. There’s no green bar that tells you you’re done.

Workflow Patterns: Common Development Workflows with Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Workflow Patterns: Common Development Workflows with Claude Code#

Executive Summary#

Claude Code is an agentic coding tool – it explores, plans, and implements rather than just answering questions. Getting the most out of it means structuring your work around its strengths: verification-driven development, iterative feedback loops, context management, and knowing when to delegate to subagents. This article covers the core workflow patterns for day-to-day development.

Workflow	When to Use	Key Pattern
Explore-Plan-Implement	New features, unfamiliar code	Separate research from coding
Fix with Verification	Bug fixes, error resolution	Reproduce, fix, verify
Test-Driven Development	New features, bug fixes	Write tests first, then implement
Code Review	Before merge, after implementation	Fresh session, different perspective
Refactor	Code improvement, migration	Small steps with continuous verification
Multi-Session	Large features, multi-day work	State files, named sessions, checkpoints
Parallel Sessions	Independent tasks, writer/reviewer split	`--worktree`, `--tmux`, headless mode
Headless / CI Integration	Automated checks, batch operations	`claude -p` with structured output

Table of Contents#

Workflow Patterns: Common Development Workflows with Claude Code

The Core Loop#

Every Claude Code workflow follows the same fundamental loop:

Azure Foundry Fundamentals

Mon, 01 Jan 0001 00:00:00 +0000

Azure Foundry Fundamentals#

What Is Azure AI Foundry?#

Azure AI Foundry (also called Microsoft Foundry) is Microsoft’s managed AI platform. Anthropic’s Claude models are available as partner models through Foundry, giving you an Azure-native API that uses the same Entra ID, billing, networking, and compliance infrastructure you already use for everything else in Azure.

CLAUDE.md Architecture -- Four-Layer Context Hierarchy

Mon, 01 Jan 0001 00:00:00 +0000

CLAUDE.md Architecture – Four-Layer Context Hierarchy#

The Core Design Problem#

Claude Code has a context window of ~200K tokens. Every CLAUDE.md file, every rule, every skill description, every file Claude reads, every conversation turn competes for space. The context window is the scarce resource, and the platform engineer’s job is to manage it like memory in a constrained system.

Unlike human developers who can skim past irrelevant instructions, Claude treats everything in its context with roughly equal attention. Irrelevant instructions don’t just waste tokens – they actively dilute the signal.

Anthropic's Chief on A.I.: 'We Don't Know if the Models Are Conscious'

Mon, 01 Jan 0001 00:00:00 +0000

Anthropic’s Chief on A.I.: ‘We Don’t Know if the Models Are Conscious’#

Dario Amodei shares his utopian – and dystopian – predictions in the near term for artificial intelligence.

Date: Feb. 12, 2026 Source: New York Times, “Interesting Times” podcast Host: Ross Douthat Guest: Dario Amodei, CEO of Anthropic

The Optimistic Vision#

AI for Biology and Medicine#

Douthat: If everything goes amazingly in the next five or 10 years, what’s A.I. for?

Debugging Techniques: Systematic Troubleshooting with Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Debugging Techniques: Systematic Troubleshooting with Claude Code#

Executive Summary#

Debugging with Claude Code works best when treated as a systematic investigation, not a guessing game. The core principle: understand the root cause before attempting a fix. Claude performs dramatically better at debugging when given the actual error, a way to reproduce it, and a way to verify the fix. Ad-hoc “try this, try that” approaches waste context and produce fragile patches.

Custom Hooks Cookbook: Practical Recipes for Automating Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Custom Hooks Cookbook: Practical Recipes for Automating Claude Code#

Executive Summary#

Hooks let you run code at specific points in Claude Code’s lifecycle – before a tool runs, after a file is edited, when a session starts, when Claude finishes responding. This cookbook provides copy-paste-ready recipes for the most common use cases: auto-formatting, command safety, test gates, notifications, logging, and context injection. Each recipe includes the hook configuration, the script, and notes on gotchas.

Product Manager Path

Mon, 01 Jan 0001 00:00:00 +0000

Product Manager Path#

Technical literacy for product managers using Claude Code. This path starts with what PMs can do directly – research synthesis, prioritization modeling, requirements writing – then builds the technical context needed to collaborate effectively with development teams.

Module	Focus	Prerequisites
1. How Claude Code Works	What it is, what PMs can do with it	None
2. Product Research & Discovery	Research synthesis, validation, prototyping	Module 1
3. Requirements & Prioritization	Specs, decomposition, trade-off modeling	Module 2
4. Technical Literacy	Design, architecture, standards, TDD essentials	Module 2
5. Working with Development Teams	Tickets, reviews, session planning	Modules 1-4

Modules 3 and 4 can be taken in either order. Both depend on Module 2, and Module 5 depends on all four.

Prompt Caching: Why Your System Prompt Doesn't Cost What You Think

Mon, 01 Jan 0001 00:00:00 +0000

Prompt Caching: Why Your System Prompt Doesn’t Cost What You Think#

Executive Summary#

Prompt caching allows the API to reuse previously processed prompt prefixes, reducing both cost and latency. Since Claude Code re-sends the system prompt on every API call, caching is what makes large system prompts economically viable. Without caching, a 200-message session with a 15,000-token system prompt would cost ~$15 on Opus 4.6. With caching, it costs ~$1.60 – an 89% reduction.

Reference Configurations

Mon, 01 Jan 0001 00:00:00 +0000

Reference Configurations#

managed-settings.json (Enterprise Baseline)#

Deploy to all developer machines via Mobile Device Management (MDM).

{
 "env": {
 "CLAUDE_CODE_USE_BEDROCK": "1",
 "ANTHROPIC_BEDROCK_BASE_URL": "https://llm-gateway.internal.corp.com/bedrock",
 "CLAUDE_CODE_SKIP_BEDROCK_AUTH": "1",
 "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
 },
 "cleanupPeriodDays": 14,
 "permissions": {
 "disableBypassPermissionsMode": "disable",
 "deny": [
 "Read(**/.env)",
 "Read(**/.env.*)",
 "Read(**/secrets/**)",
 "Read(**/.ssh/**)",
 "Read(**/credentials*)",
 "Bash(sudo:*)",
 "Bash(su:*)",
 "Bash(curl:*)",
 "Bash(wget:*)",
 "Bash(ssh:*)",
 "Bash(rm -rf:*)"
 ]
 },
 "allowManagedPermissionRulesOnly": false,
 "allowManagedHooksOnly": false,
 "strictKnownMarketplaces": []
}

File Locations#

Platform	Path
macOS	`/Library/Application Support/ClaudeCode/managed-settings.json`
Linux	`/etc/claude-code/managed-settings.json`
Windows	`C:\Program Files\ClaudeCode\managed-settings.json`

Developer Shell Environment Variables#

# /etc/profile.d/claude-code.sh

# Bedrock routing (also set in managed-settings.json env)
export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_BEDROCK_BASE_URL='https://llm-gateway.internal.corp.com/bedrock'
export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

# Corporate CA cert for proxy (if applicable)
export NODE_EXTRA_CA_CERTS='/etc/ssl/certs/corp-ca-bundle.pem'

# Optional: Model overrides
# export ANTHROPIC_MODEL='claude-sonnet-4-5-20250929'
# export ANTHROPIC_DEFAULT_HAIKU_MODEL='us.anthropic.claude-haiku-4-5-20251001-v1:0'

Terraform: VPC Endpoint for Bedrock#

resource "aws_vpc_endpoint" "bedrock_runtime" {
 vpc_id = aws_vpc.main.id
 service_name = "com.amazonaws.${var.region}.bedrock-runtime"
 vpc_endpoint_type = "Interface"
 private_dns_enabled = true

 subnet_ids = var.private_subnet_ids
 security_group_ids = [aws_security_group.bedrock_endpoint.id]

 policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
 {
 Effect = "Allow"
 Principal = "*"
 Action = [
 "bedrock:InvokeModel",
 "bedrock:InvokeModelWithResponseStream"
 ]
 Resource = "*"
 }
 ]
 })
}

resource "aws_security_group" "bedrock_endpoint" {
 name_prefix = "bedrock-endpoint-"
 vpc_id = aws_vpc.main.id

 ingress {
 from_port = 443
 to_port = 443
 protocol = "tcp"
 cidr_blocks = var.developer_subnet_cidrs
 description = "Allow HTTPS from developer subnets"
 }

 egress {
 from_port = 0
 to_port = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
 }
}

IAM Policy for Bedrock Access#

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "bedrock:InvokeModel",
 "bedrock:InvokeModelWithResponseStream",
 "bedrock:ListInferenceProfiles"
 ],
 "Resource": "*"
 }
 ]
}

Attach to the IAM role used by the LLM gateway service, not to individual developer users.

Requirements & Specifications: From Problem to Prompt

Mon, 01 Jan 0001 00:00:00 +0000

Requirements & Specifications: From Problem to Prompt#

Executive Summary#

You’ve done the research. You know what users struggle with. Now you need to turn that understanding into something precise enough that you – or Claude Code – can build it. This article covers requirement formats, feature decomposition, edge case discovery, and the handoff to spec-driven development. The goal: close the gap between “I understand the problem” and “I can write a build prompt.”

Security Controls

Mon, 01 Jan 0001 00:00:00 +0000

Security Controls#

Claude Code Permission Model#

Claude Code requires explicit developer approval for:

Writing or modifying files
Executing shell commands
Making network requests (beyond the LLM API)

This is the first line of defense. Developers see what Claude wants to do before it happens.

Non-Negotiable Controls#

Bypass Mode Disabled#

disableBypassPermissionsMode: "disable" in managed-settings.json prevents --dangerously-skip-permissions. This flag removes all permission prompts and lets Claude execute freely – never use in production or enterprise environments, regardless of developer convenience arguments.

How Coding Assistants Manage Context

Mon, 01 Jan 0001 00:00:00 +0000

How Coding Assistants Manage Context#

Raw API usage gives you a context window and a model. Everything else – deciding what to put in that window, when to remove it, and how to structure requests – is your problem. Coding assistants like Claude Code and GitHub Copilot take on parts of that work automatically.

This page covers what they actually do, where the approaches differ, and where both fall short.

Integration Patterns: Connecting Claude Code with External Tools and Services

Mon, 01 Jan 0001 00:00:00 +0000

Integration Patterns: Connecting Claude Code with External Tools and Services#

Executive Summary#

Claude Code connects to external systems through four integration mechanisms: MCP servers for tool access, hooks for workflow automation, headless mode for CLI scripting, and GitHub Actions for CI/CD. Each serves a different purpose and operates at a different layer. This article covers when to use each, how they work, and practical patterns for combining them.

Mechanism	Purpose	Direction	Runs When
MCP servers	Connect external tools/data	Claude calls out	Claude decides to use it
Hooks	Automate around Claude’s work	System calls scripts	Lifecycle events fire
Headless mode	Script Claude from outside	External calls in	Your script invokes it
GitHub Actions	CI/CD automation	Events call Claude	GitHub events trigger it

Table of Contents#

Integration Patterns: Connecting Claude Code with External Tools and Services

The Integration Landscape#

Claude Code integrates with external systems through four distinct mechanisms. Each operates at a different layer and serves a different purpose:

Prototyping & Iteration: Build to Learn

Mon, 01 Jan 0001 00:00:00 +0000

Prototyping & Iteration: Build to Learn#

Executive Summary#

A prototype is a question in code form. You build it to answer a specific question – “can this API handle the load?”, “does this workflow make sense to users?”, “will these two systems integrate?” – and then discard it. This article covers the types of prototypes, when to use each, the Claude Code workflow for running them, and the discipline of deciding what comes after.

Skills vs. Slash Commands vs. Rules -- Decision Framework

Mon, 01 Jan 0001 00:00:00 +0000

Skills vs. Slash Commands vs. Rules – Decision Framework#

When to Use Rules (.claude/rules/*.md)#

Use rules when the instruction is:

Declarative – “when working on X files, follow Y conventions”
Automatic – should apply without the developer invoking anything
About patterns and constraints, not step-by-step procedures
Path-scopable – different rules for different parts of the codebase

Examples:

API endpoint conventions that apply whenever editing API files
Testing requirements that activate when editing test files
Security constraints that apply globally
Framework-specific patterns (React, Go, etc.)

When to Use Skills (.claude/skills/)#

Use skills when the instruction is:

Structured AI Development Without the Framework

Mon, 01 Jan 0001 00:00:00 +0000

Structured AI Development Without the Framework#

Vibe coding – describing what you want and letting AI build it – works until it doesn’t.

The first few hundred lines come fast. The AI scaffolds routes, components, database schemas. You iterate by describing changes in conversation. A working prototype appears in minutes.

Then you hit a wall. Somewhere between 500 and 2,000 lines of generated code, the AI starts contradicting its earlier decisions. It rewrites a function it wrote 20 minutes ago. It adds a dependency it already added under a different name. The context window fills up and the AI loses track of what it built.

Testing Strategies: TDD Patterns and Test Automation with Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Testing Strategies: TDD Patterns and Test Automation with Claude Code#

Executive Summary#

Testing is the highest-leverage tool for getting good results from Claude Code. Tests give Claude a concrete feedback loop – write code, run tests, see failures, fix. Without tests, Claude produces code that looks right but may not work. With tests, Claude iterates until the output actually passes. This article covers how to structure test-driven development with Claude Code, avoid common testing pitfalls, and automate testing workflows.

Optimizing Token Usage: Skills, Plugins, and Context Budget

Mon, 01 Jan 0001 00:00:00 +0000

Optimizing Token Usage: Skills, Plugins, and Context Budget#

Executive Summary#

Every Claude Code session carries a baseline token cost from skills, plugins, and system configuration loaded into the context window. This cost is per-message – paid on every API round-trip regardless of whether the features are used. Understanding and managing this overhead directly impacts session cost, available context for actual work, and response latency.

Component	When Loaded	Token Cost Pattern
Skill catalog (names + descriptions)	Every message	~25-100 tokens per skill
Skill content (full SKILL.md)	On invocation only	Varies (can be significant)
Plugin subagents (descriptions in Task tool)	Every message	~50-150 tokens per subagent
CLAUDE.md files	Every message	Entire file contents
MCP tool definitions	Every message	~30-80 tokens per tool

A typical setup with 20+ plugins can consume 4,000-5,000+ tokens per message just for the skill/subagent catalog – before any actual work happens.

VPC Endpoint and PrivateLink Architecture

Mon, 01 Jan 0001 00:00:00 +0000

VPC Endpoint and PrivateLink Architecture#

Purpose#

Create a private connection between the corporate VPC and Amazon Bedrock. No internet gateway, no NAT, no public IPs needed. All traffic between the enterprise network and Bedrock stays within AWS’s private backbone.

Key Terraform Resources#

# VPC Endpoint for Bedrock Runtime
resource "aws_vpc_endpoint" "bedrock_runtime" {
 vpc_id = aws_vpc.main.id
 service_name = "com.amazonaws.${var.region}.bedrock-runtime"
 vpc_endpoint_type = "Interface"
 private_dns_enabled = true

 subnet_ids = var.private_subnet_ids
 security_group_ids = [aws_security_group.bedrock_endpoint.id]

 policy = jsonencode({
 Version = "2012-10-17"
 Statement = [
 {
 Effect = "Allow"
 Principal = "*"
 Action = [
 "bedrock:InvokeModel",
 "bedrock:InvokeModelWithResponseStream"
 ]
 Resource = "*"
 }
 ]
 })
}

# Security group: only allow traffic from developer subnets
resource "aws_security_group" "bedrock_endpoint" {
 name_prefix = "bedrock-endpoint-"
 vpc_id = aws_vpc.main.id

 ingress {
 from_port = 443
 to_port = 443
 protocol = "tcp"
 cidr_blocks = var.developer_subnet_cidrs
 }
}

Design Decisions#

Private DNS Enabled#

With private_dns_enabled = true, Claude Code’s standard Bedrock URLs resolve internally to the VPC endpoint’s private IP addresses. No application-level configuration changes needed beyond enabling Bedrock mode.

Agent Teams: Multi-Agent Orchestration in Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Agent Teams: Multi-Agent Orchestration in Claude Code#

Executive Summary#

Agent teams let multiple Claude Code instances work together on complex tasks. One session acts as team lead, coordinating work and assigning tasks. Teammates work independently in their own context windows, communicate through direct messaging, and share a task list. This is an experimental feature (disabled by default) that’s most valuable for tasks that benefit from parallel work, competing perspectives, or specialized roles.

Extended Thinking: How Claude Reasons Through Complex Problems

Mon, 01 Jan 0001 00:00:00 +0000

Extended Thinking: How Claude Reasons Through Complex Problems#

Executive Summary#

Extended thinking gives Claude additional tokens to reason before responding. On Opus 4.6 and Sonnet 4.6, thinking is adaptive: Claude decides how much to think based on task complexity. Thinking tokens are billed as output tokens ($25/MTok on Opus 4.6), making thinking depth the second-biggest cost lever after model selection. On Opus 4.6, effort levels (low/medium/high/max) control how much Claude thinks; Sonnet 4.6 supports low/medium/high effort.

LLM Gateway Design

Mon, 01 Jan 0001 00:00:00 +0000

LLM Gateway Design#

Why a Gateway?#

The LLM gateway is the piece most enterprises skip and regret. Without it, you have 500 developer machines each holding AWS credentials and making direct Bedrock calls with no centralized visibility or control.

Deploy LiteLLM (open-source or enterprise cloud) or Kong AI Gateway as an internal service between developers and Bedrock.

What the Gateway Provides#

Per-User/Per-Team Token Budgets and Rate Limiting#

Set monthly token budgets per team or per user
Default to Sonnet for routine work, gate Opus access to specific use cases
Prevent a single developer from burning through the entire org’s budget

Centralized Authentication#

The gateway holds AWS credentials for Bedrock – developers don’t need AWS access
Developers authenticate to the gateway via corporate SSO
Eliminates 500 sets of AWS credentials on developer machines

Request/Response Logging for Audit#

Log request metadata: who, when, which model, token count, latency
Don’t log prompt content if Zero Data Retention (ZDR) is active
Feed metrics to CloudWatch or your observability stack

Provider Abstraction#

Swap models or providers without touching developer configs
Route to different models based on request characteristics
A/B test model versions transparently

Developer-Facing Configuration#

Once the gateway is deployed, the developer config becomes three environment variables:

Model Selection & Cost Management: Choosing the Right Model and Controlling Spend

Mon, 01 Jan 0001 00:00:00 +0000

Model Selection & Cost Management: Choosing the Right Model and Controlling Spend#

Executive Summary#

Claude Code offers three model tiers – Opus, Sonnet, and Haiku – each with different capability, speed, and cost profiles. The right model depends on the task: Opus for complex reasoning, Sonnet for daily coding, Haiku for fast simple tasks. Beyond model choice, Claude Code provides several cost control mechanisms: prompt caching, auto-compaction, budget caps, effort levels, and subagent model selection. This article covers how to choose models, configure them, and manage costs effectively.

Feature Prioritization & Trade-offs

Mon, 01 Jan 0001 00:00:00 +0000

Feature Prioritization & Trade-offs#

Executive Summary#

Every team has more ideas than capacity. The hard part of product work is deciding what to build next and – equally important – what to defer. This article covers prioritization frameworks you can apply to a backlog, the concept of opportunity cost in engineering decisions, the discipline of saying no, and how Claude Code can model trade-offs quantitatively.

Framework	Best For	Inputs Needed	Output
Impact vs. effort	Comparing features against each other	Estimated impact (users, revenue, retention), estimated effort (days, complexity)	2x2 matrix ranking features by ROI
RICE scoring	Large backlogs with mixed feature types	Reach, impact, confidence, effort	Numeric score for stack-ranking
Opportunity cost	Binary build-or-defer decisions	What else the team could build with the same time	Explicit comparison of alternatives
Cost of delay	Time-sensitive features	Revenue or retention impact per week of delay	Urgency-adjusted priority

Table of Contents#

The Prioritization Problem
Impact vs. Effort
RICE Scoring
Opportunity Cost
Cost of Delay
Saying No
Modeling Trade-offs with Claude Code
Worked Example: The Dashboard Backlog
Anti-Patterns

The Prioritization Problem#

A team has twelve features in the backlog, capacity for three this quarter, and stakeholders who each believe their feature is the most important. Without a framework, the loudest voice wins – or the team compromises by starting five features and finishing none.

Skills Library Design -- Three-Tier Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Skills Library Design – Three-Tier Architecture#

Overview#

Skills are structured workflows Claude can invoke as complete procedures. Each skill needs a SKILL.md file with YAML frontmatter (name, description) and markdown instructions. The name becomes the /slash-command, and the description helps Claude decide when to load it automatically.

Tier 1: Organization Skills (Global, All Developers)#

Distributed via plugin marketplace (internal) or symlink from a shared repo. Installed to ~/.claude/skills/ on each developer machine.

Context Budget Worksheet

Mon, 01 Jan 0001 00:00:00 +0000

Context Budget Worksheet#

Purpose#

Before building any CLAUDE.md or skills, do this exercise for each major codebase. It forces discipline about what goes where and prevents context overload.

The Budget#

Claude Code’s context window is approximately 200K tokens. Everything competes for this space: system prompt, CLAUDE.md files, rules, skill descriptions, code files Claude reads, conversation history, and Claude’s own reasoning.

Fixed Costs (Always Loaded)#

These load into every session regardless of what the developer is doing.

Memory Organization: Structuring CLAUDE.md and Rules for Scale

Mon, 01 Jan 0001 00:00:00 +0000

Memory Organization: Structuring CLAUDE.md and Rules for Scale#

Executive Summary#

Claude Code’s memory system is a hierarchy of markdown files loaded into the system prompt. Every file you add costs context window space on every message, so organization affects both clarity and efficiency. The key is putting the right information at the right scope, keeping files concise, and using the rules directory for modularity when a single CLAUDE.md gets unwieldy.

Security Constraint Clarification

Mon, 01 Jan 0001 00:00:00 +0000

Security Constraint Clarification#

First Conversation with the CISO#

“No code leaves the network” has three interpretations that lead to completely different architectures. Get written alignment before doing anything else.

Level 1: “No code to Anthropic directly”#

What it means: Route through a cloud provider’s managed service (AWS Bedrock, Google Vertex AI). The enterprise’s contract is with AWS/GCP, not Anthropic directly. Data isn’t retained, isn’t used for training.

Architecture: Claude Code → Bedrock (standard) or Vertex AI (standard)

Tool Execution Context

Mon, 01 Jan 0001 00:00:00 +0000

Tool Execution Context#

When Claude runs a bash command or any other tool, the system prompt and skill instructions are not re-injected alongside the tool result. The result passes back to the model as bare output. This is sometimes called “pass-through” behavior.

The distinction matters when your workflows depend on behavioral rules defined in CLAUDE.md or a skill file – those rules are active when Claude is reasoning, but they are not re-delivered when Claude processes tool output.

Common Failure Modes

Mon, 01 Jan 0001 00:00:00 +0000

Common Failure Modes#

Patterns to watch for and coach against during the rollout.

1. The Encyclopedia CLAUDE.md#

Symptom: A team dumps their entire wiki into CLAUDE.md. 300+ lines of coding standards, architecture descriptions, and process documentation.

Effect: Claude’s responses get slower, less focused, and the context window fills up before any real work happens. Instructions toward the end of a long CLAUDE.md receive less attention than those at the beginning.

Essential Plugins: Extending Claude Code with MCP Servers and Skill Packs

Mon, 01 Jan 0001 00:00:00 +0000

Essential Plugins: Extending Claude Code with MCP Servers and Skill Packs#

Executive Summary#

Claude Code out of the box has no memory across sessions, no access to library documentation, and no ability to interact with browsers or external services. Plugins fill these gaps. The ecosystem splits into two categories: MCP servers that add new tools (memory databases, documentation APIs, browser control) and skill packs that add workflow knowledge and specialized subagents (code review, feature development, hook automation).

Permissions & Enterprise Deployment: Securing and Scaling Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

Permissions & Enterprise Deployment: Securing and Scaling Claude Code#

Executive Summary#

Claude Code’s permission system controls what actions Claude can take – from file reads to shell commands to network access. Permissions cascade across five settings scopes (managed, CLI, local, project, user), with deny rules always winning. Enterprise deployments add managed policy files, sandbox enforcement, provider flexibility (Bedrock, Vertex AI, Foundry), and organization-wide controls. This article covers the full permission lifecycle from individual developer configuration to team-wide lockdown.

What Developers See

Mon, 01 Jan 0001 00:00:00 +0000

What Developers See#

This is the page a team lead hands to developers on day one of rollout.

When a Deny Rule Fires#

Claude Code shows a notification explaining which policy blocked the action and why. The developer always sees what was blocked. For the full incident response workflow (rephrase, manual workaround, or policy exception), see Security Controls.

Checking Effective Permissions#

Run /permissions in any Claude Code session to see all active permission rules and their source (managed, project, user). Run /settings to see the full effective configuration with managed overrides marked.

Spec-Driven Development: Structured Planning for AI-Assisted Projects

Mon, 01 Jan 0001 00:00:00 +0000

Spec-Driven Development: Structured Planning for AI-Assisted Projects#

Executive Summary#

Spec-driven development (SDD) is the practice of creating structured specifications before writing code, then using those specs as context-engineered inputs for AI agents. Instead of describing what you want and hoping for good output, you decompose work into researched, planned, verified phases – each executed in a fresh context window where quality stays high. This article covers the core principles, the development cycle, practical patterns, and how tools like Superpowers, GSD, and GitHub Spec Kit implement them.

Large Codebase Strategies

Mon, 01 Jan 0001 00:00:00 +0000

Large Codebase Strategies#

Claude Code operates within a finite context window. On large codebases – monorepos, enterprise services, anything with hundreds or thousands of files – that window fills fast. When it does, Claude loses track of instructions, hallucinates file paths, and produces increasingly unreliable output.

This page covers practical strategies for staying within context budget and getting better results when the codebase is bigger than what Claude can hold in its head at once.

Real-World Example: Legacy Java Modernization

Mon, 01 Jan 0001 00:00:00 +0000

Real-World Example: Legacy Java Modernization#

Overview#

This example shows Agent Teams applied to a common enterprise problem: a legacy Java monolith with decade-old dependencies that no one wants to touch. The goal is to give a resistant team the confidence and tooling to act incrementally, rather than forcing a big-bang rewrite.

The scenario comes from a real consulting engagement: a 1M-line Spring/Hibernate codebase, risk-averse stakeholders, and a team that hasn’t had the bandwidth or mandate to address the underlying debt.