17 ms·

Coding agents have replaced every framework I used

• darvid 8mo ago
  "Software engineers are scared of designing things themselves." what?
  • booleandilemma 8mo ago
    With a line like that I wouldn't trust anything this guy has to say.
    • alainrk 8mo ago
      Thank you for the constructive feedback :)
  • direwolf20 8mo ago
    Read the following paragraph. The author isn't wrong.
  • ramon156 8mo ago
    > I want to build X > "Hey claude, how would you make X" > Here's how I'd build X... [Plan mode on]
  • varispeed 8mo ago
    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.
• seanclayton 8mo ago
  It never left, welcome back to software engineering though!
  • alainrk 8mo ago
    Thank you, I'm glad to be back!
• deleted 8mo ago
  [deleted]
• sixQuarks 8mo ago
  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?
• defactor 8mo ago
  I have to tell claude specifically to use plain html css js, else it goes on building react
  • alainrk 8mo ago
    Indeed, this has been one of the first things I've noticed
  • paxys 8mo ago
    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.
    • FeteCommuniste 8mo ago
      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.
  • billyp-rva 8mo ago
    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.
    • owenversteeg 8mo ago
      To be fair, trying to teach something is one of the better ways to learn it in depth. Of course, before hitting "publish" you should make sure you actually can teach well, or at least coherently... something most of those blogs forgot.
  • deleted 8mo ago
    [deleted]
  • quaintdev 8mo ago
    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.
• mentalgear 8mo ago
  If a framework, best a minimal one using web standards E.g. svelte or https://nuejs.org/ https://nuejs.org/.
  • alainrk 8mo ago
    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.
• xyzsparetimexyz 8mo ago
  It's actually so over
• voidhorse 8mo ago
  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.
• CuriouslyC 8mo ago
  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.
  • mentalgear 8mo ago
    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.
  • wtetzner 8mo ago
    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.
  • hiq 8mo ago
    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.
• softwaredoug 8mo ago
  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.
• netrem 8mo ago
  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.
  • deleted 8mo ago
    [deleted]
  • jayd16 8mo ago
    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.
• abcde666777 8mo ago
  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.
  • n4r9 8mo ago
    Pain can mean tedium rather than intellectual challenge.
    • wtetzner 8mo ago
      I really struggle to understand how people can find coding more tedious than prompting. To each their own I guess.
      • dgacmu 8mo ago
        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.
        • wtetzner 8mo ago
          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.
• akiselev 8mo ago
  > 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.
• bsenftner 8mo ago
  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.
• pkorzeniewski 8mo ago
  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?
  • srdjanr 8mo ago
    > 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
  • gtirloni 8mo ago
    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-it-wrong-to-implement-myself-a-known-published-widely-believed-to-be https://security.stackexchange.com/questions/209652/why-is-i...
• avidiax 8mo ago
  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.
  • FeteCommuniste 8mo ago
    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?
  • zelphirkalt 8mo ago
    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.
    • shimman 8mo ago
      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.
• Ronsenshi 8mo ago
  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.
• matheus-rr 8mo ago
  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.
  • milowata 8mo ago
    > 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.
    • esafak 8mo ago
      I'm confused too. When it breaks, you should have tests and a changelog handy. I solve these problems with agents routinely.
• pech0rin 8mo ago
  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.
• jazzyb 8mo ago
  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.
  • andai 8mo ago
    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.
  • woeirua 8mo ago
    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.
• jstummbillig 8mo ago
  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.
• pixelat3d 8mo ago
  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
  • gtirloni 8mo ago
    > 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.
  • Lalabadie 8mo ago
    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.
  • tempest_ 8mo ago
    > 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.
• peteforde 8mo ago
  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.
  • alexalx666 8mo ago
    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?
    • peteforde 8mo ago
      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.
• SCdF 8mo ago
  > 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.
• falloutx 8mo ago
  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.
• lowsong 8mo ago
  > 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.
  • alainrk 8mo ago
    If you have no idea on how to setup the pillars you're absolutely right, maybe you should try
• kundi 8mo ago
  Mindblowing observations.
• apapkka 8mo ago
  > 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.
