My 60 Million Token Day: A Brutal Introduction to AI Programming (Part 1)

So, in my last post, I introduced the "big idea": the SOAS model, born from a marketer's dream of building his own tools. It all sounds pretty clean and visionary, right?

Yeah, well, the reality was anything but.

My journey from "idea guy" to "guy who actually ships code" began in earnest in early July 2025. The catalyst was the release of Anthropic's new model, Claude 4 Sonnet. The hype was off the charts, promising a new level of reasoning and contextual understanding. I figured, "This is it. This is my moment."

I fired up Cursor, the AI-native code editor, and plugged in my API keys. My goal was simple: start building the foundation for my blog. What followed was a complete baptism by fire.

My daily routine became a frantic dance of prompting, generating, testing, and refactoring. And the amount of data I was processing was staggering. On an average day, I was burning through 50-60 million tokens.

Let's put that number in perspective. The entire 7-book Harry Potter series is about 1 million words. A token is roughly three-quarters of a word. This means, every single day, I was feeding the AI a volume of text equivalent to reading the entire Harry Potter series more than 50 times over.

At first, it felt like I had a superpower. But I quickly ran into a wall, and it's a problem anyone who has worked with LLMs knows intimately: digital amnesia.

The AI was a genius with the memory of a goldfish.

It would write a brilliant function, and then, ten prompts later, have no recollection of it. It would suggest a variable name and then use a completely different one two minutes later. Every new chat session was like onboarding a new developer who had zero knowledge of the project.

My solution was crude but effective. At the end of every coding session, I forced myself to create a "summary document." I'd make the AI recap everything we did: the file structure, the key functions we wrote, the logic we agreed on, and the goals for the next session. Every new day started with me feeding it this "brain dump" just to get it back up to speed.

But even that didn't solve the deeper issue. I noticed a disturbing pattern: the longer the conversation, the dumber the AI became. The context window would get cluttered with noise, and the error rate would skyrocket. The AI would start making sloppy mistakes, mixing up logic, and acting like it had just pulled an all-nighter.

I thought maybe it was the model. So, I experimented. I put Gemini 2.5 Pro through its paces. I tried Grok. They were all incredible sprinters—fantastic at generating new, isolated pieces of code from a clear prompt.

But the moment I asked them to perform surgery—to refactor existing code—the whole thing would collapse.

They were like architects who could design a beautiful room but couldn't knock down a wall without bringing the whole house down. The project was on the verge of becoming a tangled mess of brilliant but disconnected parts.

I was getting frustrated. Was this whole "AI co-pilot" thing just a gimmick for simple scripts?

As a last-ditch effort, I switched my primary model in Cursor to the one that started this whole mess: Claude 4 Sonnet.

And suddenly, the chaos started to subside.

It wasn't just a sprinter; it could run a marathon. It seemed to have a far more robust grasp of the entire codebase. When I asked it to refactor something, it didn't just change the code; it understood the implications of the change across multiple files. It was the first time I felt like I was working with a partner, not just a hyper-fast but forgetful intern.

I had finally found the right tool. But as I would soon discover, having the right tool and having the right process are two very different things.

...to be continued in Part 2.