There's no reason for software to be slow anymore

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.

I've been working on a similar agentically engineered regex project called SafeRE:

https://github.com/eaftan/safere

https://eaftan.github.io/safere-intro/

Mine is for Java and is intended to be production grade. The first goal is to guarantee linear-time behavior to prevent ReDoS attacks. My collaborator and I have recently been optimizing it to try to surpass native RE2 in performance.

It turns out optimizations are incredibly well suited for an agentic loop. You've got concrete acceptance criteria (must show a meaninging improvement on a benchmark case, must pass tests). The agent is really, really good at using tools like a profiler and disassembler, better than I am (and I've been doing this for 20 years). It also papers over things that would take me a while to learn, like how the in-incubation Vector (SIMD) API works in Java. I understand the concept but it would take me a while to understand Java's implementation. The agent can just read the docs and go.

The key is creating a good benchmark suite and ensuring the agent doesn't ship optimizations that are too narrow or too focused on the benchmark cases. You also need a really strong test suite to make sure you're not regressing correctness. SafeRE has billions of tests; a subset of several million run on CI, and the others run on-demand.

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.

ChatGPT MacOSX is the only software that regularly crashes on my machine when its memory consumption for no apparent reason spins up towards 50 GB.

And that software is build by some of the highest paid software engineers on the planet with full access to all the LLM compute in the world.

"LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly."

This person doesn't understand how to make efficient code. I can write code in almost any language (with a couple of exceptions) that outperforms "super-optimized assembly". Writing efficient code isn't about the language, and often isn't about the best algorithms either (but sometimes it is). Its about optimizing memory and cache use. And that's orthogonal to anything the author is writing about. Also, LLMs are terrible at optimizing memory utilization. There is just too little training code that does it well and far too much that doesn't.

As proof, I'm can literally feel the web getting slower and I bet many others feel this as well.

For me the comparison has always been 3DsMax vs Blender. Same kind of software, same kind of features, but Blender is so much faster.

Architectural decisions have always been important.

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.

I understand now that most software is slow because of co-tenancy reasons requiring controlling resources or simply because they're safely insulated from competition. e.g. GitHub is the former: you can give yourself a git host and CI/CD system that is much higher quality by yourself since you're probably not using its social features. I think things like Apple's five-finger inward gesture are the latter. Once you could do it and start typing but nowadays it needs to render the animation etc. before keystrokes register. This software is slow because you cannot replace it in MacOS.

But all these things will change in time. Hell is other people's software.

With RAM becoming expensive, developers will have no choice but to make memory efficient software.

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?

Just an aside. mawk 2.0 (high performance awk) has been out for about a decade. It's about 2x the performance of its predecessor mawk 1.3.4, and 4x performance of GNU awk. Practically no distro uses it, because the author Mike Brennan is not the "I maintain this code in perpetuity" guy and the mawk maintainer Thomas E. Dickey doesn't care move on from from 1.3.4.

The point is: Code needs to be maintained if it is to be relied on. I haven't heard good things about LLM's on that front.

Next time you ask your AI of choice to build an app, please tell them to use plain language without frameworks at all and keep modules to a minimum (ie. node express, ejs and pg, nothing else) and you will see a huuuuge difference

Yes I do understand what author wrote as I read the whole thing, but I argue that title is not universally true.

Like we have OLAP and OLTP, there are still batch jobs that need to happen before you can see your dashboard, we have multiple users using the same resources, there are still DB Locks when writing needed, there are "first load" issues

— heck now we have to compete for resources with even more bots than ever.

Transferring 10GB or 1TB of data still not going to be instant laws of physics still apply.

The linked article is such a gem: You can choose how many bugs you want now https://nolanlawson.com/2026/08/16/you-can-just-choose-how-m...

Love the concept of agents adding epicycles to fix bugs. It maps closely to my experience.

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

There's also no reason for body text spanning the whole width of my 24 inch display.

The article links to "You can just choose how many bugs you want now" https://nolanlawson.com/2026/08/16/you-can-just-choose-how-m...

So going on a tangent: an additional mechanism you have that becomes feasible with LLM assistance today is proving your code correct.

What makes large things slow is not the individual pieces of code but the way the architecture dynamically reacts to changes in the load. Sync vs async calls, buffers, parallel vs sequential processing. This includes optimizations made: do we want to wait until the call returns or do we proceed anyway and deal with the negative response later? Most developers can’t coherently (ie, with math, graphs and figures) explain, how a connection pool prevents undesirable consequences of brief spikes in incoming requests. And I’m pretty sure AI can’t either.

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!

Most of the time, it's the network related stuff, requests that are slow. But with AI, devs nowadays are chasing the aesthetic vibe, cool animations, forward-backward video on the background relative to the scrolls... Which worsen the performance drastically just for a cool landing page. I mean that could be cool for landing page only but some people put all those animations in the product itself too, which is a pain to use.

I was thinking about this the other day, but along a slightly different path. I realised there is no need to use web technology to provide native experiences anymore. Bundling a web browser was always a way to ship native apps to multiple platforms with minimal effort, but these days prompting up an actual native client for each platform is already accessible even to small shops!

That's probably one of the biggest sources of software slowness, and we can just stop using it now, with almost no trade-off. Neat!

I was very much on-the-fence and somewhat sceptical with respect to AI-assisted software development and optimisation, until this recent article pushed me strongly into the "believer" side: https://news.ycombinator.com/item?id=49226923

How will the user know the computer worked 'HARD', if it is not slow?

