Production Is Burning. We Can’t Merge.
Saturday afternoon. A production batch job had been hanging for over eighty hours.
The cause was clear. The BigQuery job.result() call had no timeout. When the BQ side terminates abnormally, the Python process keeps waiting for a response that will never come. Cloud Run sits at “RUNNING,” no logs, no errors. Just the electricity bill quietly burning.
The fix took thirty minutes with Claude Code.
# Before: no timeout = infinite wait
job = self.client.query(query, job_config=job_config)
result = list(job.result())
# After: 30-minute timeout + retry
for attempt in range(max_retries + 1):
job = self.client.query(query, job_config=job_config)
try:
result = list(job.result(timeout=timeout))
break
except concurrent.futures.TimeoutError:
job.cancel()
if attempt < max_retries:
continue
raise BigQueryClientError(...)
Tunable through environment variables. Existing interfaces preserved. Impact contained to one file. PR opened. CI green.
All that was left was the merge. And the merge would not happen.
The “Human Approval” Wall
GitHub branch protection rule. “At least 1 approving review is required by reviewers with write access.”
The only collaborator with write access was the author. GitHub does not allow you to approve your own PR. Admin override blocked. Direct push to main rejected.
Until a teammate logs in on Monday and clicks Approve, this PR sits frozen.
Production keeps burning. The code is finished. But without “human approval,” nothing moves.
What Will That “Human Review” Actually Examine?
A pause. A question.
When the reviewer arrives Monday morning, what exactly will they look at?
- Whether
concurrent.futures.TimeoutErroris handled correctly. - Whether the exception path around
job.cancel()is appropriate. - Whether the retry loop has any race conditions.
- Whether the change stays consistent with existing metrics collection and logging.
Honest answer: this level of code review is hard for the author to do well.
The author wears every hat — PM, designer, infrastructure, consulting. Twelve years of every domain, solo. Code is no problem. But asked “can you guarantee thread safety on this Python code?”, the answer is not a confident yes.
Meanwhile, the Claude Code that wrote this code:
- Read the existing singleton pattern, label-merging logic, and metrics collection in full.
- Added the timeout and retry without touching any existing interface.
- Threw the error using the existing constructor signature of
BigQueryClientError. - Made the values tunable through environment variables.
How many people on the team can actually “review” code like this?
Writing Code at a Production Level
Software development has many layers. Some — training large language models, managing GPU memory — are still beyond what AI does well.
But the bulk of day-to-day software work is a different animal.
- Hit an API, transform data, write to a database.
- Implement CRUD on top of a framework.
- Add parameters to existing code.
- Configure a CI/CD pipeline.
In this territory, Claude Code produces code with high accuracy and speed, consistent with the patterns already in the codebase.
The traditional workflow looks like this.
- Explain the situation in Slack (15 minutes).
- An engineer reads the codebase (30 minutes to an hour).
- Discuss the fix approach (15 minutes).
- Implement (30 minutes).
- Open a PR (10 minutes).
- Another engineer reviews (next day).
- Iterate, re-review, merge (the day after that).
With Claude Code, steps 1 through 5 collapse into thirty minutes. The code is written with the existing patterns of the codebase already in mind.
The Trust Model Is Inverted
Today’s development process is built on a single premise: humans write the code, other humans review it.
- Branch protection rules → require human Approve.
- PR templates → designed for human readers.
- CI checks → assume human verification.
But if the code is being written by AI, and that AI’s output quality is above the average engineer’s, is “human approval” actually functioning as a quality gate?
If anything, it is reversed.
AI-written code and human-written code do not call for the same review focus. Today’s process draws no such distinction.
The trust relationship has flipped, but the process is frozen in the previous era.
So What Do We Do?
Not arguing that human review should be abolished.
But at minimum, the following deserve thought.
The approval process for AI-written code may need its own track.
Code written by humans and code written by AI demand different attention. AI-written code review can concentrate on “is the intent right?” and “is the business logic correct?” Syntax errors and pattern drift happen less with AI than with humans.
Branch protection rules need a path for “team of one” repositories.
Forcing team-grade review requirements on a repo with a single collaborator is a design oversight. GitHub should fix this.
It is also time to seriously discuss recognizing AI Reviewers as legitimate reviewers.
With the Claude Code GitHub App installed, an AI can review and approve a PR. Technically, it already works. The remaining question is whether organizations are willing to accept that as “real review.”
This Is What 2026 Looks Like
Saturday afternoon. Production is burning. The code took thirty minutes to write. The merge has to wait until Monday.
Because “human approval” is required.
Will that human review the code more accurately than Claude Code did?
Probably not. But the rules say so, so we wait.
Code takes thirty minutes to fix. Merging takes three days.
The bottleneck in software development is migrating from the code itself to the process around it.