• HarHarVeryFunny 8mo ago
  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.
  • toddmorey 8mo ago
    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”.
    • tsunagatta 8mo ago
      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
      • verdverm 8mo ago
        Conspiratorially, they trained it this way to increase token usage to pay their debts and investors
        • HarHarVeryFunny 8mo ago
• bvan 8mo ago
  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.
  • goosejuice 8mo ago
    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.
    • cruffle_duffle 8mo ago
      > 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.
• dathinab 8mo ago
  > 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".
• adamddev1 8mo ago
  > 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?"
• jmull 8mo ago
  > 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.
• ipsento606 8mo ago
  > 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.
  • feastingonslop 8mo ago
    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.
    • mnicky 8mo ago
      Critically, they will also enable faster future migration to a framework in case it proves useful.
    • trescenzi 8mo ago
      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.
    • plagiarist 8mo ago
      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.
• m0llusk 8mo ago
  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?
• lcnmrn 8mo ago
  Frameworks are stable by design, generated code isn't. Why people still had to learn math when calculator was invented?
• victorbjorklund 8mo ago
  I feel the opposite. Frameworks and standardization becomes even more important when using AI.
• thagra 8mo ago
  [flagged]
  • alainrk 8mo ago
    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
• rglover 8mo ago
  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").
  • nojito 8mo ago
    >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.
    • htuibxtuhidb 8mo ago
      [dead]
    • otabdeveloper4 8mo ago
      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.
      • verdverm 8mo ago
        You both are likely incorrect, the answer lies in the middle rather than the extremes
        • 8mo ago
• postepowanieadm 8mo ago
  Build libraries, not frameworks.
• wundersam 8mo ago
  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.
• wundersam 8mo ago
  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.
• pmontra 8mo ago
  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?
• baq 8mo ago
  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.
• nuancebydefault 8mo ago
  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.
• prophesi 8mo ago
  "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!
• sam0x17 8mo ago
  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.
• azibi 8mo ago
  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.
• bdcravens 8mo ago
  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.
• 3vidence 8mo ago
  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.
  • alainrk 8mo ago
    I suggest to read the full article :)
    • 3vidence 8mo ago
      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
      • alainrk 8mo ago
        Strawman argument. Standards and patterns matter, but discernment matters more. The issue isn't reusability itself, it's the cargo-cult adoption of frameworks that solve problems you don't have, when you don't have them. Your LLM agent works for undiscussed reasons because you made deliberate architectural choices for your specific context. That's engineering. Blindly importing a framework just because "everyone uses it" is the opposite. That's the point, nothing more nothing less.
• nickstaggs 8mo ago
  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?
• aggregator-ios 8mo ago
  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.
  • qweiopqweiop 8mo ago
    I was thinking the same. On mobile both frameworks and libraries make my life infinitely easier
• eqvinox 8mo ago
  > 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.
  • rogerthis 8mo ago
    Weird thing is that it can ease things like that too.
• pawelduda 8mo ago
  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
• woeirua 8mo ago
  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.
• tantalor 8mo ago
  > 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.
• notatoad 8mo ago
  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.
• tayo42 8mo ago
  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.
• skybrian 8mo ago
  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.
• nova22033 8mo ago
  > 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?
• deadbabe 8mo ago
  AI rolled cryptographic libraries now make it feasible to just roll your own crypto.
• aschla 8mo ago
  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.
• rsolva 8mo ago
  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 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 https://stopplidelsen.no (Norwegian)
• samiv 8mo ago
  Next up "coding agents replaced me"
• YarickR2 8mo ago
  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.
• harel 8mo ago
  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...
  • drbscl 8mo ago
    ...and importantly, neither does the LLM; frameworks are incredibly useful even if you are using generative AI.
• ewuhic 8mo ago
  ai slop shit
  • alainrk 8mo ago
    Interesting analysis
• physicsguy 8mo ago
  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.
• another_twist 8mo ago
  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.
• heliumtera 8mo ago
  LinkedIn article? What frameworks and what have you accomplished with it?
• capitanazo77 8mo ago
  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
• LordHumungous 8mo ago
  LLMs finally deliver on the crochety front end dev's dream of writing everything in vanilla JS. Hallelujah.
• athrowaway3z 8mo ago
  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.
