> Software engineers are scared of designing things themselves.

When I use a framework, it's because I believe that the designers of that framework are i) probably better at software engineering than I am, and ii) have encountered all sorts of problems and scaling issues (both in terms of usage and actual codebase size) that I haven't encountered yet, and have designed the framework to ameliorate those problems.

Those beliefs aren't always true, but they're often true.

Starting projects is easy. You often don't get to the really thorny problems until you're already operating at scale and under considerable pressure. Trying to rearchitect things at that point sucks.

A significant number of developers and businesses are going to have an absolutely brutal rude awakening in the not too distant future.

You can build things this way, and they may work for a time, but you don't know what you don't know (and experience teaches you that you only find most stuff by building/struggling; not sipping a soda while the AI blurts out potentially secure/stable code).

The hubris around AI is going to be hard to watch unwind. What the moment is I can't predict (nor do I care to), but there will be a shift when all of these vibe code only folks get cooked in a way that's closer to existential than benign.

Good time to be in business if you can see through the bs and understand how these systems actually function (hint: you won't have much competition soon as most people won't care until it's too late and will "price themselves out of the market").

What they are basically saying : a framework built up from bash-or-makefile-ground by an LLM, is better than any existing framework. I don't agree. When I use LLMs to generate scripts for me, I often have to adapt them to fit in the bigger picture. The more scripts I have, the more blurred becomes what that framework as a whole stands for. Then to become a usable framework, refactoring is needed, which means the calls to those scripts need rewriting and retesting as well.

It's strange to me when articles like this describe the 'pain of writing code'. I've always found that the easy part.

Anyway, this stuff makes me think of what it would be like if you had Tolkein around today using AI to assist him in his writing.

'Claude, generate me a paragraph describing Frodo and Sam having an argument over the trustworthiness of Gollum. Frodo should be defending Gollum and Sam should be on his side.'

'Revise that so that Sam is Harsher and Frodo more stubborn.'

Sooner or later I look at that and think he'd be better off just writing the damned book instead of wasting so much time writing prompts.

The author seems to mistake having to update Node.js for a security patch to be a curse rather than a blessing.

The alternative is that your bespoke solution has undiscovered security vulnerabilities, probably no security community, and no easy fix for either of those.

You get the privilege of patching Node.js.

Similarly, as a hiring manager, you can hire a React developer. You can't hire a "proprietary AI coded integrated project" developer.

This piece seems to say more about React than it says about a general shift in software engineering.

Don't like React? Easiest it's ever been not to use it.

Don't like libraries, abstractions and code reuse in general? Avoid them at your peril. You will quickly reach the frontier of your domain knowledge and resourcing, and start producing bespoke square wheels without a maintenance plan.

I fail to see the obvious wisdom in having AI re-implement chunks of existing frameworks without the real-world battle testing, without the supporting ecosystem, and without the common parlance and patterns -- all of which are huge wins if you ever expand development beyond a single person.

It's worth repeating too, that not everything needs to be a react project. I understand the author enjoys the "vibe", but that doesn't make it a ground truth. AI can be a great accelerator, but we should be very cognizant of what we abdicate to it.

In fact I would argue that the post reads as though the developer is used to mostly working alone, and often choosing the wrong tool for the job. It certainly doesn't support the claim of the title

You can drop the boilerplate bit pushing glue frameworks, but the building block frameworks are here to stay; LLMs know a lot, but they don’t know every solution to every problem. Do not confuse a software development LLM assistant with an oracle.

I would think that frameworks make more sense than ever with LLMs.

The benefits of frameworks were always having something well tested that you knew would do the job, and that after a bit of use you'd be familiar with, and the same still stands.

LLMs still aren't AGI, and they learn by example. The reason they are decent at writing React code is because they were trained on a lot of it, and they are going to be better at generating based on what they were trained on, than reinventing the wheel.

As the human-in-the-loop, having the LLM generate code for a framework you are familiar with (or at least other people are familiar with) also let's you step in and fix bugs if necessary.

If we get to a point, post-AGI, where we accept AGI writing fully custom code for everything (but why would it - if it has human-level intelligence, wouldn't it see the value in learning and using well-debugged and optimized frameworks?!), then we will have mostly lost control of the process.

There is a fourth reason to use a framework: onboarding.

It does not work much for Django, as every project I saw using it has a different shape, but it works very well for Rails, as all projects share the same structure. However, even for Django, there are some practices that a newcomer to a project should expect to find in the code, because it's Django. So, maybe onboarding on a LLM coded project is just picking the same LLM as all the other developers, making it read the code and learning what kind of prompts the other developers use.

By the way, does anybody mind to share first hand experiences of projects in which every developer is using agents? How do those agents cope with the code of the other agents?

My biggest concern with AI is that I'm not sure how a software engineer can build up this sort of high-level intuition:

> I still have to deeply think about every important aspect of what I want to build. The architecture, the trade offs, the product decisions, the edge cases that will bite you at 3am.

Without a significant development period of this:

> What’s gone is the tearing, exhausting manual labour of typing every single line of code.

A professional mathematician should use every computer aid at their disposal if it's appropriate. But a freshman math major who isn't spending most of their time with just a notebook or chalk board is probably getting in the way of their own progress.

Granted, this was already an issue, to a lesser extent, with the frameworks that the author scorns. It's orders of magnitude worse with generative AI.

> Since [a few months ago], things have dramatically changed...

It's not like we haven't heard that one before. Things have changed, but it's been a steady march. The sudden magic shift, at a different point for everyone, is in the individual mind.

Regarding the epiphany... since people have been heavily overusing frameworks -- making their projects more complex, more brittle, more disorganized, more difficult to maintain -- for non-technical reasons, people aren't going to stop just because LLMs make them less necessary; The overuse wasn't necessary in the first place.

Perhaps unnecessary framework usage will drop, though, as the new hype replaces the old hype. But projects won't be better designed, better organized, better through-through.

Using a framework gives you some assurance that the underlying methods are well designed. If you don't know how to spot issues in auth design, then using an LLM instead of a library is a bad idea.

I agree though there's many non-critical libraries that could be replaced with helper methods. It also coincides with more awareness of supply chain risks.

So the suggestion here is that instead of using battle tested libraries/frameworks, everyone should now build their own versions, each with an unique set of silent bugs?

I have been using Cursor w/ Opus 4.x to do extensive embedded development work over the past six months in particular. My own take on this topic is that for all of the chatter about LLMs in software engineering, I think a lot of folks are missing the opportunity to pull back and talk about LLMs in the context of engineering writ large. [I'm not capitalizing engineering because I'm using the HN lens of product development, not building bridges or nuclear reactors.]

LLMs have been a critical tool not just in my application but in my circuit design, enclosure design (CAD, CNC) and I am the conductor where these three worlds meet. The degree to which LLMs can help with EE is extraordinary.

A few weeks ago I brought up a new IPS display panel that I've had custom made for my next product. It's a variant of the ST7789. I gave Opus 4.5 the registers and it produced wrapper functions that I could pass to LVGL in a few minutes, requiring three prompts.

This is just one of countless examples where I've basically stopped using libraries for anything that isn't LVGL, TinyUSB, compression or cryptography. The purpose built wrappers Opus can make are much smaller, often a bit faster, and perhaps most significantly not encumbered with the mental model of another developer's assumptions about how people should use their library. Instead of a kitchen sink API, I/we/it created concise functions that map 1:1 to what I need them to do.

Where I agree with the author of this post is that I feel like perhaps it's time for a lot of libraries to sunset. I don't think replacing frameworks is the correct abstraction at all but I do think that it no longer makes sense to spend time integrating libraries when what you really need are purpose-built functions that do exactly what you want instead of what some library author thought you should want.

I disagree about ditching abstractions. Programmatic abstractions aren't just a way to reduce the amount of code you write, they're also a common language to understand large systems more easily, and a way to make sure systems that get built are predictable.

Even with a perfect coding agent, we code to discover what correct even is.

Team decides on vague requirements, then you actually have to implement something. Well that 'implementing' means iterating until you discover the correct thing. Usually in lots of finicky decisions.

Sometimes you might not care about those decisions, so you one shot one big change. But in my experience, the day-to-day on a production app you can 100% write all the code with Claude, but you're still trying to translate high level requirements into "low"-level decisions.

But in the end its nice not to care about the code monkey work going all over a codebase, adding a lot of trivial changes by hand, etc.

If the author is this Alain di Chiappari, he works for a telehealth and psychology site:

https://theorg.com/org/unobravo-telehealth-psychology-servic...

It is interesting how many telehealth and crypto people are promoting AI (David Sacks being the finest of all specimens).

The article itself is of course an AI assisted mashup of all propaganda talking points. People using Unobravo should take note.

> We can finally get rid of all that middle work. That adapting layer of garbage we blindly accepted during these years. A huge amount of frameworks and libraries and tooling that has completely polluted software engineering, especially in web, mobile and desktop development. 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.

I disagree. At least for a little while until models improve to truly superhuman reasoning*, frameworks and libraries providing abstractions are more valuable than ever. The risk/reward for custom work vs library has just changed in unforeseen ways that are orthogonal to time and effort spent.

Not only do LLMs make customization of forks and the resulting maintenance a lot easier, but the abstractions are now the most valuable place for humans to work because it creates a solid foundation for LLMs to build on. By building abstractions that we validate as engineers, we’re encoding human in the loop input without the end-developer having to constantly hand hold the agent.

What we need now is better abstractions for building verification/test suites and linting so that agents can start to automatically self improve their harness. Skills/MCP/tools in general have had the highest impact short of model improvements and there’s so much more work to be done there.

* whether this requires full AGI or not, I don’t know.

I have to tell claude specifically to use plain html css js, else it goes on building react

> In my mind, besides the self declared objectives, frameworks solve three problems .. “Simplification” .. Automation .. Labour cost.

I think you are missing Consistency, unless you don't count frameworks that you write as frameworks? There are 100 different ways of solving the same problem, and using a framework--- off the shelf or home made--- creates consistency in the way problems are solved.

This seems even more important with AI, since you lose context on each task, so you need it to live within guardrails and best practices or it will make spaghetti.

Intellectual surrender is exactly the risk I fear with coding agents. Will the next generation of software ‘developers’ still know how to code? Seems coding agents are in a way taking us further from understanding the machine, just like frameworks have in the past.

Frameworks are stable by design, generated code isn't. Why people still had to learn math when calculator was invented?

Frameworks are the reasons why AI can learn patterns and repeat, without frameworks you will be burning credits just to do things that been optimized already and completed. Unless you are Anthropic investor, thats not the way to improve your coding.

The pendulum swing described here is real but I think the underlying issue is subtler than "AI vs. no AI."

The actual problem most teams have isn't writing code — it's understanding what the code they already depend on is doing. You can vibe-code a whole app in a weekend, but when one of your 200 transitive dependencies ships a breaking change in a patch release, no amount of AI is going to help you debug why your auth flow suddenly broke.

The skill that's actually becoming more valuable isn't "writing code from scratch" — it's maintaining awareness of the ecosystem you're building on. Knowing when Node ships a security fix that affects your HTTP handling, or when a React minor changes the reconciliation behavior, or when Postgres deprecates a function you use in 50 queries.

That's the boring, unsexy part of engineering that AI doesn't solve and most developers skip until something catches fire.

It never left, welcome back to software engineering though!

> But the true revolution happened clearly last year

Oh, that seems like a good bit of time!

> and since December 2025

So like..1 or 2 months ago? This is like saying “over half of people who tried our product loved it - all 51% of them!”. This article is pushing hype, and is mistaking Anthropics pre IPO marketing drive as actual change.

> What’s gone is the tearing, exhausting manual labour of typing every single line of code.

I constantly see this and think I must be operating in a different world. This never took significant amounts of time. Are people using react to make text blogs or something?

When you choose the right framework it saves you enormous amounts of time. Sounds like the author has trouble separating hype from fact. Pick the right framework and your LLM will work better, too.

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.

That took the strangest turn. It started with empowerment to do much more (and that I reallY agree with) — to then use it to... build everything from scratch? What? Why?

What a framework gives me is mostly other people having done precisely the architectural work, that is a prequisite to my actual work. It's fantastic, for the same reason that automatic coding is. I want to solve unsolved problems asap.

I am so confused by the disconnect that I feel like I must be missing something.

Strange how many people are comparing code to art. Software engineering has never been about the code written, it’s about solving problems with software. With AI we can solve more problems with software. I have been writing code for 25 years, I love using AI. It allows me to get to the point faster.

The author is right, eliminating all this framework cruft will be a boon for building great software. I was a skeptic but it seems obvious now its largely going to be an improvement.

I feel the opposite. Frameworks and standardization becomes even more important when using AI.

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.

Build libraries, not frameworks.

> That adapting layer of garbage we blindly accepted during these years.

Wouldn't everything that agents produce be better described as a "layer of garbage?"

It's actually so over

Pretty much completely disagree with the OP. Software Engineering never left, maybe the author moved away from it instead.

> Stop wrapping broken legs in silk. Start building things that are yours.

This however is deeply wrong for me. Anyone who writes and reviews code regularly knows very well that reading code doesn't lead to the same deep intuitive understanding of the codebase as writing same code.

So, no, with AI you are not building things which are yours. You might call them yours, but you lose deeper understanding of what you built.

If a framework, best a minimal one using web standards E.g. svelte or https://nuejs.org/.

Mindblowing observations.

This is about green field development which is relatively rare. Much of the time the starting point is a bunch of code using React or maybe just a lump of PHP. Business logic ends up plunked down all over the place and LLMs tend to make a huge mess with all this unless kept on a tight leash.

I'm glad this guy is doing well, but I'm dreading the amount of work being created for people who can reverse engineer the mountains of hallucinated bullshit that he and others are now actively producing.

And if the frameworks aren't useful then maybe work up the chain and ditch compilers next?

"Software engineers are scared of designing things themselves."

what?

There is yet another issue: the end-users are fickle fashion minded people, and will literally refuse to use an application if it does not look like the latest React-style. They do not want to be seen using "old" software, like wearing the wrong outfit or some such nonsense. This is real, and baffling.

> 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.

Nah. Nothing has changed. To offload the work to an agent and make it a productivity gain it is exactly the same as using a framework, it's a black box portion of your system, written by someone else, that you don't understand.

Unless you are quite literally spending almost the same amount of time you'd spend yourself to deeply understand each component, at which point, you could write it yourself anyway, nothing has changed when it comes to the dynamics of actually authoring systems.

There are exceptions, but generally speaking untempered enthusiasm for agents correlates pretty well with lack of understanding about what engineering software actually entails (it's about relational and conceptual comprehension, communication, developing shared knowledge, and modeling, not about writing code or using particular frameworks!)

EDIT: And to be clear, the danger of "agentizing" software engineering is precisely that it promotes a tendency to obscure information about the system, turn engineers into personal self-llm silos, and generally discard all the second-order concerns that make for good systems, resilience, modifiability, intelligibility, performance.

I feel the same way, but I’m not a traditional software engineer. Just an old-school Webmaster who’s been trying to keep up with things, but I’ve had to hire developers all along.

I’m an idea’s guy, and in the past month or so my eyes have also fully opened to what’s coming.

But there’s a big caveat. While the actual grunt work and development is going away, there’s no telling when the software engineering part is going to go away as well. Even the ideas guy part. What happens when a simple prompt from someone who doesn’t even know what they’re doing results in an app that you couldn’t have done as well with whatever software engineering skills you have?