Coding agents have replaced every framework I used

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

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

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 wanted to believe this article, but the writing is difficult to follow, and the thread even harder. My main issue is the contradiction about frameworks and using what the large tech companies have built vs real engineering.

The author seems to think that coding agents and frameworks are mutually exclusive. The draw of Vercel/next.js/iOS/React/Firebase is allowing engineers to ship. You create a repo, point to it, and boom! instant CICD, instant delivery to customers in seconds. This is what you're complaining about!? You're moaning that it took 1 click to get this for free!? Do you have any idea how long it would take to setup just the CI part on Jenkins just a few years ago? Where are you going to host that thing? On your Mac mini?

There's a distinction between frameworks and libraries. Frameworks exist to make the entire development lifecycle easier. Libraries are for getting certain things that are better than you (encryption, networking, storage, sound, etc.) A framework like Next.js or React or iOS/macOS exist because they did the heavy work of building things that need to already exist when building an application. Not making use of it because you want to perform "real engineering" is not engineering at all, that's just called tinkering and shipping nothing.

Mixing coding agents with whatever framework or platform to get you the fastest shipping speed should be your #1 priority. Get that application out. Get that first paid customer. And if you achieve a million customers and your stuff is having scaling difficulties, then you already have teams of engineers to work on bringing some of this stuff in house like moving away from Firebase/Vercel etc. Until then, do what lets you ship ASAP.

This is an interesting idea but the problem is where to stop as you travel down through layers of frameworks?

Say we take it to an absurd extreme: You probably won’t have your agent code up Verilog and run your website on an ASIC.. and you aren’t going to write an assembler to code up your OS and kernel and all the associated hardware support, so you probably want a server and an OS to run your code and maybe some containers or a process model.. so the agentic reinvention has to stop somewhere.

One helpful mindset is to choose frameworks and components that avoid rediscovery. Tailwind for example contains some very well thought out responsive breakpoints that a ton of thought went into designing. With `:md` which is only a couple of tokens, your agent can make use of all that knowledge without having to reinvent everything that went into those decisions.

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

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.

This article has some cowboy coding themes I don't agree with. If the takeaway from the article is that frameworks are bad for the age of AI, I would disagree with that. Standardization, and working with a team of developers all using the same framework has huge benefits. The same is true with agents. Agents have finite context, when an agent knows it is using rails, it automatically can assume a lot about how things work. LLM training data has a lot of framework use patterns deeply instilled. Agents using frameworks that LLMs have extensive training on produce high quality, consistent results without needing to provide a bunch of custom context for bespoke foundational code. Multiple devs and agents all using a well known framework automatically benefit from a shared mental model.

When there are multiple devs + agents all interacting with the same code base, consistency and standards are essential for maintainability. Each time a dev fires up their agent for a framework their context doesn't need to be saturated with bespoke foundational information. LLM and devs can leverage their extensive training when using a framework.

I didn't even touch on all the other benefits mature frameworks bring outside of shared mental model: security hardening, teams providing security patches, performance tuning, dependability, documentation, 3rd party ecosystems. etc.

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.

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

Do I live in a different engineering world? Because that's so much not the exhausting labour part of my work, it's not even the same universe. The exhausting manual labour for me is interacting with others in the project, aligning goals and distributing work, reviewing, testing, even coming up with test concepts, and… actually thinking through what the code conceptually will work like. The most exhausting thing I've done recently is thinking through lock-free/atomic data structures. Ouch, does that shit rack your brain.

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.

This is a wild take. Good frameworks come with clever, well-thought-out abstractions and defensive patterns for dealing with common problems experienced when working in the space the framework covers. frameworks are also often well-documented and well-supported by the community, creating common ways of doing things with well understood strengths and weaknesses.

In some cases, it's going to make sense to drop your dependency and have AI write that functionality inline, but the idea that the AI coding best practice is to drop all frameworks and build your own vibe-coded supplychain de novo for every product is ludicrous. At that point, we should just take out the middle man and just have the LLMs write machine code to fulfill our natural language product specs.

There are a few interesting points in the comments here.

