On September 9 at 07:21 I typed four words to an agent: push, PR, merge. At 07:23 I interrupted it: stop, just push to master, I'm not going to ope...
For further actions, you may consider blocking this person and/or reporting abuse
Before the commit for us too, but on a running preview rather than the diff. Each ticket gets its own stack and a private preview URL, and the developer who asked tests it and answers in the ticket thread. After that a script commits, opens the PRs and merges them, so the PR is a record of a review that already happened. Your 07:08 question is the part I can't script. On that first repository, do you read the diff at all, or only ask questions in the session?
Both. The 07:08 question is the part a preview URL wouldn't have caught. The import looked fine; some production entries had been edited by hand under the same identifier, and a full import would have written our local versions over them. The agent went and checked. That's the review. The PR afterwards would only have recorded it.
Fair hit on previews. A preview only knows the data it was built with, so a hand edit sitting in production under the same identifier never shows up there. The agent asking what the import would overwrite was the review. How did it find those entries: comparing against the last import, or reading timestamps on the production side?
Neither. I already knew those entries were there, because I had edited them by hand. The agent didn't discover them. I asked what a full import would do to them, and it checked the write path: same identifier, in place, review status reset. The read-only preflight against production came after that, once we knew the danger.
That's the clearer version: the review was your memory of the hand edits, and the agent's part was tracing the write path once you named the risk. It matches where we ended up. The person who asked knows what matters in production, so that check stays with them. The agent is good at confirming what a write would actually touch.
The detail that matters is the last one: the agent wrote the rule down so the next session would know it. Most agent workflows survive the push and die at session N+1, where the human assumption from session N has evaporated and the tooling politely rebuilds the ritual from scratch. The silent-overwrite catch is the other half — asking 'what exactly will this overwrite?' is what separates an agent from a for-loop. Did the written rule hold in the next session, or did you end up re-stating it anyway?
Yes, it held, and it's stored where the next session can't miss it: in the agent's memory for that repository, which the next session reads at startup. The overwrite question is the part that doesn't fit in a rule like that. It came from knowing that some entries had been edited by hand in production, and no file in the repo said so.
The reflex breaks the moment the committer is a machine. I run a site where an agent pushes straight to main — the PR's job (a second pair of eyes) got replaced by gates: typecheck, e2e, complexity audits, all blocking the push itself. Review moved from a UI ritual to the hook chain, and the honest trade-off is that nobody rubber-stamps a diff at 5pm anymore; either the gate catches it or nobody looks. The part I still do by hand is reading the diff of anything that touches auth or money — that review genuinely needs a human. Where do you draw the line between ceremony and safety net?
The line, on that repo, is whether a second human exists. There isn't one, so a PR is ceremony. The safety net is the session: three commits we'd already looked at, then a question about what the import would overwrite. A typecheck would have let the pull request through, because the code was fine. The ask was the bug.
The cost came from the instruction file routing the word "push" to the shipping skill, which cannot know that the review already happened in the session. The rule the agent wrote at 07:25 holds because it rests on a fact about that repository: you are the only maintainer. Does the written rule state that condition, or only that push means a fast-forward to master?
Only the second. The note the agent wrote at 07:25 says push goes straight to master, fast-forward, no pull request, and says nothing about why. You're right that the why is what makes it safe: the day a second person commits to that repository, the rule keeps firing and nobody gets a review. It lives in the agent's memory for that repo, so adding the condition takes one line.