Claude Code for startups: 15 companies, 5 rules, and a roll-out checklist

Key takeaways

• Let the person who owns the problem build the 0→1. Marketers, legal, sales, and doctors can produce working prototypes; engineering, design, security, and compliance review and productize them.
• Automate mechanical tasks with checkable results first. PR review, bug triage, test fixes, coverage completion, incident triage, and batch data analysis all have clear inputs and verifiable outputs.
• Agent permissions should be gated by validation capability. CLAUDE.md stores rules, Loops handle repeatable execution, Hooks provide hard gates, and evals plus human escalation catch drift and block regressions.
• Keep the cost of rebuilding low. Worktrees isolate old and new versions, Plan Mode reviews the approach first, the same evals gate the merge, and the old path is deleted after migration.
• Productize only after internal validation. Teams run internal agents on real data, permissions, and workflows first; then decide what to expose to customers based on the failure record.

How 15 companies put Claude Code to work

The same tool landed in very different places across these 15 companies: some let lawyers and marketers build products directly, some handed testing, code review, and on-call to agents, some rebuilt their eval systems, and others used Claude Code to design their own AI products.

15 companies

5 RULES / 15 TEAMS

15 companies, five rules in action

Click a company to see details; click a rule to filter matching teams. All 15 companies are shown by default.

All 15 01 Everyone ships 02 Automate 03 Verify 04 Rebuild 05 Productize

Artemis Security02 · 03 Cainex03 Clay01 · 02 · 04 ClickHouse02 · 05 Cognition04 Commure02 · 04 Crosby01 · 02 Emergent01 · 02 · 05 Harvey04 Heidi01 · 02 Higgsfield03 Omni01 · 02 · 05 Parahelp01 Translucent01 · 02 Zingage03

02 · 05ClickHouse

30% more features shipped

Two test agents are the repo's 2nd and 3rd largest contributors; the team also uses Claude Code to iterate on the SQL console agent and AI SRE.

1. Artemis Security6,000+ PRs / week。Offload mechanical work to agents, while using test infrastructure, codebase organization, and team knowledge systems to support end-to-end delivery.
2. CainexMedical coding verification loop。Auditors check coding and reasoning, log corrections by error type; Claude Code revises general principles, then runs the golden set and random samples.
3. Clay100% automated bug triage。Quarterly reviews move non-technical employees' prototypes into the roadmap; the Bug Agent handles initial screening through code change suggestions, and repeatedly rebuilds the same feature.
4. ClickHouse30% more features shipped。Two test agents are the repo's 2nd and 3rd largest contributors; the team also uses Claude Code to iterate on the SQL console agent and AI SRE.
5. Cognition6–12 month system lifespan。Assume today's AI systems may be obsolete within half a year to a year, and design architecture ahead of future model capabilities.
6. Commure~13 tickets in parallel。Subagents own tickets and PRs; another Skill automatically scans and deletes feature flags and old code that have been fully released.
7. CrosbyThousands of legal docs summarized in parallel。Integrate Claude Code into tools lawyers already use, let lawyers prototype products directly, and use subagents to batch-process legal materials.
8. EmergentMarkdown completes first-day environment setup。New hires have Claude read a Markdown file to set up the environment; a shared Skills repo stores database, schema, and company context.
9. HarveyPlatform architecture redone for new model capabilities。Each wave of reasoning, automation, planning, and orchestration improvements triggers a platform redesign; discard old architecture when needed.
10. HeidiDomain experts PR directly + compliance review。Those who know the problem best submit the first PR; automated review then checks against established technical and compliance frameworks, flags critical issues, and routes them to specialized reviewers.
11. HiggsfieldModel integration: days → hours。New video and image models need Skills, evals, routing, and tests before production; Claude Code compresses this integration into the same working session.
12. Omni2–3× engineering productivity。Show prototypes to the whole team in Slack, let engineers join customer interviews; the product side borrows file-based context and parallel harnesses.
13. ParahelpNon-technical roles ship UI directly。While engineers accelerate, non-technical co-founders also start submitting UI changes and other product improvements directly.
14. TranslucentMulti-perspective code review + agent marketplace。Internal review agents check the same change in parallel and merge conclusions; engineering, delivery, and sales each use dedicated agents.
15. Zingage567 lines of team invariants。When Claude's code looks plausible but strays from the architecture, the team writes down the problem framework, invariants, and proof methods to constrain every session.

