It's August 9, 2026 and if you're a software engineer who hasn't had multiple "holy shit, I can't believe it just did that" moments, it's time to consider a new trade.
I find this to be an incredibly myopic viewpoint. Software engineering is not defined by a single tool or technology, but rather how we design, implement, and maintain processes of value we want to automate or scale.
LLMs will certainly be an aide, but assuming adoption of them is required across a whole _field_ ignores whole classes of problems, domains, and constraints the production of software covers.
Rather, we should be wary of allowing our skills and hard-earned knowledge to atrophy by over reliance on new technology that is far from perfect, reliable, or even universally available. These tools more than any before suffer from the junk-in-junk-out problem and I’d much rather work with someone who knows their fundamentals than someone who knows their way around a the LLM of the month.
On the contrary, taken at face value I find the GP comment to be spot on.
They aren't saying LLM adoption is required across 100% of the field. They are pointing out that LLMs have reached an impressively capable state, and someone insufficiently inclined to test new tooling that they still dismiss LLMs as "just fancy autocomplete" is exactly who gets left behind when technology advances.
Two things can be true at the same time, 1) that LLMs are not required across a whole field, and 2) that software engineers unwilling to acknowledge their utility have as much a place in the future as the software engineers of 50 years ago who refused to use a compiler.
Can you elaborate on how someone would get "left behind"? Isn't the whole point of LLMs that they use natural language and require less effort?
If they're so easy to use, wouldn't the opposite be true? i.e. people who over rely on LLMs become weaker at the core competency? Nobody gives a rat's ass if you did something in an hour or took all night. The deadline is still next week because of all the meetings. What's the point? Anyone at any point in human history can tell you that doing too much too early has extremely high odds of failure. You're much better off thinking about the business concerns at hand instead of getting lost in the weeds playing with the code.
There's also zero chance of the cadence speeding up because software engineers were never the bottleneck, and LLMs don't work so well for everyone else's job.
If you can't pull rabbits out of hats when the time is right without an LLM, you're already at a disadvantage compared to everyone else who can (anyone who isn't a junior dev today).
> people who over rely on LLMs become weaker at the core competency
What if what people become weaker at, is no longer the core competency? Then people who maintain their skills at what used to be the core competency, at the expense of what is actually the core competency, will be left behind.
The rest of your comment, re: nothing taking less than a week because of meetings and software never being the bottleneck, is not something generally true across the industry. I'm sorry that that has been your experience; it does not sound pleasant.
I'd like to see evidence of this reality you're conveniently imagining to sow doubts among the uninitiated.
You're correct that the focus is no longer just writing code after a few years of experience, but it doesn't change the fact that being held accountable for the code means it is one of your core competencies.
You cannot seriously believe anyone is going to throw the baby out with the bathwater by giving away their power to "AI". Why else do you think a dev is in all those meetings? Why do they get paid to "hurry up and wait"? That's not inefficiency. That's the real work.
Those who find this reality unpleasant have always been the ones to switch careers (and then realize all careers are the same). I'm not sure what you're trying to say other than you'd like to muddy waters because you really like AI and are allergic to code and accountability. Do not be so naive.
> Why else do you think a dev is in all those meetings
Piss-poor management by scleratic and top-heavy organizations, mainly.
You're trying to start a fight by casually accusing me of stances I didn't take, mixed in with insults. There are healthier ways to deal with your insecurities.
Nothing I said is incompatible with devs being responsible for what they produce. Though you seem to be saying that someone should be fired because their code managed to hit a nondeterministic compiler bug? Why didn't they double check the assembly? They should take accountability.
Okay. Please generate using an AI model code for a safety-critical system which is able to be incorporated into an aircraft and that passes the coding standards and requirements in that domain and come back and tell us all about it. Surely, if AI was so good across the entire domain of software engineering, this would be trivial to do.
Edit: although you might be subject to an NDA... But this is pretty much my test for "AIs will take all the jobs": can it write truly safety-critical software yet?
Most programmers are not experienced enough to write such code themselves off-hand, but more importantly, the safety-critical systems are made safe by following a strict process, not by skills of individuals, which makes it orthogonal to involvement of LLMs.
Also, weird choice of example. 99.9% of coding is not safety-critical, so whatever reservations this would imply (even if it actually doesn't imply any), don't apply anyway.
Why? This has already done via existing processes. My point was to illustrate that if the future is LLMs then surely these processes wouldn't be needed anymore? After all, the LLM would just... Do it itself.
> ... the safety-critical systems are made safe by following a strict process, not by skills of individuals, which makes it orthogonal to involvement of LLMs.
And an LLM that is going to take all the jobs wouldn't be able to execute that process independently and with little oversight?
If my example is, to you, not a good one, what would you rather I use? Most of the common ones can be overly trivialized/minimized (particularly by someone who is uninterested in admitting that LLMs can't do something). That is not to imply that the gp is this kind of individual, but far too many people who I ask to do this (or something similar) are exactly that kind of person: believing that LLMs are insanely great and can't admit (or see) the cons.
Long bet: the NTSB will require all transportation software to be submitted for independent review, and that review process will be heavily automated by AI, within 5 years. Take it?
If we assume the current administration (and the following one) continues to be bullish on AI, then this is a suckers bet. Assuming the next administration isn't too busy cleaning up the messes of the current one.
I recently asked it a series of technical physics questions about a field I used to be involved in to evaluate whether it'd be useful for doing research, and literally every single answer it gave was critically wrong - even for basic questions. Its certainly true that I went "holy shit", but not in a good way
I did but it was followed by "holy shit now I gotta review this +3000 -500 LOC PR full of subtly wrong abstractions, needless diversions and incorrect assumptions".
People keep repeating your sentiment here but I simply can't follow, are we even on the same planet? Or did everyone switch to just not caring about maintainability and code quality anymore? Or are your work tasks simply so mindnumbingly, stupidly simple that even an AI can oneshot them properly?
I mean this honestly btw, not dismissively like some sister comments. The gap between the productivity increases people report on HN and what I experience myself is insane. In fact, if I factor in the procrastination I find myself doing on dotting the i's on a supposedly "one-shotted" AI implementation of a nontrivial feature, I think the AI actively slows me down.
The only way I've found that I can actually use AI productively and sustainably is in very small tight loops and, well, at that point it's not that much faster than just typing in the code (with the occasional "Cursor Tab" complete).
You have to have a team of agents with different roles reviewing that for you. An Advocate, a Skeptic, an Architect, a Security Engineer, a Disgruntled User, a Single Mom, a Clueless CTO, etc. each provides their unique prospective on the change. Then you have a Remediator and a Consolidator to address the feedback. Finally a Liquidator in case of a catastrophic failure.
I prefer to have a Clippy agent that identifies code that should be copied and pasted into random locations for no good reason. You may think it's not necessary given how LLMs operate, but I have found it's critical for 10x gains.
I think to effectively use LLMs in a controlled way, they can help with three things:
- Help you pump out boilerplate, or otherwise "obvious" code, that you can review at a glance
- Help you gain understanding, either through rapid plan writing/revision or code quality/architectural/security analysis. The gotcha is that it can only help along one axis at a time, or at least can only communicate information sensibly to humans this way
- Cross-cutting or fuzzy matching across a codebase. This is the hugest win, like "replace this pattern with the new approach everywhere". This used to be the scariest sort of task, and now it is one of the more stable things LLMs get right.
Where things go off the rail is when you want it to plan AND implement features. The blind spots of LLMs are not where they are for humans and way more work to anticipate. You have to stay on top of the bucking bronco, but you CAN move much faster if you can architect your system so more tasks fall in the "obvious" bucket - that is where the art of engineering still lives. Human understanding remains the goal.
I've had a similar experience on huge codebases written entirely by an aI. It works for very very specific cases (e.g., Opus 5 has helped me with SIMD optimizations) but I wouldn't trust it to do a 10000 LoC project even with agents just because of the complexity problem and the shear amount of code I have to review. Or I'll have to change a bunch of things because the LLM made assumpts I didn't specify and it didn't ask about (e.g.: I have had to repeatedly tell these models to use std::atomic_flag and not std::atomic<bool> for a project I maintain because for some reason I cannot fathom, they love, love using the generic std::atomic<T> template, and they love using std::atomic<bool> where an std::atomic_flag would be better). Just little things add up, and before you know it I'm spending more time fixing it's issues than I am making progress.
Very, very senior dev here who has never taken a shortcut in his life. Don't mean to sound like a prick but you're doing it wrong. You have to find your own path through this stuff. It works, promise. I was in your shoes six weeks ago.
Wait, only six weeks ago? That's not long enough to be reporting success, genuinely. Come back in a few months, bare minimum. I'm far from a skeptic, but I've also personally had a number of moments over the past 12 months where I've declared "this is the future!" about some new app I vibe-coded, or some new workflow I started following, only to abandon it a few weeks later. And it's not just me. Check back in on many of the vibe-coded projects or AI tools you see shared and you'll see the same. It's happened at my work too — people taking over entire meetings to discuss their new revolutionary AI workflow and then, a week later, nothing...
A big problem is that these codebases rot. Agents move incredibly fast at first, but then as you pay less attention (or perhaps no attention at all) to the architecture, they slowly fall to bits. So then you decide, I'll use AI to rewrite it! And it gets better for a while until, well, you get it.
That's not to say there isn't value here, there absolutely is, just — chill. A little.
Ah, the classic HN "I keep Wikipedia's list of logical fallacies on my bookmark bar" retort.
“No true Scotsman” would require me to redefine “senior developer” to exclude people who disagree with me. I didn’t.
And “you’re holding it wrong” is a strange objection to a tool that, like Git, rewards learning how to use it. The question is whether that learning pays off.
It can and does and may choose to do so unprompted. That was one of my "holy shit" moments. Previously I watched it spit out nonsense to get around edge cases and avoid tests and uttered many of the things I read in this thread. Then the new models hit.
Find some code you're proud of. Find someone else's code you admire. Find something that's been stable for 20 years with no bugs reported. Feed it in, ask it to look it over, and prepare to be humbled.
Nah, for what was broadly avaiable, last year it was still in the area of better custom stackoverflow answers. A good search engine for code. Helpful, but I don't remember mindblown moments.
This year we have agents work with complex codebases. That was and still is mindblown to me.
I respect the people who still haven't tried. They held a firm line when the rest of us were drawn to the shiny new thing. They're not becoming dependent on yet another centralized service (let's be real, the big centralized models are still way better than the open-weights models that most of us can run, particularly for coding). They can still develop software with nothing but their own computer, and that computer doesn't even have to be particularly new.
I had DeepSeek 4 Pro do a very good job yesterday of loop-unrolling and SIMD-ifying (both SSE/AVX and ARM Neon versions) some very old scalar Col3f image processing and resampling/resizing C++ code I hadn't touched in 12 years or so.
It also wrote some unit tests that validated the kernel sampling weights, and wrote some Jupyter notebooks to go along with the kernel algorithms as comparisons.
It's not just web dev... It helps (a lot in some cases) if you ask very specific things rather than just "make this vague thing", but I'm more and more coming round to the conclusion it is now a useful dev tool (until two months ago I was a sceptic).
> image processing and resampling/resizing C++ code I hadn't touched in 12 years or so.
So an unimportant, personal project. People seem to extrapolate being able to do something cool into being able to do useful work, which is what this whole discussion is about.
It's an example of useful work. 11 years ago, I would have been able to use that code in production for the company I worked at at the time, and the conversion would have been very useful.
I'm also using Github Copilot at work, but I can't as easily talk about what I'm doing there.
The tests and notebooks maybe: not the unrolling and re-architecting to use masking SIMD-ification. I used to do SIMD stuff a lot over the last 17 years, and it would have taken me probably a day to do that (convert 7 algorithms, all with support for various wrapping/mirroring/clamping extent-handling, so around 800 raw source file lines of templated C++) to use SIMD - and well.
Then it probably would have taken me at least half a day to think about what tests to write and to make them.
It did it in around 5 minutes. I had to check it, and it wasn't perfect, but it compiled, ran, and was very close.
You could convert ~800 lines of scalar float processing templated C++ code that used mixins for wrapping logic and float/double to well-optimised SIMD code for two different ISAs (without using wrapper class helpers, it wrote the full intrinsics) in under 5 minutes and write tests for them at the same time?
This is a sifferent point than what the thread started with (speed vs. correct output for hard problems). Yours stands, but it changed the direction of the discussion as I understand it. Hence the pushback.
