LLM Lumberjacks

2026-02-14

With the rapidly growing development and use of LLMs I wanted to write down some thoughts on a certain perspective I have on LLMs as a coding tool.

Amplifier Analogy

In the many LinkedIn posts written on the topic I have seen a couple of posts where people make the comparison of LLMs as microphones/amplifiers. Where the LLM is only going to produce a quality of result equal to, at most, the quality of the input. A common trope of "trash in/trash out"

Though this is an ok analogy to get the point across that using an LLM is not as simple as "Build me x", I don't think it's exactly matching of how LLMs function, currently as of writing.

An LLM is not simply taking the work input and amplifying it to produce an output, comparing it to a microphone and a speaker, talking into the microphone produces a louder (amplified) sound out the speaker.

The LLM is performing work based on the input and doing so based on probability. If the input is asking for a website to be built, there is a high probability they want to see HTML/CSS/JS structured in specific ways. A good prompt is one that tussles with these probabilities to get a much more accurate output. Even if that's simply stating "Build it primarily with python"

A potentially better analogy that remains within the same genre would be more akin to the entire workflow of AutoTune. If you provide any person with a microphone, some autotune software and some speakers, the output is going to sound "better" but as mentioned in an old interview with Kanye West, it's something used by people when they can't sing but for Kanye it points out his bad notes and makes him have to sing better. This is fitting for LLMs as it enables people to develop in ways they couldn't before but it still requires effort in order to make something great and though I could continue with this analogy, the one that stuck with me the most is comparing LLMs to a lumberjack's tools.

An LLM Lumberjack

A lumberjack uses an axe, this axe takes skill. You don't just hack away at a tree, there is a method to it. You have to use the right axe for cutting a tree vs splitting a log. You need to have the strength and endurance to lift, swing and remove the axe. Knowledge is needed for how certain tree woods behave, how and where to swing into the tree to get more efficient chunks of wood out etc. etc.

A chainsaw speeds up the process, and in some ways changes the process and even the end goal, but you still don't just take the chainsaw and start cutting into a tree as the tree will collapse on the chain and jam it. That's even before you've started up the chainsaw, which depending on the type could have different startup and maintenance mechanisms.

Regardless of the pros and cons, there is still skill to a chainsaw... though significantly different skill to using an axe.

Even then, the chainsaw doesn't remove the need for an axe for a lumberjack and it also doesn't mean a lumberjack won't decide to exclusively use an axe should their situation allow it or even call for it. Plenty of hour long YouTube videos show the market for individuals crafting their own house of lumber using older methods.

The Real Challenge Isn't Just Code

Regardless of the analogy used, I think these analogies are helpful as coders since it helps navigate the hype based marketing going on. There are so many adverts suggesting that we are at a point where anyone can pick up a project and develop something without writing any code. These ads imply the challenge came from the code itself, and though the ability to program is one of the largest hurdles with development, it's not at all the only one. Going from Assembly to C abstracted away machine code and tools like game engines meant you could focus on the gameplay development without needing to touch rendering APIs.

LLMs have changed the initial language to English and have made the process quicker but there is still a lot of knowledge required in order to use them effectively.

My Experience with LLMs for Coding

For me personally, LLMs do in fact lower the barrier for entry in terms of both technical skill and time. Enabling me to produce output that I otherwise wouldn't be able to due to skill or because I don't want to dedicate the time to learn. i.e. frontend development (as seen on this blog). But my ability to use them has increased over time and a portion of that has been due to an increase in my software engineering skills allowing me to create more finely tailored prompts and sound architectural decisions.

It's going to be interesting seeing how things evolve as things go on. Especially with how fast the industry is moving.