This isn’t going to be a massively long post, but it is a critical one. There is a brutal lesson here about trying to move too fast, failing your own basic processes, and misunderstanding how AI actually manages state.
If you’ve been following along, you know that getting argparse and lodash to compile natively into Go has been long and slow for the tgo project. These (to me) are foundational libraries. I use them everywhere, and I absolutely have to get them working.
Yesterday, I kicked off an AI command in Cursor to try and fix the remaining argparse compilation issues. It was the end of the day, so I just walked away. I told myself, “You know what? I’m done for the day,” and left it spinning.
When I came back this morning, it was done. And I was totally blown away—it actually compiled.
There was a minor runtime issue, but I didn't think it was going to be too much of a problem. So, I told that AI to start looking into the runtime bug. Meanwhile, I ran my broader regression tests and found out there were about five or six regressions elsewhere in the codebase. To speed things up, I spun up another AI to go and fix those regressions concurrently.
Twenty minutes later, the regressions fixed. I then tried to compile argparse and... no dice.
I then asked AI to look into it. Then look into it again. Then again, then again.
Hours, and I do mean HOURS later, there was zero progress, only more and more tokens burnt up.
I had victory in hand, and I ended up making a huge mistake that I didn't realize until much later.
I Made A Big Mistake Without Even Realizing It
There is a really, really painful lesson here: I never committed the code that had the successful fix in it. Even though, it had regression failures in it, I had no RECORD of what was actually working.
In my attempt to move faster and juggle multiple AI agents fixing different things, I violated almost every layer of proper GitOps. By failing to commit the argparse fix the second I realized it compiled, I ensured there wasn't a clear changelog that the AIs could reference against in the future.
When you are doing something difficult and hard, this is a fatal error. AI is very good at generating code. What it is not good at—especially if you are using smaller models or an IDE like Cursor that inherently has low context windows—is maintaining a rich understanding of complex state.
These AIs love to summarize the chat to save tokens, and then all of a sudden, they forget the exact nuances of what they just built. When you lose the code and tell the AI, “Oh, go look through the chats and find it,” or you tell another agent to go read a different chat, they will try. They will go and pull data. But they simply do not possess the rich, stateful understanding required to do a side-by-side comparison and create a comprehensive, working resolution of changes. They cannot magically cohere two complex, conflicting states together from a chat summary.
At the end of the day, if there is no hard evidence of the code in your Git history, what was it? I have no idea. My buddy Cursor has no idea. It's gone.
Sigh...
The Operational Rule: Commit Religiously
This is a reminder to myself, and a warning to anyone using AI to write complex software: You must commit frequently and religiously.
If you get any level of success—if you feel like actual progress has been made and a barrier has been broken—commit it right then and there. You don't necessarily have to push it up to the remote immediately. You don't have to generate a pull request. But you must establish a clear, immutable stopping point where things were objectively improved.
The reason you do this is so you, and the AI, can see the change happen. A commit provides a hard history of the exact delta that led to success. When an AI starts hallucinating or regressing, you need that diff to slap it back into reality.
I see a lot of people out there doing a similar but different thing. They have code that works, they don't commit it, and then all of a sudden something happens—their machine crashes, they run a bad command, or an AI blindly overwrites a critical file.
The next level to this is that you must push your commits. And in order to push commits—especially when the broader codebase might still have broken runtime issues or regressions—you absolutely have to use feature branches.
Do not abandon your standard engineering discipline just because AI is writing the code. If anything, AI requires more strictness, more guardrails, and tighter operational rules, because at the end of the day AI is just automation. Its automating YOUR workflows. And with all automation, it succeeds at scale, and fails at scale.
I am rebuilding the argparse compilation from scratch today because I tried to cut a corner.
Don't make the same mistake. Commit your code.
Top comments (0)