A Smooth Sea Never Made a Skillful Sailor

Three builders, one instruction, and a crack in the instruction. In one release, the reviewers caught the coordinator's own instructions being wrong three times. Not the builders' code. The instructions. I use AI agents to fix my assistant app. In Green Tests, Broken App , I ended with a rule: one coordinator plans and checks the work, builders from three vendors write the fixes, and every piece is checked by the two vendors that did not build it. Between October 27 and November 2, I ran that rule through eight more releases. The builders' mistakes were caught, as before. What I did not plan for was that the coordinator's mistakes got caught too. I count them as mine, because I run the coordinator. The Setup The coordinator is one Claude Opus 5.5 session. It plans each release, writes a short instruction for each builder, checks every review finding against the real code before passing it on, puts the pieces together, and ships. The builders are Claude, Codex runn...

A smoke detector with a green light is not proof that it works. The light only says the battery is in. To know, you press the button and listen. This post is about the week I stopped trusting the green light on my own app, pressed the button, and changed how the fixes get built. In my last post, Five Reviews in One Release , I ended with one question to ask about every fix: what else does this touch? I also said I would stop letting a green checkmark tell me I am done. This post is the bigger version of that lesson. It was not one fix that fooled me. It was the whole app. The Setup My personal assistant app is the one I wrote about in Building a Personal Assistant: What I Got Wrong . Every change to it comes with tests: small programs that check the app does what it should. By October 22, 905 issues were closed, 422 of them since August 1. Nearly all were closed because about 4,700 tests passed. That day I said it plainly: basic things did not work, and I had lost trust in the a...

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...

Two weeks ago I ended a post about rate limits with "Ollama is back." I had re-subscribed monthly on purpose, to answer the question properly this time: does this plan give me the flexibility I did not have the first time around? I have the answer now, and it is no. I cancelled. The short version is that the money ran out early. The longer version is the reason for this post: even while the money lasted, the plan was not the real cost. The real cost was how many review rounds it took to get the work to a state I could merge. The Money Part Ollama Pro is $20 a month and includes $60 of cloud usage. This is my dashboard today: The $60 was gone within the first week of the month. When I saw the reset was still three weeks away, I cancelled. Most of the requests went to kimi-k2.7-code , the model I said in the last post I had not evaluated yet. I evaluated it. For comparison, my Claude weekly limit has covered most of this past week of daily work across two apps, and i...

This came from a post I saw on X. Somebody wanted a different watch face for their Garmin, sat down with Claude, and had one working in short order. I had thought about doing that for a long time. Like most new things, I was hesitant, because it meant stepping out of my comfort zone. It turned out to be easy with the help of AI. After about an hour of fiddling with it, I had a working watch face. I almost wish I had jumped on it earlier in the week, because I bought a watch face a few days ago and was very disappointed with it. The face is Ridgeline : big time, a ring that fills toward my step goal, heart rate, steps, battery. Getting Started Was the Part I Dreaded Writing for a watch is its own little world. There is a language I had never used, a set of tools I did not have installed, and a way of getting the finished thing onto the watch that I had never done. That stack of unfamiliar steps is exactly what had kept me from trying. The agent handled all of it. It set up the ...

In July I wrote that monthly plans beat paying by the token for my development work. I also mentioned getting only three or four working days before hitting the weekly limit. What I understated was how much that limit would start deciding my schedule, and which model reviewed my code. A $20 monthly plan sounds like a month of work. In practice the weekly limit decides how much of that month you actually get, and for me the answer was about three working days. Then I waited. Not for an hour, not until midnight, but for the reset, which is most of a week away when you hit the wall on a Wednesday. Three Days, Then Waiting The plan was Ollama Pro, monthly. Twenty dollars, and on paper that is a bargain next to what the same work costs through an API key. The weekly ceiling is what broke it. I would get through roughly three days of real work and spend the rest of the week unable to do the thing I was paying for. Waiting is worse than it sounds, because the work does not pause polit...

A couple of weeks ago I wrote that 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 own phone. That sentence is no longer true. My daughter started using it, and she found a limitation I had built in so deeply that I could not see it. Before that, though, some numbers. The app is at version 6.5.0, build 191, with 115 release notes behind it. It is 245 Dart files in lib and 234 test files. The lib/services directory alone holds 124 services. I bring this up because people who ask me about building their own assistant usually think of it as a weekend project - a chat box with an API key behind it. The chat box was the weekend. Everything after that is the reason the thing is actually useful. Three things moved it from a toy to something I open every day: it learns from its own mistakes, it accepts the way people actually talk, and it can look at a photo. Everything else is plumbing, and I will be hone...