Or: What the man who wants to throw out all his frameworks hasn’t learned yet


Look, I’m going to tell you about a blog post I read the other day. But first let me tell you about my grandfather’s hammer.

My grandfather had a hammer. Not a special hammer — just a hammer, wooden handle, metal head, the kind you could buy anywhere. He used it for forty years. The handle got replaced twice. The head got replaced once. My grandmother used to say “that’s not the same hammer anymore” and my grandfather would say “mulher, it hits nails the same way it always did.”

This is not, technically, about hammers.


So there’s this guy — engineer, smart guy, builds things — who wrote a manifesto. The manifesto says: software engineering is back. What he means is: AI coding agents have gotten so good that we don’t need frameworks anymore. React, Next.js, all that parade of libraries and dependencies and security advisories at 3am — we can throw it all out. We can write our own tools now. Custom. Purpose-built. No more “intellectual surrender” to whatever Google or Vercel decided for us.

And look, I read this, and part of me — the part that has debugged a Next.js upgrade at midnight, the part that has watched a simple feature turn into a dependency nightmare — that part of me wants to stand up and applaud.

He’s not wrong about the frustration. Anyone who tells you the frustration isn’t real has never maintained a modern web application.

But.

(Here’s the but. There’s always a but. My father used to say “a story without a but is just a fact, and facts are boring.”)


The manifesto says frameworks exist because engineers are scared. Because we’d rather accept someone else’s structure than design our own. “Intellectual surrender,” he calls it.

And I want to tell you about the time I worked alone on a project for six months.

It was beautiful. Clean architecture. No framework telling me what to do. I made every decision myself. The code was mine — shaped exactly to the problem, no compromises, no adapters, no “force-fitting” into someone else’s opinions.

Then I got hit by a bus.

Not literally. I mean I got a job offer, or got sick, or whatever — the details don’t matter. What matters is: someone else had to maintain my code.

And here’s what I learned: code that’s shaped exactly to how I think is code that’s shaped exactly to how nobody else thinks.

Frameworks aren’t just technical tools. They’re coordination protocols. They’re the reason you can hire a “React developer” instead of spending three months teaching someone your personal theory of state management. They’re the reason Stack Overflow answers apply to your codebase. They’re the reason the new person can fix a bug on their second day.

The manifesto guy? He’s building alone. Ground up. Everything end-to-end. And I believe him when he says it works beautifully.

But most of us don’t work alone.


(Digression. Skip if you want, but the digressions are where the good stuff is.)

There’s a thing in the Hacker News comments — there’s always comments — where someone says AI is a “multiplier.” If you’re a 1x engineer, AI makes you 5x. If you’re a -1x engineer, you produce 5x more bad code.

This is true, and it’s the most important thing anyone said.

Someone else, a doctor-adjacent person, working in medicine, says since their team started using AI agents heavily, “the amount of shit code, bad tests and bugs has skyrocketed.” In medicine. Where bugs can kill people.

The tool is powerful. The tool doesn’t care if you know what you’re doing.


So what actually changed?

Here’s what I think changed:

Writing boilerplate is basically free now. That XKCD chart about whether automating something is worth your time? The math inverted. Things that used to take an hour take seconds.

Throwing away code costs nothing. You can try three approaches, pick the best one, delete the others. No more sunk-cost architecture. This is huge — psychologically, not just practically.

Learning unfamiliar things is faster. New API? New library? New language? You don’t have to read the docs alone anymore. The AI has read them already, badly, but still.

Here’s what I think didn’t change:

You still need to understand what the code does. Not to write it — AI can write it. But to know when it’s wrong. And it’s wrong a lot.

Debugging weird bugs is still hard. AI is bad at debugging. I know, I know, someone will show me a demo. I’ve seen the demos. Try it on a real system with real history and real weirdness. Come back and tell me how it went.

Teams still need shared mental models. This is the framework thing again. Unless you work alone forever, someone will read your code who isn’t you.

Code is still a liability, not an asset. More code means more bugs. Faster code generation means faster bug generation. The math doesn’t change just because the typing is free.


There’s a comment in the thread — I love this comment — where someone compares future developers to airline pilots. “We’ll be like pilots, mostly monitoring the autopilot.”

Two things about this:

First: pilots are still employed because of regulations. Aviation is heavily regulated. Software isn’t. If companies can replace you with a prompt, they will. There’s no pilot’s union for programmers.

Second: when autopilot fails, pilots need to actually fly. The ones who never learned — the ones who only ever monitored — are the ones who crash.

AI-native developers who never wrote code by hand will face the same problem. Not because AI will fail catastrophically (though it might). But because you can’t direct what you don’t understand.


My grandfather’s hammer.

It wasn’t the same hammer. My grandmother was right. But it worked the same, because my grandfather understood hammers. He knew when the handle was going soft. He knew when the head was loose. He could feel, in his hand, when something was wrong.

If you’d given him a robot that swung hammers for him — sure, he could have used it. He’d have known when it was swinging wrong. He’d have known how to fix it, or when to do the job himself.

But if you’d given that robot to someone who’d never held a hammer? They’d have thought every nail was driven perfectly. Until the whole thing fell down.


The manifesto ends: “The revolution already happened and most people are still decorating the old house.”

He’s right that something changed. He’s wrong about what it means.

The revolution isn’t “frameworks are dead.” The revolution is: the cost structure of software shifted, and we haven’t figured out what that means yet.

Some things that were too expensive are now cheap. Some expertise that took years can now be approximated in minutes. Some frameworks we used only for boilerplate can probably go.

But some things are still hard. Some problems require understanding. Some code needs to be read by humans, maintained by teams, extended by people who aren’t you.

The hammer got better. You still need to know how to swing it.


(My father, who studies sociology in the best place to do so — taverns — used to say: “the problem with prophets is they’re always right about the wrong thing.”)

(Then again, he also said: “never trust a man who won’t sit down and eat with you.”)

(I’m not sure what that has to do with frameworks. Maybe nothing. Maybe everything.)


What I’d actually tell you:

If you’re experienced: use the tools. They’re good now. Let them handle the boring parts. But keep your judgment sharp, because you’re the one who knows what “correct” looks like.

If you’re learning: don’t skip the fundamentals. Write code by hand. Debug things the hard way. Build the intuition that lets you tell when the AI is wrong — because it’s wrong a lot, and it’s confident when it’s wrong.

If you’re building a team: frameworks still matter. Not because the code needs them. Because people need them. Shared vocabulary. Shared patterns. The ability to hire someone who can contribute on day two.

And if you’re reading manifestos: remember that the people who declare revolutions are usually standing on ground they didn’t clear themselves.


The forge is hotter. The hammer swings faster. But the work is still the work.

The leg was never broken. We just have better tools now.

Use them wisely.