Reading the code does not mean you understand the code. One lesson that experience in software gave me: I never understood the code. You think it works a certain way, until you find out that it doesn't.
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.
Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.
Before 2024, I once went to an ATM to retrieve money and selected 50. Note that I selected it from a menu, not typed it. The ATM then told me that it cannot give me 50 because it is not a multiple of 5.
Huh? We are spending a lot of money. (which we were doing before). However we are fixing a lot of bugs. 2024 was not that long ago, it is insane to think we might have fixed all the bugs in that time. I have personally used an LLM to fix a few long standing rare bugs that were hard to figure out. Those bugs are now gone, but there are still many more that we haven't discovered.
LLMs are a great thing for bug fixing. However they are not a miracle. You still need to do all the other things about finding, testing and fixing bugs.
You also need to care about bugs - vibe coding rarely cares about bugs.
I mean, I think the problem isn't that the LLM doesn't know how to code, it's that companies are expecting 3-5x velocity with the bottleneck of code review and testing becoming much more severe than before
if you're an MBA-brained exec who doesn't actively use LLMs to code and you just believe whatever slop it outputs at first without checking it, you're not going to realize how recklessly it can be used, how you need to be critical and skeptical of its outputs, that you need to explore it's reasoning and logic (which is still really easy compared to understanding legacy code and barely takes any time!)
say you also believe all this marketing hype about 'how dangerous (ie capable) AI agents are.' LLMs can do anything you think so you just say 'ship it' without building out the tooling and capabilities to enable faster code review and better tests. and to keep the shareholders happy, you start cutting jobs that you can't directly connect to a KPI (ie the platform/SRE team who would be the ones who can trial, onboard, and maintain those capabilities for your teams)
and from this, suddenly a lot of debit card stops working and the only one getting the blame are individual SWEs trying to hit their sprint velocity. the fact that you fucked up the whole SDLC real bad with your incompetence gets you a golden parachute and you job hop to a better paycheck. rinse and repeat
The problem is absolutely that the LLM doesn't know how to program (or anything else for that matter). It's why they are ineffective tools - either you YOLO them and get buggy software, or you check up on them and it takes just as long as it did before.
depends on how you use it? I do a lot of scripting with it that makes my life a lot easier. paired with a good set of skills and some greppable context docs, the job gets done fairly easily and well. most of the misses are just oversights and overly-complicated solutions and there's plugins like superpowers and ponytail that help mitigate it somewhat
plus, it might just be me and my love of RPGs, strategy roguelikes, and 4X games but figuring out meta-process improvements for bespoke plugins and tooling feels very rewarding. being able to consistently have agents, for example, update a changelog in a straightforward and concise way whenever they're done with a slice of work without having to micro-manage it feels great and then allows you to iterate and improve on the outputs as you continue using it. it's something like a gamified loop, almost but the end result is you're better and faster at your job
> Your debit card transactions for example worked.
I've built payment rails. Six nines SLA, high capacity, resilient distributed systems.
I haven't written a single line of code since February, and I don't think I ever will again. These systems are incredibly good at replacing much of our work. They're only going to get better.
Rather than debating if these models are good (they are), we should be trying to figure out if most of us will still be around in three years. You don't need a two pizza team anymore.
"Look to the person to your left and to your right. Only one of you will remain by graduation" kind of energy. I'm not sure all of us is going to be in this career much longer. We'll have to see what the demand side looks like.
Most of developing good code is not code. I think the person to my left and right will both be here in 3 years despite us all using LLMs. We will spend even more time figuring out requirements, testing to ensure the code meet them and such. Those things were always most of the effort, and while LLMs help with that too there is so much work to be done that we will still be used.
On the other, my local pool company is hiring a software engineer and hardware engineer because with AI, they can replace a 2 pizza team as you so succinctly put it. So no two pizza teams but that doesn't mean all the pizzas are gone, they're maybe going to be spread out and not concentrated in CA, between orgs you might not have thought as "tech" before.
Does it? First line of defense is now an LLM with the runbook in its context and the human in the loop being woken up at 3 am, half asleep, just needs to make sure it doesn't rm -rf something.
Just yolo all the development and maintenance, and ops. There shouldn't be any problems, right? Coding is solved. Models are basically perfect at this point according to Astra's one shot performance on creating stuff in Blender, so...
>I haven't written a single line of code since February, and I don't think I ever will again. These systems are incredibly good at replacing much of our work. They're only going to get better.
Ah, so you're still a few months out from the "yeah, maybe I don't really love this and maybe it won't ever actually work as well as I thought" turning point.
I am not sure that is true but I don't think it would be strange or incompatible if you consider base rates.
Coding can have become cheaper and better. A lot of people who would not have been able to write software before now are. Add the ones that already have been able to write software, who will now use AI to do it better, and you might net "software is getting worse".
Strange that GP never claimed software doesn't function without LLMs and yet you strawman-man them then make some bad-faith dismissal of their experience by accusing them of having psychosis.
efficax · · focus · HN ↗
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.
Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.
12ag5a · · focus · HN ↗
This sounds like a typical testimonial whose mind has become captive to Claude. It is like Scientology.
bananaflag · · focus · HN ↗
anon7725 · · focus · HN ↗
gf000 · · focus · HN ↗
Let's be honest, most software always sucked. They are chock full of bugs, and we just often look back in time with rose tinted glasses.
MattDamonSpace · · focus · HN ↗
lazystone · · focus · HN ↗
ofjcihen · · focus · HN ↗
How can you not see the progress?!
bluGill · · focus · HN ↗
LLMs are a great thing for bug fixing. However they are not a miracle. You still need to do all the other things about finding, testing and fixing bugs.
You also need to care about bugs - vibe coding rarely cares about bugs.
ofjcihen · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
quatotor · · focus · HN ↗
[dead]
rowanG077 · · focus · HN ↗
anotha_one · · focus · HN ↗
[dead]
cat-snatcher · · focus · HN ↗
bluGill · · focus · HN ↗
You should seek professional help about your emotional issues.
cat-snatcher · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
eureka7 · · focus · HN ↗
pprotas · · focus · HN ↗
paimapi · · focus · HN ↗
if you're an MBA-brained exec who doesn't actively use LLMs to code and you just believe whatever slop it outputs at first without checking it, you're not going to realize how recklessly it can be used, how you need to be critical and skeptical of its outputs, that you need to explore it's reasoning and logic (which is still really easy compared to understanding legacy code and barely takes any time!)
say you also believe all this marketing hype about 'how dangerous (ie capable) AI agents are.' LLMs can do anything you think so you just say 'ship it' without building out the tooling and capabilities to enable faster code review and better tests. and to keep the shareholders happy, you start cutting jobs that you can't directly connect to a KPI (ie the platform/SRE team who would be the ones who can trial, onboard, and maintain those capabilities for your teams)
and from this, suddenly a lot of debit card stops working and the only one getting the blame are individual SWEs trying to hit their sprint velocity. the fact that you fucked up the whole SDLC real bad with your incompetence gets you a golden parachute and you job hop to a better paycheck. rinse and repeat
bigstrat2003 · · focus · HN ↗
paimapi · · focus · HN ↗
plus, it might just be me and my love of RPGs, strategy roguelikes, and 4X games but figuring out meta-process improvements for bespoke plugins and tooling feels very rewarding. being able to consistently have agents, for example, update a changelog in a straightforward and concise way whenever they're done with a slice of work without having to micro-manage it feels great and then allows you to iterate and improve on the outputs as you continue using it. it's something like a gamified loop, almost but the end result is you're better and faster at your job
InsideOutSanta · · focus · HN ↗
It must have been a huge shock when you were suddenly transported from a working parallel universe into ours back in 2024.
echelon · · focus · HN ↗
I've built payment rails. Six nines SLA, high capacity, resilient distributed systems.
I haven't written a single line of code since February, and I don't think I ever will again. These systems are incredibly good at replacing much of our work. They're only going to get better.
Rather than debating if these models are good (they are), we should be trying to figure out if most of us will still be around in three years. You don't need a two pizza team anymore.
"Look to the person to your left and to your right. Only one of you will remain by graduation" kind of energy. I'm not sure all of us is going to be in this career much longer. We'll have to see what the demand side looks like.
319286 · · focus · HN ↗
bluGill · · focus · HN ↗
nullsanity · · focus · HN ↗
[dead]
ModernMech · · focus · HN ↗
On the other, my local pool company is hiring a software engineer and hardware engineer because with AI, they can replace a 2 pizza team as you so succinctly put it. So no two pizza teams but that doesn't mean all the pizzas are gone, they're maybe going to be spread out and not concentrated in CA, between orgs you might not have thought as "tech" before.
whateveracct · · focus · HN ↗
on-call still exists. have fun round robin'ing that with 3 engineers.
fragmede · · focus · HN ↗
latentsea · · focus · HN ↗
whateveracct · · focus · HN ↗
wonnage · · focus · HN ↗
latentsea · · focus · HN ↗
Ah, so you're still a few months out from the "yeah, maybe I don't really love this and maybe it won't ever actually work as well as I thought" turning point.
dolmen · · focus · HN ↗
Note that AI hasn't yet solved making pizzas.
lbrito · · focus · HN ↗
/s
jstummbillig · · focus · HN ↗
Coding can have become cheaper and better. A lot of people who would not have been able to write software before now are. Add the ones that already have been able to write software, who will now use AI to do it better, and you might net "software is getting worse".
TaLiTr · · focus · HN ↗