---
title: It was MDF all along.
description: The output was always MDF. What LLMs changed is who signs for it, and which engineers survive that. On productivity, accountability and picking a lane.
author: Zander Rootman
tags: [ai, llm, engineering, productivity, careers]
draft: false
---

This is Eval Geniuses' first article. For over ten years we've operated from the shadows, as if we were some exceptional engineering hit squad.
I think that was a little foolish on our part, not only for our business but more so for the rest of the industry.
Some of our personal heroes regularly dump their opinions on blogs and mailing lists, yet we somehow thought we were above that.

I think it's time we stopped. Whether our opinions are correct and our reasoning is sound is now up for public
discourse, but I'd rather be proven wrong than not join the conversation at all.

The current state of AI has the world in a flat spin, and people in our industry more than most. I've personally heard higher-ups
in companies that move entire industries casually say that junior and mid-level engineers are done for. The entire job market
seems unsure of which way is up and which way is down. And maybe a small percentage of this article is cope.
The idea of turning natural language into software has been attempted before, and every single time engineers have had to step in.
In 1981 James Martin published a book called [Application Development Without Programmers](https://en.wikipedia.org/wiki/Fourth-generation_programming_language).
The 4GLs it championed were sold as English-like tools you could [learn in two days](https://www.computerworld.com/article/1351806/update-4gls.html). The programmers stayed.

We've advanced quite a bit since then.

So let's talk about it.

## The problem we want to solve.
Engineering is expensive. Almost anything worth doing in software takes time, and time is the one truly finite resource for
individuals and companies alike. Shareholder expectations and hockey-stick economics aside, productivity will always be output over time and effort.

```text
                Output (the thing we want to build)
Productivity = -----------------------------------------
                Input (time and effort)
```

Year over year we produce better and better stuff for the same time and effort spent.
But that was not enough. Thanks to LLMs and agentic coding, the claim is that output has now tripled, sometimes more, for the same time and effort.

In theory this sounds good. One engineer can now do the job of three. We've lived with this claim for three years now.
Has productivity really tripled?

Not according to anyone who's measured it. The pitch comes from GitHub's own [2022 experiment](https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness),
where developers with Copilot finished a toy HTTP server 55% faster. [METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) ran a randomised trial in 2025
on experienced developers working in their own large repos: they took 19% longer with AI tools, and afterwards still believed they'd been 20% faster.
The [2024 DORA report](https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report), across 39,000 respondents, found that more AI adoption came with slightly less delivery throughput
and a 7% drop in delivery stability.

Productivity was never held up by how quickly you could ship code (we all know this), nor by how good the code was
(although there's something to be said for that). Productivity was held up by something else entirely.

Trusting that the code you're about to ship won't bring down an already fragile ecosystem. Taking responsibility when it inevitably does.
That's what held features back from shipping. It was the senior engineer going over the smallest conditionals, questioning reality before it ever worked its way into CI/CD.
It was the reviewer holding the front line, painstakingly reading every line of code, refusing to ship to meet a deadline, knowing exactly whose shoulders it would fall on.
It was the quiet mid-level engineer second-guessing whether to say anything when he recognised a CVE, because how could a senior miss this?
It was that one product owner who sheltered his team from the fallout of a missed deadline, because the team wasn't happy with the current state of affairs.

Productivity was never held up by speed or quality. It was held up by someone willing to put their name on it.

These unsung white-collar heroes didn't hold the line for mission-critical systems at NASA or Lockheed Martin. They held it for the
payment feature that lets a user enter some silly digit or pick an amount from a drop-down menu. They held the line for
a new and improved search function that let users scan through their emails. Whether these features shipped tomorrow or a week from now only hurt the
ego of the exec or project manager who had made ambitious promises.

Yet they did it. They treated the product with all the sincerity and seriousness they could muster without it becoming silly.

Not all of them were heroes. For every reviewer who stopped garbage from shipping, there was one who just stopped things, for his ego's sake.
The difference was never who slowed the work down. It was who paid when they were wrong.

They slowed everything down to improve the output. The output was no better than what we're shipping now.

We think we traded our hand-crafted French oak desks for mass-produced Ikea MDF desks and called it progress.
MDF, if you've never looked under the vinyl, is sawdust and glue pressed into a board, with a photograph of wood grain stuck on top.
But it was MDF all along. What we actually traded was the carpenter for a CNC machine.

The truth is, a lot of software is mundane and not as serious as we make it out to be, and our new CNC machine is cutting through the bullshit.
No longer is the senior who forced the entire company onto his ORM (the one on its seventh refactor that quarter) venerated as an "unsung genius".
No longer are you celebrated for writing basic conditionals, or for lifting something from Stack Overflow and claiming it as your own.

This feels horrible, because our egos are hurt. Every programmer, when starting out, has the ideal in their head:
solving complex problems, mastering the machine, writing bespoke software that does something out of this world.

The carpenters who survived the industrial revolution fall into two camps:

1. The venerated artisan.
2. The industrial designer.

The artisans who produced art remained artisans. The CNC machine didn't touch their demand, because nobody buying a hand-cut oak desk was ever going to buy MDF instead.
Carpenters who thought they were producing art, but were in fact hammering and gluing tables together from scraps on the cheap, were the early Ikeas, and they were quickly replaced by industrialisation.
The carpenters who knew they were Ikea used their knowledge of material and design to produce more of what they were already making, and became the industrial designers.

And so the illusion of the ideal programmer breaks. You were never the 3 a.m. coder writing a lock-free allocator, or tracing a TCP packet across seven time zones and five data centres.
You've spent the last twelve years abstracting a database so users can post cat pictures and the lyrics to their favourite songs.

## Where we are now.
Unfortunately, that's exactly what progress looks like more often than not. It doesn't fill the world with more beauty and excellence;
it fills the world with more junk. We only have to look at the Great Pacific Garbage Patch to know where AI is headed.
The problem isn't that plastic is cheap. It's that plastic is never owned by anyone, so it ends up in a landfill (or the ocean).
Plastic owned by someone is recycled, reused or stored for safekeeping. If every piece of plastic carried the signature of the person who dumped it,
with a way to trace it back to them, there would be no plastic in the ocean.

Most people are fine spending a little money on something that will last a handful of years at worst and
can be replaced by spending a little money again at some point. Software should be treated the same. Consumers
decide the trajectory of an industry, and consumers want more Ikea.

But this leaves us in an awkward spot: engineers are still needed to build both the good and the bad stuff.

LLMs and agentic coding can turn natural language into products, but the people who want specific products aren't really able to articulate
exactly what they want. At the end of the day the "product owner" asks an engineer to interpret what they want and feed it
to an LLM to interpret what the engineer wants, and a lot of the time it actually works. As long as it's Ikea.

This year alone we've shipped three products for three clients that were heavily AI-assisted, for a fraction of the cost.
And when I say a fraction, I mean five to six times cheaper. We shipped five to six times faster, and fewer hours
meant a smaller bill for the client. That's a good thing. These products weren't in any way, shape or form complicated,
but they did require a lot of coding, interpreting and back and forth with the clients. All three clients are happy with what they got.

And I think that's what scares people the most. It works. For Ikea, but it works. You no longer have a base rate for an iOS and Play Store app;
you now estimate how much time you're going to spend fighting an LLM and bill the customer for that.
The apps are also simple enough that when an LLM runs out of its depth you can jump in and resolve it by hand.

This is awesome for engineers and companies who make money writing software, but an absolutely horrible thing
for the people selling software products. Software being expensive and laborious kept competitors at bay. Being first to market
meant having a real edge; today, it's a worked example for an LLM of what to do and where to improve. The cost of ideas and of building them
protected the very companies championing AI, and they don't even realise it.

Engineers are worried that their role in producing products is being reduced, and a lot of companies would like to sell you that idea,
but in our experience that's not the case. Your job is more threatened by recessions, inflation and prime lending rates than by any new frontier research lab.
The last layoff wave tracked [post-pandemic over-hiring and interest rates](https://www.washingtonpost.com/technology/2026/05/01/ai-jobs-tech-layoffs-austerity/) far better than it tracked model releases.
What's actually happening to your average software engineer is a big ego check:
are you the artisan or the industrial designer? Those who fail to choose end up losing their jobs.
Macro decides when it's time to cull. The machine decides who goes. Low-effort engineers are first in line.

An engineer will always be needed: to guide, to ideate, to take responsibility and to resolve issues, no matter the level of agentic LLM usage.
Companies that cut staff to balance out the productivity gains from LLMs are kneecapping themselves.

A magic fairy came along and gave companies a wand that tripled their productivity, and instead of producing more,
they admitted they were creatively bankrupt and laid off as many people as possible while keeping the wheels turning.

These companies pretended for the last two decades that they were the French oak artisans of the software world, but have revealed themselves
to be Ikea. Now that the curtain has fallen, many more Ikeas are coming.

## Where we're headed.
A world of Ikeas might sound like a horrible thing, but it's not. And let me state the following for the record:
Ikea is awesome. I have no hate for Ikea, and Ikea doesn't sell itself as a premium supplier. It knows what it is, and it fills a specific need.
Ikea is also just an example. There are plenty of Ikea copies and other companies trying to replicate the model; almost every desk is MDF and
vinyl, or particle board with melamine paper pasted onto it.

But therein lies the beauty: CNC and particle board didn't make the carpenters doing the difficult work obsolete, and turned the honest ones into industrial designers.
Something was lost: almost every house interior now looks the same. And life got cheaper, in every sense of the word.
I don't think that's a good or a bad thing, just a thing that happens when we progress.

So that's where we're heading: not to a world where engineers are worth nothing, or paid less, but one where the output of their effort
is no longer signed off by them personally, where stakes are diffused by LLMs and accountability becomes more abstract.
Yeah, that sucks, but it doesn't mean you have to stop owning the work you put out.

Sometimes the best products are born from the ashes of a thousand slop products. Engineers who've had enough of relying on
LLMs to produce mediocre code will write something by hand that can stand the test of time. Other engineers will master
leveraging AI to turn out Ikea products with speed and reliability. And the few artisans who remain, the ones doing frontier work and writing the standards
the rest of us build on, will still be hired to produce better code for us all to consume. LLMs help there too, for now mostly as research tools.

## What that means for you.
Pick a lane. If you want to be the artisan, put in the work and learn the challenging stuff. You and I both know the barrier between
a PM asking you to write a CRUD controller and you writing it is a couple of weeks of Codecademy, not intelligence.
And it was never the stuff you wanted to do anyway. Spend your time solving the hard stuff by hand.
If you want to continue being paid well, learn how to leverage LLMs and agentic coding to your advantage, or become a true specialist
in a niche that's difficult. Aiming for the low-hanging fruit produces low-hanging results.

Make no mistake, I'm not encouraging vibe coding. Write the first service layer yourself, then ask an LLM to fill in the blanks.
Write the testing framework yourself, then ask the LLM to write more test cases, but write the edge cases yourself.

The only time an LLM replaces you is when you weren't putting in the effort to begin with.

If you're only starting out now, don't panic. Instead of letting LLMs write for you, let them review for you. Still do everything by hand,
bust your brain as much as you can, and probe an LLM to question your logic. LLMs can be great learning tools if leveraged correctly.
Once you start relying on them to code for you, the output of the LLM is going to reflect your ability to code.

Unfortunately, learning on the job is now a little harder; you're going to have to spend a lot more of your free time studying and practising.
And honestly, that's what every great programmer did. They became absolutely obsessed with the craft or a problem, and let it consume them.

And then they put their name on it.