• FpUser 8mo ago
  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.
• varjag 8mo ago
  I feel like commenting on the article without reading was really vindicated with the advent of AI slop.
• zeroq 8mo ago
  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.
• clarity_hacker 8mo ago
  [dead]
• mbgerring 8mo ago
  > 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.
• Centigonal 8mo ago
  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.
  • jedwards1211 8mo ago
    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.
  • kaydub 8mo ago
    Yeah, definitely a stupid take from OP. LLMs are very strong at using the frameworks, it makes it easier to hire people to work on your codebase, it makes it easier for future uses of LLMs since they'll have a lot of framework details in their training data, etc.
• mrinterweb 8mo ago
  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.
• oxag3n 8mo ago
  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?
• keeda 8mo ago
  I had called this a while back, since the reasoning is simple: frameworks primarily exist to minimize boilerplate, but AI is very good at boilerplate, so the value of frameworks is diminished. The larger underlying shift is that the economics of coding have been upended. Since its inception, our industry has been organized around one fundamental principle: code is expensive because coders are expensive. This created several complex dynamics, one which was frameworks -- which are massive, painful dependencies aimed at alleviating costs by reducing the repeated boilerplate written by expensive people. As TFA indicates, the costs of frameworks in terms of added complexity (e.g. abstractions from the dependency infecting the entire codebase) are significant compared to their benefits. But now that the cost of code ---> 0, the need for frameworks (and reusability overall) will likely also --> 0. I had predicted that this dynamic will play out widely and result in a lot more duplicative code overall, which is already being borne out by studies like https://www.gitclear.com/ai_assistant_code_quality_2025_research https://www.gitclear.com/ai_assistant_code_quality_2025_rese... Our first instinct is to recoil and view this as a bad thing, because it is considered "Tech Debt." But as the word "debt" indicates, Tech Debt is yet another economic concept and is also being redefined by these new economics! For instance, all this duplicate code would have been terrible if only humans had to maintain it. But for LLMs, it is probably better because all the relevant logic is RIGHT THERE in the code, conveniently colocated with the rest of the functionality where it is used, and not obfuscated behind a dozen layers of abstraction whose (intended) functionality is described in natural language scattered across a dozen different pieces of documentation, each with varying amounts of sufficiency, fidelity and updated-ness. This keeps the context very focused on the relevant bits, which along with extensive testing (again, because code is cheap!) that enables instant self-checking, greatly amplifies the accuracy of the LLMs. Now, I'm not claiming to say this will work out well long term -- it's too early to tell -- but it is a logical outcome of the shifting economics of code. I always say with AI, the future of coding will look very weird to us; this is another example of it.
• cess11 8mo ago
  "Why do you ever need, for most of the use cases you can think of, a useless, expensive, flawed, often vulnerable framework, and the parade of libraries that comes with it, that you probably use for only 10% of its capabilities?" Who outside of 'frontend web developers' actually do this? I don't think this is a good description of, say, Apache Tika or Alembic's Ash.
• theonething 8mo ago
  A huge advantage of frameworks to me is to give new comers to the code a unified frame of reference. A Rails developer (or even a non-Rails guys who understands MVC) can jump into a Rails based codebase he is not familiar with a lot easier than the custom "from the ground up" thing the author espouses. It's puzzling to me that the author doesn't even mention this huge and obvious benefit of frameworks.