Rule One: hand the 0→1 to the people who know the problem best

“Everyone ships” opens the door to working prototypes and first-pass PRs. Marketers, legal, sales, and doctors can turn their domain knowledge into a runnable approach; designers, engineers, security, and compliance handle their own specialties.

Thomas Kelly, co-founder of Heidi, calls the old process a “game of telephone”: the person with the idea tells the product manager, who tells the designer, who passes it to the engineer. Weeks later, the delivered result can drift far from the original problem. With Claude Code, the problem owner creates the PR first, then brings in design and engineering for experience, architecture, and production readiness.

Making this a team-wide practice requires three parallel channels.

1. connect to the right sources of truth

If employees constantly copy database, CRM, document, or monitoring data into Claude, that is a sign the agent lacks a direct connection to the source of truth.

• MCP is for connecting Claude Code to tools, databases, and APIs, and gives teams a standard integration path.
• CLI works well where mature command-line tools already exist. The official PDF cites gh, kubectl, bq, and psql; these let Claude use the same real data engineers already work with, and sometimes cost fewer tokens than standing up a separate MCP connection.

Crosby connected Claude Code directly to the tools and OS lawyers already use, so they did not have to learn an engineering workbench. A simple signal for choosing an integration: do people copy and paste the same information into Claude every day?

Anthropic image. The MCP Connector Directory shows external tools Claude Code can connect to; the UI evolves with the product, but the MCP vs. CLI selection principles in the text still apply.

2. give prototypes a review entry point

Prototypes need a path into prioritization, resources, and the roadmap. Clay reviews employee prototypes quarterly; one marketing team member used this to build an agent that visits websites, fills out lead-gen forms, measures response time, and generates an experience report. Omni runs a dedicated Slack channel where anyone can show a Claude-generated prototype.

Omni also sends engineers directly to customer interviews. Prototypes surface internal issues; customer conversations supply external feedback; together they shorten the loop from idea to correction.

3. share team rules and workflows

As contributors grow, design systems, data locations, coding conventions, and review standards need to become shared assets.

• CLAUDE.md in subdirectories holds coding conventions that apply every time an agent works in that directory.
• Skills hold on-demand operational procedures, such as generating reports, running migrations, or checking compliance items.
• A shared directory or company plugin marketplace distributes Skills, so one employee’s validated approach can be reused by others.
• The official PDF also lists /init as a common entry point for generating the initial CLAUDE.md, capturing build commands, project layout, and conventions.

Emergent treats its Skills repository as a shared knowledge base, storing database locations, schemas, and company context. It allows context files to lag slightly, but requires agents to query facts and correct them. Translucent runs an internal agent marketplace organized by role — engineering, delivery, sales, and so on.

The acceptance criteria for this rule are concrete: problem owners can independently produce a reviewable prototype; prototypes have a regular showcase and prioritization path; team conventions come from shared files; production merges still go through expert review.

Rule Two: automate the mechanical work with clear inputs and checkable results

The source material describes this as “mechanical 80%” of what agents do. Tasks best suited for early automation share four traits: they recur, inputs are accessible, results are verifiable, and failures can be escalated to a human safely.

start with the software lifecycle

The surveyed companies plugged Claude Code into several points of the SDLC:

