lol ok have fun building from zero _without_ abstractions. It will work for the narrow thing you first tell it to build, the fun comes when you tell it to change in any way.

"Software engineers are scared of designing things themselves."

what?

This line shows either he does not get how wrong he is, or I do not understand the deepness of his enlightenment. "A simple Makefile covers 100% of my needs for 99% of my use cases". We've come a long way to replace simple Makefile with autotools (incredible monstrocity), cmake, ninja etc. I hope he does not propose to ditch *libc.

Build libraries, not frameworks.

The author makes a valid observation wrapped in an overstatement. Yes, AI coding agents have changed the economics of building custom tooling. But the conclusion—that frameworks are now obsolete—misses the forest for the trees.

The problem with "framework culture" wasn't that frameworks exist, but that we lost the ability to critically evaluate when they're appropriate. We reached for React for static sites, Kubernetes for three-server deployments, and microservices for monolithic problems—not because these tools were wrong, but because we stopped thinking.

What AI agents actually restore isn't "pure software engineering"—it's optionality. The cost of writing a custom solution has dropped dramatically, which means the decision tree has changed. Now you can prototype both approaches in an afternoon and make an informed choice.

But here's what AI doesn't solve: understanding the problem domain deeply enough to architect a maintainable solution. You can generate 10,000 lines of bespoke code in minutes, but if you don't understand the invariants, edge cases, and failure modes, you've just created a different kind of technical debt—one that's harder to unwind because there's no community, no documentation, and no shared understanding.

Frameworks encode decades of collective battle scars. Dismissing them entirely is like dismissing the wheel because you can now 3D-print custom rollers. Sometimes you want the custom roller. Sometimes you want the battle-tested wheel. AI gives you both options faster—it doesn't make the decision for you.

Latest opus and antigravity. Did an insane amount of complex refactoring on a 500k ish line codebase. I saw programming die today.

I will never significantly code by hand again and probably won't be hired in 5 years.

> The three problems frameworks solve (or claim to) [..] Simplification [..] Automation [..] Labour cost

and he misses _the most important problem frameworks solve_

which is correctness

when it comes to programming most things are far more complicated in subtle annoying ways then they seem to be

and worse while you often can "cut away" on this corner cases this also tends to lead to obscure very hard to find bugs including security issues which have a tendency to pop up way later when you haven't touched to code for a while and don't remember which corner you cut (and with AI you like did never know which corner you did cut)

like just very recently some very widely used python libraries had some pretty bad bugs wrt. "basic" HTTP/web topics like http/multipart request smuggling, DOS from "decompression bombs" and similar

and while this might look like it's a counter argument, it speaks for strict code reuse even for simple topics. Because now this bugs have been fixed! And that is a very common topic for frameworks/libraries, they start out with bugs, and sadly often the same repeated common bugs known from other frameworks, and then over time things get ironed out.

But with AI there is an issue, a lot of the data it's trained on is code _which does many of this "typical" issues wrong_.

And it's non-determenistic, and good at "hiding" bugs, especially the kind of bugs which anyway are prone to pass human reviews.

So you _really_ would want to maximize use of frameworks and libraries when using AI, as that large part of the AI reliability issues.

But what does change is that there is much less reason to give frameworks/libraries "neat compact APIs" (which is a common things people spend A LOT of time one and which is prone to be the source of issues as people insist on making things "look simpler" then they are and in turn accidentally make them not just simpler but outright wrong, or prevent use-cases you might need).

Now depending on you definition of framework you could argue that AI removes boiler-parts issues in ways which allow effectively replacing all frameworks with libraries.

But you still need to review code, especially AI generated code. To some degree the old saying that code is far more read then written is even more true with AI (as most isn't "written"(by human) anymore). Now you could just not review AI code, but that can easily count as gross negligence and in some jurisdictions it's not (fully) possible to opt out of damages from gross negligence no matter what you put in TOS or other contracts. I.e. I can't recommend such negligent actions.

So IMHO there is still use for some kind of frameworks, even if what you want from them will likely start to differ and many of them can be partially or fully "librarified".

> Layers upon layers of abstractions that abstract nothing meaningful, that solve problems we shouldn’t have had in the first place, that create ten new problems for every one they claim to fix.

LLM generated code is the ultimate abstraction. A mess of code with no trusted origin that nobody has ever understood. It's worse than even the worst maintained libraries and frameworks in every way.

Mindblowing observations.

"Why do you ever need, for most of the use cases you can think of, a useless, expensive, flawed, often vulnerable framework, and the parade of libraries that comes with it, that you probably use for only 10% of its capabilities?"

Who outside of 'frontend web developers' actually do this?

I don't think this is a good description of, say, Apache Tika or Alembic's Ash.