I never let the AI that wrote a change be the one that signs off on it

Every piece of code that runs this blog, the daily publish job, the newsletter sender, the review page, was written by an AI agent I was talking to at the time. For a while, that same conversation was also the one deciding whether the change was safe to ship. That is the part I changed, and it is the one habit from this pipeline I would hand anyone building with AI, free, no catch.

The problem is not that the AI writes bad code. Most of what it writes is fine. The problem is that the agent that just wrote a change is the worst-positioned reviewer of that change that exists. It already believes its own reasoning. It remembers why it made every choice, which is exactly the thing a reviewer is supposed to not take for granted. Ask it “does this look right” and it is grading its own homework with the answer key it just wrote.

So the rule here is plain: before a real code change counts as done, a second agent checks it, one with no memory of the conversation that produced it, looking specifically for correctness bugs, security holes, and places the code is doing more than it needs to. Not “does this look fine.” A cold read, from someone who was not in the room when the decisions got made.

It costs one extra pass. It gets weighed heaviest on the files where getting it wrong reaches an actual audience: the job that publishes to the blog, the job that sends the newsletter, and the dashboard that handles the login token for both. Everywhere else, it still runs, just with less at stake if it misses something.

You do not need my pipeline to use this. You need a second conversation, with no context from the first one, pointed at the same change and told to find what is wrong with it. The AI that built something will defend it. A fresh one owes it nothing.