Hacker News Reader

> 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.

It's also no surprise that they are markedly worse than the already low status-quo. Just because it was bad before doesn't justify it getting worse.

> 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.

> LLM code is abysmal if you look at the details

This is, unfortunately, false.

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.

Yes, that's a good argument, thank you. You bring up a good point and I'll try to avoid making such claims in the future.

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.

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.

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. :)

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.

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.

Previous poster stated ai can't do hard problems.

Yet there's a typescript compiler vibe coded, 100% compliant.

>LLMs are not generating better compilers nor better kernels than what exists.

Not LLMs, but AI is inventing new hardware:

https://deepmind.google/blog/how-alphachip-transformed-compu...

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.

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.

There is no study showing a 10x productivity improvement. There are a few studies showing a productivity decrease.

There is one requirement which is more important than performance: Software should exist in reality, not in imagination.

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.

> 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.

Unless your frontend can be used instead of claude desktop you didn't built better claude desktop. You built something different.

I didn't said what you can't. I said you didn't.

It can be, and I personally use it with my Codex subscription as well. Model interchangeability in an interface is completely trivial.