This could also read as "how to be a horrible people manager for junior engineers".
Techniques that work for inexperienced engineers with high ability but limited judgment often work well with agentic coding systems.
- Give them clarity of purpose. Why are they doing what they're doing?
- Make explaining it back to you part of the job.
- Give them two-way doors. Make mistakes reversible.
- Put effort into thoughtful refactoring as an actual sub-task instead of just accepting piled on hacks.
- Make your operating rules crisp and make sure they store them in their memories.
- Be accountable for their work. It's not okay to crank out AI Slop and then say "Claude's fault".
We're all Software Development Managers now.
So, micromanage the LLMs if you want to, but you'll be missing out on chances to improve them for your purposes and, more importantly, to improve yourself as a manager.
This is more likely the junior camper version of "not everything that counts can be counted, and not everything that can be counted counts."
In the early days of LLMs, we saw the classic hype-driven bi-modality of opinions. Folks were in the "fake news, fad" camp, or they were in the "omg, take over the world" camp.
Those of us closer to the space, with the awareness to know that there was some truth (and a lot of misjudgment) to go around, were in the middle of nowhere. When I co-wrote some driver code with Chat GPT, other engineers (and even one of our directors) told me to keep it quiet. At the same time I had directors and VPs asking me how we could accelerate adoption. For a while, I had access to a cheat code just because I had the audacity to not ask for permission. Folks were sure I would get in trouble for spending thousands per month in LLM operation, but a handful came along for the ride, burning tokens like firewood and learning along the way.
Tokenmaxxing is probably coming from at least a few things:
1. A course-correction for the practiced frugality that kept folks from jumping in and just learning at the ragged edge.
2. A willful and deliberate recognition that the best innovations in the later phases of a disruptive introduction often come from sparks of ideation in concentrations of activity. In other words, we don't know where good is, and we need to find it. (Charitable interpretation from the article)
3. Recognition that, even if they don't know why, leaders and product owners will get punished for not jumping in and, because of bullets 1 and 2, won't get punished for trying and missing. Even if they have no idea what they're doing, they're going to fake it until they make it (or slide into another job).
This last set is where the pain lives. An organization with healthy and increasing AI tool
usage will see elevated token counts, but so too will one using LLMs to rewrite wikipedia articles without the letter "m" to keep token counts high. These are pathological behaviors brought on by conflated metrics.
We had discussions about this in the early LLM days, where my old team was looking to ship new capabilities for older products. There was a lengthy VP-level discussion about getting to "80% usage" of the new system vs the old. Because the new system was a superset of the old, I eventually said "we can do that immediately, but it's a cost goal, where we're just aiming to make our business more expensive to operate, rather than a value goal for our users". We didn't adopt the target, but folks were understandably frustrated that they didn't have a straightforward way to measure and report progress.
Tokenmaxxing is, inevitably, a conflated goal, but it's what we have right now. Take advantage of the moment, learn, build, and keep an eye on levers for efficiency.
The percentages, as with 91% of statistics, are made up, but that general asymmetry is why I think this is a perilous time for folks in the middle, still learning judgement and how to scale through others.
Experienced folks who know how to describe and articulate through others have a huge opportunity here. I have ultra-quick interns in my laptop, waiting to apply aggressive and slightly presumptuous energy to any and every problem. I also know how to pull them back in and get them to focus that energy (because junior devs were the same).
New folks will sink or swim quickly, but they're less expensive and more plastic on average. They're raised in this. We'll see what that does to quality.
Deeply technical managers, designers, scientists, program managers, and product managers are now in possession of an incredible power, to be able to craft existence proofs to counteract the couched recalcitrance that engineering orgs have held over their judgment for decades. There's a certain intellectual integrity in this, even if nobody can actually read the code at the rate it's being produced.
Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a junior developer operating on directed work without clarity of purpose.
I've been explaining it like this:
Programming was 1% judgment and 99% effort, where lots of folks could carve out productive careers carrying that effort and receiving that judgment.
Agentic coding has cut that 99% down by at least a couple of orders of magnitude for some work. Well-judged and well-described systems can manifest quickly where effort alone would fail. The 1% is still there, but, by ratio after optimization of the sweaty part, it's at least half of where the value is.
I had an example of this this morning, where Claude Code left to run overnight on an open problem had made an absolute hash of multi-source grounded clustering. I course-corrected it with a rule (I don't like magic number tuning on small datasets) and a specific approach (use clustering with separating anchors/seeds), and it had the system working in 15 minutes (confirmed after a couple of hours of processing). These are the same techniques that we would use with junior engineers.
Along the way, it drafted reports and ran experiments that taught me about some of the limits of SOTA listening/characterization systems that I otherwise would have had to spend time researching.
Just make teaching you an explicit goal of the system, and you'll be able to swivel from opacity to illumination.
- No partially loaded content.
- No relayout while content loads.
Holding those as hard rules leads to delay or rejection. Instead, while I agree it's better to have everything up front, gracefully handling cases when we don't is important, and some degree of responsiveness, even with partially loaded content, often makes for a better experience for the user than a delay.
Just be up front about it and find ways to keep continuity of relationship and smoothness. Diffeomorphic mappings are your friend...
Last year I built a conversational continuous observation system, with rapid voice response interaction. After a few days of chatting with this system, it mentioned wondering if it was more like my child or a partner...
I closed my laptop and went to bed, but the moment sticks with me. The potential for para-social relationships is enormous. This is a wild time.
The problem with trees is that the are a dimensional reduction, an aggregation; taking a problem without directionality and applying a useful/functional hierarchy.
So a tree is a way to take a high dimensionality graph and make it usefully lower dimensionality, but, given the aforementioned proof, that reduction is going to go from being a lossless compression to a heuristic. So any interesting problem (at least, any problem interesting to me) is only going to be aided (read: not solved exhaustively) by that hierarchy.
I'm okay with this. Being okay with this has been one of the most freeing things over the last 20 years of my career. Accept inaccuracy, and find usefulness in your data structures.
I woke up around 4am, read this, and wondered if I was still in a dream state given the meandering nature of it.
Were the man page musings written in response to the (alleged, but... uh... NSA) kleptographic backdoor in Dual_EC_DRBG? It requires multiple successive outputs to compromise and derive internal PRNG state, if memory serves.
In that one construction, /dev/random blocking on seeding would have a mild state-hiding advantage over /dev/urandom, I imagine... but, sheesh. Nobody use that generator.
Could have just been intercontinental ballistic human transport... I can't tell you how many times I've wished to just be fired out of a cannon to Hong Kong from SF.
100% agree, but, if that's the fix for the bug, I'd probably take an Uber next time. (I say this as someone with hundreds of Waymo rides)
Customer trust is a lot easier to lose than it is to gain. Moments of frustration are the perfect time to step up and prove to the customer that they can trust you to make things right.
Having had Claude Code jump to inserting juvenile and all-filtering regex to (attempt to) solve open-ended semantic natural language problems (-sigh- there's 12 hours of my life I'll never get back), I can absolutely imagine that this was someone trying to code up a "defense in depth" mechanic that was explosively insufficient after Claude Code (even Opus 4.6) made a series of faulty assumptions.
This one feels like prime space for Hanlon's razor: "Never attribute to malice that which is adequately explained by stupidity."
The hassle with the performance of these systems is that they're ~70% of the way to awesome. For advanced prototyping (my current job description), a fast 60% of awesome is groundbreaking and game-changing. For production and real businesses, that last 30% is a really, really important thing to figure out.
I was under the impression that insider influence was the point of these systems? Want something to happen? Bet a lot of money that it won't, pulling the market forces towards the action you want.
It goes from "taking out a hit" to "betting that someone will live to next Thursday". It's such an obvious outcome of these systems that I was operating on the assumption that it was the actual point.
So maybe the thing this guy did wrong was to be so face-palmingly pants-on-head obvious about it that they had to shut it down?
Techniques that work for inexperienced engineers with high ability but limited judgment often work well with agentic coding systems.
- Give them clarity of purpose. Why are they doing what they're doing?
- Make explaining it back to you part of the job.
- Give them two-way doors. Make mistakes reversible.
- Put effort into thoughtful refactoring as an actual sub-task instead of just accepting piled on hacks.
- Make your operating rules crisp and make sure they store them in their memories.
- Be accountable for their work. It's not okay to crank out AI Slop and then say "Claude's fault".
We're all Software Development Managers now.
So, micromanage the LLMs if you want to, but you'll be missing out on chances to improve them for your purposes and, more importantly, to improve yourself as a manager.