Building and Prototyping with Claude Code

In a new conversation hosted by Anthropic, I (Alex, lead of cloud relations) sat down with Kat (product manager for Cloud Code) to unpack how Claude Code evolves so quickly, how developers are using it in the wild, and where the Cloud Code SDK is taking agent development next. This article summarizes the key takeaways and adds context for developers, teams, and engineering leaders who want to prototype, customize, or scale agentic workflows with Claude Code.

👋 Fast introductions — who’s talking and why it matters

I'm Alex and I lead cloud relations at Anthropic. Kat runs product for Cloud Code. We wanted to give a clear, practical view into how new features move from idea to production and how teams of all sizes are integrating Claude Code into real engineering workflows.

Why does this matter? Because Cloud Code isn't just another tool — it's a platform that developers can prototype on rapidly, dogfood internally, and then share or ship. The speed and feedback loop here change the game for iterating on developer tooling.

⚙️ From idea to shipping — rapid prototyping and dogfooding

One of the things Kat emphasized is the speed at which the Cloud Code team ships features. Instead of long PRDs and design-doc debates, the team often prototypes directly in Cloud Code. Great ideas get built bottom-up by engineers who actually want the feature for their own workflows.

"Because it's so fast to use Cloud Code to prototype a feature, most of the time, people just prototype the feature and then ship it internally to ants. If the reception is really positive, that's a very strong signal that the external world will like it too."

That internal dogfooding — with Anthropic employees (the friendly "ants") — is intentional. Prototyping quickly lets the team discover which version of a feature fits diverse developer workflows. Rather than assuming a particular UX is best, they iterate on working code and observe real usage.

Two operational takeaways from that process:

• Prototype fast and ship internally first. Real usage often surfaces edge cases and UX mismatches far faster than documents can predict.
• Use real developer workflows as the acceptance criteria for shipping externally. If people inside the company adopt and rely on it, it's an excellent signal.

🧩 Common use cases — indie devs to enterprises

Cloud Code is built to be approachable out of the box. A simple npm install often gets you up and running with minimal configuration. That accessibility is the secret sauce: whether you're an indie dev or at a Fortune 500, Cloud Code integrates with your local tools and files, and developers already understand the terminal-first model.

That said, usage patterns differ between small teams and larger organizations:

• Smaller teams / indie devs: Tend to run Claude more autonomously. Auto-accept mode — where Claude can propose and apply edits without asking after every step — is popular. These developers also often run multiple Claude sessions concurrently (more on that below).
• Larger companies: Prefer more cautious workflows. Plan mode is valuable here: Claude takes time to analyze the codebase, produce an engineering plan, and outline the approach before making edits. For complex, cross-cutting changes this upfront planning matters.

☁️ The rise of "multi-Clauding" — multiple agent sessions at once

One usage pattern Kat described as surprising and widespread is "multi-Clauding" — running multiple Claude sessions in parallel. Engineers have taken to opening several Claude instances at once, each with a different role or context.

Example patterns include:

• One instance dedicated to asking questions and exploring design ideas without committing edits.
• Another instance that can edit files in a repo and apply code changes.
• Separate sessions for different Git worktrees or branches so edits don't interfere with each other.

This approach gives developers a sandbox for exploration and a separate, safe channel for applying changes. Kat noted that they initially thought this would be a power-user quirk, but it turned out to be common enough that the team shifted product thinking to support it better.

🛠️ Customizing Cloud Code — CLAUDE.md, slash commands, and hooks

Customization is core to Cloud Code’s value. Developers are tailoring the tool to their team's needs using several approaches:

CLAUDE.md as the single source of memory

CLAUDE.md acts as a compact, team-shared memory. It's where you tell Cloud Code about your architecture, goals, constraints, known gotchas, and best practices. Kat was clear about the ROI here: investing time in CLAUDE.md dramatically improves output quality.

Slash commands for repeated prompts

If your team repeatedly runs the same prompt, you can save it as a custom slash command. These can be checked into version control so the whole team shares a common cheat sheet of prompts — one less repetitive ritual for engineers.

Hooks to enforce determinism or side effects

Hooks are basically scripts that run on Cloud Code events. Because developers already know how to write scripts, hooks feel familiar and low-friction. Examples include:

