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").
Then, as part of the session, you would artificially introduce a bug into the system, then run into the bug in your browser. You'd see the failure happen in browser, and looking at Cloudwatch logs you'd see the error get logged.
Two minutes later, the SRE agents had the bug fixed and ready to be merged.
"understand how these systems actually function" isn't incompatible with "I didn't write most of this code". Unless you are only ever a single engineer, your career is filled with "I need to debug code I didn't write". What we have seen over the past few months is a gigantic leap in output quality, such that re-prompting happens less and less. Additionally, "after you've written this, document the logic within this markdown file" is extremely useful for your own reference and for future LLM sessions.
AWS is making a huge, huge bet on this being the future of software engineering, and even though they have their weird AWS-ish lock-in for some of the LLM-adjacent practices, it is an extremely compelling vision, and as these nondeterministic tools get more deterministic supporting functions to help their work, the quality is going to approach and probably exceed human coding quality.
I think this dynamic applies to any use of AI, or indeed, any form of outsourcing. You can outsource a task effectively if you understand the complete task and its implementation very deeply. But if you don't, then you don't know if what you are getting back is correct, maintainable, scalable.
Now, if I were in business with any of these people, why would I be paying them hundreds of thousands, plus the hundreds of thousands in LLM subscriptions they need to barely function, when they cannot produce a single valuable thought?
Who knows, maybe soon enough we'll have specially trained de-slopper bots, too.
There will obviously be companies that build a vibe coded app which too many people depend on. There will be some iteration (maybe feature addition, maybe bug fix) which will cause a catastrophic breakage and users will know.
But there will also be companies who add a better mix of incantations to the prompts, who use version control and CI, who ensure the code is matched with tests, who maintain the prompts and requirements documents.
The former will likely follow your projected path. The latter will do fine and may even thrive better than either traditional software houses of cheap vibe coding shops.
Then again, there are famous instances of companies who have tolerated terribly low investment in IT, including SouthWest Airlines.
I use Claude Code with both Django and React which its surprisingly good with. I rather use software thats tried and tested. The only time I let it write its own is when I want ultra minimal CSS.
This has already been a problem. There's no real ramifications for it. Even for something like Cloudflare stopping a significant amount of Internet traffic for any amount of time is not (as far as I know) investigated in an independent way. There's nobody that is potentially facing charges. However, with other civil engineering endeavors, there absolutely is. Regular checks, government agencies to audit systems, penalties for causing harm, etc. are expected in those areas.
LLM-generated code is the continuation of the bastardization of software "engineering." Now the situation is not only that nobody is accountable, but a black box cluster of computers is not even reasonably accountable. If someone makes a tragic mistake today, it can be understood who caused it. If "Cloudflare2" comes about which is all (or significantly) generated, whoever is in charge can just throw their hands up and say "hey, I don't know why it did this, and the people that made the system that made this mistake don't know why it did this." It has been and will continue to be very concerning.
https://news.ycombinator.com/item?id=46888441
Developers and businesses with that attitude could experience a similarly rude awakening.
Instead agent written code will get more and more complex, requiring more and more tokens (& NPU/GPU/RAM) to create/review/debug/modify, and will rapidly pass beyond any hope of a human understanding even for relatively simple projects (e.g. such as a banking app on your phone).
I wonder, however, whether the complexity will grow slower or faster than Moore's law and our collective ability to feed the AIs.
E.g. OOP and "patterns" in 90s. What was the last time you implemented a "visitor"?
P. Norvig mentioned most of the patterns are transparent in Common Lisp: e.g. you can just use a `lambda` instead of "visitor". But OOP people kept doing class diagrams for a simple map or fold-like operation.
AI producing a flawed code and "not understanding" are completely different issues. Yes, AI can make mistakes, we know. But are you certain your understanding is really superior?
These people get paid millions a year to fly around and shake hands with people aka shit fuck all.
At times in the past I have worked on projects that were rushed out and didn't do a single thing that they were intended to do.
And you know what management's response was? They loved that shit. Ooooh it looks do good, that's so cool, well done. Management circle jerking each other, as if using everyone else's shafts as handles to climb the rungs of the ladder.
It's just...like it kills me that this thing I love, technology/engineering/programming...things that are responsible for many of the best things present in our modern lives, have both been twisted to create some of the worst things in our modern lives in the pursuit of profit. And the people in charge? They don't even care if it works or not, they just want that undeserved promotion for a job that a Simpsons-esque fucking drinking bird is capable of.
I just want to go back to the mid 2000s. ;~;
It's really not a great sense of things for someone working in tech to make such a strong statement as the above given these circumstances. There is no reason to expect improvement will not continue, that agents' ability to review code-- drastically improved even since May/June, won't improve and, to the extend your concerns are valid about current agents, be able to manage the review and surfacing of issues for review and remediation.
This also ignores the growing awareness within the community of professional developers that, yes, blind trust-- as naively but minimally understandable given lack of knowledge on capabilities-- that blind trust cannot be given, and reasonable review of generated code at the end of a session is good practice. Developers are quite often already changing their habits with agents, if they were even avoiding such review before.
As for companies that may fire developers, rely near completely on agentic coding? I agree with the sentiment, but I really have not seen that happen to any great degree.
I won't assume this is the case for you, you may very well have dug in depth and worked with agents like claude code, understanding how best to scaffold by creating skills and agents, and still come to your conclusions. I would hope so. For the most part though, a large number of the people making comments of this sort seem to betray directly or indirectly that they-- nearly by definition of distrusting these agents and therefore avoiding them-- have little idea of what they are dismissing precisely because they have not taken the time to do more than dismiss them after little more than cursory review.
At the same time, many notable developers of significant accomplished near daily comment in pages here sharing experiences of true capability and assistance by these agents.
> 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
For those who are "vibe code only", perhaps. But it's no different than the "coding bootcamp only" developers who never really learned to think holistically. Or the folks who learned the bare minimum to get those sweet dotcom boom dollars back in the day, and then had to return to selling cars when it call came crashing down.
The winners have been, and will always be, those who can think bigger. The ones today who already know how to build from scratch but then find the superpower is in architecture, not syntax, and suddenly find themselves 10x more productive.
Authentication and authorization is as simple as POST /api/create/admin with zero checks. Pretty much every API ever slop coded looks like this. And if it doesn't, it will forget about security checks two prompts later and reverse the previously working checks.
Given a good design, software engineers today are 100x more productive. What they produce is high quality due to the design. Production is fast and cheap due to the agents.
You are correct, there will be a reckoning for large scale systems which are vibe coded. They author is also correct, well designed systems no longer need frameworks or vendors, and they are unlikely to fail because they were well designed from the start.
Now they can quickly build simple tools. Yes, they are bad from software quality pov, but they solve problems.
I have be building systems for 20 years and I think the author is right.
I pray (?) for times like the ones you predict. But companies can stay irrational longer than the average employee can afford.
Correct. Those who wave away coding agents and refuse to engrain them into their workflows are going to be left behind in the dust.
The frameworks are what make the AI write easily understandable code. I let it run nextjs with an ORM, and it almost always creates very well defined api routes, classes & data models. etter then I would do often,
I also ask it be way more correct on the validation & error handling then I would ever do. It makes mistakes, I shout at it and corrects quickly.
So the project I've been "vibe coding" have a much better codebase then I used to have on my solo projects.
A experiment was tried on a large and very intractable code-base of C++, Visual Basic, classic .asp, and SQL Server, with three different reporting systems attached to it. The reporting systems were crazy being controlled by giant XML files with complex namespaces and no-nos like the order of the nodes mattering. It had been maintained by offshore developers for maybe 10 years or more. The application was originally created over 25 years ago. They wanted to replace it with modern technology, but they estimated it'd take 7 years(!). So they just threw a team at it and said, "Just use prompts to AI and hand code minimally and see how far you get."
And they did wonderfully (and this is before the latest Claude improvements and agents) and they managed to create a minimal replacement in just two months (two or maybe three developers full time I think was the level of effort). This was touted at a meeting and given the approval for further development. At the meeting I specifically asked, "You only maintain this with prompts?" "Yes," they said, "we just iterate through repeated prompts to refine the code."
It has all mostly been abandoned a few months later. Parts of it are being reused, attempting a kind of "work in from the edges" approach to replacing parts of the system, but mostly it's dead.
We are yet to have a postmortem on this whole thing, but I've talked to the developers, and they essentially made a different intractable problem of repeated prompting breaking existing features when attempting to apply fixes or add features. And breaking in really subtle and hard to discern ways. The AI created unit tests didn't often find these bugs, either. They really tried a lot of angles trying to sort it out - complex .md files, breaking up the monolith to make the AI have less context to track, gross simplification of existing features, and so on. These are smarty-pants developers, too, people who know their stuff, got better than BS's, and they themselves were at first surprised at their success, then not so surprised later at the eventual result.
There was also a cost angle that became intractable. Coding like that was expensive. There was a lot of hand-wringing from managers over how much it was costing in "tokens" and whatever else. I pointed out if it's less cost than 7 years of development you're ahead of the game, which they pointed out it would be a cost spread over 7 years, not in 1 year. I'm not an accountant, but apparently that makes a difference.
I don't necessarily consider it a failed experiment, because we all learned a lot about how to better do our software development with AI. They swung for the fences but just got a double.
Of course this will all get better, but I wonder if it'll ever get there like we envision, with the Star Trek, "Computer, made me a sandwich," method of software development. The takeaway from all this is you still have to "know your code" for things that are non-trivial, and really, you can go a few steps above non-trivial. You can go a long way not looking to close at the LLM output, but there is a point at which it starts to be friction.
As a side note, not really related to the OP, but the UI cooked up by the LLMs was an interesting "card" looking kind of thing, actually pretty nice to look at and use. Then, when searching for a wiki for the Ball x Pit game, I noticed that some of the wikis very closely resembled the UI for the application. Now I see variations of it all over the internet. I wonder if the LLMs "converge" on a particular UI if not given specific instructions?
Nothing speciail will happen when things are built "this way". People will just be used to lower quality, like they've been used to enshittified software for the past two decades.
No "artisans" will be employed to fix any mess. The mess will be our software baseline going forward.
You missed out the most crucial and least likely requirement (assuming you're not self employed); management also need to be able to see through the bs.
"I am sick of articles about the cloud!"
"Anyone know of message boards where discussing cloud compute is banned?"
"Businesses will not trust the cloud!"
Aside from logistics of food and medicine, most economic activity is ephemeral wank.
It's memes. It's a myth. Allegory.
These systems are electrical state in machines and they can be optimized at the hardware layer.
Your Python or Ruby or whatever you ship 9,000 layers of state and abstraction above the OS running in the data center has little influence on how these systems actually function.
To borrow from poker; software engineers were being handed their hat years ago. It's already too late.
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.
Even just some AI-assisted development in the trickier parts of my code bases completely robs me of understanding. And those are the parts that need my understanding the most!
I find it strange to compare the comment sections for AI articles with those about vim/emacs etc.
In the vim/emacs comments, people always state that typing in code hardly takes any time, and thinking hard is where they spend their time, so it's not worth learning to type fast. Then in the AI comments, they say that with AI writing the code, they are free'd up to spend more time thinking and less time coding. If writing the code was the easy part in the first place, and wasn't even worth learning to type faster, then how much value can AI be adding?
Now, these might be disjoint sets of people, but I suspect (with no evidence of course) there's a fairly large overlap between them.
CI is failing. It passed yesterday. Is there a flaky API being called somewhere? Did a recent commit introduce a breaking change? Maybe one of my third-party dependencies shipped a breaking change?
I was going to work on new code, but now I have to spend between 5 minutes and an hour+ - impossible to predict - solving this new frustration that just cropped up.
I love building things and solving new problems. I'd rather not have that time stolen from me by tedious issues like this... especially now I can outsource the CI debugging to an agent.
These days if something flakes out in CI I point Claude Code at it and 90% of the time I have the solution a couple of minutes later.
I wonder how much it comes down to that divide. I also wonder how true that is, or if they’re just more trusting that the function does what its name implies the way they think it should.
I suspect you, like me, feel more comfortable with code we’ve written than having to review totally foreign code. The rate limit is in the high level design, not in how fast I can throw code at a file.
It might be a difference in cognition, or maybe we just have a greater need to know precisely how something works instead of accepting a hand wavey “it appears to work, which is good enough”.
I tend to believe that, in all things, the quality of the output and how it is received is what matters and not the process that leads to producing the output.
If you use an LLM assisted workflow to write something that a lot of people love, then you have created art and you are a great artist. It's probable that if Tolkien was born in our time instead of his, he'd be using modern tools while still creating great art, because his creative mind and his work ethic are the most important factors in the creative process.
I'm not of the opinion that any LLM will ever provide quality that comes close to a master work by itself, but I do think they will be valuable tools for a lot of creative people in the grueling and unrewarding "just make it exist first" stage of the creative process, while genius will still shine as it always has in the "you can make it good later" stage.
1. That prompt is always a slot machine. It's never 100% deterministic and that's why we haven't seen an explosion of claude skills. When it works for you, and it's magical, everyone is wowed. However, there is a set of users who then bang their head, wondering why their identical attempt is garbage compared to their coworker. "It must be a skills issue." No, it's just the LLM being an LLM.
2. Coding agents are hyper localized and refuse to consider the larger project when it solves something. So you end up with these "paper cuts" of duplicated functions or classes that do one thing different. Now the LLM in future runs has to decide which of these classes or functions to use and you end up with two competing implementations. Future you will bang your head trying to figure out how to combine them.
3. The "voice" of the code it outputs is trained on public repositories so if your internal codebase is doing something unique, the LLM will consistently pick the voice it's trained on, forcing you to rewrite behind it to match your internal code.
4. It has no chill. If I set any "important" rules in the prompt then it sometimes adheres to it at the expense of doing the "right" thing in its changes. Or it completely ignores it and does its own thing, when it would have been the perfect time to follow the rule. This is to your point that, if I had just written the code myself, it would have been less words than any "perfect" prompt it would have taken to get the same code change.
Now, some program may be considered art (e.g. codegolf) or considered art by their creator. I consider my programs and code are only the means to get the computer to do what it wants, and there are also easy way to ensure that they do what we want.
> Frodo and Sam having an argument over the trustworthiness of Gollum. Frodo should be defending Gollum and Sam should be on his side.'
Is exactly what programs are. Not the minutiae of the language within.
Yeah, this was always the easy part.
When you're ready, maybe you've done some POC in areas you were unsure, maybe some good skeletons work to see a happy path draw a shadow of s solution, iterate over your plans and then put some real "code"/foundation in place.
It's a beautiful process. Starting out I used to just jump into s project deep with the code first and hit that workaround button one too many times and it's far more expensive, we all know that.
To take it back to your example, let's imagine Tolkien is spending a ton of time on setting up his typewriter, making sure he had his correction tape handy, verifying his spelling and correcting mistakes, ensuring his tab stops were setup to his writing standard, checking for punctuation marks, etc. Now imagine eliminating all that crap so he can focus on the artistic nature of the dialogue.
Sometimes you are writing a marketing copy for a new Nissan that's basically the same as last year Nissan, yet you need to sell it somehow. Nobody will REALLY read it more than 2 seconds and your words will be immediately forgotten. Maybe some AI is good then.
“He’s a liar and a sneak, Mr. Frodo, and I’ll say it plain — he’d slit our throats in our sleep if he thought he could get away with it,” Sam spat, glaring at the hunched figure scrabbling over the stones ahead. “Every word out of that foul mouth is poison dressed up as helpfulness, and I’m sick of pretending otherwise.” Frodo stopped walking and turned sharply, his eyes flashing with an intensity that made Sam take half a step back. “Enough, Sam. I won’t hear it again. I have decided. Sméagol is our guide and he is under my protection — that is the end of it.” Sam’s face reddened. “Protection! You’re protecting the very thing that wants to destroy you! He doesn’t care about you, Mr. Frodo. You’re nothing to him but the hand that carries what he wants!” But Frodo’s expression had hardened into something almost unrecognizable, a cold certainty that brooked no argument. “You don’t understand what this Ring does to a soul, Sam. You can’t understand it. I feel it every moment of every day, and if I say there is still something worth saving in that creature, then you will trust my judgment or you will walk behind me in silence. Those are your choices.” Sam opened his mouth, then closed it, stung as if he’d been struck. He fell back a pace, blinking hard, and said nothing more — though the look he fixed on Gollum’s retreating back was one of pure, undisguised loathing.
Your post feels like the last generation lamenting the new generation. Why can't we just use radios and slide rules?
If you've ever enjoyed the sci-fi genre, do you think the people in those stories are writing C and JavaScript?
There's so much plumbing and refactoring bullshit in writing code. I've written years of five nines high SLA code that moves billions of dollars daily. I've had my excitement setting up dev tools and configuring vim a million ways. I want starships now.
I want to see the future unfold during my career, not just have it be incrementalism until I retire.
I want robots walking around in my house, doing my chores. I want a holodeck. I want to be able to make art and music and movies and games. I will not be content with twenty more years of cellphone upgrades.
God, just the thought of another ten years of the same is killing me. It's so fucking mundane.
The future is exciting.
Bring it.
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.
The below captures this perfectly. The author is trying to explain that vibe-coding their own frameworks lets them actually "understand" the code, while not noticing that the LLM-generated text they used to make this point is talking about cutting and sewing bricks.
> But I can do all of this with the experience on my back of having laid the bricks, spread the mortar, cut and sewn for twenty years. If I don’t like something, I can go in, understand it and fix it as I please, instructing once and for all my setup to do what I want next time.
What I think does change is now you can more easily write components that are tailor made to your problem, and situation. Some of these frameworks are meant to solve problems at varying levels of complexity and need to worry about avoid breaking changes. It’s nice to have the option to develop alternatives that are as sophisticated as your problem needs and not more. But I’m not convinced that it’s always the right choice to build something custom.
Now look at the cross team collaboration and it gets even harder without frameworks. When every team has their own conventions, how would they communicate and work together? Imagine a website with React, Vue, Angular all over the place, all fighting for the same DOM.
You can probably tell with a high certainty, from the API in an hour or so.
I did asked AI to generate landing page. This gave me the initial headers, footers and styles that I used for my webapp but I threw away everything else.
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.
You can put it another way: If my customers lose data because of a nasty bug and it was because there was an error in the compiler, it wasn't my fault (unless I chose some unfinished hobby compiler with no reputation at all). If my AI assistant wrote the bug and I didn't spot it, the bug was definitely my fault and is fully my responsibility.
"It wasn't me, my AI assistant did it" is a lousy excuse.
However:
> ..it can probably be used for AI programmers using temperature 0.0 as well, just one abstraction level higher.
Right, but... approximately zero users of AI for coding are setting temperature to 0 not to mention changing temperature at all. So this is a comparison to a world that doesn't really exist.
Additionally, C code compiles much much closer to the same assembly and microcode regardless of compiler as compared to temperature zero prompts across different AIs.
Maybe using AI assistant instead of directly writing code is equivalent to using a high level language instead of assembly and maybe it isn't. So at least begin your discussion as "I think programmers who don't use AI are like programmers who insist on assembly rather than a high level language" (and they existed back in the day). I mean, an "honest question" is one where you are honestly unsure whether you will get an answer or what the answer will be. That's completely different from honestly feeling your opponents have no good arguments. Just about the opposite, really.
By the way, the reason I view AI assistants and high level language compilers as fundamentally different is that high level languages compilers are mostly deterministic, mostly you can determine both the code generated and the behavior of code in terms of the high level language. AI created/assisted code is fundamentally undermined relative to the source (a prompt) on a much wider basis than the assembly created by a high level language compiler (whose source is source code).
Edit: formatting
what?
So that creates the notion as if the design was something out of reach. I met developers now who cannot develop anything on their own if it doesn't have a ticket that explains everything and hand holds them. If something is not clear they are stuck and need help of senior engineers.
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
The trend of copying code from StackOverflow has just evolved to the AI era now.
I also expect people will attempt complete rewrites of systems without fully understanding the implications or putting safeguards in place.
AI simply becomes another tool that is misused, like many others, by unexperienced developers.
I feel like nothing has changed on the human side of this equation.
Which are often the top reason to use a framework at all.
I could re-implement a web frame work in python if I needed to but then I would lose all the testing, documentation, middle-ware and worst of all the next person would have to show up and re learn everything I did and understand my choices.
In recent months, we have MCPs, helping lots of people realize that huh, when services have usable APIs, you can connect them together!
In the current case: AI can do the tedious things for me -> Huh, discarding vast dependency trees (because I previously wanted the tedious stuff done for me too) lessens my risk surface!
They really are discovered truths, but no one's forcing them to come with an understanding of the tradeoffs happening.
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.
With LLM code, I'd rather have higher-level abstractions.
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 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.
What I don't know is what state I'd be in right now, if I'd had AI from the start. There are definitely a ton of brain circuits I wouldn't have right now.
Counterpoint: I've actually noticed them holding me back. I have 20 years of intuition built up now for what is hard and what is easy, and most of it became wrong overnight, and is now limiting me for no real reason.
The hardest part to staying current isn't learning, but unlearning. You must first empty your cup, and all that.
These arguments basically just amount to the intellectual equivalent of hazing. 90% of engineers don’t need to know how these things work to be productive. 90% of engineers will never work on a global scale system. Doing very basic things will work for those engineers. Don’t let perfect be the enemy of good enough.
Also, I’d argue that AI will advance enough to capture system design soon too.
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.
Like the vibe coded solution won't be flawed and vulnerable
https://security.stackexchange.com/questions/209652/why-is-i...
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.
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.
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.
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.
If you use a well regarded library, you can trust that most things in it were done with intention. If an expectation is violated, that's a learning opportunity.
With the AI firehose, you can't really treat it the same way. Bad patterns don't exactly stand out.
Maybe it'll be fine but I still expect to see a lot of code bases saddled with garbage for years to come.
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.
What? Coding agents are very capable at helping fix bugs in specific domains. Your examples are like, the exact place where AI can add value.
You do an update, things randomly break: tell Claude to figure it out and it can go look up the breaking changes in the new versions, read your code and tell you what happened and fix it for you.
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.
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.
Is software even a real industry with patterns, safety, design, performance, review, etc.
Or are we just a hype generating machine that's happy to ship the most broken stuff possible the fastest.
Why do we have to constantly relearn the same lessons.
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.
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.
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.
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)
It's puzzling to me that the author doesn't even mention this huge and obvious benefit of frameworks.
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.
They're used more frequently, I couldn't imagine in python there's more examples of web servers from scratch then using flask or Django?
Frameworks provide a layer of abstraction, so the code is denser, which will use less tokens, and put less code in the prompt.
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.
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.
I talked about it in a currently unfinished blog post, here's the section
"In the 2000s and 2010s, this was the core conflict of frameworks. Does the framework have enough alignment with the task that it would cumulatively simplify things.
However, this is not how we behave. Instead habituation promotes einstellung where we end up relying on the tool of the AI to do the trivial. This is closely related to Automation bias and OOTL."
It's not complete but here it is anyways
https://blog.day50.dev/intro/vibedrift/
Things like the einstellung effect are important in vibe coding, software design and framework use. It's a truism about meta tool use and the relationships and behavior systems that accompany them along with the epistemological edifices they prop up. Quoting Wikipedia:
"After solving many problems which had the same solution, subjects applied the same solution to later problems even though a simpler solution existed"
I should get back and finish it probably by this week.
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.
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.
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 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
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?
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.
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.
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.
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.
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.
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?
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.
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?
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?
The main burden I see is validation of the output and getting reproducable results. As with many AI solutions.
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.
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.
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.
if you want something specific without ever-changing needs, it makes sense to do it with fewer dependencies as possible. this should be even more ideal if you believe the code made is of high quality, as it reduces the pain of updating the project for non-functional reasons.
this sentiment ironically goes against the existence of these services, as they themselves are always working on matching the ever-changing dependencies to give the impression of a stable platform.
only if it was possible to have the cake and eat it too
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.
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.
I run a dev community of ~1500 devs. The ones getting the most out of agents aren't throwing away frameworks. They're offloading the stuff nobody enjoys. OAuth scope spelunking, boilerplate migrations, flaky test debugging. That's where agents shine.
The actual risk nobody talks about: if you've never manually debugged a race condition, you won't catch it when the agent introduces one. Agents amplify what you already know. They don't replace knowing things.
Why wouldn't you clone frameworks code into your repository, removing parts you don't need, modifying code as you wish?
> 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.
I will never significantly code by hand again and probably won't be hired in 5 years.
It's now cheaper to try diving into a system to change it, opposed to the 'safe' path to built on-top-off and adapt to it.
So the answer is to let AI agents design it for you, trained on the data of the giants of software engineering. Got it!
Not using a framework means creating and maintaining a new and bad one.
And the AI doesn’t even do that. They repeat and create new complexity
Oh, you accepted that? I feel sorry for you. Many of us never did.
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...
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.
Wouldn't everything that agents produce be better described as a "layer of garbage?"
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.
However, I think I understand where the author's coming from based on this line:
> I’ve been building a product from the ground up. Not the “I spun up a Next.js template” kind of ground up
Next.JS is the pinnacle of JavaScript-on-the-backend frameworks, and it's kind of pathetic compared to what Rails or Django give you. You still have a lot of thinking to do, so I posit (as I have for some time) that using Next.JS vs using NodeJS directly gives humans very little productivity boost. I think people just know that frameworks are a good thing in general, and never realized that the JavaScript offerings weren't that powerful.
I recently migrated from my YOURLS install to just having an Apache2 config with some scripts to append to it: https://blog.kronis.dev/blog/sometimes-dropbox-is-just-ftp-b...
Sometimes you don't need "serious" bullshit like Spring Boot either but something more minimalist is more than enough. Though I think it can only work well when you have enough usable primitives, e.g. I've written software in Go that has minimal dependencies and it only worked so well thanks to both the language being relatively simple AND also having a really strong standard library.
The moment when someone tries to write a web server from scratch in a collaborative environment (e.g. project at work with deadlines), I'm peacing the fuck out of there. And in my experience, trying to make design systems or frameworks from scratch leads to a pretty bad mess, because people miss all sorts of inherent complexity until it comes around to bite them later.
I guess what I'm saying is that there's quite the difference between what you do for your own projects, vs what is most likely to lead to long term success in a group setting, especially in 1-2 pizza teams - evaluate the benefits vs risks when considering using vs building.
I'm also a bit blind to this when it comes to certain things, look at this funny video: https://www.youtube.com/watch?v=40SnEd1RWUU I would still prefer to use self-hostable software so I know more of the stack and have control and possibly some cost savings vs someone who'd just fork over a bunch of cash to a SaaS / PaaS vendor.
What frameworks and what have you accomplished with it?
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".
So just because we now have "automated programming" agents, every project should eschew the use of a known, tested set of libraries or an entire framework and instead build everything from the ground up? That is insane.
