How Anthropic Teams Use Claude Code
Anthropic · pdf · 2025-06-03 Reader 🖥️
Agent Planning ArtifactsCitizen DeveloperAgent Context Files (CLAUDE.md / AGENTS.md)Knowledge BaseMulti-Agent OrchestrationNon-Engineers BuildingRisk Tiering
Across nine internal teams spanning both engineering (Security, Inference, RL Engineering, the Claude Code team itself) and non-engineering functions (Legal, Growth Marketing, Product Design, Finance via Data Infrastructure), Claude Code's value comes less from writing application code per se than from acting as a general-purpose interface to unfamiliar systems, documentation, and workflows -- letting people without coding backgrounds independently build and run working software, and letting engineers extend their reach into unfamiliar domains -- provided teams invest in persistent context files, checkpoint-heavy supervision, and an explicit sense of which tasks warrant autonomous versus closely-supervised execution.
practical · mixed — A curated internal case-study collection (expository per-team profiles plus narrative anecdotes) assembled in service of a practical argument: here is how to adopt Claude Code across technical and non-technical functions, with tips implicitly recommending specific practices to the reader's own organization.
Structure
| Part | Role |
|---|---|
| Nine per-team profiles (Data Infrastructure, the Claude Code team, Security Engineering, Inference, Data Science/ML Engineering, API Knowledge, Growth Marketing, Product Design, RL Engineering, Legal), each with 'Main use cases' and 'Team impact / Top tips' | Evidence -- each profile is a self-contained case study |
| Recurring patterns across profiles: CLAUDE.md investment, checkpoint/revert workflow, risk-based mode switching, sub-agent decomposition, documentation-as-byproduct | Implicit cross-team argument, assembled by the reader from repeated 'top tips' rather than stated as a single thesis |
Key terms
- auto-accept mode / 'slot machine' workflow
Letting Claude Code work fully autonomously for a bounded period (minutes to tens of minutes) after committing a clean checkpoint, then either accepting the complete result or discarding it and restarting, rather than attempting to correct a partially-wrong result in place. - task classification intuition
A developed sense, specific to one's own codebase and team, of which tasks are safe to hand to Claude Code autonomously (peripheral features, prototyping, work in unfamiliar languages) versus which require synchronous, closely-monitored collaboration (core business logic, critical fixes). - Claude.md / plan-then-build workflow
A project-level context file documenting workflows, conventions, constraints, and even the user's own skill level, combined with a two-phase pattern of extensive planning in a conversational interface (Claude.ai) before moving to implementation in Claude Code.
Propositions
- explicitAcross nine internal teams spanning technical and non-technical functions, Claude Code's primary reported value is not limited to writing application code -- it is used as a general-purpose interface for debugging infrastructure, synthesizing documentation, understanding unfamiliar systems, and automating workflows described in plain language rather than scripts.conf: high
- explicitTeams with no formal coding background -- Growth Marketing's team of one, Legal, Finance (via the Data Infrastructure team's help), and non-developer Product Design staff -- use Claude Code to independently build and run working software (ad-generation pipelines, G Suite automation tools, an accessibility app, data workflows described only in plain text) without engineering support or a budget request.conf: highsupportsLawyers are quietly becoming builders · p1 — The report's Legal, Growth Marketing, and Finance examples are concrete instances of the broader claim that 'building' in the AI era means turning a repeatable task into a corrected, reusable AI workflow rather than writing software.
- explicitTeams explicitly distinguish a fast, autonomous mode (checkpoint, let the agent run unsupervised for a bounded period, accept or discard the whole result) for peripheral, low-risk, or unfamiliar-domain work, from a slower, synchronous, closely-supervised mode for changes touching core business logic -- and describe developing 'task classification intuition' about which mode a given task calls for.conf: high
- explicitdevelopedTeams across the company converge on checkpoint-heavy, revert-friendly workflows -- commit before letting the agent work, then accept the result or discard it and restart rather than correcting it in place -- as the practical mechanism that makes autonomous agent work safe to run unsupervised.conf: highextends ←How Claude Code Is Built · p6 — Claude Code's own grant/grant-persistently/reject permission system is the tool-level mechanism underlying the checkpoint-heavy, revert-friendly workflow that other Anthropic teams report adopting at the practice level to make autonomous agent work safe without sandboxing.
- explicitWriting and maintaining project-level context files (Claude.md) that document workflows, tools, conventions, and even the user's own skill level (e.g. 'I'm a designer with little coding experience, give detailed explanations and smaller changes') measurably improves the quality and reliability of Claude Code's output, and multiple teams describe this as the single highest-leverage investment for ongoing use.conf: high
- explicitSeveral teams build a self-reinforcing feedback loop in which the agent itself is asked to update its own guiding documentation (end-of-session summaries, workflow-instruction refinements) after each task, so institutional knowledge accumulates automatically rather than depending on someone remembering to write it down.conf: highextendsLawyers are quietly becoming builders · p8 — The report's Claude.md-maintenance and end-of-session-summary patterns, observed across many Anthropic teams, are a cross-team instance of the 'reusable AI recipe' pattern -- feeding in preferences and correcting mistakes so the tool remembers -- that the lawyers piece names as the decisive, non-coding skill of AI-era knowledge work.
- explicitcorroboratedFor tasks with an external API (ad platforms, analytics, design tools), teams decompose a single complex workflow into multiple specialized sub-agents with narrow roles (a headline-writing agent and a separate description-writing agent, rather than one agent doing both) specifically because narrower scope makes debugging easier and improves output quality.conf: highsupportsThe Work Behind Delegation: A Framework for Supervising AI Coding Agents · p6 — Growth Marketing's explicit two-sub-agent design (a headline agent, a description agent) 'because this makes debugging easier' is a concrete instance of the paper's broader finding that developers distribute supervisory work by splitting it across agents with narrower, more reviewable scopes.supports ←How Claude Code Is Built · p12 — The subagents feature's own founding design (a simple orchestrator invoking narrowly-scoped agents, no inter-agent chat) is the underlying mechanism that other Anthropic teams are later reported applying when they decompose a complex workflow into specialized sub-agents.
- explicitcontestedA security-sensitive team restricts Claude Code's access mechanism (MCP servers with logging and access control) rather than giving it direct CLI access to sensitive data, even though the CLI route is functionally equivalent, specifically to preserve auditability and control over what the agent can reach.conf: highcontradicts ←Just Talk To It - the no-bs Way of Agentic Engineering · p6 — A security-sensitive team in the other document deliberately restricts Claude Code to MCP servers (for their logging and access control) rather than giving it direct CLI access to sensitive systems — the opposite preference from this post's 'almost all MCPs should just be CLIs' stance, precisely because that team values the governance properties this post never weighs against token cost.
- explicitMultiple teams report that Claude Code materially shortens the time needed to become productive in an unfamiliar codebase or technical domain -- new hires, engineers rotating teams, and domain experts crossing into adjacent technical territory (data scientists building full React dashboards, security engineers contributing to unfamiliar projects) all describe reaching meaningful contribution in days or hours rather than weeks.conf: high
- explicitMultiple non-technical teams (Legal, Growth Marketing) adopt a two-phase workflow -- extensive planning and brainstorming in a conversational AI interface (Claude.ai) first, producing a detailed step-by-step prompt, and only then moving to Claude Code for implementation -- deliberately separating planning from execution.conf: highsupportsThe Work Behind Delegation: A Framework for Supervising AI Coding Agents · p5 — Anthropic's own non-technical teams independently converge on the academic paper's core strategy of concentrating supervisory effort in planning: a separate, extensive planning phase (in Claude.ai) specifically intended to reduce how much correction and supervision implementation in Claude Code will later require.
- explicitProduct Design team members paste static mockup images directly into Claude Code and receive fully functional, immediately buildable prototypes, replacing the traditional cycle of static Figma designs that required extensive explanation and translation into working code by engineers.conf: highsupportsDesign at the Speed of AI · p4 — Both describe the same shift: pasting a mockup or description directly into an AI coding tool eliminates the traditional design-to-development handoff cycle that previously took a week of mockups and back-and-forth.
- implicitBecause Claude Code lets a non-engineer complete a working prototype without first convincing an engineer or budget-holder the idea has merit, internal prototyping shifts from being gated by resource-allocation approval to being gated mainly by the prototyper's own willingness to try and share something imperfect -- several teams name this willingness itself, not technical skill, as the remaining cultural barrier.conf: medium
- explicitThe Legal team's own product lawyers identify deep MCP integrations as a coming security and compliance tension specific to their domain: as AI tools gain access to more sensitive systems, conservative security postures will create adoption friction, and compliance tooling needs to be built proactively rather than reactively.conf: high
Arguments
Teams should route a task to one of two distinct supervision modes -- fast autonomous/checkpoint-and-accept, or slow synchronous/closely supervised -- based on the task's risk and centrality, rather than applying one default mode to everything.
Explicit premises:
- Peripheral, low-priority, or domain-unfamiliar work (Vim mode, visualization dashboards, routine refactors) succeeds well under autonomous, checkpoint-heavy supervision
- Core business-logic changes require real-time monitoring for code quality, style, and architecture compliance
- Discarding and restarting a bad autonomous attempt is cheaper than trying to correct it in place
Implicit premises:
- A task's appropriate supervision mode is knowable in advance from its position in the codebase or business (peripheral vs. core), not only discoverable after a failed attempt
- The cost of running the wrong mode -- over-supervising a safe task, or under-supervising a risky one -- is asymmetric enough to justify explicit, deliberate classification rather than a uniform default
Inferences:
- Organizations that don't develop this 'task classification intuition' explicitly will default either to over-supervising everything (losing the reported productivity gains) or under-supervising core-logic changes (risking production issues)
Narratives
- The Data Infrastructure team's Kubernetes diagnosis: when clusters stopped scheduling pods, the team fed screenshots of Google Cloud dashboards into Claude Code, which guided them menu by menu to a pod-IP-exhaustion warning and then supplied the exact commands to fix it -- resolving an incident that would normally require pulling in a networking specialist.
→ Shows concretely that Claude Code's value in this report extends well beyond writing application code into cross-domain infrastructure troubleshooting, grounding the broader claim that teams use it as a general interface to systems outside their own deep expertise. - A Legal team member built a predictive-text communication app for a family member with a speech disability in about an hour, using native speech-to-text and voice banks -- filling a gap in existing accessibility tools that speech therapists had recommended but that didn't fully meet the need -- then validated the prototype by showing it to UCSF specialists.
→ Demonstrates the furthest extreme of the report's 'non-engineer builder' pattern: a lawyer with no engineering background solving a genuinely novel, personally consequential problem, grounding the report's advice to share imperfect prototypes in a case where the stakes of trying were low but the payoff was high.
Questions addressed
- ✅ Can Claude Code provide real value to people and teams without software-engineering training, or is its benefit confined to professional developers?
Non-technical teams and individuals (Legal, Growth Marketing's team of one, Finance via Data Infrastructure's help, non-developer Product Design staff) independently build and run working software with it -- the report frames this as one of its central findings, not a side note. - ✅ How should a team decide when to let Claude Code work autonomously versus supervise it closely in real time?
Multiple teams converge on a risk/centrality heuristic: autonomous, checkpoint-and-accept-or-discard supervision for peripheral or low-stakes work; synchronous, detailed-prompt supervision for core business logic -- described across teams as 'task classification intuition.' - ⭕ Do the reported productivity and time-savings figures (e.g. 'research time reduced by 80%', '2-3x faster execution', 'ad copy from 2 hours to 15 minutes') reflect rigorous measurement, or self-reported impressions from the power users interviewed?
The report doesn't say -- it presents these as 'top tips' and impact statements from interviews with the company's own power users, with no stated methodology, baseline measurement, or comparison group. - ⭕ What happens to the teams and processes this report's successes route around -- networking specialists for Kubernetes issues, engineers supporting designers' changes, IT/dev gatekeeping for new internal tools?
Gaps
- incompleteThe report is Anthropic's own curated internal success-story collection, drawn from interviews with self-selected 'power users' of its own flagship product, with no stated methodology, sample size beyond the illustrative anecdotes, baseline, or failure cases -- every reported figure ('80% time reduction', '2-4x time savings', '70% of the implementation came from Claude') is a one-sided, unverified impact claim from the people most invested in the tool's success.
Read next: An independent, methodologically transparent study of the same claims (non-engineers building working internal tools with coding agents; task-risk-based supervision heuristics) across organizations other than the vendor itself. - incompleteSeveral teams describe routing around specialist teams entirely -- no networking team for the Kubernetes fix, no engineer for the designer's state-management changes, no IT for Legal's internal tools -- which the report frames purely as a productivity win, but never asks what happens to the bypassed teams' institutional knowledge, their own skill maintenance, or their future role once this kind of self-service becomes routine.
Read next: A follow-up examining second-order organizational effects: whether specialist teams (networking, platform/IT, dev support) see reduced demand, redefined scope, or an erosion of the tacit knowledge that made them the escalation point in the first place. - incompleteThe report documents several individual non-engineers (one lawyer, one marketer, one designer) succeeding with Claude Code, but doesn't examine what happens when ownership of a tool one person built (the Growth Marketing team's ad-generation pipeline, the Legal team's G Suite tracker) needs to be shared, maintained, or handed off across a team -- who else can read, debug, or extend a workflow that only its non-engineer author ever understood, especially once that person is unavailable.
Read next: A case study of a non-engineer-built internal tool's maintenance lifecycle after its original builder is no longer available to tend it, to test whether the 'citizen developer' pattern this report celebrates creates a new, less visible form of single-person dependency.
Closes gaps elsewhere
- Design at the Speed of AI · g1 — This report supplies what that gap says is missing: a concrete internal case study (Anthropic's own Product Design team) with a stated before/after workflow comparison -- pasting a mockup into Claude Code versus a week of static-Figma-to-engineer handoff, now compressed to hours -- rather than only assertion and visual demo. It remains a vendor-internal account rather than an independent study, but it is the kind of testimonial, named evidence g1 flags as absent.
Related documents
- Design at the Speed of AI
- Jacob Langvad Nilsson's Post
- Looking back at the Future of Software Engineering unconference
- Agent Harness Engineering
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- Harness design for long-running application development
- Presentation: A Few Predicted Talks From QConAI 2030
- Charlie Hills 🦩's Post
- Claude Code: Best practices for agentic coding
- A harness for every task: dynamic workflows in Claude Code