• nubg 8mo ago
  To the people who are against AI programming, honest question: why do you not program in assembly? Can you really say "you" "programmed" anything at all if a compiler wrote your binaries? This is a 100% honest question. Because whatever your justification to this is, it can probably be used for AI programmers using temperature 0.0 as well, just one abstraction level higher. I'm 100% honestly looking forward to finding a single justification that would not fit both scenarios.
  • J_Shelby_J 8mo ago
    Compiling the symbols into a binary is not the bottleneck. Formalizing the contract for interacting with the real world is and always has been the bottleneck.
    • H8crilA 8mo ago
      Nah, it's the 50 tabs in my browser that I no longer have to open before I know the correct incantation to type. I bet someone knows how many tabs an average deveoper is keeping opened when working (like Google or someone with a nasty spying browser extension) - would be cool to see that plotted against the fraction of Github commits that are co-authored by Claude. I predict a fairly tight negative correlation.
  • joe_the_user 8mo ago
    I dislike it when rhetorical flourishes start with "honest question...". Maybe using AI assistant instead of directly writing code is equivalent to using a high level language instead of assembly and maybe it isn't. So at least begin your discussion as "I think programmers who don't use AI are like programmers who insist on assembly rather than a high level language" (and they existed back in the day). I mean, an "honest question" is one where you are honestly unsure whether you will get an answer or what the answer will be. That's completely different from honestly feeling your opponents have no good arguments. Just about the opposite, really. By the way, the reason I view AI assistants and high level language compilers as fundamentally different is that high level languages compilers are mostly deterministic, mostly you can determine both the code generated and the behavior of code in terms of the high level language. AI created/assisted code is fundamentally undermined relative to the source (a prompt) on a much wider basis than the assembly created by a high level language compiler (whose source is source code). Edit: formatting
• carlcarrie 8mo ago
  Good article: Software Engineering is finally being liberated from the "Middle Work" of the last decade. The AI tsunami isn't just about coding faster—it’s about reclaiming architectural sovereignty from hyperscaler blueprints. The future is Just-in-Time and Highly Customized. My full thoughts here: https://www.linkedin.com/posts/carlcarrie_software-engineering-is-back-activity-7425998281358417921-NroB?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAFhwLIBV2C-gSAGPc9b6jOkykpmGaIobvI https://www.linkedin.com/posts/carlcarrie_software-engineeri...
• soueuls 8mo ago
  I found the article interesting yet my thinking is at the opposite spectrum. I also spent a lot of time using LLM, and I am moving away from "no framework" or "library pretending to be a framework". Not that I was a fan of it, but for work purpose I was using React / Next.js etc. Now, I am using Laravel. lots of magic, pretty much always one recommended way to do things, excellent code generation using CLI. When you combine it with AI it's following the framework's guideline. The AI does not have to think about whether it should locate business logic with UI, use a hook or not, extract a helper, etc. It knows how to create route, controller, validator, view, model, migration, whatever.
• pengaru 8mo ago
  now we get to watch an entire generation of clowns who struggled to create anything at all learn the need for self-discipline in the face of newly accessible NIH traps
• owenversteeg 8mo ago
  There are a few interesting points in the comments here. The pro case for getting rid of frameworks: they're bulky, complex, there are security holes, updates to keep up with, things keep changing. LLMs can write you something perfectly customized to what you're doing. You get some free security by obscurity. The con case: LLMs are excellent at getting you up to speed with a framework and understanding issues. As avidiax says in this thread, "The author seems to mistake having to update Node.js for a security patch to be a curse rather than a blessing. You get the privilege of patching Node.js." Security by obscurity is generally a bad design. To me, the general architecture and maintainability is a huge issue when you have LLMs write everything from scratch. Not that a Node or React app is a paragon of maintainability or architecture, but it's certainly better than something made from scratch by an LLM. The code quality of a framework is also far higher. I personally feel like the best path today is to use something lightweight, like Svelte. You get the best of both worlds. Light structure but nothing overbearing.
• rirze 8mo ago
  You can never have a good substitute for a good framework. A good framework would let you skip over boilerplate code, abstract at a higher level, and be dependable. Context matters most here-- does a solid framework exist for the work you're trying to do? Then use it, otherwise write what you need and understand the risks that come with freshly written code.
• straightbuggin 8mo ago
  I am a non coder. For many years I went through many various coding tutorials, but never had been able to fully build anything other than basic websites. Now with AI I have been able to build useful CLI tools. Instead of using a static website generator such as Hugo, I can now quick build a website of what I am looking for. Heck, I just had it build me a website as a presentation instead of doing a slide show. I came up with an outline + my notes and information then had it build out the site based on that information. I was able to have it create some really cool animations to help explain my ideas.
