John Hacker's Hammer

There’s no ignoring it - LLMs are getting much better. As a reluctant purist¹ who still adamantly refuses to include anything but human-written code in my data pipelines, I recently bit the bullet and subscribed to Claude Code for a month for personal use.

At first, it rocked my world. With two Anthropic badges² under my belt, I had an excellent grip on the function and capabilities of the latest LLM tech, but had yet to test it myself. For a week or so, I was obsessed, running projects on my personal machines and the cloud VM³ during every waking hour. I became the quintessential and loathed vibe architect (sans Twitter account,) and built out several projects in those two weeks, maxing out my usage each time and learning lots.

This was where I encountered the first of several problems, the largest of which was several thousand lines of code to review - and I didn’t trust a single one of them. The unit tests passed, but the cognitive load of double-checking the very verbose codebase made it essentially impossible to review in the time I had. Even though work appeared to get done, there was no way to verify that it was secure and correct without combing through, function by function.

As I looked at the work more carefully, I realized that the language model had been applying spot-fixes rather than stepping back, assessing how the entire problem had changed, and then mutating the codebase to fit the true shape of the problem. Instead, it had been patching small parts with additional functionality - growing the codebase exponentially beyond the scope of the problem. Solving it excessively.

These problems also plagued me at work, but from the other side, looking towards operationally maintaining a codebase that had grown so fat that it would take a two-year (programming) diet to slim it down into the shape of the actual problem.

From this standpoint, slow thinking and writing seem more like a feature than a bug.

From all of these problems, two big questions came to mind:

1. To keep people sharp, how can we ensure people must do the thinking and LLMs can optionally do the work, so we can continue to understand what we are building?
2. How do we design programming languages for both people and LLMs that minimize repetition, enforce contracts on data, and output minimal and concise solutions to the given problem?

Most of all - how do we survive the advent of LLMs without becoming plumbers?

To begin answering these questions, we need to step back into the past…

John Henry, a Folk Legend¶

People fighting with new technology is a tale as old as time. Back in the 1870s, steel driving was how railroad tunnels were cut through rock. A heavy hammer was used to smash a series of steel drill bits into the rock, forming a hole. Eventually this hole would be filled with dynamite or nitroglycerin and blown up.

The legend goes something like this:

1. John Henry is a steel driver, one of the best
2. A steam drill is rolled onto his worksite
3. John Henry challenges the steam drill to a race
4. He wins, beating out the steam drill
5. He collapses from the toll this took on his body

Famously, Johnny Cash included this folk song on one of his records with the title “The Legend of John Henry’s Hammer” . It’s a great tune, and it’ll get stuck in your head if you aren’t careful!

The song poses some key questions about the tireless march of technology:

John Henry said, “I feed for little brothers
And baby sisters’ walkin’ on her knees
Now did the Lord say that machines ought to take place of livin’?
And what’s a substitute for bread and beans? (I ain’t seen it!)
Do engines get rewarded for their steam?

John Henry said to his captain said “A man ain’t nothin’ but a man
But if you’ll bring that steamdrill ’round I’ll beat it fair and honest.
I’ll die with that hammer in my hand but, I’ll be laughin’,
‘Cause you can’t replace a steel-drivin’ man.

John Hacker, the Everyman¶

What can you, John Hacker, learn from the story of John Henry?

First off, let’s not collapse from exhaustion and die trying to fight the new technology. Pandora’s box has been opened, and there isn’t a lot we can do to close it again. We must live with the advantages and suffer the drawbacks of living in a world with LLMs. If we still want our bread and beans, we’ll need to learn to use these as tools and leverage them for ourselves - not to ignore them as they push us aside.

Secondly, we need to remember that this technology does make us measurably more productive in the short term. Data engineering work in particular is accelerated due to the ease of generating one-off scripts to produce transformed data, schemas, and tools. Just like with the steam drill, the employer wants maximum productivity, and language models certainly deliver this in the short term.

“When CLT is managed well, users can engage more thoroughly with a task without feeling overwhelmed.⁴ LLM users are 60% more productive overall and due to the decrease in extraneous cognitive load, users are more willing to engage with the task for longer periods, extending the amount of time used to complete tasks.⁴” ⁵

Finally, we understand that our employer does not primarily have our wellbeing or self-development in mind - they just want the work done, and are beholden to the same propaganda as everybody else. IBM committed to tripling entry-level hiring in 2026 after overestimating the growing capabilities of language models.⁶ The industry as a whole will continue to pivot and make mistakes with this rapidly evolving tech until they find a fit.

