待翻譯：My AI Agents Ship Code While I Sleep. Nobody Reviews It

AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。

←All posts I plan during the day, agents build overnight, and I review when I wake up. This is the system that decides what ships without me. My morning starts with the board and last night's diffs. While I slept, an AI agent picked ticket SET-175 off the queue. Four cron jobs were running the same copy-pasted database scan. The agent pulled it into one shared helper, wrote six tests for it, ran the full 2,282-test suite, deployed to dev, and marked the ticket done. It even noticed a second ticket describing the same duplication and closed it. Nobody reviewed any of that before it went out. I'm the review, the next morning: the diff, the activity log, the board. The same agent left a different ticket unfinished. SET-184 flags appraisal-gap risk on pending deals using a property-data API. The code was built, tested, and deployed, and it shuts itself off safely if the API fails. It still didn't go live, because turning it on means paying for a data subscription, and no test can tell you if that's worth the money. That call waited for me. A ticket field called autonomy decided which one could finish without me. The rest of this post is that field and the system around it. I also think most of the autonomy debate is about the wrong thing. Plan all day, build overnight, review in the morning The routine is simple: Daytime is planning. Turning ideas into specs, writing acceptance criteria, making the calls agents will need before they need them. Nights are loops. A background agent picks the top buildable ticket, builds it end to end, and either finishes or parks it with a question. Mornings are code review. Code moves the same way every day. Agents branch, merge to dev, and dev deploys to the dev Amplify site plus the backend. Once a day I review the PR from dev into prod. That daily PR is the only way anything reaches prod. How code moves Agents get everything up to dev. Prod goes through one PR a day, and I'm the reviewer. agent brancheseach build on its own branch → merge to devloops land here, never further → dev deployAmplify dev site + backend → the daily PRdev → prod. I review it myself → prodships after my check Here's the ticket from this morning: --- id: SET-175 title: Extract shared scanActiveDeals(statuses) cron helper (api) lane: done size: S autonomy: auto commits: [0117e92] --- WHAT: 4 EventBridge crons (chaseScan, weeklyDigest, deadlineReminder, morningBriefingNotification) hand-roll the identical active-deal scan: loop statuses -> paginated QueryCommand on GSI1 -> MAX_DEALS_PER_RUN cap. EXTRACT scanActiveDeals(statuses, opts) into packages/api/utils; each cron calls it and PRESERVES its EXACT status set (chaseScan includes 'prospect'; weeklyDigest excludes it). ACCEPTANCE (behavior-preserving; verifiable): new scanActiveDeals unit test (pagination across pages, MAX cap enforced, status param drives the GSI1 keys); existing handler tests stay green. api unit + tsc. Promoted from IDEA-40 (janitor tech-debt; auto-promoted per attention-ledger AL-3 — no product decision, verifiable by build-next). Every call is made in the spec before an agent touches it. This one even says why it qualified for auto: no product decision, and every requirement can be checked by a test. Planning at night and reviewing in the morning is common practice now.1 Plenty of people run this schedule and wake up to slop. The difference is what the agent is allowed to finish. I main Claude Code as my coding agent. Every loop in this post is one of its sessions. The loops themselves are skills: instruction files in the repo, run like commands. I tweak them every time one goes wrong. My toolbelt My skills: instruction files in the repo, invoked like commands. Real names from my two repos. The loopsthe autonomous passes that drain the board /autopilot/build-next/housekeeping/harvest-ideas/rr-audit/board Eyes on productionhow a build proves itself against the deployed system /deploy-status/amplify-logs/api-logs/observability-triage/debug-doc-pipeline/debug-doc-chat/test-doc-pipeline Test data on demandrealistic state without touching real clients /seed-deal/seed-calendar/reset-deal/list-deals/inspect-deal Auth and usersreal Clerk users and orgs for auth-boundary tests /clerk-users/clerk-orgs/clerk-metadata/settle-auth Docs and planningthe system of record stays current; decisions get a sitting /docs-atlas/docs-review/plan-session Why I don't code-review every AI commit The debate right now is about how much to trust the agent. One extreme is YOLO mode: permissions off, guardrails off, agent runs free.2 Agents are cheap, so the pitch has legs; ship fast, revert whatever breaks. But a revert doesn't un-ship bad data or win back a client's trust. The other extreme reviews every diff, which works until the agent produces more than you can read. Most people sit at the careful end. Only 8% are comfortable with full agent autonomy.3 Engineers who use AI on most of their work say they can fully hand off almost none of it.4 The tools split the difference with classifiers that auto-approve safe-looking actions and flag the rest. I think both camps are asking the wrong question. The right question is: what work can a test prove? My planning lives in a folder: one markdown file per ticket. Agents edit the files directly. A small local server renders them as a Kanban board for me. Every ticket has one field that decides everything: autonomy: auto | needs-input | blocked. A missing field counts as needs-input, so nothing builds by default. auto means an agent can take the ticket all the way to done with no human involved. needs-input means the ticket waits for me no matter how green its tests are. The question is simple: can a test prove this correct, or does it need human judgment? SET-175 was a pure refactor with tests that fail if the behavior changes. Provable, so it shipped itself. SET-184's code was just as provable and got built; the money call wasn't, so it waited. SET-175 vs SET-184 Both tickets got built and verified; the autonomy field decided which one could ship itself. board/tickets/SET-175.mdauto Extract shared scanActiveDeals(statuses) cron helper lane: donesize: Spriority: P3 Pure refactor. Zero behavior change. Six new tests that fail if the scan behavior changes. Shipped itself to dev overnight. No review before it went out. board/tickets/SET-184.mdblocked Flag appraisal-gap risk with AVM + comps on every pending deal lane: backlogsize: Mpriority: P2 Built, tested, deployed. Shuts itself off safely if the property-data API fails. Held on one call no test can make: is the paid data subscription worth the money? That's the whole idea. I make the decisions a test can't settle: product direction, pricing, brand voice, legal text, security policy, client data, anything irreversible. To be clear: unreviewed means unreviewed to dev. Agents deploy to a dev environment on dev data. The prod branch is out of their reach. shipped only moves when I run the cut myself. Client data sits behind the same gates as pricing and copy. The blast radius of a bad overnight build is a broken dev URL. Here's the full system as a map: My board, drawn as a graph Agents and one human as nodes; lanes, promotion, and escalation as edges. Purple edges are provable and run alone; amber edges wait for a person. If you've used LangGraph, this looks familiar. The practice is called graph engineering: wire agent steps into a graph like this one.5 Every serious framework landed on the same building blocks this year: typed state, conditional routing, checkpoints, interrupt gates.6 My board has all four as markdown and rules. Frontmatter is the typed state. autonomy is the routing. needs-input is the interrupt. The activity log is the checkpoint. What I give up is enforcement. A graph runtime can block an illegal move and tell you exactly which step failed. My rules only hold because the model follows them and I catch drift in the morning. What I get back: I can change a rule with a commit, and nothing sits between me and the model. The real difference is who picks the path, the agent or you.5 A graph locks the route in up front. I let the agent pick its own route and put the effort into checks instead. Anthropic's own agent guide says the same thing: simple, composable patterns over frameworks.7 Even the graph teams are moving this way: the 2026 trend in production is adding human approval gates before risky actions.6 Verification the agent can't fake Unreviewed shipping only works if the model can't declare done by itself. Every auto ticket has to clear checks that live outside the model: My verification ladder Every auto ticket climbs all six rungs. The two starred ones are where 'the AI finished it' claims usually fall apart. • 1 · TDD Failing vitest tests first, for every acceptance criterion: happy, null/empty, invalid, and the authorization boundary. ★ 2 · E2E required A Playwright spec drives the real UI via mock-auth role switching. A user-facing change with no spec is not done. • 3 · Typecheck react-router typegen + tsc, clean on the touched surface and everything that consumes it. • 4 · Deploy to dev Push the dev branch. Local edits change nothing a live check can see until this happens. ★ 5 · Live verify Deploy job SUCCEED, dev URL renders, Playwright green against that live URL, error monitor clean on the exercised path. All four, every time. • 6 · Docs sync docs/ and CLAUDE.md updated wherever behavior or a contract changed. Shipping isn't done until the docs are. A missing rung means the ticket isn't done, no matter how confident the agent's activity note sounds. Here's an agent finishing SET-308, straight from the ticket's activity log (trimmed): 2026-07-03 [claude] DONE (autopilot, dev-verified). ... ADDED the mandated class-retiring guard packages/api/infra-guards.test.ts ... Verification ladder cleared: infra-guards (5, incl. negative control) + full api suite 2718 pass; api+infra typecheck green; deployed SettleStack-Dev (cdk 135s); doc-intelligence E2E PASS vs deployed dev; AWS-log live confirmation — processed a doc on dev, settle-doc-process-dev finalized clean with ZERO ses:SendEmail AccessDenied in the window. Docs synced. Commits 2552b89 + 4b8e352. Most setups skip the live-verify step because their agent can't see past localhost. Mine can. It reads the build log when a deploy fails, and checks deploy status before saying it deployed. It tails CloudWatch for new errors on the surface it touched. Playwright runs against the deployed dev URL, not a local server, so the build it tested is the build users hit. When a deploy 500s at 2am, the agent pulls the build log and fixes what it finds. The ticket's activity line says exactly what was checked, including the gaps. What my agents touch Every surface my agents can read or drive. The verification row is the part the model can't fake. The harness, code, and planning Claude Codethe harness; every loop is one of its sessions gitcommits, branches, worktrees GitHubpushes and PRs via the gh CLI the boardmarkdown tickets it edits directly docsatlas and ADRs, synced in the same commit AWS Amplify Hostingdeploys; reads the build log when one fails CloudWatchlogs and alarms on the surface it touched Lambda30 handlers, debugged by log stream Step Functionsthe doc pipeline, traced end to end DynamoDBsingle-table state reads while debugging S3document buckets and extracted text Bedrockthe models the product itself calls Verification vitestfailing test first, full suite before done TypeScripttypecheck on the touched surface Playwrightdriven against the deployed dev URL Clerkreal test users and orgs for auth flows If you've run Playwright, you're wondering about flaky tests. The rule: re-run the failing spec by itself. If the change caused the failure, fix it or abort the build. If it was already failing before, it goes o [truncated for AI cost control]