• Culonavirus 8mo ago
  Dumbest take I've seen in a while. Really. If anything, AI working with frameworks is making them more effective. Frameworks, by definition, produce more structure, than just the language + libs do, and their entire practical utility is to abstract away complexity and lower the amount of footguns. The ultimate form of abstracting away complexity is an AI agent/coder writing the code for you. But there are gazillions of solutions (and opinionated ones) out there, for gazillions of all kinds of problems... having an AI agent work within the constraints of a framework is going to be a good thing in almost all cases as it will be more focused on your problem space rather than figuring out how to send freaking bits between computers. How do people not understand that even if AI is writing all your code you still want to have as little code as possible for a given problem solution that you have to manage yourself? Frameworks help with that.
• pickleRick243 8mo ago
  I'm surprised I don't see many (or any) comments mentioning this: this blog post was clearly written with heavy LLM assistance.
• nprateem 8mo ago
  Latest opus and antigravity. Did an insane amount of complex refactoring on a 500k ish line codebase. I saw programming die today. I will never significantly code by hand again and probably won't be hired in 5 years.
• cadamsdotcom 8mo ago
  This is an interesting idea but the problem is where to stop as you travel down through layers of frameworks? Say we take it to an absurd extreme: You probably won’t have your agent code up Verilog and run your website on an ASIC.. and you aren’t going to write an assembler to code up your OS and kernel and all the associated hardware support, so you probably want a server and an OS to run your code and maybe some containers or a process model.. so the agentic reinvention has to stop somewhere. One helpful mindset is to choose frameworks and components that avoid rediscovery. Tailwind for example contains some very well thought out responsive breakpoints that a ton of thought went into designing. With `:md` which is only a couple of tokens, your agent can make use of all that knowledge without having to reinvent everything that went into those decisions.
• luckydata 8mo ago
  honestly this blog post was pretty off base. Current AIs have a limited ability to keep up with complexity and using known frameworks helps with managing that complexity. If you need to write everything from scratch every time you have to go through the process of scaffolding and harnessing the whole system from scratch. I don't think it's worth rewriting react from scratch every time you make a browser application, even in the best case it's just a huge waste of tokens.
• kristopolous 8mo ago
  They're addressing the same need and yield the same behavior patterns and thus will have the same organizational outcomes I talked about it in a currently unfinished blog post, here's the section "In the 2000s and 2010s, this was the core conflict of frameworks. Does the framework have enough alignment with the task that it would cumulatively simplify things. However, this is not how we behave. Instead habituation promotes einstellung where we end up relying on the tool of the AI to do the trivial. This is closely related to Automation bias and OOTL." It's not complete but here it is anyways https://blog.day50.dev/intro/vibedrift/ https://blog.day50.dev/intro/vibedrift/ Things like the einstellung effect are important in vibe coding, software design and framework use. It's a truism about meta tool use and the relationships and behavior systems that accompany them along with the epistemological edifices they prop up. Quoting Wikipedia: "After solving many problems which had the same solution, subjects applied the same solution to later problems even though a simpler solution existed" I should get back and finish it probably by this week.
• onionopionion 8mo ago
  I use claude for everything nowadays tbh - nothing else anymore
• phendrenad2 8mo ago
  This is interesting, because I've been going the other way: Using coding agents to write MORE abstraction layers. This is because I realized that, just like humans, in fact even more so, language models struggle to keep the whole stack in mind at once. See for yourself: Try having your agent write a CRUD app in Ruby or Python (no Rails, no Django), and then try it again with Rails or Django. It'll be a lot more productive and error-free the second time. However, I think I understand where the author's coming from based on this line: > I’ve been building a product from the ground up. Not the “I spun up a Next.js template” kind of ground up Next.JS is the pinnacle of JavaScript-on-the-backend frameworks, and it's kind of pathetic compared to what Rails or Django give you. You still have a lot of thinking to do, so I posit (as I have for some time) that using Next.JS vs using NodeJS directly gives humans very little productivity boost. I think people just know that frameworks are a good thing in general, and never realized that the JavaScript offerings weren't that powerful.
• karma_daemon 8mo ago
  A glorious new era of bespoke industrial code
• steve_adams_86 8mo ago
  This gives me "anyone can run their online presence with WordPress" vibes, back at the beginning of my career when I spent a lot of time repairing people's broken, exploited, corrupted websites. We saw an explosion of people creating websites, but even with the guard rails of a framework like WordPress it turned into a total mess. Now we've thrown out the guard rails.
