🌏 閱讀中文版本
CI fails.
You stare at the screen. Progress bar stuck on “Running tests.”
Five minutes.
You get up for coffee. Come back. Still five minutes.
Copy the error. Paste it to AI. Wait for the fix. Push again.
Wait five more minutes.
Then?
It fails again.
You flip to Slack. A teammate: “Done yet? I’m waiting to merge.”
You reply: “CI failed again.”
You’re not blocked. The process is.
Last month at a Taipei Meetup, Anthropic engineers shared how they handle this.
The room was energized. Nobody was asking “Can AI write code for me?”
They were asking: “How do you design systems where AI is part of the development infrastructure?”
Context Loss: Memory Needs to Be Engineered
Every developer who’s used an AI coding assistant deeply has hit this moment.
You spend thirty minutes building project context — conventions, architecture decisions, the reasoning behind key choices.
You feel like the AI gets it.
Then the context window compresses.
And it forgets everything.
Context isn’t the AI’s memory. It’s your infrastructure.
Anthropic’s approach is straightforward: write context to files, read them back automatically at the start of every session.
Sounds low-tech? That’s engineering.
You don’t expect RAM to remember yesterday. You write it to disk. Context works the same way.
The implementation: a session start hook.
Every time Claude Code starts, it automatically reads CLAUDE.md, ADRs, and your conventions.
That’s it.
Not fighting the context limit. Assuming it will drop, and designing the recovery.
A design premise worth considering: treat context loss as the default, and build the recovery mechanism in.
Key Insight 1: Context isn’t the AI’s memory — it’s your infrastructure. Managing context persistence deliberately is more reliable than depending on the model’s natural recall.
The Permission Dilemma: Balancing Autonomy and Control
You’re in flow.
Claude pops up: “Should I write this file?”
You click yes.
Three seconds later, another prompt.
Three seconds after that, another.
But here’s the thing: safety and efficiency have never been a binary.
The permission system exists because autonomous code execution carries real risk — accidental file deletion, unexpected system changes, sensitive data exposure.
When the repo is isolated, the operation scope is clear, and rollback cost is manageable, higher automation makes sense.
Auto-accept hooks let developers build custom logic to automatically approve specific categories of operations. A hook inspects the pending operation, evaluates it against preset rules, and grants approval without user intervention.
Think of it like giving an intern a whitelist — these folders you can touch freely, everything else you come ask me.
For example, a hook could auto-approve all file writes within a specific directory, while still requiring confirmation for anything outside that scope.
For developers willing to own full responsibility, the dangerously-skip-permissions flag removes the approval flow entirely. The flag was deliberately named to be alarming — a constant reminder of the tradeoff being made.
In a production repo? Approve each operation manually.
In an isolated container for experiments? Enable dangerously-skip. If it breaks, throw it away and start over.
The difference isn’t the tool. It’s whether you’re willing to own the consequences.
Key Insight 2: Permission control isn’t an on/off switch — it’s a layered design: what runs automatically, and what requires a human. Auto-accept hooks are the most practical way to balance efficiency and safety.
YOLO Push: Putting AI Inside Your CI Pipeline
Then there’s YOLO Push. Name’s a bit reckless. Architecture is surprisingly sound.
10 engineers. 10 CI runs per person per day. 5 minutes each.
That’s an 8-hour workday. Gone. You think you’re building. You’re waiting.
Their solution flips the loop entirely.
CI fails. The pipeline installs Claude Code. Passes the failure context to it.
Claude reads the error, finds the issue, fixes it, commits.
No human in the loop.
Reruns. If it passes, the pipeline continues. If not, it tries again — up to the retry limit.
Sounds risky? The key is where you draw the line on what Claude can touch.
The allowlist is hardcoded: lint errors, type errors, formatting issues, unused imports.
The blocklist is hardcoded too: security, secrets, authorization, compliance. Anything touching authentication or data access — human review, every time.
How does this land in practice? Use the official Claude Code GitHub Action in your workflow, and pass the allow/block lists in the prompt.
What gets automated isn’t bugs. It’s waiting.
This isn’t just a tooling question. It’s a question of how engineers define their own value. When mechanical work gets automated, where does your judgment live?
Key Insight 3: The core of YOLO Push isn’t “let AI write code” — it’s “let AI handle deterministic mechanical errors.” The allow/block list mechanism keeps AI autonomy scoped to low-risk, high-frequency scenarios.
Multi-Agent Code Review: Dividing the Reviewer’s Attention
Single-model review — the problem isn’t intelligence, it’s scope. Logic, security, style, all at once. Humans can’t do that either.
One Agent for logic. One for security. One for style.
This approach reduces single-model blind spots and lowers the risk of both false positives and false negatives.
If you’ve reviewed AI-written PRs, you’ve noticed: strong on logic, weak on style. The division of labor makes sense.
Single-reviewer blind spots aren’t solved with a smarter model. They’re solved with specialization. One Agent per domain — logic, security, style — then a combined verdict. That’s what review should look like.
Managing Up: Getting Your Manager on Board
If you want to push YOLO Push or auto-accept hooks to your team, your manager’s first reaction will be: “Is this safe?”
Acknowledge it upfront: yes, there’s risk.
But ask the honest question: does your current manual review actually catch everything?
Manual review works well in certain contexts, but for high-frequency, low-risk errors, the marginal return diminishes.
Managers putting responsibility and risk first is a reasonable consideration.
Here’s what you can say:
“I want to try this on one small feature. If something goes wrong, I own it. Two weeks, then I’ll show you the data.”
This tells your manager: you’ve defined the scope, the accountability, and the way you’ll measure it.
Pick an internal tool with a clear blast radius and low rollback cost. Hardcode the allowlist — lint, format, unused imports only. Block everything else.
Then watch the numbers.
Did CI failure rate drop? Did developer wait time go down?
Data makes the argument. It’s more persuasive than principles.
Managers don’t need guarantees. They need clear accountability boundaries.
Two weeks later, the CI failure rate will answer the question. Not you. Not your manager.
Sources
- Claude Code GitHub Repository — Official Claude Code implementation and tooling reference
- Anthropic Documentation — Model capabilities and API usage
- Claude Code GitHub Action — GitHub Actions integration and parameters
- Anthropic Engineering Blog — Technical articles from the Anthropic engineering team
Where are your ten minutes going today?
Are you spending it waiting for CI, or manually fixing the mechanical issues that AI could automatically handle within an allowlist?