charles leifer | Tokens and Dreams
//charlesleifer.com
/blog
/code
/resume
Tokens and Dreams
June 16, 2026 15:04
ai
thoughts
0 comments
The one great principle of the English law is, to make business for itself.
At work we were talking about metrics. Well, they were talking about metrics,<br>and then when they realized they had none, they asked me to generate some. I<br>spent an hour or so putting together a script that pulled all the relevant<br>historical data from our database, cleaned and normalized into a CSV. Then<br>I fed the CSV into AI. With only a sentence or two of prompt, AI extrapolated<br>meaningful signals, produced no less than 5 graphs, and correlated the data<br>with external market signals which were not explicit in the data-set. It also<br>built a polished interactive dashboard. A dashboard! A dashboard! I've said<br>it in my head so many times I don't even know what it fucking means. Dash<br>board. But I know this: Everyone wants dashboards. AI knows it, too.
Around this same time, I was doing more AI coding experiments. I'd been stuck<br>between the hype, the Big Fear, and the mundane reality of trying to get AI to<br>write good code. I wanted to understand what was real and what was not. My<br>detector has been giving me conflicting signals. Given the exact same prompt and<br>inputs, one run of Claude goes in a wildly different direction than another.<br>Junk gets confidently asserted as not-junk, and then when corrected, the model<br>just as confidently asserts that it was, indeed, junk all along. A turn or two<br>later it's right back at it. Memories of preferences ("don't you even THINK<br>about committing code") get forgotten in the whirl of tokens. em-dashes appear. Tangles of weedy code spread with each iteration, and<br>need a vigorous hand-pruning to keep things clean, because the show must<br>go on. Even special workflows dedicated to reducing sprawl tend to come back<br>with gems like "X cannot be refactored because Y is load-bearing ."
Load bearing. My inlaws have a lake house down in the Ozarks, and there was<br>this 4" metal pole in the basement underneath a support beam. My father-in-law<br>hated that pole because it was right in everyone's way when going out to the<br>dock. I'm not sure how he determined this, but one day he decided that it was<br>not load bearing, and he removed it. We spent an anxious night that night in<br>the basement bedroom wondering if we'd be awakened by unborne loads coming down<br>on top of us. Thankfully, he was right, or more accurately, right enough.
Claude and the boys sit down to write me some code.
The evidence is puzzling. When<br>someone's daily experience of AI is of the dashboard variety, the hype seems<br>real (and with it the concomitant Fear). Yet I continue to find myself in this<br>no-mans-land of yeah, AI is legit for some stuff, but it also sucks at some<br>stuff. When pushing back against a hype claim that landed in my Slack DMs, I<br>find myself constantly wanting to attach a disclaimer: "No! I embrace these<br>tools! This is not thinly-veiled self-preservation, just hear me out!" And then<br>I want to attach a sub-disclaimer to that one that says "(well, actually it<br>is, but just not in the way that you think)". But Slack doesn't have a<br>disclaimer and sub-disclaimer feature yet. It'd be nice, given that silver<br>bullets are absolutely raining down these days. I sometimes find myself<br>wondering, with resignation, do I just need to take the leap of faith and<br>submit to the swarm of agents and markdown files? Let go, and become machine?<br>But no, you all know me better than that.
The map is not the territory.
Brooks' Tarpit and Agentic Quicksand
In his essay No Silver Bullet,<br>written 40 years ago, Fred Brooks argues that the difficulty in shipping<br>software has never been the code-writing. Instead it's the inherent,<br>irreducible complexity of the problem itself, which the software is designed to<br>solve, that makes it so challenging:
The essence of a software entity is a construct of interlocking concepts: data sets,<br>relationships among data items, algorithms, and invocations of functions. This essence is<br>abstract, in that the conceptual construct is the same under many different<br>representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing<br>of this conceptual construct, not the labor of representing it and testing the fidelity of the<br>representation.
For proof, I'd point to the fact that, even with 40 years to develop<br>best-practices, modern languages and incredibly advanced code authoring tools,<br>we're still drowning in buggy, bloated software. Subjectively, it seems to be<br>getting worse.
It's just teamchat, bro.
Who manages this complexity, nowadays, besides the programmer? At best, it is<br>encoded in rigorously-updated design docs. More usually it exists in obsolete<br>documentation that one go-getter wrote a couple years ago and never touched<br>again, poorly-normalized database schemas, and perhaps some code comments...