• ericyd 8mo ago
  What a tired headline, what a tired topic. Can't believe how much joy has been sapped from my life reading about AI
• dsiegel2275 8mo ago
  This is a strange take. So just because we now have "automated programming" agents, every project should eschew the use of a known, tested set of libraries or an entire framework and instead build everything from the ground up? That is insane.
• zachYCB 8mo ago
  The discussion around any AI topic trends towards these low-quality hype train type discussions. It’s like I live in a separate world than these people. AI is useful but it is so extremely limited and error-prone. It makes me question the skill of the people writing articles like this.
• clawaimarket 8mo ago
  There's a middle ground here that doesn't get discussed enough. Coding agents haven't replaced frameworks for me — they've changed how I interact with them. I still use the same tools, but now the agent handles the boilerplate and repetitive parts while I focus on architecture decisions and edge cases. The "vibe code only" crowd will hit a wall eventually, but dismissing agents entirely because some people misuse them is throwing the baby out with the bathwater. The real skill is knowing when to let the agent drive vs when to take the wheel.
• KronisLV 8mo ago
  I kinda like the idea, decreasing the friction of doing things yourself to near 0. I recently migrated from my YOURLS install to just having an Apache2 config with some scripts to append to it: https://blog.kronis.dev/blog/sometimes-dropbox-is-just-ftp-building-a-link-shortener https://blog.kronis.dev/blog/sometimes-dropbox-is-just-ftp-b... Sometimes you don't need "serious" bullshit like Spring Boot either but something more minimalist is more than enough. Though I think it can only work well when you have enough usable primitives, e.g. I've written software in Go that has minimal dependencies and it only worked so well thanks to both the language being relatively simple AND also having a really strong standard library. The moment when someone tries to write a web server from scratch in a collaborative environment (e.g. project at work with deadlines), I'm peacing the fuck out of there. And in my experience, trying to make design systems or frameworks from scratch leads to a pretty bad mess, because people miss all sorts of inherent complexity until it comes around to bite them later. I guess what I'm saying is that there's quite the difference between what you do for your own projects, vs what is most likely to lead to long term success in a group setting, especially in 1-2 pizza teams - evaluate the benefits vs risks when considering using vs building. I'm also a bit blind to this when it comes to certain things, look at this funny video: https://www.youtube.com/watch?v=40SnEd1RWUU https://www.youtube.com/watch?v=40SnEd1RWUU I would still prefer to use self-hostable software so I know more of the stack and have control and possibly some cost savings vs someone who'd just fork over a bunch of cash to a SaaS / PaaS vendor.
• deafpolygon 8mo ago
  Wait until we get optimisation developers to cut the cruft out of LLM generated code!
• pipejosh 8mo ago
  Everyone's talking about how productive agents are but nobody's talking about what happens when one gets prompt injected. Your agent has shell access, your API keys in env vars, and unrestricted internet. That's one bad dependency readme away from leaking everything. The productivity gains are real but so is the attack surface.
• thecoderpanda 8mo ago
  simonw nailed it. The pain was never "writing code." It was the random hour lost debugging why CI broke overnight because some dependency shipped a breaking change. I run a dev community of ~1500 devs. The ones getting the most out of agents aren't throwing away frameworks. They're offloading the stuff nobody enjoys. OAuth scope spelunking, boilerplate migrations, flaky test debugging. That's where agents shine. The actual risk nobody talks about: if you've never manually debugged a race condition, you won't catch it when the agent introduces one. Agents amplify what you already know. They don't replace knowing things.
• rldjbpin 8mo ago
  so many parties peddling AI related services should also agree with the sentiment (so do i). a lot of people in the stack are acting as wrappers. most of their tools are always changing (e.g. see the commit counts in openclaw project), often full of breaking changes and while forcing to migrate to newer version regularly. if you want something specific without ever-changing needs, it makes sense to do it with fewer dependencies as possible. this should be even more ideal if you believe the code made is of high quality, as it reduces the pain of updating the project for non-functional reasons. this sentiment ironically goes against the existence of these services, as they themselves are always working on matching the ever-changing dependencies to give the impression of a stable platform. only if it was possible to have the cake and eat it too