Unfortunately the largest cost of leveraging language models is personal and comes to rest squarely on your own shoulders. Racing against the machine may be a fool’s errand in some ways, but giving yourself an unwitting lobotomy is the alternative.

“While lower cognitive loads often improve productivity by simplifying task completion, LLM users generally engage less deeply with the material, compromising the germane cognitive load necessary for building and automating robust schemas. Students relying on LLMs for scientific inquiries produced lower-quality reasoning than those using traditional search engines, as the latter required more active cognitive processing to integrate diverse sources of information.

Additionally, it is interesting to note that the reduction of cognitive load leads to a shift from active critical reasoning to passive oversight.” ⁵

To sum up the downsides of unthinking LLM use:

1. You don’t know what you’re writing
2. You are writing a lot of it
3. You aren’t learning or using your brain

Swing John Hacker’s Hammer¶

The silver lining is this: a hammer is a tool, and a steam drill is a tool. An editor is a tool, and a language model is equally a tool. We should be thankful that the replacement for our current tools is an even better set of tools that we can easily upskill to. The only sound way forward, in this hacker’s opinion, is to learn the tools, and learn when to use them. Overreliance on language models builds awful cognitive debt,⁵ a lack of thinking that the user is putting off, potentially forever. Common sense can’t be taught, and LLM overuse seems to cause brain atrophy, making you lazy and shortsighted. In this way, it could easily be compared to amphetamines with parallels to the productivity gains, profiteers, and side effects of the drugs.

“Perhaps one of the more concerning findings is that participants in the LLM-to-Brain group repeatedly focused on a narrower set of ideas, as evidenced by n-gram analysis […] and supported by interview responses. This repetition suggests that many participants may not have engaged deeply with the topics or critically examined the material provided by the LLM.” ⁵

Another silver lining is the present shortcomings of language models which can write piles and piles of code that work for a while, but can’t assess a problem the same way a flesh-and-blood programmer can.⁷

Continue to sharpen your programming skills and advocate for small, purposeful, functional systems. Without doing so, you and everyone around you will lose a grip on what these systems actually do, and will be at a loss when you attempt to debug them, even in an assisted manner.

In a few years I bet we’ll see operations teams crushed under the weight of the huge codebases being vibe-coded today. At that scale, only models from the frontier model labs will be able to deal with the nightmarish scope and complexity.

“You have a human programmer do it who’s good and an AI do it - and the AI will give you a lot more code. Just like the mathematical proofs would be a lot longer than if a real mathematician had written the proof. Sometimes ten times longer, a hundred times longer. And then that extra code is all technical debt that you have to deal with in the next iteration, right? The extrapolative thinking just says, well, the AI will deal with it. Yeah, it’s more of this stuff, but then it just goes in the AI. The AI understands it. Well, if the AI isn’t God at this time, then there is a limit to how much it can do.” ⁷

– Jonathan Blow on “The Students” Podcast

A Next-Generation LLM Language¶

I’ll be honest - this section is just an excuse to talk about Elixir, a beautiful functional programming language written for the BEAM VM, originally built for the Erlang programming language. Crucially, Elixir allows the definition of the data shape right in the function arguments, dramatically reducing error handling logic.

# Simple pattern matching:
{ hand, rest_of_deck } = Cards.deal(Cards.create_deck, 5)

# Pulling data out of structs!
def pick_color(%Identicon.Image{hex: [r, g, b | _tail]} = image) do
  {r, g, b}
end

There are a number of other key features that make it perfect for language models and humans alike. The actor model lends itself to breaking programs apart in a way that LLMs would do better with: smaller, lightweight, isolated programs with limited purpose passing messages to one another. Elixir is functional and uses immutable data structures making data flow much easier to reason about and write.

Looking Forwards¶

As developers, let us continue to learn the tools while acknowledging and mitigating the risks of language model use. If you want to have full confidence in the code you are writing, deeply understand the machine and write it yourself.

Despite the claims of Boris Cherny,⁸ the art of programming is not a solved problem. Not by a long shot.⁷ While language models can solidly beat out cheaters and pretenders, those who treat it like a discipline will continue to come out on top.

Pursue excellence in your craft, understand your systems, and flee from the temptation to lazily phone in your work. The bill always comes due.

Happy Hacking,