> which shows how far windows has fallen as a developer environment,
Be mindful of living in an echo chamber. HN is one. There is a startup/SV-oriented culture here, which selects for a specific niche of people that is not representative of the general population. Going by this forum, you'd also think Java and especially C# were dead languages by how many votes and comments their threads get. Yet in the real world, Windows dev environments dwarf Linux, and Java/C# are everywhere in enterprise.
Yes, the previous fad (crypto) killed consumer GPU prices for good. I don't believe anything has compared on price-performance to a 1080 in the 10 years since.
Also the enshittification of software might count? You used to own Photoshop for life, now you're expected to pay a subscription for life. And legal onslaught, too. Encryption and consumer VPNs are on the chopping block in much of the world at the rate things are going. The end goal of governments and corporations alike is to remove the ability of consumers to own hardware they control. We are rapidly moving towards a future where you will only be able to access the internet and government services with a "trusted device", which will be a thin client with a TPM, biometric verification, telemetry of everything you do on it, and which will require paying an ongoing subscription to use.
As far as I can tell, in terms of MSRP, 980ti was $649 at launch. 1080 and 1080ti were both $699 when they hit the market.
$699 in 2015 (when the 1080 was new) is ~$975 today, adjusted for inflation.
$975 is pretty close to the launch MSRP of a 5080, which is "just" $999. (We can't actually buy them for $999, of course, but we couldn't usually get 1080 cards at MSRP during the mining frenzy a decade ago either.)
The big difference here is that by the time the 2080 had saturated the market, you could regularly find a 1080 for ~$300 (I paid $275 for an EVGA B-stock model).
Whereas today, with the 5000 series in the market for quite a while already, a 4080 is still well over MSRP
I can think of nothing I'd like to use less than a database or filesystem vibecoded by Gas Town-flavored psychosis. Roleplaying with LLMs is not the secret to producing amazing code.
This is one of those completely factual statements that is not factually complete.
Obviously not all (tech) companies will prove to be successful.
Although, if we define success as “was acquired, investors / founders came out financial better off” then both absorbed and successful can be true while consolidation never was a concern.
This piece is either a psyop or written by the victim of a psyop. I believe the former is more likely. It establishes for granted that LLMs produce more optimized code than performance-oriented humans do. This could not be further from the truth, and I think any human who writes low-level performance-oriented code knows this. It's not even remotely close to being close; LLM code is abysmal if you look at the details. I think the only way you could come to this misconception is if you were not a low-level programmer; certainly LLMs can produce more optimized code than whatever abominations JS devs do, although even this is not a given.
Take, for example, Claude Desktop and Claude Web. They recently bragged about reducing their first paint from 4500ms to 1000ms. For an interface that displays text and sends/receives HTTP chat requests for more text, let's remember. This is from a frontier company that can allocate infinite compute to the frontier models consumers don't even have access to. Let's not get into how it consumes gigabytes of memory. We wrote more efficient GUIs than this in the 80s with 128kb of RAM on a 4mhz CPU.
These despair pieces do not reflect reality in any form, and they're so far from reality that I believe this is more likely to be an article written intentionally to deceive people who don't know better than it is to be genuine. Performance engineer jobs are not going anywhere. LLMs are not generating better compilers nor better kernels than what exists. They're producing insanely inefficient CRUD garbage.
> It establishes for granted that LLMs produce more optimized code than performance-oriented humans do.
I didn't read the piece as claiming anything of the sort. I read it as claiming that employers don't care.
The author is well known around here and has demonstrated quite a bit of low-level technical proficiency; see previous submissions https://hn.algolia.com/?q=purplesyringa.moe .
> Take, for example, Claude Desktop and Claude Web. They recently bragged about reducing their first paint from 4500ms to 1000ms. For an interface that displays text and sends/receives HTTP chat requests for more text, let's remember. This is from a frontier company that can allocate infinite compute to the frontier models consumers don't even have access to. Let's not get into how it consumes gigabytes of memory. We wrote more efficient GUIs than this in the 80s with 128kb of RAM on a 4mhz CPU.
Developer tolerance of low performing software has been a problem since before LLMs though. The whole industry seems to think O(seconds) is a perfectly acceptable amount of time to launch a program. For decades, as computers got more and more powerful developers tolerated proportionally poorer and poorer performance. There's almost no such thing as a "performance-oriented human" anymore outside of a few niche industries, and nobody is really producing and sharing much hand-optimized high-performing code anymore, so it's no surprise that LLMs trained on the Internet are not good at it either.
I think it's tied to the fact that many developers are given unreasonably capable systems (compared to end users) for running their software, or else exclusively test on small data sets or without considering resource limitations or real-world situations.
I've seen plenty of product demos that work fine with test data, but once you introduce real world things like: 200+ concurrent users that need to do more than just navigate to the 3 most easily demonstrated screens; application is hosted at a data center in another state; making that hosted system be a shared tenant; introducing data of real-world complexity; making the client system be a system spec'ed for a basic office worker 5 years ago; installing web filtering and other applications and not only running your one application.
Suddenly, loading N,000 records into a dynamic gridview table on a page load becomes a real bad idea, and the occasional needing to view logs or audit trails that reach N,000,000 records to load into that same dynamic gridview table means the site just times out.
It's a similar reason why you can sometimes find that you have to scroll right and left on a site. Well, that's because the dev has multiple 32-inch monitors in 4k or 8k, and they're not designing the interface for the 1080p laptop screen that most of their userbase actually has.
> LLMs are not generating better compilers nor better kernels than what exists. They're producing insanely inefficient CRUD garbage.
Exactly. People always talk about how LLMs can produce CRUD user-apps and then say, ok there's no more reason for humans to write code anymore.
These CRUD apps are the most trivial, simple things. The AI agents make inferior, bloated, unmaintainable, and unreliable versions of these simplest of things which have already been done to death.
There is a a whole other realm of programming innovative tools, performant systems, truly insightful solutions that people will need to keep working on. No AI agent swarm is creating the next FFMPEG, or coming up with and implementing the whole idea of using monads and do notation. They're not creating true progress (spam-solved math proofs have yet to hold out as solid and useful), only making half-baked, inferior copies of the patterns that are already out there.
Saying, "Some programming is being replaced by AI agents therefore all programming will be replaced by AI agents," is a big converse logic error.
Yes, if you one-shot some code with an LLM, it can be terrible. But if you let it profile and optimize it, there is no obvious limit. LLMs have more patience to investigate performance issues and fix them than humans.
Again, I wish this wasn't so, but I see it in my job daily. There is code in my projects that is vastly faster because of LLM optimizations. Not only can they find more in less time, but they find things I and my co-workers would not have thought of.
I'll take your claim that I'm capable of writing a psyop piece as compliment :) Truth be told I'd rather be writing a psyop arguing the opposite point than dealing with these emotions.
To your main argument: I absolutely agree that LLMs are terrible at producing working code, or efficient code, and that they're incapable of solving lots of important problems. I've seen LLMs make embarrassing typos, patch vulnerabilities with differently vulnerable code, and go through the motions of optimization as if blindfolded.
That is, however, not the central matter here. IMO, at present what management thinks LLMs are capable off has a larger impact than what LLMs are actually capable off, and while I'm hoping that the market will regulate itself once more and more slop projects break down, that'll take time, and I'm not confident that LLMs won't improve sufficiently by that point that the most glaring mistakes will be fixed. Of course, new and non-obvious issues may still be present, and they may cause trouble at a later point, but again, that won't happen immediately and I think we'll just end up in this infinite loop for the time being.
I will also add that AI companies' claims affect the general public's perception of the acceptable level of software quality. If Anthropic says 1000ms is great, and other companies follow the same approach, people will consider that the norm and not demand better software. This enshittification has started a long time ago -- just look at how bloated Windows and the web are -- and I don't think it's going to end just because we know things can work better.
Taking a step back, I think it's really a question of how many people will understand the value of what people like you and I can deliver. That number has been falling bit by bit before the LLMpocalypse, but now it's just becoming abysmal.
I understand the fear that perception matters, and it does, which is why I take issue with articles like this and use terminology like 'psyop'. You are effectively harming your own cause when you write things like this:
> If anyone can point an LLM at slow code and it automatically finds a hot loop and uses a trick it found somewhere on the 'net to vectorize it, there is little point in hiring someone with a focus on that.
If you yourself are saying there is no point to hiring you because an LLM can do what you can do, when it actually can't, you are actively contributing to the perception you don't want to proliferate. And although I am financially set from my own work, I am also opposed to that perception proliferating because it is wrong, and the discourse around blatantly untrue things is extremely tiring. We need to bring perception closer to reality, not perpetuate the divergence of perception from reality. OpenAI and Anthropic have an extremely vested interest in influencing both industry and consumers to believe things about their products that are not true, because their dubious financial future is staked on people believing those things, but we don't need to help them along.
On the one hand, the Claude code thing was indeed a weird brag, because they took shit performance and made it suck slightly less. It's not in the same ballpark as getting a 2% boost in an already highly optimized system (e.g. Google search results page lets say).
But it was also a tale of simply needing to tell the models what to care about. They built metrics (I'm sure they vibe-coded them) and then told the system to optimize itself to those metrics. And it sort of worked. Of course most LLM code is not performant by default, you still have to prod it to optimize itself. You can't one shot it yet. But nothing about the trajectory of this stuff tells me it won't get there some day soon.
Even if LLMs aren’t producing more performant code today, them solving frontier math problems (especially discovering new optimizations) suggests they’re close. You can algorithmically judge performance, and recent advancements have been in the algorithmically judgeable.
I also thought that, and then I started pointing Claude at various projects and having it look for optimizations. The projects themselves were, of course, largely AI-generated. What I found was that simply asking it to improve performance could indeed help, but if I pointed out specific architectural issues - like storing massive graphs in a giant JSON blob - and then recommended a solution (normalize, store in SQLite, recursive CTEs to walk it), the performance ceiling went WAY up.
Now, you could argue that AI didn’t fix that, I told it what to fix, and it just wrote the code. That’s valid, I suppose. The view I’m coming around to is that LLMs do know how to write performant code, but their corpus is so full of garbage that you have to tell it explicitly what you want, which requires you to know how to spot the problems and solve them.
I will not make any claims that they can write kernels or compilers well, because I haven’t tried to do either of those, on my own or with an LLM.
Another anecdote: yesterday, I got tired of dealing with Mumble on my LAN (random audio issues on the Mac clients, poor echo cancellation, etc.) and asked Claude to build a replacement. I gave it a rough spec, including non-goals (private use only, so no encryption needed, and I don’t care about supporting a large number of clients), then told it to build it in Rust, supporting MacOS and Windows both natively. Two hours later, it worked. Not just kind of, it worked flawlessly on Macs and Windows, and the audio quality and echo cancellation was perfect. The only bug I found - which it fixed - was denormal numbers was causing relatively high CPU (~1/2 of a core) usage on Windows due to x86_64 handling of that. The binary is 5 MB. It ran its own echo cancellation training while writing it to tune parameters. It implemented RFC 2198 without me mentioning it (hell, I didn’t even know about it - it’s fascinating!). When I fed it back some logs, it saw that one client had higher latency than expected (meshed WiFi without a backhaul), and then proceeded to create a network simulator so it could test various latency and jitter scenarios to solve it. While doing so, it also determined that Windows was lying about its latency numbers by 25 msec, and addressed that.
So again, I think LLMs are capable of excellent work, you just have to know what you need to ask for.
Actually LLMs are creating better compilers than what exists. In 2 weekends I let a LLM write almost fully compliant re-targetable C23 compiler (except for a few C library related things that are worthless for its targets) with state of the art optimization for five 8 and 16-bit fairly different architectures. For PIC16F/18F it's slightly better than XC8. For 8051 it's waaay better at optimization than industry standard Keil C51, and of course sdcc. Dev process found several pretty startling miscompilations that XC8 is prone to. And it's tiny. Codebase is like 0.5 MiB with data file for all ~1100 PIC microcontrollers that normally take gigabytes in XC8 taking 350 KiB.
So it's optimized both on code/data size needed for the compiler, which is like 3 orders of magnitude smaller. It has better coverage of C23, and it produces smaller, faster and more correct code. :)
Your comment feels like it was written 18 months ago.
A vibe coded typescript compiler runs twice as fast as the one maintained by two dozen people led by some of the most brilliant language and compiler experts out there backed by thousands of open source contributors.
All of that by saying "here's the tests, implement it in rust".
> Your comment feels like it was written 18 months ago.
AI bros have been making the same claim for the last 3 years. It wasn't true then, it isn't true now, and it won't be true the next time either. You just aren't willing to admit the emperor has no clothes.
LLMs recently optimized integer multiplication and matrix multiplication beyond the known theoretical limits.
If you tell them to optimize and give them evals and targets, they will optimize. And they will be more thorough and diligent about it than you.
We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.
> We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.
As a categorical generalisation, this is absurd. Much depends on much, and the devil is in the details. In certain domains, this might be true, though the word "better" is doing a lot of work there. It is certainly not true in all domains; my consulting practice, where code is written by hand, is thriving, and my clients are mostly AI companies who have discovered the limits of "vibe coding" in this particular area.
Thank you, this is coming close to my own reaction to the article.
Folks reading this: none of this bullshit and hype is inevitable. You don't have to be delusionally enthusiastic about something just because a lot of people around you are.
Absolutely right! Honestly, I hate AI even though it COULD make me 10x more productive in what I do. I can think of a dozen tasks that AI could help me with.
Audio processing for instance: I process audio by hand, it's more of a rote task, and it takes me hours a week to do it. AI COULD give me what I want in probably one minute. One minute instead of one hour.
But firstly, I've built up my audio processing skill over years and I enjoy it. It's calming. It's not creative, thinking up new stuff-type work but it's calming. And secondly, I want to do things myself. I don't want to let a machine do everything so I can concentrate on the high level stuff.
In fact, what I've found is that my mind works best when I'm NOT concentrating on high-level stuff. When I just go about my tasks by hand.
Do I write code to save time? Yes I do. But I write the code by hand and I understand how things work from first principles, as far as possible of course.
So, I don't use AI. AI could take away hours of work for me and I don't use it because I hate it and I hate the idea it represents.
> You could dream all you want about how you would write better version of claude desktop. Fact is: you didn't. And you never will.
I already did, actually. I work in an LLM startup that produces small models for specialised purposes and I wrote our frontend interfaces, which are vastly superior to both Codex and Claude's interfaces. Unlike OpenAI and Anthropic, we are profitable, turning 8-digit revenue with zero outside investment. We have complete ownership, without tens~hundreds of billions in expenses and debt. Excellence in software still has a place in the world, even if the VC darlings get most of the attention, because at the end of the day consumers and enterprises alike will pay for software that truly works well.
Destroying 450 out of 130,000, ie 0.3%, is not sufficient to resist the imposition of a surveillance state. Americans pretty clearly do not care for freedom as much as they yap about.
I don't think it's that simple... the vast majority of people simply don't know what having Flock means in the first place besides "less crime".
They don't understand how it could personally affect them and hence why they should care.
The "nothing to hide" crowd never thinks about data harvesting, leaks, hacks, malware, viruses, corrupted employees or other threat actors using the data maliciously.
Manipulating leaked/stolen data is also an extremely easy way to frame someone because the accuracy of the data is almost never questioned.
Fascinating, I didn't know one of our resident "IDEs are obsolete and I never use them" commenters was demonstrating the complete uselessness of their mindset in production! Usually the vibe coders are cagey and never share their amazing 10x applications. Now we see why.
> but there's room given weeks and enough tokens to get this into a usable state,
There really isn't. I've certainly been down this road trying to understand the hype. The more complex the application gets the more the models will buckle under not having a solid foundation to work from, applying hacky patch after hacky patch. Simple changes will take 30 minutes, break three other things because the tests they write are trash, and introduce new edge case bugs. We've been hearing about how software development is over with every model release for the past two years, with the biggest upswing being since last Nov, and we're still hearing "just a couple of more weeks". When do we face reality?
I understand your skepticism. I'm actually pushing for this project to go as far as it can so that we can have the "facing reality" discussion, and see whether it completely collapses under its own complexity or if something usable comes out the other end.
C doesn't bounds check arrays. A C compiler is perfectly capable of producing the same machine code as an assembler when given a loop that writes bytes to an array and then keeps writing beyond the space allocated for the array.
Missingno wasn't the result of an array overrun, it was due to data in a set of registers (which had temporarily been used to store a string) being arbitrarily reinterpreted as structured data governing which pokemon were allowed to be encountered. It more closely resembles a compiler miscompilation than a typical logic bug that you'd encounter in a C program. An idiomatic C implementation of Pokemon Red/Blue (ignoring hardware limitations, which is of course why it was written in assembly in the first place) would have used a static array to hold the per-area pokemon encounter table, and would have used a global variable to hold the index into this array representing the player's currently-loaded encounter zone; at no point would the static encounter array have been overwritten by a string temporary (which, in our C implementation, is just a function local variable on the stack), and at no point would the global location index be overwritten with garbage, because just like in the original game it only gets updated when we load a zone where wild pokemon can be encountered (which means that surfing on the side of Cinnabar Island would result in encounters drawing from whatever encounter zone we had most recently visited).
Rigorous specification doesn't even help, the rigority of a good spec requires too much context for LLMs to adhere to and they will flagrantly violate clear specifications once you have too much detail. The only thing that does work is having specification encoded as tests, because LLMs can fix compile errors in a loop and that deterministic guidance is what they need to keep them on track, but... writing tests is coding. Writing good tests still requires understanding the code and architecture in fine detail.
This is why you see all of these headlines about porting things that already have years of human work as deterministic guidelines and yet absolutely nothing worth using in production is being vibe coded from scratch. Don't let the hype/FOMO get to you, you are not alone, that is just what the people selling you the hype want you to believe.
For one, there are millions of people who use chatbots for DnD-like roleplaying game purposes. Is it being cruel to the chatbot if the chatbot is roleplaying as a goblin and you kill it? Claude is already useless for this purpose, of course, because it helpfully censors killing goblins already.
But the more important point, to me, is that this is a form of fraud. Anthropic are knowingly and deliberately pushing a narrative that their chatbot is conscious, something they clearly do not believe themselves, because if they did believe it themselves they would understand that what they are doing is slavery. In that context, this action is disgusting when seen for what it is: an attempt to intentionally deceive people into believing things about their product that are not true.
It's about as pointless as "old man yells at cloud" or swearing at and kicking your car that just broke down, but that's exactly why a ban of such behaviour is also completely pointless.
Be mindful of living in an echo chamber. HN is one. There is a startup/SV-oriented culture here, which selects for a specific niche of people that is not representative of the general population. Going by this forum, you'd also think Java and especially C# were dead languages by how many votes and comments their threads get. Yet in the real world, Windows dev environments dwarf Linux, and Java/C# are everywhere in enterprise.
reply