The pro case for getting rid of frameworks: they're bulky, complex, there are security holes, updates to keep up with, things keep changing. LLMs can write you something perfectly customized to what you're doing. You get some free security by obscurity.

The con case: LLMs are excellent at getting you up to speed with a framework and understanding issues. As avidiax says in this thread, "The author seems to mistake having to update Node.js for a security patch to be a curse rather than a blessing. You get the privilege of patching Node.js." Security by obscurity is generally a bad design. To me, the general architecture and maintainability is a huge issue when you have LLMs write everything from scratch. Not that a Node or React app is a paragon of maintainability or architecture, but it's certainly better than something made from scratch by an LLM. The code quality of a framework is also far higher.

I personally feel like the best path today is to use something lightweight, like Svelte. You get the best of both worlds. Light structure but nothing overbearing.

You can never have a good substitute for a good framework. A good framework would let you skip over boilerplate code, abstract at a higher level, and be dependable.

Context matters most here-- does a solid framework exist for the work you're trying to do? Then use it, otherwise write what you need and understand the risks that come with freshly written code.

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.

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.

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.

To the people who are against AI programming, honest question: why do you not program in assembly? Can you really say "you" "programmed" anything at all if a compiler wrote your binaries?

This is a 100% honest question. Because whatever your justification to this is, it can probably be used for AI programmers using temperature 0.0 as well, just one abstraction level higher.

I'm 100% honestly looking forward to finding a single justification that would not fit both scenarios.

I found the article interesting yet my thinking is at the opposite spectrum. I also spent a lot of time using LLM, and I am moving away from "no framework" or "library pretending to be a framework".

Not that I was a fan of it, but for work purpose I was using React / Next.js etc.

Now, I am using Laravel. lots of magic, pretty much always one recommended way to do things, excellent code generation using CLI. When you combine it with AI it's following the framework's guideline. The AI does not have to think about whether it should locate business logic with UI, use a hook or not, extract a helper, etc.

It knows how to create route, controller, validator, view, model, migration, whatever.

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?

Right. Lets all write our own Spring Framework / Django / Ruby on Rails. Everyone who contributed to these frameworks was obviously a jackass but me with my Claude sub can beat everybody while ignoring the actual stuff that I should be doing. Makes for a perfectly great maintenance burden.

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.

The interesting question here is what replaces frameworks as the unit of leverage.

Frameworks existed because the cost of understanding someone else's abstractions was lower than rebuilding from scratch. With agents, that calculus flips — generating bespoke code from a clear spec is now cheaper than learning a framework's opinions about how your app should work.

But the article buries the key point: "with the experience on my back of having laid the bricks." The author can direct agents effectively because he has two decades of mental models about what good software looks like. The agent is executing his taste and judgment, not replacing it.

The people who will struggle are not the ones who skip frameworks — it is the ones who never built the internal model of how systems fail. Frameworks taught you that implicitly (why does Rails do it this way? Because the alternative breaks at scale). If you skip straight to "agent, build me X," you never develop the instinct for when the output is subtly wrong.

The real unlock is probably closer to what the SRE agent trio example shows: agents handling the mechanical loop (detect, diagnose, fix, PR) while humans focus on system design and invariant definition. The skill shifts from writing code to defining constraints precisely enough that automated systems can maintain them.

Good article: Software Engineering is finally being liberated from the "Middle Work" of the last decade.

The AI tsunami isn't just about coding faster—it’s about reclaiming architectural sovereignty from hyperscaler blueprints.

The future is Just-in-Time and Highly Customized.

My full thoughts here: https://www.linkedin.com/posts/carlcarrie_software-engineeri...

I'm surprised I don't see many (or any) comments mentioning this: this blog post was clearly written with heavy LLM assistance.

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

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

Dumbest take I've seen in a while. Really. If anything, AI working with frameworks is making them more effective. Frameworks, by definition, produce more structure, than just the language + libs do, and their entire practical utility is to abstract away complexity and lower the amount of footguns. The ultimate form of abstracting away complexity is an AI agent/coder writing the code for you. But there are gazillions of solutions (and opinionated ones) out there, for gazillions of all kinds of problems... having an AI agent work within the constraints of a framework is going to be a good thing in almost all cases as it will be more focused on your problem space rather than figuring out how to send freaking bits between computers.

