I hear so much about people running into token limits and using bajillions of tokens. Am I doing something wrong? I'm finding it hard to run into the limits of a Claude Max (20x) account. Well, perhaps the 50% Fable limit is something I have to be aware of, but otherwise this more than I can consume. I am the limiting factor: my capability to review code and design documents.

I use it to develop a large MRP-style app. This is as complex as things get.

Is it Clojure that makes things so efficient? My work style (lots of design documents)? I really don't know.

Do people skip the "review the code and read the documents" step perhaps?

The guy built an engine designed to burn tokens: https://miro.medium.com/v2/resize:fit:1100/format:webp/1*85x...

Each little critter in there is a component that both consumes and produces tokens, and it runs in a feedback loop, so each token inserted into the machine will cause it burn exponentially more tokens in order to output yet another token.

Ostensibly its purpose is to create software, but what it does is very efficiently burn tokens as fast as possible.

The article talks very directly about abandoning human code reviews. Couple that with a layer of AI agents whose purpose is to produce work for other AI agents, and you've got yourself a very efficient token burning feedback loop.

I'm on similar plan through work ( Teams max ), and I've only ever reached the limits by backgrounding large exploratory feasibility studies while also getting on with actual work.

From what I can tell however, true "vibe coding" gets a lot more expensive very quickly.

If you're actually just agentic engineering, then after a couple of mis-fires you'll stop, re-analyze what it is doing, what you asked for, and consider different approaches.

With pure "vibe coding", you'll keep asking it to meet your requirements as it twists and turns in the background to try to fit.

A more concrete example from a personal "game" I'm developing as a hobby:

Fable got itself in knots trying to render some fairly basic blocks on top of a wall. It understood the problem, it consistently rendered as "fins" under screenshot, and thrashed away for a good while trying to produce better looking blocks to no avail.

Eventually it stopped, and lied that it was happy with how the walls now rendered.

It took me 30 seconds in-game to realise that it was only rendering backfaces, once clued into that, the machine was able to trivially fix it without using much tokens.

But then another similar issue popped up later, hedges exhibited the same behaviour.

It would have been easy to accept the solution to render the hedges in the other order too, but I demanded a better explanation, and it turns out that it had fairly early on defined a DrawBox() method that was backward to Unity's expectations, and pushing further, it emerged this all started when I asked it to transfer what it had learned from a webGL prototype to unity.

It took things a little too literally, which is also how I ended up with an Eastward sunset at first. When I asked it to fix that, I hadn't realised that it's solution was to essentially reverse coordinates and world understanding.

Now, this stemmed from a lack of understanding or review of the 3D code, it's a vibey hobby that I'm using to learn what really goes into rendering a scene.

Had I been a professional, I would have absolutely caught that error ( and many others ).

So being professional would have helped reduce token expenditure massively, firstly by slowing down what could be done to leave time for review, but secondly and perhaps more importantly, by avoiding it getting into a state where it thrashed away for an hour trying to solve an impossible puzzle because the base assumptions were wrong.