[HN Gopher] Coding agents have replaced every framework I used
___________________________________________________________________
Coding agents have replaced every framework I used
Author : alainrk
Score : 267 points
Date : 2026-02-07 13:07 UTC (9 hours ago)
(HTM) web link (blog.alaindichiappari.dev)
(TXT) w3m dump (blog.alaindichiappari.dev)
| darvid wrote:
| "Software engineers are scared of designing things themselves."
|
| what?
| booleandilemma wrote:
| With a line like that I wouldn't trust anything this guy has to
| say.
| alainrk wrote:
| Thank you for the constructive feedback :)
| direwolf20 wrote:
| Read the following paragraph. The author isn't wrong.
| ramon156 wrote:
| > I want to build X > "Hey claude, how would you make X" >
| Here's how I'd build X... [Plan mode on]
| varispeed wrote:
| 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 wrote:
| It never left, welcome back to software engineering though!
| alainrk wrote:
| Thank you, I'm glad to be back!
| sixQuarks wrote:
| 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 wrote:
| I have to tell claude specifically to use plain html css js, else
| it goes on building react
| alainrk wrote:
| Indeed, this has been one of the first things I've noticed
| paxys wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| quaintdev wrote:
| 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.
| rsolva wrote:
| 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.
| mentalgear wrote:
| If a framework, best a minimal one using web standards E.g.
| svelte or https://nuejs.org/.
| alainrk wrote:
| 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 wrote:
| It's actually so over
| voidhorse wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jayd16 wrote:
| 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 wrote:
| 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 wrote:
| Pain can mean tedium rather than intellectual challenge.
| wtetzner wrote:
| I really struggle to understand how people can find coding
| more tedious than prompting. To each their own I guess.
| dgacmu wrote:
| 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 wrote:
| 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.
| dgacmu wrote:
| 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. :)
| TuringTest wrote:
| 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.
| gertlex wrote:
| 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".
| kaydub wrote:
| How long have you been coding? How many languages and
| frameworks have you worked with? Where has your
| professional focus been?
|
| I've written professional code in production for the past
| 15+ years in VB, C# (MVC2/MVC3 + Razor), Php(Yii, Yii2,
| Symfony), Perl, Python(Flask, Cherrpy), Java(Spring MVC,
| Spring boot, JSF, J2EE), Golang, Rust, Ruby. I've worked on
| build/ci pipelines from Jenkins, CircleCI, Github, Gitlab,
| Teamcity, etc. I've had to deploy/manage infrastructure
| from bare metal to the cloud with Ansible, Puppet,
| Saltstack, Terraform, Cloudformation. I've had to run on
| MySQL, Postgres, Mariadb, SQL Server and use ActiveMQ,
| RabbitMQ, Kafka, SQS, SNS, MSK, Kinesis (of all flavors). I
| could literally keep going and going and going.
|
| I'm tired. It's way easier to prompt than keep track of all
| this shit at this point. I don't need to know how to
| implement $feature or $tool in each and every framework,
| I'll let the machines worry about that.
| wtetzner wrote:
| I've been writing professional code for 20 years at this
| point, using many languages, libraries, frameworks, etc.
| But I certainly don't use them all at the same time.
|
| This also just feels like we're solving the wrong
| problem. Using AI doesn't fix any of it, it just makes it
| easier to make the problem worse faster.
| kaydub wrote:
| You haven't worked somewhere where you're working on
| multiple different microservices each written by
| different teams in different languages?
| capyba wrote:
| 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!
| wtetzner wrote:
| > I would have finished the project in the same amount of
| time
|
| Probably less time, _because_ you understood the details
| better.
| dvfjsdhgfv wrote:
| > 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.
| testuser312 wrote:
| 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.
| jbloggs777 wrote:
| 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.
| hakunin wrote:
| 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.
| ctoth wrote:
| > 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!
| hakunin wrote:
| 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.
| danny_codes wrote:
| GCC is, I imagine, several orders of magnitude mor
| deterministic than an LLM.
| hakunin wrote:
| It's not _more_ deterministic. It's deterministic,
| period. The LLMs we use today are simply not.
| philipswood wrote:
| 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
| hakunin wrote:
| 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.
| We're yet to see if we're heading for net gain or net
| loss.
| dvfjsdhgfv wrote:
| If we want to get really narrow I'd say real determinism
| is possible only in abstract systems, to which you'd
| reply it's just my ignorance of all possible factors
| involved and hence the incompleteness of the model. To
| which I'd point of practical limitations involved with
| that. And that reason, even though it is incorrect and I
| don't use it in this way, I understand why some people
| are using the quantifiers more/less with the term
| "deterministic", probably for the lack of a better
| construct.
| hakunin wrote:
| I don't think I'm being pedantic or narrow. Cosmic rays,
| power spikes, and falling cows can change the course of
| deterministic software. I'm saying that your "compiler"
| either has intentionally designed randomness (or
| "creativity") in it, or it doesn't. Not sure why we're
| acting like these are more or less deterministic. They
| are either deterministic or not inside normal operation
| of a computer.
| cheema33 wrote:
| "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.
| otabdeveloper4 wrote:
| > just add more magic turtles to the stack, bro
|
| You're just amplifying hallucination and bias.
| hakunin wrote:
| 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.
| verdverm wrote:
| I've been wondering if there are better random seeds,
| like how there are people who hunt for good seeds in
| Minecraft
| exe34 wrote:
| it's literally just setting T=0. except they are not as
| creative then. they don't explore alternative ideas from
| the mean.
| hakunin wrote:
| 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).
| dkersten wrote:
| 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.
| scrame wrote:
| quite a bit of software you would need to understand the
| assembly. not everything is web-services.
| manofmanysmiles wrote:
| 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!
| HarHarVeryFunny wrote:
| Do you mean gdb batch mode (which I've heard of others
| using with LLMs), or the LLM using gdb interactively ?
| verdverm wrote:
| 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
| Thanemate wrote:
| >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.
| AstroBen wrote:
| 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
| exe34 wrote:
| 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.
| jatora wrote:
| 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
| Ocha wrote:
| So you skipped the code review and just checked that it
| does what you needed it to do?
| enraged_camel wrote:
| I don't know how anyone can make this assumption in good
| faith. The poster did not imply anything along those
| lines.
| joshuahaglund wrote:
| That looked like a leading question to me, asking for
| confirmation but not an outright assumption. Seems like a
| fair question
| TideAd wrote:
| GPT-5 codex variants with xhigh reasoning make great code
| reviewers.
| SamPatt wrote:
| 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.
| throwaw12 wrote:
| 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.
| sowbug wrote:
| 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.
| goobert wrote:
| 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.
| SamPatt wrote:
| I found coordinating skill usage across worktrees quite
| annoying, how are you managing this?
| verdverm wrote:
| Have you added agents.md files?
|
| You have to do more than prompts to get the more impressive
| results
| andoando wrote:
| 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
| karmasimida wrote:
| Then you are using it the wrong way
|
| Driving is a skill that needs to be learnt, same with working
| with agents.
| echelon wrote:
| 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.
| estimator7292 wrote:
| Burn the planet to the ground because your life is boring.
| Extremely mature stance you've got there
| echelon wrote:
| This is 1960's era anti-nuclear all over again.
|
| People on Reddit posting AI art are getting death threats.
| It's absurd.
| objclxt wrote:
| > 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.
| wtetzner wrote:
| > 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.
| kaydub wrote:
| What hard problems are you working on?
| creata wrote:
| > I want to be able to make art and music and movies and
| games.
|
| Then make them. What's stopping you?
| echelon wrote:
| 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.
| nradov wrote:
| 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.
| abcde666777 wrote:
| 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.
| kaydub wrote:
| I knew nothing about game development a few months ago. Now
| I've built a simple godot game. I'm sure the game is all
| pretty common (simple 2d naval combat game) but it's still
| impressive that a couple claude/gemini/codex cli sessions
| spit out a working game (admittedly, I'm not a professional
| artist, so THAT part of it has been painful since I can't
| rely on generative AI to do that, I have to do it myself
| with aesprite. But maybe a professional artist would know
| HOW to prompt for the artwork)
|
| Agentic programming still needs devs/engineers. It's only
| going to take your lunch if you let it. And by that, I mean
| the FUD and complete refusal to give good faith attempts to
| use the ai/llm tools.
| cruffle_duffle wrote:
| > 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
| plagiarist wrote:
| Oh, no, you're imagining the wrong subgenre of sci-fi. These
| robots are actually owned and operated by billionaires.
| alainrk wrote:
| 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?
| estimator7292 wrote:
| 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.
| wtetzner wrote:
| I think it's still an open question if it's actually a net
| savings of time.
| chasd00 wrote:
| 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.
| FeteCommuniste wrote:
| 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.
| kaydub wrote:
| Always have another agent around that is just reviewing
| code. "Look for duplicate code, code smells, bad
| architecture, future scalability problems..."
|
| I usually keep one agent/prompt/context ripping through
| new features and another 1-3 agents/prompts/contexts
| reviewing, testing, planning.
| strange_quark wrote:
| 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.
| milowata wrote:
| 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.
| normie3000 wrote:
| Integrating auth code is probably a good example of code
| you want to understand, rather than just seeing that it
| appears to work.
| marginalia_nu wrote:
| 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.
| normie3000 wrote:
| I'm glad to hear the gradle experience hasn't changed in
| the decade since I started avoiding it.
| wtetzner wrote:
| > 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.
| falkensmaize wrote:
| 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.
| geetee wrote:
| 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.
| thwarted wrote:
| 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.
| notpachet wrote:
| I wonder how many vibecoding/automatic programming zealots
| are fluent in a multimodal editor.
| mycall wrote:
| 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.
| irishcoffee wrote:
| 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!"
| franze wrote:
| 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. Smeagol 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.
| Calavar wrote:
| 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.
| dmbche wrote:
| Do you find this interesting to make and read?
| franze wrote:
| 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.
| jesse_dot_id wrote:
| 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.
| thwarted wrote:
| _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_.
| jack_pp wrote:
| 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.
| thwarted wrote:
| 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".
| everforward wrote:
| 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".
| Aperocky wrote:
| 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.
| dkersten wrote:
| " What's gone is the tearing, exhausting manual labour of
| typing every single line of code."
|
| Yeah, this was always the easy part.
| kmac_ wrote:
| 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.
| throwaw12 wrote:
| 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
| kmac_ wrote:
| That's why they bring a lot of value. Plus, new models and
| methods enable solutions that weren't available a decade
| ago.
| bilbo0s wrote:
| 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.
| GeoAtreides wrote:
| 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?
| simonw wrote:
| 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.
| throwaw12 wrote:
| > 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"
| enraged_camel wrote:
| 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.
| simonw wrote:
| 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.
| sevensor wrote:
| 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.
| verdverm wrote:
| 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
| bdcravens wrote:
| 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.
| bilekas wrote:
| 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.
| kaydub wrote:
| So waterfall sdlc...
| bilekas wrote:
| If the shoe fits your work flow, call it what you want.
| Change it how you like for all I care. But coding shouldn't
| be the majority of your time.
| bufordtwain wrote:
| 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.
| karel-3d wrote:
| 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.
| jarjoura wrote:
| Your comment is spot on, but the nuance people who are still
| new to these LLMs don't yet see is the real reason "he'd be
| better off just writing the damned book instead."
|
| 1. That prompt is always a slot machine. It's never 100%
| deterministic and that's why we haven't seen an explosion of
| claude skills. When it works for you, and it's magical,
| everyone is wowed. However, there is a set of users who then
| bang their head, wondering why their identical attempt is
| garbage compared to their coworker. "It must be a skills
| issue." No, it's just the LLM being an LLM.
|
| 2. Coding agents are hyper localized and refuse to consider the
| larger project when it solves something. So you end up with
| these "paper cuts" of duplicated functions or classes that do
| one thing different. Now the LLM in future runs has to decide
| which of these classes or functions to use and you end up with
| two competing implementations. Future you will bang your head
| trying to figure out how to combine them.
|
| 3. The "voice" of the code it outputs is trained on public
| repositories so if your internal codebase is doing something
| unique, the LLM will consistently pick the voice it's trained
| on, forcing you to rewrite behind it to match your internal
| code.
|
| 4. It has no chill. If I set any "important" rules in the
| prompt then it sometimes adheres to it at the expense of doing
| the "right" thing in its changes. Or it completely ignores it
| and does its own thing, when it would have been the perfect
| time to follow the rule. This is to your point that, if I had
| just written the code myself, it would have been less words
| than any "perfect" prompt it would have taken to get the same
| code change.
| akiselev wrote:
| _> 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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...
| avidiax wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| I'm confused too. When it breaks, you should have tests and a
| changelog handy. I solve these problems with agents
| routinely.
| pech0rin wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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(tm) 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_ wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sanex wrote:
| 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.
| wrs wrote:
| 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.
| SCdF wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| If you have no idea on how to setup the pillars you're
| absolutely right, maybe you should try
| kundi wrote:
| Mindblowing observations.
| apapkka wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Conspiratorially, they trained it this way to increase
| token usage to pay their debts and investors
| HarHarVeryFunny wrote:
| 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".
| HarHarVeryFunny wrote:
| 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.
| dathinab wrote:
| > 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 wrote:
| > 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?"
| bvan wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| jmull wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| Critically, they will also enable faster future migration to
| a framework in case it proves useful.
| trescenzi wrote:
| 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 wrote:
| 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.
| koverstreet wrote:
| 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.
| leecommamichael wrote:
| > 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.
| bdangubic wrote:
| 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.
| GoatInGrey wrote:
| 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.
| Dfiesl wrote:
| 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.
| GeoAtreides wrote:
| > 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
| potsandpans wrote:
| > 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!"
| cortesoft wrote:
| It's the 'woke' of the computer world.
| exe34 wrote:
| 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.
| SoftTalker wrote:
| 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.
| exe34 wrote:
| 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".
| andoando wrote:
| Software companies all understand that so its not really
| a problem. Maybe in companies where the software isn't
| the main product
| devin wrote:
| In Clojure land, the mantra has long been "libraries over
| frameworks" for this reason.
| fourside wrote:
| 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.
| solidasparagus wrote:
| I'm not sure.
|
| The cost of replacement-level software drops a lot with
| agentic coding. And maintenance tasks are similarly much
| smaller time syncs. When you combine that with the long-
| standing benefits of inhouse software (customizable to your
| exact problem, tweakable, often cleaner code because the
| feature-set can be a lot smaller), I think a lot of
| previously obvious dependencies become viable to write in
| house.
|
| It's going to vary a lot by the dependency and scope -
| obvious owning your own react is a lot different than owning
| your own leftpad, but to me it feels like there's no way that
| agentic coding doesn't shift the calculus somewhat.
| Particularly when agentic coding make a lot of nice-to-have
| mini-features trivial to add so the developer experience gap
| between a maintained library and a homegrown solution is
| smaller than it used to be.
| marcosdumay wrote:
| > 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.
| kaydub wrote:
| Yeah, I'm huge on using LLMs for coding, but one of the biggest
| wins for me is that the LLM already knows the frameworks. I no
| longer need to learn whatever newest framework there is. I'll
| stick to my frameworks, especially when using an LLM to code.
| m0llusk wrote:
| 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 wrote:
| Frameworks are stable by design, generated code isn't. Why people
| still had to learn math when calculator was invented?
| victorbjorklund wrote:
| I feel the opposite. Frameworks and standardization becomes even
| more important when using AI.
| thagra wrote:
| 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.
| alainrk wrote:
| 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 wrote:
| 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 wrote:
| >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.
| otabdeveloper4 wrote:
| 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 wrote:
| You both are likely incorrect, the answer lies in the
| middle rather than the extremes
| redleggedfrog wrote:
| This is not just software development wisdom, it's _life_
| wisdom.
| kaydub wrote:
| I think a lot of the people pro-llm are already in the
| middle. It's the naysays that are sticking to a strict
| definition of "vibe coding" as if it's random people
| typing in "make me $app but make no bugs" and getting a
| 100% working $app with no bugs. You have the gastown
| folks trying to do that, but nobody serious putting in
| good work with llm agents is "vibe coding" in that way.
| HighGoldstein wrote:
| > 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?
| pawelduda wrote:
| 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
| LunaSea wrote:
| Like being ratioed with a 50% price crash?
| literalAardvark wrote:
| You mean just like META, NFLX, AMZN, TSLA, NVDA, CSCO,
| MSFT, GE, BAC ?
| pawelduda wrote:
| I can tell you what a decade is but I'll have to leave
| the reading comprehension to you
| superze wrote:
| You forgot NFTs
| FeteCommuniste wrote:
| Remember when the geniuses at Andreessen Horowitz were
| dumping hundreds of millions into the "metaverse?"
| literalAardvark wrote:
| Might not be the best counter example since everyone who
| has bought BTC before Jan 2024 is now in massive profit.
| bdcravens wrote:
| 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.
| FeteCommuniste wrote:
| 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.
| HighGoldstein wrote:
| > Who knows, maybe soon enough we'll have specially trained
| de-slopper bots, too.
|
| Fire, meet oil.
| woeirua wrote:
| 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.
| omnicognate wrote:
| 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.
| pengaru wrote:
| 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.
| kuboble wrote:
| 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.
| kaydub wrote:
| 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.
| sph wrote:
| > 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.
| pixelmelt wrote:
| 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.
| leptons wrote:
| Same as it was for "blockchain" and NFTs. Tech
| "enthusiasts" can be quite annoying, until whatever they
| hype is yesterday's fad. Then they jump on the next big
| thing. Rinse, repeat.
| beoberha wrote:
| > 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.
| kaydub wrote:
| 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.
| AndrewKemendo wrote:
| 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
| ektjah wrote:
| CTO at Gambit AI? How generous of you to talk your book
| while insulting us. At least we know what to avoid.
| the__alchemist wrote:
| My guess: Their UASs run modified PX4 firmware.
| AndrewKemendo wrote:
| Do we make UAS'?
|
| Please tell me more
| the__alchemist wrote:
| Yikes.
| woeirua wrote:
| You have your head in the sand. Anyone making this claim
| in 2026 hasn't legitimately tried these tools.
| majormajor wrote:
| > 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."
| kaydub wrote:
| 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.
| kaydub wrote:
| We already do. It's the same tool.
| giancarlostoro wrote:
| 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.
| kenjackson wrote:
| 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.
| eqvinox wrote:
| > 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?
| lenkite wrote:
| 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 ?
| nottorp wrote:
| > 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.
| giancarlostoro wrote:
| 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.
| fauigerzigerk wrote:
| 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?
| giancarlostoro wrote:
| There's tooling out there 100% vibe coded, that is used
| by tens of thousands of devs daily, if that codebase
| found its way to training data, would it somehow ruin
| everything? I don't think this is really a problem, the
| problem will become people will need to identify good
| codebases from bad ones, if you point out which codes bad
| during training it makes a difference. There's a LOT of
| writings about how to write better code out there that
| I'm sure are already part of the training data.
| nottorp wrote:
| How much proprietary business logic is on public github
| repos?
|
| I'm not talking about "do me this solo founder saas
| little thing". I'm talking about working on existing
| codebases running specialized stuff for a functional
| company or companies.
| catlifeonmars wrote:
| 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.
| tappio wrote:
| 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...)
| catlifeonmars wrote:
| Or you could use an off the shelf popular framework in
| Python and save yourself some time curating the context.
| giancarlostoro wrote:
| I asked Claude to use some Dlang libraries even I had not
| heard of and it built a full blown proof of concept
| project for me, using obscure libraries nobody really
| knows. It just looked through docs and source code. Maybe
| back 3 years ago this would have been the case.
| kaydub wrote:
| 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.
| geophile wrote:
| 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.
| SoftTalker wrote:
| > 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.
| tsycho wrote:
| But setups get equally complicated, even with human
| software engineers. The approach that the OP is talking
| about applies only to experienced, good architect-level
| SWEs, and I suspect that the code quality and its problems
| are going to be the same whether they are directing LLMs vs
| a set of junior SWEs to write the code.
|
| There is an inherent level of complexity in projects that
| solve some real world problem, due to all the code handling
| edge cases that were added incrementally over time.
| eqvinox wrote:
| > 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.)
| zmmmmm wrote:
| It does beg, the question , whether any of this applies to
| less experienced people. I have a hunch that the open-ended
| nature of what can be achieved with AI will actually lead
| right back to needing frameworks, just as much as we do now,
| if not more, when it comes to less experienced people.
| bodge5000 wrote:
| On the face of it, this or at least acting as a code reviewer
| from an experienced point of view seems like the solution,
| the problem is that we all naturally get lazy and complacent.
| I actually think AI was at its best for coding a year or so
| ago, when it could kind of do part of the work but theres no
| way you could ever ship it. Code that works today but breaks
| in 6 months is far more insidious.
| MrDarcy wrote:
| 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.
| goostavos wrote:
| >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.
| MrDarcy wrote:
| 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.
| vips7L wrote:
| No they're not.
| devsda wrote:
| 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".
| seabrookmx wrote:
| 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.
| drcode wrote:
| 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
| pragmatic wrote:
| How would it improve skills?
|
| Does driving a car improve your running speed?
| FeteCommuniste wrote:
| 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.
| drcode wrote:
| 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.
| leptons wrote:
| You made the analogy worse. It's nonsense. The original
| analogy is far better.
| literalAardvark wrote:
| No, but it does improve your ability to get to classes
| after work
| kgeist wrote:
| >is going to improve the human programming skills worldwide
| to levels never before imaginable
|
| "We found that using AI assistance led to a statistically
| significant decrease in mastery. On a quiz that covered
| concepts they'd used just a few minutes before, participants
| in the AI group scored 17% lower than those who coded by
| hand"
|
| https://www.anthropic.com/research/AI-assistance-coding-
| skil...
| redleggedfrog wrote:
| 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?
| sonofhans wrote:
| In a veritable ocean of opinions it is excellent to see a
| detailed, first-hand report. Many thanks!
| nottorp wrote:
| 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.
| pragmatic wrote:
| 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"
| J_Shelby_J wrote:
| For complex code bases generated by AI the last 10% takes
| 190% of the effort because you end up tearing it all apart
| to rebuild it right.
| kaydub wrote:
| > I wonder if the LLMs "converge" on a particular UI if not
| given specific instructions?
|
| Purple. They really fucking like this purple gradient
| background for some reason lol.
| mark242 wrote:
| 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.
| pphysch wrote:
| 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.
| pragmatic wrote:
| 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.
| finebalance wrote:
| "evolution (fit to environment) than engineering (fit to
| purpose)."
|
| Oh, I absolutely love this lens.
| skybrian wrote:
| 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.
| smashed wrote:
| 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.
| skybrian wrote:
| "What can we do to reduce the size of the codebase" seems
| like an interesting prompt to try.
| NitpickLawyer wrote:
| There's an interesting phenomenon I noticed with the
| "skeptics". They're constantly using what-ifs (aka
| goalpost moving), but the interesting thing is that those
| exact same what-ifs were "solved" earlier, but dismissed
| as "not good enough".
|
| This exact thing about optimisation has been shown years
| ago. "Here's a function, make it faster". With "glue" to
| test the function, and it kinda worked even with GPT4 era
| models. Then came alphaevolve where google found
| improvements in real algorithms (both theoretical i.e.
| packing squares and practical i.e. ML kernels). And yet
| these were dismissed as "yeah, but that's just
| optimisation, that's easyyyy. Wake me up when they write
| software from 0 to 1 and it works".
|
| Well, here we are. We now have a compiler that can
| compile and boot linux! And people are complaining that
| the code is unmaintainable and that it's slow /
| unoptimised. We've gone full circle, but forgot that
| optimisation was easyyyy. Now it's something to complain
| about. Oh well...
| Applejinx wrote:
| Microsoft will be an excellent real-world experiment on
| whether this is any good. We so easily forget that giant
| platform owners are staking everything on all this
| working exactly as advertised.
|
| Some of my calculations going forward will continue to be
| along the lines of 'what do I do in the event that
| EVERYTHING breaks and cannot be fixed'. Some of my day
| job includes retro coding for retro platforms, though
| it's cumbersome. That means I'll be able to supply useful
| things for survivors of an informational apocalypse,
| though I'm hoping we don't all experience one.
| pragmatic wrote:
| 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.
| skybrian wrote:
| The costs for code improvement projects have gone down
| dramatically now that we have power tools. So, perhaps it
| will be considered more worthwhile now? But how this
| actually plays out for professional programming is going
| to depend on company culture and management.
|
| In my case, I'm an early-retired hobbyist programmer, so
| I control the budget. The same is true for any open
| source project.
| xtracto wrote:
| 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.
| thesmtsolver2 wrote:
| 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.
| skybrian wrote:
| There are certainly people working on making this happen.
| As a hobbyist, maybe I'll still have some retro fun
| polishing the source code for certain projects I care
| about? (Using our new power tools, of course.)
| manmal wrote:
| What you're describing is that we'd turn deterministic
| engineering into the same march of 9s that FSD and
| robotics are going through now - but for every single
| workflow. If you can't check the code for correctness,
| and debug it, then your test system must be absolutely
| perfect and cover every possible outcome. Since that's
| not possible for nontrivial software, you're starting a
| march of 9s towards 100% correctness of each solution.
|
| That accounting software will need 100M unit tests before
| you can be certain it covers all your legal requirements.
| (Hyperbole but you get the idea) Who's going to verify
| all those tests? Do you need a reference implementation
| to compare against?
|
| Making LLM work opaque to inspection is kind of like
| pasting the outcome of a mathematical proof without any
| context (which is almost worthless AFAIK).
| sifar wrote:
| And what happens when these different objectives conflict
| or diverge ? Will it be able to figure out the
| appropriate trade-offs, live with the results and go meta
| to rethink the approach or simply delude itself ? We
| would definitely lose these skills if it continues like
| this.
| ThrowawayR2 wrote:
| It'll probably look like the code version of this, an image
| run through a LLM 101 times with the directive to create a
| replica of the input image: https://www.reddit.com/r/ChatGP
| T/comments/1kbj71z/i_tried_th... Despite being provided
| with explicit instructions, well...
|
| People are still wrongly attributing a mind to something
| that is essentially mindless.
| pinkgolem wrote:
| I mean, if you tell a chain of 100 humans to redraw a a
| picture i would expect it to go similar, just much faster
| seba_dos1 wrote:
| > 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)
| kaydub wrote:
| I hope you realize that means your position is in danger.
| seba_dos1 wrote:
| It would be in danger if LLMs could actually do that for
| me, but they're still very far from it and they progress
| slowly. One day I could start worrying, but it's not
| today.
| fragmede wrote:
| And even if you are the single engineer, I'll be honest, it
| might as well have been somebody else that wrote the code
| if I have to go back to something I did seven years ago and
| unearth wtf.
| dasil003 wrote:
| 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.
| athrowaway3z wrote:
| 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.
| J_Shelby_J wrote:
| Id wager my life savings that devs aren't even 1.5x more
| productive using these tools.
| zer00eyz wrote:
| Dead wrong.
|
| Because the world is still filled with problems that
| would once have been on the wrong side of the is it worth
| your time matrix ( https://xkcd.com/1205/ )
|
| There are all sorts of things that I, personally, should
| have automated long ago that I threw at claud to do for
| me. What was the cost to me? Prompt and a code review.
|
| Meanwhile, on larger tasks an LLM deeply integrated into
| my IDE has been a boon. Having an internal debate on how
| to solve a problem, try both, write a test, prove out
| what is going to be better. Pair program, function by
| function with your LLM, treat it like a jr dev who can
| type faster than you if you give it clear instructions. I
| think you will be shocked at how quickly you can
| massively scale up your productivity.
| newAccount2025 wrote:
| The matrix framing is a very nice and way to put it. This
| morning I asked my assistant to code up a nice debugger
| for a particular flow in my application. It's much better
| than I would have had time/patience to build myself for a
| nice-to-have.
| rubyn00bie wrote:
| I sort of have a different view of that time matrix. If
| AI is only able to help me do tasks that are of low
| value, where I previously wouldn't have bothered--- is it
| really saving me anything? Before where I'd simply ignore
| auxiliary tasks, and focus on what matters, I'm now
| constantly detoured with them thinking "it'll only take
| ten minutes."
|
| I also primarily write Elixir, and I have found most
| Agents are only capable of writing small pieces well.
| More complicated asks tend to produce unnecessarily
| complicated solutions, ones that may "work," on the
| surface, but don't hold up in practice. I've seen a large
| increase in small bugs with more AI coding assistance.
|
| When I write code, I want to write it and forget about
| it. As a result, I've written a LOT of code which has
| gone on to work for years without touching it. The amount
| of time I spent writing it is inconsequential in every
| sense. I personally have not found AI capable of
| producing code like that (yet, as all things, that could
| change).
|
| Does AI help with some stuff? Sure. I always forget
| common patterns in Terraform because I don't often have
| to use it. Writing some initial resources and asking it
| to "make it normal," is helpful. That does save time.
| Asking it to write a gen server correctly, is an act of
| self-harm because it fundamentally does not understand
| concurrency in Erlang/BEAM/OTP. It very much looks like
| it does, but it 100% does not.
|
| tldr; I think the ease of use of AI can cause us to over
| produce and as a result we miss the forest for the trees.
| zer00eyz wrote:
| > are only capable of writing small pieces well.
|
| It excels at this, and if you have it deeply integrated
| into your workflow and IDE/dev env the loop should feel
| more like pair programing, like tennis, than it should
| feel like its doing everything for you.
|
| > I also primarily write Elixir,
|
| I would also venture that it has less to do with the
| language (it is a factor) and more to do with what you
| are working on. Domain will matter in terms of sample
| size (code) and understanding (language to support).
| There could be 1000s of examples in its training data of
| what you want, but if no one wrote a commment that
| accurately describes what that does...
|
| > I think the ease of use of AI can cause us to over
| produce and as a result we miss the forest for the trees.
|
| This is spot on. I stopped thinking of it as "AI" and
| started thinking of it as "power tools". Useful, and like
| a power tool you should be cautious because there is
| danger there... It isnt smart, it's not doing anything
| that isnt in its training data, but there is a lot there,
| everything, and it can do some basic synthesis.
| xeromal wrote:
| Yup, I've already run like 6 of my personal projects
| including 1 for my wife that I had lost interest in. For
| a few dollars, these are now actually running and being
| used by my family. These tools are a great enabler for
| people like me. lol
|
| I used to complain when my friends and family gave me
| ideas for something they wanted or needed help with
| because I was just too tired to do it after a day's work.
| Now I can sit next to them and we can pair program an
| entire idea in an evening.
| leptons wrote:
| It probably depends on the developer, and how much
| slop/bugs is willing to be tolerated.
| mattlondon wrote:
| Even if I am only slightly more productive, it feels like
| I am flying. The mental toll is severely reduced and the
| feel good factor of getting stuff done easily (rather
| than as a slog) is immense. That's got to be worth
| something in terms of the mental wellbeing of our
| profession.
|
| FWIW I generally treat the AI as a pair programmer. It
| does most of the typing and I ask it why it did this? Is
| that the most idiomatic way of doing it? That seems
| hacky. Did you consider edge case foo? Oh wait let's call
| it a BarWidget not a FooWidget - rename everything in all
| other code/tests/make/doc files Etc etc.
|
| I save a _lot_ of time typing boilerplate, and I find
| myself more willing (and a lot less grumpy!!!) to bin a
| load of things I 've been working on but then realise is
| the wrong approach or if the requirements change (in the
| past I might try to modify something I'd been working on
| for a week rather than start from scratch again, with AI
| there is zero activation energy to start again the right
| way). Thats super valuable in my mind.
| seff wrote:
| I view the current tools as more of a multiplier of base
| skill.
|
| A 1x engineer may become a 5x engineer, but a -1x will
| also produce 5x more bad code.
| Retric wrote:
| Several experiments have shown quality of output at every
| skill level drops.
|
| In many cases the quantity of output is good enough to
| compensate, but quality is extremely difficult to improve
| at scale. Beefing up QA to handle significantly more code
| of noticeably lower quality only goes so far.
| rirze wrote:
| Like others are saying, AI will accelerate the gap
| between competent devs and mediocre devs. It is a
| multiplier. AI cannot replace fundamentals, at least not
| a good helmsman with a good rational, detail-oriented
| mind. Having fundamentals (skill & knowledge) + using AI
| will be the cheat code in the next 10 years.
|
| The only historical analogue of this is perhaps
| differentiating a good project manager from an excellent
| one. No matter how advanced, technology will not
| substitute for competence.
| bodge5000 wrote:
| I get its necessary for investment, but I'd be a lot
| happier with these tools if we didn't keep making these
| wild claims, because I'm certainly not seeing 10x the
| output. When I ask for examples, 90% its claude code (not
| a beacon of good software anyway but if nearly everyone
| is pointing to one example it tells you thats the best
| you can probably expect) and 10% weekend projects, which
| are cool, but not 10x cool. Opus 4.5 was released in Dec
| 2025, by this point people should be churning out year
| long projects in a month, and I certainly haven't seen
| that.
|
| I've used them a few times, and they're pretty cool. If
| it was just sold as that (again, couldn't be, see:
| trillion dollar investments) I wouldn't have nearly as
| much of a leg to stand on
| robhlt wrote:
| 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.
| scoofy wrote:
| 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.
| robhlt wrote:
| 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.
| scoofy wrote:
| I mean, the thesis of the post is odd. I'll grant you
| that.
|
| I work mostly with python (the vast majority is pure
| python), flask, and htmx, with a bit of vanilla js thrown
| in.
|
| In a sense, I can understand the thesis. On the one hand
| Flask is a fantastic tool, with a reasonable abstraction
| given the high complexity. I wouldn't want to replace
| Flask. On the otherhand HTMX is a great tool, but often
| imperfect for what I'm exactly trying to do. Most people
| would say "well just just React!" except that I honestly
| loathe working with js, and unless someone is paying me,
| I'll do it in python. I could see working with an LLM to
| build a custom tool to make a version of HTMX that better
| interacts with Flask in the way I want it to.
|
| In fact, in my project I'm working on now I'm building
| complex heatmap illustrations that require a ton of
| dataprocessing, so I've been building a model to reduce
| the NP hard aspects of that process. However, the
| illustrations _are the point_ , and I've already had a
| back and forth with the LLM about porting the project
| into HTML, or some web based version of illustration at
| least, simply because I'd have much more control over the
| illustrations. Right now, matplotlib still suits me just
| fine, but if I had to port it, I could see just building
| my own tool instead of finding an existing framework and
| learning it.
|
| Frameworks are mostly useful because of group knowledge.
| I learn Flask because I don't want to build all these
| tools from scratch, and because I makes me literate in a
| very common language. The author is suggesting that these
| barriers -- at least for your own code -- functionally
| don't exist anymore. Learning a new framework is about as
| labor intensive as learning one you're creating as you
| go. I think it's short-sighted, yes, but depending on the
| project, yea when it's trivial to build the tool you
| want, it's tempting to do that instead learning to use a
| similar tool that needs two adapters attached to it to
| work well on the job you're trying to do.
|
| At the same time, this is about scope. Anyone throwing
| out React because they want to just "invent their own
| entire web framework" is just being an idiot.
| poulsbohemian wrote:
| What kind of project / prompts - what's working for you?
| /I spent a good 20 years in the software world but have
| been away doing other things professionally for couple
| years. Recently was in the same place as you, with a new
| project and wanting to try it out. So I start with a
| generic Django project in VSCode, use the agent mode,
| and... what a waste of time. The auto-complete
| suggestions it makes are frequently wrong, the actions it
| takes in response to my prompts tend to make a mess on
| the order of a junior developer. I keep trying to figure
| out what I'm doing wrong, as I'm prompting pretty simple
| concepts at it - if you know Django, imagine concepts
| like "add the foo module to settings.py" or "Run the
| check command and diagnose why the foo app isn't
| registered correctly" Before you know it, it's spiraling
| out of control with changes it thinks it is making, all
| of which are hallucinations.
| scoofy wrote:
| I'm just using Gemini in the browser. I'm not ready to
| let it touch my code. Here are my last two prompts, for
| context the project is about golf course architecture:
|
| Me, including the architecture_diff.py file: _I would
| like to add another map to architecture_diff. I want the
| map to show the level of divergence of the angle of the
| two shots to the two different holes from each point.
| That is, when your are right in between the two holes, it
| should be a 180 degree difference, and should be very
| dark, but when you 're on the tee, and the shot is almost
| identical, it should be very light. Does this make sense?
| I realize this might require more calculations, but I
| think it's important._
|
| Gemini output was some garbage about a simple naive angle
| to two hole locations, rather than using the
| sophisticated expected value formula I'm using to
| calculate strokes-to-hole... thus worthless.
|
| Follow up from me, including the course.py and the
| player.py files: _I don 't just want the angle, I want
| the angle between the optimal shot, given the dispersion
| pattern. We may need to update get_smart_aim in the
| player to return the vector it uses, and we may need to
| cache that info. We may need to update
| generate_strokes_gained_map in course to also return the
| vectors used. I'm really not sure. Take as much time as
| you need. I'd like a good idea to consider before
| actually implementing this._
|
| Gemini output now has a helpful response about saving the
| vector field as we generate the different maps I'm trying
| to create as they are created. This is exactly the type
| of code I was looking for.
| jacomoRodriguez wrote:
| I recently started building a POC for an app idea. As
| framework I choose django and I did not once wrote code
| myself. The whole thing was done in a github codespace
| with copilot in agentic mode and using mostly sonnet and
| opus models. For prompting, I did not gave it specific
| instructions like add x to settings. I told it "We are
| now working on feature X. X should be able to do a, b and
| c. B has the following constraints. C should work like
| this." I have also some instructions in the agents.md
| file which tells the model to, before starting to code,
| ask me all unclear questions and then make a
| comprehensive plan on what to implement. I would then go
| over this plan, clarify or change if needed - and then
| let it run for 5-15 minutes. And every time it just did
| it. The whole thing, with debugging, with tests. Sure,
| sometimes there where minor bugs when I tested - but then
| I prompted directly the problem, and sure enough it got
| fixed in seconds...
|
| Not sure why we had so different experiances. Maybe you
| are using other models? Maybe you miss something in your
| prompts? Letting it start with a plan which I can then
| check did definitly help a lot. Also a summary of the
| apps workings and technical decissions (also produced by
| the model) did maybe help in the long run.
| kolinko wrote:
| Also >20 years in software. The VSCode/autocomplete,
| regardless of the model, never worked good for me. But
| Claude Code is something else - it doesn't do
| autocomplete per se - it will do modifications, test, if
| it fails debug, and iterate until it gets it right.
| MrDarcy wrote:
| 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.
| fullstackchris wrote:
| > better to not have bugs in the first place
|
| you must have never worked on any software project ever
| Balinares wrote:
| Have you? Then you know that the amount of defects scales
| linearly with the amount of code. As things stand models
| write a lot more code than a skilled human for a given
| requirement.
| james_marks wrote:
| Because frameworks don't have bugs? Or unpredictable
| dependency interactions?
|
| This is generous, to the say the least.
| 113 wrote:
| > 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?
| viraptor wrote:
| Because nobody posts the good ones. They're boring,
| correct, you merge them and move on to the next one. It's
| like there's a murder in the news every day but generally
| we're still all fine.
|
| Don't assume that when people make fun of some examples
| that there aren't thousands more that nobody cares to write
| about.
| poulsbohemian wrote:
| I think back on the ten+ years I spent doing SRE consulting
| and the thing is, finding the problems and identifying
| solutions -- the technical part of the work -- was such a
| small part of the actual work. So often I would go to work
| with a client and discover that they often already knew the
| problem, they just didn't believe it - my job was often about
| the psychology of the organization more than the technical
| knowledge. So you might say "Great, so the agent will
| automatically fix the problem that the organization previous
| misidentified." That sounds great right up until it starts
| dreaming... it's not to say there aren't places for these
| agents, but I suspect ultimately it will be like any other
| technology we use where it becomes part of the toolkit, not
| the whole.
| markus_zhang wrote:
| But by then many of us are already starved. That's why I always
| said that engineers should NOT integrate AI with internal data.
| bthornbury wrote:
| 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.
| paulhebert wrote:
| 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
| paulhebert wrote:
| 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?
| paulhebert wrote:
| - 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?
| kaydub wrote:
| 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.
| rglover wrote:
| I've been using it every day for nearly two years now, with
| your suggested productivity boost observed.
|
| The difference is that I'm not just letting agents willy
| nilly commit code. I treat them more like a companion and
| guide their steps (I use Cline w/ Sonnet/Opus 4.5/4.6). Not
| only do I save a ton of money on tokens, but the results end
| up being infinitely better than the "yolo" mode outcomes
| (even _with_ excellent prompting /context).
|
| From my POV, the only divide is between a willingness to be
| an accountable professional versus someone who just "lets the
| AI do it" and whistles-with-hands-in-pockets when that code
| inevitably blows up in a way you couldn't predict (because
| you weren't checking, only the AI was, which you swore was
| "good enough").
|
| That approach works if you're just sitting on your couch
| hacking up toys to dice roll on X. But if you're trying to
| build reliable, deterministic systems that aren't constantly
| buzzing you awake at 3am, you're asking for a serious
| humbling if no one in your organization can explain how or
| why anything your business relies on works the way it does
| (that's operationally suicidal, imo, but hey-- _America_ ).
|
| That gets misinterpreted as being a "luddite," when really
| it's just having been down the rabbit hole enough times to
| know that if you can't point to and understand why it's
| happening (and ideally, _whodunit_ ), you don't know shit.
| straydusk wrote:
| 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?
| squidbeak wrote:
| 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.
| imiric wrote:
| Pray tell, how has the world benefited from a flood of all
| these superhuman developers? Where is the groundbreaking
| software that is making our lives _better_?
| rglover wrote:
| I'm not betting against them, I use them every day (but I
| don't "vibe code"--there's more intent). I'm just not
| treating them as a deity or other prayer-candle worthy
| entity. They're business tools. _It 's just a chat bot bro_.
| cookiengineer wrote:
| 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.
| tenthirtyam wrote:
| 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.
| layer8 wrote:
| 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.
| leptons wrote:
| It's already like that, for a long time. Humans are quite
| capable of creating complex systems that become unwieldy
| the bigger they get. No one person can understand all of
| it. I will offer the AT&T billing system as an example that
| I'm all too familiar with as a customer, due to the pain it
| causes me. So many ridiculous problems with that system,
| it's been around a long time, and it is just so screwball.
| wouldbecouldbe wrote:
| 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.
| rugPool wrote:
| 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.
| harrisi wrote:
| 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.
| feastingonslop wrote:
| Nobody is saying to skip testing the software. Testing is
| still important. What the code itself looks like, isn't.
| fennecbutt wrote:
| 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. ;~;
| divbzero wrote:
| 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.
| rglover wrote:
| If you've ever been responsible for large systems, you'll
| know why that is an incredibly naive position to take.
| kaydub wrote:
| The hubris is with the devs that think like you actually.
| rglover wrote:
| Carefully, patiently, and intentionally in the direction of
| stability and good user experience?
| kaydub wrote:
| The arrogance to think this isn't possible using llm tools
| and that the opposite didn't already exist at plenty of
| software shops pre-llm tools...
| aogaili wrote:
| What's makes you so sure of your statement?
|
| I have be building systems for 20 years and I think the author
| is right.
| manuelabeledo wrote:
| 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?
| karmasimida wrote:
| I give a year, the realization would be brutal.
| farseer wrote:
| I think it would be the opposite and we are all in for a rude
| awakening. If you have tried playing with Opus 4.6 you would
| know what I am talking about.
| nomel wrote:
| I tell my colleagues we're in the instantaneous _peak_ of the
| AI developer relationship, especially for code monkeys. We
| 're still valued, still paid really well, and our jobs will
| get easier and easier probably for the next 5-10 years! After
| that, maybe not so great for many of us, with the developers
| that _use_ software as a _means_ of their actual profession
| continuing to do just fine (hard math
| /science/optimization/business planning/project
| planners/etc).
|
| I think it's going to be an amazing shift from those that
| know intricate details of software to _enabling_ those that
| _have the best ideas_ that can be implemented with software
| (a shift from tool makers to tool users).
|
| I think many developers misunderstand the quality of software
| that people _outside of software_ are willing to live with,
| if it does exactly what they want when they need it. For a
| user, it 's all black box "do something I want or not"
| regardless of what's under the hood. Mostly "academic",
| things like "elegant" and "clean" and "maintainable" almost
| never _practically matter_ for most _practical solutions to
| actual problems_. This is something I learned far too late in
| my professional career, where the lazy dev with shite code
| would get the same recognition as the guy that had beautiful
| code: does it solve the _real world_ problem or not?
|
| Safety critical, secure, etc, sure, but most is not. And,
| even with those, the libraries/APIs/etc are separate
| components.
| igleria wrote:
| > A significant number of developers and businesses are going
| to have an absolutely brutal rude awakening in the not too
| distant future.
|
| I pray (?) for times like the ones you predict. But companies
| can stay irrational longer than the average employee can
| afford.
| killerstorm wrote:
| Software engineers have been confidently wrong about a lot of
| things.
|
| E.g. OOP and "patterns" in 90s. What was the last time you
| implemented a "visitor"?
|
| P. Norvig mentioned most of the patterns are transparent in
| Common Lisp: e.g. you can just use a `lambda` instead of
| "visitor". But OOP people kept doing class diagrams for a
| simple map or fold-like operation.
|
| AI producing a flawed code and "not understanding" are
| completely different issues. Yes, AI can make mistakes, we
| know. But are you certain your understanding is really
| superior?
| thephyber wrote:
| This sounds entirely too doomer.
|
| There will obviously be companies that build a vibe coded app
| which too many people depend on. There will be some iteration
| (maybe feature addition, maybe bug fix) which will cause a
| catastrophic breakage and users will know.
|
| But there will also be companies who add a better mix of
| incantations to the prompts, who use version control and CI,
| who ensure the code is matched with tests, who maintain the
| prompts and requirements documents.
|
| The former will likely follow your projected path. The latter
| will do fine and may even thrive better than either traditional
| software houses of cheap vibe coding shops.
|
| Then again, there are famous instances of companies who have
| tolerated terribly low investment in IT, including SouthWest
| Airlines.
| rglover wrote:
| I'd say you're absolutely right.
|
| The problem is...what is the distribution of companies who do
| it "right" to companies that don't?
| nekitamo wrote:
| The same as the distribution of companies which are
| profitable over time and grow steadily, vs the others which
| clumsily flail around to somehow stay alive. To the winner
| go the spoils, and the winners will be a tiny fraction of
| companies, same as it ever was.
|
| A way I look at it is that all net wealth creation in
| public companies has come from just 4% of businesses:
|
| https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2900447
|
| https://www.reddit.com/r/investing/comments/rk4udc/only_4_o
| f...
|
| It'll be similar with software companies. 4% of them will
| hit on a unique cultural and organizational track which
| will let them thrive, probably using AI in one form or
| another. The other 96% will be lucky to stay alive.
|
| Same as it ever was.
| bodge5000 wrote:
| > Good time to be in business if you can see through the bs and
| understand how these systems actually function
|
| You missed out the most crucial and least likely requirement
| (assuming you're not self employed); management also need to be
| able to see through the bs.
| postepowanieadm wrote:
| Build libraries, not frameworks.
| wundersam wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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
| steroides, 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 wrote:
| 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 wrote:
| 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 wrote:
| I suggest to read the full article :)
| 3vidence wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I was thinking the same. On mobile both frameworks and
| libraries make my life infinitely easier
| eqvinox wrote:
| > 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.
| pawelduda wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| AI rolled cryptographic libraries now make it feasible to just
| roll your own crypto.
| aschla wrote:
| 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 wrote:
| 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)
| samiv wrote:
| Next up "coding agents replaced me"
| YarickR2 wrote:
| 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 wrote:
| 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 wrote:
| ...and importantly, neither does the LLM; frameworks are
| incredibly useful even if you are using generative AI.
| ewuhic wrote:
| ai slop shit
| alainrk wrote:
| Interesting analysis
| physicsguy wrote:
| 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 wrote:
| 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 wrote:
| LinkedIn article?
|
| What frameworks and what have you accomplished with it?
| capitanazo77 wrote:
| 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 wrote:
| LLMs finally deliver on the crochety front end dev's dream of
| writing everything in vanilla JS. Hallelujah.
| athrowaway3z wrote:
| 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 wrote:
| 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 wrote:
| I feel like commenting on the article without reading was really
| vindicated with the advent of AI slop.
| zeroq wrote:
| 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 wrote:
| 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.
| mbgerring wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I had called this a while back, since the reasoning is simple:
| frameworks primarily exist to minimize boilerplate, but AI is
| very good at boilerplate, so the value of frameworks is
| diminished.
|
| The larger underlying shift is that the economics of coding have
| been upended. Since its inception, our industry has been
| organized around one fundamental principle: code is expensive
| because coders are expensive. This created several complex
| dynamics, one which was frameworks -- which are massive, painful
| dependencies aimed at alleviating costs by reducing the repeated
| boilerplate written by expensive people. As TFA indicates, the
| costs of frameworks in terms of added complexity (e.g.
| abstractions from the dependency infecting the entire codebase)
| are significant compared to their benefits.
|
| But now that the cost of code ---> 0, the need for frameworks
| (and reusability overall) will likely also --> 0.
|
| I had predicted that this dynamic will play out widely and result
| in a lot more duplicative code overall, which is already being
| borne out by studies like
| https://www.gitclear.com/ai_assistant_code_quality_2025_rese...
|
| Our first instinct is to recoil and view this as a bad thing,
| because it is considered "Tech Debt." But as the word "debt"
| indicates, Tech Debt is yet another economic concept and is also
| being redefined by these new economics!
|
| For instance, all this duplicate code would have been terrible if
| only humans had to maintain it. But for LLMs, it is probably
| _better_ because all the relevant logic is RIGHT THERE in the
| code, conveniently colocated with the rest of the functionality
| where it is used, and not obfuscated behind a dozen layers of
| abstraction whose (intended) functionality is described in
| natural language scattered across a dozen different pieces of
| documentation, each with varying amounts of sufficiency, fidelity
| and updated-ness. This keeps the context very focused on the
| relevant bits, which along with extensive testing (again, because
| code is cheap!) that enables instant self-checking, greatly
| amplifies the accuracy of the LLMs.
|
| Now, I'm not claiming to say this will work out well long term --
| it's too early to tell -- but it is a logical outcome of the
| shifting economics of code. I always say with AI, the future of
| coding will look very weird to us; this is another example of it.
| cess11 wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| djoldman wrote:
| I am not "against" AI programming, although I confess I don't
| really know what that means... coders and business folk are
| gonna do whatever gets the job done and opinions by and large
| matter not a whit.
|
| However:
|
| > ..it can probably be used for AI programmers using
| temperature 0.0 as well, just one abstraction level higher.
|
| Right, but... approximately zero users of AI for coding are
| setting temperature to 0 not to mention changing temperature at
| all. So this is a comparison to a world that doesn't really
| exist.
|
| Additionally, C code compiles much much closer to the same
| assembly and microcode regardless of compiler as compared to
| temperature zero prompts across different AIs.
| carlcarrie wrote:
| Good article: Software Engineering is finally being liberated
| from the "Middle Work" of the last decade.
|
| The AI tsunami isn't just about coding faster--it's about
| reclaiming architectural sovereignty from hyperscaler blueprints.
|
| The future is Just-in-Time and Highly Customized.
|
| My full thoughts here:
| https://www.linkedin.com/posts/carlcarrie_software-engineeri...
| soueuls wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I'm surprised I don't see many (or any) comments mentioning this:
| this blog post was clearly written with heavy LLM assistance.
| nprateem wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/
|
| 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.
___________________________________________________________________
(page generated 2026-02-07 23:01 UTC)