Feel like this is the equivalent of a traffic engineer standing at the grand opening of the 5th lane for the highway saying there’s no reason for traffic to be slow anymore.
That is, there’s a misunderstanding of why software (traffic) was slow in the first place, and it has nothing to do with our ability to generate code (number of lanes), even if that code is “high quality”.
The HN crowd understands that, depending on bottleneck, adding a fifth network connection (lane) between 2 nodes may not necessary decrease the latency (travel time).
Sorry I can't resist the pedantry but a traffic engineer knows better than anyone that adding a 5th lane (often even a 4th) won't improve traffic except in fairly specific circumstances. :D
That cannot be an emperical statement. Traffic engineers have absolutely wrecked the american city, largely be ause they didnt know the impact of adding lanes.
It's not the only reason. I think that traffic engineers lack/lacked a feel, a certain gut understanding , an inability to feel through the skin. Just look around you. See and hear them at municipal meetings. They are unable to sensually experience the effects of their work, their praxis.
I've spoken with traffic engineers before, and the consensus I've gotten is that, excusing a few bad apples, much of the problems originate with popular or political interference.
I'm really bothered by the mindset of the people against this. People act like induced demand is evil.
In reality, if more people were able to go wherever they wanted to go, that's actually a good thing regardless of if the existing people didn't get to go somewhere faster.
This isn't categorically true either, the real world is delightfully complicated, far more so than you imagine. The way cars interact within a road, as they enter an exit the road, or how they choose their route can all create conditions where adding a lane only makes traffic worse and can reduce both speed and volume during peak traffic hours.
Locally. Under many circumstances. But always? That's not a universal law, as it's a part of a larger system that may perform more poorly if this leg provides more traffic.
you dont mesaure the quality of a plane by how much it weighs. but yea i think everything is rot to the core. app to os if just wackness that nobody cared about.
It's all about the test suite. The test suite becomes an executable specification, and the better the spec, the better the results you can get from AI.
The very first thing many people did with AI is start calling the automated tests it writes good enough to capture the desired behavior. Writing tests isn't a whole lot of fun for most, so now the thing that it is supposed to help ensure we're not evolving our software into piles of trash is, in fact, one of the most neglected parts of vibed out codebases.
> Only the small and unimpressive programs can be checked exhaustively.
Even if you assume that statement is true, there are techniques other than exhaustive checking/model checking. Proof assistants/theorem provers/etc. like Rocq/Isabelle/Lean are quite capable of formally verifying programs without needing to exhaustively explore the search space.
I'd question the accuracy of that statement in general as well; model checkers like CBMC/TLA+ are handy for proving properties about interesting systems. The latter, for example, sees use for verifying concurrent/distributed systems, which I think can be reasonably described as more than "small and unimpressive"
Not true at all! Most of the HTTP APIs, and a good chunk of the webapps, that I've worked on can be defined as a combination of an API spec that carves out valid and invalid behaviors, and a set of behavioral tests for the workflows that the client users care about. Working from a codebase which is generated from a spec document (e.g. OpenAPI or gRPC) and use of tools like https://pkg.go.dev/net/http/httptest and https://bun.com/docs/test/dom makes this a pretty achievable goal in practice.
It's part of it but you need good systems thinking in order to write good tests. The kind of thinking which requires years of software engineering experience to acquire.
Also the architecture really matters now because a poor architecture will lead to more weird edge cases and require more exotic tests to plug all the holes.
No it really is about the test suite, and provably so. As another poster pointed out, speed is a superoptimization problem and the test suite provides the constraints. If the constraints are appropriately set, even a naive genetic algorithm will eventually improve the outcome over time, provided suitable mixing of the proposal scheme. LLMs provide measurably better proposals than naive approaches, so the entire chain is sound. The issue really is an inability to set appropriate constraints on what the user is looking for, and poor quantification of the multiple objectives one should try to balance in practice. What's great is that's a human problem. Diverting that to the models is obviously a disaster.
I agree that there has been a glut of subpar developers for years, and that has lowered the bar significantly. This is mostly because core values shifted. So let's keep our eyes on what really matters rather than acting elitist.
Regarding speed - now it takes much less learning to use a fast web framework(like Meteor), this means web based software will be more performant.
Regarding security - i wonder: can we develop a framework that is responsible to 100% of the security, with zero responsibility for security on the app developer?
I cannot imagine how nitpicky people are. AI went from 'good autocomplete' to 'I just tell it to do an entire thing and it does it and it works the first try'.
Maybe pick languages that are more boring. That's what works for me. It worked for hiring crappy outsourced programmers and it works for AI. It seems to do well with PHP - no long running processes / side effects. it works great with golang, simple language spec, and a very common style of writing.1
I feel like I’m reading a post from 2025 instead of one written three minutes ago.
People get entrenched in closedminded thinking. My guess is that this has been your canned spasm for the past year. Repeating these things won’t make them true or protect your job.
You protect your job by learning how to use new tools as the technology advances.
This sort of lazy thinking isn’t acceptable anymore. Whether this is a reflexive Luddite response or a reflection of your work ethic, neither is a good look.
So long as the way to improve software is "just stack another VM on it", software will continue to get slower.
Cutting edge development practice in 2025 was using a big JavaScript framework (not quite VMs, but they inherently strain the environments they run in).
That code is run by the JavaScript interpreter VM, which is running in the browser (another VM), which was (in whole or part) written in a managed language (another VM).
That program runs on top of the OS (another VM), which runs on another VM (the default hypervisor for Windows 10/11, or the desktop environment for Linux/macOS).
Each VM lets you have an entirely new managed programming environment- you have a new program that lets you write software even quicker than before- but that comes at the expense of memory usage and (most importantly) latency. Which is why it takes modern systems a few seconds to figure out you pressed a button in your React application that's running in an isolated browser instance consuming 1GB of RAM, where systems in the 90s were instant by comparison even though they had a fraction of the processing power.
It's conceivable that in 10-20 years, LLMs could be used as VMs in and of themselves, which will still likely be using 2020s development languages. So your software is going to require at least 128GB of RAM to compile, use another 32GB to run, and it'll take twice as long to respond to clicking a button.
you are probably right as far as desktop stuff is concerned.
But there were some sea changes from time to time.
When the iphone came out, phones became very responsive to fingers. hate the control apple gave to customers, but their guidance made apps respond in milliseconds. Before that phones were clumsy. Wasn't a desktop, but was different.
Will we have voice/chat interfaces that will be bloated... but responsive like a conversation?
I agree, but it won’t be because we can’t do it. It will be easier than ever to achieve, but of course money for the tokens to do it will go toward some other aspect of the business. That the products get worse seems to be the rule.
For the same reasons, too. Software is buggy and slow because you impact the bottom line when you make it better. Same thing with LLMs and token expenses.
People these days are saying “don’t look at the code”.
People are shipping all sorts of weird architectures, non-performance code, etc.
I wish that the ram scarcity would drive more performant software however I just think that the way people are shipping software currently will not lead to this
> A stochastic search process with an executable optimization objective over space of programs S can only maintain or improve the objective
This is superoptimization. We've known this since the 80s (Massalin, STOKE is more recent: https://github.com/StanfordPL/stoke) The only novelty is that the proposer is now way better with LMs.
Further, there's a large number of reasons for software written by agents to be slow:
- LMs still don't do data or hardware-oriented design well out of the box, and therefore if you're engaging in any sort of serious novel work, beyond porting an extremely well-understood program with extremely well-understood workloads, you're going to be spending hours tracking down bad allocation decisions (c.f. why TigerBeetle doesn't use agents), which are often the root of evil (before you'd reach for anything further)
- The knobs you'd need to get serious performance are nearly unreachable in languages which LMs are good at (even Rust requires a discipline that the default language doesn't enforce). When you drop into the lower realms, you're trading consumption context for access to these levers. The levers are also "soft": you find yourself writing a bunch of skills, and tools to try and enforce the discipline.
The reality is to get performant code (quickly) out of an agent, you need to know how to write performant code (and you need to know how to surface the information that you'd use to create a verifier for such a thing to the agent), which 99% of developers do not know in 2026.
Sure, agents can teach you how to do this -- but it's one of these things where iykyk.
Experience: I've poured 10s of billions of tokens into Zig with the best agents and I have the time and space to try these things.
If you want to start learning the discipline, I'd recommend matklad's + TigerBeetle blog -- as well as hardware-oriented design.
> - The knobs you'd need to get serious performance are nearly unreachable in languages which LMs are good at (even Rust requires a discipline that the default language doesn't enforce). When you drop into the lower realms, you're trading consumption context for access to these levers. The levers are also "soft": you find yourself writing a bunch of skills, and tools to try and enforce the discipline.
Hasn’t been my experience at all. The latest LLMs can knock out assembly optimized subroutines and benchmark 100 different variations faster than I ever could dream of.
That's fair for a well-scoped subroutine: what I meant is that if you ask an agent to write a compiler and let it rip for a few days, you are going to be spending a few more days correcting the default behaviors in the distribution, which often do not tend towards hardware-oriented design.
To correct those behaviors, you're going to write tools and skills, and that's going to help, but it is still clear that you are fighting the distribution (today).
Ironically a perfect thing to iterate on with your favorite coding agent. "make this page look better, present me 2 versions, I'll pick my favorite, and we'll iterate until I say stop"
Counterpoint - I like Dan's site. I think it fits his vibe and priorities, and I don't find it unreadable. I can always pick my browser width and font size with a couple keyboard touches, and I never have to fight his idea of how I should want to read it.
I don’t know why you got downvoted but you have a point. It looks as if OP doesn’t write for readership and his posts contents have similar characteristics of reckless abandon for conventional norms for a tech post. Too many cross references and link-backs to his own other articles that makes it really hard to follow the main thread of the essay.
The downvotes may be related to community enforcing what's in the HN guidelines:
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
His site has always looked like this, i'm sure of it. This is what sites look like if you just write them as text. Not everybody knows how to use sql or css or java or whatever thing it is that lets you pick the font.
I'm almost certain he used to have a reasonably styled website. I just tried to look it up but it looks like he's excluded the website from WayBackMachine.
> Not everybody knows how to use sql or css or java or whatever thing it is that lets you pick the font.
lol at the idea that Dan Luu can't add css to his website by copypasting some links into his html. He could make the site readable in about 3 mins and never have to worry about it again.
BTW this is just the first such library I found. There are lots of 'em, and all very well documented, requiring less knowledge to use than what it takes to publish a blog... which he's mastered.
One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it.
Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick.
If your software has the affordance of a waiting dialogue or loading wheel for many of its UI controls, you are building with this default blocked assumption. Even if you are building something web based, ask yourself if that's actually necessary for your software or if you could build it differently to avoid constant UI blocking.
AI SDLCs simply compress the same incentives that were always there: you could invest in optimizing your architecture and improving your UX, neither of which make for big bullet points that close sales, or you could invest in new features that do.
The investment that was previously measured in months of developer time may now be measured in token spend across days, but the underlying dynamics shaping where it’s directed haven’t changed.
Because it's not built with client side optimization in mind any more. It's built with circular investment in mind.
Big tech funds startups (through obfuscated legal and financial means) and that funding goes straight back into big tech cloud hosting and SaaS services.
The private equity and venture capitalist playbook has always been enshittification: you either take an existing high quality product or innovate one subsidized with investment capital, then once it’s time to flip the business you 10x the price and cut costs (which usually cuts quality).
AI is the perfect tool for enshittification, because it can get you 80% of a finished product with a fraction of the costs it used to take, but the last 20% takes 2-5x times longer. So you just ignore the last 20%, make it up in volume by producing 100 mediocre products instead of 1 great one.
And that’s basically the state of the tech industry right now. I don’t think it’ll be like this forever, I think there will be better ways to collaborate with AI rather than wholesale delegation and prompting. But for now we’re stuck with mass enshittifation. People who have no sense of quality, taste, or craftsmanship don’t even understand, they skim over some generic blog post from Claude that takes five paragraphs to say one thing or watch the Coca Cola AI ad and don’t event notice it’s a different train in every shot and they think it’s so amazing. I hope this isn’t just the way things are now.
Giving an LLM a program that does a well defined thing correctly and asking it to make a faster version and a crapload of tests to show that it performs exactly the same task is a great way to burn through a bunch of tokens and getting a faster program in return.
I currently have one running working on a multi path problem trying to make an A* heuristic that produces the same or better score for search time, paths crossed, corners taken (plus a few other metrics, like proximity of opposite direction corners of unconnected paths.)
I have another where I'm testing how well it can iteratively rewrite the same program without regressions and successively stricter resource conditions. Instead of progressively adding lines of code to make an over engineered behemoth, starting over with the previous version as a template of functionality lets it consider the problem increasingly holistically
I would be genuinely interested to see how it evolves the same program over a large number of generations. Given a whole lot of software is more a collection of programs rather than a singular "program", I have to imagine that the outcomes would be vastly different in shape when dealing with smaller targeted, articulable-in-a-few-paragraphs programs vs many-years-of-business-domain layered programs.
This was for https://non.io, which is something I had purposefully written to be as fast as possible (hand wrote all the comopnents, didnt even use react).
I've been considering creating a skill / utility to do this based on learnings from the speedups - would others find this kind of thing useful?
Much like security, optimization is now a function of token spend—which in some ways means it's a function of care. The reason why software may continue to be slower or less secure than it could be is simply that no one cares enough to invest the time and money in improving it.
Off-topic, but Dan, in the name of all that is holy, throw a `max-width: 40em;` on your blog!
I regularly support Windows users and when I do, I cringe at just how awful the experience is! (My daily driver for the last decade have been various flavours of linux)
High end Windows 10/11 machines (like my Alienware I9 w/ 64GB mem + RTX4090) seem a bit sluggish. Low end machines with Windows are absolutely painful to use!
I've install debian onto my fairly ancient Lenovo X201 Tablet and it is exceptionally snappy.
I've been using computers for 4 decades. They have gotten no faster. The nuclear plant computer system we built in 1989 had to present selected screens in 1 second. I don't think any apps I use today can do that.
Incentive has shifted. It’s now more important to worry about “developer productivity” and churning out as much code as quickly as possible than it is to spend time optimizing that code.
I recently built a piece of code which downloads a bulk set of data, indexes it for search, and then serves a pretty web UI on top of this with the help of some AIs. Normally I would have reached for sstables, sqlite, etc. This time, because the lookup patterns actually would not have been too efficient on sstables and SQLite would have been overkill, I had an agent take the data structures, pack the text effectively, and build a prefix tree for fast auto completion from the search bar. It was great. I could have done this all before but I wouldn't have. I would have felt sqlite was fast enough. The resulting web server is significantly faster feeling (because the optimized lookup speeds) than an sqlite implementation would feel like.
I think engineers building very complex systems now have a lot of performance knobs to twiddle that would have just been too costly for human effort. Since we constrain the responsibilities of the agent slop is less of a problem. We relegate it to defined tasks with clear API boundaries and test harnesses.
Jevon's paradox implies we're getting more fast software, and more slow software. Sturgeon’s law implies the ratio will remain the same. 90% of what ships will be slow, buggy, slop. Just as it was before LLMs.
This makes sense for a verifiable task like a regex engine - but those are clearly defined and I doubt an LLM will have a meaningful speed increase over current human regex engines.
Anything else kind of just feels like "make GTA 6, make no mistakes". The ability for you to write fast and correct software is really going to depend on well you can specify your problem, and having the ability to specify correct programs in such detail an LLM can reasonably performance tune it is a big enough reason for me to believe there will still be slow software
Yeah.... maybe. I think AI is still too prone to go down rabbit holes and not understand the whole picture well enough to come up with good optimisations. It's probably good at micro-optimisation, e.g. pre-allocating arrays. But is it going to realise that you don't need that array in the first place? I dunno.
On the other hand it does mean there's no excuse for writing your program using Python or Electron or whatever, which will have a big effect on performance.
>LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly
LLMs have caused such an increase in ram prices that pine64 is no longer making linux machines. When you can't afford RAM, as a direct result of LLMs, it's going to make your assembly app slower too. Sorry, this is the future you chose.
Well, at least with the RAM crunch that the AI boom has caused, I hope there will be some sort of pressure to write efficient software, otherwise device manufacturers are quite fucked.
Yeah, I've been thinking this as well. I have some optimism, but not with high confidence. The exponentially increasing power of computing hardware up until this point is often cited as the reason performance optimization has been sidelined in the software industry. Now that there's a definite hiccup in that trend, I'm hoping programmers will remember that software actually can be fast and memory-efficient, and that poor design choices that lead to bad performance are exactly that, a choice.
The author of the article definitely seems to think LLMs are what enables this to happen, but I personally am much more skeptical of that. I think what it really needs is bringing engineering back into software, not just throwing LLMs at it and calling it a day.
I've been hoping for this for my entire software engineering career but it never came.
It's messed up. Sometimes it feels like everything in the universe is aligned to ensure that skilled software engineers lead horrible lives full of anguish, frustration and powerlessness.
It feels like the economic system creates incentives which go against efficiency. So then it makes sense that software engineers would be most impacted.
There's a weird duality to our job; it's supposed to be about automation and efficiency but in reality, engineers who make the most money are those who create unnecessary complexity because it creates better lock-in and thus gives them more leverage in negotiations. And the tech monopolies they work for never seem to run out of money no matter how much enshittification occurs as a result.
Same perverse incentive for open source projects; engineers who lead projects that are full of bugs can charge more consulting fees and sell more enterprise licenses to work around the issues.
And engineers are often forced to use shitty tools by their employers so we're always stuck between a rock and a hard place with limited control over our output... Which we are blamed for when things go wrong but never given credit for when we pull heroic feats because those achievements are often overshadowed by missed deadlines resulting from being forced to use shitty software.
Adoption and quality are orthogonal, unfortunately.
Worst part is that nobody listens to us. Business people with money only listen to engineers who have money; who are mostly merchants of complexity. Engineers who care about efficiency have no voice in this market.
Its more about discipline because you now have so much more option for that power, not just optimization. The engineer or the manager can choose more tech debt, then LLM's power is neutered because the complexity to optimize has increased by that much, and somehow evens out, and you are back to square one.
There is no reason for it to be non-extensible either and depending on the use cases people might want to trade speed/optimization for more runtime customizations which will inherently be slower than pre-baked SIMD regex and whatnot.
> performance work that used to require a person or team that had a rare set of skills can be done by anyone who can type a few sentences
This idea is the reason why software will keep getting slower and less reliable. Because it's wrong and yet people believe it.
Not only do people believe this, even if they didn't, they would still have the problem that most people (including many engineers) are bad at telling who is a good software engineer.
So this means that code will get worse and worse; less performant, less reliable, less secure.
It will be impossible to fix because nobody would know what the problems are let alone identify who is able to solve those problems.
I don't know how bad it has to get before people understand we have to rebuild everything from scratch on much more rigid guardrails.
The essence of the problem is that the LLM does exactly what you tell it. In the hands of a skilled engineer who understands the project, this is a superpower. In the hands of a junior, this is dangerous... Because it will do things that are insecure; it doesn't push back on a user request; it just goes ahead and tries to make it work, even if it's a bad idea and the problem is best solved in a different way.
"There's no reason" being very different than "we can now do the thing easier". There are still tons of reasons for software to be slow, the biggest of which is priorities.
If you want your software to be fast, stop writing it in Python and TypeScript and instead write it in Go, Rust, C++ or C. But nobody's going to do that, because humans are emotional creatures who get attached to things (like programming languages). Or if you want your software to be fast, stop spending your time and money (tokens) on features, and start spending it on profiling log replays to find a bottleneck causing a 50ms delay for the 95th percentile. But nobody's going to do that either, because how slow is too slow? Answer: when it's slow enough to scare the shareholders or annoy the developer on their high-powered laptop.
If you want faster/more efficient software, force it to run on a 100MHz CPU with 512KB RAM and a 56k modem. You'll definitely prioritize speed then.
Eh, not sure. Very few humans do software optimization productively, so I'm not optimistic about machines built by humans, either. Every encounter I've had with agentic optimization involved trying to apply a bunch of myths to an existing code base, in a way that seemed cool (unrolling loops, eliminating apparent branches, SIMD) but which was all pointless because the only credible optimizations were going to come from doing fewer loads and taking up fewer itlb slots and stuff like that.
Data point of one, but after a few months of uselessness, I have managed to get some pretty serious, measurable performance improvements with AI optimizations -- order-of-magnitude speedups of business critical processes which took days as well as significant latency reductions.
But you need a really solid workflow, solid benchmarks which run quickly, and a lot of tokens -- plus a rigorous profiling workflow.
Feel like this is the equivalent of a traffic engineer standing at the grand opening of the 5th lane for the highway saying there’s no reason for traffic to be slow anymore.
That is, there’s a misunderstanding of why software (traffic) was slow in the first place, and it has nothing to do with our ability to generate code (number of lanes), even if that code is “high quality”.
The HN crowd understands that, depending on bottleneck, adding a fifth network connection (lane) between 2 nodes may not necessary decrease the latency (travel time).
Sorry I can't resist the pedantry but a traffic engineer knows better than anyone that adding a 5th lane (often even a 4th) won't improve traffic except in fairly specific circumstances. :D
That cannot be an emperical statement. Traffic engineers have absolutely wrecked the american city, largely be ause they didnt know the impact of adding lanes.
It's not the only reason. I think that traffic engineers lack/lacked a feel, a certain gut understanding , an inability to feel through the skin. Just look around you. See and hear them at municipal meetings. They are unable to sensually experience the effects of their work, their praxis.
I've spoken with traffic engineers before, and the consensus I've gotten is that, excusing a few bad apples, much of the problems originate with popular or political interference.
But it will definitely improve, either speed or volume.
I'm really bothered by the mindset of the people against this. People act like induced demand is evil.
In reality, if more people were able to go wherever they wanted to go, that's actually a good thing regardless of if the existing people didn't get to go somewhere faster.
This isn't categorically true either, the real world is delightfully complicated, far more so than you imagine. The way cars interact within a road, as they enter an exit the road, or how they choose their route can all create conditions where adding a lane only makes traffic worse and can reduce both speed and volume during peak traffic hours.
Check out the Downs-Thomson paradox.
Locally. Under many circumstances. But always? That's not a universal law, as it's a part of a larger system that may perform more poorly if this leg provides more traffic.
The author clearly understood this part of the topic and agrees. There are multiple reasons that software is slow.
As you imply, some of them are not because spending time on optimization seems relatively expensive compared to value. But some of them are.
you dont mesaure the quality of a plane by how much it weighs. but yea i think everything is rot to the core. app to os if just wackness that nobody cared about.
What's the public transport of software development? Where can I get good train service here?
> What's the public transport of software development?
Understanding.
Still a struggle to get coworkers to write docs or tests despite it being effortless.
At the end of the day its a mindset.
just¹ prompt like the lotus philosophy:
Simplify, then add lightness.
[1] hn favorite word
One article said secure software was here because of AI, this one says it can now be performant.
Yet when I ask for code it writes, by default, both slow and insecure code that mostly works. Kinda.
As I try to get AI to rewrite it into more secure, less bloated and optimized code is when it starts to randomly crash.
Then I read articles about how AI is "moving too fast" and cry.
It's all about the test suite. The test suite becomes an executable specification, and the better the spec, the better the results you can get from AI.
The very first thing many people did with AI is start calling the automated tests it writes good enough to capture the desired behavior. Writing tests isn't a whole lot of fun for most, so now the thing that it is supposed to help ensure we're not evolving our software into piles of trash is, in fact, one of the most neglected parts of vibed out codebases.
How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.
> Only the small and unimpressive programs can be checked exhaustively.
Even if you assume that statement is true, there are techniques other than exhaustive checking/model checking. Proof assistants/theorem provers/etc. like Rocq/Isabelle/Lean are quite capable of formally verifying programs without needing to exhaustively explore the search space.
I'd question the accuracy of that statement in general as well; model checkers like CBMC/TLA+ are handy for proving properties about interesting systems. The latter, for example, sees use for verifying concurrent/distributed systems, which I think can be reasonably described as more than "small and unimpressive"
Not true at all! Most of the HTTP APIs, and a good chunk of the webapps, that I've worked on can be defined as a combination of an API spec that carves out valid and invalid behaviors, and a set of behavioral tests for the workflows that the client users care about. Working from a codebase which is generated from a spec document (e.g. OpenAPI or gRPC) and use of tools like https://pkg.go.dev/net/http/httptest and https://bun.com/docs/test/dom makes this a pretty achievable goal in practice.
It's part of it but you need good systems thinking in order to write good tests. The kind of thinking which requires years of software engineering experience to acquire.
Also the architecture really matters now because a poor architecture will lead to more weird edge cases and require more exotic tests to plug all the holes.
It really isn't.
It's s about subpar models trained on subpar data doing subpar work.
The only reason why anyone takes it seriously is that we've had a glut of subpar developers for 30 years so it all balances out in the end.
No it really is about the test suite, and provably so. As another poster pointed out, speed is a superoptimization problem and the test suite provides the constraints. If the constraints are appropriately set, even a naive genetic algorithm will eventually improve the outcome over time, provided suitable mixing of the proposal scheme. LLMs provide measurably better proposals than naive approaches, so the entire chain is sound. The issue really is an inability to set appropriate constraints on what the user is looking for, and poor quantification of the multiple objectives one should try to balance in practice. What's great is that's a human problem. Diverting that to the models is obviously a disaster.
I agree that there has been a glut of subpar developers for years, and that has lowered the bar significantly. This is mostly because core values shifted. So let's keep our eyes on what really matters rather than acting elitist.
It's all now about money extraction from the areas dependant on software, not the sofrware itself.
If you have such a test suite then you really don't need AI to write the code for you.
Writing a benchmark test is about 100x to 1000x easier than writing optimizations. A benchmark test can be as simple as:
Actually optimizing the runCodeUnderBenchmark() function is far more difficult.Regarding speed - now it takes much less learning to use a fast web framework(like Meteor), this means web based software will be more performant.
Regarding security - i wonder: can we develop a framework that is responsible to 100% of the security, with zero responsibility for security on the app developer?
Skill issue.
The fact is that with the right spec, agentic guardrails, and evals, frontier models can now one-shot secure, performant code.
This is the job of software engineering now. Learn to properly use the tools for the job.
Aha, the problem is you're asking for code that works.
I cannot imagine how nitpicky people are. AI went from 'good autocomplete' to 'I just tell it to do an entire thing and it does it and it works the first try'.
Maybe pick languages that are more boring. That's what works for me. It worked for hiring crappy outsourced programmers and it works for AI. It seems to do well with PHP - no long running processes / side effects. it works great with golang, simple language spec, and a very common style of writing.1
The goal posts always move
I feel like I’m reading a post from 2025 instead of one written three minutes ago.
People get entrenched in closedminded thinking. My guess is that this has been your canned spasm for the past year. Repeating these things won’t make them true or protect your job.
You protect your job by learning how to use new tools as the technology advances.
This sort of lazy thinking isn’t acceptable anymore. Whether this is a reflexive Luddite response or a reflection of your work ethic, neither is a good look.
> Yet when I ask for code
Engineers don't ask a tool to write code.
100% sure software in the coming years will just feel slower and slower.
So long as the way to improve software is "just stack another VM on it", software will continue to get slower.
Cutting edge development practice in 2025 was using a big JavaScript framework (not quite VMs, but they inherently strain the environments they run in).
That code is run by the JavaScript interpreter VM, which is running in the browser (another VM), which was (in whole or part) written in a managed language (another VM).
That program runs on top of the OS (another VM), which runs on another VM (the default hypervisor for Windows 10/11, or the desktop environment for Linux/macOS).
Each VM lets you have an entirely new managed programming environment- you have a new program that lets you write software even quicker than before- but that comes at the expense of memory usage and (most importantly) latency. Which is why it takes modern systems a few seconds to figure out you pressed a button in your React application that's running in an isolated browser instance consuming 1GB of RAM, where systems in the 90s were instant by comparison even though they had a fraction of the processing power.
It's conceivable that in 10-20 years, LLMs could be used as VMs in and of themselves, which will still likely be using 2020s development languages. So your software is going to require at least 128GB of RAM to compile, use another 32GB to run, and it'll take twice as long to respond to clicking a button.
you are probably right as far as desktop stuff is concerned.
But there were some sea changes from time to time.
When the iphone came out, phones became very responsive to fingers. hate the control apple gave to customers, but their guidance made apps respond in milliseconds. Before that phones were clumsy. Wasn't a desktop, but was different.
Will we have voice/chat interfaces that will be bloated... but responsive like a conversation?
I agree, but it won’t be because we can’t do it. It will be easier than ever to achieve, but of course money for the tokens to do it will go toward some other aspect of the business. That the products get worse seems to be the rule.
It will be the equivalent of that Excel =COPILOT(“sum the numbers above”) meme.
For the same reasons, too. Software is buggy and slow because you impact the bottom line when you make it better. Same thing with LLMs and token expenses.
I’m a lot more optimistic now that RAM is scarce. A lot of focus will be on maximizing software performance.
See: iOS 27. It’s faster than the previous version, even on very old phones.
I also think AI will contribute to removing a lot of the tedium surrounding optimization.
People these days are saying “don’t look at the code”.
People are shipping all sorts of weird architectures, non-performance code, etc.
I wish that the ram scarcity would drive more performant software however I just think that the way people are shipping software currently will not lead to this
> People are shipping all sorts of weird architectures, non-performance code, etc.
And they weren’t before AI?
Is iOS 27 particularly impressive, or was iOS 26 a shitheap? Maybe a bit of both.
It fucking better be faster, iOS 26 basically bricked my iPhone SE, which had never been the slightest bit laggy or glitchy before that cursed update.
Here's this boiled down:
> A stochastic search process with an executable optimization objective over space of programs S can only maintain or improve the objective
This is superoptimization. We've known this since the 80s (Massalin, STOKE is more recent: https://github.com/StanfordPL/stoke) The only novelty is that the proposer is now way better with LMs.
Further, there's a large number of reasons for software written by agents to be slow:
- LMs still don't do data or hardware-oriented design well out of the box, and therefore if you're engaging in any sort of serious novel work, beyond porting an extremely well-understood program with extremely well-understood workloads, you're going to be spending hours tracking down bad allocation decisions (c.f. why TigerBeetle doesn't use agents), which are often the root of evil (before you'd reach for anything further)
- The knobs you'd need to get serious performance are nearly unreachable in languages which LMs are good at (even Rust requires a discipline that the default language doesn't enforce). When you drop into the lower realms, you're trading consumption context for access to these levers. The levers are also "soft": you find yourself writing a bunch of skills, and tools to try and enforce the discipline.
The reality is to get performant code (quickly) out of an agent, you need to know how to write performant code (and you need to know how to surface the information that you'd use to create a verifier for such a thing to the agent), which 99% of developers do not know in 2026.
Sure, agents can teach you how to do this -- but it's one of these things where iykyk.
Experience: I've poured 10s of billions of tokens into Zig with the best agents and I have the time and space to try these things.
If you want to start learning the discipline, I'd recommend matklad's + TigerBeetle blog -- as well as hardware-oriented design.
> - The knobs you'd need to get serious performance are nearly unreachable in languages which LMs are good at (even Rust requires a discipline that the default language doesn't enforce). When you drop into the lower realms, you're trading consumption context for access to these levers. The levers are also "soft": you find yourself writing a bunch of skills, and tools to try and enforce the discipline.
Hasn’t been my experience at all. The latest LLMs can knock out assembly optimized subroutines and benchmark 100 different variations faster than I ever could dream of.
That's fair for a well-scoped subroutine: what I meant is that if you ask an agent to write a compiler and let it rip for a few days, you are going to be spending a few more days correcting the default behaviors in the distribution, which often do not tend towards hardware-oriented design.
To correct those behaviors, you're going to write tools and skills, and that's going to help, but it is still clear that you are fighting the distribution (today).
Wow, my browser's Reader Mode saved my bacon on this one.
Otherwise, I would have left immediately.
I'm all for speedy, simple, plaintext websites, but it is a negligible amount of work in 2026 to throw some barebones CSS in and make it approachable.
Ironically a perfect thing to iterate on with your favorite coding agent. "make this page look better, present me 2 versions, I'll pick my favorite, and we'll iterate until I say stop"
Counterpoint - I like Dan's site. I think it fits his vibe and priorities, and I don't find it unreadable. I can always pick my browser width and font size with a couple keyboard touches, and I never have to fight his idea of how I should want to read it.
You must not look at many academic websites.
I don’t know why you got downvoted but you have a point. It looks as if OP doesn’t write for readership and his posts contents have similar characteristics of reckless abandon for conventional norms for a tech post. Too many cross references and link-backs to his own other articles that makes it really hard to follow the main thread of the essay.
The downvotes may be related to community enforcing what's in the HN guidelines:
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
Dan Luu is a bit famous around HN.
I think he might subscribe to the philosophy of everyone should style websites however they like and not be prescribed by the author.
Nah, he's just trying to be different. It's vanity.
He's had a usable website in the past. This one is explicitly made to be shitty. "Look at me, I'm such a geek" energy.
His site has always looked like this, i'm sure of it. This is what sites look like if you just write them as text. Not everybody knows how to use sql or css or java or whatever thing it is that lets you pick the font.
I'm almost certain he used to have a reasonably styled website. I just tried to look it up but it looks like he's excluded the website from WayBackMachine.
> Not everybody knows how to use sql or css or java or whatever thing it is that lets you pick the font.
lol at the idea that Dan Luu can't add css to his website by copypasting some links into his html. He could make the site readable in about 3 mins and never have to worry about it again.
BTW this is just the first such library I found. There are lots of 'em, and all very well documented, requiring less knowledge to use than what it takes to publish a blog... which he's mastered.One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it.
Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick.
If your software has the affordance of a waiting dialogue or loading wheel for many of its UI controls, you are building with this default blocked assumption. Even if you are building something web based, ask yourself if that's actually necessary for your software or if you could build it differently to avoid constant UI blocking.
It's not very hard to engineer software with these two constraints at the same time:
* Must feel very responsive * Network requests can take up to 500ms end to end
But software seems to be getting slower and less user friendly by the hour.
Both can be true.
AI SDLCs simply compress the same incentives that were always there: you could invest in optimizing your architecture and improving your UX, neither of which make for big bullet points that close sales, or you could invest in new features that do.
The investment that was previously measured in months of developer time may now be measured in token spend across days, but the underlying dynamics shaping where it’s directed haven’t changed.
Because it's not built with client side optimization in mind any more. It's built with circular investment in mind.
Big tech funds startups (through obfuscated legal and financial means) and that funding goes straight back into big tech cloud hosting and SaaS services.
Isn't this just enshittification? Where money is the driver, enshittification is just bound to happen.
If that euphemism makes sense of it for you, sure.
The private equity and venture capitalist playbook has always been enshittification: you either take an existing high quality product or innovate one subsidized with investment capital, then once it’s time to flip the business you 10x the price and cut costs (which usually cuts quality).
AI is the perfect tool for enshittification, because it can get you 80% of a finished product with a fraction of the costs it used to take, but the last 20% takes 2-5x times longer. So you just ignore the last 20%, make it up in volume by producing 100 mediocre products instead of 1 great one.
And that’s basically the state of the tech industry right now. I don’t think it’ll be like this forever, I think there will be better ways to collaborate with AI rather than wholesale delegation and prompting. But for now we’re stuck with mass enshittifation. People who have no sense of quality, taste, or craftsmanship don’t even understand, they skim over some generic blog post from Claude that takes five paragraphs to say one thing or watch the Coca Cola AI ad and don’t event notice it’s a different train in every shot and they think it’s so amazing. I hope this isn’t just the way things are now.
Giving an LLM a program that does a well defined thing correctly and asking it to make a faster version and a crapload of tests to show that it performs exactly the same task is a great way to burn through a bunch of tokens and getting a faster program in return.
I currently have one running working on a multi path problem trying to make an A* heuristic that produces the same or better score for search time, paths crossed, corners taken (plus a few other metrics, like proximity of opposite direction corners of unconnected paths.)
I have another where I'm testing how well it can iteratively rewrite the same program without regressions and successively stricter resource conditions. Instead of progressively adding lines of code to make an over engineered behemoth, starting over with the previous version as a template of functionality lets it consider the problem increasingly holistically
I would be genuinely interested to see how it evolves the same program over a large number of generations. Given a whole lot of software is more a collection of programs rather than a singular "program", I have to imagine that the outcomes would be vastly different in shape when dealing with smaller targeted, articulable-in-a-few-paragraphs programs vs many-years-of-business-domain layered programs.
This speaks to me. I've been running an autoresearch loop the past couple of days to improve the load time of my various projects' frontends.
I've been really, really impressed with how effective this is. I went from a 4s load on simulated slow 4g to ~750ms: https://image.non.io/speedup-graphs.webp
Side by side vid of the results: https://video.non.io/speedups.mp4
This was for https://non.io, which is something I had purposefully written to be as fast as possible (hand wrote all the comopnents, didnt even use react).
I've been considering creating a skill / utility to do this based on learnings from the speedups - would others find this kind of thing useful?
> This was for https://non.io
Maybe hugged but feels really sluggish to me for it is.
What if we need pretty, rounded, softly opaque corners on all our transparent windows hovering above a gently shadowed background?
apple might sue you for infringing on their primary money maker
Much like security, optimization is now a function of token spend—which in some ways means it's a function of care. The reason why software may continue to be slower or less secure than it could be is simply that no one cares enough to invest the time and money in improving it.
Off-topic, but Dan, in the name of all that is holy, throw a `max-width: 40em;` on your blog!
I regularly support Windows users and when I do, I cringe at just how awful the experience is! (My daily driver for the last decade have been various flavours of linux)
High end Windows 10/11 machines (like my Alienware I9 w/ 64GB mem + RTX4090) seem a bit sluggish. Low end machines with Windows are absolutely painful to use!
I've install debian onto my fairly ancient Lenovo X201 Tablet and it is exceptionally snappy.
How will the user know the computer worked 'HARD', if it is not slow?
Do you not add sleep to your programs?
I've been using computers for 4 decades. They have gotten no faster. The nuclear plant computer system we built in 1989 had to present selected screens in 1 second. I don't think any apps I use today can do that.
As long as there’s a trade off between experimentation and performance, software will always be slightly too slow.
Incentive has shifted. It’s now more important to worry about “developer productivity” and churning out as much code as quickly as possible than it is to spend time optimizing that code.
i can pore all my time, agents running profiling, workloads and so but no one gives a damn. tried the whole year, still do for my personal projects
In my experience AI coding is often about making lots of additive changes without a lot of (or any) thinking in advance.
Not sure how either of those things are conducive to performance
I recently built a piece of code which downloads a bulk set of data, indexes it for search, and then serves a pretty web UI on top of this with the help of some AIs. Normally I would have reached for sstables, sqlite, etc. This time, because the lookup patterns actually would not have been too efficient on sstables and SQLite would have been overkill, I had an agent take the data structures, pack the text effectively, and build a prefix tree for fast auto completion from the search bar. It was great. I could have done this all before but I wouldn't have. I would have felt sqlite was fast enough. The resulting web server is significantly faster feeling (because the optimized lookup speeds) than an sqlite implementation would feel like.
I think engineers building very complex systems now have a lot of performance knobs to twiddle that would have just been too costly for human effort. Since we constrain the responsibilities of the agent slop is less of a problem. We relegate it to defined tasks with clear API boundaries and test harnesses.
Jevon's paradox implies we're getting more fast software, and more slow software. Sturgeon’s law implies the ratio will remain the same. 90% of what ships will be slow, buggy, slop. Just as it was before LLMs.
This makes sense for a verifiable task like a regex engine - but those are clearly defined and I doubt an LLM will have a meaningful speed increase over current human regex engines.
Anything else kind of just feels like "make GTA 6, make no mistakes". The ability for you to write fast and correct software is really going to depend on well you can specify your problem, and having the ability to specify correct programs in such detail an LLM can reasonably performance tune it is a big enough reason for me to believe there will still be slow software
Yeah.... maybe. I think AI is still too prone to go down rabbit holes and not understand the whole picture well enough to come up with good optimisations. It's probably good at micro-optimisation, e.g. pre-allocating arrays. But is it going to realise that you don't need that array in the first place? I dunno.
On the other hand it does mean there's no excuse for writing your program using Python or Electron or whatever, which will have a big effect on performance.
>LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly
LLMs have caused such an increase in ram prices that pine64 is no longer making linux machines. When you can't afford RAM, as a direct result of LLMs, it's going to make your assembly app slower too. Sorry, this is the future you chose.
Well, at least with the RAM crunch that the AI boom has caused, I hope there will be some sort of pressure to write efficient software, otherwise device manufacturers are quite fucked.
Yeah, I've been thinking this as well. I have some optimism, but not with high confidence. The exponentially increasing power of computing hardware up until this point is often cited as the reason performance optimization has been sidelined in the software industry. Now that there's a definite hiccup in that trend, I'm hoping programmers will remember that software actually can be fast and memory-efficient, and that poor design choices that lead to bad performance are exactly that, a choice.
The author of the article definitely seems to think LLMs are what enables this to happen, but I personally am much more skeptical of that. I think what it really needs is bringing engineering back into software, not just throwing LLMs at it and calling it a day.
Yah, maybe $1k/dimm on 32 dimm system is a slight price bump.
I've been hoping for this for my entire software engineering career but it never came.
It's messed up. Sometimes it feels like everything in the universe is aligned to ensure that skilled software engineers lead horrible lives full of anguish, frustration and powerlessness.
It feels like the economic system creates incentives which go against efficiency. So then it makes sense that software engineers would be most impacted.
There's a weird duality to our job; it's supposed to be about automation and efficiency but in reality, engineers who make the most money are those who create unnecessary complexity because it creates better lock-in and thus gives them more leverage in negotiations. And the tech monopolies they work for never seem to run out of money no matter how much enshittification occurs as a result.
Same perverse incentive for open source projects; engineers who lead projects that are full of bugs can charge more consulting fees and sell more enterprise licenses to work around the issues.
And engineers are often forced to use shitty tools by their employers so we're always stuck between a rock and a hard place with limited control over our output... Which we are blamed for when things go wrong but never given credit for when we pull heroic feats because those achievements are often overshadowed by missed deadlines resulting from being forced to use shitty software.
Adoption and quality are orthogonal, unfortunately.
Worst part is that nobody listens to us. Business people with money only listen to engineers who have money; who are mostly merchants of complexity. Engineers who care about efficiency have no voice in this market.
Its more about discipline because you now have so much more option for that power, not just optimization. The engineer or the manager can choose more tech debt, then LLM's power is neutered because the complexity to optimize has increased by that much, and somehow evens out, and you are back to square one.
There is no reason for it to be non-extensible either and depending on the use cases people might want to trade speed/optimization for more runtime customizations which will inherently be slower than pre-baked SIMD regex and whatnot.
> performance work that used to require a person or team that had a rare set of skills can be done by anyone who can type a few sentences
This idea is the reason why software will keep getting slower and less reliable. Because it's wrong and yet people believe it.
Not only do people believe this, even if they didn't, they would still have the problem that most people (including many engineers) are bad at telling who is a good software engineer.
So this means that code will get worse and worse; less performant, less reliable, less secure.
It will be impossible to fix because nobody would know what the problems are let alone identify who is able to solve those problems.
I don't know how bad it has to get before people understand we have to rebuild everything from scratch on much more rigid guardrails.
The essence of the problem is that the LLM does exactly what you tell it. In the hands of a skilled engineer who understands the project, this is a superpower. In the hands of a junior, this is dangerous... Because it will do things that are insecure; it doesn't push back on a user request; it just goes ahead and tries to make it work, even if it's a bad idea and the problem is best solved in a different way.
"There's no reason" being very different than "we can now do the thing easier". There are still tons of reasons for software to be slow, the biggest of which is priorities.
If you want your software to be fast, stop writing it in Python and TypeScript and instead write it in Go, Rust, C++ or C. But nobody's going to do that, because humans are emotional creatures who get attached to things (like programming languages). Or if you want your software to be fast, stop spending your time and money (tokens) on features, and start spending it on profiling log replays to find a bottleneck causing a 50ms delay for the 95th percentile. But nobody's going to do that either, because how slow is too slow? Answer: when it's slow enough to scare the shareholders or annoy the developer on their high-powered laptop.
If you want faster/more efficient software, force it to run on a 100MHz CPU with 512KB RAM and a 56k modem. You'll definitely prioritize speed then.
The vast majority of users - weighting by the profits they generate for software companies - obviously don't care about "slow".
And Munger's Law never cares if you hate its consequences.
who is Jamie Brandon
It is https://www.scattered-thoughts.net/
we should just have the LLM rewrite everything in Rust :D
problem solved
Eh, not sure. Very few humans do software optimization productively, so I'm not optimistic about machines built by humans, either. Every encounter I've had with agentic optimization involved trying to apply a bunch of myths to an existing code base, in a way that seemed cool (unrolling loops, eliminating apparent branches, SIMD) but which was all pointless because the only credible optimizations were going to come from doing fewer loads and taking up fewer itlb slots and stuff like that.
Data point of one, but after a few months of uselessness, I have managed to get some pretty serious, measurable performance improvements with AI optimizations -- order-of-magnitude speedups of business critical processes which took days as well as significant latency reductions.
But you need a really solid workflow, solid benchmarks which run quickly, and a lot of tokens -- plus a rigorous profiling workflow.