2 posts tagged with "ai-engineering"

Tokenmaxxing now gets the hangover treatment. A few months ago, the same behavior looked like aggressive AI adoption. Now the press writes the behavior up as runaway cost. Pylon's bill jumped into enterprise pricing. Fortune called tokenmaxxing a bad ROI metric. WSJ covered the companies that treated tokenmaxxing as survival. Satya Nadella admitted that the habit is addictive.

The obvious lesson: tokens are not output. A leaderboard that rewards the person with the most burned model context is a speedometer on the wrong machine. The leaderboard tells you that activity happened. The leaderboard does not tell you whether the spec improved. The leaderboard does not tell you whether the code survived review, or whether the next run got easier.

But the opposite lesson is also wrong. "Tokenmaxxing is dead" becomes nonsense if the phrase means "stop spending frontier tokens." The useful version is narrower. Spend the expensive tokens where the tokens improve the harness, not where the tokens become the scoreboard.

A few weeks ago, I read Every's compound-engineering guide. The guide gave a name to a practice that I had built without a name. That discovery deflated me a little. The guide states the core idea: "each unit of engineering work should make subsequent units easier—not harder." Most codebases drift the other way. Each feature adds complexity. The more you ship into a codebase, the worse the codebase gets.

I read the line and thought: that idea is the entire point of the harness. The idea is not a feature that I should add. The idea is the constraint that already shapes each file in the harness.

This post is about a concrete, working instance of compound engineering. The post skips the abstract philosophy. The post shows the files that make the idea true. The post also shows the documented failure modes, because I want to be useful, not breathless.