--- 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. author: Zander Rootman tags: [ai, llm, engineering, productivity, careers] draft: false --- This is Eval Geniuses' first article. For over 10 years we've operated from the shadows as if we were some exceptional engineering hit squad. I think that was a little folly from our side, not only for our business, but more so for the rest of the industry. Some of our personal heroes frequently mind dump their opinions on blogs and mailing lists, but we somehow thought we were above that? I think it's time we stopped doing that. 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, more so people from our industry than others. I've personally heard higher-ups in companies that move entire industries casually speak about how junior / mid-level engineers are done for. The entire job market seems unsure of which way is up and which way is down. And maybe there's a small % of this article that's a little bit of 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 chat about it. ## The problem we want to solve. Engineering is expensive. Almost anything worth doing in software takes time, and time is the one true finite resource for individuals and companies alike. Shareholder expectations and hockey stick economics aside, productivity will always be output over time and effort. ```markdown Output (The thing we want to build) Productivity = ----------------------------------------- Input (Time and Effort) ``` Year over year we increasingly produce better and better stuff for the same time and effort spent. But that was not enough; thanks to LLMs and Agentic Coding, 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 engineers. We've lived in this reality for 3 years now. Has productivity really 3x'd? 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), it's also not in how good the code is that you ship (although there's something to be said there). 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 for when it inevitably does. That's what held up features from being shipped. 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 frontline, painstakingly reading every line of code, refusing to ship to meet deadlines, knowing exactly whose shoulders it would fall on. It was the quiet mid-level engineer second guessing whether he should say anything when he recognized a CVE, because how could a senior miss this? It was that one product owner who sheltered his team from the fallout of missing deadlines, 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 system feature that allows a user to enter some silly digit or select an amount from a drop down menu. They held the line for a new 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 made ambitious promises. Yet they did it. Treated the product with all the sincerity and seriousness they could without it becoming silly to them. 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 French Oak hand-crafted 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, and we traded the carpenter for a CNC machine. The truth is, a lot of software is very 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 a senior who forced the entire company to use his ORM (that's going through a 7th refactor that quarter) venerated for being an "unsung genius," no longer are you celebrated for writing basic conditionals or stripping 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 that 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 were quickly replaced by industrialization. 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 3am coder writing a lock-free allocator, or tracing a TCP packet across seven timezones and five datacenters. You've spent the last 12 years abstracting a database so users can post cat pictures and lyrics to their favorite 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 and it just ends up in a landfill (or the ocean). Plastic owned by someone is recycled, re-used or stored for safe keeping. 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 okay with spending a little bit of money for 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 industry and consumers want more Ikea. But this leaves us in an awkward spot; Engineers are still needed to build both the bad and good 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, about five to six times reduced cost. We were able to ship five to six times faster, and the fewer hours required to build reduce the billing to the client. And that's a good thing. These products weren't in any way, shape or form complicated products, but they did require a lot of coding, interpreting and back and forth with the clients. All three clients are happy with their products. 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 if an LLM runs out of its own depth you're able to 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 the software products. Software being expensive and laborious kept competitors at bay. Being first to market meant having a real edge; today, it's an example of what to do and where to improve for an LLM. The cost of ideas and building them protected the very companies championing AI, and they don't even realize 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 from our experience that's not the case. Your job is more threatened by economic recessions, inflation rates and prime lending rates than 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, take responsibility and resolve issues, no matter the level of agentic LLM usage. Companies that reduce their staff to balance out the productivity gains from LLMs are kneecapping themselves. A magic fairy came along, gave companies a wand that increased their productivity by 3 and instead of producing more, they admit they're creatively bankrupt and lay off as many people as possible while keeping the wheels turning. These companies pretended for the last 2 decades they were the French Oak desk artisans of the software world, but have revealed themselves to be Ikea, and 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 just state the following for the record: Ikea is awesome. I have no hate towards Ikea, and Ikea also doesn't sell itself as a premium product 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 their model; almost every desk is MDF and vinyl or some particle board with a 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 it turned the honest ones into industrial designers. There's a little bit lost: almost every house interior now looks the same. This made life cheaper, in every sense of the word. I don't think that's a good or 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 where the output of their effort is no longer signed off by them personally, stakes are diffused by LLMs and accountability is becoming more abstract. Yeah that sucks, but it doesn't mean you have to stop owning the work you output. 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 output Ikea products at increased speed and with reliability. And the few artisans that 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, 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, ask an LLM to fill in the blanks. Write the testing framework yourself, ask the LLM to write more test cases for you, but write the edge cases yourself. The only time an LLM replaces you is if 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 LLMs review for you. Do everything by hand still, bust your brain as much as you can, 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, that's where 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 free time studying and practicing. 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.