Tool Lust is a Solo Act

In 2009, film critic Roger Ebert reviewed the movie Fanboys and embedded a paragraph so sharp it still circulates today. It was not about the movie. It was about the fans themselves.

Ebert's observation cut through pop-culture obsession. Star Wars devotees who camp on sidewalks for premiere tickets. Trekkies who can recite every line of every season. His point was surgical: these people are not really into the movies. They are into the camping. They are into the fandom itself. The object of obsession is mainly a backdrop for their own devotion. Fandom becomes a security blanket. If you have memorized every piece of trivia about your chosen universe, you never have to know anything about anything else.

Seventeen years later, browser engineer Andreas Kling, the mind behind the Ladybird project, took Ebert's template and swapped the nouns. In a post on X, he aimed the same indictment squarely at software. A lot of programmers are fans of programming itself. They have mastered Rust, Haskell, or Zig. But the languages are mainly a backdrop for their own cleverness. Anyone who spends six weeks rewriting a working system in a new language just to make the types nicer is more into the rewrite than the product. The language is not the point. Shipping is the point.

I watched a game developer read this aloud on stream recently. He builds a tower defense game and broadcasts the process. He read Kling's post, paused, and admitted he felt personally attacked. He had just rewritten his project from Lua and the Love 2D framework to Odin. His defense was practical. Lua pushed most errors to runtime. Bundling Love 2D into a single cross-platform binary was a nightmare. Odin caught the same mistakes at compile time, and bundling across Mac, Windows, and Linux became trivial. The rewrite had engineering justification.

But then he drew a line he would not cross. A second rewrite, from Odin to Rust, would be indefensible. He called it exactly what it would be: type masturbation.

That moment of self-awareness is where things get interesting. He acknowledged the whole thing was a meme, a copy-paste joke. But beneath it was a question he had been wrestling with for months. There used to be an era where your job was to scrutinize every line of code to the nth degree. That world made sense. Then it fractured. Now there is a class of software you build at the 50th percentile of care, and another at the zeroth. The hard part is knowing which one you are in.

He admitted something that does not get said often enough. He is not good at the interface-only world. The idea of caring only about what a system exposes, trusting what sits behind it without inspecting, does not come naturally. He finds it genuinely difficult and does not know how to get better at it.

This is the tension the AI era has surfaced and sharpened. When half your code is generated by an agent, scrutinizing every line becomes unsustainable. But trusting the output and moving on feels like negligence. He pulled up his agent logs on stream. For roughly sixty lines of code, there was a mountain of back-and-forth. He spent more time talking to the agent than writing the code by hand. The point was never speed. It was convenience. He could pull weeds in the garden while the agent shaped things toward his intent.

This is not laziness. It is a different kind of engagement, where the developer becomes editor and reviewer more than writer. But it asks a question Kling's original post was gesturing toward. Can you care about the details while the agent loops on its own output? His hypothesis was no. Autonomous iteration and detail-level care are fundamentally at odds. If the agent is looping, you are not scrutinizing. If you are scrutinizing, it is not a loop.

He is trying to build his own looping harness. A system where an agent iterates on its own code and produces something usable. Can the loop produce good code? Big projects? Passable code that meets a real need? Code quality is not the only form of value. Something ugly inside that you actually use beats something elegant that never shipped.

This is where the loop brings you back to the fandom question. The trap is not caring too much about code. The trap is making the tool the point instead of the product. If your relationship to a language or framework is primarily about how it reflects on you, how clever it makes you feel, how it signals membership in a tribe, then you are a fan, not a builder. The compiler does not care how clever you are. Neither do your users.

The game developer ended with a reflection worth keeping. Most voices online are just telling you how to do things. Very few are trying to prove themselves wrong in public. The process of being wrong and correcting course is the work. Everything else is just fandom. And fandom has always been a solo act.