Do you not add sleep to your programs?

As long as there’s a trade off between experimentation and performance, software will always be slightly too slow.

I had an Odin code base with raylib doing cpu bound stuff. On Catchy OS it tanked my frame rate from 120 to 90 fps (intentionally, seeing what I can get away with). Same build, on Windows 11, 40fps.

the OS makes a huge baseline difference

Dan Luu might benefit from having an LLM optimize his website for readability.

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

[delayed]

I gave Fable 5 access to the database and the browser and asked it to optimize for performance.

Woke up today with 2x improvement and fully tested.

The code optimized was mostly written by humans over the years. That code was too cumbersome to optimize by humans so we never touched it.

What about these reasons?

- Your boss/most of the market doesn't care if your software is slightly slow - Your boss/the market wants new features

It's easier now to slip in fun optimization features when no one's looking, but the incentives are still off.

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

Not paying for premium? That's still a good reason. Even solo SaaS builders have to pay the rent.

This needs to be qualified with "to the degree that you have a specification of what that software should do." The better the spec, the more leeway you can give the optimizer. A very thorough spec lets you give the LLM free reign to run optimization passes over your codebase.

I think this oversimplifies the problem of dealing with performance issues. In my experience, there are three aspects that contribute to the software engineering cost of performance optimizations:

1. Identifying the cause of poor performance. 2. Implementation. 3. Architectural impact (performance is a classic case of a cross-cutting concern)

(I am specifically leaving out the case of realtime systems, hard or soft, where additional factors come into play.)

But the article seems to focus entirely on the second aspect, while largely ignoring the other two.

Most performance bugs are not difficult to fix [1, 2], but can sometimes be hard to identify. Implementation effort is not the driving limitation in those cases.

Conversely, other performance improvements may affect the overall design, e.g. 27% of all bugs identified in [3].

Having an obvious, self-contained optimization target with a benchmark where algorithmic optimization within a module is also the key problem seems to be the exception, not the rule.

Also, not all performance issues are created equal. Many have trivial cost.

In contrast, some of the most challenging performance issues are the ones that affect the design and architecture of the system. After all, the hard part of software engineering is not writing a small, self-contained application. It's managing system complexity, while maintaining (in the words of Fred Brooks) conceptual integrity. Fixing performance issues is at least in this regard not fundamentally different from fixing other software defects.

Unfortunately, this is an area that is also full of trade-offs, such as performance vs. architectural simplicity, or performance in one part of the system vs. performance in another part, all of which requires judgement.

For example, you may need to bypass an abstraction boundary or reorganize abstraction boundaries to improve performance. Or you may have to special-case something while keeping duplicated code at a minimum and easy to maintain.

This is not to say that agents cannot help here, too. In fact, agents can be very helpful at e.g. identifying bottlenecks that are not directly visible in a profiler or can be used quickly do comparative evaluations of the various options for an architectural change. But solving these issues is not, like with the regex example in the article, about hillclimbing towards better performance, but involves a combination of puzzle-solving and design skill, IMHO.

And finally, even a self-contained algorithmic improvement may come with an increased maintenance burden, especially around edge cases and through increased code complexity.

[1] Jin, Guoliang & Song, Linhai & Shi, Xiaoming & Scherpelz, Joel & Lu, Shan. (2012). Understanding and Detecting Real-World Performance Bugs. Sigplan Notices - SIGPLAN. 47. 10.1145/2345156.2254075.

[2] Selakovic, Marija & Pradel, Michael. (2016). Performance issues and optimizations in JavaScript: an empirical study. 61-72. 10.1145/2884781.2884829.

[3] Zhao, Yutong & Xiao, Lu & Bondi, André & Chen, Bihuan & Liu, Yang. (2023). A Large-Scale Empirical Study of Real-Life Performance Issues in Open Source Projects. IEEE Transactions on Software Engineering. 49. 924-946. 10.1109/TSE.2022.3167628.

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

Yes, simply stop using JavaScript and give me static webpages. Done. I don't give a fuck if your website have a nice effect that follows my cursor, I just think about the amount of energy, effort and time wasted on making this demo.

See https://deepseek.com/harness/en/

Is anyone really impressed by this gimmick anymore? Just give me a blank HTML with <table>. Its fine. I dont think anyone care.

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

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.

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

> There's no reason for software to be slow anymore

There has never been. We are running supercomputers. And somehow every app is a dog-slow barely moving monstrosity incapable of showing a page of text without stuttering.

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.

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.

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

LLMs have essentially made any language above the C++/Rust systems level tier obsolete. The only reason you picked a language like C# or Python is often out of convenience of having a broad ecosystem or due to the lower level languages being too hard to master, with too many footguns. The tradeoff being is that you got a less performant implement, while being easier to write. Nowadays, those arguments are dead.

LLMs can now write perfect code in low-level languages, that is frankly _safer_ and _exponentially_ faster than implementations in high-level languages.

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.

I agree with the headline, but I don't think LLMs are a reliable way of optimizing software.

First of all, coding speed is not the main bottleneck. I've been working on my own JavaScript framework. Most of my work is talking to people about challenges they have with web development, doing research on existing tools, and thinking about features to add.

Coding more slowly without LLM usage is a benefit because it helps me understand every line of code. The slower pace also helps me think about making things intuitive and reflect on my experiences with React.

While my framework is outperforming React, that isn't particularly impressive. On the other hand, it demonstrates how ignoring LLMs improves quality. Also, my monthly token spend is $0.