A Smooth Sea Never Made a Skillful Sailor

This article follows Executor Model, Reviewer Model: Why Cross-Vendor Code Review Actually Works , where I wrote about using a second model to validate review findings. This time, the missing check was not another opinion. It was running the code. I am the only user of my personal assistant app, so every issue in its tracker is one I filed after watching something fail on my phone. One was the fasting timer. I told it in chat that I had started a fast at seven in the evening, and nothing started. I handed that issue and eight others to Claude. It read the source, quoted the right files, and explained why the timer could not fail the way I described. I closed all nine issues that afternoon. A few days later I asked Claude to check again, but this time it had to run the reported inputs. Four verdicts flipped. The second pass took six and a half minutes instead of two and a half. Those extra four minutes recovered four real bugs and found two more I had never noticed to file. T...

I thought one of my projects was in reasonable shape. I had been working in it for months, it was on version 4.24.3, and Claude had been through most of it more than once. Then I pointed Codex GPT-5.6 Sol at it with Ultra High reasoning, asked it to evaluate the codebase and file issues for anything it found, and it came back with 42 new issues in about ten minutes. Some of them were release blocking. I had Claude Opus 4.8 go through all 42 looking for false positives, and it confirmed zero. Every issue was real. That result is what convinced me to stop having one vendor's model check its own family's work. The Setup: One Model Writes, a Different Vendor Reviews The workflow is simple to state. Implement with one model, working from the most critical issues to the least critical and matching model strength to issue criticality: the highest-confidence model takes the most critical work, and the cheaper, faster models take the routine fixes further down the list. Then valid...

In July I asked an agent to push a build of my personal assistant app to my phone. Routine task. I do it most days. It built the release APK, ran flutter install , and my habits, journal, and health logs were gone. Not corrupted, not partially migrated. Gone. flutter install uninstalls the app first when it feels like it, and everything my assistant had learned about me lived in app-private storage with no cloud copy I could count on. The part that still bothers me is not that it happened. It is that the instruction telling it not to do this was already sitting in the repository, in the file the agent claims to read. The Rule Was Already There, in Capital Letters After the first time this happened, I did the obvious thing. I wrote the rule down. The commit is still in my history, and the message reads like an incident report because that is what it was: flutter install uninstalled the app before reinstalling on a real device, wiping local user data (habits, journal, health log...