FILED FROM ISTANBUL — A year after Anthropic shipped the first public version of Claude Code, the product is no longer just a CLI bundled with the Claude API. It is the de facto background agent inside a recognizable category of engineering team — small, senior, autonomy-comfortable, and disproportionately likely to be building agentic systems for somebody else.

The pattern is the part worth tracking. The Bulletin has spent the last quarter interviewing teams that have adopted Claude Code at production scale, and the adoption shape is more consistent than the official documentation suggests.

The shape of the adopting team

The typical Claude Code adopter, in our reading, is a five-to-twenty-person engineering team with at least one staff-level engineer who treats the CLI as a primary interface. The team's workload is heavy on configuration, refactoring, multi-repo coordination, and the kind of debugging that touches systems-level abstractions. The team is autonomy-comfortable — they have at least one prior agentic-AI tool in production, and they have at least one engineer whose pattern of work is to delegate sub-tasks to an agent and review the diff rather than to write the diff themselves.

This is a more specific pattern than the trade-press coverage of Claude Code tends to capture. Most of the public coverage frames the product as a Cursor competitor — a coding-agent for individual developers. The teams we have talked to are not using it that way. They are using it as a team-level automation primitive. Pull requests are generated by Claude Code. Refactors are kicked off by Claude Code. Investigation tasks ("find every place we reference the old API and tell me what changed") are routed through Claude Code. The product is being used more like a CI runner than like a pair-programmer.

The structural reason matters. Claude Code's terminal-native posture is, from the standpoint of a senior engineer, a feature rather than a limitation. The CLI is scriptable, integrable, deterministic in its surface area. The product fits naturally into the kind of tooling a senior engineer already has — Makefiles, shell scripts, CI configurations, hand-rolled automation. The Cursor-shaped IDE experience is, for this category of user, the wrong shape; the CLI is the right one.

What teams actually run on it

A representative sample, anonymized, of what we have heard:

A four-person platform team at a mid-market SaaS company runs Claude Code as a nightly job that scans the codebase for deprecation patterns and opens draft PRs against them. The team reviews the PRs in the morning, merges the obvious ones, kicks back the uncertain ones with structured feedback that Claude Code re-runs against. The team estimates the workflow has displaced something like one full engineer's worth of low-leverage maintenance work over a six-month window.

A seven-person agentic-infrastructure startup uses Claude Code as the build-time agent for their own product. The team's pattern is to write the high-level integration spec — three or four paragraphs in a markdown file — and let Claude Code propose the implementation. The implementation is reviewed by a human, revised by Claude Code, and merged. The team's stated reason for adoption is that the product treats the engineer as the authority and the agent as the worker, which is the inverse of the Cursor-shaped products' default.

A twelve-person team inside a larger enterprise uses Claude Code as the audit-and-investigation agent. The team's primary use case is forensic — when a production incident requires a deep dive into a system the on-call engineer does not own, Claude Code is the first responder. The product is configured with read-only access to the relevant systems and produces a structured incident report. The team estimates that this single use case has reduced mean-time-to-context on incidents by something like 40%.

The pattern across these three teams is the autonomy-comfortable pattern. None of them is using Claude Code as a replacement for the engineer's primary work; all of them are using it as the layer underneath the primary work.

What we did not see

We did not see Claude Code in casual or hobbyist use. The product's adoption is concentrated in teams whose engineers are comfortable with terminals, scripting, and the kind of explicit configuration that the CLI requires. This is a deliberate design choice on Anthropic's part — the product does not lower the technical floor — but it constrains the addressable market in ways that the trade press has not fully registered.

We also did not see Claude Code displacing the IDE-shaped products in their core use cases. Cursor is still the dominant pair-programming tool. Lovable is still the dominant vibe-coding tool. Claude Code is competing with neither of those products directly. It is competing, instead, with the absence of background automation — with the engineering hours that previously went into Makefiles, shell scripts, and hand-rolled CI rules. The competition is against the status quo, not against the other products in the category.

What this means for the category

The Bulletin's editorial position is that Claude Code's adoption pattern is informative about what the autonomy-layer category will look like at maturity. The dominant products in the category will not be one-size-fits-all. They will be shaped by the work patterns of the engineering teams that adopt them, and the patterns will be more heterogeneous than the venture-press framing has acknowledged.

The IDE-shaped products will dominate the individual-developer market and the team-collaboration market. The CLI-shaped products will dominate the senior-engineer market and the team-automation market. The vibe-coding products will dominate the small-team build-from-scratch market. None of them will compete directly with the others; the autonomy layer is wide enough to support several distinct shapes of product.

Anthropic's contribution to the category, at one year in, is the CLI shape. That is a more durable contribution than the trade press has yet recognized.

What we are watching

Three things. The first is whether the CLI-shaped adoption pattern survives the v2 redesign that Anthropic is reportedly working on. If the redesign moves toward an IDE-shaped product, the adoption pattern we have described above will fragment.

The second is whether other model vendors ship comparable CLI-shaped products. The competing products have, so far, been IDE-shaped or chat-shaped; if OpenAI or Google ship a CLI-shaped competitor, the pattern will consolidate into a recognizable category.

The third is whether the senior-engineer adoption pattern propagates downward into less-senior teams. The base-rate behavior is that powerful tools start with the most-skilled users and broaden over time. If Claude Code stays at the senior end, the addressable market is limited. If it broadens, the autonomy layer's adoption curve looks more like the cloud's than like the AI tools that have preceded it.