So today, I'm going to talk about "tokenmaxxing", which is this stupid new idea that programmers should max out the number of tokens they use every day, or if not max them out, at least use as many as they possibly can, and that any programmer who doesn't max out their token uses isn't being as productive as they should be.

Jensen Huang, from Nvidia, who makes more money on AI than any other company, was on the All-In podcast on March 19th, saying that he would be alarmed if an engineer wasn't using enough tokens, and then March 20th, an article from The New York Times popularized the idea of maxing on token budgets, and then on March 23rd, the most prestigious venture capital firm, who is HEAVILY invested in the AI bubble, published a letter, quote, "to software CEOs, founders, boards, and the investor community," unquote, called, quote, "There are only two paths left for software," unquote, in which they push the idea of AI-driven developer productivity.

Some companies are even putting up leaderboards to show which programmers are burning through the most tokens. Now, I have no hesitation in saying that's an incredibly counterproductive way to incentivize for real productivity. It's just yet another, and arguably the worst, attempt to turn programmers into micromanage laborers with no agency or opportunities for creativity I've seen in 30-something years.

"Not all code is good code." In fact, some code is bad code, in addition, with the exception of code that's so bad it should never be used under any circumstances. All code quality is situational. Code can only be good if it does what needs to be done in the situation in which the code is called.

And that's one of the most crucial and most difficult parts of writing code: anticipating all the different conditions under which the code being written might be called, what the right thing to do is in each of those situations - in coordination with all the things being done in that situation by all the other code around the code currently being written - and then doing all that while keeping in mind that there are people out there, often referred to as hackers, who will intentionally try to force your code to encounter malicious situations so they can try to take financial advantage of what it does wrong. Under no circumstances does writing more code faster make that process any easier or better. In fact, quite the opposite.

Counting the lines of code a person or team writes in a certain period of time is a very easy thing to measure, so people often use it as a metric. But it's a horrific measure of productivity. Because to do that correctly, lines of good code should add to your score, but lines of bad code should be deducted from your score, but there's no easy way to tell what lines of code are which.

Another attempt at metrics are "story points" or "t-shirt sizes" or "planning poker" or whatever crap method you use to try to estimate the size of a piece of functionality. It does, I guess, approximate productivity better than just counting lines of code.

But "tokenmaxxing", it's literally the worst metric for measuring good programming I've ever heard of. Goodhart's law tells us that when people start being judged based on a metric, it ceases to be a good metric because people will game the system. But with this nightmare, the more people game the system, the more companies who are pushing the metrics have to pay their AI vendor, which I guess is great revenue if you're the AI vendor, but not so great for everyone else's finances though.

So some of the earliest companies who are reported to be doing this, like Meta and Shopify and Amazon, are probably pushing this metric for purposes of training their in-house AIs. In theory, if you could take the output of your AI and then track how that output gets refined and changed as it gets used in the real world, and then add that tracking and change information back into the model, that could become good training data.

Now there's a bet there: Those companies are betting that the pain caused by the bugs that your current customers are feeling now because of the slop that your current AI is pushing to your production environment will be smaller than the gain that you get later from having better trained models in the future. I'll be honest, it sounds like a bad bet to me, but time will tell.

Now some other companies aren't training their own AIs, and they're doing it because they aspirationally mimic everything that they read about the big companies doing, without having a clue as to whether the reasons the big companies are doing it apply to the smaller companies or not.

And what was REALLY fun was when idiots just wrote a bunch of code they never actually ran and stuck it in the code base without ever calling it just to get credit for the lines, which often leads to some other idiot assuming that that code - since it's in production - works and either copies it and pastes it in somewhere else or calls into it expecting it to do what it says it's going to do.

So a quick word of advice, don't ever, ever ship dead code. The largest amount of real money ever lost to a bug, $440 million, was because a code hidden behind a feature flag that was not supposed to be run, but there was a bug in the way the feature flag was implemented. It's the 2012 Knight Capital Group meltdown.

The answer is to allocate time on every code change, especially bug fixes, to be spent looking back at the code that was changed and deducting the value of the current bug fix from the metric score for the original code.

Now people hate this. First off, management hates it because it means that everything takes more time. Programmers hate it because it means more paperwork time and less programming time. But the exceedingly rare people that do manage to do this "looking back" exercise, those people learn incredibly valuable skills that, in my experience, just can't be taught or learned any other way. And those skills certainly can't be learned by "tokenmaxxing", and the AI has no chance of learning from any kind of such exercise.

Personally, I expect the "tokenmaxxing" fever will die off. I've already started to see reports of companies complaining about how expensive it is. The question is, "will the fever die down before or after the AI companies use the revenue they get from it to prop up their IPO paperwork?"

These upcoming IPOs, starting with the Frankenstein X.AI and SpaceX conglomeration in a few weeks, are going to be a Groundhog Day event for the AI bubble. There are others, including the financial irregularities going on between Anthropic and X.AI, the way that NASDAQ is changing its rules right in time for the series of IPOs. Please at least remember that the Internet is full of too many bugs already, and anyone who says different might well be trying to sell you their new IPO.