How do people not understand that even if AI is writing all your code you still want to have as little code as possible for a given problem solution that you have to manage yourself? Frameworks help with that.

I am a non coder. For many years I went through many various coding tutorials, but never had been able to fully build anything other than basic websites. Now with AI I have been able to build useful CLI tools. Instead of using a static website generator such as Hugo, I can now quick build a website of what I am looking for. Heck, I just had it build me a website as a presentation instead of doing a slide show. I came up with an outline + my notes and information then had it build out the site based on that information. I was able to have it create some really cool animations to help explain my ideas.

I have had the same experience when building simple websites for myself and others. I did it as a test to begin with, but it worked out so well that I have kept at it for a while. The core concept for my experiment was to have no dependencies other than PHP and a web server. Longevity is the goal, I should be able to leave a project for years and it should just keep on running.

Source code is here: https://forge.dmz.skyfritt.net/ruben/folderweb.

It is kind of a mini-framework, but really more of a core that can be expanded upon. A few simple ideas that has been codified. It is mainly a router that does very specific things with some convenient features built-in, and with the option to build plugins and templates on top of this core. The customization and freedom it enables is fantastic!

I used to worry that AI would lead to a regression toward the mean, but for this specific use case I think it can have the opposite effect. It can cause a flourish of experiments and custom-tailored solutions that enables a richer online experience. It demands a certain discipline in the way you build, to avoid making a long-term mess, but having just a little bit of experience and insight into general web development goes a long way to keep things tidy and predictable.

Have anyone else had similar experiences?

EDIT: One live site where I have built on top of FolderWeb, is https://stopplidelsen.no (Norwegian)

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.

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

It's a chicken and an egg problem.

Sure, you can skip using frameworks and let AI write them directly for you, because that's what they are trained on - these framework you think you're omitting.

Now the issue is - if we play with the idea that the revolution is actually going to happen and developers will get replaced with vibe coders in the next 6 months (as has been prophesied for the last 5 years) - then the innovation will stop as there will be no one left to add to the pool.

This whole thing reminds me of debacle about retirement funds and taxes in my country. People think they are smart by avoiding them, because they suspect that the system will fail and they won't get anything back. But by the virtue of avoiding these taxes they themselves make a self fulfilling prophecy that is already breaking the system.

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.

this is totally backwards to how i've been using agents.

the thing that an agent is really really good at is overcoming the initial load of using a new framework or library. i know, at some level, that using other people's code is going to save me trouble down the road, but there's an initial load to learn how to integrate with it, how to use it, and how to map the way the framework authors think to the way i think and the way my project needs to work. there's always the temptation to just build from scratch instead because it's initially quicker and easier.

letting the AI figure that out, and do the first initial steps of getting the framework to accomplish the task i need, produces a product that is better than what either the AI or i would produce without the framework, and it creates a product that i can then read, understand, and work on. letting the AI go from scratch invariably produces code that i don't want to work with myself.

> They would rather accept someone else’s structure, despite having to force fit it into their product, rather than taking the time to start from the goal and work backwards to create the perfect suit for their idea. Like an architect blindly accepting another architect’s blueprints and applying them regardless of the context, the needs, the terrain, the new technological possibilities. We decided to remove complexity not by sharpening our mental models around the products we build, but by buying a one size fits all design and applying it everywhere. That is not simplification. That is intellectual surrender.

Sorry, i don't buy this. There is a very good reason to use tried and tested frameworks. Am I "intellectually surrendering" when I use a compiler/language/framework that has a great track record?

And how is it not "intellectual surrender" to let the AI do the work for you?

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

Nothing fundamentally changed about frameworks. No need to reconsider every single practice because of AI. I think frameworks actually keep agents in check because they're trained on huge set of conventions.

I vibe coded a few of projects in vanilla JS and they eventually became mess, but with a framework they'd at least be structured mess

I had called this a while back, since the reasoning is simple: frameworks primarily exist to minimize boilerplate, but AI is very good at boilerplate, so the value of frameworks is diminished.

