Shipping Daily with AI
The discipline matters more than the tools. Here's what that looks like in practice.
Our only advantage was speed.
— Boris Cherny, Head of Claude Code
That's not a tooling claim. It's a discipline claim.
Daily releases aren't about having better tooling. They're about committing to a discipline that makes every slow, manual, or ambiguous process immediately painful. When shipping is cheap, the bottlenecks you've been tolerating become impossible to ignore — vague issue reports, unclear ownership, review cycles that stretch into days.
That pain is the point.
AI coding tools didn't fix any of that for us. But they lowered the cost of shipping enough that we couldn't hide from those problems anymore. Here's what we actually changed.
PRs over issues
The biggest shift wasn't technical. We stopped accepting "it's broken" and started requiring "here's what I found and here's what I'd try."
Before opening an issue, open a branch. Do the research. Claude Code can read your codebase, your logs, your errors — and propose a diff. Even if the proposal is wrong, it's concrete. Engineers can review a PR in ten minutes. Triaging a vague issue report takes three Slack threads and a week.
This extended beyond the engineering team. Our radiologists and product managers submit PRs now. Branch protection and required reviews mean nothing merges without an engineer sign-off — but the work of figuring out what to do shifts to the person who found the problem. Sometimes the code lands as-is. More often it becomes a precise brief that an engineer rebuilds in an hour, with full context already documented in the diff.
Cherny's team ran the same playbook: no PRDs, no mandatory ticketing, designers and data scientists and finance people all writing code. When contributing concretely becomes accessible to everyone, the bottleneck moves. That's the point.
Read-only Claude for observability
We gave Claude Code read-only database and log access in staging. It can look at errors, query structured logs, surface patterns — and change nothing.
Two things made this acceptable in a healthcare context: a BAA with Anthropic, and a strict policy against logging PHI. Structured logging with named fields — not f-strings, not interpolation — means logs are queryable without being sensitive. Claude sees user_id=<uuid> and event shapes, not patient data.
The result: Claude can say "this error has occurred 47 times since Tuesday, always on tenant X, always after this sequence" — and attach that context directly to the PR. That's not magic. It's latent demand made visible. Clinical staff and product people were already trying to understand errors and surface patterns — they just had no channel. Read-only Claude access met that need without asking anyone to change their workflow.
Better commits, better reviews
Conventional commits aren't about automation. They're about forcing yourself to categorize your own work. feat: vs fix: vs chore: is a small discipline that compounds. When release notes write themselves from commit history, you stop writing commit messages like "fix stuff."
Claude drafts PR descriptions that include what changed, why, and what to look for in review. Engineers edit them — they don't write them from scratch. Review quality goes up because the context is already there.
Claude as chrome, not core
Some things that used to require specialist time now don't. Grafana dashboards. Slack digests. Internal tooling. Claude builds the scaffolding, an engineer reviews it. The cognitive cost drops below the threshold of "we'll get to it."
Release notes to customers. Weekly team updates on what shipped. These aren't engineering work — but they used to be engineering bottlenecks. Now they're a prompt and a review.
There's a version of this that goes wrong — where you start trusting the chrome like it's the core. The diff still needs to be read. What changes is who spends cognitive energy where. As Cherny put it: the goal is to automate yourself away from the tedious work, so you can focus on what actually requires your judgment. That's not a threat to engineering. It's the whole point of engineering.
Safety controls are what make speed feel calm
Continuous delivery without controls isn't delivery — it's chaos. What we run:
- Branch protection on
main: no direct commits, required reviews developas integration branch: PRs land here first;mainis production- Feature flags per tenant: ship to one customer before everyone
- Required CI: tests, linting, type checking — not negotiable
- Multi-tenant isolation: a bad deploy can't cross tenant boundaries
The controls aren't slowing us down. They're what makes daily shipping feel sustainable rather than reckless. Speed without guardrails is just velocity in an unknown direction.