• Environment setup. New hires at Emergent point Claude at a Markdown file to initialize their dev environment; when a step fails, Claude updates the file.
• PR review. Claude Code’s Code Review was in research preview when the source PDF was published and can automatically review PRs in a given repo. Developers can fix findings manually or @Claude in a comment — with GitHub Actions configured — to hand it back to the agent.
• Compliance checks. Heidi checks changes against already-approved technical and compliance frameworks, flags serious issues first, then routes recommendations to the right reviewer.
• Multi-angle review. Translucent’s internal code-review agent examines a change from multiple angles and merges the findings into a report that resembles a senior engineer’s review.
• Bug triage. Clay’s agent goes from first-pass classification all the way to proposing code fixes.
• Testing and coverage. ClickHouse built two dedicated agents — one for flaky tests, one for missing coverage — and they became the #2 and #3 contributors to the repository.

Anthropic image. Code Review labels the severity of findings on a PR and lets developers hand them back to Claude; the feature was in research preview when the source PDF was published.

Commure notes that one engineer ran roughly 13 tickets in parallel, with a subagent assigned to each ticket and its PR. Parallel work requires clear ownership and acceptance criteria. When many tasks touch the same state frequently, merge conflicts and rework can erase the parallelism gains.

put agents in an always-on on-call flow

Anthropic’s own Claude Tag shows another pattern. It has its own service account, reads from CI and engineering tools like Datadog and Grafana, and its operating instructions live as Skills in a Git repo that the team maintains through code review.

Inside Anthropic, Claude Tag writes the first report for any incident with recent activity, typically publishing an initial analysis within 15 minutes.

Anthropic image. Claude Tag reads live monitoring tools and keeps a Slack incident thread updated; team members can correct course in the same thread.

extend beyond engineering into batch information work

Non-engineering use cases in the source material include: Clay’s internal analytics agent; Heidi categorizing feedback from customers and clinical staff; Crosby using subagents to summarize thousands of legal documents; Commure scanning claims data for cross-site anomalies; and Translucent continuously analyzing hospital financial data for risk signals.

Dynamic workflows let multiple subagents analyze large volumes of material in parallel, or one agent run an adversarial review of another’s output. Before batch execution, you should pin down the input scope, output format, merge rules, and failure escalation criteria.

Acceptance criteria for this rule: automation has a clear start, stop condition, and owner; results land in a visible review or monitoring system; anomalies are never silently swallowed; engineers can redirect their time to architecture, complex edge cases, compliance, and customer issues.

Rule Three: build the validation system before expanding agent permissions

An agent’s autonomy should be capped by its validation capability. Zingage gave Claude significant latitude and got code that looked reasonable but slowly drifted from the team’s architecture. The team responded by codifying the problem space, invariants, and proof approach into a 567-line document.

put non-negotiables in the root

The root CLAUDE.md is the right place for architectural rules, security boundaries, and other non-negotiable items, because Claude Code reads it at the start of every session. Local conventions go in subdirectory files, on-demand procedures go into Skills, and hard gates that must run every time belong in Hooks.

set up loops and stop conditions for long-running tasks

Loops let an agent repeat a task until a condition is met or a round limit is hit. Flaky-test fixing is a good fit: the failure signal is clear, and the agent can modify the code and rerun the same test. Tasks with vague stop conditions are not good candidates for long-running loops.

Anthropic image. A loop can keep running only if an Evaluator can check the goal and signal when it is not met.

In the PDF's 2026/8 product context, Dynamic workflows are for sequencing deterministic steps, isolating context, and focusing objectives; /goal is recommended for long tasks that tend to declare completion early, favor their own conclusions during self-review, or drift off target. Specific commands may change with Claude Code updates, so check the current official docs before use.

improve principles with human corrections

Cainex’s medical coding workflow demonstrates a full validation loop:

1. The agent processes a batch of medical records while auditors review the coding and reasoning inside an internal app.
2. Every correction is tagged by error type, such as diagnosis or procedure. All inputs, outputs, comments, and instruction versions remain auditable.
3. Claude Code identifies which part of the guidance caused the error, then revises the general principle. New error types trigger new guidance.
4. Candidate fixes are re-run against the failed records first, then tested against the golden set and random samples.
5. Because medical coding can have multiple valid answers, verification combines semantic matching with a judge to decide whether a difference is an error or simply another reasonable path.
6. Regressions are blocked. Records that cannot be resolved, along with pending questions, go to a human queue.

