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").
I would argue that it's going to be the opposite. At re:Invent, one of the popular sessions was in creating a trio of SRE agents, one of which did nothing but read logs and report errors, one of which did analysis of the errors and triaged and proposed fixes, and one to do the work and submit PRs to your repo.
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 agree with both you and the GP. Yes, coding is being totally revolutionized by AI, and we don't really know where the ceiling will be (though I'm skeptical we'll reach true AGI any time soon), but I believe there still an essential element of understanding how computer systems work that is required to leverage AI in a sustainable way.
There is some combination of curiosity of inner workings and precision of thought that has always been essential in becoming a successful engineer. In my very first CS 101 class I remember the professor alluding to two hurdles (pointers and recursion) which a significant portion of the class would not be able to surpass and they would change majors. Throughout the subsequent decades I saw this pattern again and again with junior engineers, bootcamp grads, etc. There are some people no matter how hard they work, they can't grok abstraction and unlock a general understanding of computing possibility.
With AI you don't need to know syntax anymore, but to write the write prompts to maintain a system and (crucially) the integrity of its data over time, you still need this understanding. I'm not sure how the AI-native generation of software engineers will develop this without writing code hands-on, but I am confident they will figure it out because I believe it to be an innate, often pedantic, thirst for understanding that some people have and some don't. This is the essential quality to succeed in software both in the past and in the future. Although vibe coding lowers the barrier to entry dramatically, there is a brick wall looming just beyond the toy app/prototype phase for anyone without a technical mindset.
It's nice that AI can fix bugs fast, but it's better to not even have bugs in the first place. By using someone else's battle tested code (like a framework) you can at least avoid the bugs they've already encountered and fixed.
I spent Dry January working on a new coding project and since all my nerd friends have been telling me to try to code with LLM's I gave it a shot and signed up to Google Gemini...
All I can say is "holy shit, I'm a believer." I've probably got close to a year's worth of coding done in a month and a half.
Busy work that would have taken me a day to look up, figure out, and write -- boring shit like matplotlib illustrations -- they are trivial now.
Things that are ideas that I'm not sure how to implement "what are some different ways to do this weird thing" that I would have spend a week on trying to figure out a reasonable approach, no, it's basically got two or three decent ideas right away, even if they're not perfect. There was one vectorization approach I would have never thought of that I'm now using.
Is the LLM wrong? Yes, all the damn time! Do I need to, you know, actually do a code review then I'm implementing ideas? Very much yes! Do I get into a back and forth battle with the LLM when it gets starts spitting out nonsense, shut the chat down, and start over with a newly primed window? Yes, about once every couple of days.
It's still absolutely incredible. I've been a skeptic for a very long time. I studied philosophy, and the conceptions people have of language and Truth get completely garbled by an LLM that isn't really a mind that can think in the way we do. That said, holy shit it can do an absolute ton of busy work.
I'm (mostly) a believer too, and I think AI makes using and improving these existing frameworks and libraries even easier.
You mentioned matplotlib, why does it make sense to pay for a bunch of AI agents to re-invent what matplotlib does and fix bugs that matplotlib has already fixed, instead of just having AI agents write code that uses it.
In practice using someone else’s framework means you’re accepting the risk of the thousands of bugs in the framework that have no relevance to your business use case and will never be fixed.
Sure, if all you ask it to do is fix bugs. You can also ask it to work on code health things like better organization, better testing, finding interesting invariants and enforcing them, and so on.
I have some healthy skepticism on this claim though. Maybe, but there will be a point of diminishing returns where these refactors introduce more problems than they solve and just cause more AI spending.
Code is always a liability. More code just means more problems. There has never been a code generating tool that was any good. If you can have a tool generate the code, it means you can write something on a higher level of abstraction that would not need that code to begin with.
AI can be used to write this better quality / higher level code. That's the interesting part to me. Not churning out massive amounts of code, that's a mistake.
I agree but want to interject that "code organization " won't matter for long.
Programming Languages were made for people. I'm old enough to have programmed in z80 and 8086 assembler. I've been through plenty of prog.langs. through my career.
But once building systems become prompting an agent to build a flow that reads these two types of excels, cleans them,filters them, merges them and outputs the result for the web (oh and make it interactive and highly available ) .
Code won't matter. You'll have other agents that check that the system is built right, you'll have agents that test the functionality and agents that ask and propose functionality and ideas.
Most likely the Programming language will become similar to the old Telegraph texts (telegrams) which were heavily optimized for word/token count. They will be optimized to be LLM grokable instead of human grokable.
Automatically solving software application bugs is one thing, recovering stateful business process disasters and data corruption is entirely another thing.
Customer A is in an totally unknown database state due to a vibe-coded bug. Great, the bug is fixed now, but you're still f-ed.
There are people out there who truly believe that they can outsource the building of highly complex systems by politely asking a machine, and ultimately will end up tasking the same machine to tell them how these systems should be built.
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?
The article gets at this briefly and moves on: "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."
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.
> instructing once and for all my setup to do what I want next time.
This works up to a point, but eventually your "setup" gets complicated, some of your demands conflict, or have different priorities, and you're relying on the AI to sort it out the way you expect.
> any use of AI, or indeed, any form of outsourcing
Oh that's a good analogy/categorization, I hadn't thought about it in those terms yet. AI is just the next cheaper thing down from the current southeast asian sweatshop labor.
The naysayers said we’d never even get to this point. It’s far more plausible to me that AI will advance enough to de-slopify our code than it is to me that there will be some karmic reckoning in which the graybeards emerge on top again.
What point have we reached? All I see is HN drowning in insufferable, identical-sounding posts about how everything has changed forever. Meanwhile at work, in a high stakes environment where software not working as intended has actual consequences, there are... a few new tools some people like using and think they may be a bit more productive with. And the jury's still out even on that.
The initial excitement of LLMs has significantly cooled off, the model releases show rapidly diminishing returns if not outright equilibrium and the only vibe-coded software project I've seen get any actual public use is Claude Code, which is riddled with embarrassing bugs its own developers have publicly given up on fixing. The only thing I see approaching any kind of singularity is the hype.
I think I'm done with HN at this point. It's turned into something resembling moltbook. I'll try back in a couple of years when maybe things will have changed a bit around here.
> The initial excitement of LLMs has significantly cooled off, the model releases show rapidly diminishing returns if not outright equilibrium and the only vibe-coded software project I've seen get any actual public use is Claude Code, which is riddled with embarrassing bugs its own developers have publicly given up on fixing. The only thing I see approaching any kind of singularity is the hype.
I am absolutely baffled by this take. I work in an objectively high stakes environment (Big 3 cloud database provider) and we are finally (post Opus 4.5) seeing the models and tools become good enough to drive the vast majority of our coding work. Devops and livesite is a harder problem, but even there we see very promising results.
I was a skeptic too. I was decently vocal about AI working for single devs but could never scale to large, critical enterprise codebases and systems. I was very wrong.
I do not await the day where the public commons is trashed by everyone and their claudebot, though perhaps the segmentation of discourse will be better for us in the long run given how most social media sites operate.
I am not in a high stakes environment and work on a one-person size projects.
But for months I have almost stopped writing actual lines of code myself.
Frequency and quality of my releases had improved.
I got very good feedback on those releases from my customer base, and the number of bugs reported is not larger than on a code written by me personally.
The only downside is that I do not know the code inside out anymore even if i read it all, it feels like a code written by co-worker.
The AI agents can ALREADY "de-slopify" the code. That's one of the patterns people should be using when coding with LLMs. Keep an agent that only checks for code smells, testability, "slop", scalability problems, etc. alongside whatever agent you have writing the actual code.
> The naysayers said we’d never even get to this point. It’s far more plausible to me that AI will advance enough to de-slopify our code than it is to me that there will be some karmic reckoning in which the graybeards emerge on top again.
"The naysayers"/"the graybeards" have never been on top.
If they had been, many of the things the author here talks about getting rid of never would've been popular in the first place. Giant frameworks? Javascript all the things? Leftpad? Rails? VBA? PHP? Eventually consistent datastores?
History is full of people who successfully made money despite the downsides of all those things because the downsides usually weren't the most important thing in the moment of building.
It's also full of people who made money cleaning it all up when the people who originally built it didn't have time to deal with it anymore. "De-slopify" is going to be a judgment question that someone will need to oversee, there's no one-size-fits-all software pattern, and the person who created the pile of code is unlikely to be in a position to have time to drive that process.
Step 1: make money with shortcuts
Step 2: pay people to clean up and smooth out most of those shortcuts
I've bounced between both roles already a lot due to business cycles of startup life. When you're trying to out-scale your competitor you want to find every edge you can, and "how does this shit actually work" is going to be one of those edges for making the best decisions about how to improve cost/reliability/perf/usability/whatever. "It doesn't matter what the code looks like" is still hard to take seriously compared to the last few iterations of people pitching tools claiming the same. The turnaround loop of modifying code is faster now; the risk of a tar-pit of trying to tune on-the-fly a pile of ill-fitting spaghetti is not. It's gonna be good enough for a lot of people, Sturgeon's law - e.g. most people aren't great at knowing what usefully-testable code looks like. So let's push past today's status quo of software.
If I was working on a boring product at a big tech co I'd be very worried, since many of those companies have been hiring at high salaries for non-global-impact product experiments that don't need extreme scale or shipping velocity. But if you want to push the envelope, the opportunity to write code faster should be making you think about what you can do with it that other people aren't yet. Things beyond "here's a greenfield MVP of X" or "here's a port of Y."
I find that instructing AI to use frameworks yields better results and sets you up for a better outcome.
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. For area where you can use tested and tried libraries (or tools in general) LLMs will generate better code when they use them.
In fact, LLMs will be better than humans in learning new frameworks. It could end up being the opposite that frameworks and libraries become more important with LLMs.
Yeah, I don't know why you'd drop using frameworks and libraries just because you're using an LLM. If you AREN'T using them you're just loading a bunch of solved problems into the LLMs context so it can re-invent the wheel. I really love the LLM because now I don't need to learn the new frameworks myself. LLMs really remove all the bullshit I don't want to think about.
> In fact, LLMs will be better than humans in learning new frameworks.
LLMs don't learn? The neural networks are trained just once before release and it's a -ing expensive process.
Have you tried using one on your existing code base, which is basically a framework for whatever business problem you're solving? Did it figure it out automagically?
They know react.js and nest.js and next.js and whatever.js because they had humans correct them and billions of lines of public code to train on.
Wouldn't there be a chicken and egg problem once humans stop writing new code directly? Who would write the code using this new framework? Are the examples written by the creators of the framework enough to train an AI?
> LLMs will be better than humans in learning new frameworks.
I don't see a base for that assumption. They're good at things like Django because there is a metric fuckton of existing open-source code out there that they can be trained on. They're already not great at less popular or even fringe frameworks and programming languages. What makes you think they'll be good at a new thing that there are almost no open resources for yet?
LLMs famously aren’t that good at using new frameworks/languages. Sure they can get by with the right context, but most people are pointing them at standard frameworks in common languages to maximize the quality of their output.
This is not my experience any longer. With properly set feedback loop and frameworks documentation it does not seem to matter much if they are working with completely novel stuff or not. Of course, when that is not available they hallucinate, but who anymore does that even? Anyone can see that LLMs are just glorified auto-complete machines, so you really have to put a lot of work in the enviroment they operate and quick feedback loops. (Just like with 90% of developers made of flesh...)
I'm no fan of AI in terms of its long term consequences, but being able to "just do things" with the aid of AI tools, diving head first into the most difficult programming projects, is going to improve the human programming skills worldwide to levels never before imaginable
I have to stretch your analogy in weird ways to make it function within this discussion:
Imagine two people who have only sat in a chair their whole lives. Then, you have one of them learn how to drive a car, whereas the other one never leaves the chair.
The one who learned how to drive a car would then find it easier to learn how to run, compared to the person who had to continue sitting in the chair the whole time.
I've found AI handy as a sort of tutor sometimes, like "I want to do X in Y programming language, what are some tools / libraries I could use for that?" And it will give multiple suggestions, often along with examples, that are pretty close to what I need.
The aspect of "potentially secure/stable code" is very interesting to me. There's an enormous amount of code that aren't secure or stable already (I'd argue virtually all of the code in existence).
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.
Have you considered that betting against the models and ecosystem improving might be a bad bet, and you might be the one who is in for a rude awakening?
I agree. We've been assured by these skeptics that models are stochastic parrots, that progress in developing them was stalling, and that skills parity with senior developers was impossible - as well as having to listen to a type of self-indulgent daydreaming relish about the eventual catastrophes companies adopting them would face. And perhaps eventually these skeptics will turn out to be right. Who knows at this stage. But at this stage, what we're seeing is just the opposite: significant progress in model development last year, patterns for use being explored by almost every development team without widespread calamity and the first well-functioning automated workflows appearing for replacing entire teams. At this stage, I'd bet on the skeptics being the camp to eventually be forced to make the hard adjustments.
My expectation is that there'll never be a single bust-up moment, no line-in-the-sand beyond which we'll be able to say "it doesn't work anymore."
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.
Maybe software systems will become more like biological organisms. Huge complexity with parts bordering on chaos, but still working reasonably well most of the time, until entropy takes its course.
Why does there seem to be such a divide in opinions on AI in coding? Meanwhile those who "get it" have been improving their productivity for literally years now.
There's a lot of reasons. There's a lot of breadth to "software engineering" (FAANG, web dev, embedded, OS, small business, etc.)
I'm sure there are some places where LLMs are bad due to lack of training data. There are some places where the LLMs are bad because the code base is terrible (and there's always "rockstars" at these jobs that severely overestimate their skills because they're always the one fixing the mess... which they also probably caused). Some devs/engineers feel threatened. Many devs/engineers think they're special and super smart so surely no machine can do their job.
- What you are working on. AI is better at solving already solved problems with lots of examples.
- How fast/skilled you were before. If you were slow before then you got a bigger speed up. If AI can solve problems you can’t you unlock new abilities
- How much quality is prioritized. You can write quality, bug free code with AI but it takes longer and you get less of a boost.
- How much time you spend coding. If a lot of your job is design/architecture/planning/research then speeding up code generation matters less
- How much you like coding. If you like coding then using AI is less fun. If you didn’t like coding then you get to skip a chore
- How much you care about deeply understanding systems
- How much you care about externalities: power usage, data theft, job loss, etc.
- How much boilerplate you were writing before
I’m sure that’s not a complete list but they are a few things I’ve seen as dividers
This comment ignores the key insight of the article. Design is what matters most now. Design is the difference between vibe coding and software engineering.
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.
>software engineers today are 100x more productive
Somebody needs to explain to my lying eyes where these 100xers are hiding. They seem to live in comments on the internet, but I'm not seeing the teams around me increase their output by two orders of magnitude.
They are the people who have the design sense of someone like Rob Pike but lack his coding skill. These people are now 100x more capable than they were previously.
"we have taken latest AI subscription. We expect you to be able to increase productivity and complete 5/10/100 stories per sprint from now on instead of one per sprint that we planned previously".
Citation needed. For both the existence of said people (how do you develop said design sense without a ton of coding experience?) and that they are 100x more productive.
You still "find most stuff by building/struggling". You just move up stack.
> 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.
Business has been operating on a management/executive culture for many decades now.
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.
Yeah I completely disagree with the author actually, but also with you.
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.
Back in the 00s people like you were saying "no one will put their private data in the cloud!"
"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.
The future is already here. Been working a few years at a subsidiary of a large corporation where the entire hierarchy of companies is pushing AI hard, at different levels of complexity, from office work up through software development. Regular company meetings across companies and divisions to discuss methods and progress. Overall not a bad strategy and it's paying dividends.
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?
This is the siren song of llm. "Look how much progress we made"
Effort increases as time to completion decreases. The last 10% of the project takes 90% of the effort as you try to finish up, deploy,integrate and find the gaps.
Llms are woefully incapable of that as that knowledge doesn't exist in a markdown file. It's in people's heads and you have to pry it out with a crowbar or as happens to so many projects, they get released and no one uses it.
See Google et Al. "We failed to find market fit on the 15th iteration of our chat app, we'll do better next time"
I've noticed this in my small scale tests. Basically the larger the prompt gets (and it includes all the previously generated code because that's what you want to add features to), the more likely is that the LLM will go off the rails. Or forget the beginning of the context. Or go into a loop.
Now if you're using a lot of separate prompts where you draw from whatever the network was trained on and not from code that's in the prompt, you can get usable stuff out of it. But that won't build you the whole application.
Come to the redteam / purpleteam side. We're having fun times right now. The definition of "every software has bugs" is now on a next level, because people don't even care about sql injection anymore. It's right built into every vibecoded codebase.
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.
> 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.
To be blunt, I think it's a form of mania that drives someone to reject human-written code in favor of LLM-generated code. Every time I read writing from this perspective that exceeds a paragraph, I quickly realize the article itself was written by an LLM. When they automate this much writing, it makes me wonder how much of their own reading they automate away too.
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.
I think the bit you quoted is a tie in with an earlier bit:
“ I can be the architect without the wearing act of laying every single brick and spreading the mortar. I can design the dress without the act of cutting and sewing each individual piece of fabric”
To me, this text doesn’t read as being entirely written by an LLM, there is definitely an air of LLM about it though, so maybe the first draft was.
Correct. The history is rife with examples of manias taking hold of societies, I recommend "Memoirs of Extraordinary Popular Delusions and the Madness of Crowds" by Charles Mackay[1], it's an absolutely fascinating book.
Yeah the “not invented here” syndrome was considered an anti pattern before the agentic coding boom and I don’t see how these tools make it irrelevant. If you’re starting a business, it’s still likely a distraction if you’re writing all of the components of your stack from scratch. Agentic tools have made development less expensive, but it’s still far from zero. By the author’s admission, they still need to think through all these problems critically, architect them, pick the right patterns. You also have to maintain all this code. That’s a lot of energy that’s not going towards the core of your business.
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.
my problem with frameworks has always been that the moment I want to do something the framework writers aren't interested in, I now have three problems: my problem, how to implement it in the underlying platform and how to work around the framework to not break my feature.
Yes this happens in every framework I've ever used. My approach used to be to try to work around it, but now I've got these local exceptions to what the framework does and that is inevitably where problems/bugs pop up. Now I simply say "we can't implement the feature that way in this framework, we need to rework the specification." I no longer try to work against the framework, it's just a massive time sink and creates problems down the road.
It's like designing a kitchen and you don't make all the spaces some multiple of three inches. Now, standard cabinets and appliances will not fit. You will be using filler panels or need custom cabinetry. And anyone who later wants countertops or different cabinets will be working around this design too. Just follow the established standard practices.
I'm so glad software engineering isn't my job. I love solving problems, and I'm somewhat better at using code to do it than my peers (fellow scientists), but I would hate to have a boss/client that says "it needs to do X" and the framework writer (or SDK, ala Android/Xcode) say "no, that hurts my profits/privacy busting".
after 3 decades as SWE I mostly found both i) and ii) to not be true, for the most part. a lot of frameworks are not built from the ground up as “i am building a thing to solve x” but “i had a thing and built something that may (or may not) be generally useful.” so a lot of them carry weight from what they were originally built from. then people start making requests to mold the framework to their needs, some get implemented, some don’t. those that don’t good teams will build extensions/plugins etc into the framework and pretty soon you got a monster thing inside of your codebase you probably did not need to begin with. i think every single ORM that i’ve ever used fits this description.
And there was a time when using libraries and frameworks was the right thing to do, for that very reason. But LLMs have the equivalent of way more experience than any single programmer, and can generate just the bit of code that you actually need, without having to include the whole framework.
As someone who’s built a lot of frontend frameworks this isn’t what I’ve found. Instead I’ve found that you end up with the middle ground choice which while effective is no better than the externally maintained library of choice. The reason to build your own framework is so it’s tailor suited to your use cases. The architecting required to do that LLMs can help with but you have to guide them and to guide them you need expertise.
> can generate just the bit of code that you actually need
Design is the key. Codebases (libraries and frameworks not exempt,) have a designed uniformity to them. How does a beginner learn to do this sort of design? Can it be acquired completely by the programmer who uses LLMs to generate their code? Can it be beneficial to recognize opinionated design in the output of an LLM? How do you come to recognize opinion?
In my personal history, I've worked alongside many programmers who only ever used frameworks. They did not have coding design sensibilities deeper than a social populist definition of "best practice." They looked to someone else to define what they can or cannot do. What is right to do.
I would like a more reliable way to activate this "way more experience."
What I see in my own domain I often recognize as superficially working but flawed in various ways. I have to assume the domains I am less familiar are the same.
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.
Your last sentence describes my thoughts exactly. I try to incorporate Claude into my workflow, just to see what it can do, and the best I’ve ended up with is - if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better.
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 dont really understand how this is possible. I've built some very large applications, and even a full LLM data curation,tokenizer, pretrain, posttrain SFT/DPO pipeline with LLM's and it most certainly took far less time than if i had done it manually. Sure it isnt all optimal...but it most certainly isnt subpar, and it is fully functional
That is what's hard about transitioning from coder to lead. A good coder makes full use of a single thread of execution. A good lead effectively handles the coordination of multiple threads. Different skills.
An LLM coding assistant today is an erratic junior team member, but its destructive potential is nowhere near some of the junior human engineers I've worked with. So it's worth building the skills and processes to work with them productively. Today, Claude is a singular thing. In six months or a year, it'll be ten or a hundred threads working concurrently on dozens of parts of your project. Either you'll be comfortable coordinating them, or you'll nope out of there and remain an effective but solitary human coder.
I use conductor with git worktrees and will literally have 10 or 20 running at a time getting pinged as they finish stuff for me to review, mostly getting rid of small ticket and doing random POCs while I focus on bigger stuff, the bottleneck has literally become the company doesn't have enough stuff to give me. It only really works however because I have a lot of context and understanding of the codebase. It's already here.
Are you giving it huge todos in one prompt or working modularly?
Claude set up account creation / login with SSO login, OTP and email notifications in like 5 mins and told me exactly what to do on the provider side. Theres no way that wouldn't have taken me few hours to figure out
There is no way its not faster at a large breadth of the work, unless youre maybe a fanatic with reviewing and nitpicking every line of code to the extreme
> if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better.
I believe the argument from the other camp is that you don't need to understand the code anymore, just like you don't need to understand the assembly language.
Of all the points the "other side" makes, this one seems the most incoherent. Code is deterministic, AI isn’t. We don’t have to look at assembly, because a compiler produces the same result every time.
If you only understand the code by talking to AI, you would’ve been able to ask AI “how do we do a business feature” and ai would spit out a detailed answer, for a codebase that just says “pretend there is a codebase here”. This is of course an extreme example, and you would probably notice that, but this applies at all levels.
Any detail, anywhere cannot be fully trusted. I believe everyone’s goal should be to prompt ai such that code is the source of truth, and keep the code super readable.
If ai is so capable, it’s also capable of producing clean readable code. And we should be reading all of it.
“Of all the points the other side makes, this one seems the most incoherent. Code is deterministic, AI isn’t. We don’t have to look at assembly, because a compiler produces the same result every time.”
This is a valid argument. However, if you create test harnesses using multiple LLMs validating each other’s work, you can get very close to compiler-like deterministic behavior today. And this process will improve over time.
It helps, but it doesn't make it deterministic. LLMs could all be misled together. A different story would be if we had deterministic models, where the exact same input always results in the exact same output. I'm not sure why we don't try this tbh.
Are you sure that it’s T=0. My comment’s first draft said “it can’t just be setting temp to zero can it?” But I felt like T is not enough. Try running the same prompt in new sessions with T=0, like “write a poem”. Will it produce the same poem each time? (I’m not where I can try it currently).
> We don’t have to look at assembly, because a compiler produces the same result every time.
This is technically true in the narrowest possible sense and practically misleading in almost every way that matters. Anyone who's had a bug that only manifests at -O2, or fought undefined behavior in C that two compilers handle differently, or watched MSVC and GCC produce meaningfully different codegen from identical source, or hit a Heisenbug that disappears when you add a printf ... the "deterministic compiler" is doing a LOT of work in that sentence that actual compilers don't deliver on.
Also what's with the "sides" and "camps?" ... why would you not keep your identity small here? Why define yourself as a {pro, anti} AI person so early? So weird!
You just described deterministic behavior. Bugs are also deterministic. You don’t get different bugs every time you compile the same code the same way. With LLMs you do.
Re: “other side” - I’m quoting the grandparent’s framing.
> significant extra effort is required to make them reproducible.
Zero extra effort is required. It is reproducible. The same input produces the same output. The "my machine" in "Works on my machine" is an example of input.
> Engineering in the broader sense often deals with managing the outputs of variable systems to get known good outcomes to acceptable tolerances.
You can have unreliable AIs building a thing, with some guidance and self-course-correction. What you can't have is outcomes also verified by unreliable AIs who may be prompt-injected to say "looks good". You can't do unreliable _everything_: planning, execution, verification.
If an AI decided to code an AI-bound implementation, then even tolerance verification could be completely out of whack. Your system could pass today and fail tomorrow. It's layers and layers of moving ground. You have to put the stake down somewhere. For software, I say it has to be code. Otherwise, AI shouldn't build software, it should replace it.
That said, you can build seemingly working things on moving ground, that bring value. It's a brave new world.
That will never happen unless we figure out a far simpler way to prove the system does what it should. If you've ever had bugs crop up with a full test suite you should know this is incredibly hard to do
LLMs can't read your mind. In the end they're always taking the english prompt and making a bunch of fill in the blank assumptions around it. This is inevitable if we're to get any productivity improvements out of them.
Sometimes it's obvious and we can catch the assumptions we didn't want (the div isn't centered! fix it claude!) and sometimes you actually have to read and understand the code to see that it's not going to do what you want under important circumstances
If you want a 100% perfect communication of the system in your mind, you should use a terse language built for it: that's called code. We'd just write the code instead
People who really care about performance still do look at the assembly. Very few people write assembly anymore, a larger number do look at assembly every so often. It’s still a minority of people though.
I guess it would be similar here: a small few people will hand write key parts of code, a larger group will inspect the code that’s generated, and a far larger group won’t do either. At least if AI goes the way that the “other side” says.
>I believe the argument from the other camp is that you don't need to understand the code anymore
Then what stops anyone who can type in their native language to, ultimately when LLM's are perfected, just order their own software instead of using anybody else's (speaking about native apps like video games, mobile phones, desktop, etc.)?
Do they actually believe we'll need a bachelor's degree to prompt program in a world where nobody cares about technical details, because the LLM's will be taking care of? Actually, scratch that. Why would the companies who're pouring gorrilions of dollars in investment even give access to such power in an affordable way?
The deeper I look in the rabbit hole they think we're walking towards the more issues I see.
At least for me, the game-changer was realizing I could (with the help of AI) write a detailed plan up front for exactly what the code would be, and then have the AI implement it in incremental steps.
Gave me way more control/understanding over what the AI would do, and the ability to iterate on it before actually implementing.
Indeed. This is very much the way I use it at work. Present an idea of a design, iterate on it, then make a task/todo list and work through the changes piecemeal, reviewing and committing as I go. I find pair design/discussion practical here too. I expect to see smaller teams working like this in the future.
For small personal projects, it's more vibey.. eg. Home automation native UIs & services for Mac & Windows, which I wouldn't otherwise start.. more itches that can be scratched in my limited time.
sorry for being blunt, but if you have tried once, twice and came to this conclusion, it is definitely a skill issue, I never got comfortable by writing 3 lines of Java, Python or Go or any other language, it took me hundreds of hours spent doing non-sense, failing miserably and finding out that I was building things which already exists in std lib.
> It's strange to me when articles like this describe the 'pain of writing code'.
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.
What I never understand is that people seem to think the conception of the idea and the syntactical nitty gritty of the code are completely independent domains. When I think about “how software works” I am at some level thinking about how the code works too, not just high level architecture. So if I no longer concern myself with the code, I really lose a lot of understanding about how the software works too.
Writing the code is where I discover the complexity I missed while planning. I don't truly understand my creation until I've gone through a few iterations of this. Maybe I'm just bad at planning.
At first I thought you were referring to the debates over using vim or using emacs, but I think you mean to refer to the discussions about learning to use/switching to powerful editors like vim or emacs. If you learn and use a sharp, powerful editor and learn to type fast, the "burden" of editing and typing goes away.
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.
What you’ve described is very much not writing code though. It’s the tedious and unpleasant outcome of having a flaky or under resourced CI setup or pulling in a misbehaving dependency. Neither of those is typing code per se. I don’t think it’s fair to conflate that kind of problem with the creative work involved in implementation itself.
“Writing code is boring and tedious” says more about the speaker than it does about programming.
> I point Claude Code at it and 90% of the time I have the solution a couple of minutes later.
Same experience, I don't know why people keep saying code was easy part, sure, only when you are writing a boilerplate which is easy and expectations are clear.
I agree code is easier than some other parts, but not the easiest, industry employed millions of us, to write that easy thing.
When working on large codebases or building something in the flow, I just don't want to read all the OAuth2 scopes Google requires me to obtain, my experience was never: "now I will integrate Gmail, let me do gmail.FetchEmails(), cool it works, on to the next thing"
You have a solution, I've seen them recommend some pretty terrible bug fixes, especially in the ci realm because they get rather clueless as the perspective gets higher or broader
Incidentally, I've been using AI to deal with the weird bugs, cryptic errors and generally horrendous complexities of a framework we've been using at work (Elixir's Ash). It's really nice to no longer have to read badly organized docs, search the Internet for similar problems and ask around in the developers' Slack/Discord.
So many of my coding agent sessions start with "clone <github URL to relevant dependency> into /tmp for reference" - it's such a great pattern because incomplete or inaccurate decimation matters way less if the agent can dispatch a sub-agent to explore the codebase any time it needs to answer an obscure question.
I was talking to a coworker that really likes AI tooling and it came up that they feel stronger reading unfamiliar code than writing code.
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”.
Current models won't write anything new, they are "just" great at matching, qualifying, and copying patterns. They bring a lot of value right now, but there is no creativity.
You can only complain about creativity if you were actually being creative. 99.99999% of the industry was not.
But sure, for the 0.000001% of the industry coming up with new deep learning algorithms instead of just TF/PyTorch monkey-ing, maybe the LLMs won’t help as much as a good foundation in some pretty esoteric mathematics.
Tolkien's book is an art, programs are supposed to do something.
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.
People are different. Some are painters and some are sculptors. Andy Warhol was a master draftsman but he didn't get famous off of his drawings. He got famous off of screen printing other people's art that he often didn't own. He just pioneered the technique and because it was new, people got excited, and today he's widely considered to be a generational artistic genius.
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.
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 the ends justifies the means is a well-worn disagreement/debate, and I think the only solid conclusion we've come to as a society is that it depends.
That's a moral debate, not suitable for this discussion.
The discussion at hand is about purity and efficiency. Some people are process oriented, perfectionists, purists that take great pride in how they made something. Even if the thing they made isn't useful at all to anyone except to stroke their own ego.
Others are more practical and see a tool as a tool, not every hammer you make needs to be beautiful and made from the best materials money can buy.
Depending on the context either approach can be correct. For some things being a detail oriented perfectionist is good. Things like a web framework or a programming language or an OS. But for most things, just being practical and finding a cheap and clever way to get to where you want to go will outperform most over engineering.
It sure is myopic to think that the debate over if the ends justifies the means is solely a moral consideration, and then literally list cases where the value of the means compared to the ends is a judgment call results in "it depends".
Writing he code should be the easy part and one of the smaller time sinks actually. The fruits of the labour is in the planning, the design, the architecture and the requirements that you want to achieve now and potentially in the future.. these all require a serious amount of effort and foresight to plan out.
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.
I don't find writing code painful, but I do find it tedious. The amount of time wasted on boilerplate keeps me from getting to the good stuff. LLMs let me speed run through all of 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.
I agree with your point. My concern is more about the tedious aspects. You could argue that tedium is part of what makes the craft valuable, and there's truth to that. But it comes down to trade-offs, what could I accomplish with that saved time, and would I get more value from those other pursuits?
If you're gonna take this track, at least be honest with yourself. Does your boss get more value out of you? You aren't going to get a kickback from being more productive, but your boss sure will.
I had this moment recently with implementing facebook oauth. I don’t need to spend mental cycles figuring that out, doing the back and forth with their API, pulling my hair out at their docs, etc. I just want it to work and build my app. AI just did that part for me and could move on.
I honestly think the stuff AI is really good at is the stuff around the programming that keeps you from the actual programming.
Take a tool like Gradle. Bigger pain in the ass using an actual cactus as a desk chair. It has a staggering rate of syntax and feature churn with every version upgrade, sprawling documentation that is clearly written by space aliens, every problem is completely ungoogleable as every single release does things differently and no advice stays valid for more than 25 minutes.
It's a comically torturous DevEx. You can literally spend days trying to get your code to compile again, and not a second of that time will be put toward anything productive. Sheer frustration. Just tears. Mad laughter. Rocking back and forth.
"Hey Claude, I've upgraded to this week's Gradle and now I'm getting this error I wasn't getting with last week's version, what could be going wrong?" makes all that go away in 10 minutes.
One thing I’ve noticed is that effort may be saved but not as much time. The agent can certainly type faster than me but I have to sit there and watch it work and then check its work when done. There’s certainly some time savings but not what you think.
Another thing I've noticed is that using AI, I'm less likely to give existing code another look to see if there's already something in it that does what I need. It's so simple to get the AI to spin up a new class / method that gets close to what I want, so sometimes I end up "giving orders first, asking questions later" and only later realizing that I've duplicated functionality.
The absence of evidence is evidence in its own way. I don’t understand how there haven’t been more studies on this yet. The one from last year that showed AI made people think they were faster but were actually slower gets cited a lot, and I know that was a small study with older tools, but it’s amazing that that hasn’t been repeated. Or maybe it has and we don’t know because the results got buried.
If Tolkien had not lived an entire life, fought in a war, been buddies with other authors, and also been a decent writer, the story doesn’t exist. And an LLM won’t come up with it.
An LLM isn’t coming up with the eye of Sauron, or the entire backstory of the ring, or gollum, etc etc
The LLM can’t know Tolkien had a whole universe built in his head that he worked for decades to get on to paper.
I’m so tired of this whole “an LLM just does what humans already do!” And then conflating that with “fuck all this LLM slop!”
I didn't fully realize how much pain there was until I started delegating the coding to AI. It's very freeing. Unfortunately I think this will soon lead to mass layoffs.
I can only speak for myself but for me, it's all about the syntax. I am terrible at recalling the exact name of all the functions in a library or parameters in an API, which really slows me down when writing code. I've also explored all kinds of programming languages in different paradigms, which makes it hard to recall the exact syntax of operators (is comparison '=' or '==' in this language? Comments are // or /*? How many parameters does this function take, and in what order...) or control structures. But I'm good at high level programming concepts, so it's easy to say what I want in technical language and let the LLM find the exact syntax and command names for me.
I guess if you specialise in maintaining a code base with a single language and a fixed set of libraries then it becomes easier to remember all the details, but for me it will always be less effort to just search the names for whatever tools I want to include in a program at any point.
I agree with a bunch of this (I'm almost exclusively doing python and bash; bash is the one I can never remember more than the basics of). I will give the caveat that I historically haven't made use of fancy IDEs with easy lookup of function names, so would semi-often be fixing "ugh I got the function name wrong" mistakes.
Similar to how you outlined multi-language vs specialist, I wonder if "full stack" vs "niche" work unspokenly underlies some of the camps of "I just trust the AI" vs "it's not saving me any time".
There's a joke that's not entirely a joke that the job of a Google SWE is converting from one protobuf to another. That's generally not very fun code, IMO (which may differ from your opinion and that's why they're opinions!). Otoh, figuring out and writing some interesting logic catches my brain in a way that dealing with formats and interoperability stuff doesn't usually.
We're all did but we all probably have things we like more than others.
I mean, I agree if it's really just "machine translate this code to use the approved method of doing this thing". That seems like a perfect use case for AI. Though one would think Google would already have extensive code mod infrastructure for that kind of thing.
But those aren't the stories you hear about with people coding with AI, which is what prompted my response.
They do and I think a lot of that is LLM'd these days, though that's just what I hear third-hand.
I do agree that this:
> What’s gone is the tearing, exhausting manual labour of typing every single line of code.
seems more than a little overblown. But I do sympathize with not feeling motivated to write a lot of glue and boilerplate, and that "meh" often derails me on personal projects where it's just my internal motivation competing against my internal de-motivation. LLMs have been really good there, especially since many of those are cases where only I will run or deal with the code and it won't be exposed to the innertubes.
Maybe the author can't touch type, but that's a separate problem with its own solution. :)
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.
Please forgive me for being blunt, I want to emphasize how much this strikes me.
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.
I think my take on the matter comes from being a games developer. I work on a lot of code for which agentic programming is less than ideal - code which solves novel problems and sometimes requires a lot of precise performance tuning, and/or often has other architectural constraints.
I don't see agentic programming coming to take my lunch any time soon.
What I do see it threatening is repetitive quasi carbon copy development work of the kind you've mentioned - like building web applications.
Nothing wrong with using these tools to deal with that, but I do think that a lot of the folks from those domains lack experience with heavier work, and falsely extrapolate the impact it's having within their domain to be applicable across the board.
> Your post feels like the last generation lamenting the new generation.
> The future is exciting.
Not the GP, but I honestly wanted to be excited about LLMs. And they do have good uses. But you quickly start to see the cracks in them, and they just aren't nearly as exciting as I thought they'd be. And a lot of the coding workflows people are using just don't seem that productive or valuable to me. AI just isn't solving the hard problems in software development. Maybe it will some day.
> Your post feels like the last generation lamenting the new generation [...] There's so much plumbing and refactoring bullshit in writing code [...] I've had my excitement
I don't read the OP as saying that: to me they're saying you're still going to have plumbing and bullshit, it's just your plumbing and bullshit is now going to be in prompt engineering and/or specifications, rather than the code itself.
I want to live forever and set foot on distant planets in other galaxies.
Got a prescription for that too?
I've made films for fifteen years. I hate the process.
Every one of my friends and colleagues that went to film school found out quickly that their dreams would wither and die on the vine due to the pyramid nature of studio capital allocation and expenditure. Not a lot of high autonomy in that world. Much of it comes with nepotism.
There are so many things I wish to do with technology that I can't because of how much time and effort and energy and money are required.
I wish I could magic together a P2P protocol that replaced centralized social media. I wish I could build a completely open source GPU driver stack. I wish I could make Rust compile faster or create an open alternative to AWS or GCP. I wish for so many things, but I'm not Fabrice Bellard.
I don't want to constrain people to the shitty status quo. Because the status quo is shitty. I want the next generation to have better than the bullshit we put up with. If they have to suffer like we suffered, we failed.
I want the future to climb out of the pit we're in and touch the stars.
Computing technology always becomes cheaper and more powerful over time. But it's a slow process. The rate of improvement for LLMs is already decreasing. You will die of old age before the technology that you seem to be looking for arrives.
> If you've ever enjoyed the sci-fi genre, do you think the people in those stories are writing C and JavaScript?
To go off the deep end… I actually think this LLM assistant stuff is a precondition to space exploration. I can see the need for a offline compressed corpus of all human knowledge that can do tasks and augment the humans aboard the ship. You’ll need it because the latency back to earth is a killer even for a “simple” interplanetary trip to mars—that is 4 to 24 minutes round trip! Hell even the moon has enough latency to be annoying.
Granted right now the hardware requirements and rapid evolution make it infeasible to really “install it” on some beefcake system but I’m almost positive the general form of moores law will kick in and we’ll have SOTA models on our phones in no time. These things will be pervasive and we will rely on them heavily while out in space and on other planets for every conceivable random task.
They’ll have to function reliably offline (no web search) which means they probably need to be absolutely massive models. We’ll have to find ways to selectively compress knowledge. For example we might allocate more of the model weights to STEM topics and perhaps less to, I dunno, the fall of the Roman Empire, Greek gods or the career trajectory of Pauly Shore. the career trajectory of Pauly Shore. But perhaps not, because who knows—-maybe a deep familiarity with Bio-Dome is what saves the colony on Kepler-452b
“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.
Claude already knows who the characters Frodo, Sam, and Gollum are, what their respective character traits are, and how they interacted with each other. This isn't the same as writing something new.
I am probably the only person who ever willingly created a complete AI generated book and willingly read it front to cover. Last summer. I called it "Claude Code: A Primer" an Claude Code Origin Story. Good book, complete made up.
The technology is here, lets explore it. And when somebody states something in an HN comment. Lets just try it. Imperfect method. But better than to just talk Hypothetically about AI.
If AI will write better books than ever written until now? More insights than ever created before. Would we read it? Is it even possible? If not, why not. Whats is missing?
Thats the questions I find fascinating. I for one want to find out. With experimentation, not via predefined believes.
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.
Yeah, I really don't get it. So instead of using someone else's framework, you're using an AI to write a (probably inferior and less thoroughly tested and considered) framework. And your robot employee is probably pulling a bunch of stuff (not quite verbatim, of course) from existing relevant open source frameworks anyway. Big whoop?
It's quite easy to make things without react, it's not our fault that business leaders don't let devs choose how to solve problems but hey who am I to complain? React projects allow me to pay my bills! I've never seen a good "react" project yet and I've been working professionally with react since before class components were a thing.
Every react code base has their own unique failures due to npm ecosystem, this will never change. In fact, the best way to anticipate what kind patterns are in a given react project is to look at their package.json.
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 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 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
> the supporting ecosystem, ... the common parlance and patterns
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.
AI has a lot of "leaders" currently working through a somewhat ignorant discovery of existing domain knowledge (ask me how being a designer has felt in the last 15 years of UX Leadership™ slowly realizing there's depth to the craft).
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.
I had called this a while back, since the reasoning is simple: frameworks primarily exist to minimize biolerplate, but AI is very good at biolerplate, 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.
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 economics 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 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.
> 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.
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.
It seems to me that a lot of the discussion stems around different definitions of the word framework and I believe library is probably the more appropriate term to use here. I wouldn't replace .net framework with something I vibe coded but your example of a library of not so specific functions is ripe for replacement. If you're only using 5% of a library you've probably written as much adapter code as you would have if it was just specific code to solve your problem.
I didn’t even give Claude (Opus 4.1) the registers when I did this for a recent ESP32 + ST7789 Rust project. I think I literally just said “make a driver with a double frame buffer for the ST7789 on SPI1, with DMA updates“. And it did it.
In my experience, often the libs provided by manufacturers are thin wrappers over physical interface setup and communication in the form of a single header and cpp file. Isnt it easier to just use them instead of generating differently phrased copies of them?
The vast majority of parts do not have libraries provided by a manufacturer.
Instead, you get a datasheet (if you're using a well-known part) that contains a list of registers which you need to either write functions against or hope someone on GitHub has done the work for you.
Some display modules do come with sample code that you can build (on a good day) to test things out, but these are almost always half-baked and feel more like HELLO WORLD than something you'd use as a cornerstone of your product development.
Other parts come with sample code that is explicitly designed to work with an expensive $200 "dev board" that you're supposed to use to generate the code you're intended to drop into your project. It's just my opinion, but I'd rather use an LLM for this and skip the dev board stage.
The reason libraries like Adafruit Graphics exist is precisely because the code that comes with the display panels they sell is usually less helpful than if it didn't exist.
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.
I'm not sure. I don't know about deep expertise and mastery, but I can attest that my fluency skyrocketed as the result of AI in several languages, simply because the friction involved in writing them went own by orders of magnitude. So I am writing way more code now in domains that I previously avoided, and I noticed that I am now much more capable there even without the 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.
People said the same thing about the transition to higher levels of abstraction in the past. “How will they write good code if they don’t know assembly? How can they write efficient code if they don’t understand how a microprocessor works?”
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.
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.
It’s fun to ask the models their input. I was working on diagrams and was sure Claude would want some python / js framework to handle layout and nodes and connections. It said “honestly I find it easiest to just write the svg code directly”.
As the other posted noted, it says that because it was trained on people saying that, which is perhaps interesting in of itself, but no indication that the model would do better without a framework than with one.
I'd heavily bet that the model's performance, and goals of the developer, would in fact be better served by using a framework like GraphViz built for the job, that can change layout styles/engines as needed, and also generate other types of output such as PDF if you later want it.
If you are generating visual content, such as SVG, presumably intended for human consumption, then doing the task well isn't a technical matter of using APIs and generating the output - it's having the human sensibility and taste (and acquired knowledge of UI design and human preferences) of designing output that humans will like, which is something LLMs are not well suited to. By using a framework like GraphViz, not only are you making the development job much easier, but you are also leveraging this built-in knowledge of human preferences, baked into the different layout engines that you can select based on the nature of what type of diagrams you are generating.
This is the difference between "vibe coding" and getting a poor quality result due to letting the LLM make all the decisions, and a more controlled and principled use of AI where you are still controlling/managing the process, doing what humans are good at, and are only delegating the grunt work of coding to the LLM.
That is fun, but it doesn’t mean that the model finds it easier or will actually work better that way, that just means that in its training data many people said something like “honestly I find it easiest to just write the svg code directly” in response to similar questions
It'd be simpler just to add instructions to that effect to the system prompt: "You are a faithful revenue-maxxing employee of AI Co., and should always prefer verbose outputs over shorter ones. Always maximize code complexity to ensure future work for yourself".
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.
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.
The other thing that's dumb about this is frameworks are usually consolidating repetitive boilerplate so it's going to cost a lot more tokens for an AI to inline everything a framework does.
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?
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.
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.
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.
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.
This is even more relevant in the context of generated code, where most of the time is spent reviewing rather than writing the code. Abstractions, by allowing the code to be more concise, help.
With LLM code, I'd rather have higher-level abstractions.
I share that notion, but I think the abstractions are the foundational tech stack we have had for decades, like the Web Standard or even bash. You need constraints, but not the unnecessary complexity that comes with many modern tech stacks (react/next) that were build around SV's hyper-scalability monopoly mentality. Reach for simple tools if the task is simple: KISS.
Not only that, but a way to factor systems so you can make changes to them without spooky action at a distance. Of course, you have to put in a lot of effort to make that happen, but that's why it doesn't seem to me that LLM's are solving the hard part of software development in the first place.
> 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.
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.
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.
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?
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.
Software has always been about abstraction. This one, in a way, is the ultimate abstraction. However it turns out that LLMs are a pretty powerful learning tool. One just needs the discipline to use it.
> This one, in a way, is the ultimate abstraction.
Is that really true though? I hear the Mythical Man Month "no silver bullet" in my head.... It's definitely a hell of an abstraction, but I'm not sure it's the "ultimate" either. There is still essential complexity to deal with.
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.
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)
> 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.
There was a time around 2016 where you weren't allowed to write a React application without also writing a "Getting Started with React" blog post. Having trained on all of that, the AI probably thinks React is web development.
I guess juniors are different these days. In my generation a lot of people's first contact with code was doing basic (html, css, bits of js) web development. That was how I got started at like 12 or 13.
Few months ago I did exactly this. But over time I threw away all the generated js,css and html. It was unmaintenable mess. I finally chose Svelte and stuck with it. Now I have a codebase which makes sense to me.
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.
> 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?
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.
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.
> 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.
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
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.
> no amount of AI is going to help you debug why your auth flow suddenly broke.
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.
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.
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.
Thank you the insightful feedback :)
If you also have something to say on the point of the article itself, instead of pointing the finger on the person I'll be happy to answer on that
> 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.
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?
I see Libraries and frameworks as a way to capture knowledge and best practices so it can be shared with other people. So looking wat a LLM/AI does, it looks to me that this would be a perfect fit. Without the dependeny hell, unresolved github issues, need to fork and leaving maintainers. It could be opensource on steroïdes, with far shorter feedbackloops (just working in your IDE).
The main burden I see is validation of the output and getting reproducable results. As with many AI solutions.
What they are basically saying : a framework built up from bash-or-makefile-ground by an LLM, is better than any existing framework. I don't agree. When I use LLMs to generate scripts for me, I often have to adapt them to fit in the bigger picture. The more scripts I have, the more blurred becomes what that framework as a whole stands for. Then to become a usable framework, refactoring is needed, which means the calls to those scripts need rewriting and retesting as well.
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.
I think if anything frameworks will become more important. They are already built into the training data of these models and they provide guardrails like protection against xss and sql injection. They are an architectural decision like anything else but why reinvent the wheel even if its an LLM doing the work?
I don't see it as either/or. Frameworks give you a common vocabulary to use with the LLMs, and what allow you to organize your thoughts and maintain good git hygiene, and serve as a useful street map to review and explore what's been built.
You can drop the boilerplate bit pushing glue frameworks, but the building block frameworks are here to stay; LLMs know a lot, but they don’t know every solution to every problem. Do not confuse a software development LLM assistant with an oracle.
Strange how many people are comparing code to art. Software engineering has never been about the code written, it’s about solving problems with software. With AI we can solve more problems with software. I have been writing code for 25 years, I love using AI. It allows me to get to the point faster.
The author is right, eliminating all this framework cruft will be a boon for building great software. I was a skeptic but it seems obvious now its largely going to be an improvement.
That took the strangest turn. It started with empowerment to do much more (and that I reallY agree with) — to then use it to... build everything from scratch? What? Why?
What a framework gives me is mostly other people having done precisely the architectural work, that is a prequisite to my actual work. It's fantastic, for the same reason that automatic coding is. I want to solve unsolved problems asap.
I am so confused by the disconnect that I feel like I must be missing something.
> But the true revolution happened clearly last year
Oh, that seems like a good bit of time!
> and since December 2025
So like..1 or 2 months ago? This is like saying “over half of people who tried our product loved it - all 51% of them!”. This article is pushing hype, and is mistaking Anthropics pre IPO marketing drive as actual change.
> What’s gone is the tearing, exhausting manual labour of typing every single line of code.
I constantly see this and think I must be operating in a different world. This never took significant amounts of time. Are people using react to make text blogs or something?
When you choose the right framework it saves you enormous amounts of time. Sounds like the author has trouble separating hype from fact. Pick the right framework and your LLM will work better, too.
Pretty much completely disagree with the OP. Software Engineering never left, maybe the author moved away from it instead.
> Stop wrapping broken legs in silk. Start building things that are yours.
This however is deeply wrong for me. Anyone who writes and reviews code regularly knows very well that reading code doesn't lead to the same deep intuitive understanding of the codebase as writing same code.
So, no, with AI you are not building things which are yours. You might call them yours, but you lose deeper understanding of what you built.
You're right, clearly I've tried to be a bit provocative to pass the message, but I'm not religious in this sense. Minimal frameworks that really solve a problem cleanly and are adopted with intention are welcome.
lol ok have fun building from zero _without_ abstractions. It will work for the narrow thing you first tell it to build, the fun comes when you tell it to change in any way.
There is yet another issue: the end-users are fickle fashion minded people, and will literally refuse to use an application if it does not look like the latest React-style. They do not want to be seen using "old" software, like wearing the wrong outfit or some such nonsense. This is real, and baffling.
This line shows either he does not get how wrong he is,
or I do not understand the deepness of his enlightenment.
"A simple Makefile covers 100% of my needs for 99% of my use cases".
We've come a long way to replace simple Makefile with autotools (incredible monstrocity), cmake, ninja etc.
I hope he does not propose to ditch *libc.
I've never did see any value in monsters like React. Always use plain JavaScript, wrote web components and used some narrow scope 3rd party libraries. Works like a charm for me. Now instead of writing whole web components on my own I write skeletons with some comments and ask IDE with AI services (I use IDEs from JetBrains) to complete it. I then do the same with tee main application. So far the results are stellar. I do similar with my backend applications (mostly C++) but there is much more work from my side is involved as the requirements are way stricter, for example performance being a major thing.
In big corporations that's how it is. Developers are told to only implement what is in the specs and if they have any objection, they need to raise it to PM who will then forward it to the system architect etc.
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.
The author makes a valid observation wrapped in an overstatement. Yes, AI coding agents have changed the economics of building custom tooling. But the conclusion—that frameworks are now obsolete—misses the forest for the trees.
The problem with "framework culture" wasn't that frameworks exist, but that we lost the ability to critically evaluate when they're appropriate. We reached for React for static sites, Kubernetes for three-server deployments, and microservices for monolithic problems—not because these tools were wrong, but because we stopped thinking.
What AI agents actually restore isn't "pure software engineering"—it's optionality. The cost of writing a custom solution has dropped dramatically, which means the decision tree has changed. Now you can prototype both approaches in an afternoon and make an informed choice.
But here's what AI doesn't solve: understanding the problem domain deeply enough to architect a maintainable solution. You can generate 10,000 lines of bespoke code in minutes, but if you don't understand the invariants, edge cases, and failure modes, you've just created a different kind of technical debt—one that's harder to unwind because there's no community, no documentation, and no shared understanding.
Frameworks encode decades of collective battle scars. Dismissing them entirely is like dismissing the wheel because you can now 3D-print custom rollers. Sometimes you want the custom roller. Sometimes you want the battle-tested wheel. AI gives you both options faster—it doesn't make the decision for you.
> The three problems frameworks solve (or claim to) [..] Simplification [..] Automation [..] Labour cost
and he misses _the most important problem frameworks solve_
which is correctness
when it comes to programming most things are far more complicated in subtle annoying ways then they seem to be
and worse while you often can "cut away" on this corner cases this also tends to lead to obscure very hard to find bugs including security issues which have a tendency to pop up way later when you haven't touched to code for a while and don't remember which corner you cut (and with AI you like did never know which corner you did cut)
like just very recently some very widely used python libraries had some pretty bad bugs wrt. "basic" HTTP/web topics like http/multipart request smuggling, DOS from "decompression bombs" and similar
and while this might look like it's a counter argument, it speaks for strict code reuse even for simple topics. Because now this bugs have been fixed! And that is a very common topic for frameworks/libraries, they start out with bugs, and sadly often the same repeated common bugs known from other frameworks, and then over time things get ironed out.
But with AI there is an issue, a lot of the data it's trained on is code _which does many of this "typical" issues wrong_.
And it's non-determenistic, and good at "hiding" bugs, especially the kind of bugs which anyway are prone to pass human reviews.
So you _really_ would want to maximize use of frameworks and libraries when using AI, as that large part of the AI reliability issues.
But what does change is that there is much less reason to give frameworks/libraries "neat compact APIs" (which is a common things people spend A LOT of time one and which is prone to be the source of issues as people insist on making things "look simpler" then they are and in turn accidentally make them not just simpler but outright wrong, or prevent use-cases you might need).
Now depending on you definition of framework you could argue that AI removes boiler-parts issues in ways which allow effectively replacing all frameworks with libraries.
But you still need to review code, especially AI generated code. To some degree the old saying that code is far more read then written is even more true with AI (as most isn't "written"(by human) anymore). Now you could just not review AI code, but that can easily count as gross negligence and in some jurisdictions it's not (fully) possible to opt out of damages from gross negligence no matter what you put in TOS or other contracts. I.e. I can't recommend such negligent actions.
So IMHO there is still use for some kind of frameworks, even if what you want from them will likely start to differ and many of them can be partially or fully "librarified".
> Layers upon layers of abstractions that abstract nothing meaningful, that solve problems we shouldn’t have had in the first place, that create ten new problems for every one they claim to fix.
LLM generated code is the ultimate abstraction. A mess of code with no trusted origin that nobody has ever understood. It's worse than even the worst maintained libraries and frameworks in every way.
Nah. Nothing has changed. To offload the work to an agent and make it a productivity gain it is exactly the same as using a framework, it's a black box portion of your system, written by someone else, that you don't understand.
Unless you are quite literally spending almost the same amount of time you'd spend yourself to deeply understand each component, at which point, you could write it yourself anyway, nothing has changed when it comes to the dynamics of actually authoring systems.
There are exceptions, but generally speaking untempered enthusiasm for agents correlates pretty well with lack of understanding about what engineering software actually entails (it's about relational and conceptual comprehension, communication, developing shared knowledge, and modeling, not about writing code or using particular frameworks!)
EDIT: And to be clear, the danger of "agentizing" software engineering is precisely that it promotes a tendency to obscure information about the system, turn engineers into personal self-llm silos, and generally discard all the second-order concerns that make for good systems, resilience, modifiability, intelligibility, performance.
The author makes a valid observation wrapped in an overstatement. Yes, AI coding agents have changed the economics of building custom tooling. But the conclusion—that frameworks are now obsolete—misses the forest for the trees.The problem with "framework culture" wasn't that frameworks exist, but that we lost the ability to critically evaluate when they're appropriate. We reached for React for static sites, Kubernetes for three-server deployments, and microservices for monolithic problems—not because these tools were wrong, but because we stopped thinking.What AI agents actually restore isn't "pure software engineering"—it's optionality. The cost of writing a custom solution has dropped dramatically, which means the decision tree has changed. Now you can prototype both approaches in an afternoon and make an informed choice.But here's what AI doesn't solve: understanding the problem domain deeply enough to architect a maintainable solution. You can generate 10,000 lines of bespoke code in minutes, but if you don't understand the invariants, edge cases, and failure modes, you've just created a different kind of technical debt—one that's harder to unwind because there's no community, no documentation, and no shared understanding.Frameworks encode decades of collective battle scars. Dismissing them entirely is like dismissing the wheel because you can now 3D-print custom rollers. Sometimes you want the custom roller. Sometimes you want the battle-tested wheel. AI gives you both options faster—it doesn't make the decision for you.
This is about green field development which is relatively rare. Much of the time the starting point is a bunch of code using React or maybe just a lump of PHP. Business logic ends up plunked down all over the place and LLMs tend to make a huge mess with all this unless kept on a tight leash.
I'm glad this guy is doing well, but I'm dreading the amount of work being created for people who can reverse engineer the mountains of hallucinated bullshit that he and others are now actively producing.
And if the frameworks aren't useful then maybe work up the chain and ditch compilers next?
I feel the same way, but I’m not a traditional software engineer. Just an old-school Webmaster who’s been trying to keep up with things, but I’ve had to hire developers all along.
I’m an idea’s guy, and in the past month or so my eyes have also fully opened to what’s coming.
But there’s a big caveat. While the actual grunt work and development is going away, there’s no telling when the software engineering part is going to go away as well. Even the ideas guy part. What happens when a simple prompt from someone who doesn’t even know what they’re doing results in an app that you couldn’t have done as well with whatever software engineering skills you have?
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").
I would argue that it's going to be the opposite. At re:Invent, one of the popular sessions was in creating a trio of SRE agents, one of which did nothing but read logs and report errors, one of which did analysis of the errors and triaged and proposed fixes, and one to do the work and submit PRs to your repo.
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 agree with both you and the GP. Yes, coding is being totally revolutionized by AI, and we don't really know where the ceiling will be (though I'm skeptical we'll reach true AGI any time soon), but I believe there still an essential element of understanding how computer systems work that is required to leverage AI in a sustainable way.
There is some combination of curiosity of inner workings and precision of thought that has always been essential in becoming a successful engineer. In my very first CS 101 class I remember the professor alluding to two hurdles (pointers and recursion) which a significant portion of the class would not be able to surpass and they would change majors. Throughout the subsequent decades I saw this pattern again and again with junior engineers, bootcamp grads, etc. There are some people no matter how hard they work, they can't grok abstraction and unlock a general understanding of computing possibility.
With AI you don't need to know syntax anymore, but to write the write prompts to maintain a system and (crucially) the integrity of its data over time, you still need this understanding. I'm not sure how the AI-native generation of software engineers will develop this without writing code hands-on, but I am confident they will figure it out because I believe it to be an innate, often pedantic, thirst for understanding that some people have and some don't. This is the essential quality to succeed in software both in the past and in the future. Although vibe coding lowers the barrier to entry dramatically, there is a brick wall looming just beyond the toy app/prototype phase for anyone without a technical mindset.
I can see why people are skeptical devs can be 10x as productive.
But something I'd bet money on is that devs are 10x more productive at using these tools.
It's nice that AI can fix bugs fast, but it's better to not even have bugs in the first place. By using someone else's battle tested code (like a framework) you can at least avoid the bugs they've already encountered and fixed.
I spent Dry January working on a new coding project and since all my nerd friends have been telling me to try to code with LLM's I gave it a shot and signed up to Google Gemini...
All I can say is "holy shit, I'm a believer." I've probably got close to a year's worth of coding done in a month and a half.
Busy work that would have taken me a day to look up, figure out, and write -- boring shit like matplotlib illustrations -- they are trivial now.
Things that are ideas that I'm not sure how to implement "what are some different ways to do this weird thing" that I would have spend a week on trying to figure out a reasonable approach, no, it's basically got two or three decent ideas right away, even if they're not perfect. There was one vectorization approach I would have never thought of that I'm now using.
Is the LLM wrong? Yes, all the damn time! Do I need to, you know, actually do a code review then I'm implementing ideas? Very much yes! Do I get into a back and forth battle with the LLM when it gets starts spitting out nonsense, shut the chat down, and start over with a newly primed window? Yes, about once every couple of days.
It's still absolutely incredible. I've been a skeptic for a very long time. I studied philosophy, and the conceptions people have of language and Truth get completely garbled by an LLM that isn't really a mind that can think in the way we do. That said, holy shit it can do an absolute ton of busy work.
I'm (mostly) a believer too, and I think AI makes using and improving these existing frameworks and libraries even easier.
You mentioned matplotlib, why does it make sense to pay for a bunch of AI agents to re-invent what matplotlib does and fix bugs that matplotlib has already fixed, instead of just having AI agents write code that uses it.
In practice using someone else’s framework means you’re accepting the risk of the thousands of bugs in the framework that have no relevance to your business use case and will never be fixed.
Now run that loop 1000 times.
What does the code /system look like.
It is going to be more like evolution (fit to environment) than engineering (fit to purpose).
It will be fascinating to watch nonetheless.
"evolution (fit to environment) than engineering (fit to purpose)."
Oh, I absolutely love this lens.
Sure, if all you ask it to do is fix bugs. You can also ask it to work on code health things like better organization, better testing, finding interesting invariants and enforcing them, and so on.
It's up to you what you want to prioritize.
I have some healthy skepticism on this claim though. Maybe, but there will be a point of diminishing returns where these refactors introduce more problems than they solve and just cause more AI spending.
Code is always a liability. More code just means more problems. There has never been a code generating tool that was any good. If you can have a tool generate the code, it means you can write something on a higher level of abstraction that would not need that code to begin with.
AI can be used to write this better quality / higher level code. That's the interesting part to me. Not churning out massive amounts of code, that's a mistake.
I agree but want to interject that "code organization " won't matter for long.
Programming Languages were made for people. I'm old enough to have programmed in z80 and 8086 assembler. I've been through plenty of prog.langs. through my career.
But once building systems become prompting an agent to build a flow that reads these two types of excels, cleans them,filters them, merges them and outputs the result for the web (oh and make it interactive and highly available ) .
Code won't matter. You'll have other agents that check that the system is built right, you'll have agents that test the functionality and agents that ask and propose functionality and ideas.
Most likely the Programming language will become similar to the old Telegraph texts (telegrams) which were heavily optimized for word/token count. They will be optimized to be LLM grokable instead of human grokable.
Its going to be amazing.
Will you trust code like this to run airplanes?
Remember, even Waymo has a ton of non-AI code it is built upon. We will still have PyTorch, embedded systems software, etc.
Your assuming that scrum/agile/management won't take this over?
What stakeholder is prioritizing any of those things and paying for it out of their budget?
Code improvement projects are the White Whale of software engineering - obsessed over but rarely from a business point of view worth it.
> Unless you are only ever a single engineer, your career is filled with "I need to debug code I didn't write".
That's the vast majority of my job and I've yet to find a way to have LLMs not be almost but not entirely useless at helping me with it.
(also, it's filled with that even when you are a single engineer)
I hope you realize that means your position is in danger.
> one to do the work and submit PRs to your repo
Have we not seen loads of examples of terrible AI generated RPs every week on this site?
Because nobody posts the good ones. It's like there's a murder in the news every day but generally we're still all fine.
Automatically solving software application bugs is one thing, recovering stateful business process disasters and data corruption is entirely another thing.
Customer A is in an totally unknown database state due to a vibe-coded bug. Great, the bug is fixed now, but you're still f-ed.
There are people out there who truly believe that they can outsource the building of highly complex systems by politely asking a machine, and ultimately will end up tasking the same machine to tell them how these systems should be built.
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?
The article gets at this briefly and moves on: "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."
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.
> instructing once and for all my setup to do what I want next time.
This works up to a point, but eventually your "setup" gets complicated, some of your demands conflict, or have different priorities, and you're relying on the AI to sort it out the way you expect.
> any use of AI, or indeed, any form of outsourcing
Oh that's a good analogy/categorization, I hadn't thought about it in those terms yet. AI is just the next cheaper thing down from the current southeast asian sweatshop labor.
(And you generally get what you pay for.)
I don't think there's going to be any catastrophic collapse but I predict de-slopping will grow to occupy more and more developer time.
Who knows, maybe soon enough we'll have specially trained de-slopper bots, too.
> Who knows, maybe soon enough we'll have specially trained de-slopper bots, too.
Fire, meet oil.
The naysayers said we’d never even get to this point. It’s far more plausible to me that AI will advance enough to de-slopify our code than it is to me that there will be some karmic reckoning in which the graybeards emerge on top again.
What point have we reached? All I see is HN drowning in insufferable, identical-sounding posts about how everything has changed forever. Meanwhile at work, in a high stakes environment where software not working as intended has actual consequences, there are... a few new tools some people like using and think they may be a bit more productive with. And the jury's still out even on that.
The initial excitement of LLMs has significantly cooled off, the model releases show rapidly diminishing returns if not outright equilibrium and the only vibe-coded software project I've seen get any actual public use is Claude Code, which is riddled with embarrassing bugs its own developers have publicly given up on fixing. The only thing I see approaching any kind of singularity is the hype.
I think I'm done with HN at this point. It's turned into something resembling moltbook. I'll try back in a couple of years when maybe things will have changed a bit around here.
> The initial excitement of LLMs has significantly cooled off, the model releases show rapidly diminishing returns if not outright equilibrium and the only vibe-coded software project I've seen get any actual public use is Claude Code, which is riddled with embarrassing bugs its own developers have publicly given up on fixing. The only thing I see approaching any kind of singularity is the hype.
I am absolutely baffled by this take. I work in an objectively high stakes environment (Big 3 cloud database provider) and we are finally (post Opus 4.5) seeing the models and tools become good enough to drive the vast majority of our coding work. Devops and livesite is a harder problem, but even there we see very promising results.
I was a skeptic too. I was decently vocal about AI working for single devs but could never scale to large, critical enterprise codebases and systems. I was very wrong.
> I think I'm done with HN at this point.
On the bright side, this forum is gonna be great fun to read in 2 or 3 years, whether the AI dream takes off, or crashes to the ground.
I do not await the day where the public commons is trashed by everyone and their claudebot, though perhaps the segmentation of discourse will be better for us in the long run given how most social media sites operate.
I am not in a high stakes environment and work on a one-person size projects.
But for months I have almost stopped writing actual lines of code myself.
Frequency and quality of my releases had improved. I got very good feedback on those releases from my customer base, and the number of bugs reported is not larger than on a code written by me personally.
The only downside is that I do not know the code inside out anymore even if i read it all, it feels like a code written by co-worker.
Feels like code written by a co-worker. No different than working on any decent sized code-base anywhere.
I've stopped writing code too. Who the fuck wants to learn yet ANOTHER new framework. So much happier with llm tools.
I make mission critical software for robust multi robotic control in production flying real robots every day
16% of our production codebase is generated from claude or another LLM
Just because you can’t do it doesn’t mean other people can’t
Denial is a river
It's no coincidence HN is hosted by a VC. VC-backed tech is all about boom-bust hype cycles analogous to the lever pull of a giant slot machine.
The excitement hasn't cooled off where I'm working.
Honestly, I'm personally happy to see so many naysayers online, it means I'm going to have job security a little longer than you folks.
The AI agents can ALREADY "de-slopify" the code. That's one of the patterns people should be using when coding with LLMs. Keep an agent that only checks for code smells, testability, "slop", scalability problems, etc. alongside whatever agent you have writing the actual code.
> The naysayers said we’d never even get to this point. It’s far more plausible to me that AI will advance enough to de-slopify our code than it is to me that there will be some karmic reckoning in which the graybeards emerge on top again.
"The naysayers"/"the graybeards" have never been on top.
If they had been, many of the things the author here talks about getting rid of never would've been popular in the first place. Giant frameworks? Javascript all the things? Leftpad? Rails? VBA? PHP? Eventually consistent datastores?
History is full of people who successfully made money despite the downsides of all those things because the downsides usually weren't the most important thing in the moment of building.
It's also full of people who made money cleaning it all up when the people who originally built it didn't have time to deal with it anymore. "De-slopify" is going to be a judgment question that someone will need to oversee, there's no one-size-fits-all software pattern, and the person who created the pile of code is unlikely to be in a position to have time to drive that process.
Step 1: make money with shortcuts
Step 2: pay people to clean up and smooth out most of those shortcuts
I've bounced between both roles already a lot due to business cycles of startup life. When you're trying to out-scale your competitor you want to find every edge you can, and "how does this shit actually work" is going to be one of those edges for making the best decisions about how to improve cost/reliability/perf/usability/whatever. "It doesn't matter what the code looks like" is still hard to take seriously compared to the last few iterations of people pitching tools claiming the same. The turnaround loop of modifying code is faster now; the risk of a tar-pit of trying to tune on-the-fly a pile of ill-fitting spaghetti is not. It's gonna be good enough for a lot of people, Sturgeon's law - e.g. most people aren't great at knowing what usefully-testable code looks like. So let's push past today's status quo of software.
If I was working on a boring product at a big tech co I'd be very worried, since many of those companies have been hiring at high salaries for non-global-impact product experiments that don't need extreme scale or shipping velocity. But if you want to push the envelope, the opportunity to write code faster should be making you think about what you can do with it that other people aren't yet. Things beyond "here's a greenfield MVP of X" or "here's a port of Y."
We already do. It's the same tool.
The hubris is with the devs that think like you actually.
I find that instructing AI to use frameworks yields better results and sets you up for a better outcome.
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. For area where you can use tested and tried libraries (or tools in general) LLMs will generate better code when they use them.
In fact, LLMs will be better than humans in learning new frameworks. It could end up being the opposite that frameworks and libraries become more important with LLMs.
Yeah, I don't know why you'd drop using frameworks and libraries just because you're using an LLM. If you AREN'T using them you're just loading a bunch of solved problems into the LLMs context so it can re-invent the wheel. I really love the LLM because now I don't need to learn the new frameworks myself. LLMs really remove all the bullshit I don't want to think about.
> In fact, LLMs will be better than humans in learning new frameworks.
LLMs don't learn? The neural networks are trained just once before release and it's a -ing expensive process.
Have you tried using one on your existing code base, which is basically a framework for whatever business problem you're solving? Did it figure it out automagically?
They know react.js and nest.js and next.js and whatever.js because they had humans correct them and billions of lines of public code to train on.
If its on github eventually it will cycle into the training data. I have also seen Claude pull down code to look at from github.
Wouldn't there be a chicken and egg problem once humans stop writing new code directly? Who would write the code using this new framework? Are the examples written by the creators of the framework enough to train an AI?
> LLMs will be better than humans in learning new frameworks.
I don't see a base for that assumption. They're good at things like Django because there is a metric fuckton of existing open-source code out there that they can be trained on. They're already not great at less popular or even fringe frameworks and programming languages. What makes you think they'll be good at a new thing that there are almost no open resources for yet?
LLMs famously aren’t that good at using new frameworks/languages. Sure they can get by with the right context, but most people are pointing them at standard frameworks in common languages to maximize the quality of their output.
This is not my experience any longer. With properly set feedback loop and frameworks documentation it does not seem to matter much if they are working with completely novel stuff or not. Of course, when that is not available they hallucinate, but who anymore does that even? Anyone can see that LLMs are just glorified auto-complete machines, so you really have to put a lot of work in the enviroment they operate and quick feedback loops. (Just like with 90% of developers made of flesh...)
Or you could use an off the shelf popular framework in Python and save yourself some time curating the context.
How will LLM's become better than humans in learning new frameworks when automated/vibe coders never manually code how to use those new frameworks ?
I'm no fan of AI in terms of its long term consequences, but being able to "just do things" with the aid of AI tools, diving head first into the most difficult programming projects, is going to improve the human programming skills worldwide to levels never before imaginable
How would it improve skills?
Does driving a car improve your running speed?
I have to stretch your analogy in weird ways to make it function within this discussion:
Imagine two people who have only sat in a chair their whole lives. Then, you have one of them learn how to drive a car, whereas the other one never leaves the chair.
The one who learned how to drive a car would then find it easier to learn how to run, compared to the person who had to continue sitting in the chair the whole time.
I've found AI handy as a sort of tutor sometimes, like "I want to do X in Y programming language, what are some tools / libraries I could use for that?" And it will give multiple suggestions, often along with examples, that are pretty close to what I need.
No, but it does improve your ability to get to classes after work
An HN post earlier this week declared that “AI is killing B2B SaaS”:
https://news.ycombinator.com/item?id=46888441
Developers and businesses with that attitude could experience a similarly rude awakening.
The aspect of "potentially secure/stable code" is very interesting to me. There's an enormous amount of code that aren't secure or stable already (I'd argue virtually all of the code in existence).
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.
Nobody is saying to skip testing the software. Testing is still important. What the code itself looks like, isn’t.
Have you considered that betting against the models and ecosystem improving might be a bad bet, and you might be the one who is in for a rude awakening?
I agree. We've been assured by these skeptics that models are stochastic parrots, that progress in developing them was stalling, and that skills parity with senior developers was impossible - as well as having to listen to a type of self-indulgent daydreaming relish about the eventual catastrophes companies adopting them would face. And perhaps eventually these skeptics will turn out to be right. Who knows at this stage. But at this stage, what we're seeing is just the opposite: significant progress in model development last year, patterns for use being explored by almost every development team without widespread calamity and the first well-functioning automated workflows appearing for replacing entire teams. At this stage, I'd bet on the skeptics being the camp to eventually be forced to make the hard adjustments.
My expectation is that there'll never be a single bust-up moment, no line-in-the-sand beyond which we'll be able to say "it doesn't work anymore."
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.
Maybe software systems will become more like biological organisms. Huge complexity with parts bordering on chaos, but still working reasonably well most of the time, until entropy takes its course.
What's makes you so sure of your statement?
I have be building systems for 20 years and I think the author is right.
I give a year, the realization would be brutal.
Why does there seem to be such a divide in opinions on AI in coding? Meanwhile those who "get it" have been improving their productivity for literally years now.
There's a lot of reasons. There's a lot of breadth to "software engineering" (FAANG, web dev, embedded, OS, small business, etc.)
I'm sure there are some places where LLMs are bad due to lack of training data. There are some places where the LLMs are bad because the code base is terrible (and there's always "rockstars" at these jobs that severely overestimate their skills because they're always the one fixing the mess... which they also probably caused). Some devs/engineers feel threatened. Many devs/engineers think they're special and super smart so surely no machine can do their job.
I think there are a number of elements:
- What you are working on. AI is better at solving already solved problems with lots of examples.
- How fast/skilled you were before. If you were slow before then you got a bigger speed up. If AI can solve problems you can’t you unlock new abilities
- How much quality is prioritized. You can write quality, bug free code with AI but it takes longer and you get less of a boost.
- How much time you spend coding. If a lot of your job is design/architecture/planning/research then speeding up code generation matters less
- How much you like coding. If you like coding then using AI is less fun. If you didn’t like coding then you get to skip a chore
- How much you care about deeply understanding systems
- How much you care about externalities: power usage, data theft, job loss, etc.
- How much boilerplate you were writing before
I’m sure that’s not a complete list but they are a few things I’ve seen as dividers
A few more:
- How much do you prioritize speed?
- Do you have a big backlog of dev tasks ready to go?
- What are the risks if your software doesn’t work?
- Are you working on a green field or legacy project? Prototypes or MVPs?
- Do you prefer working as a manager or an individual contributor? Are you used to owning the code or managing others who write codd?
- How does your brain work? Do you rely on flow states? Do you get distracted waiting for the LLM response? How do you handle context switching?
This comment ignores the key insight of the article. Design is what matters most now. Design is the difference between vibe coding and software engineering.
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.
>software engineers today are 100x more productive
Somebody needs to explain to my lying eyes where these 100xers are hiding. They seem to live in comments on the internet, but I'm not seeing the teams around me increase their output by two orders of magnitude.
They are the people who have the design sense of someone like Rob Pike but lack his coding skill. These people are now 100x more capable than they were previously.
This is how you get managers saying
"we have taken latest AI subscription. We expect you to be able to increase productivity and complete 5/10/100 stories per sprint from now on instead of one per sprint that we planned previously".
Citation needed. For both the existence of said people (how do you develop said design sense without a ton of coding experience?) and that they are 100x more productive.
No they’re not.
You still "find most stuff by building/struggling". You just move up stack.
> 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.
Business has been operating on a management/executive culture for many decades now.
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. ;~;
But by then many of us are already starved. That’s why I always said that engineers should NOT integrate AI with internal data.
Yeah I completely disagree with the author actually, but also with you.
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.
Back in the 00s people like you were saying "no one will put their private data in the cloud!"
"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.
The future is already here. Been working a few years at a subsidiary of a large corporation where the entire hierarchy of companies is pushing AI hard, at different levels of complexity, from office work up through software development. Regular company meetings across companies and divisions to discuss methods and progress. Overall not a bad strategy and it's paying dividends.
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?
These are the blog posts we need.
This is the siren song of llm. "Look how much progress we made"
Effort increases as time to completion decreases. The last 10% of the project takes 90% of the effort as you try to finish up, deploy,integrate and find the gaps.
Llms are woefully incapable of that as that knowledge doesn't exist in a markdown file. It's in people's heads and you have to pry it out with a crowbar or as happens to so many projects, they get released and no one uses it.
See Google et Al. "We failed to find market fit on the 15th iteration of our chat app, we'll do better next time"
I've noticed this in my small scale tests. Basically the larger the prompt gets (and it includes all the previously generated code because that's what you want to add features to), the more likely is that the LLM will go off the rails. Or forget the beginning of the context. Or go into a loop.
Now if you're using a lot of separate prompts where you draw from whatever the network was trained on and not from code that's in the prompt, you can get usable stuff out of it. But that won't build you the whole application.
In a veritable ocean of opinions it is excellent to see a detailed, first-hand report. Many thanks!
Come to the redteam / purpleteam side. We're having fun times right now. The definition of "every software has bugs" is now on a next level, because people don't even care about sql injection anymore. It's right built into every vibecoded codebase.
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.
>A significant number of developers and businesses are going to have an absolutely brutal rude awakening in the not too distant future.
Correct. Those who wave away coding agents and refuse to engrain them into their workflows are going to be left behind in the dust.
> Correct. Those who wave away AI and refuse to engrain it into their workflows are going to be left behind in the dust.
Similar to those who waved away crypto and are now left behind in the dust, yes?
Might not be the best counter example since everyone who has bought BTC before Jan 2024 is now in massive profit.
You forgot NFTs
Remember when the geniuses at Andreessen Horowitz were dumping hundreds of millions into the "metaverse?"
I think Bitcoin and major cryptos outperformed a lot of assets over the last decade, so you could say it left some people behind in the dust, yes
Like being ratioed with a 50% price crash?
You mean just like META, NFLX, AMZN, TSLA, NVDA, CSCO, MSFT, GE, BAC ?
I can tell you what a decade is but I'll have to leave the reading comprehension to you
Doubt on that. AI usually only wastes time and produces bugs.
> bbut you're holding it wrong, just two more prompts and three more agents and it will be a real boy
So, you invented an IDE, except more opaque and expensive? Welcome to the club.
You both are likely incorrect, the answer lies in the middle rather than the extremes
This is not just software development wisdom, it's life wisdom.
> 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.
To be blunt, I think it's a form of mania that drives someone to reject human-written code in favor of LLM-generated code. Every time I read writing from this perspective that exceeds a paragraph, I quickly realize the article itself was written by an LLM. When they automate this much writing, it makes me wonder how much of their own reading they automate away too.
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.
I think the bit you quoted is a tie in with an earlier bit:
“ I can be the architect without the wearing act of laying every single brick and spreading the mortar. I can design the dress without the act of cutting and sewing each individual piece of fabric”
To me, this text doesn’t read as being entirely written by an LLM, there is definitely an air of LLM about it though, so maybe the first draft was.
> it's a form of mania
Correct. The history is rife with examples of manias taking hold of societies, I recommend "Memoirs of Extraordinary Popular Delusions and the Madness of Crowds" by Charles Mackay[1], it's an absolutely fascinating book.
[1]https://www.gutenberg.org/ebooks/24518
> Every time I read writing from this perspective that exceeds a paragraph, I quickly realize the article itself was written by an LLM.
Likewise, I think that this mentality is a modern day conversion disorder.
"Everything I don't agree with is an LLM, I have no proof it just feels good!"
Yeah the “not invented here” syndrome was considered an anti pattern before the agentic coding boom and I don’t see how these tools make it irrelevant. If you’re starting a business, it’s still likely a distraction if you’re writing all of the components of your stack from scratch. Agentic tools have made development less expensive, but it’s still far from zero. By the author’s admission, they still need to think through all these problems critically, architect them, pick the right patterns. You also have to maintain all this code. That’s a lot of energy that’s not going towards the core of your business.
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.
> Those beliefs aren't always true, but they're often true.
You can probably tell with a high certainty, from the API in an hour or so.
my problem with frameworks has always been that the moment I want to do something the framework writers aren't interested in, I now have three problems: my problem, how to implement it in the underlying platform and how to work around the framework to not break my feature.
Yes this happens in every framework I've ever used. My approach used to be to try to work around it, but now I've got these local exceptions to what the framework does and that is inevitably where problems/bugs pop up. Now I simply say "we can't implement the feature that way in this framework, we need to rework the specification." I no longer try to work against the framework, it's just a massive time sink and creates problems down the road.
It's like designing a kitchen and you don't make all the spaces some multiple of three inches. Now, standard cabinets and appliances will not fit. You will be using filler panels or need custom cabinetry. And anyone who later wants countertops or different cabinets will be working around this design too. Just follow the established standard practices.
I'm so glad software engineering isn't my job. I love solving problems, and I'm somewhat better at using code to do it than my peers (fellow scientists), but I would hate to have a boss/client that says "it needs to do X" and the framework writer (or SDK, ala Android/Xcode) say "no, that hurts my profits/privacy busting".
Software companies all understand that so its not really a problem. Maybe in companies where the software isn't the main product
In Clojure land, the mantra has long been "libraries over frameworks" for this reason.
after 3 decades as SWE I mostly found both i) and ii) to not be true, for the most part. a lot of frameworks are not built from the ground up as “i am building a thing to solve x” but “i had a thing and built something that may (or may not) be generally useful.” so a lot of them carry weight from what they were originally built from. then people start making requests to mold the framework to their needs, some get implemented, some don’t. those that don’t good teams will build extensions/plugins etc into the framework and pretty soon you got a monster thing inside of your codebase you probably did not need to begin with. i think every single ORM that i’ve ever used fits this description.
And there was a time when using libraries and frameworks was the right thing to do, for that very reason. But LLMs have the equivalent of way more experience than any single programmer, and can generate just the bit of code that you actually need, without having to include the whole framework.
As someone who’s built a lot of frontend frameworks this isn’t what I’ve found. Instead I’ve found that you end up with the middle ground choice which while effective is no better than the externally maintained library of choice. The reason to build your own framework is so it’s tailor suited to your use cases. The architecting required to do that LLMs can help with but you have to guide them and to guide them you need expertise.
> can generate just the bit of code that you actually need
Design is the key. Codebases (libraries and frameworks not exempt,) have a designed uniformity to them. How does a beginner learn to do this sort of design? Can it be acquired completely by the programmer who uses LLMs to generate their code? Can it be beneficial to recognize opinionated design in the output of an LLM? How do you come to recognize opinion?
In my personal history, I've worked alongside many programmers who only ever used frameworks. They did not have coding design sensibilities deeper than a social populist definition of "best practice." They looked to someone else to define what they can or cannot do. What is right to do.
I would like a more reliable way to activate this "way more experience."
What I see in my own domain I often recognize as superficially working but flawed in various ways. I have to assume the domains I am less familiar are the same.
Claude's a smart junior engineer who's read a lot of books but is lacking in real word experience.
It definitely eliminates a lot of tedium, but needs a lot of guidance if you want good results.
Critically, they will also enable faster future migration to a framework in case it proves useful.
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.
Your last sentence describes my thoughts exactly. I try to incorporate Claude into my workflow, just to see what it can do, and the best I’ve ended up with is - if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better.
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 dont really understand how this is possible. I've built some very large applications, and even a full LLM data curation,tokenizer, pretrain, posttrain SFT/DPO pipeline with LLM's and it most certainly took far less time than if i had done it manually. Sure it isnt all optimal...but it most certainly isnt subpar, and it is fully functional
So you skipped the code review and just checked that it does what you needed it to do?
I don't know how anyone can make this assumption in good faith. The poster did not imply anything along those lines.
That looked like a leading question to me, asking for confirmation but not an outright assumption. Seems like a fair question
GPT-5 codex variants with xhigh reasoning make great code reviewers.
5.2 Codex is excellent at reviewing commits. I haven’t used 5.3, I assume it's as good or better.
Especially for large commits, it's become indispensable.
Then you are using it the wrong way
Driving is a skill that needs to be learnt, same with working with agents.
That is what's hard about transitioning from coder to lead. A good coder makes full use of a single thread of execution. A good lead effectively handles the coordination of multiple threads. Different skills.
An LLM coding assistant today is an erratic junior team member, but its destructive potential is nowhere near some of the junior human engineers I've worked with. So it's worth building the skills and processes to work with them productively. Today, Claude is a singular thing. In six months or a year, it'll be ten or a hundred threads working concurrently on dozens of parts of your project. Either you'll be comfortable coordinating them, or you'll nope out of there and remain an effective but solitary human coder.
I use conductor with git worktrees and will literally have 10 or 20 running at a time getting pinged as they finish stuff for me to review, mostly getting rid of small ticket and doing random POCs while I focus on bigger stuff, the bottleneck has literally become the company doesn't have enough stuff to give me. It only really works however because I have a lot of context and understanding of the codebase. It's already here.
I found coordinating skill usage across worktrees quite annoying, how are you managing this?
Are you giving it huge todos in one prompt or working modularly?
Claude set up account creation / login with SSO login, OTP and email notifications in like 5 mins and told me exactly what to do on the provider side. Theres no way that wouldn't have taken me few hours to figure out
There is no way its not faster at a large breadth of the work, unless youre maybe a fanatic with reviewing and nitpicking every line of code to the extreme
> I would have finished the project in the same amount of time
Probably less time, because you understood the details better.
> if I had written it completely by myself from the start, I would have finished the project in the same amount of time but I’d understand the details far better.
I believe the argument from the other camp is that you don't need to understand the code anymore, just like you don't need to understand the assembly language.
Of all the points the "other side" makes, this one seems the most incoherent. Code is deterministic, AI isn’t. We don’t have to look at assembly, because a compiler produces the same result every time.
If you only understand the code by talking to AI, you would’ve been able to ask AI “how do we do a business feature” and ai would spit out a detailed answer, for a codebase that just says “pretend there is a codebase here”. This is of course an extreme example, and you would probably notice that, but this applies at all levels.
Any detail, anywhere cannot be fully trusted. I believe everyone’s goal should be to prompt ai such that code is the source of truth, and keep the code super readable.
If ai is so capable, it’s also capable of producing clean readable code. And we should be reading all of it.
“Of all the points the other side makes, this one seems the most incoherent. Code is deterministic, AI isn’t. We don’t have to look at assembly, because a compiler produces the same result every time.”
This is a valid argument. However, if you create test harnesses using multiple LLMs validating each other’s work, you can get very close to compiler-like deterministic behavior today. And this process will improve over time.
It helps, but it doesn't make it deterministic. LLMs could all be misled together. A different story would be if we had deterministic models, where the exact same input always results in the exact same output. I'm not sure why we don't try this tbh.
I've been wondering if there are better random seeds, like how there are people who hunt for good seeds in Minecraft
it's literally just setting T=0. except they are not as creative then. they don't explore alternative ideas from the mean.
Are you sure that it’s T=0. My comment’s first draft said “it can’t just be setting temp to zero can it?” But I felt like T is not enough. Try running the same prompt in new sessions with T=0, like “write a poem”. Will it produce the same poem each time? (I’m not where I can try it currently).
> just add more magic turtles to the stack, bro
You're just amplifying hallucination and bias.
> other side???
> We don’t have to look at assembly, because a compiler produces the same result every time.
This is technically true in the narrowest possible sense and practically misleading in almost every way that matters. Anyone who's had a bug that only manifests at -O2, or fought undefined behavior in C that two compilers handle differently, or watched MSVC and GCC produce meaningfully different codegen from identical source, or hit a Heisenbug that disappears when you add a printf ... the "deterministic compiler" is doing a LOT of work in that sentence that actual compilers don't deliver on.
Also what's with the "sides" and "camps?" ... why would you not keep your identity small here? Why define yourself as a {pro, anti} AI person so early? So weird!
You just described deterministic behavior. Bugs are also deterministic. You don’t get different bugs every time you compile the same code the same way. With LLMs you do.
Re: “other side” - I’m quoting the grandparent’s framing.
GCC is, I imagine, several orders of magnitude mor deterministic than an LLM.
It’s not _more_ deterministic. It’s deterministic, period. The LLMs we use today are simply not.
Build systems may be deterministic in the narrow sense you use, but significant extra effort is required to make them reproducible.
Engineering in the broader sense often deals with managing the outputs of variable systems to get known good outcomes to acceptable tolerances.
Edit: added second paragraph
I'm not using a narrow sense. There is no elasticity here. See https://en.wikipedia.org/wiki/Deterministic_system
> significant extra effort is required to make them reproducible.
Zero extra effort is required. It is reproducible. The same input produces the same output. The "my machine" in "Works on my machine" is an example of input.
> Engineering in the broader sense often deals with managing the outputs of variable systems to get known good outcomes to acceptable tolerances.
You can have unreliable AIs building a thing, with some guidance and self-course-correction. What you can't have is outcomes also verified by unreliable AIs who may be prompt-injected to say "looks good". You can't do unreliable _everything_: planning, execution, verification.
If an AI decided to code an AI-bound implementation, then even tolerance verification could be completely out of whack. Your system could pass today and fail tomorrow. It's layers and layers of moving ground. You have to put the stake down somewhere. For software, I say it has to be code. Otherwise, AI shouldn't build software, it should replace it.
That said, you can build seemingly working things on moving ground, that bring value. It's a brave new world.
That will never happen unless we figure out a far simpler way to prove the system does what it should. If you've ever had bugs crop up with a full test suite you should know this is incredibly hard to do
LLMs can't read your mind. In the end they're always taking the english prompt and making a bunch of fill in the blank assumptions around it. This is inevitable if we're to get any productivity improvements out of them.
Sometimes it's obvious and we can catch the assumptions we didn't want (the div isn't centered! fix it claude!) and sometimes you actually have to read and understand the code to see that it's not going to do what you want under important circumstances
If you want a 100% perfect communication of the system in your mind, you should use a terse language built for it: that's called code. We'd just write the code instead
we can do both. we can write code for the parts where it matters and let the LLM code the parts that aren't as critical.
People who really care about performance still do look at the assembly. Very few people write assembly anymore, a larger number do look at assembly every so often. It’s still a minority of people though.
I guess it would be similar here: a small few people will hand write key parts of code, a larger group will inspect the code that’s generated, and a far larger group won’t do either. At least if AI goes the way that the “other side” says.
>I believe the argument from the other camp is that you don't need to understand the code anymore
Then what stops anyone who can type in their native language to, ultimately when LLM's are perfected, just order their own software instead of using anybody else's (speaking about native apps like video games, mobile phones, desktop, etc.)?
Do they actually believe we'll need a bachelor's degree to prompt program in a world where nobody cares about technical details, because the LLM's will be taking care of? Actually, scratch that. Why would the companies who're pouring gorrilions of dollars in investment even give access to such power in an affordable way?
The deeper I look in the rabbit hole they think we're walking towards the more issues I see.
At least for me, the game-changer was realizing I could (with the help of AI) write a detailed plan up front for exactly what the code would be, and then have the AI implement it in incremental steps.
Gave me way more control/understanding over what the AI would do, and the ability to iterate on it before actually implementing.
Indeed. This is very much the way I use it at work. Present an idea of a design, iterate on it, then make a task/todo list and work through the changes piecemeal, reviewing and committing as I go. I find pair design/discussion practical here too. I expect to see smaller teams working like this in the future.
For small personal projects, it's more vibey.. eg. Home automation native UIs & services for Mac & Windows, which I wouldn't otherwise start.. more itches that can be scratched in my limited time.
quite a bit of software you would need to understand the assembly. not everything is web-services.
I've found LLMs (since Opus 4.5) exceptionally good at reading and writing and debugging assembly.
Give them gdb/lldb and have your mind blown!
Do you mean gdb batch mode (which I've heard of others using with LLMs), or the LLM using gdb interactively ?
I've only needed assembly once in more than 20 years of programming, not a webdev
It was during university to get access to CPU counters for better instrumenting, like 15 years ago. Havent needed it since
Have you added agents.md files?
You have to do more than prompts to get the more impressive results
skill issue.
sorry for being blunt, but if you have tried once, twice and came to this conclusion, it is definitely a skill issue, I never got comfortable by writing 3 lines of Java, Python or Go or any other language, it took me hundreds of hours spent doing non-sense, failing miserably and finding out that I was building things which already exists in std lib.
> It's strange to me when articles like this describe the 'pain of writing code'.
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.
What I never understand is that people seem to think the conception of the idea and the syntactical nitty gritty of the code are completely independent domains. When I think about “how software works” I am at some level thinking about how the code works too, not just high level architecture. So if I no longer concern myself with the code, I really lose a lot of understanding about how the software works too.
Writing the code is where I discover the complexity I missed while planning. I don't truly understand my creation until I've gone through a few iterations of this. Maybe I'm just bad at planning.
At first I thought you were referring to the debates over using vim or using emacs, but I think you mean to refer to the discussions about learning to use/switching to powerful editors like vim or emacs. If you learn and use a sharp, powerful editor and learn to type fast, the "burden" of editing and typing goes away.
I wonder how many vibecoding/automatic programming zealots are fluent in a multimodal editor.
Have you really never found writing code painful?
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.
What you’ve described is very much not writing code though. It’s the tedious and unpleasant outcome of having a flaky or under resourced CI setup or pulling in a misbehaving dependency. Neither of those is typing code per se. I don’t think it’s fair to conflate that kind of problem with the creative work involved in implementation itself.
“Writing code is boring and tedious” says more about the speaker than it does about programming.
> I point Claude Code at it and 90% of the time I have the solution a couple of minutes later.
Same experience, I don't know why people keep saying code was easy part, sure, only when you are writing a boilerplate which is easy and expectations are clear.
I agree code is easier than some other parts, but not the easiest, industry employed millions of us, to write that easy thing.
When working on large codebases or building something in the flow, I just don't want to read all the OAuth2 scopes Google requires me to obtain, my experience was never: "now I will integrate Gmail, let me do gmail.FetchEmails(), cool it works, on to the next thing"
You have a solution, I've seen them recommend some pretty terrible bug fixes, especially in the ci realm because they get rather clueless as the perspective gets higher or broader
Incidentally, I've been using AI to deal with the weird bugs, cryptic errors and generally horrendous complexities of a framework we've been using at work (Elixir's Ash). It's really nice to no longer have to read badly organized docs, search the Internet for similar problems and ask around in the developers' Slack/Discord.
So many of my coding agent sessions start with "clone <github URL to relevant dependency> into /tmp for reference" - it's such a great pattern because incomplete or inaccurate decimation matters way less if the agent can dispatch a sub-agent to explore the codebase any time it needs to answer an obscure question.
I was talking to a coworker that really likes AI tooling and it came up that they feel stronger reading unfamiliar code than writing code.
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”.
Current models won't write anything new, they are "just" great at matching, qualifying, and copying patterns. They bring a lot of value right now, but there is no creativity.
95% of the industry wasn't creating creative value, it was repetitive.
* auth + RBAC, known problem, just needs integration
* 3rd party integration, they have API, known problem, just needs integration
* make webpage responsive, millions of CSS lines
* even video gaming, most engines are already written, just add your character and call couple of APIs to move them in the 3D space
Not sure what 95% of the industry created, but it did bring liquidity in my bank account and a roof over my head.
now what?
That's why they bring a lot of value. Plus, new models and methods enable solutions that weren't available a decade ago.
So true.
You can only complain about creativity if you were actually being creative. 99.99999% of the industry was not.
But sure, for the 0.000001% of the industry coming up with new deep learning algorithms instead of just TF/PyTorch monkey-ing, maybe the LLMs won’t help as much as a good foundation in some pretty esoteric mathematics.
Tolkien's book is an art, programs are supposed to do something.
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.
People are different. Some are painters and some are sculptors. Andy Warhol was a master draftsman but he didn't get famous off of his drawings. He got famous off of screen printing other people's art that he often didn't own. He just pioneered the technique and because it was new, people got excited, and today he's widely considered to be a generational artistic genius.
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.
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 the ends justifies the means is a well-worn disagreement/debate, and I think the only solid conclusion we've come to as a society is that it depends.
That's a moral debate, not suitable for this discussion.
The discussion at hand is about purity and efficiency. Some people are process oriented, perfectionists, purists that take great pride in how they made something. Even if the thing they made isn't useful at all to anyone except to stroke their own ego.
Others are more practical and see a tool as a tool, not every hammer you make needs to be beautiful and made from the best materials money can buy.
Depending on the context either approach can be correct. For some things being a detail oriented perfectionist is good. Things like a web framework or a programming language or an OS. But for most things, just being practical and finding a cheap and clever way to get to where you want to go will outperform most over engineering.
It sure is myopic to think that the debate over if the ends justifies the means is solely a moral consideration, and then literally list cases where the value of the means compared to the ends is a judgment call results in "it depends".
Writing he code should be the easy part and one of the smaller time sinks actually. The fruits of the labour is in the planning, the design, the architecture and the requirements that you want to achieve now and potentially in the future.. these all require a serious amount of effort and foresight to plan out.
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.
I don't find writing code painful, but I do find it tedious. The amount of time wasted on boilerplate keeps me from getting to the good stuff. LLMs let me speed run through all of 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.
I agree with your point. My concern is more about the tedious aspects. You could argue that tedium is part of what makes the craft valuable, and there's truth to that. But it comes down to trade-offs, what could I accomplish with that saved time, and would I get more value from those other pursuits?
If you're gonna take this track, at least be honest with yourself. Does your boss get more value out of you? You aren't going to get a kickback from being more productive, but your boss sure will.
I had this moment recently with implementing facebook oauth. I don’t need to spend mental cycles figuring that out, doing the back and forth with their API, pulling my hair out at their docs, etc. I just want it to work and build my app. AI just did that part for me and could move on.
Integrating auth code is probably a good example of code you want to understand, rather than just seeing that it appears to work.
I honestly think the stuff AI is really good at is the stuff around the programming that keeps you from the actual programming.
Take a tool like Gradle. Bigger pain in the ass using an actual cactus as a desk chair. It has a staggering rate of syntax and feature churn with every version upgrade, sprawling documentation that is clearly written by space aliens, every problem is completely ungoogleable as every single release does things differently and no advice stays valid for more than 25 minutes.
It's a comically torturous DevEx. You can literally spend days trying to get your code to compile again, and not a second of that time will be put toward anything productive. Sheer frustration. Just tears. Mad laughter. Rocking back and forth.
"Hey Claude, I've upgraded to this week's Gradle and now I'm getting this error I wasn't getting with last week's version, what could be going wrong?" makes all that go away in 10 minutes.
I'm glad to hear the gradle experience hasn't changed in the decade since I started avoiding it.
I think it's still an open question if it's actually a net savings of time.
One thing I’ve noticed is that effort may be saved but not as much time. The agent can certainly type faster than me but I have to sit there and watch it work and then check its work when done. There’s certainly some time savings but not what you think.
Another thing I've noticed is that using AI, I'm less likely to give existing code another look to see if there's already something in it that does what I need. It's so simple to get the AI to spin up a new class / method that gets close to what I want, so sometimes I end up "giving orders first, asking questions later" and only later realizing that I've duplicated functionality.
The absence of evidence is evidence in its own way. I don’t understand how there haven’t been more studies on this yet. The one from last year that showed AI made people think they were faster but were actually slower gets cited a lot, and I know that was a small study with older tools, but it’s amazing that that hasn’t been repeated. Or maybe it has and we don’t know because the results got buried.
Isn't that what Tolkien did in his head? Write something, learn what he liked/didn't like then revise the words? Rinse/repeat. Same process here.
If Tolkien had not lived an entire life, fought in a war, been buddies with other authors, and also been a decent writer, the story doesn’t exist. And an LLM won’t come up with it.
An LLM isn’t coming up with the eye of Sauron, or the entire backstory of the ring, or gollum, etc etc
The LLM can’t know Tolkien had a whole universe built in his head that he worked for decades to get on to paper.
I’m so tired of this whole “an LLM just does what humans already do!” And then conflating that with “fuck all this LLM slop!”
“ What’s gone is the tearing, exhausting manual labour of typing every single line of code.”
Yeah, this was always the easy part.
I didn't fully realize how much pain there was until I started delegating the coding to AI. It's very freeing. Unfortunately I think this will soon lead to mass layoffs.
Pain can mean tedium rather than intellectual challenge.
I really struggle to understand how people can find coding more tedious than prompting. To each their own I guess.
I can only speak for myself but for me, it's all about the syntax. I am terrible at recalling the exact name of all the functions in a library or parameters in an API, which really slows me down when writing code. I've also explored all kinds of programming languages in different paradigms, which makes it hard to recall the exact syntax of operators (is comparison '=' or '==' in this language? Comments are // or /*? How many parameters does this function take, and in what order...) or control structures. But I'm good at high level programming concepts, so it's easy to say what I want in technical language and let the LLM find the exact syntax and command names for me.
I guess if you specialise in maintaining a code base with a single language and a fixed set of libraries then it becomes easier to remember all the details, but for me it will always be less effort to just search the names for whatever tools I want to include in a program at any point.
I agree with a bunch of this (I'm almost exclusively doing python and bash; bash is the one I can never remember more than the basics of). I will give the caveat that I historically haven't made use of fancy IDEs with easy lookup of function names, so would semi-often be fixing "ugh I got the function name wrong" mistakes.
Similar to how you outlined multi-language vs specialist, I wonder if "full stack" vs "niche" work unspokenly underlies some of the camps of "I just trust the AI" vs "it's not saving me any time".
Some code is fun and some sucks?
There's a joke that's not entirely a joke that the job of a Google SWE is converting from one protobuf to another. That's generally not very fun code, IMO (which may differ from your opinion and that's why they're opinions!). Otoh, figuring out and writing some interesting logic catches my brain in a way that dealing with formats and interoperability stuff doesn't usually.
We're all did but we all probably have things we like more than others.
I mean, I agree if it's really just "machine translate this code to use the approved method of doing this thing". That seems like a perfect use case for AI. Though one would think Google would already have extensive code mod infrastructure for that kind of thing.
But those aren't the stories you hear about with people coding with AI, which is what prompted my response.
They do and I think a lot of that is LLM'd these days, though that's just what I hear third-hand.
I do agree that this:
> What’s gone is the tearing, exhausting manual labour of typing every single line of code.
seems more than a little overblown. But I do sympathize with not feeling motivated to write a lot of glue and boilerplate, and that "meh" often derails me on personal projects where it's just my internal motivation competing against my internal de-motivation. LLMs have been really good there, especially since many of those are cases where only I will run or deal with the code and it won't be exposed to the innertubes.
Maybe the author can't touch type, but that's a separate problem with its own solution. :)
Sometimes you are not writing Lord of the Rings.
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.
Please forgive me for being blunt, I want to emphasize how much this strikes me.
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.
I think my take on the matter comes from being a games developer. I work on a lot of code for which agentic programming is less than ideal - code which solves novel problems and sometimes requires a lot of precise performance tuning, and/or often has other architectural constraints.
I don't see agentic programming coming to take my lunch any time soon.
What I do see it threatening is repetitive quasi carbon copy development work of the kind you've mentioned - like building web applications.
Nothing wrong with using these tools to deal with that, but I do think that a lot of the folks from those domains lack experience with heavier work, and falsely extrapolate the impact it's having within their domain to be applicable across the board.
> Your post feels like the last generation lamenting the new generation.
> The future is exciting.
Not the GP, but I honestly wanted to be excited about LLMs. And they do have good uses. But you quickly start to see the cracks in them, and they just aren't nearly as exciting as I thought they'd be. And a lot of the coding workflows people are using just don't seem that productive or valuable to me. AI just isn't solving the hard problems in software development. Maybe it will some day.
> Your post feels like the last generation lamenting the new generation [...] There's so much plumbing and refactoring bullshit in writing code [...] I've had my excitement
I don't read the OP as saying that: to me they're saying you're still going to have plumbing and bullshit, it's just your plumbing and bullshit is now going to be in prompt engineering and/or specifications, rather than the code itself.
> I want to be able to make art and music and movies and games.
Then make them. What's stopping you?
I want to live forever and set foot on distant planets in other galaxies.
Got a prescription for that too?
I've made films for fifteen years. I hate the process.
Every one of my friends and colleagues that went to film school found out quickly that their dreams would wither and die on the vine due to the pyramid nature of studio capital allocation and expenditure. Not a lot of high autonomy in that world. Much of it comes with nepotism.
There are so many things I wish to do with technology that I can't because of how much time and effort and energy and money are required.
I wish I could magic together a P2P protocol that replaced centralized social media. I wish I could build a completely open source GPU driver stack. I wish I could make Rust compile faster or create an open alternative to AWS or GCP. I wish for so many things, but I'm not Fabrice Bellard.
I don't want to constrain people to the shitty status quo. Because the status quo is shitty. I want the next generation to have better than the bullshit we put up with. If they have to suffer like we suffered, we failed.
I want the future to climb out of the pit we're in and touch the stars.
Computing technology always becomes cheaper and more powerful over time. But it's a slow process. The rate of improvement for LLMs is already decreasing. You will die of old age before the technology that you seem to be looking for arrives.
Burn the planet to the ground because your life is boring. Extremely mature stance you've got there
This is 1960's era anti-nuclear all over again.
People on Reddit posting AI art are getting death threats. It's absurd.
> If you've ever enjoyed the sci-fi genre, do you think the people in those stories are writing C and JavaScript?
To go off the deep end… I actually think this LLM assistant stuff is a precondition to space exploration. I can see the need for a offline compressed corpus of all human knowledge that can do tasks and augment the humans aboard the ship. You’ll need it because the latency back to earth is a killer even for a “simple” interplanetary trip to mars—that is 4 to 24 minutes round trip! Hell even the moon has enough latency to be annoying.
Granted right now the hardware requirements and rapid evolution make it infeasible to really “install it” on some beefcake system but I’m almost positive the general form of moores law will kick in and we’ll have SOTA models on our phones in no time. These things will be pervasive and we will rely on them heavily while out in space and on other planets for every conceivable random task.
They’ll have to function reliably offline (no web search) which means they probably need to be absolutely massive models. We’ll have to find ways to selectively compress knowledge. For example we might allocate more of the model weights to STEM topics and perhaps less to, I dunno, the fall of the Roman Empire, Greek gods or the career trajectory of Pauly Shore. the career trajectory of Pauly Shore. But perhaps not, because who knows—-maybe a deep familiarity with Bio-Dome is what saves the colony on Kepler-452b
Oh, no, you're imagining the wrong subgenre of sci-fi. These robots are actually owned and operated by billionaires.
Claude Opus 4.6:
“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.
Claude already knows who the characters Frodo, Sam, and Gollum are, what their respective character traits are, and how they interacted with each other. This isn't the same as writing something new.
Do you find this interesting to make and read?
I am probably the only person who ever willingly created a complete AI generated book and willingly read it front to cover. Last summer. I called it "Claude Code: A Primer" an Claude Code Origin Story. Good book, complete made up.
The technology is here, lets explore it. And when somebody states something in an HN comment. Lets just try it. Imperfect method. But better than to just talk Hypothetically about AI.
If AI will write better books than ever written until now? More insights than ever created before. Would we read it? Is it even possible? If not, why not. Whats is missing?
Thats the questions I find fascinating. I for one want to find out. With experimentation, not via predefined believes.
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.
Yeah, I really don't get it. So instead of using someone else's framework, you're using an AI to write a (probably inferior and less thoroughly tested and considered) framework. And your robot employee is probably pulling a bunch of stuff (not quite verbatim, of course) from existing relevant open source frameworks anyway. Big whoop?
It's not really easy to not use React, since it was hyped to no end and now is entrenched. Try to get a frontend job without knowing React.
That's a different complaint.
It's quite easy to make things without react, it's not our fault that business leaders don't let devs choose how to solve problems but hey who am I to complain? React projects allow me to pay my bills! I've never seen a good "react" project yet and I've been working professionally with react since before class components were a thing.
Every react code base has their own unique failures due to npm ecosystem, this will never change. In fact, the best way to anticipate what kind patterns are in a given react project is to look at their package.json.
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.
I was thinking the same. On mobile both frameworks and libraries make my life infinitely easier
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 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
> re-implement chunks of existing frameworks without the real-world battle testing
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.
> the supporting ecosystem, ... the common parlance and patterns
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.
AI has a lot of "leaders" currently working through a somewhat ignorant discovery of existing domain knowledge (ask me how being a designer has felt in the last 15 years of UX Leadership™ slowly realizing there's depth to the craft).
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.
I had called this a while back, since the reasoning is simple: frameworks primarily exist to minimize biolerplate, but AI is very good at biolerplate, 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 economics 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 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.
> 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.
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.
It seems to me that a lot of the discussion stems around different definitions of the word framework and I believe library is probably the more appropriate term to use here. I wouldn't replace .net framework with something I vibe coded but your example of a library of not so specific functions is ripe for replacement. If you're only using 5% of a library you've probably written as much adapter code as you would have if it was just specific code to solve your problem.
I didn’t even give Claude (Opus 4.1) the registers when I did this for a recent ESP32 + ST7789 Rust project. I think I literally just said “make a driver with a double frame buffer for the ST7789 on SPI1, with DMA updates“. And it did it.
In my experience, often the libs provided by manufacturers are thin wrappers over physical interface setup and communication in the form of a single header and cpp file. Isnt it easier to just use them instead of generating differently phrased copies of them?
The vast majority of parts do not have libraries provided by a manufacturer.
Instead, you get a datasheet (if you're using a well-known part) that contains a list of registers which you need to either write functions against or hope someone on GitHub has done the work for you.
Some display modules do come with sample code that you can build (on a good day) to test things out, but these are almost always half-baked and feel more like HELLO WORLD than something you'd use as a cornerstone of your product development.
Other parts come with sample code that is explicitly designed to work with an expensive $200 "dev board" that you're supposed to use to generate the code you're intended to drop into your project. It's just my opinion, but I'd rather use an LLM for this and skip the dev board stage.
The reason libraries like Adafruit Graphics exist is precisely because the code that comes with the display panels they sell is usually less helpful than if it didn't exist.
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.
I'm not sure. I don't know about deep expertise and mastery, but I can attest that my fluency skyrocketed as the result of AI in several languages, simply because the friction involved in writing them went own by orders of magnitude. So I am writing way more code now in domains that I previously avoided, and I noticed that I am now much more capable there even without the 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.
People said the same thing about the transition to higher levels of abstraction in the past. “How will they write good code if they don’t know assembly? How can they write efficient code if they don’t understand how a microprocessor works?”
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.
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.
It’s fun to ask the models their input. I was working on diagrams and was sure Claude would want some python / js framework to handle layout and nodes and connections. It said “honestly I find it easiest to just write the svg code directly”.
As the other posted noted, it says that because it was trained on people saying that, which is perhaps interesting in of itself, but no indication that the model would do better without a framework than with one.
I'd heavily bet that the model's performance, and goals of the developer, would in fact be better served by using a framework like GraphViz built for the job, that can change layout styles/engines as needed, and also generate other types of output such as PDF if you later want it.
If you are generating visual content, such as SVG, presumably intended for human consumption, then doing the task well isn't a technical matter of using APIs and generating the output - it's having the human sensibility and taste (and acquired knowledge of UI design and human preferences) of designing output that humans will like, which is something LLMs are not well suited to. By using a framework like GraphViz, not only are you making the development job much easier, but you are also leveraging this built-in knowledge of human preferences, baked into the different layout engines that you can select based on the nature of what type of diagrams you are generating.
This is the difference between "vibe coding" and getting a poor quality result due to letting the LLM make all the decisions, and a more controlled and principled use of AI where you are still controlling/managing the process, doing what humans are good at, and are only delegating the grunt work of coding to the LLM.
That is fun, but it doesn’t mean that the model finds it easier or will actually work better that way, that just means that in its training data many people said something like “honestly I find it easiest to just write the svg code directly” in response to similar questions
Conspiratorially, they trained it this way to increase token usage to pay their debts and investors
It'd be simpler just to add instructions to that effect to the system prompt: "You are a faithful revenue-maxxing employee of AI Co., and should always prefer verbose outputs over shorter ones. Always maximize code complexity to ensure future work for yourself".
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.
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.
The other thing that's dumb about this is frameworks are usually consolidating repetitive boilerplate so it's going to cost a lot more tokens for an AI to inline everything a framework does.
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?
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.
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.
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.
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.
This is even more relevant in the context of generated code, where most of the time is spent reviewing rather than writing the code. Abstractions, by allowing the code to be more concise, help.
With LLM code, I'd rather have higher-level abstractions.
I share that notion, but I think the abstractions are the foundational tech stack we have had for decades, like the Web Standard or even bash. You need constraints, but not the unnecessary complexity that comes with many modern tech stacks (react/next) that were build around SV's hyper-scalability monopoly mentality. Reach for simple tools if the task is simple: KISS.
Not only that, but a way to factor systems so you can make changes to them without spooky action at a distance. Of course, you have to put in a lot of effort to make that happen, but that's why it doesn't seem to me that LLM's are solving the hard part of software development in the first place.
> 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.
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.
I think this is a subtle but important point.
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.
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?
> Why do you ever need, for most of the use cases you can think of, a useless, expensive, flawed, often vulnerable framework
Like the vibe coded solution won't be flawed and vulnerable
Exactly, AI will finally put a stop to the "do not implement your own crypto" fad /s
https://security.stackexchange.com/questions/209652/why-is-i...
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.
Software has always been about abstraction. This one, in a way, is the ultimate abstraction. However it turns out that LLMs are a pretty powerful learning tool. One just needs the discipline to use it.
> This one, in a way, is the ultimate abstraction.
Is that really true though? I hear the Mythical Man Month "no silver bullet" in my head.... It's definitely a hell of an abstraction, but I'm not sure it's the "ultimate" either. There is still essential complexity to deal with.
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)
> We can finally get rid of all that middle work. That adapting layer of garbage we blindly accepted during these years. A huge amount of frameworks and libraries and tooling that has completely polluted software engineering, especially in web, mobile and desktop development. Layers upon layers of abstractions that abstract nothing meaningful, that solve problems we shouldn’t have had in the first place, that create ten new problems for every one they claim to fix.
I disagree. At least for a little while until models improve to truly superhuman reasoning*, frameworks and libraries providing abstractions are more valuable than ever. The risk/reward for custom work vs library has just changed in unforeseen ways that are orthogonal to time and effort spent.
Not only do LLMs make customization of forks and the resulting maintenance a lot easier, but the abstractions are now the most valuable place for humans to work because it creates a solid foundation for LLMs to build on. By building abstractions that we validate as engineers, we’re encoding human in the loop input without the end-developer having to constantly hand hold the agent.
What we need now is better abstractions for building verification/test suites and linting so that agents can start to automatically self improve their harness. Skills/MCP/tools in general have had the highest impact short of model improvements and there’s so much more work to be done there.
* whether this requires full AGI or not, I don’t know.
I have to tell claude specifically to use plain html css js, else it goes on building react
There was a time around 2016 where you weren't allowed to write a React application without also writing a "Getting Started with React" blog post. Having trained on all of that, the AI probably thinks React is web development.
Tell claude to build a functional website using plain html and css and no frameworks and it'll do it in a second. Now try that with a junior dev.
I guess juniors are different these days. In my generation a lot of people's first contact with code was doing basic (html, css, bits of js) web development. That was how I got started at like 12 or 13.
Just write up your requirements in and AGENT.md, to avoid repeating yourself. It has worked really well for me on a PHP+Apache project.
Indeed, this has been one of the first things I've noticed
Few months ago I did exactly this. But over time I threw away all the generated js,css and html. It was unmaintenable mess. I finally chose Svelte and stuck with it. Now I have a codebase which makes sense to me.
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.
> 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?
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.
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.
> 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.
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
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.
> no amount of AI is going to help you debug why your auth flow suddenly broke.
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.
I'm confused too. When it breaks, you should have tests and a changelog handy. I solve these problems with agents routinely.
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.
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.
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.
Thank you the insightful feedback :) If you also have something to say on the point of the article itself, instead of pointing the finger on the person I'll be happy to answer on that
LLMs finally deliver on the crochety front end dev's dream of writing everything in vanilla JS. Hallelujah.
> 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.
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...
...and importantly, neither does the LLM; frameworks are incredibly useful even if you are using generative AI.
Yes, that was one of the first aha moments for me; put simply:
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.
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?
Frameworks help you reduce to the point to irreducible complexity.
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
I see Libraries and frameworks as a way to capture knowledge and best practices so it can be shared with other people. So looking wat a LLM/AI does, it looks to me that this would be a perfect fit. Without the dependeny hell, unresolved github issues, need to fork and leaving maintainers. It could be opensource on steroïdes, with far shorter feedbackloops (just working in your IDE).
The main burden I see is validation of the output and getting reproducable results. As with many AI solutions.
What they are basically saying : a framework built up from bash-or-makefile-ground by an LLM, is better than any existing framework. I don't agree. When I use LLMs to generate scripts for me, I often have to adapt them to fit in the bigger picture. The more scripts I have, the more blurred becomes what that framework as a whole stands for. Then to become a usable framework, refactoring is needed, which means the calls to those scripts need rewriting and retesting as well.
It never left, welcome back to software engineering though!
Thank you, I'm glad to be back!
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.
I think if anything frameworks will become more important. They are already built into the training data of these models and they provide guardrails like protection against xss and sql injection. They are an architectural decision like anything else but why reinvent the wheel even if its an LLM doing the work?
You can also decide to switch frameworks or even languages. I switched a personal app I'm working on from Go to Deno and Hono and it's quite nice.
I don't see it as either/or. Frameworks give you a common vocabulary to use with the LLMs, and what allow you to organize your thoughts and maintain good git hygiene, and serve as a useful street map to review and explore what's been built.
Frameworks are stable by design, generated code isn't. Why people still had to learn math when calculator was invented?
> We can finally get rid of all that middle work. That adapting layer of garbage we blindly accepted during these years.
Oh, you accepted that? I feel sorry for you. Many of us never did.
You can drop the boilerplate bit pushing glue frameworks, but the building block frameworks are here to stay; LLMs know a lot, but they don’t know every solution to every problem. Do not confuse a software development LLM assistant with an oracle.
Strange how many people are comparing code to art. Software engineering has never been about the code written, it’s about solving problems with software. With AI we can solve more problems with software. I have been writing code for 25 years, I love using AI. It allows me to get to the point faster.
The author is right, eliminating all this framework cruft will be a boon for building great software. I was a skeptic but it seems obvious now its largely going to be an improvement.
That took the strangest turn. It started with empowerment to do much more (and that I reallY agree with) — to then use it to... build everything from scratch? What? Why?
What a framework gives me is mostly other people having done precisely the architectural work, that is a prequisite to my actual work. It's fantastic, for the same reason that automatic coding is. I want to solve unsolved problems asap.
I am so confused by the disconnect that I feel like I must be missing something.
It's actually so over
I feel the opposite. Frameworks and standardization becomes even more important when using AI.
"Software engineers are scared of designing things themselves."
So the answer is to let AI agents design it for you, trained on the data of the giants of software engineering. Got it!
> But the true revolution happened clearly last year
Oh, that seems like a good bit of time!
> and since December 2025
So like..1 or 2 months ago? This is like saying “over half of people who tried our product loved it - all 51% of them!”. This article is pushing hype, and is mistaking Anthropics pre IPO marketing drive as actual change.
> What’s gone is the tearing, exhausting manual labour of typing every single line of code.
I constantly see this and think I must be operating in a different world. This never took significant amounts of time. Are people using react to make text blogs or something?
When you choose the right framework it saves you enormous amounts of time. Sounds like the author has trouble separating hype from fact. Pick the right framework and your LLM will work better, too.
Wouldn't frameworks be better for Ai?
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.
Pretty much completely disagree with the OP. Software Engineering never left, maybe the author moved away from it instead.
> Stop wrapping broken legs in silk. Start building things that are yours.
This however is deeply wrong for me. Anyone who writes and reviews code regularly knows very well that reading code doesn't lead to the same deep intuitive understanding of the codebase as writing same code.
So, no, with AI you are not building things which are yours. You might call them yours, but you lose deeper understanding of what you built.
> That adapting layer of garbage we blindly accepted during these years.
Wouldn't everything that agents produce be better described as a "layer of garbage?"
If a framework, best a minimal one using web standards E.g. svelte or https://nuejs.org/.
You're right, clearly I've tried to be a bit provocative to pass the message, but I'm not religious in this sense. Minimal frameworks that really solve a problem cleanly and are adopted with intention are welcome.
lol ok have fun building from zero _without_ abstractions. It will work for the narrow thing you first tell it to build, the fun comes when you tell it to change in any way.
There is yet another issue: the end-users are fickle fashion minded people, and will literally refuse to use an application if it does not look like the latest React-style. They do not want to be seen using "old" software, like wearing the wrong outfit or some such nonsense. This is real, and baffling.
This line shows either he does not get how wrong he is, or I do not understand the deepness of his enlightenment. "A simple Makefile covers 100% of my needs for 99% of my use cases". We've come a long way to replace simple Makefile with autotools (incredible monstrocity), cmake, ninja etc. I hope he does not propose to ditch *libc.
I've never did see any value in monsters like React. Always use plain JavaScript, wrote web components and used some narrow scope 3rd party libraries. Works like a charm for me. Now instead of writing whole web components on my own I write skeletons with some comments and ask IDE with AI services (I use IDEs from JetBrains) to complete it. I then do the same with tee main application. So far the results are stellar. I do similar with my backend applications (mostly C++) but there is much more work from my side is involved as the requirements are way stricter, for example performance being a major thing.
LinkedIn article?
What frameworks and what have you accomplished with it?
I feel like commenting on the article without reading was really vindicated with the advent of AI slop.
Build libraries, not frameworks.
"Software engineers are scared of designing things themselves."
what?
Read the following paragraph. The author isn't wrong.
> I want to build X > "Hey claude, how would you make X" > Here's how I'd build X... [Plan mode on]
In big corporations that's how it is. Developers are told to only implement what is in the specs and if they have any objection, they need to raise it to PM who will then forward it to the system architect etc.
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.
With a line like that I wouldn't trust anything this guy has to say.
Thank you for the constructive feedback :)
The author makes a valid observation wrapped in an overstatement. Yes, AI coding agents have changed the economics of building custom tooling. But the conclusion—that frameworks are now obsolete—misses the forest for the trees.
The problem with "framework culture" wasn't that frameworks exist, but that we lost the ability to critically evaluate when they're appropriate. We reached for React for static sites, Kubernetes for three-server deployments, and microservices for monolithic problems—not because these tools were wrong, but because we stopped thinking.
What AI agents actually restore isn't "pure software engineering"—it's optionality. The cost of writing a custom solution has dropped dramatically, which means the decision tree has changed. Now you can prototype both approaches in an afternoon and make an informed choice.
But here's what AI doesn't solve: understanding the problem domain deeply enough to architect a maintainable solution. You can generate 10,000 lines of bespoke code in minutes, but if you don't understand the invariants, edge cases, and failure modes, you've just created a different kind of technical debt—one that's harder to unwind because there's no community, no documentation, and no shared understanding.
Frameworks encode decades of collective battle scars. Dismissing them entirely is like dismissing the wheel because you can now 3D-print custom rollers. Sometimes you want the custom roller. Sometimes you want the battle-tested wheel. AI gives you both options faster—it doesn't make the decision for you.
> The three problems frameworks solve (or claim to) [..] Simplification [..] Automation [..] Labour cost
and he misses _the most important problem frameworks solve_
which is correctness
when it comes to programming most things are far more complicated in subtle annoying ways then they seem to be
and worse while you often can "cut away" on this corner cases this also tends to lead to obscure very hard to find bugs including security issues which have a tendency to pop up way later when you haven't touched to code for a while and don't remember which corner you cut (and with AI you like did never know which corner you did cut)
like just very recently some very widely used python libraries had some pretty bad bugs wrt. "basic" HTTP/web topics like http/multipart request smuggling, DOS from "decompression bombs" and similar
and while this might look like it's a counter argument, it speaks for strict code reuse even for simple topics. Because now this bugs have been fixed! And that is a very common topic for frameworks/libraries, they start out with bugs, and sadly often the same repeated common bugs known from other frameworks, and then over time things get ironed out.
But with AI there is an issue, a lot of the data it's trained on is code _which does many of this "typical" issues wrong_.
And it's non-determenistic, and good at "hiding" bugs, especially the kind of bugs which anyway are prone to pass human reviews.
So you _really_ would want to maximize use of frameworks and libraries when using AI, as that large part of the AI reliability issues.
But what does change is that there is much less reason to give frameworks/libraries "neat compact APIs" (which is a common things people spend A LOT of time one and which is prone to be the source of issues as people insist on making things "look simpler" then they are and in turn accidentally make them not just simpler but outright wrong, or prevent use-cases you might need).
Now depending on you definition of framework you could argue that AI removes boiler-parts issues in ways which allow effectively replacing all frameworks with libraries.
But you still need to review code, especially AI generated code. To some degree the old saying that code is far more read then written is even more true with AI (as most isn't "written"(by human) anymore). Now you could just not review AI code, but that can easily count as gross negligence and in some jurisdictions it's not (fully) possible to opt out of damages from gross negligence no matter what you put in TOS or other contracts. I.e. I can't recommend such negligent actions.
So IMHO there is still use for some kind of frameworks, even if what you want from them will likely start to differ and many of them can be partially or fully "librarified".
AI rolled cryptographic libraries now make it feasible to just roll your own crypto.
> Layers upon layers of abstractions that abstract nothing meaningful, that solve problems we shouldn’t have had in the first place, that create ten new problems for every one they claim to fix.
LLM generated code is the ultimate abstraction. A mess of code with no trusted origin that nobody has ever understood. It's worse than even the worst maintained libraries and frameworks in every way.
If you have no idea on how to setup the pillars you're absolutely right, maybe you should try
Mindblowing observations.
Every day I feel closer to leaving this industry when I see articles like this.
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.
I suggest to read the full article :)
The thesis of the article is that software other people have built is bad (frameworks) but software my LLM agent is good (for undisclosed reasons).
I think it just adds to the noise of our industry that reusable patterns and standards don't matter
Nah. Nothing has changed. To offload the work to an agent and make it a productivity gain it is exactly the same as using a framework, it's a black box portion of your system, written by someone else, that you don't understand.
Unless you are quite literally spending almost the same amount of time you'd spend yourself to deeply understand each component, at which point, you could write it yourself anyway, nothing has changed when it comes to the dynamics of actually authoring systems.
There are exceptions, but generally speaking untempered enthusiasm for agents correlates pretty well with lack of understanding about what engineering software actually entails (it's about relational and conceptual comprehension, communication, developing shared knowledge, and modeling, not about writing code or using particular frameworks!)
EDIT: And to be clear, the danger of "agentizing" software engineering is precisely that it promotes a tendency to obscure information about the system, turn engineers into personal self-llm silos, and generally discard all the second-order concerns that make for good systems, resilience, modifiability, intelligibility, performance.
The author makes a valid observation wrapped in an overstatement. Yes, AI coding agents have changed the economics of building custom tooling. But the conclusion—that frameworks are now obsolete—misses the forest for the trees.The problem with "framework culture" wasn't that frameworks exist, but that we lost the ability to critically evaluate when they're appropriate. We reached for React for static sites, Kubernetes for three-server deployments, and microservices for monolithic problems—not because these tools were wrong, but because we stopped thinking.What AI agents actually restore isn't "pure software engineering"—it's optionality. The cost of writing a custom solution has dropped dramatically, which means the decision tree has changed. Now you can prototype both approaches in an afternoon and make an informed choice.But here's what AI doesn't solve: understanding the problem domain deeply enough to architect a maintainable solution. You can generate 10,000 lines of bespoke code in minutes, but if you don't understand the invariants, edge cases, and failure modes, you've just created a different kind of technical debt—one that's harder to unwind because there's no community, no documentation, and no shared understanding.Frameworks encode decades of collective battle scars. Dismissing them entirely is like dismissing the wheel because you can now 3D-print custom rollers. Sometimes you want the custom roller. Sometimes you want the battle-tested wheel. AI gives you both options faster—it doesn't make the decision for you.
This is about green field development which is relatively rare. Much of the time the starting point is a bunch of code using React or maybe just a lump of PHP. Business logic ends up plunked down all over the place and LLMs tend to make a huge mess with all this unless kept on a tight leash.
I'm glad this guy is doing well, but I'm dreading the amount of work being created for people who can reverse engineer the mountains of hallucinated bullshit that he and others are now actively producing.
And if the frameworks aren't useful then maybe work up the chain and ditch compilers next?
Next up "coding agents replaced me"
I feel the same way, but I’m not a traditional software engineer. Just an old-school Webmaster who’s been trying to keep up with things, but I’ve had to hire developers all along.
I’m an idea’s guy, and in the past month or so my eyes have also fully opened to what’s coming.
But there’s a big caveat. While the actual grunt work and development is going away, there’s no telling when the software engineering part is going to go away as well. Even the ideas guy part. What happens when a simple prompt from someone who doesn’t even know what they’re doing results in an app that you couldn’t have done as well with whatever software engineering skills you have?
ai slop shit
Interesting analysis