The larger underlying shift is that the economics of coding have been upended. Since its inception, our industry has been organized around one fundamental principle: code is expensive because coders are expensive. This created several complex dynamics, one which was frameworks -- which are massive, painful dependencies aimed at alleviating costs by reducing the repeated boilerplate written by expensive people. As TFA indicates, the costs of frameworks in terms of added complexity (e.g. abstractions from the dependency infecting the entire codebase) are significant compared to their benefits.

But now that the cost of code ---> 0, the need for frameworks (and reusability overall) will likely also --> 0.

I had predicted that this dynamic will play out widely and result in a lot more duplicative code overall, which is already being borne out by studies like https://www.gitclear.com/ai_assistant_code_quality_2025_rese...

Our first instinct is to recoil and view this as a bad thing, because it is considered "Tech Debt." But as the word "debt" indicates, Tech Debt is yet another economic concept and is also being redefined by these new economics!

For instance, all this duplicate code would have been terrible if only humans had to maintain it. But for LLMs, it is probably better because all the relevant logic is RIGHT THERE in the code, conveniently colocated with the rest of the functionality where it is used, and not obfuscated behind a dozen layers of abstraction whose (intended) functionality is described in natural language scattered across a dozen different pieces of documentation, each with varying amounts of sufficiency, fidelity and updated-ness. This keeps the context very focused on the relevant bits, which along with extensive testing (again, because code is cheap!) that enables instant self-checking, greatly amplifies the accuracy of the LLMs.

Now, I'm not claiming to say this will work out well long term -- it's too early to tell -- but it is a logical outcome of the shifting economics of code. I always say with AI, the future of coding will look very weird to us; this is another example of it.

> For companies, it is much better having Google, Meta, Vercel deciding for you how you build product and ship code. Adopt their framework. Pay the cost of lock in. Be enchanted by their cloud managed solution to…

Right, a future where you have to pay an AI hyperscaler thousands of dollars a month for access to their closed-source black box that needs a world historical capital moat to operate effectively is actually worse than this. It is baffling to me that more people don’t see this.

I use coding agents almost exclusively now and I’m going to say yes and no on this one.

Yes, I think there’s the potential to replace some frameworks that abstract away too many details and make things way too complicated for basic apps. A good example of this are ORMs like SqlAlchemy. Every time I use them I think to myself it would be easier to just write SQL myself, but it would be a tremendous amount of boilerplate. Nowadays though it might be worth it for an agent to just write the SQL for you instead!

On the other hand, you have libraries like Django. Sure, an agent _could_ write you your own web server. But wow would it be a waste of tokens and your projects surface area would be dwarfed by the complexity of just building your own alternative to Django. I can’t see that being the right move for years still.

I'm not sure why this is against 'frameworks' per se; if we were sure that the code LLMs could generate was the best possible, we might as well use Assembly, no, since that'd lead to best performance? But we don't generally, we still need to validate, verify and read it. And in, that, there is still some value in using a framework since the code generated is likely, on the whole, to be shorter and simpler than that not using a framework. On top of that, because it's simpler, I've at least found that there's less scope for LLMs to go off and do something strange.

I choose to use frameworks in the same sense I choose to use crypto libraries. Smarter people have thought long and hard about the problems involved, and came up with the best ways to solve them.

Why have the agents redo all of that if it's not absolutely necessary? Which it probably isn't for ~98% of cases.

Also, the models are trained on code which predominantly uses frameworks, so it'll probably trend toward the average anyway and produce a variant of what already exists in frameworks.

In the cases where it might make sense, maybe the benefit then is the ability to take and use piecemeal parts of a framework or library and tailor it to your specific case, without importing the entire framework/library.

It never left, welcome back to software engineering though!

No, it copied some relevant parts of every framework code, shifting burden of design, maintenance, debugging and polishing all corner cases to your shoulders.

Why wouldn't you clone frameworks code into your repository, removing parts you don't need, modifying code as you wish?

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?

A framework also gives you someone's expertise in a domain so you don't have to develop that expertise yourself and focus on all the other stuff...

LLMs finally deliver on the crochety front end dev's dream of writing everything in vanilla JS. Hallelujah.

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.