After 74 Billion Tokens, I Spend More Time Exploring the Foundation

I have consumed more than 74 billion Codex tokens.

I use subscriptions from almost every major AI provider, and it has been more than a year since I wrote code line by line with my own hands.

AI has removed a lot of repetitive work and made implementation dramatically faster. But in some parts of my work, I am spending more time than before.

The foundation of a new application is a good example.

Faster implementation changes what is worth exploring

Before, implementing one approach could take so much time that exploring several alternatives was expensive. Each new direction meant another substantial investment before I could properly see how it behaved.

Now I can build an approach with AI, test it against what the application needs, find what does not fit, and try another.

I might go through three, four or five approaches. Combine parts of them. Throw others away. Simplify something that became unnecessarily complicated.

The extra time goes into using that freedom well. I can investigate choices that would previously have been too expensive to implement just for comparison.

Test the alternatives against the application

A working example is useful, but it is not enough to select a foundation.

The pieces need to support the business scenarios, the user experience and the performance the application will need as it grows. An approach that looks clean in isolation may create awkward dependencies once it has to work with everything else.

Consider a booking product. A foundation should support more than creating one successful booking. What happens when availability changes before confirmation, when a customer cancels, or when an operator needs to correct a mistake? How does the chosen approach affect the information the screen needs and the rules the system must protect?

These are questions to compare approaches against, not a claim that every application needs the same architecture. The requirements give the experiment a purpose. Without them, generating another version is simply more output.

AI can help investigate difficult cases as well as routine ones. The useful test remains whether the result fits the application we are actually building.

Combine carefully, then remove what is unnecessary

An alternative can be useful even when I do not keep it whole.

One may suggest a clearer way to organize data. Another may handle a business scenario more directly. But combining their useful parts creates another version that needs testing; two good pieces do not automatically fit together.

The aim is not to keep every capability explored along the way. Extra abstractions, duplicate responsibilities and flexibility the application does not need can make the foundation harder to understand and change.

Discarding them is part of the work. A prototype that exposes why an approach does not fit can be valuable without contributing code to the final product.

I still review the code

AI can produce something impressive and then make a decision that makes me think, “Thank God I checked that.”

The result may be a small, solid foundation. It looks simple precisely because I spent the time trying, testing and removing what the application did not need.