• Run linting and tests before a commit.
• Send a Slack notification when a long-running agent finishes.
• Kick off a CI pipeline after a set of edits completes.

Kat pointed out that hooks were originally inspired by the desire to get notifications when work finished, but they’ve expanded into a general-purpose customization mechanism for determinism and integration.

📦 The Cloud Code SDK — a framework for building agents

If Cloud Code is the product experience, the Cloud Code SDK is the developer harness for building your own agents. Kat described the SDK as giving you the agent loop and the plumbing so you can focus on the unique behavior or domain logic.

Key features of the SDK include:

• Access to core agent building blocks (system prompts, tool integration, memory primitives).
• A prebuilt agentic loop that manages turns and executes tool calls.
• Built-in permission systems so teams don’t need to roll their own.
• Robustness features: API backoff handling, aggressive prompt caching for token efficiency, and other production-friendly behaviors.

Kat's claim: you can prototype a powerful agent in about thirty minutes if you use the SDK. That's a strong promise — and it reflects the SDK’s goal of removing boilerplate so teams can iterate on domain-specific logic quickly.

🚀 What people are building with the SDK

Teams have already built a wide range of agents on the SDK. Within the engineering domain you’ll see:

• SRE agents that can triage or suggest remediation steps.
• Security agents for static checks and vulnerability triage.
• Incident response agents to collect logs, summarize incidents, and propose follow-ups.
• GitHub integrations (Anthropic open-sourced their GitHub integration built on the SDK).

Outside engineering, folks are prototyping legal, compliance, and business ops agents. The SDK is intentionally general-purpose: you can swap out system prompts, tools, and memory implementations to match your domain.

💡 Best practices and tips from the front lines

Kat and I wrapped up by sharing concrete tips for getting the most out of Cloud Code and agent-driven workflows. Here are the practical rules of thumb you can apply today:

1. Communicate goals clearly: Treat Claude like a teammate. Be explicit about purpose, evaluation criteria, and constraints. Good prompting is less magic and more clear instruction.
2. Use CLAUDE.md: Invest in a well-maintained CLAUDE.md. It’s cheap to write and pays dividends by aligning the agent to team norms and architectural assumptions.
3. Debug by asking: If Claude does something unexpected, ask clarifying questions. It often reveals what the agent read or which memory entry influenced its decision. Use that feedback loop to improve context or update CLAUDE.md.
4. Leverage hooks and slash commands: Automate repetitive prompts and integrate deterministic checks (lint/test) via hooks so agent changes comply with team rules.
5. Choose modes to match risk: Use auto-accept for high trust or low-risk edits; use plan mode for complex changes that need thoughtful design and review.
6. Run parallel sessions intentionally: Multi-Clauding can increase productivity, but be explicit about the role of each session (e.g., one for exploration, one for edits).
7. Start with the SDK when building agents: It saves time by providing the agent loop, caching, backoff, and permission primitives. Focus on your domain logic instead of reinventing the harness.

One practical tip Kat likes: ask the agent "why did you do that?" when it makes a surprising edit. Often the agent will reference a file or a CLAUDE.md paragraph that led it there, and you can use that comment to update the memory or adjust the prompt.

🔚 Where this is headed and final thoughts

Cloud Code and the SDK are accelerating the next wave of agent-driven developer tools. The product vision is pragmatic: enable fast prototyping, strong dogfooding loops, and a customizable harness that teams can adapt. Whether you’re an individual developer who wants an autonomous coding assistant or a large org that needs well-governed agent workflows, the tooling is evolving to meet both ends.

If you want to get started, a few action steps:

• Install Cloud Code locally and try it in a safe repo.
• Create a CLAUDE.md that outlines your architecture and team rules.
• Experiment with one hook (e.g., run lint before commit) and one slash command (a saved prompt you often use).
• If you're building a custom agent, prototype on the Cloud Code SDK and iterate on your system prompts and tools.

In short: prototype early, dogfood internally, and use the SDK to skip the plumbing so you can explore what agents could do for your team. As Kat put it, quick prototyping and real usage are how we learn the shape of features that actually stick.

— Alex (Anthropic)