For weeks I went in a figure-8. I would fix something broken, feel good about it, then break it again on the very next pass. What made it baffling was simple. I had a context file the whole time. My AI coding context sat there loaded and ready, exactly the way the workflow should run. The work still went in circles. For a while I blamed the model, or some setting I had missed. It was neither. One file in my setup was quietly doing two jobs at once. And those two jobs were canceling each other out.
I Used Three Man Team to Build Three Man Team
Some background. I have a free version of Three Man Team on GitHub. I am building a Pro version now. It lives in its own folder, wired to a Bitbucket repo. The plan was about as clean as it gets. Use my own copy of Three Man Team to build the Pro version. The tool builds the product. I do this kind of thing for a living, so I did not think twice about it.
So every morning I opened iTerm and started a fresh Claude session. My context file sat right there in the project. On paper it should have worked perfectly. In practice I kept ending the day about where I started. And I could not figure out why.
My AI Coding Context Was Overwriting Itself
Here is what was actually happening under the hood. My architect file carried two responsibilities at once. It ran the skills that build the product, the way it should. But it also rewrote itself in the same motion. So every run wrote over the file steering the work. That turned into a loop. I would fix something broken. The next pass would run. My own changes would write straight back over the fix and undo it. Fixed, then re-broken. Fixed, then re-broken. That is the figure-8. It can spin for a long time before you catch it. Every session still looks like progress while you are inside it.
Here is the honest part. The AI coding context was never the real culprit. That context was fine. The file holding it was both the engine and the target. It drove the work. And it was the thing the work overwrote.
Go back and read that last line.
Three Man Team exists to prevent exactly this. The whole framework runs on file-based handoffs between roles. Architect, Builder, and Reviewer each live in their own file. Each one passes state cleanly to the next. That separation is the entire point. And I had collapsed two of those jobs into a single file without noticing. So the handoff overwrote itself. I broke my own rule, on my own product. It took me weeks to catch it. It is the same discipline I wrote about when the tooling turns on you. I just never thought to point it back at myself.
Git Showed Me the Figure-8
The only reason I caught it is that I had committed everything to Bitbucket as I went. So when the work stopped making sense, I did not trust my memory. I pulled up the history and looked. The diffs told the whole story. I watched the same lines flip back and forth. One commit fixed a line. The next clobbered it. Over and over down the log. What felt like a vague sense of being stuck was a precise, repeating pattern, right there in the record.
This is the part most developers underuse. We treat version control as a safety net for code. It absolutely is that. But it is also a running record of decisions. The shape of your own mistakes lives in that record too. A diff does not only show you what changed. Read enough of them in a row and it shows you what you have been doing to yourself. Once I could see the pattern, the fix was almost boring. I split the file. Now the architect directs the build, and the build never touches it back. One file, one job.
Git Became My AI Coding Context Layer
So I rebuilt my process around that lesson. This part is worth stealing even if you never touch my framework. It runs on the same instinct as the way I talk to these tools in the first place. Say what you mean. Leave nothing to assumption.
Now when I start a new Claude session, we do one thing first. We create a new branch named with that day’s date. Then we write a short file that captures what we are building and what we decided. Not the code itself, but the thinking behind it. The reasons, the tradeoffs, the small decisions that usually evaporate when you close the window. The working copy holds the instructions and points at a separate folder for the actual build. So the tool and the product never touch. And nothing the build does ever rewrites the file that drives it.
There are paid services for this now. They store your chat history and hand your AI a memory across sessions. Some of them are genuinely good. But I write code for a living, which means I already live in git all day. Branches, commits, history, diffs. None of that is a new tool I have to go adopt. It is the same job a memory app is selling me. And I already own the infrastructure. So I put the two ideas together. I am building an AI tool, and I track the software and the conversation in the same place. The commits remember the code. The branch files remember the decisions. My AI coding context stops living in a chat window I am going to lose. It lives in the repo, right alongside the rest of the work.
What Good AI Coding Context Looks Like in Practice
You do not need Three Man Team to do this. You do not need any framework at all. The core rule is simple. Give every file one job. The file that drives the work should not be the file the work edits. The moment those two collapse, you get the figure-8. And you can run it for weeks before anything tips you off. After that it is mostly habit. Write down what you are building and why. Commit it. Create a new branch per session if that fits your head. And when the agent loses the thread, and it will, point it back at the file. Do not explain the whole project from scratch again.
The AI starts every session at zero. Your job is to make sure the project does not.
Leave a Reply