Claude Hit 100%, Codex Kept Going: The Week My AI Workflow Became a System
Last week I wrote about usage curves and cost in Claude Max vs Codex Max. This week felt different.
I still shipped a lot of work, but the bigger shift was in how I worked. When Claude hit the cap, I did not just bounce between prompts and hope for the best. I started tightening the operating model so the work could survive context switches, model switches, and long sessions.
From Feb 17 through Feb 22, 2026, I had 70 commits in aiv-git and 27 commits in assets. Version moved from 1.1.80 to 1.1.124. There was a lot of motion, but the most important change was that the system got more deterministic.
The Real Shift
The first change was procedural. I stopped relying on memory and started codifying build behavior in repo-level rules: AGENTS.md and doc/BUILD_TEST_WORKFLOW.md. Once the loop became explicit (bump version, build, reserve, verify HTTP 200, report status), I got cleaner handoffs and fewer ambiguous “did that actually work?” moments.
The second change was architectural. Boss behavior kept moving toward contracts and data in doc/BOSS_RULES.md and doc/BOSS_TIMELINE_AUTHORING_RULES.md. That mattered because one-off patches are hard for both humans and models to reason about over time. Extending an authoring contract is slower up front, but it ages better.
The third change was tooling discipline. tools/ stopped being a pile of side scripts and started behaving like a stack with clear entrypoints and health checks. I cover that in detail in From Side Scripts to Infrastructure, but the short version is this: one command startup and stable paths changed daily velocity more than any single prompt tweak.
The fourth change was treating content as first-class. The C:\devland\assets repo moved in lockstep with code and tools. Maps, scenes, particles, and UI assets were part of the same engineering loop, not a separate afterthought.
Trello, MCP, and Why Contracts Matter
I also spent time thinking through the Trello integration. The in-game reporter proved the loop works: file bug while testing, pull the card, fix it, close it. That was a good start, but it is still a direct API pattern.
The MCP version of the same idea is mostly about boundary quality. Instead of rebuilding request details every time, you expose stable operations (bug_create, bug_move, bug_comment, and so on) behind one tool surface with centralized auth and validation.
That is the same direction, just a cleaner level of maturity. I wrote the deeper take here: Should I Build My Own MCP for Trello?.
What Changed in My Prompting
My prompts are less open-ended now. I use smaller ownership boundaries, explicit acceptance criteria, and trigger phrases that map to deterministic loops. In plain terms, I am spending less energy trying to be clever in chat and more energy building reusable operating blocks.
That has been the biggest lesson this week. The model matters, but workflow design matters more. Once the rules and contracts are real, both Claude and Codex become much easier to direct.