Cainex imposed a hard rule on this approach: fix principles, not examples. The first version encoded specific cases directly into the rules, and patches kept piling up. The team then limited how much concrete detail a single modification could add, forcing the system to generalize broader guidance.

Anthropic original. A proper agent evaluation preserves the task, the trial process, the final environment state, the judge, and the metrics being tracked.

Build layered verification

• Deterministic checks: linting, type checking, unit tests, static analysis, and security scanning.
• Hooks: run at fixed points in the Claude Code lifecycle and trigger every time. They can block writes that fail linting, require tests to pass before a commit, or strip secrets before data leaves the sandbox.
• Use-case evals: maintain multiple evaluation sets for every key use case, with regular additions of new failures, edge-case inputs, and regression samples from model upgrades.
• Golden sets and random samples: golden sets protect known-good behavior, while random samples catch changes the team did not anticipate writing tests for.
• Human escalation: domain experts handle high-risk, ambiguous, or multiply-solvable cases.
• Real-world result checks: after the agent claims a task is complete, verify that the database, files, service, or user state actually changed as expected.

The guiding rule for expanding permissions is simple: the agent runs where tests can cover the work; anything beyond that stays behind human approval.

Rule four: use worktrees, evals, and cleanup to lower rebuild costs

Model capabilities and agent architectures keep shifting, which means scaffolding built for an early capability gap can quickly become obsolete. Clay rebuilds the same feature repeatedly, using several rounds of implementation to deepen its understanding of the problem. Harvey noted that new reasoning, automation, planning, and orchestration capabilities sometimes forced a platform redesign, while Cognition expects AI systems completed today to be scrapped within six months to a year.

Cognition is talking about the lifespan of AI systems and architectures: something built today could be obsolete within six to twelve months as new capabilities arrive.

A safe rebuild process involves four steps:

1. Worktree isolation. v1 keeps running in the main working directory while v2 uses a separate directory and branch. Multiple linked worktrees share the same .git object store, so the full repository history does not need to be copied.

Anthropic original. Three worktrees use separate directories and branches while sharing repository history; this isolation lets the new version be tested without disrupting the current one.

2. Plan Mode first. For complex rewrites, use --plan or Shift+Tab so Claude explores the codebase and presents a proposal. The team reviews dependencies, migrations, permissions, and architecture boundaries before any code changes.
3. Same-basis evals. v1 and v2 run against the same tasks, data, judge, and cost metrics. v2 only gets merged after it wins on the key metrics.
4. Delete the old path. Remove feature flags, old code, and old migrations once fully rolled out. Keeping both paths alive for long increases the test surface, cognitive load, and risk of incidents.

Commure turned cleanup into a Skill: it scans for feature flags already released to all users, opens separate PRs for the relevant flags and code, and engineers review them. Migrations that used to consume a large chunk of the development cycle now finish in hours thanks to planning and parallel execution.

The acceptance criteria for this chapter: the old version stays available; the new version is fully isolated; both versions are measured on the same basis; there is a clear winning condition before merge; and the old path is removed once migration finishes.

Rule five: dogfood internal agents before productizing them

The teams interviewed repeatedly followed the same path: build an internal agent with Claude Code, use it in daily team work, then decide whether to turn it into a customer feature based on feedback. Internal usage doubles as both product research and fault diagnosis.

• Omni drew inspiration from Claude Code's file-based context, which reduced the need for a complex RAG pipeline. It also borrowed the Harness's parallel working style for its product interface.
• Emergent uses Claude Code to reproduce anomalous product behavior locally, helping the team separate model behavior from issues in its own harness.
• ClickHouse builds and iterates on a SQL console agent and an AI SRE with Claude Code; both agents serve customers directly.

The official checklist has no Chapter Five entries. The five steps below were synthesized from the case studies in this article:

