Luddism 2026

Software Engineering is back: Answering the Room

A few days ago I published a clearly provocative post on something I've been noticing: how much coding agents can replace most of the frameworks and tooling I would use in my workflow, especially when the benefit is so low that the bloat doesn't justify their introduction.

I didn’t expect it to travel as far as it did, with nearly 600 comments on Hacker News. I want to genuinely thank everyone who, whether they agreed or not, discussed it, shared it, and reached out to me because they felt I raised a point worth engaging with.

Anyway, I knew it would sting, and some reactions¹ confirmed not only what I thought, but also what I wrote: most people are still decorating the old house. Many are scared, in a denial phase that brings the discussion to a detrimental state for everyone.

I'll try here to cluster and answer the most common takes.

Framework Defenders

Of course frameworks have their place. The point was different: we're talking about blindly accepting design decisions without considering the trade-offs that always exist. We often do this from the start, when the solution space isn't clear yet. Starting to develop a simple web application with Next.js just because it's easy enough and deployable in a click on Vercel is a terrible idea if done by default, just because that's what YouTube influencer X told you.

“Frameworks provide correctness and battle-tested security”. Sure. Nobody is arguing against that when you really need it and it’s part of your design decisions. I’m arguing against defaulting to someone else’s blueprint when you now have the tools to draw your own, especially when the problem doesn’t warrant it.

The argument that AI performs better with frameworks because they provide "vocabulary" is telling. You're saying the machine needs the crutch too. That's not a defense of frameworks. That's an accusation of how we've trained ourselves (and now our tools) to think inside someone else's box, regardless of the context.

SQL injection protection is not an argument for adopting an entire web framework. It’s an argument for adopting a single, purpose-built sanitization layer. Not ten thousand lines of someone else’s opinions about how your application should breathe.

The middle path people get it. Build or buy what you need. Nothing more. Nothing less.

“But I love writing code”

So do I. In twenty years I have hand-built thousands of projects of any kind. This keeps being true even now, when the most powerful LLMs are available. Writing code is relaxing. It’s satisfying. It’s craft for the sake of craft, and I have never stopped doing it.

But that’s not what we’re talking about.

Loving to write code and questioning whether you should write every line by hand for every project are two completely different conversations. A carpenter can love hand-cut joinery and still use a table saw when building a deck. The love of the craft is not an argument against better tools. It’s an argument for knowing when the craft matters and when the deadline does.

Confusing what you enjoy with what a project demands is not passion. It’s lack of pragmatism. And pragmatism is not the enemy of craftsmanship. It’s what separates the craftsman from the hobbyist. The hobbyist would write code because it feels good. The craftsman writes code when it’s the right call, and lets the machine handle the rest so they can focus on the part that actually requires a human brain.

Nobody is asking you to stop writing code. Do, literally, what you want. I’m asking you to stop pretending that enjoying something makes it the right tool for every job.

Productivity Skeptics

The ones claiming “1.2x at best”: If your speed hasn’t changed, you’re using the forge to heat your coffee. I’ve recently heard university professors claiming they can’t find useful ways to use LLMs, and that most of the time the results are wrong. If you think buying a kitchen teaches you to cook, you'll be disappointed.

The 10x claim is also nonsense for most. Here’s the truth nobody wants to quantify honestly: the multiplier is not uniform. It’s asymmetric. The thinking time stays the same, if not more. It should. If your thinking time decreased, you’re not engineering, you’re gambling. What collapses is the translation time, the brutal, exhausting distance between a clear idea and working code. That distance used to be days. Now it’s hours. Sometimes minutes.

If you were already fast at typing and slow at thinking, yes, you’ll see 1.2x. The tool replaced your least valuable skill. If you were slow at typing and sharp at thinking, you just got some of your life back, or increased the value you can get.

“Rude Awakening” Prophets

You’re right. Partially.

Vibe coding will produce disasters. Companies are already shipping systems nobody understands. I see it. And when those systems break, not if, when, there will be no one in the building who can find the fracture. This is not a prediction. This is a certainty.

But this is not an argument against Automatic Programming (again, thanks to Antirez for coining the term). This is an argument against ignorance. The stochasticity argument is more interesting, and of course must have a place. Yes, a model is not a compiler. A compiler is a contract. A model is a collaborator. We don’t trust a collaborator blindly. We review. We test. We verify. If we’re not doing that, the problem is not the tool. The problem is us.

From Robert Martin’s Clean Code 2nd Edition:

On the other hand, I am the final arbiter of the code that gets produced.
It remains incumbent upon me to do the work to ensure that I can evaluate what it produces.
Doing that work will usually involve writing and cleaning the code that I ask it to improve so that I can properly judge the outcome. The trade-off is very similar to using an autopilot in an airplane. The autopilot can vastly reduce the workload. But under no circumstances should it be implicitly trusted. Rather, the pilot must continuously oversee its operation. By the same token, no pilot should ever fly without possessing the necessary flying skills that they continuously maintain and refine. So it is with us. We must stay in practice, and keep our skills high, because we must be able to competently oversee the automation that reduces our workload.

Career Worriers

There is fear, and uncertainty, I understand. The question isn’t whether the landscape is changing, it clearly is. The question is what we do with that knowledge.

The pilot model is the closest analogy I’ve seen.

The junior dev crisis is real and it’s already here. But the solution can’t be to slow down the tools. The solution is to fix how we teach. We don’t teach new pilots by making them build an engine from scratch. We teach them aerodynamics, systems thinking, failure modes. Then we put them in the seat with supervision.

The craft of understanding why code works is not going away. It’s becoming more important, not less. Because when the agent writes something wrong, and it will, the person in the seat needs to know why it’s wrong before the ground gets close.

We also have to consider the new skills that are forming, and will form, because of Automatic Programming. The ability to architect systems at a higher level of abstraction. The skill of ‘prompt engineering’ is, now more than ever, really just clear thinking made explicit. The judgment to know when to trust the machine and when to rewrite from scratch. These aren't lesser skills. They're different skills, and some of them require sharper thinking than what came before.

Skill polarization is not a bug. It’s how every tool revolution has worked since the first human picked up a sharper rock. The question is whether you’re sharpening your rock or admiring someone else’s.

The “Last 10%” Realists

Yes. The last ten percent is where the craft lives. It always has been. A prototype is not a product. A sketch is not a building. Anyone who ships a 90% AI-generated system and calls it done deserves the 3am phone call they’re going to get.

Here’s what you’re missing: that last ten percent used to come after months of the first ninety. Now it comes after days. You’re not saving ten percent of the effort. You’re reclaiming ninety percent of your time to spend on the part that actually matters. The hard part. The part that requires a human who has laid the bricks before and knows which ones crack under pressure.

But this is the 10% of the building part. If you've worked in this industry at all, you know where the biggest part of Software Engineering really lives. And it's not building.

1. Insulters: I’m flattered you took the time to type with both hands.