A Smooth Sea Never Made a Skillful Sailor

You fix a squeaky door, and now it hits the light switch when it opens. Anyone who has done a home repair knows this feeling. The fix was right. It just touched something you were not looking at. This post is about how often that happens when AI writes my code, and what my current way of working catches and misses. The Setup In Seven Releases With Grok , Grok wrote most of the code and Claude reviewed it. I ended that post saying I would spend my Grok usage on reviewing more than on writing code. So for this round I turned the roles around. Claude Opus 5.5 wrote the code. Two models from other companies reviewed it: GPT-6 Astra first, then Grok 4.7. This is the idea from Executor Model, Reviewer Model : the model that checks the work should not come from the same company as the model that did it. The work was a feature for my personal assistant app. In a long chat, you can now pin a message, or pick up a question and its answer and move them into a new conversation of their own. ...

In my last post I cancelled Ollama. The money running out early was enough on its own, but the part I wrote about was how many review rounds the work needed before I could merge it. That gives me a simple test for any model: how many times does the work go around review, and does each fix pass make things better or add new problems? This post runs the same test on Grok. Starting on September 21, it implemented four releases of my Zone 2 Trainer app and two releases of my personal assistant app. On a seventh release I swapped the roles, and Grok reviewed code that Claude wrote. Grok did well on that test. That is the short version. The longer version is about where the bugs that did get through were hiding: not in what the changed lines did, but in what they assumed. The Setup The models are grok-4.6 and grok-4.7 from xAI, on a SuperGrok subscription. grok-4.7 came out right after the first release, so it did the rest. On the other side was Claude. It wrote the issue lists and...