1. Pick a problem that recurs internally, has easily observable outcomes, and start with an internal agent.
2. Let real users work with it using real permissions, data, and pace; record successes, failures, human takeovers, and stop reasons.
3. Classify failures into model, prompt and rules, harness, data, permissions, interface, and operational support.
4. Distill capabilities that hold across users and inputs, then add the isolation, audit, explanation, support, and compliance requirements needed for customer scenarios.
5. Only after a stable capability has been repeatedly validated should you decide to integrate Claude API, SDK, Managed Agents, or another production approach.

Internal tools can rely on team tacit knowledge; customer products need explicit contracts. Productization decisions should be based on real usage records and failure distributions, not a single demo.

Official checklist: eleven operational items across four chapters

Page 26 of the official PDF condenses the technical tips from the first four chapters onto a single page. The following is a translated and organized version:

Anthropic official PDF original page. The checklist covers eleven items across four chapters; the fifth rule has no dedicated checklist section. A complete Chinese organization follows.

Chapter 1 · Everyone ships

• Connect Claude to the team's everyday sources of truth and tools via MCP or CLI.
• Build a company plugin marketplace or shared directory to distribute best practices via Skills; a CLAUDE.md in subdirectories keeps persistent local coding conventions while Skills carry on-demand workflows.

Chapter 2 · Automate tedium

• Enable Code Review in the repo (then in research preview) to automatically review PRs.
• Connect Claude Tag (then in public beta) to CI/CD on-call response and bug triage.
• Use dynamic workflows to analyze large datasets in parallel, or to run adversarial reviews on another agent's work.

Chapter 3 · Trust, but verify

• Put non-negotiable architecture, security, and project rules in the root CLAUDE.md.
• Use Loops for long tasks with clear stopping conditions.
• Establish a process for creating, maintaining, and updating agent evals.
• Use Hooks as hard gates where deterministic execution is required.

Chapter 4 · Build for rebuilding

• Use git worktrees to isolate rebuilds and keep the current version unaffected.
• Start complex rewrites in Plan Mode and review the proposal before touching code.

Chapter Five does not appear in the official checklist. This should be treated as an editorial gap in the source material, not something to fill in as an "official twelfth item."

A two-week starter plan: build one verifiable loop first

Small teams can compress all five rules into a two-week experiment. The goal is to deliver one workflow that runs, gets accepted, and can be reviewed afterward, not to achieve a "lights-out company."

Week one: connect, set rules, prototype

1. Choose a task that repeats weekly, currently depends on copy-paste, and has a manageable failure cost.
2. Write down inputs, expected outputs, stopping conditions, the human owner, and prohibited actions.
3. Use CLI first if a mature one exists; evaluate MCP only when there is no unified integration.
4. Put security and architecture guardrails in the root directory, local rules in subdirectory CLAUDE.md, and operational steps in a Skill.
5. Build a prototype and schedule a review with the task's users, engineers, and risk owners.

Week two: verify, run, and review

1. Add linting, tests, or other deterministic checks; configure mandatory checks as Hooks.
2. Prepare a small set of validated samples, then add random samples and historical failures.
3. Run multiple batches and record success rates, human takeovers, cost, time, and error types.
4. Turn one failure into a reusable principle, re-run the full sample set, and check for regressions.
5. Adjust permissions based on verification coverage; bring in Subagents or dynamic workflows for independent tasks that can run in parallel.

When the two weeks are up, the team should have six deliverables: a working prototype, documented source-of-truth connections, a set of CLAUDE.md/Skills, acceptance and evaluation samples, a human escalation path, and a log of runs and failures. Together these determine whether the next round should expand automation, continue refining, or stop the line of work entirely.

Related readingAnthropic's playbook for AI-native startups: four stages, graduation criteria, and ready-to-copy promptsAnthropic's 36-page playbook breaks down the graduation bar and common pitfalls for four startup stages, complete with matching Claude prompts you can copy straight in.→