Most people in this thread are quibbling about the exact degree of utility LLMs provide, which a tedious argument.
What's more interesting to me is, per the article, the concern regarding everyone who is leaning into LLMs without realizing (or downplaying) the exorbitant, externalized cost. Our current LLM usage is being subsidized to the point of being free by outside investment. One day when the well runs dry, you must be able to either pay the actual cost (barring grand technology breakthroughs), or switch back to non-LLM workflows. I run local LLMs infrequently, and every single prompt makes my beefy PC sounds like a jet engine taking off. It's a great reminder to not become codependent.
As someone who works on the design and construction of datacenters, I cannot stress enough how apropos this comment is. Even before the first conversation in your IDE starts, the load on national and local government resources, local utility capacity, and roadway infrastructure is enormous. We're all paying whether we're using the tools or not.
Nearly nobody cares about the load on “national and local government resources, local utility capacity, and roadway infrastructure” for any other day-to-day activity. Why should they care about the same for AI which for most people is “out there online” somewhere? Related my, crypto bros worried about electricity usage only so far as its expense went and whether they could move closer to hydro dams.
I always liken it to using Uber in ~2012. It was fun to get around major metro areas for dirt cheap. But then prices rose dramatically over the next decade+ as the company was forced to wean itself off of VC subsidies.
There's a lot in this comment that doesn't exactly fit.
First of all, there could be other solutions, such as B2B subsidizing individual user plans, or more fine grained model tiering per cost.
Also, yes you can get some access for free, but even today the higher tiers of proprietary models is around $200/mo for individual users, which might still be subsidized but is definitely not free, and is quite a chunk of money at $2400 a year!
I don't know what your setup is at the moment, but it's possible more efficient hardware and stack are available that you're not utilizing. Of course this depends on what models you're trying to run.
I think that smaller models will become a lot better, and hardware will become more optimized as well. We're starting to see this with NPUs and TPUs.
All this means running models will cost less, and maybe upgrading the power grid will also reduce cost of energy, making it more affordable.
I don't see any way that AI will go away because it "hits a wall". We have long passed the point of no return.
You are looking at it from the individual's PoV, but the OP is using the bird view from high above. It is the total amount of effort deployed today already to provide all the existing AI services, which is enormous. Data centers, electricity, planning/attention (entities focused on AI have less time to work on something else), components (Nvidia shortage, RAM shortage), etc.
This is not about finance, but about the real economy and how much of it, and/or its growth, is diverted to AI. The real economy is being reshaped, influencing a lot of other sectors independent of AI use itself. AI heavily competes with other uses for many kinds of actual real resources - without having equally much to show for it yet.
This is a good point but you can see the price "ceiling" by examining the prices for PCs that can effectively run local models. A DGX Spark is ~$4k (plus power) for example.
That's not nothing, but it's still not very much to pay compared to e.g. the cost of a FTE.
I find the cost discussion to be exceedingly more tedious. This would be a more compelling line of thinking if we didn't have highly effective open-weight models like qwen3-coder, glm 4.7 etc. which allow us to directly measure the cost of running inference with large models without confounding factors like VC money. Regardless of the cost of training, the models that exist right now are cheap and effective enough to push the conversation right back to "quibbling about the exact degree of utility LLMs provide".
>I run local LLMs infrequently, and every single prompt makes my beefy PC sounds like a jet engine taking off. It's a great reminder to not become codependent.
I would try setting the GPU to run at a lower power level. I set my GPU power level to 80% and it becomes much quieter, and only runs maybe 5% slower at most.
Also I 100% agree with the rest of your comment. We can only power the current growth we are seeing for so long.
> One day when the well runs dry, you must be able to either pay the actual cost
What multiple of the current cost do you expect? Currently, GitHub Copilot and ChatGPT for Business cost $19/month and €29/month respectively. Even a 10×–20× increase will still be economically viable in a professional setting if the tools continue to save hours of work.
The cost is coming down fast. You can get a $2000 desktop machine (AMD 395) that can run effectively chatGPT 3.5 levels of LLMs at over 100 tokens per second.
if you wrote this comment 70 years ago when computers were the size of rooms, it would make a lot of sense, and yet we know how history played out where everyone has a super computer in their pocket.
for some reason it feels like people are under the assumption that hardware isnt going to improve or something?
Writing my comment on this post, I kind of feel like LLM's are like similar to wordpress/drag and drop tool although its more inconsistent too perhaps not sure
I 100% share the codependent path too and had written a similar comment some 2-3 days ago but these AI companies which provide are either seriously negative/loss making subsidizing or they are barely net zero. I doubt that it will continue and so the bubble will burst I guess and prices of these will rise perhaps
We will see perhaps something like google which can feed on advertising can perhaps still provide such subsidies for a longer time but the fact of the matter is that I have no alleigance to any model as some might have and I will simply shift to the cheapest thing which can still provide me / be enough for my queries or prototypes mostly I suppose.
I am sorry, but this kind of level-headed and realistic take is completely unacceptable on hackernews, and you should be ashamed of yourself. This is not a place for rational discussion when it comes to LLMs.
LLMs are amazing and they will change everything, and then everything will be changed.
After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
LLMs pretend to do this with big confidence and fail miserably.
For every problem I need to turn my brain to ON MODE and wake up, the LLM doesn't wake up.
It surprised me how well it solved another task: I told it to set up a website with some SQL database and scripts behind it. When you click here, show some filtered list there. Worked like a charm. A very solved problem and very simple logic, done a zillion times before. But this saved me a day of writing boilerplate.
I agree that there is no indication that LLMs will ever cross the border from simple-boilerplate-land to understanding-complex-problems-land.
I can confirm that they are completely useless for real programming
And I can confirm, with similar years of experience, that they are not useless.
Absolutely incredible tools that have saved hours and hours helping me understand large codebases, brainstorm features, and point out gaps in my implementation or understanding.
I think the main disconnect in the discourse is that there are those pretending they can reliably just write all the software, when anyone using them regularly can clearly see they cannot.
But that doesn't mean they aren't extremely valuable tools in an engineer's arsenal.
I feel like I have to be strategic with my use of claude code. things like frequently clearing out sessions to minimize context, writing the plan out to a file so that I can review it more effectively myself and even edit it, breaking problems down into consumable chunks, attacking those chunks in separate sessions, etc. it's a lot of prep work I have to do to make the tool thrive. that doesn't mean it's useless, though.
Perhaps you're doing some amazing low-level work, but it feels like you're way overestimating how much of our industry does that. A massive amount of developers show up to work every day and just stitch together frameworks and libraries.
In many ways, it feels similar to EVs. Just because EVs aren't yet, and may never be, effective to moving massive amounts of cargo in a day with minimal refueling, doesn't mean that they aren't an effective solution for the bulk of drivers who have an average commute of 40 miles a day.
> After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming
This is a bit of no-true-scottsman, no? For you "real programming" is "stuff LLMs are bad at," but a lot of us out in the real world are able to effectively extract code that meets the requirements of our day jobs from tossing natural language descriptions into LLMs.
I actually find the rise of LLM coding depressing and morally problematic (re copyright / ownership / license laundering), and on a personal level I feel a lot of nostalgia for the old ways, but I simply can't levy an "it's useless" argument against this stuff with any seriousness.
I only use it sparingly thus far, and for small things, but I don't find it depressing at all - but timely.
All those many, many languages, frameworks, libraries, APIs and there many many iterations, soooo much time lost on minute details. The natural language description, even highly detailed down to being directly algorithmic, is a much better level for me. I have gotten more and more tired of coding, but maybe part of it is too much Javascript and its quickly changing environment and tools, for too many years (not any more though). I have felt that I'm wasting way too much time chasing all those many, many details for quite some time.
I'm not pro-high-level-programming per se - I started a long time ago with 8 bit assembler and knowing every one of the special registers and RAM cells. I cherish the memories of complex software fitting on a 1.44 MB floppy. But it had gotten just a bit too extreme with all the little things I had to pay attention to that did not contribute to solving the actual (business) problem.
I feel it's a bit early even if it's already usable, but I hope they can get at least one more giant leap out of AI in the next decade or so. I am quite happy to be able to concentrate on the actual task, instead of the programming environment minutiae, which has exploded in size and complexity across platforms.
"they are completely useless for real programming"
You and I must have completely different definitions of "real programming". In this very comment, you described a problem that the model solved. The solution may not have involved low-level programming, or discovering a tricky bug entrenched in years-worth of legacy code, but still a legitimate task that you, as a programmer, would've needed to solve otherwise. How is that not "real programming"?
I wouldn't describe the LLM's actions in the example as "solving a problem" so much as "following a well-established routine". If I were to, for instance, make a PB&J sandwich, I wouldn't say that what I'm doing is "real cooking" even if it might technically fit the definition.
If an LLM controlling a pair of robot hands was able to make a passable PB&J sandwich on my behalf, I _guess_ that could be useful to me (how much time am I really saving? is it worth the cost? etc.), but that's very different from those same robo-hands filling the role of a chef de cuisine at a fine dining restaurant, or even a cook at a diner.
You'll get a vastly different experience the more you use these tools and learn their limitations and how you can structure things effectively to let them do their job better. But lots of people, understandably, don't take the time to actually sit down and learn it. They spend 30 seconds on some prompt not even a human would understand, and expect the tooling to automatically spend 5 hours trying its hardest at implementing it, then they look at the results and conclude "How could anyone ever be productive with this?!".
People say a lot of things, and there is a lot of context behind what they're saying that is missing, so then we end up with conversations that basically boil down to one person arguing "I don't understand how anyone cannot see the value in this" with another person thinking "I don't understand how anyone can get any sort of value out of this", both missing the other's perspective.
I've been using Codex and Claude Sonnet for many months now for personal (Codex) and work (Sonnet) and I agree. Three months ago these tools were highly usable, now with Codex 5.2 and Sonnet 4.5 I think we're at the point where you can confidently rely on them to analyze your repo codebase and solve, at the very least, small scoped problems and apply any required refactor back throughout the codebase.
6-12+ months ago the results I was getting with these tools were highly questionable but in the last six months the changes have been pretty astounding
It’s crazy how different my experience is. I think perhaps it’s incredibly important what programming language you are using, what your project and architecture is like. Agents are making an extraordinary contribution to my productivity. If they jacked my Claude Code subscription up to $500/month I would be upset but almost certainly would keep paying it, that’s how much value it brings.
It sounds like you use your personal Claude Code subscription for work of your employer, but that is not something I would ever consider doing personally so I imagine I must be mistaken.
Can you elaborate slightly on what you pay for personally and what your employer pays for with regards to using LLMs for Enterprise ERP?
Even more important than those things, is how well you can write and communicate your ideas. If you cannot communicate your ideas so a human could implement it as you wanted it to without asking extra questions, a LLM isn't gonna be able to.
> After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
"completely useless" and "real programming" are load bearing here. Without a definition to agree on for those terms, it's really hard not to read that as you're trying to troll us by making a controversial unprovable claim that you know will get people that disagree with you riled up. What's especially fun is that you then get to sneer at the abilities of anybody making concrete claims by saying "that's not real programming".
Ultimately it all boils down to the money - show me the money. OAI have to show money and so do its customers from using this tool.
But nope, the only thing out there where it matters is hype. Nobody is on an earnings call clearly showing how they had a numerical jump in operating efficiency.
Until I see that, this technology has a dated shelf life and only those who already generate immense cash flows will fund its continued existence given the unfavourable economics of continued reinvestment where competition is never-ending.
> After working with agent-LLMs for some years now
Some years? I don't remember any agents being any good at all before just over 1 year ago with Cursor and stuff really didn't take off until Claude Code.
Which isn't to say you weren't working with agent-LLMs before that, but I just don't know how relevant anything but recent experience is.
> I can confirm that they are completely useless for real programming
Can you elaborate on "real programming" ?
I am assuming you mean the simplest hard problem that is solved. The value of the work is measured in those terms. Easy problems have boilerplate solutions and have been solved numerous times in the past. LLMs excel here.
Hard problems require intricate woven layers of logic and abstraction, and LLMs still struggle since they do not have causal models. The value however is in the solution of these kinds of problems since the easy problems are assumed to be solved already.
> After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
> They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
This was how I felt until about 18 months ago.
Can you give a single, precise example where modern day LLMs fail as woefully as you describe?
i had to disable baby Ceph (Deepseek 3.1) from writing changes in Continue because he's like a toddler. But, he did confirm some solutions and wrote a routine and turn me on to some libraries, etc
so I see what you're saying. he comes up with the wrong answers a lot to a problem involving a group of classes in related files
however it's Continue, so it can read files in vs code which is really nice and that helps a lot with its comprehension so sometimes it does find the issue or at least the nature of the issue
I tend to give it bug n-1 to pre digest while I work on bug n
>After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
>They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
>LLMs pretend to do this with big confidence and fail miserably.
This is true for most developers as well. The mean software developer, especially if you outsource, has failure modes worse than any LLM and round-trip time is not seconds but days.
The promise of LLMs is not that they solve the single most difficult tasks for you instantly, but that they do the easy stuff well enough that they replace offshore teams.
> The promise of LLMs is not that they solve the single most difficult tasks for you instantly, but that they do the easy stuff well enough that they replace offshore teams.
But that's exactly the *promise* of LLMs by the hypepeople behind it.
Claude is currently porting my rust emulator to WASM. It's not easy at all, it struggles, I need to guide it quite a lot but it's way easier to let him do it than me learning yet another tech. For the same result I have 50% the mental load...
The idea they're good for development is propped up a lot by people able to have a react + tailwind site spun up fast. You know what also used to be able to scaffold projects quickly? The old init scripts and generators!
I really really want this to be true. I want to be relevant. I don’t know what to do if all those predictions are true and there is no need (or very little need) for programmers anymore.
But something tells me “this time is different” is different this time for real.
Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me. I’m basically just the conductor of all those processes.
Oh, and don't ask about coding. If you use AI for tasks above, as a result you'll get very well defined coding task definitions which an AI would ace.
I’m still hired, but I feel like I’m doing the work of an entire org that used to need twenty engineers.
I was a chef in Michelin-starred restaurants for 11 years. One of my favorite positions was washing dishes. The goal was always to keep the machine running on its 5-minute cycle. It was about getting the dishes into racks, rinsing them, and having them ready and waiting for the previous cycle to end—so you could push them into the machine immediately—then getting them dried and put away after the cycle, making sure the quality was there and no spot was missed. If the machine stopped, the goal was to get another batch into it, putting everything else on hold. Keeping the machine running was the only way to prevent dishes from piling up, which would end with the towers falling over and breaking plates. This work requires moving lightning fast with dexterity.
AI coding agents are analogous to the machine. My job is to get the prompts written, and to do quality control and housekeeping after it runs a cycle. Nonetheless, like all automation, humans are still needed... for now.
If it requires an expert engineer/dishwasher to keep the flow running perfectly, the human is the bottleneck in the process. This sounds a lot more like the past before AI to me. What AI does is just give you enough dishes that they don’t need to be washed at all during dinner service. Just let them pile up dirty or throw them away and get new dishes tomorrow it’s so immaterial to replace that washing them doesn’t always make sense. But if for some reason you do want to reuse them, then, it washes and dries them for you too. You just look over things at the end and make sure they pass your quality standards. If they left some muck on a plate or lipstick on a cup, just tell it not to let that happen again and it won’t. So even your QC work gets easier over time. The labor needed to deal with dirty dishes is drastically reduced in any case.
"AI" doesn't have a clue what to do on its own. Humans will always be in the loop, because they have goals, while the AI is designed to placate and not create.
The amount of "AI" garbage I have to sift through to find one single gem is about the same or more work than if I had just coded it myself. Add to that the frustration of dealing with a compulsive liar, and it's just a fucking awful experience for anyone that actually can code.
> Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me.
That is just not true, assuming you have a modicum of competence (which I assume you do). AIs suck at all these tasks; they are not even as good as an inexperienced human.
For all we know, you both could comparing using a Nokia 3310 and a workstation PC based on the hardware, but you both just say "this computer is better than that computer".
There are a ton of models out there, ran in a ton of different ways, that can be used in different ways with different harnesses, and people use different workflows. There is just so many variables involved, that I don't think it's neither fair nor accurate for anyone to claim "This is obviously better" or "This is obviously impossible".
I've been in situations where I hit my head against some hard to find bug for days, then I put "AI" (but what? No one knows) to it and it solves it in 20 minutes. I've also asked "AI" to do trivial work that it still somehow fucked up, even if I could probably have asked a non-programmer friend to do it and they'd be able to.
The variance is great, and the fact that system/developer/user prompts matter a lot for what the responses you get, makes it even harder to fairly compare things like this without having the actual chat logs in front of you.
LLMs generate the most likely code given the problem they're presented and everything they've been trained on, they don't actually understand how (or even if) it works. I only ever get away with that when I'm writing a parser.
Depends on how he defined "better". If he uses the word "better" to mean "good enough to not fail immediately, and done in 1/10th of the time", then he's correct.
I think I've been using AI wrong. I can't understand testimonies like this. Most times I try to use AI for a task, it is a shitshow, and I have to rewrite everything anyway.
I don’t know about right/wrong. You need to use the tools that make you productive. I personally find that in my work there are dozens of little scripts or helper functions that accelerate my work. However I usually don’t write them because I don’t have the time. AI can generate these little scripts very consistently. That accelerates my work. Perhaps just start simple.
Do you tell AI the patterns/tools/architecture you want? Telling agents to "build me XYZ, make it gud!" is likely to precede a mess, telling it to build a modular monolith using your library/tool list, your preferred folder structure, other patterns/algorithms you use, etc will end you up with something that might have some minor style issues or not be perfectly canonical, but will be approximately correct within a reasonable margin, or is within 1-2 turns of being so.
You have to let go of the code looking exactly a certain way, but having code _work_ a certain way at a coarse level is doable and fairly easy.
how much time/effort have you put in to educate yourself about how they work, what they excel at, what they suck at, what is your responsibility when you use them…? this effort is directly proportional to how well they will serve you
Not because the models are random, but because you are mistaking a massive combinatorial search over seen patterns for genuine reasoning. Taleb point was about confusing luck for skill. Dont confuse interpolation for understanding.
You can read a Rust book after years of Java, then go build software for an industry that did not exist when you started. Ask any LLM to write a driver for hardware that shipped last month, or model a regulatory framework that just passed... It will confidently hallucinate. You will figure it out. That is the difference between pattern matching and understanding.
I've worked with a lot of interns, fresh outs from college, overseas lowest bidders, and mediocre engineers who gave up years ago. All over the course of a ~20 year career.
Not once in all that time has anyone PRed and merged my completely unrelated and unfinished branch into main. Except a few weeks ago. By someone who was using the LLM to make PRs.
He didn't understand when I asked him about it and was baffled as to how it happened.
Really annoying, but I got significantly less concerned about the future of human software engineering after that.
Have you used an LLM specifically trained for tool calling, in Claude Code, Cursor or Aider?
They’re capable of looking up documentation, correcting their errors by compiling and running tests, and when coupled with a linter, hallucinations are a non issue.
I don’t really think it’s possible to dismiss a model that’s been trained with reinforcement learning for both reasoning and tool usage as only doing pattern matching. They’re not at all the same beasts as the old style of LLMs based purely on next token prediction of massive scrapes of web data (with some fine tuning on Q&A pairs and RLHF to pick the best answers).
Why would you expect an LLM or even a human to succeed in these cases? “Write a piece of code for a specification that you can’t possibly know about?” That’s why you have to do context engineering, just like you’d provide a reference to a new document to an engineer writing code.
They do all those things you've mentioned more efficiently than most of us, but they fall woefully short as soon as novelty is required. Creativity is not in their repertoire. So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce. But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step.
I choose to look at it as an opportunity to spend more time on the interesting problems, and work at a higher level. We used to worry about pointers and memory allocation. Now we will worry less and less about how the code is written and more about the result it built.
Take food for example. We don't eat food made by computers even though they're capable of making it from start to finish.
Sure we eat carrots probably assisted by machines, but we are not eating dishes like protein bars all day every day.
Our food is still better enjoyed when made by a chef.
Software engineering will be the same. No one will want to use software made by a machine all day every day. There are differences in the execution and implementation.
No one will want to read books entirely dreamed up by AI. Subtle parts of the books make us feel something only a human could have put right there right then.
No one will want to see movies entirely made by AI.
The list goes on.
But you might say "software is different". Yes but no, in the abundance of choice, when there will be a ton of choice for a type of software due to the productivity increase, choice will become more prominent and the human driven software will win.
Even today we pick the best terminal emulation software because we notice the difference between exquisitely crafted and bloated cruft.
> So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce.
The same thing over and over again should be a SaaS, some internal tool, or a plugin. Computers are good at doing the same thing over and over again and that's what we've been using them for
> But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step.
Even if the high level description of a task may be similar to another, there's always something different in the implementation. A sports car and a sedan have roughly the same components, but they're not engineered the same.
> We used to worry about pointers and memory allocation.
Some still do. It's not in every case you will have a system that handle allocations and a garbage collector. And even in those, you will see memory leaks.
> Now we will worry less and less about how the code is written and more about the result it built.
I think your image of LLMs is a bit outdated. Claude Code with well-configured agents will get entirely novel stuff done pretty well, and that’s only going to get better over time.
As of today NONE of the known AI codebots can
solve correctly ANY of the 50+ programming
exercises we use to interview fresh grads
or summer interns. NONE! Not even level 1
problems that can be solved in fewer than 20
lines of code with a bit of middle school
math.
After 25+ years in this field, having interviewed ~100 people for both my startup and other companies, I'm having a hard time believing this. You're either in an extremely niche field (such as to make your statement irrelevant to 99.9% of the industry), or it's hyperbole, or straight up bs.
Interviewing is an art, and IME "gotcha" types of questions never work. You want to search for real-world capabilities, and like it or not the questions need to match those expectations. If you're hiring summer interns and the SotA models can't solve those questions, then you're doing something wrong. Sorry, but having used these tools for the past three years this is extremely ahrd to believe.
I of course understand if you can't, but sharing even one of those questions would be nice.
I promise you that I can show you how to reliably solve any of them using any of the latest OpenAI models. Email me if you want proof; josh.d.griffith at gmail
However I'm still finding a trend even in my org; better non-AI developers tend to be better at using AI to develop.
AI still forgets requirements.
I'm currently running an experiment where I try to get a design and then execute on an enterprise 'SAAS-replacement' application [0].
AI can spit forth a completely convincing looking overall project plan [1] that has gaps if anyone, even the AI itself, tries to execute on the plan; this is where a proper, experienced developer can step in at the right steps to help out.
IDK if that's the right way to venture into the brave new world, but I am at least doing my best to be at a forefront of how my org is using the tech.
[0] - I figured it was a good exercise for testing limits of both my skills prompting and the AI's capability. I do not expect success.
> I’m basically just the conductor of all those processes.
a car moves faster than you, can last longer than you, and can carry much more than you. But somehow, people don't seem to be scared of cars displacing them(yet)? Perhaps autodriving would in the near future, but there still needs to be someone making decisions on how best to utilize that car - surely, it isn't deciding to go to destination A without someone telling them.
> I feel like I’m doing the work of an entire org that used to need twenty engineers.
and this is great. A combine harvester does the work of what used to be an entire village for a week in a day. More output for less people/resources expended means more wealth produced.
> a car moves faster than you, can last longer than you, and can carry much more than you. But somehow, people don't seem to be scared of cars displacing them(yet)?
People whose life were based around using horses for transportation were very scared of cars replacing them though, and correctly so, because horses for transportation is something people do for leisure today, not necessity. I feel like that's a more apt analogy than comparing cars to any human.
> More output for less people/resources expended means more wealth produced.
This is true, but it probably also means that this "more wealth produced" will be more concentrated, because it's easier to convince one person using AI that you should have half of the wealth they produce, rather than convincing 100 people you should have half of what they produce. From where I'm standing, it seems to have the same effects (but not as widespread or impactful, yet) as industrialization, that induced that side-effect as well.
> a car moves faster than you, can last longer than you, and can carry much more than you. But somehow, people don't seem to be scared of cars displacing them(yet)?
Sure LLMs can churn out code, and they sort of work for developers who already understand code and design, but what happens when that junior dev with no hard experience builds their years of experience with LLMs?
Over time those who actually understand what the LLMs are doing and how to correct the output are replaced by developers who've never learned the hard lessons of writing code line by line. The ability to reason about code gets lost.
This points to the hard problem that the article highlights. The hard problem of software is actually knowing how to write it, which usually takes years, sometimes up to a decade of real experience.
Any idiot can churn out code that doesn't work. But working, effective software takes a lot of skill that LLMs will be stripping people of. Leaving a market there for people who have actually put the time in and understand software.
This is not how I think about it.
Me and the coding assistant is better then me or the coding assistant separately.
For me its not about me or the coding assistant, its me and the coding assistant. But I'm also not a professional coder, i dont identify as a coder. I've been fiddling with programming my whole life, but never had it as title, I've more worked from product side or from stakeholder side, but always got more involved, as I could speak with the dev team.
This also makes it natural for me to work side-by-side with the coding assistant, compared maybe to pure coders, who are used to keeping the coding side to themselves.
I have been using the most recent Claude, ChatGPT and Gemini models for coding for a bit more than a year, on a daily basis.
They are pretty good at writing code *after* I thoroughly described what to do, step by step. If you miss a small detail they get loose and the end result is a complete mess that takes hours to clean up. This still requires years of coding experience, planning ahead in head, you won't be able to spare that, or replace developers with LLMs. They are like autocomplete on steroids, that's pretty much it.
I mean, AIs can drop something fast the same way you cannot beat a computer at adding or multiplying.
After that, you find mistakes, false positives, code that does not work fully, and the worse part is the last one: code that does not work fully but also, as a consequence, that you do NOT understand yet.
That is where your time shrinks: now you need to review it.
Also, they do not design systems better. Maybe partial pieces. Give them something complex and they will hallucinate worse solutions than what you already know if you have, let us say, over 10 years of experience programming in a language (or mabye 5).
Now multiply this unreliability problem as the code you "AI-generate" grows.
Now you have a system you do not know if it is reliable and that you do not understand to modify. Congrats...
I use AI moderately for the tasks is good at: generate some scripts, give me this small typical function amd I review it.
Review my code: I will discard part of your mistakes and hallucinations as a person that knows well the language and will find maybe a few valuable things.
Also, when reviewing and found problems in my code I saw that the LLMs really need to hallucinate errors that do not exist to justify their help. This is just something LLMs seem to not be accurate at.
Also, when problems go a bit more atypical or past a level of difficulty, it gets much more unreliable.
All in all: you are going to need humans. I do not know how many, I do not know how much they will improve. I just know that they are not reliable and this "generate-fast-unreliable vs now I do not know the codebase" is a fundamental obstacle that I think it is if not very difficult, impossible to workaround.
I feel you, it's scary. But the possibilities we're presented with are incredible. I'm revisiting all these projects that I put aside because they were "too big" or "too much for a machine". It's quite exciting
I'm extremely pro-faster-keyboard, i use the faster keyboards in almost every opportunity i can, i've been amazed by debugging skills (in fairness, i've also been very disappointed many times), i've been bowled over by my faster keyboard's ability to whip out HTML UI's in record time, i've been genuinely impressed by my faster keyboard's ability to flag flaws in PRs i'm reviewing.
All this to say, i see lots of value in faster keyboard's but add all the prompts, skills and hooks you like, explain in as much detail as you like about modularisation, and still "agents" cannot design software as well as a human.
Whatever the underlying mechanism of an LLM (to call it a next token predictor is dismissively underselling its capabilities) it does not have a mechanism to decompose a problem into independently solvable pieces. While that remains true, and i've seen zero precursor of a coming change here - the state of the art today is equiv to having the agent employ a todo list - while this remains true, LLMs cannot design better than humans.
There are many simple CRUD line of business apps where they design well enough (well more accurately stated, the problem is small/simple enough) that it doesn't matter about this lack of design skill in LLMs or agents. But don't confuse that for being able to design software in the more general use case.
Exactly, for the thing that has been done in Github 10000x times over, LLMs are pretty awesome and they speed up your job significantly (it's arguable if you would be better off using some abstraction already built if that's the case).
But try to do something novel and... they become nearly useless. Not like anything particularly difficult, just something that's so niche it's never been done before. It will most likely hallucinate some methods and call it a day.
As a personal anecdote, I was doing some LTSpice simulations and tried to get Claude Sonnet to write a plot expression to convert reactance to apparent capacitance in an AC sweep. It hallucinated pretty much the entire thing, and got the equation wrong (assumed the source was unit intensity, while LTSpice models AC circuits with unit voltage. This surely is on the internet, but apparently has never been written alongside the need to convert an impedance to capacitance!).
> Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me.
They don't do any of that better than me; they do it poorer and faster, but well enough for most of the time.
There will be a need. Don't worry. Most people still haven't figured out how to properly read and interpret instructions. So they build things incorrectly - with or without AI
Seriously. The bar is that low. When people say "AI slop" I just chuckle because it's not "AI" it's everyone. That's the general state of the industry.
So all you have to do is stay engaged, ask questions, and understand the requirements. Know what it is you're building and you'll be fine.
More than any other effect they have LLMs breed something called "learned helplessness". You just listed a few things it may stay better than you at, and a few things that it is not better than you at and never will be.
Planning long running projects and deciding are things only you can do well!! Humans manage costs. We look out for our future. We worry. We have excitement, and pride. It wants you to think none of these things matter of course, because it doesn't have them. It says plausible things at random, basically. It can't love, it can't care, it won't persist.
WHATEVER you do don't let it make you forget that it's a bag of words and you are someing almost infinitely more capable, not in spite of human "flaws" like caring, but because of them :)
Plus I think I've almost never see so little competition for what I think are the real prizes! Everyone's off making copies of copies of copies of the same crappy infrastructure we already have. They're busy building small inconsequential side projects so they can say they built something using an LLM.
Yea I've been seeing very similar behavior from people. They think of themselves as static, unchanging, uncreative but view LLMs as some kind of unrelenting and inevitable innovative force...
I think it's people's anxieties and fears about the uncertainty about the value of their own cognitive labor demoralizing them and making them doubt their own self-efficacy. Which I think is an understandable reaction in the face of trillion dollar companies frothing at the mouth to replace you with pale imitations.
You are still in denial of what an LLM actually is capable of in the near-mid term.
In the current architecture there are mathmatical limitations on what it can do with information. However, tool use and external orchestration allow it to work around many (maybe all) those limitations.
The current models have brittle parts and some bad tendencies.. but they will continue to eat up the executive thought ladder.
I think it is better to understand this and position yourself higher and higher on that chain while learning what are the weak areas in the current generation of models.
Your line of thinking is like hiding in a corner while the water is rising. You are right, it is a safe corner, but probably not for long.
Where the hell was all this fear when the push for open source everything got fully underway? When entire websites were being spawned and scaffolded with just a couple lines of code? Do we not remember all those impressive tech demos of developers doing massive complex thing with "just one line of code"? How did we not just write software for every kind of software problem that could exist by now?
How has free code, developed by humans, become more available than ever and yet somehow we have had to employ more and more developers? Why didn't we trend toward less developers?
It just doesn't make sense. AI is nothing but a snippet generator, a static analyzer, a linter, a compiler, an LSP, a google search, a copy paste from stackoverflow, all technologies we've had for a long time, all things developers used to have to go without at some point in history.
> Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me
Perfect economic substitution in coding doesn't happen for a long time. Meanwhile, AI appears as an amplifier to the human and vice versa. That the work will change is scary, but the change also opens up possibilities, many of them now hard to imagine.
Stop freaking out. Seriously. You're afraid of something completely ridiculous.
It is certainly more eloquent than you regarding software architecture (which was a scam all along, but conversation for another time).
It will find SOME bugs better than you, that's a given.
Review code better than you? Seriously? What you're using and what you consider code review?
Assume I could identify one change broke production and you reviewed the latest commit. I am pinging you and you better answer. Ok, Claude broke production, now what?
Can you begin to understand the difference between you and the generative technology?
When you hop on the call, you will explain to me with a great deal of details what you know about the system you built, and explain decision making and changes over time. You'll tell about what worked and what didn't. You will tell about the risks, behavior and expectations. About where the code runs, it's dependencies, users, usage patterns, load, CPU usage and memory footprint, you could probably tell what's happening without looking at logs but at metrics.
With Claude I get: you're absolutely right! You asked about what it WAS, but I told you about what it WASN'T! MY BAD.
Knowledge requires a soul to experience and this is why you're paid.
We use code rabbit and it's better than practically any human I've worked with at a number of code review tasks, such as finding vulnerabilities, highlighting configuration issues, bad practices, etc. It's not the greatest at "does this make sense here" type questions, but I'd be the one answering those questions anyway.
Yeah, maybe the people I've worked with suck at code reviews, but that's pretty normal.
Not to say your answer is wrong. I think the gist is accurate. But I think tooling will get better at answering exactly the kind of questions you bring up.
Also, someone has to be responsible. I don't think the industry can continue with this BS "AI broke it." Our jobs might devolve into something more akin to a SDET role and writing the "last mile" of novel code the AI can't produce accurately.
Yes, seriously (not OP). Sometimes it's dumb as rocks, sometimes it's frighteningly astute.
I'm not sure at which point of the technology sigmoid curve we find ourselves (2007 iPhone or 2017 iPhone?) but you're doing yourself a disservice to be so dismissive
The AI is pretty scary if you think most of software engineering is about authoring individual methods and rubber ducking about colors of paint and brands of tools.
Once you learn that it's mostly about interacting with a customer (sometimes this is yourself), you will realize the AI is pretty awful at handling even the most basic tasks.
Following a product vision, selecting an appropriate architecture and eschewing 3rd party slop are examples of critical areas where these models are either fundamentally incapable or adversely aligned. I find I have to probe ChatGPT very hard to get it to offer a direct implementation of something like a SAML service provider. This isn't a particularly difficult thing to do in a language like C# with all of the built in XML libraries, but the LLM will constantly try to push you to use 3rd party and cloud shit throughout. If you don't have strong internal convictions (vision) about what you really want, it's going to take you for a ride.
One other thing to remember is that our economies are incredibly efficient. The statistical mean of all information in sight of the LLMs likely does not represent much of an arbitrage opportunity at scale. Everyone else has access to the same information. This also means that composing these systems in recursive or agentic styles means you aren't gaining anything. You cannot increase the information content of a system by simply creating another instance of the same system and having it argue with itself. There usually exists some simple prompt that makes a multi agent Rube Goldberg contraption look silly.
> I’m basically just the conductor of all those processes.
"Basically" and "just" are doing some heroic weight lifting here. Effectively conducting all of the things an LLM is good at still requires a lot of experience. Making the constraints live together in one happy place is the hard part. This is why some of us call it "engineering".
This reads like shilling/advertisement.. Coding AIs are struggling for anything remotely complex, make up crap and present it as research, write tests that are just "return true", and won't ever question a decision you make.
Those twenty engineers must not have produced much.
I think part of what is happening here is that different developers on HN have very different jobs and skill levels. If you are just writing a large volume of code over and over again to do the same sort of things, then LLMs probably could take your job. A lot of people have joined the industry over time, and it seems like the intelligence bar moved lower and lower over time, particularly for people churning out large volumes of boilerplate code. If you are doing relatively novel stuff, at least in the sense that your abstractions are novel and the shape of the abstraction set is different from the standard things that exist in tutorials etc online, then the LLM will probably not work well with your style.
So some people are panicking and they are probably right, and some other people are rolling their eyes and they are probably right too. I think the real risk is that dumping out loads of boilerplate becomes so cheap and reliable that people who can actually fluently design coherent abstractions are no longer as needed. I am skeptical this will happen though, as there doesn’t seem to be a way around the problem of the giant indigestible hairball (I.e as you have more and more boilerplate it becomes harder to remain coherent).
No it doesn’t read like shilling and advertisement, it’s tiring hearing people continually dismiss coding agents as if they have not massively improved and are driving real value despite limitations and they are only just getting started. I’ve done things with Claude I never thought possible for myself to do, and I’ve done things where Claude made the whole effort take twice as long and 3x more of my time. It’s not like people are ignoring the limitations, it’s that people can see how powerful the already are and how much more headroom there is even with existing paradigms not to mention the compute scaling happening in 26-27 and the idea pipeline from the massive hoarding of talent.
I would say while LLMs do improve productivity sometimes, I have to say I flatly cannot believe a claim (at least without direct demonstration or evidence) that one person is doing the work of 20 with them in december 2025 at least.
I mean from the off, people were claiming 10x probably mostly because it's a nice round number, but those claims quickly fell out of the mainstream as people realised it's just not that big a multiplier in practice in the real world.
I don't think we're seeing this in the market, anywhere. Something like 1 engineer doing the job of 20, what you're talking about is basically whole departments at mid sized companies compressing to one person. Think about that, that has implications for all the additional management staff on top of the 20 engineers too.
It'd either be a complete restructure and rethink of the way software orgs work, or we'd be seeing just incredible, crazy deltas in output of software companies this year of the type that couldn't be ignored, they'd be impossible to not notice.
This is just plainly not happening. Look, if it happens, it happens, 26, 27, 28 or 38. It'll be a cool and interesting new world if it does. But it's just... not happened or happening in 25.
My experience is that you get out what you put in. If you have a well-defined foundation, AI can populate the stubs and get it 95% correct. Getting to that point can take a bit of thought, and AI can help with that, too, but if you lean on it too much, you'll get a mess.
And of course, getting to the point where you can write a good foundation has always been the bulk of the work. I don't see that changing anytime soon.
This is completely wrong. Codex 5.2 and Claude Sonnet 4.5 don't have any of these issues. They will regularly tell you that you're wrong if you bother to ask them and they will explain why and what a better solution is. They don't make up anything. The code they produce is noticeably more efficient in LoC than previous models. And yes they really will do research, they will search the Internet for docs and articles as needed and cite their references inline with their answers.
You talk as if you haven't used a LLM since 2024. It's now almost 2026 and things have changed a lot.
I'd be willing to give you access to the experiment I mentioned in a separate reply (have a github repo), as far as the output that you can get for a complex app buildout.
Will admit It's not great (probably not even good) but it definitely has throughput despite my absolute lack of caring that much [0]. Once I get past a certain stage I am thinking of doing an A-B test where I take an earlier commit and try again while paying more attention... (But I at least want to get where there is a full suite of UOW cases before I do that, for comparison's sake.)
> Those twenty engineers must not have produced much.
I've been considered a 'very fast' engineer at most shops (e.x. at multiple shops, stories assigned to me would have a <1 multiplier for points[1])
20 is a bit bloated, unless we are talking about WITCH tier. I definitely can get done in 2-3 hours what could take me a day. I say it that way because at best it's 1-2 hours but other times it's longer, some folks remember the 'best' rather than median.
[0] - It started as 'prompt only', although after a certain point I did start being more aggressive with personal edits.
[1] - IDK why they did it that way instead of capacity, OTOH that saved me when it came to being assigned Manual Testing stories...
Yeah, it makes me wonder whether I should start learning to be a carpenter or something. Those who either support AI or thinks "it's all bullshit" cite a lack of evidence for humans truly being replaced in the engineering process, but that's just the thing; the unprecedented levels of uncertainty make it very difficult to invest one's self in the present, intellectually and emotionally. With the current state of things, I don't think it's silly to wonder "what's the point" if another 5 years of this trajectory is going to mean not getting hired as a software dev again unless you have a PhD and want to work for an AI company.
What doesn't help is that the current state of AI adoption is heavily top-down. What I mean is the buy-in is coming from the leadership class and the shareholder class, both of whom have the incentive to remove the necessary evil of human beings from their processes. Ironically, these classes are perhaps the least qualified to decide whether generative AI can replace swathes of their workforce without serious unforeseen consequences. To make matters worse, those consequences might be as distal as too many NEETs in the system such that no one can afford to buy their crap anymore; good luck getting anyone focused on making it to the next financial quarter to give a shit about that. And that's really all that matters at the end of the day; what leadership believes, whether or not they are in touch with reality.
His logic is off and his experience is irrelevant because i doesn’t encompass scale to have been exposed to an actual paradigm shifting event. Civilizations and entire technologies have been overturned so he can’t say it won’t happen this time.
What we do know is this. If AI keeps improving at the current rate it’s improving then it will eventually hit a point where we don’t need software engineers. That’s inevitable. The way for it to not happen is for this technology to hit an impenetrable wall.
This wave of AI came so fast that there are still stubborn people who think it’s a stochastic parrot. They missed the boat.
As much as my first gut reaction to this article was to be excited about its conclusion, I can’t say my experience matches up. Are LLMs perfect? Absolutely not, but I can point to many examples in my own work where using Codex has saved me easily a week or more—especially when it comes to tedious refactors. I don’t agree with the conclusion; the real-world improvement and progress I’ve seen in the last year in the problem-solving quality of these agents has been pretty astounding.
The reason for my excitement about the conclusion is obvious: I want programmers and people to stay in demand. I find the AI future to be quite bleak if this tech really does lead to AGI, but maybe that’s just me. I think we’re at a pretty cool spot with this technology right now—where it’s a powerful tool—but at some point, if or when it’s way smarter than you or me… I'm not sure that's a fun happy future. I think work is pretty tied to our self worth as humans.
Sure thing. I work on a few projects for my company. The main one is an Android and iOS audiobook-media-player app. I had to update the Android side to use the Google Media3 library instead of the legacy ExoPlayer library. In a typical app this would be pretty straightforward, but we’ve mixed in a lot of custom elements that made the transition quite challenging. I actually attempted it manually back in the day and probably spent three or four days on it, but I simply didn’t have time to finish, so I shelved it. A few months ago I tried again in Codex; within two prompts it was done flawlessly and starting from the beginning.
Another example: I also maintain the back-end API for these apps. There was a lot of old utility code that was messy, unorganized, and frankly gross. I had Codex completely reorganize the code into a sensible folder structure and strip out any functions that weren’t being used anymore—something like 300-plus functions. Doing that by hand would easily have taken a day or more
I could go on, but those were the two initial “aha” moments that showed me how powerful this tool can be when it’s used for the right tasks.
I agree the ELIZA effect is strong, additionally I think it is some kind of natural selection.
I feel like LLM's are specifically selected to impress people that have a lot of influence. People like investors and CEO's. Because a "AI" that does not impress this section of the population does not get adopted widely.
This is one of the reasons I think AI will never really be an expert as it does not need to be. It only needs to adopt a skill (for example coding) to pass the examination of the groups that decide if it is to be used. It needs to be "good enough to pass".
I got this wild idea a short while ago and your comment helped cement it: probably one of the reasons why languages like Lisp are not "successful" has something to do with the impressability factor? If the people with money (and the decision) do not understand the tech or are not able to even fake that understanding, will they bet their money on it?
> Edgar Dijkstra called it nearly 50 years ago: we will never be programming in English, or French, or Spanish. Natural languages have not evolved to be precise enough and unambiguous enough. Semantic ambiguity and language entropy will always defeat this ambition.
This is the most important quote for any AI coding discussion.
Anyone that doesn't understand how the tools they use came to be is doomed to reinvent them.
> The folly of many people now claiming that “prompts are the new source code”,
These are the same people that create applications in MS Excel.
Further evidence: After all these years (far longer than we have been doing programming), we still don't do math in English or French or Spanish. We do it in carefully defined formal notations.
But so many problems (programming, but also physics and math) start as informal word problems. A major skill is being able to turn the informal into something formal and precise.
> These are the same people that create applications in MS Excel.
Ones that want their application to work? :) the last piece of software you should be knocking is MS Excel, in my 30+ year career the one common thread just about everywhere I worked (or contracted at) has used Excel to run some amazing sh*t
Everywhere I've worked as a software engineer the past 30 years I've seen Excel spreadsheets but rarely anything amazing, maybe once back in the 1990's at one place by an Excel guru but those are rare. 00% of the time Excel is used to make essentially table layouts of data maybe with some simple cell calculations.
Excel (or similar spreadsheet programs) is indeed great and has it's place. There are certain area's where there is no real replacement which is impressive. However I think that creating (interactive) applications is not one of the jobs Excel is the best tool for the job.
This exactly the argument I try to make Excel (spreadsheets) is a great interface for processing and working with certain type of data, think economic etc. but it is not great for other things. There we need a different interface to efficiently communicate our intent. For example programming languages or even writing a novel would not work very well in a Excel sheet (though no doubt someone has attempted it).
I think programmets often underestimate the power of Excel for non-programmers, it in practice runs the business world.
I think that it also is a comparable to the ai side we see now.
Do something for real, use real database or programmer.
Non-programmer needs something, vibe code or excel
>WYSIWYG, drag-and-drop editors like Visual Basic and Delphi were going to end the need for programmers.
VB6 and Delphi were the best possible cognitive impedance match available for domain experts to be able to whip up something that could get a job done. We haven't had anything nearly as productive in the decades since, as far as just letting a normie get something done with a computer.
You'd then hire an actual programmer to come in and take care of corner cases, and make things actually reliable, and usable by others. We're facing a very similar situation now, the AI might be able to generate a brittle and barely functional program, but you're still going to have to have real programmers make it stable and usable.
I read a book called "Blood in the machine". It's the history of the Luddites.
It really put everything into perspective to where we are now.
Pre-industrial revolution whole towns and families built clothing and had techniques to make quality clothes.
When the machines came out it wasn't overnight but it wiped out nearly all cottage industries.
The clothing it made wasn't to the same level of quality, but you could churn it out faster and cheaper. There was also the novelty of having clothes from a machine which later normalised it.
We are at the beginning of the end of the cottage industry for developers.
We had "free clothes" for years, decades now. I don't mean cheap I mean literally free, as in $0.0 software. Cheaper software isn't new.
Also there are still clothe designers, fashion runways, and expensive Patagonia vests today. The clothing industry is radically different from back then but it's definitely not gone.
It didn't kill everything. Some survived but not to the extent that it was.
> The clothing industry is radically different from back then but it's definitely not gone.
Small towns had generations of people who had learned skills in making clothing / yarn. To do the work you needed years of experience and that's all you knew.
Once the industrial revolution hit they hired low skilled workers that could be dumped at a moments notice. It made whole villages destitute. Some survived, but the far majority became poor.
That was one industry. We now have AI at a point to wipe out multiple industries to a similar scale.
I posted elsewhere, but you are looking at the wrong part of the chain.
We have cheap (or free) software for large markets, and certain small markets where software developers with hobbies have made something. If every niche that will never be able to afford a large 6-figure custom software could get slop software for an affordable price, then that establishes a foot-hold for working its way up the quality ladder.
Luddism arose in response to weaving machines, not garment-making machines. The machines could weave a piece of cloth that still had to be cut and sewn by hand into a garment. Weaving the cloth was by far the most time consuming part of making the clothing.
Writing code is not at all the most time consuming part of software development.
If you used the car as an analogy instead, it would make more sense to me. There were car craftsmen in Europe that Toyota displaced almost completely. And software is more similar to cars in that it needs maintenance and if it breaks down, large consequences like death and destruction and/or financial loss follows.
If llms can churn out software like Toyota churns out cars, AND do maintenance on it, then the craftsmen (developers of today) are going to be displaced.
I feel like the comments/articles that continue to point out how LLMs cannot solve complex problems are missing a few important points:
1. LLMs are only getting better from here. With each release, we continue to see improvements in their capabilities. And strong competition is driving this innovation, and will probably not stop anytime soon. Much of the world is focused on this right now, and therefore much of the world’s investments are being poured into solving this problem.
2. They’re using the wrong models for the wrong job. Some models are better than others at some tasks. And this gap is only shrinking (see point 1).
3. Even if LLMs can’t solve complex problems (and I believe they can/will, see points 1 and 2), much of our jobs is refactoring, writing tests, and hand coding simpler tasks, which LLMs are undeniably good at.
4. It’s natural to deny LLMs can eventually replace much/all of what we do. Our careers depend on LLMs not being able to solve complex problems so that we don’t risk/fear losing our careers. Not to mention the overall impact to the general way our lives are impacted if AGI becomes a reality.
I’ve been doing this a while, and I’ve never seen the boost to productivity that LLMs bring. Yes, I’ve seen them make a mess of things and get things wrong. But see points 1-3.
> Our careers depend on LLMs not being able to solve complex problems so that we don’t risk/fear losing our careers
I think both this sentiment and the article are on the same wrong track, which is to see programming as solving well defined problems. The way I see it, the job is mostly about taking ill defined needs and turning them into well defined problems. The rest is just writing code. From this perspective, whether LLM prompting can replace writing code is only marginally relevant. It’s automating the easy part.
Also 5: "But LLMs produce a bunch of code I need to read and review".
Yes, but so do your coworkers? Do you complain about every PR you need to read? Are they all compressed diamonds of pure genious, not a single missed character or unoptimised function? Not a bad or suboptimal decision in sight?
If so, shoot me a mail, I want to work where you're working =)
My coworkers do sure. But I don’t have to completely reread what I wrote to grok it. That’s the issue.
You either prompt and read the code it wrote to understand it before making a PR, or you prompt and drop the PR for your team. The latter is disrespectful.
This has been my biggest hurdle so far. Sure the models do great at writing code, find things faster than I would. But time wise I still have to read what it wrote, in depth.
ETA: I also implicitly trust my coworkers. This trust has been built over years. I don’t trust LLM generated code the same way.
I am a long-time software developer too... but I am strongly encouraging people to embrace the future now and get creative in finding ways to adapt.
There will always be demand for smart and creative people. BUT ... if you don't look up and look around you right now at some point you will be irrelevant.
Also see Ray Dalio's "Principles" book on embracing reality. A critical principle in the modern age of AI.
In aviation safety, there is a concept of "Swiss cheese" model, where each successful layer of safety may not be 100% perfect, but has a different set of holes, so overlapping layers create a net gain in safety metrics.
One can treat current LLMs as a layer of "cheese" for any software development or deployment pipeline, so the goal of adding them should be an improvement for a measurable metric (code quality, uptime, development cost, successful transactions, etc).
Of course, one has to understand the chosen LLM behaviour for each specific scenario - are they like Swiss cheese (small numbers of large holes) or more like Havarti cheese (large number of small holes), and treat them accordingly.
LLMs are Kraft Singles. Stuff that only kind of looks like cheese. Once you know it's in there, someone has to inspect, and sign-off on, the entire wheel for any credible semblance of safety.
LLMs are very good at first pass PR checks for example. They catch the silly stuff actual humans just miss sometimes. Typos, copy-paste mistakes etc.
Before any human is pinged about a PR, have a properly tuned LLM look at it first so actual people don't have to waste their time pointing out typos in log messages.
Interesting concept, but as of now we don't apply this technologies as a new compounding layer.
We are not using them after the fact we constructed the initial solution. We are not ingesting the code to compare against specs. We are not using them to curate and analyze current hand written tests(prompt: is this test any good? assistant: it is hot garbage, you are inferring that expected result equals your mocked result).
We are not really at this phase yet. Not in general, not intelligently.
But when the "safe and effective" crowd leave technology we will find good use cases for it, I am certain (unlike uml, VB and Delphi)
> One can treat current LLMs as a layer of "cheese" for any software development or deployment pipeline
It's another interesting attempt at normalising the bullshit output by LLMs, but NO. Even with the entshittified Boeing, the aviation industry safety and reliability records, are far far far above deterministic software (know for a lot of un-reliability itself), and deterministic, B2C software to LLMs in turn is what Boeing and Airbus software and hardware reliablity are for the B2C software...So you cannot even begin to apply aviation industry paradigms to the shit machines, please.
I understand the frustration, but factually it is not true.
Engines are reliable to about 1 anomaly per million flight hours or so, current flight software is more reliable, on order of 1 fault per billion hours. In-flight engine shutdowns are fairly common, while major software anomalies are much rarer.
I used LLMs for coding and troubleshooting, and while they can definitely "hit" and "miss", they don't only "miss".
The biggest threat to American software engineers is outsourcing, AI is just a distraction. I am an immigrant, I work at a prestigious financial corporation in NYC. Pretty much 95% of the staff were born and did undergraduate degree in other countries. We hire a few grads but they usually quit or get laid off after a few years - most new hires are H1Bs or contractors on H1Bs. Just about to open another big office in a developing country.
This time it actually is different.
HN might not think so, but HN is really skewed towards more senior devs, so I think they're out of touch with what new grads are going through.
It's awful.
What is it that new grads are going through? If you are referring to difficulty finding a job, keep in mind that there is both an economic downturn and an over-hiring correction happening in the industry right now. I imagine the AI industry is indeed having an impact in how management is behaving, but I would not yet bet on AI actually replacing developers jobs holistically.
I can talk about my own experiences.
About a year and half ago I dropped everything to get into tech, a couple years out from completing my civil engineering degree because I hated it.
I worked very intensely day in day out building many projects, and I had one project go extremely viral, changing my life.
That led to me getting hired at a small AI start up, where I learned an enormous amount, but 9 months later, I still got let go as work had dried up for the product I was working on. Not much I was able to do there unfortunately.
Still, I really do believe that due to AI there was just far less work that I could meaningful contribute to, speaking as someone who is more junior in the field. Little bug fixes here and there, organization, grunt work tasks, etc - those are completely automated now.
The rungs on the ladder of meaningful progression are growing increasingly wider as eac day goes by.
A decade ago I think big tech companies would be fighting to get me on board, but now it's different,
That said, to end this comment on some silver lining - I know someone who currently works at a big lab who got an enormous amount of work xp by contributing on OSS projects till he became more senior, so maybe there's more to it.
Also one other thought - companies will still have job postings for juniors because a "junior" can be an MIT IOI gold medalist.
I think the only thing we can say about the future of LLMs is “we don’t know.” Everything is changing too fast. Models from a year ago are already obsolete. We seem to be hitting the top of an asymptote on improvements, but things have not been steady state for long enough to know. I also agree with the author that the VC money is driving all of this, and at some point the check is going to come due.
This thread is full of antidotes from “AI is useless for me” to “AI changes everythingfor me” I believe each and every one of them.
The way I see it, the problem with LLMs is the same as with self-driving cars: trust.
You can ask an LLM to implement a feature, but unless you're pretty technical yourself, how will you know that it actually did what you wanted? How will you know that it didn't catastrophically misunderstand what you wanted, making something that works for your manual test cases, but then doesn't generalize to what you _actually_ want to do?
People have been saying we'll have self-driving cars in five years for fifteen years now. And even if it looks like it might be finally happening now, it's going glacially slow, and it's one run-over baby away from being pushed back another ten years.
People used to brush away this argument with plain statistics. Supposedly, if the death statistics is below the average human, you are supposed to lean back and relax. I never bought this one. Its like saying LLMs write better texts then the average huamn can, so you are supposed to use it, no matter how much you bring to the table.
The self driving car analogy is a good one, because what happens when you trust the car enough to do most of your driving but it suddenly thrusts the controls upon you when it shits the bed and can't figure out what to do?
You suddenly realise you've become a very rusty driver in a moment that requires fast recall of skill, but your car is already careening off a cliff while you have this realisation.
[The "children of the magenta line"](https://www.computer.org/csdl/magazine/sp/2015/05/msp2015050...) is a god explanation of this, and is partly why I often dissuade junior devs from pretty user friendly using tools that abstract away the logic beneath them.
Just like the pro-AI articles, it reads to me like a sales pitch. And the ending only adds to it: the author invites to hire companies to contract him for training.
I would only be happy if in the end the author turns out to be right.
But as the things stand right now, I can see a significant boost to my own productivity, which leads me to believe that fewer people are going to be needed.
When coal powered engines became more efficient, demand for coal went UP. It went up because vastly more things could now be cost effectively be coal-powered.
I can see a future where software development goes the same way. My wife works in science and I see all kinds of things in a casual observation of her work that could be made more efficient with good software support. But not by enough to pay six-figures per year for multiple devs to create it. So it doesn’t get done and her work and the work of tens of thousands like her around the world is less efficient as a result.
In a world where development is even half as expensive, many such tasks become approachable. If it becomes a third or quarter as expensive, even more applications are now profitable.
I think far more people will be doing something that creates the outcomes that are today created by SWEs manually coding. I doubt it will be quite as lucrative for the median person doing it, but I think it will still be well above the median wage and there will be a lot of it.
Many HN users may point to Jevons paradox, I would like to point out that it may very well work up until the point that it doesn't. After all a chicken has always seen the farmer as benevolent provider of food, shelter and safety, that is until of course THAT day when he decides he doesn't.
I agree with you on this feeling like a sales pitch, probably because ultimately it is. I've done a software training course led by this guy. It was fine, and his style and his lessons are all pretty decent and I found/find myself agreeing with his "takes". But it's nothing ground breaking, and he's not really adding anything to the debate that I've not read before.
I don't know how active he is as a developer, I assumed that he was more of a teacher of established practices than being on the cutting edge of development. That's not an insult, but it stands out to me in this article.
Ironically, like an LLM, this article feels like more like an amalgamation of plenty of other opinions on the growth of AI in the workplace rather than any original thoughts. There's not really anything "new" here, just putting together a load of existing opinions.
(I am not suggesting that Jason got an AI to write this article, though that would be funny).
As someone having watched AI systems being good enough to replace jobs like content creation on CMS, this is being in denial.
Yes software developer are still going to be need, except much fewer of us, exactly like fully automated factories still need a few humans around, to control and build the factory in first place.
Am puzzled why so many on HN cannot see this. I guess most users on HN are employed? Your employers - let me tell you - are positively salivating at the prospect of firing you. The better LLM's get the fewer of you will be needed.
Denial, like those factory workers at the first visit from the automation company, each one hoping they are the ones elected to stay and overwatch the robots.
I have seen projects where translator teams got reduced, asset creation teams, devops head count, support teams on phone lines,...
It is all about how to do more with less, now with AI help as well.
> The hard part of computer programming isn't expressing what we want the machine to do in code. The hard part is turning human thinking -- with all its wooliness and ambiguity and contradictions -- into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
> That was the hard part when programmers were punching holes in cards. It was the hard part when they were typing COBOL code. It was the hard part when they were bringing Visual Basic GUIs to life (presumably to track the killer's IP address). And it's the hard part when they're prompting language models to predict plausible-looking Python.
> The hard part has always been – and likely will continue to be for many years to come – knowing exactly what to ask for.
I don't agree with this:
> To folks who say this technology isn’t going anywhere, I would remind them of just how expensive these models are to build and what massive losses they’re incurring. Yes, you could carry on using your local instance of some small model distilled from a hyper-scale model trained today. But as the years roll by, you may find not being able to move on from the programming language and library versions it was trained on a tad constraining.
Some of the best Chinese models (which are genuinely competitive with the frontier models from OpenAI / Anthropic / Gemini) claim to have been trained for single-digit millions of dollars. I'm not at all worried that the bubble will burst and new models will stop being trained and the existing ones will lose their utility - I think what we have now is a permanent baseline for what will be available in the future.
The first part is surely true if you change it to "the hardEST part," (I'm a huge believer in "Programming as Theory Building"), but there are plenty of other hard or just downright tedious/expensive aspects of software development. I'm still not fully bought in on some of the AI stuff—I haven't had a chance to really apply an agentic flow to anything professional, I pretty much always get errors even when one-shotting, and who knows if even the productive stuff is big-picture economical—but I've already done some professional "mini projects" that just would not have gotten done without an AI. Simple example is I converted a C# UI to Java Swing in less than a day, few thousand lines of code, simple utility but important to my current project for <reasons>. Assuming tasks like these can be done economically over time, I don't see any reason why small and medium difficulty programming tasks can't be achieved efficiently with these tools.
Indeed, while DeepSeek 3.2 or GLM 4.7 are not Opus 4.5 quality, they are close enough that I could _get by_ because they're not that far off, and are about where I was with Sonnet 3.5 or Sonnet 4 a few months ago.
I'm not convinced DeepSeek is making money hosting these, but it's not that far off from it I suspect. They could triple their prices and still be cheaper than Anthropic is now.
> claim to have been trained for single-digit millions of dollars
Weren't these smaller models trained by distillation from larger ones, which therefore have to exist in order to do it? Are there examples of near state of the art foundation models being trained from scratch in low millions of dollars? (This is a genuine question, not arguing. I'm not knowledgeable in this area.)
Both of those were frontier models at the time of their release.
Another interesting number here is Claude 3.7 Sonnet, which may people (myself included) considered the best model for several months after its release and was apparently trained for "a few tens of millions of dollars": https://www.oneusefulthing.org/p/a-new-generation-of-ais-cla...
maybe not the MOST valuable part of prompting an LLM during a task, but one of them, is defining the exact problem in precise language. i dont just blindly turn to an LLM without understanding the problem first, but i do find Claude is better than a cardboard cutout of a dog
I am good at software. It turns out that isn’t sufficient, or alternatively stated, you have to be good at a number of other things than just churning code, even good code. So to me, the combination of being good at software, understanding complexity and ability articulate it concisely and precisely, when combined with the latest and greatest LLMs, is magic. I know people want to examples of success, I wish I could share what we are working on, but it is unbelievable how much more productive our team is, and I promise, we are solving novel problems, some that have not been tackled yet, at least not in any meaningful way. And I am having time of my life doing what I love, coding. This is not to downplay folks who are having a hard time with LLMs or agents, I think, it’s a skill that you can learn, if you are already good at software and the adjacencies.
> This is not to downplay folks who are having a hard time with LLMs or agents, I think, it’s a skill that you can learn, if you are already good at software and the adjacencies.
Someone on the page already quoted Dijkstra, recommend reading that, he was correct.
Prompt engineering isn't engineering at all, it's throwing words at a wall to see which ones stick then declaring success if the outcome looks at all recognizable. That isn't actually success.
The more articles written like this only reflect the inevitable. This is not an era of slow progress which may have supported the authors opinion. This era is a rapid replacement of what was once dominated by masters of one who edged out others and arrogantly tried to hold onto their perceived positions of all knowing. There will always be those types unfortunately, but when the masters of one realize theyve wasted time stalling the inevitable, instead of accepting and guiding the path forward and opening the door to a broader audience, you will see a lot more articles like this which are a clear signal to many of us that theyre simply doing and saying too much trying to hold on to their perceived worth.
The bit about drag-and-drop and Visual Studio hides a key insight: insofar as those tools allowed non-software engineers to build applications that were key to certain business processes, they were tech-debt accelerators. It is true to a very large degree; there are still businesses out there depending on shoddy VB applications that were built by someone that didn't know what they were doing, and they are hobbled by it. LLM-generated applications are the turbocharged equivalent of this, and I anticipate that giant spagehetti codebases will be made out of them, the likes of which have never been seen before, and the workflows that are wedded to them will be doomed.
Edgar Dijkstra called it nearly 50 years ago: we will never be programming in English, or French, or Spanish. Natural languages have not evolved to be precise enough and unambiguous enough. Semantic ambiguity and language entropy will always defeat this ambition.
I don’t think that’s actually what Dijkstra was saying, nor do I think it stands to reason.
Assuming that product designers articulate their designs in English to software engineers, who subsequently turn those ideas into products, doesn’t it stand to reason that this process is to some degree approachable?
I’m not saying that we are at that point or that we will be soon, but it just seems like flawed reasoning.
I see it as pure deterministic logic being contaminated by probabilistic logic at higher layers where human interaction happens. Seeking for human comfort by forcing computers to adapt to the human languages. Building adapters that can allow humans to stay in their comfort zone instead of dealing with the sharp-edged computer interfaces.
At the end, I don't see it going beyond being a glorified form-assistant who can search internet for answers and summarize. That boils down to chat bots that will remain and become part of every software component that ever need to interface with humans.
Agent stuff is just a fluff that is providing hype-cushion around chat bots and will go away with hype cycle.
This is the usual „but they can’t do the hard stuff“ argument. It’s not the right lens - at least not for employment.
If you need three programmers to deliver a project, one doing boilerplate, one intermediate and one doing hard task. And the AI can’t do the hard task then you’ve still got two unemployed dudes.
So yeah you can make the technically correct argument that it still needs a programmer but it glosses over the coming storm in real world job market.
The only other option to square that circle is to assume that A) we suddenly need 3x as much projects and B) boilerplate guy can somehow graduate to hard tasks
One thing that many of these kinds of articles don't really talk about but that also emphasizes their point is that there will be an increase in interfaces/languages for software developers to do increasingly specialized for work. As such, there will be more compilers, vms, dsls, etc which means that there will be more of a demand for developers who have this skillset. Ideally, this should lead to more folks becoming developers or at least acquiring skills that professional developers have in order to make effective use of these tools.
My counterargument for that is that LLMs need to communicate not only between themselves and humans but LLM to LLM communication. We will get more niche and domain specific languages designed for LLMs as a result.
The future of software development is systems analysts.
It was discovered in the 1970s (at the latest) that the hard part of software is figuring out WHAT to build not HOW to build it—and the two should be separate responsibilities with separate personnel bearing separate talents. (Do NOT let your programmers do systems analysis!)
Furthermore, it was discovered that without a clear, precise description of what to build, even the most talented programmers will happily use industry best practice to build the wrong thing, and that is worse than useless: it's a net cost to the business. This is something that programmers have in common with LLMs. So it turns out, in order to build software correctly and cost-effectively, you need to perform lots of systems analysis up front, then through a stepwise refinement process design and document your solution, yielding a detailed spec. It also turns out that LLMs, like human programmers, do just fine if you give them a detailed spec and hold them accountable to that spec!
So much of the "grunt work" of programming can be handed to the LLM—IF you perform the necessary systems analysis up front to determine what needs to be built! (Bryce's Law: Programming is a translation function, taking human-readable requirements to machine-executable instructions.)
As the AI era matures we are either going to see a revival of PRIDE—the original and still most complete software development methodology, but minus the programmers Milt and Tim Bryce loathed so much—or the entire collapse of software as a field.
Playing devil's advocate here. My main take with the responses here is that the naysayers are assuming that the current capabilities of models will remain fixed for the next 1-2 decades which is questionable. They are saying that AI (now or in the future) won't eat a good chunk of my career opportunities because AI now isn't good now. That's the wrong viewpoint.
My views:
- Developers are expensive
- Most development isn't that hard or that creative
- LLMs can already do some of the sub tasks that the above kind of development entails
- If the above kind of development disappears, then there is only the harder, creative kind of development left
- Less development jobs and more developers will reduce dev salaries and increase dev competition regardless of the kind of development that you do. Any such change will be fairly slow and gradual
- The 2010s Everyone Can Code era is gone and is not going to come back as a result of the above
there's a huge flaw in the logic here but I can't pinpoint it
we've never had machines that can reason. today, they reason badly. tomorrow, they'll reason better. not all ai research white papers will pan out, but some will. the ai research community is acutely aware of the limitations in reasoning; it's their whole mission right now. 100% chance someone will make progress. Analogous to the chip industry or self driving, in that regard
incremental improvements in reasoning will broaden the dead zone for human developers
what difference does it make if in 20 years NASA still needs a few human developers but the rest of us are unemployed? ai agents still can't get you to the moon with one shot coding session in 2045? who cares?
the "still can't" we really need to be worried about is "politicians still can't consider UBI"
There is a guaranteed cap on how far LLM based AI models can go. Models improve by being trained on better data. LLMs being used to generate millions of lines of sloppy code will substantially dilute the pool of good training data. Developers moving over to AI based development will cease to grow and learn - producing less novel code.
The massive increase in slop code and loss of innovation in code will establish an unavoidable limit on LLMs.
Maybe we'll train the llms in our ways of using them, and the next generation of coding assistants will be another layer inbetween us and the code. You talk to the chief engineer llm who in turn talks to its cadre of claude code instances running in virtual tmux. \hj?
But they're not just training off code and its use, but off a corpus general human knowledge in written form.
I mean, in general not only do they have all of the crappy PHP code in existence in their corpus but they also have Principia Mathematica, or probably The Art of Computer Programming. And it has become increasingly clear to me that the models have bridged the gap between "autocomplete based on code I've seen" to some sort of distillation of first order logic based on them just reading a lot of language... and some fuzzy attempt at reasoning that came out of it.
Plus the agentic tools driving them are increasingly ruthless at wringing out good results.
That said -- I think there is a natural cap on what they can get at as pure coding machines. They're pretty much there IMHO. The results are usually -- I get what I asked for, almost 100%, and it tends to "just do the right thing."
I think the next step is actually to actually make it scale and make it profitable but also...
fix the tools -- they're not what I want as an engineer. They try to take over, and they don't put me in control, and they create a very difficult review and maintenance problem. Not because they make bad code but because they make code that nobody feels responsible for.
That is a naive assumption. Or rather multiple naive assumptions: Developers mostly don’t move over to AI development, but integrate it into their workflow. Many of them will stay intellectually curious and thus focus their attention elsewhere; I’m not convinced they will just suddenly all stagnate.
Also, training data isn’t just crawled text from the internet anymore, but also sourced from interactions of millions of developers with coding agents, manually provided sample sessions, deliberately generated code, and more—there is a massive amount of money and research involved here, so that’s another bet I wouldn’t be willing to make.
I don’t recall seeing entire economies betting on 4GLs.
Not even a nitpick because the scale is indeed orders of magnitude different, but…
There was a lot of chatter, government attention, and both public and private money chasing 4GL’s in the 1980’s, due to what turned out to be (for the US, at least) a phantom “software crisis”. It was mostly for naught?
Same in Japan, where you can argue about the motivations of MITI’s “Fourth Generation Project”, but at its software core was a primeval 4GL in the form of Prolog. Their perceptions of a Japanese software crisis were ultimately more well-founded.
I have been programming professionally (i.e., getting paid for it) for a much more modest 13 years, but unlike a quite large portion of my peers, I am actually interested in the history of our field.
‘Obviously’ AI and programming are antonyms. AI is defined as the ability for computers to do whatever it is that humans can do that (most) computers can't currently do. Conversely, ‘programming’ is whatever activity is required to fully take advantage of computer hardware that (most) humans can't currently do.
Both sets of goalposts are firmly affixed to their wheels :)
I did a bit of scripting trying to automate the TDD cycle given a task description. The problem is, that the LLM tends to jump forward and submit a full implementation instead of a minimal change. I guess the problem is, that LLMs are trained on complete solutions instead of minimal steps.
I really wonder why people aren't drawing comparisons with crypto/blockchain. In the beginning, there were also two camps: people who thought crypto would replace our entire financial system and everything would be tokenized on the blockchain, and another camp who predicted that within a few years bitcoin would be worth exactly zero and all crypto/blockchain companies would disappear.
The reality turned out to be somewhere in the middle. Crypto didn't replace our financial system, but it exists as a 1-2 trillion dollar segment serving a particular (though controversial) niche of the global economy. It's not going to zero anytime soon.
I think AI/LLMs will follow the same path. There's definitely a level of usefulness there. But we've clearly hit a ceiling since 3.5/4.0. Advancement has only happened in benchmarks and open source models. Also, the idea that a neural net that accepts a fixed amount of padded tokens and returns a list of probabilities will replace the complexities of the human brain is delusional at best.
The only real issue I see is that certain actors in the US have taken such large positions that unwinding them could potentially destroy the US economy at worst, or trigger a recession at best. But this mainly concerns the US, which is on an AI high at the moment.
Here’s how I see it. Writing code or building software well requires knowledge of logic, data structures, reliable messaging, and separation of concerns.
You can learn a foreign language just fine, but if you mangle the pronunciation, no one will talk to you. Same thing with hacking at software without understanding the above elements. Your software will be mangled and no one will use it.
the quality of how maintainable the source code is has no bearing on how a user perceives the software's usefulness.
If the software serves a good function for the user, they will use it, regardless of how badly the datastructures are. Of course, good function also means reliability from the POV of the user. If your software is so bad that you lose data, obviously no one will use it.
But you are conflating the maintainability and sensibilities of clean tools, clean code and clean workspaces, with output.
A messy carpentry workshop can still produce great furniture.
Totally delusional. The article does not even try to figure out why any of this happened.
In all of the cases the main prediction that was made came true. The cost, especially the human cost, of developing some piece of software dramatically decreased. The only reason why the amount of programmers needed still rose was because the amount of software needed rose faster.
Clearly that trend will not hold forever.
>The hard part of computer programming isn’t expressing what we want the machine to do in code. The hard part is turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
And there is exactly one single technology which has ever been able to do this task, which is LLMs. Not addressing the elephant in the room, which is that an LLM can actually take such instructions and produce something meaningful with it, just makes the whole article worthless.
Everything in this article is just inverse special pleading. Since the last N times, the most enthusiastic predictions did not come true, this time only minor changes can happen. If LLMs are only a revolution on the scale of fast interpreted languages (which have significantly impacted what a small team is capable of delivering in terms of complexity), then they will drastically impact most of the software industry.
If these changes happen, and simultaneously the rate at which software is demanded does not also increase (why would it?), then the implications will be extremely serious. Especially if you are not a developer in an established position.
In past cases of automation, quantity was the foot-in-the-door and quality followed. Early manufactured items were in many cases inferior to hand-built items, but one was affordable and the other not.
Software is incredibly expensive and has made up for it with low marginal costs. Many small markets could potentially be served by slop software, and it's better than what they would have otherwise gotten (which is nothing).
This blurb is the whole axiom on which the author built their theory. In my opinion it is not accurate, to say the least. And I say this as someone who is still underwhelmed by current AI for coding.
The future of IT is going back to basics. People who know their karnough diagrams, their algorithm flow charts, memory models, state machines, algorithms, their sql CTEs, window functions, their obscure cpu/gpu instructions, people who can build a VM and a language on top from ground up will become even more valuable, because they can drive LLMs more effectively.
Your run of the mill bootcamp webdev/data scientists will have to educate themselves or find manual jobs.
> The foreseeable future of software development is one where perhaps “AI” – in a much more modest form (e.g., a Java coding assistant built atop a basic language model) – is used to generate prototypes, and maybe for inline completion on production code and those sorts of minor things.
This...
I have said this in multiple other comments and I 100% agree with the author's take.
I feel like AI can be good for prototyping sometimes but that's about it.
The reason is simple but I just don't trust AI system from not breaking given their volatile nature and I wouldn't expect to be paying for AI generated code that much/zero to be honest
And I will treat other people the same way I wish to be treated (golden rule) so why would I use AI when I can do things by my hand? (There are also 1000's of other discussions I can point in the moral,financial,even technological impacts of the whole situation)
That being said, prototyping as author pointed out feels the only good use to me because at that point you are building it for yourself or a small community. I think a good use of AI can be to build open source prototypes of softwares and if you really like something, one can rebuild it or build it the way they like it as an example.
Prototyping can be similar to the drag n drop and other things and honestly wordpress did reduce the number of programmers needed to maintain a website and for good measure, I think AI is similar to this then anything else and even then small models will win as author states and so the financial point of these companies training these usually becomes moot.
So till the time being, I use these free/subsidized websites to get prototypes to be generated but I feel as if long term, I can find projects which heavily resonate with me and I can build them/learn languages catered to them and build my mental model of thinking around them
Although I must admit, prototyping using AI models definitely gives me Imposter syndrome and I sometimes feel that perhaps its a learning opportunity and that I can perhaps instead spend hours but I don't really know too much about it so its something that I am figuring out as we speak
Like there is this feeling that I can spend more hours and feel more "proud" of what I did if I did it without AI than if I did with AI since perhaps the journey matters too. I really don't know but just weighing all my thoughts on the matter as I thought about it really closely once.
Edit: although I am not sure about calling AI wordpress-like since then it would mean that I am giving significance to AI similar to wordpress, honestly I respect wordpress more but not sure, perhaps they are similar, perhaps they are not, I don't really know perhaps but what I do know is that the financial impact of the AI bubble is gonna impact all of us negatively.
Most people in this thread are quibbling about the exact degree of utility LLMs provide, which a tedious argument.
What's more interesting to me is, per the article, the concern regarding everyone who is leaning into LLMs without realizing (or downplaying) the exorbitant, externalized cost. Our current LLM usage is being subsidized to the point of being free by outside investment. One day when the well runs dry, you must be able to either pay the actual cost (barring grand technology breakthroughs), or switch back to non-LLM workflows. I run local LLMs infrequently, and every single prompt makes my beefy PC sounds like a jet engine taking off. It's a great reminder to not become codependent.
As someone who works on the design and construction of datacenters, I cannot stress enough how apropos this comment is. Even before the first conversation in your IDE starts, the load on national and local government resources, local utility capacity, and roadway infrastructure is enormous. We're all paying whether we're using the tools or not.
Nearly nobody cares about the load on “national and local government resources, local utility capacity, and roadway infrastructure” for any other day-to-day activity. Why should they care about the same for AI which for most people is “out there online” somewhere? Related my, crypto bros worried about electricity usage only so far as its expense went and whether they could move closer to hydro dams.
10 replies →
I always liken it to using Uber in ~2012. It was fun to get around major metro areas for dirt cheap. But then prices rose dramatically over the next decade+ as the company was forced to wean itself off of VC subsidies.
It’s common since year dot fir new businesses to compete on price to attract customers and gain market share. It wasn’t invented by uber
Same with Airbnb. Oh and Moviepass. Those were the days.
5 replies →
... and people kept using Uber.
4 replies →
There's a lot in this comment that doesn't exactly fit.
First of all, there could be other solutions, such as B2B subsidizing individual user plans, or more fine grained model tiering per cost.
Also, yes you can get some access for free, but even today the higher tiers of proprietary models is around $200/mo for individual users, which might still be subsidized but is definitely not free, and is quite a chunk of money at $2400 a year!
I don't know what your setup is at the moment, but it's possible more efficient hardware and stack are available that you're not utilizing. Of course this depends on what models you're trying to run.
I think that smaller models will become a lot better, and hardware will become more optimized as well. We're starting to see this with NPUs and TPUs.
All this means running models will cost less, and maybe upgrading the power grid will also reduce cost of energy, making it more affordable.
I don't see any way that AI will go away because it "hits a wall". We have long passed the point of no return.
You are looking at it from the individual's PoV, but the OP is using the bird view from high above. It is the total amount of effort deployed today already to provide all the existing AI services, which is enormous. Data centers, electricity, planning/attention (entities focused on AI have less time to work on something else), components (Nvidia shortage, RAM shortage), etc.
This is not about finance, but about the real economy and how much of it, and/or its growth, is diverted to AI. The real economy is being reshaped, influencing a lot of other sectors independent of AI use itself. AI heavily competes with other uses for many kinds of actual real resources - without having equally much to show for it yet.
Just an example: https://www.technologyreview.com/2025/05/20/1116327/ai-energ... (it is worth skip-reading it all, the headline on its own is useless)
This is a good point but you can see the price "ceiling" by examining the prices for PCs that can effectively run local models. A DGX Spark is ~$4k (plus power) for example.
That's not nothing, but it's still not very much to pay compared to e.g. the cost of a FTE.
You're counting the cost of running the model, but what about training it? You can't count the compute and data costs at $0.
7 replies →
That can't come anywhere close to running the current SotA models, though.
1 reply →
I find the cost discussion to be exceedingly more tedious. This would be a more compelling line of thinking if we didn't have highly effective open-weight models like qwen3-coder, glm 4.7 etc. which allow us to directly measure the cost of running inference with large models without confounding factors like VC money. Regardless of the cost of training, the models that exist right now are cheap and effective enough to push the conversation right back to "quibbling about the exact degree of utility LLMs provide".
>I run local LLMs infrequently, and every single prompt makes my beefy PC sounds like a jet engine taking off. It's a great reminder to not become codependent.
I would try setting the GPU to run at a lower power level. I set my GPU power level to 80% and it becomes much quieter, and only runs maybe 5% slower at most.
Also I 100% agree with the rest of your comment. We can only power the current growth we are seeing for so long.
LLMs cannot generate coherent sentences
LLMs writing prose is too robotic
LLMs output is too dependent on prompts to be interesting
LLMs take too much RAM to run effectively
LLMs take too much electricity to run locally
LLMs work locally but are a bit too slow for my taste
LLMs output mostly correct code but it isn't applicable to my codebase
LLMs make tool calls to pull in additional context
LLMs outputted code works for most developers but not my codebase <---- you are currently here
isn't this template supposed to mean that all the previous considerations are now obsolete?
1 reply →
So what'll happen to all these companies building on top of openai license. I don't hear these warnings in professional circles, only online
A competitive coding like devstral 2 runs fast enough to be very helpful: https://www.hardware-corner.net/devstral-2-hardware-requirem...
The required hardware is fits the budget for a professional developer.
Putting LLMs in the cloud allows the hardware to be utilised better and to have sharding of big models.
> One day when the well runs dry, you must be able to either pay the actual cost
What multiple of the current cost do you expect? Currently, GitHub Copilot and ChatGPT for Business cost $19/month and €29/month respectively. Even a 10×–20× increase will still be economically viable in a professional setting if the tools continue to save hours of work.
These tools (e.g. Chatgpt pro) lose money at $200/month
So expect, maybe, $1000 a month? Until your business is dependant on these LLMs. Then they can extract basically all your margin lol
1 reply →
Claude max is like $100/mo, and if you’re a daily user you’re likely going to need max
Remember when Uber was cheap and showed you the surge pricing multiple?
The cost is coming down fast. You can get a $2000 desktop machine (AMD 395) that can run effectively chatGPT 3.5 levels of LLMs at over 100 tokens per second.
if you wrote this comment 70 years ago when computers were the size of rooms, it would make a lot of sense, and yet we know how history played out where everyone has a super computer in their pocket.
for some reason it feels like people are under the assumption that hardware isnt going to improve or something?
Writing my comment on this post, I kind of feel like LLM's are like similar to wordpress/drag and drop tool although its more inconsistent too perhaps not sure
I 100% share the codependent path too and had written a similar comment some 2-3 days ago but these AI companies which provide are either seriously negative/loss making subsidizing or they are barely net zero. I doubt that it will continue and so the bubble will burst I guess and prices of these will rise perhaps
We will see perhaps something like google which can feed on advertising can perhaps still provide such subsidies for a longer time but the fact of the matter is that I have no alleigance to any model as some might have and I will simply shift to the cheapest thing which can still provide me / be enough for my queries or prototypes mostly I suppose.
I am sorry, but this kind of level-headed and realistic take is completely unacceptable on hackernews, and you should be ashamed of yourself. This is not a place for rational discussion when it comes to LLMs.
LLMs are amazing and they will change everything, and then everything will be changed.
After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
LLMs pretend to do this with big confidence and fail miserably.
For every problem I need to turn my brain to ON MODE and wake up, the LLM doesn't wake up.
It surprised me how well it solved another task: I told it to set up a website with some SQL database and scripts behind it. When you click here, show some filtered list there. Worked like a charm. A very solved problem and very simple logic, done a zillion times before. But this saved me a day of writing boilerplate.
I agree that there is no indication that LLMs will ever cross the border from simple-boilerplate-land to understanding-complex-problems-land.
And I can confirm, with similar years of experience, that they are not useless.
Absolutely incredible tools that have saved hours and hours helping me understand large codebases, brainstorm features, and point out gaps in my implementation or understanding.
I think the main disconnect in the discourse is that there are those pretending they can reliably just write all the software, when anyone using them regularly can clearly see they cannot.
But that doesn't mean they aren't extremely valuable tools in an engineer's arsenal.
Same. I started coding before hitting puberty, and Im well into my 30s.
If you know the problem space well, you can let LLMs(I use Claude and ChatGPT) flesh it out.
2 replies →
I feel like I have to be strategic with my use of claude code. things like frequently clearing out sessions to minimize context, writing the plan out to a file so that I can review it more effectively myself and even edit it, breaking problems down into consumable chunks, attacking those chunks in separate sessions, etc. it's a lot of prep work I have to do to make the tool thrive. that doesn't mean it's useless, though.
"real programming"
Perhaps you're doing some amazing low-level work, but it feels like you're way overestimating how much of our industry does that. A massive amount of developers show up to work every day and just stitch together frameworks and libraries.
In many ways, it feels similar to EVs. Just because EVs aren't yet, and may never be, effective to moving massive amounts of cargo in a day with minimal refueling, doesn't mean that they aren't an effective solution for the bulk of drivers who have an average commute of 40 miles a day.
> After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming
This is a bit of no-true-scottsman, no? For you "real programming" is "stuff LLMs are bad at," but a lot of us out in the real world are able to effectively extract code that meets the requirements of our day jobs from tossing natural language descriptions into LLMs.
I actually find the rise of LLM coding depressing and morally problematic (re copyright / ownership / license laundering), and on a personal level I feel a lot of nostalgia for the old ways, but I simply can't levy an "it's useless" argument against this stuff with any seriousness.
I only use it sparingly thus far, and for small things, but I don't find it depressing at all - but timely.
All those many, many languages, frameworks, libraries, APIs and there many many iterations, soooo much time lost on minute details. The natural language description, even highly detailed down to being directly algorithmic, is a much better level for me. I have gotten more and more tired of coding, but maybe part of it is too much Javascript and its quickly changing environment and tools, for too many years (not any more though). I have felt that I'm wasting way too much time chasing all those many, many details for quite some time.
I'm not pro-high-level-programming per se - I started a long time ago with 8 bit assembler and knowing every one of the special registers and RAM cells. I cherish the memories of complex software fitting on a 1.44 MB floppy. But it had gotten just a bit too extreme with all the little things I had to pay attention to that did not contribute to solving the actual (business) problem.
I feel it's a bit early even if it's already usable, but I hope they can get at least one more giant leap out of AI in the next decade or so. I am quite happy to be able to concentrate on the actual task, instead of the programming environment minutiae, which has exploded in size and complexity across platforms.
"they are completely useless for real programming"
You and I must have completely different definitions of "real programming". In this very comment, you described a problem that the model solved. The solution may not have involved low-level programming, or discovering a tricky bug entrenched in years-worth of legacy code, but still a legitimate task that you, as a programmer, would've needed to solve otherwise. How is that not "real programming"?
I wouldn't describe the LLM's actions in the example as "solving a problem" so much as "following a well-established routine". If I were to, for instance, make a PB&J sandwich, I wouldn't say that what I'm doing is "real cooking" even if it might technically fit the definition.
If an LLM controlling a pair of robot hands was able to make a passable PB&J sandwich on my behalf, I _guess_ that could be useful to me (how much time am I really saving? is it worth the cost? etc.), but that's very different from those same robo-hands filling the role of a chef de cuisine at a fine dining restaurant, or even a cook at a diner.
3 replies →
"real programming" hits a "true scottsman" snare with me.
People are saying Codex 5.2 fullsolved crypto challenges in 39C3 CTF last weekend.
Three months ago I would have agreed with you, but anecdotal evidence says Codex 5.2 and Opus 4.5 are finally there.
You'll get a vastly different experience the more you use these tools and learn their limitations and how you can structure things effectively to let them do their job better. But lots of people, understandably, don't take the time to actually sit down and learn it. They spend 30 seconds on some prompt not even a human would understand, and expect the tooling to automatically spend 5 hours trying its hardest at implementing it, then they look at the results and conclude "How could anyone ever be productive with this?!".
People say a lot of things, and there is a lot of context behind what they're saying that is missing, so then we end up with conversations that basically boil down to one person arguing "I don't understand how anyone cannot see the value in this" with another person thinking "I don't understand how anyone can get any sort of value out of this", both missing the other's perspective.
1 reply →
I've been using Codex and Claude Sonnet for many months now for personal (Codex) and work (Sonnet) and I agree. Three months ago these tools were highly usable, now with Codex 5.2 and Sonnet 4.5 I think we're at the point where you can confidently rely on them to analyze your repo codebase and solve, at the very least, small scoped problems and apply any required refactor back throughout the codebase.
6-12+ months ago the results I was getting with these tools were highly questionable but in the last six months the changes have been pretty astounding
5 replies →
It’s crazy how different my experience is. I think perhaps it’s incredibly important what programming language you are using, what your project and architecture is like. Agents are making an extraordinary contribution to my productivity. If they jacked my Claude Code subscription up to $500/month I would be upset but almost certainly would keep paying it, that’s how much value it brings.
I’m in enterprise ERP.
It sounds like you use your personal Claude Code subscription for work of your employer, but that is not something I would ever consider doing personally so I imagine I must be mistaken.
Can you elaborate slightly on what you pay for personally and what your employer pays for with regards to using LLMs for Enterprise ERP?
8 replies →
Even more important than those things, is how well you can write and communicate your ideas. If you cannot communicate your ideas so a human could implement it as you wanted it to without asking extra questions, a LLM isn't gonna be able to.
3 replies →
> After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
"completely useless" and "real programming" are load bearing here. Without a definition to agree on for those terms, it's really hard not to read that as you're trying to troll us by making a controversial unprovable claim that you know will get people that disagree with you riled up. What's especially fun is that you then get to sneer at the abilities of anybody making concrete claims by saying "that's not real programming".
How tiresome.
Who cares about semantics.
Ultimately it all boils down to the money - show me the money. OAI have to show money and so do its customers from using this tool.
But nope, the only thing out there where it matters is hype. Nobody is on an earnings call clearly showing how they had a numerical jump in operating efficiency.
Until I see that, this technology has a dated shelf life and only those who already generate immense cash flows will fund its continued existence given the unfavourable economics of continued reinvestment where competition is never-ending.
4 replies →
agreed. we should instead be sneering at the AI critics because "you're holding it wrong"
> After working with agent-LLMs for some years now
Some years? I don't remember any agents being any good at all before just over 1 year ago with Cursor and stuff really didn't take off until Claude Code.
Which isn't to say you weren't working with agent-LLMs before that, but I just don't know how relevant anything but recent experience is.
> I can confirm that they are completely useless for real programming
Can you elaborate on "real programming" ?
I am assuming you mean the simplest hard problem that is solved. The value of the work is measured in those terms. Easy problems have boilerplate solutions and have been solved numerous times in the past. LLMs excel here.
Hard problems require intricate woven layers of logic and abstraction, and LLMs still struggle since they do not have causal models. The value however is in the solution of these kinds of problems since the easy problems are assumed to be solved already.
> After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming. > They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
This was how I felt until about 18 months ago.
Can you give a single, precise example where modern day LLMs fail as woefully as you describe?
i had to disable baby Ceph (Deepseek 3.1) from writing changes in Continue because he's like a toddler. But, he did confirm some solutions and wrote a routine and turn me on to some libraries, etc
so I see what you're saying. he comes up with the wrong answers a lot to a problem involving a group of classes in related files
however it's Continue, so it can read files in vs code which is really nice and that helps a lot with its comprehension so sometimes it does find the issue or at least the nature of the issue
I tend to give it bug n-1 to pre digest while I work on bug n
>After working with agent-LLMs for some years now, I can confirm that they are completely useless for real programming.
>They never helped me solve complex problems with low-level libraries. They can not find nontrivial bugs. They don't get the logic of interwoven layers of abstractions.
>LLMs pretend to do this with big confidence and fail miserably.
This is true for most developers as well. The mean software developer, especially if you outsource, has failure modes worse than any LLM and round-trip time is not seconds but days.
The promise of LLMs is not that they solve the single most difficult tasks for you instantly, but that they do the easy stuff well enough that they replace offshore teams.
> The promise of LLMs is not that they solve the single most difficult tasks for you instantly, but that they do the easy stuff well enough that they replace offshore teams.
But that's exactly the *promise* of LLMs by the hypepeople behind it.
8 replies →
Claude is currently porting my rust emulator to WASM. It's not easy at all, it struggles, I need to guide it quite a lot but it's way easier to let him do it than me learning yet another tech. For the same result I have 50% the mental load...
The idea they're good for development is propped up a lot by people able to have a react + tailwind site spun up fast. You know what also used to be able to scaffold projects quickly? The old init scripts and generators!
I really really want this to be true. I want to be relevant. I don’t know what to do if all those predictions are true and there is no need (or very little need) for programmers anymore.
But something tells me “this time is different” is different this time for real.
Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me. I’m basically just the conductor of all those processes.
Oh, and don't ask about coding. If you use AI for tasks above, as a result you'll get very well defined coding task definitions which an AI would ace.
I’m still hired, but I feel like I’m doing the work of an entire org that used to need twenty engineers.
From where I’m standing, it’s scary.
I was a chef in Michelin-starred restaurants for 11 years. One of my favorite positions was washing dishes. The goal was always to keep the machine running on its 5-minute cycle. It was about getting the dishes into racks, rinsing them, and having them ready and waiting for the previous cycle to end—so you could push them into the machine immediately—then getting them dried and put away after the cycle, making sure the quality was there and no spot was missed. If the machine stopped, the goal was to get another batch into it, putting everything else on hold. Keeping the machine running was the only way to prevent dishes from piling up, which would end with the towers falling over and breaking plates. This work requires moving lightning fast with dexterity.
AI coding agents are analogous to the machine. My job is to get the prompts written, and to do quality control and housekeeping after it runs a cycle. Nonetheless, like all automation, humans are still needed... for now.
If it requires an expert engineer/dishwasher to keep the flow running perfectly, the human is the bottleneck in the process. This sounds a lot more like the past before AI to me. What AI does is just give you enough dishes that they don’t need to be washed at all during dinner service. Just let them pile up dirty or throw them away and get new dishes tomorrow it’s so immaterial to replace that washing them doesn’t always make sense. But if for some reason you do want to reuse them, then, it washes and dries them for you too. You just look over things at the end and make sure they pass your quality standards. If they left some muck on a plate or lipstick on a cup, just tell it not to let that happen again and it won’t. So even your QC work gets easier over time. The labor needed to deal with dirty dishes is drastically reduced in any case.
> humans are still needed... for now
"AI" doesn't have a clue what to do on its own. Humans will always be in the loop, because they have goals, while the AI is designed to placate and not create.
The amount of "AI" garbage I have to sift through to find one single gem is about the same or more work than if I had just coded it myself. Add to that the frustration of dealing with a compulsive liar, and it's just a fucking awful experience for anyone that actually can code.
Humans are still needed, but they just got down-skilled.
1 reply →
> Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me.
That is just not true, assuming you have a modicum of competence (which I assume you do). AIs suck at all these tasks; they are not even as good as an inexperienced human.
For all we know, you both could comparing using a Nokia 3310 and a workstation PC based on the hardware, but you both just say "this computer is better than that computer".
There are a ton of models out there, ran in a ton of different ways, that can be used in different ways with different harnesses, and people use different workflows. There is just so many variables involved, that I don't think it's neither fair nor accurate for anyone to claim "This is obviously better" or "This is obviously impossible".
I've been in situations where I hit my head against some hard to find bug for days, then I put "AI" (but what? No one knows) to it and it solves it in 20 minutes. I've also asked "AI" to do trivial work that it still somehow fucked up, even if I could probably have asked a non-programmer friend to do it and they'd be able to.
The variance is great, and the fact that system/developer/user prompts matter a lot for what the responses you get, makes it even harder to fairly compare things like this without having the actual chat logs in front of you.
7 replies →
LLMs generate the most likely code given the problem they're presented and everything they've been trained on, they don't actually understand how (or even if) it works. I only ever get away with that when I'm writing a parser.
9 replies →
Depends on how he defined "better". If he uses the word "better" to mean "good enough to not fail immediately, and done in 1/10th of the time", then he's correct.
I think I've been using AI wrong. I can't understand testimonies like this. Most times I try to use AI for a task, it is a shitshow, and I have to rewrite everything anyway.
Have you tried Opus 4.5 (or similar recent models)? With Claude code 2, it's actually harder to mess things up IMO
3 replies →
Same. Seems to be the never ending theme of AI.
Try Claude. And partner with it on building something complex.
1 reply →
I don’t know about right/wrong. You need to use the tools that make you productive. I personally find that in my work there are dozens of little scripts or helper functions that accelerate my work. However I usually don’t write them because I don’t have the time. AI can generate these little scripts very consistently. That accelerates my work. Perhaps just start simple.
2 replies →
Do you tell AI the patterns/tools/architecture you want? Telling agents to "build me XYZ, make it gud!" is likely to precede a mess, telling it to build a modular monolith using your library/tool list, your preferred folder structure, other patterns/algorithms you use, etc will end you up with something that might have some minor style issues or not be perfectly canonical, but will be approximately correct within a reasonable margin, or is within 1-2 turns of being so.
You have to let go of the code looking exactly a certain way, but having code _work_ a certain way at a coarse level is doable and fairly easy.
9 replies →
have you tried using $NEWEST_MODEL ?
3 replies →
how much time/effort have you put in to educate yourself about how they work, what they excel at, what they suck at, what is your responsibility when you use them…? this effort is directly proportional to how well they will serve you
>> From where I’m standing, it’s scary.
You are being fooled by randomness [1]
Not because the models are random, but because you are mistaking a massive combinatorial search over seen patterns for genuine reasoning. Taleb point was about confusing luck for skill. Dont confuse interpolation for understanding.
You can read a Rust book after years of Java, then go build software for an industry that did not exist when you started. Ask any LLM to write a driver for hardware that shipped last month, or model a regulatory framework that just passed... It will confidently hallucinate. You will figure it out. That is the difference between pattern matching and understanding.
[1] https://en.wikipedia.org/wiki/Fooled_by_Randomness
I've worked with a lot of interns, fresh outs from college, overseas lowest bidders, and mediocre engineers who gave up years ago. All over the course of a ~20 year career.
Not once in all that time has anyone PRed and merged my completely unrelated and unfinished branch into main. Except a few weeks ago. By someone who was using the LLM to make PRs.
He didn't understand when I asked him about it and was baffled as to how it happened.
Really annoying, but I got significantly less concerned about the future of human software engineering after that.
Have you used an LLM specifically trained for tool calling, in Claude Code, Cursor or Aider?
They’re capable of looking up documentation, correcting their errors by compiling and running tests, and when coupled with a linter, hallucinations are a non issue.
I don’t really think it’s possible to dismiss a model that’s been trained with reinforcement learning for both reasoning and tool usage as only doing pattern matching. They’re not at all the same beasts as the old style of LLMs based purely on next token prediction of massive scrapes of web data (with some fine tuning on Q&A pairs and RLHF to pick the best answers).
15 replies →
Why would you expect an LLM or even a human to succeed in these cases? “Write a piece of code for a specification that you can’t possibly know about?” That’s why you have to do context engineering, just like you’d provide a reference to a new document to an engineer writing code.
This is exactly what happened to me: novel or uncommon = hallucinate or invent wrong.
It is ok for getting snippets for example and saying (I did it). Please make this MVVM style. It is not perfect, but saves time.
For very broad or novel reasoning, as of today... forget it.
They do all those things you've mentioned more efficiently than most of us, but they fall woefully short as soon as novelty is required. Creativity is not in their repertoire. So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce. But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step.
I choose to look at it as an opportunity to spend more time on the interesting problems, and work at a higher level. We used to worry about pointers and memory allocation. Now we will worry less and less about how the code is written and more about the result it built.
Take food for example. We don't eat food made by computers even though they're capable of making it from start to finish.
Sure we eat carrots probably assisted by machines, but we are not eating dishes like protein bars all day every day.
Our food is still better enjoyed when made by a chef.
Software engineering will be the same. No one will want to use software made by a machine all day every day. There are differences in the execution and implementation.
No one will want to read books entirely dreamed up by AI. Subtle parts of the books make us feel something only a human could have put right there right then.
No one will want to see movies entirely made by AI.
The list goes on.
But you might say "software is different". Yes but no, in the abundance of choice, when there will be a ton of choice for a type of software due to the productivity increase, choice will become more prominent and the human driven software will win.
Even today we pick the best terminal emulation software because we notice the difference between exquisitely crafted and bloated cruft.
6 replies →
> So if you're banging out the same type of thing over and over again, yes, they will make that work light and then scarce.
The same thing over and over again should be a SaaS, some internal tool, or a plugin. Computers are good at doing the same thing over and over again and that's what we've been using them for
> But if you need to create something niche, something one-off, something new, they'll slip off the bleeding edge into the comfortable valley of the familiar at every step.
Even if the high level description of a task may be similar to another, there's always something different in the implementation. A sports car and a sedan have roughly the same components, but they're not engineered the same.
> We used to worry about pointers and memory allocation.
Some still do. It's not in every case you will have a system that handle allocations and a garbage collector. And even in those, you will see memory leaks.
> Now we will worry less and less about how the code is written and more about the result it built.
Wasn't that Dreamweaver?
I think your image of LLMs is a bit outdated. Claude Code with well-configured agents will get entirely novel stuff done pretty well, and that’s only going to get better over time.
I wouldn’t want to bet my career on that anyway.
1 reply →
As of today NONE of the known AI codebots can solve correctly ANY of the 50+ programming exercises we use to interview fresh grads or summer interns. NONE! Not even level 1 problems that can be solved in fewer than 20 lines of code with a bit of middle school math.
After 25+ years in this field, having interviewed ~100 people for both my startup and other companies, I'm having a hard time believing this. You're either in an extremely niche field (such as to make your statement irrelevant to 99.9% of the industry), or it's hyperbole, or straight up bs.
Interviewing is an art, and IME "gotcha" types of questions never work. You want to search for real-world capabilities, and like it or not the questions need to match those expectations. If you're hiring summer interns and the SotA models can't solve those questions, then you're doing something wrong. Sorry, but having used these tools for the past three years this is extremely ahrd to believe.
I of course understand if you can't, but sharing even one of those questions would be nice.
2 replies →
I promise you that I can show you how to reliably solve any of them using any of the latest OpenAI models. Email me if you want proof; josh.d.griffith at gmail
3 replies →
It's definitely scary in a way.
However I'm still finding a trend even in my org; better non-AI developers tend to be better at using AI to develop.
AI still forgets requirements.
I'm currently running an experiment where I try to get a design and then execute on an enterprise 'SAAS-replacement' application [0].
AI can spit forth a completely convincing looking overall project plan [1] that has gaps if anyone, even the AI itself, tries to execute on the plan; this is where a proper, experienced developer can step in at the right steps to help out.
IDK if that's the right way to venture into the brave new world, but I am at least doing my best to be at a forefront of how my org is using the tech.
[0] - I figured it was a good exercise for testing limits of both my skills prompting and the AI's capability. I do not expect success.
AI does not forget requirements when you use a spec driven AI tool like Kiro
1 reply →
> I’m basically just the conductor of all those processes.
a car moves faster than you, can last longer than you, and can carry much more than you. But somehow, people don't seem to be scared of cars displacing them(yet)? Perhaps autodriving would in the near future, but there still needs to be someone making decisions on how best to utilize that car - surely, it isn't deciding to go to destination A without someone telling them.
> I feel like I’m doing the work of an entire org that used to need twenty engineers.
and this is great. A combine harvester does the work of what used to be an entire village for a week in a day. More output for less people/resources expended means more wealth produced.
> a car moves faster than you, can last longer than you, and can carry much more than you. But somehow, people don't seem to be scared of cars displacing them(yet)?
People whose life were based around using horses for transportation were very scared of cars replacing them though, and correctly so, because horses for transportation is something people do for leisure today, not necessity. I feel like that's a more apt analogy than comparing cars to any human.
> More output for less people/resources expended means more wealth produced.
This is true, but it probably also means that this "more wealth produced" will be more concentrated, because it's easier to convince one person using AI that you should have half of the wealth they produce, rather than convincing 100 people you should have half of what they produce. From where I'm standing, it seems to have the same effects (but not as widespread or impactful, yet) as industrialization, that induced that side-effect as well.
1 reply →
And parent is scared of being made redundant by AI because they need their job to pay for their car, insurance, gas and repairs.
> a car moves faster than you, can last longer than you, and can carry much more than you. But somehow, people don't seem to be scared of cars displacing them(yet)?
???
Cars replaced horses, not people.
In this scenario you are the horse.
3 replies →
That's kind of the point of the article, though.
Sure LLMs can churn out code, and they sort of work for developers who already understand code and design, but what happens when that junior dev with no hard experience builds their years of experience with LLMs?
Over time those who actually understand what the LLMs are doing and how to correct the output are replaced by developers who've never learned the hard lessons of writing code line by line. The ability to reason about code gets lost.
This points to the hard problem that the article highlights. The hard problem of software is actually knowing how to write it, which usually takes years, sometimes up to a decade of real experience.
Any idiot can churn out code that doesn't work. But working, effective software takes a lot of skill that LLMs will be stripping people of. Leaving a market there for people who have actually put the time in and understand software.
My experience with these tools is far and away no where close to this.
If you're really able to do the work of a 20 man org on your own, start a business.
This is not how I think about it. Me and the coding assistant is better then me or the coding assistant separately.
For me its not about me or the coding assistant, its me and the coding assistant. But I'm also not a professional coder, i dont identify as a coder. I've been fiddling with programming my whole life, but never had it as title, I've more worked from product side or from stakeholder side, but always got more involved, as I could speak with the dev team.
This also makes it natural for me to work side-by-side with the coding assistant, compared maybe to pure coders, who are used to keeping the coding side to themselves.
I have been using the most recent Claude, ChatGPT and Gemini models for coding for a bit more than a year, on a daily basis.
They are pretty good at writing code *after* I thoroughly described what to do, step by step. If you miss a small detail they get loose and the end result is a complete mess that takes hours to clean up. This still requires years of coding experience, planning ahead in head, you won't be able to spare that, or replace developers with LLMs. They are like autocomplete on steroids, that's pretty much it.
Yes what you are describing is exactly what Kiro solves
1 reply →
I am sorry to say you are not a good programmer.
I mean, AIs can drop something fast the same way you cannot beat a computer at adding or multiplying.
After that, you find mistakes, false positives, code that does not work fully, and the worse part is the last one: code that does not work fully but also, as a consequence, that you do NOT understand yet.
That is where your time shrinks: now you need to review it.
Also, they do not design systems better. Maybe partial pieces. Give them something complex and they will hallucinate worse solutions than what you already know if you have, let us say, over 10 years of experience programming in a language (or mabye 5).
Now multiply this unreliability problem as the code you "AI-generate" grows.
Now you have a system you do not know if it is reliable and that you do not understand to modify. Congrats...
I use AI moderately for the tasks is good at: generate some scripts, give me this small typical function amd I review it.
Review my code: I will discard part of your mistakes and hallucinations as a person that knows well the language and will find maybe a few valuable things.
Also, when reviewing and found problems in my code I saw that the LLMs really need to hallucinate errors that do not exist to justify their help. This is just something LLMs seem to not be accurate at.
Also, when problems go a bit more atypical or past a level of difficulty, it gets much more unreliable.
All in all: you are going to need humans. I do not know how many, I do not know how much they will improve. I just know that they are not reliable and this "generate-fast-unreliable vs now I do not know the codebase" is a fundamental obstacle that I think it is if not very difficult, impossible to workaround.
I feel you, it's scary. But the possibilities we're presented with are incredible. I'm revisiting all these projects that I put aside because they were "too big" or "too much for a machine". It's quite exciting
>> Coding AIs design software better than me
Absolutely flat out not true.
I'm extremely pro-faster-keyboard, i use the faster keyboards in almost every opportunity i can, i've been amazed by debugging skills (in fairness, i've also been very disappointed many times), i've been bowled over by my faster keyboard's ability to whip out HTML UI's in record time, i've been genuinely impressed by my faster keyboard's ability to flag flaws in PRs i'm reviewing.
All this to say, i see lots of value in faster keyboard's but add all the prompts, skills and hooks you like, explain in as much detail as you like about modularisation, and still "agents" cannot design software as well as a human.
Whatever the underlying mechanism of an LLM (to call it a next token predictor is dismissively underselling its capabilities) it does not have a mechanism to decompose a problem into independently solvable pieces. While that remains true, and i've seen zero precursor of a coming change here - the state of the art today is equiv to having the agent employ a todo list - while this remains true, LLMs cannot design better than humans.
There are many simple CRUD line of business apps where they design well enough (well more accurately stated, the problem is small/simple enough) that it doesn't matter about this lack of design skill in LLMs or agents. But don't confuse that for being able to design software in the more general use case.
Exactly, for the thing that has been done in Github 10000x times over, LLMs are pretty awesome and they speed up your job significantly (it's arguable if you would be better off using some abstraction already built if that's the case).
But try to do something novel and... they become nearly useless. Not like anything particularly difficult, just something that's so niche it's never been done before. It will most likely hallucinate some methods and call it a day.
As a personal anecdote, I was doing some LTSpice simulations and tried to get Claude Sonnet to write a plot expression to convert reactance to apparent capacitance in an AC sweep. It hallucinated pretty much the entire thing, and got the equation wrong (assumed the source was unit intensity, while LTSpice models AC circuits with unit voltage. This surely is on the internet, but apparently has never been written alongside the need to convert an impedance to capacitance!).
Try have your engineers pick up some product work. Clients do NOT want to talk to bots.
> Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me.
They don't do any of that better than me; they do it poorer and faster, but well enough for most of the time.
Then you are using the wrong AI tools or using them poorly
There will be a need. Don't worry. Most people still haven't figured out how to properly read and interpret instructions. So they build things incorrectly - with or without AI
Seriously. The bar is that low. When people say "AI slop" I just chuckle because it's not "AI" it's everyone. That's the general state of the industry.
So all you have to do is stay engaged, ask questions, and understand the requirements. Know what it is you're building and you'll be fine.
More than any other effect they have LLMs breed something called "learned helplessness". You just listed a few things it may stay better than you at, and a few things that it is not better than you at and never will be.
Planning long running projects and deciding are things only you can do well!! Humans manage costs. We look out for our future. We worry. We have excitement, and pride. It wants you to think none of these things matter of course, because it doesn't have them. It says plausible things at random, basically. It can't love, it can't care, it won't persist.
WHATEVER you do don't let it make you forget that it's a bag of words and you are someing almost infinitely more capable, not in spite of human "flaws" like caring, but because of them :)
Plus I think I've almost never see so little competition for what I think are the real prizes! Everyone's off making copies of copies of copies of the same crappy infrastructure we already have. They're busy building small inconsequential side projects so they can say they built something using an LLM.
7 replies →
Yea I've been seeing very similar behavior from people. They think of themselves as static, unchanging, uncreative but view LLMs as some kind of unrelenting and inevitable innovative force...
I think it's people's anxieties and fears about the uncertainty about the value of their own cognitive labor demoralizing them and making them doubt their own self-efficacy. Which I think is an understandable reaction in the face of trillion dollar companies frothing at the mouth to replace you with pale imitations.
Best name I could think of calling this narrative / myth is people believing in "effortless AI": https://www.insidevoice.ai/p/effortless-ai
You are still in denial of what an LLM actually is capable of in the near-mid term.
In the current architecture there are mathmatical limitations on what it can do with information. However, tool use and external orchestration allow it to work around many (maybe all) those limitations.
The current models have brittle parts and some bad tendencies.. but they will continue to eat up the executive thought ladder.
I think it is better to understand this and position yourself higher and higher on that chain while learning what are the weak areas in the current generation of models.
Your line of thinking is like hiding in a corner while the water is rising. You are right, it is a safe corner, but probably not for long.
4 replies →
Where the hell was all this fear when the push for open source everything got fully underway? When entire websites were being spawned and scaffolded with just a couple lines of code? Do we not remember all those impressive tech demos of developers doing massive complex thing with "just one line of code"? How did we not just write software for every kind of software problem that could exist by now?
How has free code, developed by humans, become more available than ever and yet somehow we have had to employ more and more developers? Why didn't we trend toward less developers?
It just doesn't make sense. AI is nothing but a snippet generator, a static analyzer, a linter, a compiler, an LSP, a google search, a copy paste from stackoverflow, all technologies we've had for a long time, all things developers used to have to go without at some point in history.
I don't have the answers.
> Coding AIs design software better than me, review code better than me, find hard-to-find bugs better than me, plan long-running projects better than me, make decisions based on research, literature, and also the state of our projects better than me
ChatGPT, is that you?
Perfect economic substitution in coding doesn't happen for a long time. Meanwhile, AI appears as an amplifier to the human and vice versa. That the work will change is scary, but the change also opens up possibilities, many of them now hard to imagine.
Notice who makes these predictions that programmers will become irrelevant.
Stop freaking out. Seriously. You're afraid of something completely ridiculous.
It is certainly more eloquent than you regarding software architecture (which was a scam all along, but conversation for another time). It will find SOME bugs better than you, that's a given.
Review code better than you? Seriously? What you're using and what you consider code review? Assume I could identify one change broke production and you reviewed the latest commit. I am pinging you and you better answer. Ok, Claude broke production, now what? Can you begin to understand the difference between you and the generative technology? When you hop on the call, you will explain to me with a great deal of details what you know about the system you built, and explain decision making and changes over time. You'll tell about what worked and what didn't. You will tell about the risks, behavior and expectations. About where the code runs, it's dependencies, users, usage patterns, load, CPU usage and memory footprint, you could probably tell what's happening without looking at logs but at metrics. With Claude I get: you're absolutely right! You asked about what it WAS, but I told you about what it WASN'T! MY BAD.
Knowledge requires a soul to experience and this is why you're paid.
We use code rabbit and it's better than practically any human I've worked with at a number of code review tasks, such as finding vulnerabilities, highlighting configuration issues, bad practices, etc. It's not the greatest at "does this make sense here" type questions, but I'd be the one answering those questions anyway.
Yeah, maybe the people I've worked with suck at code reviews, but that's pretty normal.
Not to say your answer is wrong. I think the gist is accurate. But I think tooling will get better at answering exactly the kind of questions you bring up.
Also, someone has to be responsible. I don't think the industry can continue with this BS "AI broke it." Our jobs might devolve into something more akin to a SDET role and writing the "last mile" of novel code the AI can't produce accurately.
1 reply →
> Review code better than you? Seriously?
Yes, seriously (not OP). Sometimes it's dumb as rocks, sometimes it's frighteningly astute.
I'm not sure at which point of the technology sigmoid curve we find ourselves (2007 iPhone or 2017 iPhone?) but you're doing yourself a disservice to be so dismissive
1 reply →
>I really really want this to be true. I want to be relevant
Think of yourself as a chef and LLMs as ready to eat meals or a recipe app. Can ready to eat meals OR recipe apps put a chef out of business?
The AI is pretty scary if you think most of software engineering is about authoring individual methods and rubber ducking about colors of paint and brands of tools.
Once you learn that it's mostly about interacting with a customer (sometimes this is yourself), you will realize the AI is pretty awful at handling even the most basic tasks.
Following a product vision, selecting an appropriate architecture and eschewing 3rd party slop are examples of critical areas where these models are either fundamentally incapable or adversely aligned. I find I have to probe ChatGPT very hard to get it to offer a direct implementation of something like a SAML service provider. This isn't a particularly difficult thing to do in a language like C# with all of the built in XML libraries, but the LLM will constantly try to push you to use 3rd party and cloud shit throughout. If you don't have strong internal convictions (vision) about what you really want, it's going to take you for a ride.
One other thing to remember is that our economies are incredibly efficient. The statistical mean of all information in sight of the LLMs likely does not represent much of an arbitrage opportunity at scale. Everyone else has access to the same information. This also means that composing these systems in recursive or agentic styles means you aren't gaining anything. You cannot increase the information content of a system by simply creating another instance of the same system and having it argue with itself. There usually exists some simple prompt that makes a multi agent Rube Goldberg contraption look silly.
> I’m basically just the conductor of all those processes.
"Basically" and "just" are doing some heroic weight lifting here. Effectively conducting all of the things an LLM is good at still requires a lot of experience. Making the constraints live together in one happy place is the hard part. This is why some of us call it "engineering".
This reads like shilling/advertisement.. Coding AIs are struggling for anything remotely complex, make up crap and present it as research, write tests that are just "return true", and won't ever question a decision you make.
Those twenty engineers must not have produced much.
I think part of what is happening here is that different developers on HN have very different jobs and skill levels. If you are just writing a large volume of code over and over again to do the same sort of things, then LLMs probably could take your job. A lot of people have joined the industry over time, and it seems like the intelligence bar moved lower and lower over time, particularly for people churning out large volumes of boilerplate code. If you are doing relatively novel stuff, at least in the sense that your abstractions are novel and the shape of the abstraction set is different from the standard things that exist in tutorials etc online, then the LLM will probably not work well with your style.
So some people are panicking and they are probably right, and some other people are rolling their eyes and they are probably right too. I think the real risk is that dumping out loads of boilerplate becomes so cheap and reliable that people who can actually fluently design coherent abstractions are no longer as needed. I am skeptical this will happen though, as there doesn’t seem to be a way around the problem of the giant indigestible hairball (I.e as you have more and more boilerplate it becomes harder to remain coherent).
34 replies →
No it doesn’t read like shilling and advertisement, it’s tiring hearing people continually dismiss coding agents as if they have not massively improved and are driving real value despite limitations and they are only just getting started. I’ve done things with Claude I never thought possible for myself to do, and I’ve done things where Claude made the whole effort take twice as long and 3x more of my time. It’s not like people are ignoring the limitations, it’s that people can see how powerful the already are and how much more headroom there is even with existing paradigms not to mention the compute scaling happening in 26-27 and the idea pipeline from the massive hoarding of talent.
114 replies →
I would say while LLMs do improve productivity sometimes, I have to say I flatly cannot believe a claim (at least without direct demonstration or evidence) that one person is doing the work of 20 with them in december 2025 at least.
I mean from the off, people were claiming 10x probably mostly because it's a nice round number, but those claims quickly fell out of the mainstream as people realised it's just not that big a multiplier in practice in the real world.
I don't think we're seeing this in the market, anywhere. Something like 1 engineer doing the job of 20, what you're talking about is basically whole departments at mid sized companies compressing to one person. Think about that, that has implications for all the additional management staff on top of the 20 engineers too.
It'd either be a complete restructure and rethink of the way software orgs work, or we'd be seeing just incredible, crazy deltas in output of software companies this year of the type that couldn't be ignored, they'd be impossible to not notice.
This is just plainly not happening. Look, if it happens, it happens, 26, 27, 28 or 38. It'll be a cool and interesting new world if it does. But it's just... not happened or happening in 25.
16 replies →
My experience is that you get out what you put in. If you have a well-defined foundation, AI can populate the stubs and get it 95% correct. Getting to that point can take a bit of thought, and AI can help with that, too, but if you lean on it too much, you'll get a mess.
And of course, getting to the point where you can write a good foundation has always been the bulk of the work. I don't see that changing anytime soon.
This is completely wrong. Codex 5.2 and Claude Sonnet 4.5 don't have any of these issues. They will regularly tell you that you're wrong if you bother to ask them and they will explain why and what a better solution is. They don't make up anything. The code they produce is noticeably more efficient in LoC than previous models. And yes they really will do research, they will search the Internet for docs and articles as needed and cite their references inline with their answers.
You talk as if you haven't used a LLM since 2024. It's now almost 2026 and things have changed a lot.
3 replies →
I'd be willing to give you access to the experiment I mentioned in a separate reply (have a github repo), as far as the output that you can get for a complex app buildout.
Will admit It's not great (probably not even good) but it definitely has throughput despite my absolute lack of caring that much [0]. Once I get past a certain stage I am thinking of doing an A-B test where I take an earlier commit and try again while paying more attention... (But I at least want to get where there is a full suite of UOW cases before I do that, for comparison's sake.)
> Those twenty engineers must not have produced much.
I've been considered a 'very fast' engineer at most shops (e.x. at multiple shops, stories assigned to me would have a <1 multiplier for points[1])
20 is a bit bloated, unless we are talking about WITCH tier. I definitely can get done in 2-3 hours what could take me a day. I say it that way because at best it's 1-2 hours but other times it's longer, some folks remember the 'best' rather than median.
[0] - It started as 'prompt only', although after a certain point I did start being more aggressive with personal edits.
[1] - IDK why they did it that way instead of capacity, OTOH that saved me when it came to being assigned Manual Testing stories...
2 replies →
Ok, let's say the 20 devs claim is false [1]. What if it's 2? I'd still learn and use the tech. Wouldn't you?
[1] I actually think it might be true for certain kinds of jobs.
3 replies →
Post model
> I’m basically just the conductor of all those processes.
Orchestrating harmony is no mean feat.
AI is absolutely rock-bottom shit at all that.
Yeah, it makes me wonder whether I should start learning to be a carpenter or something. Those who either support AI or thinks "it's all bullshit" cite a lack of evidence for humans truly being replaced in the engineering process, but that's just the thing; the unprecedented levels of uncertainty make it very difficult to invest one's self in the present, intellectually and emotionally. With the current state of things, I don't think it's silly to wonder "what's the point" if another 5 years of this trajectory is going to mean not getting hired as a software dev again unless you have a PhD and want to work for an AI company.
What doesn't help is that the current state of AI adoption is heavily top-down. What I mean is the buy-in is coming from the leadership class and the shareholder class, both of whom have the incentive to remove the necessary evil of human beings from their processes. Ironically, these classes are perhaps the least qualified to decide whether generative AI can replace swathes of their workforce without serious unforeseen consequences. To make matters worse, those consequences might be as distal as too many NEETs in the system such that no one can afford to buy their crap anymore; good luck getting anyone focused on making it to the next financial quarter to give a shit about that. And that's really all that matters at the end of the day; what leadership believes, whether or not they are in touch with reality.
His logic is off and his experience is irrelevant because i doesn’t encompass scale to have been exposed to an actual paradigm shifting event. Civilizations and entire technologies have been overturned so he can’t say it won’t happen this time.
What we do know is this. If AI keeps improving at the current rate it’s improving then it will eventually hit a point where we don’t need software engineers. That’s inevitable. The way for it to not happen is for this technology to hit an impenetrable wall.
This wave of AI came so fast that there are still stubborn people who think it’s a stochastic parrot. They missed the boat.
As much as my first gut reaction to this article was to be excited about its conclusion, I can’t say my experience matches up. Are LLMs perfect? Absolutely not, but I can point to many examples in my own work where using Codex has saved me easily a week or more—especially when it comes to tedious refactors. I don’t agree with the conclusion; the real-world improvement and progress I’ve seen in the last year in the problem-solving quality of these agents has been pretty astounding.
The reason for my excitement about the conclusion is obvious: I want programmers and people to stay in demand. I find the AI future to be quite bleak if this tech really does lead to AGI, but maybe that’s just me. I think we’re at a pretty cool spot with this technology right now—where it’s a powerful tool—but at some point, if or when it’s way smarter than you or me… I'm not sure that's a fun happy future. I think work is pretty tied to our self worth as humans.
> but I can point to many examples in my own work where using Codex has saved me easily a week or more
Care to share a few of these examples?
Sure thing. I work on a few projects for my company. The main one is an Android and iOS audiobook-media-player app. I had to update the Android side to use the Google Media3 library instead of the legacy ExoPlayer library. In a typical app this would be pretty straightforward, but we’ve mixed in a lot of custom elements that made the transition quite challenging. I actually attempted it manually back in the day and probably spent three or four days on it, but I simply didn’t have time to finish, so I shelved it. A few months ago I tried again in Codex; within two prompts it was done flawlessly and starting from the beginning.
Another example: I also maintain the back-end API for these apps. There was a lot of old utility code that was messy, unorganized, and frankly gross. I had Codex completely reorganize the code into a sensible folder structure and strip out any functions that weren’t being used anymore—something like 300-plus functions. Doing that by hand would easily have taken a day or more
I could go on, but those were the two initial “aha” moments that showed me how powerful this tool can be when it’s used for the right tasks.
10 replies →
It is just the Eliza effect on a massive scale: https://en.wikipedia.org/wiki/ELIZA_effect
Reading Weizenbaum today is eye opening: https://en.wikipedia.org/wiki/Computer_Power_and_Human_Reaso...
I agree the ELIZA effect is strong, additionally I think it is some kind of natural selection.
I feel like LLM's are specifically selected to impress people that have a lot of influence. People like investors and CEO's. Because a "AI" that does not impress this section of the population does not get adopted widely.
This is one of the reasons I think AI will never really be an expert as it does not need to be. It only needs to adopt a skill (for example coding) to pass the examination of the groups that decide if it is to be used. It needs to be "good enough to pass".
I got this wild idea a short while ago and your comment helped cement it: probably one of the reasons why languages like Lisp are not "successful" has something to do with the impressability factor? If the people with money (and the decision) do not understand the tech or are not able to even fake that understanding, will they bet their money on it?
1 reply →
> Edgar Dijkstra called it nearly 50 years ago: we will never be programming in English, or French, or Spanish. Natural languages have not evolved to be precise enough and unambiguous enough. Semantic ambiguity and language entropy will always defeat this ambition.
This is the most important quote for any AI coding discussion.
Anyone that doesn't understand how the tools they use came to be is doomed to reinvent them.
> The folly of many people now claiming that “prompts are the new source code”,
These are the same people that create applications in MS Excel.
Further evidence: After all these years (far longer than we have been doing programming), we still don't do math in English or French or Spanish. We do it in carefully defined formal notations.
But so many problems (programming, but also physics and math) start as informal word problems. A major skill is being able to turn the informal into something formal and precise.
> These are the same people that create applications in MS Excel.
Ones that want their application to work? :) the last piece of software you should be knocking is MS Excel, in my 30+ year career the one common thread just about everywhere I worked (or contracted at) has used Excel to run some amazing sh*t
Everywhere I've worked as a software engineer the past 30 years I've seen Excel spreadsheets but rarely anything amazing, maybe once back in the 1990's at one place by an Excel guru but those are rare. 00% of the time Excel is used to make essentially table layouts of data maybe with some simple cell calculations.
1 reply →
Excel (or similar spreadsheet programs) is indeed great and has it's place. There are certain area's where there is no real replacement which is impressive. However I think that creating (interactive) applications is not one of the jobs Excel is the best tool for the job.
This exactly the argument I try to make Excel (spreadsheets) is a great interface for processing and working with certain type of data, think economic etc. but it is not great for other things. There we need a different interface to efficiently communicate our intent. For example programming languages or even writing a novel would not work very well in a Excel sheet (though no doubt someone has attempted it).
I think programmets often underestimate the power of Excel for non-programmers, it in practice runs the business world.
I think that it also is a comparable to the ai side we see now. Do something for real, use real database or programmer. Non-programmer needs something, vibe code or excel
> Natural languages have not evolved to be precise enough and unambiguous enough.
Are they?
I feel like AIs fill in a lot of the blanks with reasonable assumptions rather than the input being precise
English is poor language in terms of preciseness - and even worse in terms of impreciseness.
Sometimes it looks like about anything else would be better as a programming interface.
>WYSIWYG, drag-and-drop editors like Visual Basic and Delphi were going to end the need for programmers.
VB6 and Delphi were the best possible cognitive impedance match available for domain experts to be able to whip up something that could get a job done. We haven't had anything nearly as productive in the decades since, as far as just letting a normie get something done with a computer.
You'd then hire an actual programmer to come in and take care of corner cases, and make things actually reliable, and usable by others. We're facing a very similar situation now, the AI might be able to generate a brittle and barely functional program, but you're still going to have to have real programmers make it stable and usable.
I read a book called "Blood in the machine". It's the history of the Luddites.
It really put everything into perspective to where we are now.
Pre-industrial revolution whole towns and families built clothing and had techniques to make quality clothes.
When the machines came out it wasn't overnight but it wiped out nearly all cottage industries.
The clothing it made wasn't to the same level of quality, but you could churn it out faster and cheaper. There was also the novelty of having clothes from a machine which later normalised it.
We are at the beginning of the end of the cottage industry for developers.
Does the analogy hold though?
We had "free clothes" for years, decades now. I don't mean cheap I mean literally free, as in $0.0 software. Cheaper software isn't new.
Also there are still clothe designers, fashion runways, and expensive Patagonia vests today. The clothing industry is radically different from back then but it's definitely not gone.
It didn't kill everything. Some survived but not to the extent that it was.
> The clothing industry is radically different from back then but it's definitely not gone.
Small towns had generations of people who had learned skills in making clothing / yarn. To do the work you needed years of experience and that's all you knew.
Once the industrial revolution hit they hired low skilled workers that could be dumped at a moments notice. It made whole villages destitute. Some survived, but the far majority became poor.
That was one industry. We now have AI at a point to wipe out multiple industries to a similar scale.
I posted elsewhere, but you are looking at the wrong part of the chain.
We have cheap (or free) software for large markets, and certain small markets where software developers with hobbies have made something. If every niche that will never be able to afford a large 6-figure custom software could get slop software for an affordable price, then that establishes a foot-hold for working its way up the quality ladder.
Luddism arose in response to weaving machines, not garment-making machines. The machines could weave a piece of cloth that still had to be cut and sewn by hand into a garment. Weaving the cloth was by far the most time consuming part of making the clothing.
Writing code is not at all the most time consuming part of software development.
> Luddism arose in response to weaving machines, not garment-making machines.
It started there, yes.
> Writing code is not at all the most time consuming part of software development.
The current Vibe coding systems can do the full pipeline.
1 reply →
If you used the car as an analogy instead, it would make more sense to me. There were car craftsmen in Europe that Toyota displaced almost completely. And software is more similar to cars in that it needs maintenance and if it breaks down, large consequences like death and destruction and/or financial loss follows.
If llms can churn out software like Toyota churns out cars, AND do maintenance on it, then the craftsmen (developers of today) are going to be displaced.
I feel like the comments/articles that continue to point out how LLMs cannot solve complex problems are missing a few important points:
1. LLMs are only getting better from here. With each release, we continue to see improvements in their capabilities. And strong competition is driving this innovation, and will probably not stop anytime soon. Much of the world is focused on this right now, and therefore much of the world’s investments are being poured into solving this problem.
2. They’re using the wrong models for the wrong job. Some models are better than others at some tasks. And this gap is only shrinking (see point 1).
3. Even if LLMs can’t solve complex problems (and I believe they can/will, see points 1 and 2), much of our jobs is refactoring, writing tests, and hand coding simpler tasks, which LLMs are undeniably good at.
4. It’s natural to deny LLMs can eventually replace much/all of what we do. Our careers depend on LLMs not being able to solve complex problems so that we don’t risk/fear losing our careers. Not to mention the overall impact to the general way our lives are impacted if AGI becomes a reality.
I’ve been doing this a while, and I’ve never seen the boost to productivity that LLMs bring. Yes, I’ve seen them make a mess of things and get things wrong. But see points 1-3.
> Our careers depend on LLMs not being able to solve complex problems so that we don’t risk/fear losing our careers
I think both this sentiment and the article are on the same wrong track, which is to see programming as solving well defined problems. The way I see it, the job is mostly about taking ill defined needs and turning them into well defined problems. The rest is just writing code. From this perspective, whether LLM prompting can replace writing code is only marginally relevant. It’s automating the easy part.
Sounds like philosophers will be the new programmers if playing around with language and definitions is all that will be left.
1 reply →
Also 5: "But LLMs produce a bunch of code I need to read and review".
Yes, but so do your coworkers? Do you complain about every PR you need to read? Are they all compressed diamonds of pure genious, not a single missed character or unoptimised function? Not a bad or suboptimal decision in sight?
If so, shoot me a mail, I want to work where you're working =)
My coworkers learn, and an important part of my job is teaching them. LLM-based tools don't.
1 reply →
My coworkers do sure. But I don’t have to completely reread what I wrote to grok it. That’s the issue.
You either prompt and read the code it wrote to understand it before making a PR, or you prompt and drop the PR for your team. The latter is disrespectful.
This has been my biggest hurdle so far. Sure the models do great at writing code, find things faster than I would. But time wise I still have to read what it wrote, in depth.
ETA: I also implicitly trust my coworkers. This trust has been built over years. I don’t trust LLM generated code the same way.
1 reply →
lol
I think "The Bitter Lesson" is relevant here [1].
This wave IS different.
It isn't a matter of "if" but "when".
I am a long-time software developer too... but I am strongly encouraging people to embrace the future now and get creative in finding ways to adapt.
There will always be demand for smart and creative people. BUT ... if you don't look up and look around you right now at some point you will be irrelevant.
Also see Ray Dalio's "Principles" book on embracing reality. A critical principle in the modern age of AI.
Nothing but love for my fellow developers!!
[1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html
why didn't ready to eat meals available so cheaply at any grocery store make the local mom and pop restaurants irrelevant?
People like experiences!
Plus those meals are disgusting! :-)
Plus plus… those meals are actually expensive!!
In aviation safety, there is a concept of "Swiss cheese" model, where each successful layer of safety may not be 100% perfect, but has a different set of holes, so overlapping layers create a net gain in safety metrics.
One can treat current LLMs as a layer of "cheese" for any software development or deployment pipeline, so the goal of adding them should be an improvement for a measurable metric (code quality, uptime, development cost, successful transactions, etc).
Of course, one has to understand the chosen LLM behaviour for each specific scenario - are they like Swiss cheese (small numbers of large holes) or more like Havarti cheese (large number of small holes), and treat them accordingly.
LLMs are Kraft Singles. Stuff that only kind of looks like cheese. Once you know it's in there, someone has to inspect, and sign-off on, the entire wheel for any credible semblance of safety.
how sure are you that an llm won't be better at reviewing code for safety than most humans, and eventually, most experts?
2 replies →
LLMs are very good at first pass PR checks for example. They catch the silly stuff actual humans just miss sometimes. Typos, copy-paste mistakes etc.
Before any human is pinged about a PR, have a properly tuned LLM look at it first so actual people don't have to waste their time pointing out typos in log messages.
Interesting concept, but as of now we don't apply this technologies as a new compounding layer. We are not using them after the fact we constructed the initial solution. We are not ingesting the code to compare against specs. We are not using them to curate and analyze current hand written tests(prompt: is this test any good? assistant: it is hot garbage, you are inferring that expected result equals your mocked result). We are not really at this phase yet. Not in general, not intelligently. But when the "safe and effective" crowd leave technology we will find good use cases for it, I am certain (unlike uml, VB and Delphi)
> One can treat current LLMs as a layer of "cheese" for any software development or deployment pipeline
It's another interesting attempt at normalising the bullshit output by LLMs, but NO. Even with the entshittified Boeing, the aviation industry safety and reliability records, are far far far above deterministic software (know for a lot of un-reliability itself), and deterministic, B2C software to LLMs in turn is what Boeing and Airbus software and hardware reliablity are for the B2C software...So you cannot even begin to apply aviation industry paradigms to the shit machines, please.
I understand the frustration, but factually it is not true.
Engines are reliable to about 1 anomaly per million flight hours or so, current flight software is more reliable, on order of 1 fault per billion hours. In-flight engine shutdowns are fairly common, while major software anomalies are much rarer.
I used LLMs for coding and troubleshooting, and while they can definitely "hit" and "miss", they don't only "miss".
4 replies →
The biggest threat to American software engineers is outsourcing, AI is just a distraction. I am an immigrant, I work at a prestigious financial corporation in NYC. Pretty much 95% of the staff were born and did undergraduate degree in other countries. We hire a few grads but they usually quit or get laid off after a few years - most new hires are H1Bs or contractors on H1Bs. Just about to open another big office in a developing country.
Perhaps, but that's been going on for decades.
This time it actually is different. HN might not think so, but HN is really skewed towards more senior devs, so I think they're out of touch with what new grads are going through. It's awful.
What is it that new grads are going through? If you are referring to difficulty finding a job, keep in mind that there is both an economic downturn and an over-hiring correction happening in the industry right now. I imagine the AI industry is indeed having an impact in how management is behaving, but I would not yet bet on AI actually replacing developers jobs holistically.
I can talk about my own experiences. About a year and half ago I dropped everything to get into tech, a couple years out from completing my civil engineering degree because I hated it. I worked very intensely day in day out building many projects, and I had one project go extremely viral, changing my life. That led to me getting hired at a small AI start up, where I learned an enormous amount, but 9 months later, I still got let go as work had dried up for the product I was working on. Not much I was able to do there unfortunately. Still, I really do believe that due to AI there was just far less work that I could meaningful contribute to, speaking as someone who is more junior in the field. Little bug fixes here and there, organization, grunt work tasks, etc - those are completely automated now. The rungs on the ladder of meaningful progression are growing increasingly wider as eac day goes by. A decade ago I think big tech companies would be fighting to get me on board, but now it's different, That said, to end this comment on some silver lining - I know someone who currently works at a big lab who got an enormous amount of work xp by contributing on OSS projects till he became more senior, so maybe there's more to it. Also one other thought - companies will still have job postings for juniors because a "junior" can be an MIT IOI gold medalist.
I think the only thing we can say about the future of LLMs is “we don’t know.” Everything is changing too fast. Models from a year ago are already obsolete. We seem to be hitting the top of an asymptote on improvements, but things have not been steady state for long enough to know. I also agree with the author that the VC money is driving all of this, and at some point the check is going to come due.
This thread is full of antidotes from “AI is useless for me” to “AI changes everythingfor me” I believe each and every one of them.
In firm wait and see mode.
The way I see it, the problem with LLMs is the same as with self-driving cars: trust. You can ask an LLM to implement a feature, but unless you're pretty technical yourself, how will you know that it actually did what you wanted? How will you know that it didn't catastrophically misunderstand what you wanted, making something that works for your manual test cases, but then doesn't generalize to what you _actually_ want to do? People have been saying we'll have self-driving cars in five years for fifteen years now. And even if it looks like it might be finally happening now, it's going glacially slow, and it's one run-over baby away from being pushed back another ten years.
People used to brush away this argument with plain statistics. Supposedly, if the death statistics is below the average human, you are supposed to lean back and relax. I never bought this one. Its like saying LLMs write better texts then the average huamn can, so you are supposed to use it, no matter how much you bring to the table.
The self driving car analogy is a good one, because what happens when you trust the car enough to do most of your driving but it suddenly thrusts the controls upon you when it shits the bed and can't figure out what to do? You suddenly realise you've become a very rusty driver in a moment that requires fast recall of skill, but your car is already careening off a cliff while you have this realisation.
[The "children of the magenta line"](https://www.computer.org/csdl/magazine/sp/2015/05/msp2015050...) is a god explanation of this, and is partly why I often dissuade junior devs from pretty user friendly using tools that abstract away the logic beneath them.
Just like the pro-AI articles, it reads to me like a sales pitch. And the ending only adds to it: the author invites to hire companies to contract him for training.
I would only be happy if in the end the author turns out to be right.
But as the things stand right now, I can see a significant boost to my own productivity, which leads me to believe that fewer people are going to be needed.
When coal powered engines became more efficient, demand for coal went UP. It went up because vastly more things could now be cost effectively be coal-powered.
I can see a future where software development goes the same way. My wife works in science and I see all kinds of things in a casual observation of her work that could be made more efficient with good software support. But not by enough to pay six-figures per year for multiple devs to create it. So it doesn’t get done and her work and the work of tens of thousands like her around the world is less efficient as a result.
In a world where development is even half as expensive, many such tasks become approachable. If it becomes a third or quarter as expensive, even more applications are now profitable.
I think far more people will be doing something that creates the outcomes that are today created by SWEs manually coding. I doubt it will be quite as lucrative for the median person doing it, but I think it will still be well above the median wage and there will be a lot of it.
See: https://en.wikipedia.org/wiki/Jevons_paradox
Many HN users may point to Jevons paradox, I would like to point out that it may very well work up until the point that it doesn't. After all a chicken has always seen the farmer as benevolent provider of food, shelter and safety, that is until of course THAT day when he decides he doesn't.
4 replies →
I agree with you on this feeling like a sales pitch, probably because ultimately it is. I've done a software training course led by this guy. It was fine, and his style and his lessons are all pretty decent and I found/find myself agreeing with his "takes". But it's nothing ground breaking, and he's not really adding anything to the debate that I've not read before. I don't know how active he is as a developer, I assumed that he was more of a teacher of established practices than being on the cutting edge of development. That's not an insult, but it stands out to me in this article.
Ironically, like an LLM, this article feels like more like an amalgamation of plenty of other opinions on the growth of AI in the workplace rather than any original thoughts. There's not really anything "new" here, just putting together a load of existing opinions.
(I am not suggesting that Jason got an AI to write this article, though that would be funny).
As someone having watched AI systems being good enough to replace jobs like content creation on CMS, this is being in denial.
Yes software developer are still going to be need, except much fewer of us, exactly like fully automated factories still need a few humans around, to control and build the factory in first place.
I concur with your sentiments.
Am puzzled why so many on HN cannot see this. I guess most users on HN are employed? Your employers - let me tell you - are positively salivating at the prospect of firing you. The better LLM's get the fewer of you will be needed.
Denial, like those factory workers at the first visit from the automation company, each one hoping they are the ones elected to stay and overwatch the robots.
I have seen projects where translator teams got reduced, asset creation teams, devops head count, support teams on phone lines,...
It is all about how to do more with less, now with AI help as well.
I nodded furiously at this bit:
> The hard part of computer programming isn't expressing what we want the machine to do in code. The hard part is turning human thinking -- with all its wooliness and ambiguity and contradictions -- into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
> That was the hard part when programmers were punching holes in cards. It was the hard part when they were typing COBOL code. It was the hard part when they were bringing Visual Basic GUIs to life (presumably to track the killer's IP address). And it's the hard part when they're prompting language models to predict plausible-looking Python.
> The hard part has always been – and likely will continue to be for many years to come – knowing exactly what to ask for.
I don't agree with this:
> To folks who say this technology isn’t going anywhere, I would remind them of just how expensive these models are to build and what massive losses they’re incurring. Yes, you could carry on using your local instance of some small model distilled from a hyper-scale model trained today. But as the years roll by, you may find not being able to move on from the programming language and library versions it was trained on a tad constraining.
Some of the best Chinese models (which are genuinely competitive with the frontier models from OpenAI / Anthropic / Gemini) claim to have been trained for single-digit millions of dollars. I'm not at all worried that the bubble will burst and new models will stop being trained and the existing ones will lose their utility - I think what we have now is a permanent baseline for what will be available in the future.
The first part is surely true if you change it to "the hardEST part," (I'm a huge believer in "Programming as Theory Building"), but there are plenty of other hard or just downright tedious/expensive aspects of software development. I'm still not fully bought in on some of the AI stuff—I haven't had a chance to really apply an agentic flow to anything professional, I pretty much always get errors even when one-shotting, and who knows if even the productive stuff is big-picture economical—but I've already done some professional "mini projects" that just would not have gotten done without an AI. Simple example is I converted a C# UI to Java Swing in less than a day, few thousand lines of code, simple utility but important to my current project for <reasons>. Assuming tasks like these can be done economically over time, I don't see any reason why small and medium difficulty programming tasks can't be achieved efficiently with these tools.
Indeed, while DeepSeek 3.2 or GLM 4.7 are not Opus 4.5 quality, they are close enough that I could _get by_ because they're not that far off, and are about where I was with Sonnet 3.5 or Sonnet 4 a few months ago.
I'm not convinced DeepSeek is making money hosting these, but it's not that far off from it I suspect. They could triple their prices and still be cheaper than Anthropic is now.
Hardest part of programming is knowing wtf all the existing code does and why.
And that is the super power of LLMs. In my experience LLMs are better a reading code than writing it. Have it annotate some code for you.
2 replies →
> claim to have been trained for single-digit millions of dollars
Weren't these smaller models trained by distillation from larger ones, which therefore have to exist in order to do it? Are there examples of near state of the art foundation models being trained from scratch in low millions of dollars? (This is a genuine question, not arguing. I'm not knowledgeable in this area.)
The DeepSeek v3 paper claims to have trained from scratch for ~$5.5m: https://arxiv.org/pdf/2412.19437
Kimi K2 Thinking was reportedly trained for $4.6m: https://www.cnbc.com/2025/11/06/alibaba-backed-moonshot-rele...
Both of those were frontier models at the time of their release.
Another interesting number here is Claude 3.7 Sonnet, which may people (myself included) considered the best model for several months after its release and was apparently trained for "a few tens of millions of dollars": https://www.oneusefulthing.org/p/a-new-generation-of-ais-cla...
maybe not the MOST valuable part of prompting an LLM during a task, but one of them, is defining the exact problem in precise language. i dont just blindly turn to an LLM without understanding the problem first, but i do find Claude is better than a cardboard cutout of a dog
Aren't they also losing money on the marginal inference job?
I think it is very unlikely that they are charging less money for tokens than it costs them to serve those tokens.
If they are then they're in trouble, because the more paying customers they get the more money they lose!
2 replies →
I am good at software. It turns out that isn’t sufficient, or alternatively stated, you have to be good at a number of other things than just churning code, even good code. So to me, the combination of being good at software, understanding complexity and ability articulate it concisely and precisely, when combined with the latest and greatest LLMs, is magic. I know people want to examples of success, I wish I could share what we are working on, but it is unbelievable how much more productive our team is, and I promise, we are solving novel problems, some that have not been tackled yet, at least not in any meaningful way. And I am having time of my life doing what I love, coding. This is not to downplay folks who are having a hard time with LLMs or agents, I think, it’s a skill that you can learn, if you are already good at software and the adjacencies.
> This is not to downplay folks who are having a hard time with LLMs or agents, I think, it’s a skill that you can learn, if you are already good at software and the adjacencies.
Someone on the page already quoted Dijkstra, recommend reading that, he was correct.
Prompt engineering isn't engineering at all, it's throwing words at a wall to see which ones stick then declaring success if the outcome looks at all recognizable. That isn't actually success.
The more articles written like this only reflect the inevitable. This is not an era of slow progress which may have supported the authors opinion. This era is a rapid replacement of what was once dominated by masters of one who edged out others and arrogantly tried to hold onto their perceived positions of all knowing. There will always be those types unfortunately, but when the masters of one realize theyve wasted time stalling the inevitable, instead of accepting and guiding the path forward and opening the door to a broader audience, you will see a lot more articles like this which are a clear signal to many of us that theyre simply doing and saying too much trying to hold on to their perceived worth.
The bit about drag-and-drop and Visual Studio hides a key insight: insofar as those tools allowed non-software engineers to build applications that were key to certain business processes, they were tech-debt accelerators. It is true to a very large degree; there are still businesses out there depending on shoddy VB applications that were built by someone that didn't know what they were doing, and they are hobbled by it. LLM-generated applications are the turbocharged equivalent of this, and I anticipate that giant spagehetti codebases will be made out of them, the likes of which have never been seen before, and the workflows that are wedded to them will be doomed.
I don’t think that’s actually what Dijkstra was saying, nor do I think it stands to reason.
Assuming that product designers articulate their designs in English to software engineers, who subsequently turn those ideas into products, doesn’t it stand to reason that this process is to some degree approachable?
I’m not saying that we are at that point or that we will be soon, but it just seems like flawed reasoning.
I see it as pure deterministic logic being contaminated by probabilistic logic at higher layers where human interaction happens. Seeking for human comfort by forcing computers to adapt to the human languages. Building adapters that can allow humans to stay in their comfort zone instead of dealing with the sharp-edged computer interfaces.
At the end, I don't see it going beyond being a glorified form-assistant who can search internet for answers and summarize. That boils down to chat bots that will remain and become part of every software component that ever need to interface with humans.
Agent stuff is just a fluff that is providing hype-cushion around chat bots and will go away with hype cycle.
This is the usual „but they can’t do the hard stuff“ argument. It’s not the right lens - at least not for employment.
If you need three programmers to deliver a project, one doing boilerplate, one intermediate and one doing hard task. And the AI can’t do the hard task then you’ve still got two unemployed dudes.
So yeah you can make the technically correct argument that it still needs a programmer but it glosses over the coming storm in real world job market.
The only other option to square that circle is to assume that A) we suddenly need 3x as much projects and B) boilerplate guy can somehow graduate to hard tasks
i hope the collective realization that "hard task" guys were once intermediate or boilerplate guys comes sooner than later :(
I think the realisation is already there but nobody knows what to do about it.
Companies won’t hire people just to train.
One thing that many of these kinds of articles don't really talk about but that also emphasizes their point is that there will be an increase in interfaces/languages for software developers to do increasingly specialized for work. As such, there will be more compilers, vms, dsls, etc which means that there will be more of a demand for developers who have this skillset. Ideally, this should lead to more folks becoming developers or at least acquiring skills that professional developers have in order to make effective use of these tools.
I would agrue as LLMs increase in capability, the demand for new languages will collapse.
My counterargument for that is that LLMs need to communicate not only between themselves and humans but LLM to LLM communication. We will get more niche and domain specific languages designed for LLMs as a result.
The future of software development is systems analysts.
It was discovered in the 1970s (at the latest) that the hard part of software is figuring out WHAT to build not HOW to build it—and the two should be separate responsibilities with separate personnel bearing separate talents. (Do NOT let your programmers do systems analysis!)
Furthermore, it was discovered that without a clear, precise description of what to build, even the most talented programmers will happily use industry best practice to build the wrong thing, and that is worse than useless: it's a net cost to the business. This is something that programmers have in common with LLMs. So it turns out, in order to build software correctly and cost-effectively, you need to perform lots of systems analysis up front, then through a stepwise refinement process design and document your solution, yielding a detailed spec. It also turns out that LLMs, like human programmers, do just fine if you give them a detailed spec and hold them accountable to that spec!
So much of the "grunt work" of programming can be handed to the LLM—IF you perform the necessary systems analysis up front to determine what needs to be built! (Bryce's Law: Programming is a translation function, taking human-readable requirements to machine-executable instructions.)
As the AI era matures we are either going to see a revival of PRIDE—the original and still most complete software development methodology, but minus the programmers Milt and Tim Bryce loathed so much—or the entire collapse of software as a field.
"We really could produce working software faster with VB or with Microsoft Access"
Press X to doubt.
Playing devil's advocate here. My main take with the responses here is that the naysayers are assuming that the current capabilities of models will remain fixed for the next 1-2 decades which is questionable. They are saying that AI (now or in the future) won't eat a good chunk of my career opportunities because AI now isn't good now. That's the wrong viewpoint.
My views:
- Developers are expensive
- Most development isn't that hard or that creative
- LLMs can already do some of the sub tasks that the above kind of development entails
- If the above kind of development disappears, then there is only the harder, creative kind of development left
- Less development jobs and more developers will reduce dev salaries and increase dev competition regardless of the kind of development that you do. Any such change will be fairly slow and gradual
- The 2010s Everyone Can Code era is gone and is not going to come back as a result of the above
there's a huge flaw in the logic here but I can't pinpoint it
we've never had machines that can reason. today, they reason badly. tomorrow, they'll reason better. not all ai research white papers will pan out, but some will. the ai research community is acutely aware of the limitations in reasoning; it's their whole mission right now. 100% chance someone will make progress. Analogous to the chip industry or self driving, in that regard
incremental improvements in reasoning will broaden the dead zone for human developers
what difference does it make if in 20 years NASA still needs a few human developers but the rest of us are unemployed? ai agents still can't get you to the moon with one shot coding session in 2045? who cares?
the "still can't" we really need to be worried about is "politicians still can't consider UBI"
AI is like electricity.
Agentic IDEs are like power tools.
While most construction work today uses power tools, there are still lots of artisans productively using hand tools.
LLMs can be useful and developers can still be productive without them.
Things get weird when we confuse the developers with the power tools.
There is a guaranteed cap on how far LLM based AI models can go. Models improve by being trained on better data. LLMs being used to generate millions of lines of sloppy code will substantially dilute the pool of good training data. Developers moving over to AI based development will cease to grow and learn - producing less novel code.
The massive increase in slop code and loss of innovation in code will establish an unavoidable limit on LLMs.
Maybe we'll train the llms in our ways of using them, and the next generation of coding assistants will be another layer inbetween us and the code. You talk to the chief engineer llm who in turn talks to its cadre of claude code instances running in virtual tmux. \hj?
I think most of the progress is training by reinforcement learning on automated assessments of the code produced. So data is not really an issue.
But they're not just training off code and its use, but off a corpus general human knowledge in written form.
I mean, in general not only do they have all of the crappy PHP code in existence in their corpus but they also have Principia Mathematica, or probably The Art of Computer Programming. And it has become increasingly clear to me that the models have bridged the gap between "autocomplete based on code I've seen" to some sort of distillation of first order logic based on them just reading a lot of language... and some fuzzy attempt at reasoning that came out of it.
Plus the agentic tools driving them are increasingly ruthless at wringing out good results.
That said -- I think there is a natural cap on what they can get at as pure coding machines. They're pretty much there IMHO. The results are usually -- I get what I asked for, almost 100%, and it tends to "just do the right thing."
I think the next step is actually to actually make it scale and make it profitable but also...
fix the tools -- they're not what I want as an engineer. They try to take over, and they don't put me in control, and they create a very difficult review and maintenance problem. Not because they make bad code but because they make code that nobody feels responsible for.
That is a naive assumption. Or rather multiple naive assumptions: Developers mostly don’t move over to AI development, but integrate it into their workflow. Many of them will stay intellectually curious and thus focus their attention elsewhere; I’m not convinced they will just suddenly all stagnate.
Also, training data isn’t just crawled text from the internet anymore, but also sourced from interactions of millions of developers with coding agents, manually provided sample sessions, deliberately generated code, and more—there is a massive amount of money and research involved here, so that’s another bet I wouldn’t be willing to make.
I don’t recall seeing entire economies betting on 4GLs.
Not even a nitpick because the scale is indeed orders of magnitude different, but…
There was a lot of chatter, government attention, and both public and private money chasing 4GL’s in the 1980’s, due to what turned out to be (for the US, at least) a phantom “software crisis”. It was mostly for naught?
Same in Japan, where you can argue about the motivations of MITI’s “Fourth Generation Project”, but at its software core was a primeval 4GL in the form of Prolog. Their perceptions of a Japanese software crisis were ultimately more well-founded.
I have been programming professionally (i.e., getting paid for it) for a much more modest 13 years, but unlike a quite large portion of my peers, I am actually interested in the history of our field.
So, yeah, I agree.
‘Obviously’ AI and programming are antonyms. AI is defined as the ability for computers to do whatever it is that humans can do that (most) computers can't currently do. Conversely, ‘programming’ is whatever activity is required to fully take advantage of computer hardware that (most) humans can't currently do.
Both sets of goalposts are firmly affixed to their wheels :)
I did a bit of scripting trying to automate the TDD cycle given a task description. The problem is, that the LLM tends to jump forward and submit a full implementation instead of a minimal change. I guess the problem is, that LLMs are trained on complete solutions instead of minimal steps.
I really wonder why people aren't drawing comparisons with crypto/blockchain. In the beginning, there were also two camps: people who thought crypto would replace our entire financial system and everything would be tokenized on the blockchain, and another camp who predicted that within a few years bitcoin would be worth exactly zero and all crypto/blockchain companies would disappear.
The reality turned out to be somewhere in the middle. Crypto didn't replace our financial system, but it exists as a 1-2 trillion dollar segment serving a particular (though controversial) niche of the global economy. It's not going to zero anytime soon.
I think AI/LLMs will follow the same path. There's definitely a level of usefulness there. But we've clearly hit a ceiling since 3.5/4.0. Advancement has only happened in benchmarks and open source models. Also, the idea that a neural net that accepts a fixed amount of padded tokens and returns a list of probabilities will replace the complexities of the human brain is delusional at best.
The only real issue I see is that certain actors in the US have taken such large positions that unwinding them could potentially destroy the US economy at worst, or trigger a recession at best. But this mainly concerns the US, which is on an AI high at the moment.
The future of problem solving is problem solvers
[dead]
The future of weaving is automated looms, but sheep will still be needed to provide the raw materials.
Here’s how I see it. Writing code or building software well requires knowledge of logic, data structures, reliable messaging, and separation of concerns.
You can learn a foreign language just fine, but if you mangle the pronunciation, no one will talk to you. Same thing with hacking at software without understanding the above elements. Your software will be mangled and no one will use it.
> Your software will be mangled
the quality of how maintainable the source code is has no bearing on how a user perceives the software's usefulness.
If the software serves a good function for the user, they will use it, regardless of how badly the datastructures are. Of course, good function also means reliability from the POV of the user. If your software is so bad that you lose data, obviously no one will use it.
But you are conflating the maintainability and sensibilities of clean tools, clean code and clean workspaces, with output.
A messy carpentry workshop can still produce great furniture.
This is bean counter mentality. Personally just don’t believe this is how it works.
The intention/perspective of development is something on its own and doesn’t correspond to the end result directly.
This is such a complex issue that everything comes down to what someone believes
Software doesn't have to be good academically speaking. It just needs to furnish a useful function to be economically viable.
LLM's may not generate the best code but they need only to generate useful code to warrant their use.
Totally delusional. The article does not even try to figure out why any of this happened.
In all of the cases the main prediction that was made came true. The cost, especially the human cost, of developing some piece of software dramatically decreased. The only reason why the amount of programmers needed still rose was because the amount of software needed rose faster.
Clearly that trend will not hold forever.
>The hard part of computer programming isn’t expressing what we want the machine to do in code. The hard part is turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
And there is exactly one single technology which has ever been able to do this task, which is LLMs. Not addressing the elephant in the room, which is that an LLM can actually take such instructions and produce something meaningful with it, just makes the whole article worthless.
Everything in this article is just inverse special pleading. Since the last N times, the most enthusiastic predictions did not come true, this time only minor changes can happen. If LLMs are only a revolution on the scale of fast interpreted languages (which have significantly impacted what a small team is capable of delivering in terms of complexity), then they will drastically impact most of the software industry.
If these changes happen, and simultaneously the rate at which software is demanded does not also increase (why would it?), then the implications will be extremely serious. Especially if you are not a developer in an established position.
In past cases of automation, quantity was the foot-in-the-door and quality followed. Early manufactured items were in many cases inferior to hand-built items, but one was affordable and the other not.
Software is incredibly expensive and has made up for it with low marginal costs. Many small markets could potentially be served by slop software, and it's better than what they would have otherwise gotten (which is nothing).
>AGI seem as far away as it’s always been
This blurb is the whole axiom on which the author built their theory. In my opinion it is not accurate, to say the least. And I say this as someone who is still underwhelmed by current AI for coding.
The future of IT is going back to basics. People who know their karnough diagrams, their algorithm flow charts, memory models, state machines, algorithms, their sql CTEs, window functions, their obscure cpu/gpu instructions, people who can build a VM and a language on top from ground up will become even more valuable, because they can drive LLMs more effectively.
Your run of the mill bootcamp webdev/data scientists will have to educate themselves or find manual jobs.
Just a reminder that everyone copes with change differently.
> The foreseeable future of software development is one where perhaps “AI” – in a much more modest form (e.g., a Java coding assistant built atop a basic language model) – is used to generate prototypes, and maybe for inline completion on production code and those sorts of minor things.
This...
I have said this in multiple other comments and I 100% agree with the author's take.
I feel like AI can be good for prototyping sometimes but that's about it.
The reason is simple but I just don't trust AI system from not breaking given their volatile nature and I wouldn't expect to be paying for AI generated code that much/zero to be honest
And I will treat other people the same way I wish to be treated (golden rule) so why would I use AI when I can do things by my hand? (There are also 1000's of other discussions I can point in the moral,financial,even technological impacts of the whole situation)
That being said, prototyping as author pointed out feels the only good use to me because at that point you are building it for yourself or a small community. I think a good use of AI can be to build open source prototypes of softwares and if you really like something, one can rebuild it or build it the way they like it as an example.
Prototyping can be similar to the drag n drop and other things and honestly wordpress did reduce the number of programmers needed to maintain a website and for good measure, I think AI is similar to this then anything else and even then small models will win as author states and so the financial point of these companies training these usually becomes moot.
So till the time being, I use these free/subsidized websites to get prototypes to be generated but I feel as if long term, I can find projects which heavily resonate with me and I can build them/learn languages catered to them and build my mental model of thinking around them
Although I must admit, prototyping using AI models definitely gives me Imposter syndrome and I sometimes feel that perhaps its a learning opportunity and that I can perhaps instead spend hours but I don't really know too much about it so its something that I am figuring out as we speak
Like there is this feeling that I can spend more hours and feel more "proud" of what I did if I did it without AI than if I did with AI since perhaps the journey matters too. I really don't know but just weighing all my thoughts on the matter as I thought about it really closely once.
Edit: although I am not sure about calling AI wordpress-like since then it would mean that I am giving significance to AI similar to wordpress, honestly I respect wordpress more but not sure, perhaps they are similar, perhaps they are not, I don't really know perhaps but what I do know is that the financial impact of the AI bubble is gonna impact all of us negatively.
[dead]
[dead]
[dead]