Rendered at 06:39:31 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ehnto 4 hours ago [-]
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.
jcelerier 2 hours ago [-]
I have a new laptop with a rtx 5090. Opening any GL context takes more than half a second. There's tons of things that can be optimized and are pretty far from web.
fc417fc802 1 hours ago [-]
I assume you're running proprietary drivers? Because I've never experienced anything like that on mesa. Launching an app that opens a window with a gl or vk context is so fast on my almost 10 year old hardware that it's nearly imperceptible.
userbinator 2 hours ago [-]
We can only hope that the company building the hardware on which this new age of AI is based on soon starts "vibe-optimising" their own driver stack.
exe34 60 minutes ago [-]
They don't want other companies to train on their IP and regurgitate it to random people.
genxy 2 hours ago [-]
You should profile that, it is probably hitting the registry, the disk and maybe the network.
Try turning off wifi and see if it improves.
jcelerier 1 hours ago [-]
i'm on linux
4k0hz 1 hours ago [-]
No idea about your setup but that's probably a fixable driver issue. My desktop with an RTX 40-series GPU takes _maybe_ 4 frames to create an OpenGL context.
ntoskrnl_exe 18 minutes ago [-]
Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick.
Don’t know about that, pretty much everything is hosted on Cloudflare, Azure or S3 these days and all of them have at least one CDN on each continent.
alightsoul 1 hours ago [-]
In my experience the main driver of latency is not ping time, but how long the server takes to process the request.
andersmurphy 54 minutes ago [-]
I think a lot of the time when people say the network is slow. They really mean their backend is slow.
With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU).
With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger.
Now the network to you is distance to the server (not your rail/nextjs backend taking 400ms). Things like 4G and 3G are fine. The real problem is when you have such bad signal you effectively have no down or up.
fhub 26 minutes ago [-]
1-5ms response time is clearly hard for most real world endpoints.
hsn915 4 hours ago [-]
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
otterley 11 minutes ago [-]
It isn’t, but at the same time, smart hackers were working with highly constrained PC hardware in the 1980s and early 1990s and were cranking surprisingly good performance out of it. Folklore.org has plenty of stories about it, and John Carmack’s early career history is very impressive. We mustn’t forget the demo scene hackers either.
alightsoul 1 hours ago [-]
That's why phones and windows use animations. You can also use intersitials related to the product you sell. Users are usually fine seeing many changes on the screen quickly because it gives the impression that stuff is happening on the background. For example in the interstitial, use an animation that takes up a small portion of the screen and not just a simple spinner or loading icon. Something more complicated with 2 or more things moving or changing at once.
jbstack 18 minutes ago [-]
If your app absolutely must rely on the cloud for every one of its interactions, then fine. If not, you're just applying band-aids to a problem of your own making. Many apps could easily be local only, or local first. If you're not constantly accessing the network for information which could be stored locally, then you don't need to hide your app's slowness behind animations.
alightsoul 11 minutes ago [-]
Canva replaced PowerPoint. Canva is cloud based and PowerPoint is not. There's so many apps that are cloud only so that corporate it no longer has to manage installations and users don't need to ask IT for permission anymore. I think SaaS doesn't really work without the cloud, you could technically do what adobe does but why bother with app distribution and windows' quirks. Cloud based web apps are write once, run anywhere come true with no installation required. Cloud based is more convenient for the user and the developer, at the cost of app runtime speed
ddejohn 26 minutes ago [-]
> Users are usually fine seeing many changes on the screen quickly because it gives the impression that stuff is happening on the background
This gave me a chuckle because I personally hate things like watching the browser jump through 50+ redirects when logging into a website.
alightsoul 13 minutes ago [-]
My bad, I mean the interstitial. Like it should stay for at least a second to not make it jarring. People believe computers need to think so you can't make things too fast either. Not the interstitial and not the app either, to the point you sometimes have to deliberately slow down the app, add latency to make people trust it because it "gives the computer time to think"
jmtulloss 2 hours ago [-]
I’ve been playing with this with software that needs to work with agents and also without internet at all (we’re serving construction projects that have limited access)
Obviously agent access goes away with internet failure but the state doesn’t need to… we use CRDTs and a virtual FS. There’s a toy-ish version of the harness at https://ourhearth.ai … if local first is interesting to you I’d love your feedback
energy123 3 hours ago [-]
Can't they use ML to predict where I'm going to click, and pre-cache the predicted page whenever the predicted button doesn't mutate important state? Or skip the difficult ML and have some basic rule of thumb that pre-caches frequent button clicks, using a markov chain, and conditioned on those pages being low bandwidth to pre-load.
markerz 2 hours ago [-]
So Next.JS actually pre-fetches links when they move into the viewport or you hover over it. It's interesting, but then you get wasted battery on mobile while on bad networks. The world is full of tradeoffs. Tech workers tend to want to consume more battery and data to be faster. Other people want to do less work.
In my view, websites should not take seconds to load with gigabit fiber. Whatever happened to "mobile first"?
supriyo-biswas 2 hours ago [-]
> pre-caches frequent button clicks, using a markov chain
I don't think the current crop of fullstack engineers would be hard pressed to know what a "markov chain" is, but in theory yes, you could emit a bunch of speculation rules[1] based on your predictions.
I should also say that markov chain based approaches have been used for fraud detection, e.g. identifying checkout anomalies by detecting the sequence of web pages that they clicked on, amongst other factors.
If we stored the edges (links) and nodes (pages) separately, rather than requiring you to blindly run a node's code just to discover what its edges might be, then you could skip the prediction and instead pre-cache the next hop for all edges just in case you follow one. You could even do this to two or three hops.
This might seem wasteful, but if the web were content addressed instead of server addressed you could then be serving that cache to your municipality even after it became disconnected from the rest of the internet. Which sort of recasts it not like wastefulness but instead like fault tolerance and preparedness.
We could maybe even dispense with the servers entirely.
There are so many different ways to build a web. Why does it feel like we've landed on the worst possible one?
charcircuit 1 hours ago [-]
>but if the web were content addressed instead of server addressed you could then be serving that cache to your municipality even after it became disconnected from the rest of the internet.
This is already possible without content addressing with CDNs. They can serve content from a local cache even when the host is disconnected from the internet.
TeMPOraL 26 minutes ago [-]
And the first thing webdevs did once this became widely available, is change their apps to cache-bust their code; between that, and the short release periods in webshit ecosystem in general, and security and privacy considerations messing up things as usual, the promise of users mostly hitting just local cache with any marginal request, never materialized.
Onavo 2 hours ago [-]
> If we stored the edges (links) and nodes (pages) separately, rather than requiring you to blindly run a node's code just to discover what its edges might be, then you could skip the prediction and instead pre-cache the next hop for all edges just in case you follow one. You could even do this to two or three hops.
Welcome to Next.js
__MatrixMan__ 2 hours ago [-]
Can next.js give me a page's links without requiring that I execute any code that I didn't have prior to visiting that page?
The problem isn't in preloading, it's in how much data needs to be sent while quite probably most of the data could be either fetched on startup in an efficient format and rendered natively, or is completely unnecessary in the first place (telemetry, ads).
CalRobert 2 hours ago [-]
Heh, this is how browser accelerators from the dial up era worked
3 hours ago [-]
aaron695 3 hours ago [-]
[dead]
arjie 22 minutes ago [-]
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.
Nevermark 13 minutes ago [-]
> Apple's five-finger inward gesture are the opposite. Once you could do it and start typing but nowadays it needs to render the animation
There is no technical reason that animation should take that long.
Someone said, "good enough" and let it be visibly slow. The reasons for that could be anything, including non-performant code in dependencies, written by other people. But it just does not take much computing power by today's standards to composite code-generated animation.
Somehow, despite year after year of percentage-speed hardware improvements, there are cultural and structural reasons people ship code visibly slower than it needs to be. And faster compute appears to be irrelevant.
arjie 1 minutes ago [-]
Perhaps the real tragedy is not the animation. It is the fact that previously keystrokes would register even if the animation had not completed and now they do not. Interaction once you've entered a new mode should be instantaneous. Instead we are faced with inputs going neither to the old app nor to the new app.
eaftan 3 hours ago [-]
I've been working on a similar agentically engineered regex project called SafeRE:
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.
za3faran 2 hours ago [-]
This sounds very interesting. Which JVM profiler do you use?
stickfigure 2 hours ago [-]
Not OP, but I went through this last week. I (ok, codex) optimized a hot path in some Java code from ~350ms to ~60ms, which made a substantial difference in "is this whole business going to work".
My Java profiling knowledge is... let's call it "antique". I was really not looking forward to ramping back up for this work. Turns out, I didn't have to do any of it. The LLM chose the tools (flight recorder) and even built a JMH (also new to me) harness to experiment with different algorithms.
About half of the optimizations were things that I would have figured out on my own; the other half were definitely "wow" moments.
The whole thing was done in a couple hours, with just a few back-and-forths. Sans AI, it would have taken a week, with nowhere near the same gain. I'm impressed.
"Figure out how to make this process fast" is really a perfect activity for LLMs. And the prompt doesn't really have to be much more sophisticated than that.
chii 18 minutes ago [-]
> the other half were definitely "wow" moments.
do you have some samples? It would be interesting to learn what it might be.
eaftan 43 minutes ago [-]
I've been using:
JMH as the framework to write microbenchmarks. It takes care of dealing with JIT warmup, etc. It's the standard way to write rigorous Java microbenchmarks.
async-profiler (https://github.com/async-profiler/async-profiler) for profiling. Java has a problem where many profilers are based on safepoints, which are biased toward particular program points. async-profiler is not biased in this way.
Java Flight Recorder for memory allocation data.
One thing I've observed in all of this is that it's really useful to have expertise in the programming language and ecosystem you're writing in, otherwise it's all Greek to you and you can't really guide the agent to do the right thing. I have opinions about e.g. profilers and I can point the agent to one that I think is more accurate than other options.
mccoyb 4 hours ago [-]
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.
Aurornis 4 hours ago [-]
> - 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.
mccoyb 4 hours ago [-]
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).
2 hours ago [-]
senderista 3 hours ago [-]
Agreed, IME Fable can churn out decent SIMD kernels optimized for whatever tradeoffs you give it.
josephg 3 hours ago [-]
> iykyk
A story.
I have a friend, who is - like me - interested in the CRDT / collaborative editing space. He asked ChatGPT to write him a CRDT. Then he grabbed every good CRDT implementation, and asked chatgpt to benchmark and optimise his CRDT, using tricks and techniques from existing hand-optimised CRDTs. He got massive performance gains by doing this - which is really interesting! I think it helped that he had a clear objective function, and chatgpt could look at other projects for ideas on how to optimise.
He proudly boasted that his resulting code outperformed my diamond-types library. I asked him if he was comparing against the native implementation, or the -Oz webassembly build, running in a wasm vm. It was the latter. When he tested it properly, his CRDT was - and is - significantly slower than diamond types. As far as I know, chatgpt still hasn't been able to catch up. I tried myself using fable. Even with reference to my source code, Fable still doesn't understand what I did in diamond types and why. (... Maybe I should document what I did!)
I think his technique itself is solid though. I tried it myself. I asked fable to write a custom binary serialization format & parser. Then optimise. Then optimise, with explicit reference to existing libraries. Optimising with reference to other code made a huge additional difference. It is now nearly as fast as those libraries. (But still not faster than them.)
My takeaway is this: I think LLMs are exceptionally good at reading and understanding code. If you guide them to do so, they're good at profiling and benchmarking. But it seems like they're not very good at coming up with novel optimisations. If you have an obviously slow program (for example, some slop claude wrote), you can often get big speedups by asking it to benchmark and optimise. But if you have a complex, already well optimised codebase, like the zig compiler, claude doesn't seem very good at figuring out novel ways to improve things on its own.
This is good news for the 95% of slow software out there. But bad news for the 5% of us who write fast code already, but want our code to go even faster.
fc417fc802 56 minutes ago [-]
The refutation of your takeaway is autoresearch and similar. They can brute force novel optimizations (and generally achieve superhuman performance) when provided with an appropriate environment.
Of course that doesn't mean they have a human level mental model and associated novel ideas. Brute force can be effective but remains entirely unsatisfying from an academic perspective.
hiddencost 2 hours ago [-]
> A stochastic search process with an executable optimization objective over space of programs S can only maintain or improve the objective
Reasons this doesn't follow:
(1) Benchmarks never match real world use, and many optimizations the improve benchmarks degrade cases that aren't measured (think about how CPU cache behavior can be surprising)
(2) In software performance optimization, frequently there is significant noise, from many sources. This makes it difficult to guarantee that a measured change is actually an improvement.
fc417fc802 52 minutes ago [-]
Both of those things are indicators of deficiencies in the testing process.
hunterpayne 58 minutes ago [-]
"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.
whatisthiseven 24 minutes ago [-]
My contradictory proof: I have been working on an old service with tons of performance issues, from server memory bloat, client graph rendering, excessive network requests, excessive repeat rendering, memory leaks, resource leaks, etc.
The app and service are measurably and subjectively faster. Because I chose to have the LLM focus on solving those problems. It obviously can. It described the issues in big-O.
It is a priority problem, as it always has been, not a knowledge or skill problem, like it always has been.
malisper 41 minutes ago [-]
> This person doesn't understand how to make efficient code
The author is one of the most knowledgeable people about performance there is
ddejohn 17 minutes ago [-]
The author was paraphrasing a tweet written by somebody else:
> The other day, I saw a viral tweet saying [...]
userbinator 21 minutes ago [-]
Also, LLMs are terrible at optimizing memory utilization.
A vibe-coded OS that runs on an 8088 with 256KB of RAM.
As proof, I'm can literally feel the web getting slower and I bet many others feel this as well.
"It's not the tool, it's how you use it..."
amarant 12 minutes ago [-]
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!
jjcm 4 hours ago [-]
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.
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?
Should note the server is on USW and I don't have edge servers for it at the moment.
ltbarcly3 3 hours ago [-]
Why is it so slow? Like clicking around this is a very simple site, it seems like the fade in and fade out, besides being jarring and annoying, is just adding load time.
intrasight 4 hours ago [-]
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.
alightsoul 1 hours ago [-]
At some point, probably in the 1980s, people probably decided that computers could update UI fast enough, so any additional compute power or speed has been used for other things like making it prettier or reducing development effort or time, and now ai
paulhebert 3 hours ago [-]
It’s all incentives. I’ve worked on web projects where the people in charge cared about performance. It’s easy to get sub second speeds if you start with that goal.
I’ve also worked on projects where the people in charge added 1mb client-side mapping libraries to render a static map and ignored my push back. Those website were slow
cyteeditor 54 minutes ago [-]
[flagged]
Kuyawa 3 hours ago [-]
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
spockz 17 minutes ago [-]
Basically you are telling the agent to inline those frameworks. It has access to the frameworks, their functionality, and how they implemented things, combined with countless examples on how to use those frameworks.
If only we had a sufficiently smart™ compiler, it could do the inkling, dead code elimination, and WPO across the application.
(Oh we do have that, as long as you don’t write in JavaScript…)
alightsoul 1 hours ago [-]
I had the same thought a few days ago. Coding agents have rendered frameworks obsolete. Apparently many people disagree though.
catlifeonmars 32 minutes ago [-]
I like to use frameworks to steer the agent. I constrain it different primitives for different tasks in order get the shape I want without explicitly prompting too much. You can think of it as API driven development
globular-toast 23 minutes ago [-]
If this it true, the frameworks will either move to the specs or, worse, remain in the models.
You can't exhaustively write down all the possible ways for software to execute, especially since many programs run forever (e.g. servers, GUIs etc)
So when you say in your spec "when the user clicks here it shows this stuff" there is the tacit expectation that this will always happen and isn't dependent on the entire execution path up to this point. You also wouldn't expect a server to just finish execution after processing a request because you forgot to write "finally, cede control back to the main loop" at the end.
These assumptions are the framework. Almost everything you read is likely written in a framework, unless you limit yourself to non-technical writing for younger readers.
You could try to formalise the framework in your specs. But you'll then end up copy and pasting these paragraphs every time you want another server program. These context frameworks will probably get names, just like today.
Or you could skip that entirely and pretend you're not using a framework, but you are. It's just that the most has already learned tons of frameworks. What worries me here is stagnation. There's no way for the model to learn new frameworks. But this might be a short term effect. Maybe software in the next few years will look quite odd to those in the future as we keep writing it in the language of frameworks we already know. Maybe they'll look back at these relics and ask "what is a view, and why did the model understand that?"
esikich 2 hours ago [-]
Yep, I feel like there's less of a reason to use frameworks now that you can just have it bash out only the needed stuff on its own. I've been able to make some really really tiny C tools and I'm absolutely loving it.
albert_e 2 hours ago [-]
Good point.
Maybe if this philosophy / approach has a catchy name it might be more widely adopted and we all can have better more performant web and apps.
hirvi74 1 hours ago [-]
My experiences might mirror yours to some degree.
I somehow managed to avoid the entire SPA scene. I feel so vindicated because I am absolutely zooming with my tried and true Vanilla JS these days. I have tried React, Vue, Angular, and ever just plain TS, and I hate them all.
robertoandred 56 minutes ago [-]
> my preferred frameworks can’t possibly be slow and yours can’t possibly be fast
belZaah 1 hours ago [-]
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.
Whether it can apply it directly from the codebase, I’m unsure and depends on many factors.
dat999zx 1 hours ago [-]
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.
1 hours ago [-]
Lerc 5 hours ago [-]
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
devin 4 hours ago [-]
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.
So going on a tangent: an additional mechanism you have that becomes feasible with LLM assistance today is proving your code correct.
userbinator 2 hours ago [-]
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
bensyverson 4 hours ago [-]
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!
hombre_fatal 1 hours ago [-]
That said, performance and security considerations can be automated by a reusable harness and I think within six months it will just be built in to things like claude code and codex the same way you might tack on a performance/security section to your project's AGENTS.md.
A crude example is how, when building a large forum project years ago, I had a checklist I ran on every new http route: authentication, authorization, validation, etc. just because it's trivial to forget one of them. Yet now the LLM can come up with a lintable/verifiable way to ensure every route has the whole kit by construction.
Almost every way I feel like I can provide unique value to the automated AI workflow (aside from deciding what to build at all, and taste) feels like it can be automated by better markdown.
em3rgent0rdr 3 hours ago [-]
Reader mode (built-in to both Chrome and Firefox) does the trick.
0xblinq 2 hours ago [-]
There's no reason for sites to look super ugly, full width and unreadable anymore.
killbot5000 5 hours ago [-]
As long as there’s a trade off between experimentation and performance, software will always be slightly too slow.
aurareturn 3 hours ago [-]
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.
asdfman123 3 hours ago [-]
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.
ltbarcly3 3 hours ago [-]
I can't tell if you are saying the market doesn't care if your software is slow, or quoting someone else. Either way it's objectively false and that has been known for decades. Making users wait is a surefire way to make them engage with your product less, and the more you make them wait the less they will use it.
If your boss doesn't care about your software being slow he's incompetent.
The market cares. In my experience it’s harder to make your boss care.
It’s often been hard for me to make coworkers care as well which is even more frustrating.
Unless your job really prioritizes performance and builds in benchmarking people often focus on finishing a feature as fast as possible and ignore performance (and accessibility, bugs, UI polish, etc.)
asdfman123 2 hours ago [-]
Experiments demonstrate that increasing web search latency 100 to 400 ms reduces the daily number of searches per user by 0.2% to 0.6%
It obviously depends a lot on what you do, but often that doesn't matter.
ltbarcly3 1 hours ago [-]
Do you think most websites are hitting 100ms? You are picking silly numbers. The real world case is more like 500ms vs 2.5s. The pingdom numbers suggest that is more like 5%. It's very common for pages to take over 5s to load. That is a huge bounce multiplier. I just did a search for "sony lens" on fb marketplace, and it took about 2s to load the page. This is a very very optimized page, it got some results at the top within 500ms, which was probably enough to fill above the fold on mobile (and thus seem like it was finished). however the broader search to fill the results took about 2s. When I worked at eBay searches took 2-3s routinely if they weren't warm. Getting to 100ms for a lot of very important ecommerce pages, which are critical in terms of bounce rate sensitivity, is a real engineering challenge that millions of dollars are spent on. Imagine if eBay could get 3% lower bounce on their search pages, delivering that would make multiple careers.
3dedb728-3f77 4 hours ago [-]
How will the user know the computer worked 'HARD', if it is not slow?
Do you not add sleep to your programs?
gr_norm 2 hours ago [-]
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 total free rein to run optimization passes over your codebase.
3 hours ago [-]
nemothekid 5 hours ago [-]
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
canada_dry 4 hours ago [-]
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.
shoopadoop 4 hours ago [-]
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
4lx87 4 hours ago [-]
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.
paulhebert 3 hours ago [-]
I wonder if AI has changed the 90% rate. From my perspective it’s already increased the ratio of what I’d consider bad.
I haven’t seen as big of an impact on the “good” side. People with attention to detail and craft can use it with great results but they’re not pumping things out at the speed of the slip slingers.
phyzix5761 2 hours ago [-]
Software will get slower as we do things beyond the current hardware capabilities which is always the case as hardware improves.
vinyl7 1 hours ago [-]
We have yet to reach the limit of the radius that we already have
> 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.
rfgplk 31 minutes ago [-]
> This idea is the reason why software will keep getting slower and less reliable. Because it's wrong and yet people believe it.
Not even close to being true. Prior to the advent of LLMs writing good SIMD was hard. Writing good SIMD for arbitrary tasks was _extra_ hard. Having the entire application be written with SIMD in mind was nigh impossible, from simple string parsing to data pipelining. Having arbitrary OpenCL/CUDA offloading to GPUs was a monstrous task. And even the people who were experts in these domains didn't have the time to do it in an afternoon.
But now you can. You can literally instruct your agent to write SIMD accelerated code everywhere, or to optimize down to it. And it just _does_.
> The essence of the problem is that the LLM does exactly what you tell it.
This is correct. I implore people to try writing a SaaS with an LLM, but instead of going the classic agentic project style of "design me an app", tell it to use C++ or Rust, use extensive SIMD intrinsics and inline assembly wherever possible. Just off those two instructions the difference in code quality is staggering.
rfgplk 36 minutes ago [-]
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.
raincole 34 minutes ago [-]
Yeah, let LLM write C++ when your team have cannot comfortably write C++ in the first place. This is surely a frankly safter way than human-written C# and Python.
rahkiin 7 minutes ago [-]
Yes indeed, that will be a much better road to a durable, maintainable, secure and agile product than focusing on product goals in a higher level language with a framework.
When will we start using LLMs to write my web backend directly in UEFI and assembler? (Although uefi is an OS, so maybe more fair to exit the boot services)
HumblyTossed 4 hours ago [-]
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.
gravypod 5 hours ago [-]
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.
anon-3988 3 hours ago [-]
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.
Is anyone really impressed by this gimmick anymore? Just give me a blank HTML with <table>. Its fine. I dont think anyone care.
radium3d 3 hours ago [-]
Sites can be fast with PHP and JavaScript. The slowness you see is mostly coming from all the frameworks too many developers "include" willy nilly with code that can only be described as bloat because 99% of it is completely unused, yet being loaded and computed by the browser on every load. That's what you're experiencing on too many websites.
rfgplk 27 minutes ago [-]
Funnily enough, since most JS frameworks are utter junk, developers are better off instructing LLMs to write pure JS instead.
Fun story, I was writing some 3D graphics animations for a website, and the only dependency I allowed was three.js. It ran well, but the site was loading slightly too slow so I told the LLM to optimize. It essentially hit a hard wall and told me something along the lines of "I can't optimize further, three.js is the bottleneck due to blablabla, but you don't need it. If you want I can rewrite it with pure WebGL". I said sure and load times were cut by like 90% and framerate went up too. Staggering.
panny 5 hours ago [-]
>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.
pdimitar 4 hours ago [-]
[flagged]
IshKebab 4 hours ago [-]
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.
paulhebert 3 hours ago [-]
The reason for using Electron is to write once and run everywhere right?
I get that LLMs would make it faster to write distinct copies for different operating systems and maintain them both but thats still more costly than a single system.
Sorry if I’m misunderstanding the goal of Electron but it still seems cheaper and easier (although admittedly worse than multiple native apps)
supriyo-biswas 5 hours ago [-]
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.
WCSTombs 4 hours ago [-]
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.
newsomix9xl 5 hours ago [-]
Yah, maybe $1k/dimm on 32 dimm system is a slight price bump.
jongjong 4 hours ago [-]
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.
briheet 4 hours ago [-]
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
gulugawa 1 hours ago [-]
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.
1 hours ago [-]
squirrellous 1 hours ago [-]
This doesn’t seem to mention that having AI aggressively optimize software will result in code that is too clever / complex to be maintained by the original human author. For something with a very stable API and can be tested to death like a regex engine it’s likely
workable. Other things, not so much. We have enough trouble maintaining AI generated code _without_ aggressive optimizations as is!
0xbadcafebee 4 hours ago [-]
"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.
measurablefunc 5 hours ago [-]
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.
newsomix9xl 5 hours ago [-]
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.
y1n0 4 hours ago [-]
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.
devin 4 hours ago [-]
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.
noosphr 4 hours ago [-]
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.
hodgehog11 4 hours ago [-]
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.
adamddev1 2 hours ago [-]
Tests do not prove the absence of bugs.
4 hours ago [-]
4 hours ago [-]
archargelod 4 hours ago [-]
How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.
aw1621107 4 hours ago [-]
> 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"
rfgplk 24 minutes ago [-]
You can formally prove the correctness of even massive programs.
thorian1828i03 4 hours ago [-]
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.
jongjong 4 hours ago [-]
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.
globular-toast 53 minutes ago [-]
It doesn't sound very intelligent to just brute force iterate until you pass all the tests. This sounds like what Rich Hickey called "bashing into the guard rails". Even if we assume the tests suite is perfect and will guide the model to a correct solution, maybe this is one case we really should just say "LLM" rather than "AI".
zx8080 4 hours ago [-]
It's all now about money extraction from the areas dependant on software, not the sofrware itself.
moron4hire 4 hours ago [-]
If you have such a test suite then you really don't need AI to write the code for you.
thorian1828i03 4 hours ago [-]
Writing a benchmark test is about 100x to 1000x easier than writing optimizations. A benchmark test can be as simple as:
func Benchmark(b *testing.B) {
for range b.N {
runCodeUnderBenchmark()
}
}
Actually optimizing the runCodeUnderBenchmark() function is far more difficult.
petra 4 hours ago [-]
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?
jayd16 4 hours ago [-]
Aha, the problem is you're asking for code that works.
calvinmorrison 4 hours ago [-]
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
paulddraper 4 hours ago [-]
The goal posts always move
phucphungbk 3 hours ago [-]
[flagged]
etoxin 4 hours ago [-]
[dead]
SadErn 4 hours ago [-]
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.
hollowturtle 3 hours ago [-]
> Repeating these things won’t make them true or protect your job.
Most of these things are just true as of today.
> You protect your job by learning how to use new tools as the technology advances.
Sure and the more you learn the more you see how hyped they were and reality untangle
> Engineers don't ask a tool to write code.
And what they ask? They create loops or graphs? These tools ultimately vomit code anyways
bitwize 3 hours ago [-]
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.
hollowturtle 3 hours ago [-]
Very much not a skill issue; even with the best spec, guardrails and evals, frontier models will just do the hell they want.
> one-shot secure, performant code.
I call it reverse skill issue; it feels secure and performant because you can't verify properly, it feels right but it's actually broken in many nuanced ways. You can measure performance and produce a broken measurement as well. It's not as simple as you make it
hombre_fatal 52 minutes ago [-]
You can just ask Claude to create a workflow that fans out agents looking for security issues and performance issues, rank them by impact vs confidence, and get a really good list. Then do it again. Then do it again but to vet/verify every finding in the list. Then do it again if you want.
And the list will be all really good issues. Fully automated. The only limitation being tokens and time.
Now do this as part of your normal, automated development cycle.
Software is basically solved. We're just figuring out the ideal harness and token thift to automate high quality.
baliex 3 hours ago [-]
Color me sceptical but I’d say that’s a bold claim.
Can you give a concrete example of that being the case? I’d love to see the prompt and harness. And understand the scale of problem you’re talking about solving with a one-shot approach.
How long will it take to write the right spec? How will you know ahead of time that the spec is correct?
Which agentic guardrails do you mean? How can they be set up?
-
I’d say the job of software engineering is still firmly being able to stand by the work you present and being reasonably confident that it’s correct according to yours and others’ understanding of the problem you’re attempting to solve.
dionian 3 hours ago [-]
I feel so nostalgic viewing this website. I love the simple old school design. we need to bring it back
raincole 5 hours ago [-]
100% sure software in the coming years will just feel slower and slower.
qball 4 hours ago [-]
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.
mbirth 5 hours ago [-]
It will be the equivalent of that Excel =COPILOT(“sum the numbers above”) meme.
transcriptase 3 hours ago [-]
aka electron
Grombobulous 5 hours ago [-]
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.
champagnepapi 5 hours ago [-]
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
0x20cowboy 4 hours ago [-]
> People are shipping all sorts of weird architectures, non-performance code, etc.
And they weren’t before AI?
wlesieutre 4 hours ago [-]
Is iOS 27 particularly impressive, or was iOS 26 a shitheap? Maybe a bit of both.
senderista 4 hours ago [-]
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.
devin 3 hours ago [-]
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.
m463 3 hours ago [-]
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?
beej71 4 hours ago [-]
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.
jeswin 3 hours ago [-]
For Desktop use, 100% of electron and python slowness will be gone in a couple of years, at least for new projects. If you're using Rust (or Mojo or C/C++), you'll have to try hard (almost a deliberate effort) to make software slow.
phucphungbk 3 hours ago [-]
[flagged]
m3kw9 4 hours ago [-]
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.
datsci_est_2015 4 hours ago [-]
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”.
efsavage 4 hours ago [-]
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
trgn 4 hours ago [-]
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.
cwnyth 3 hours ago [-]
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.
trgn 3 hours ago [-]
I believe it, but what's the point of having them then.
cwnyth 3 hours ago [-]
To do the best they can do within the confines of what's politically acceptable. There's an intersection near me that is just horrendous, but the engineer I talked to, who is now retired, said it was his mentor's task to fix it some 50 years ago. Actually fixing it, though, would require removing parking spaces, and the mayors have routinely vetoed that idea after they received pushback.
The people are to blame. You get what you vote for.
datsci_est_2015 3 hours ago [-]
I mean that was kind of my point, but judging by the responses I may have been too snarky.
Both the traffic engineer and the author of this blogpost are well-qualified enough in their fields of expertise to be careful about the claims that they make with regards to speed and efficiency.
A big issue is how those claims are interpreted by non-technical people, especially in leadership. Would hate for my CEO to stumble upon this blog post and believe, based on the title and a brief skimming, that his engineers just aren’t using AI correctly and that’s why the website still takes a few seconds to load its content.
paulddraper 4 hours ago [-]
But it will definitely improve, either speed or volume.
coaksford 4 hours ago [-]
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.
Negitivefrags 3 hours ago [-]
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.
globular-toast 49 minutes ago [-]
Most people use roads to get to work. It's definitely not where they want to go.
dwattttt 4 hours ago [-]
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.
shoopadoop 3 hours ago [-]
Check out the Downs-Thomson paradox.
Timpanzee 3 hours ago [-]
I agree with traffic example, however, I don’t think it quite applies to software in the same way. Imagine a world where for some reason our current quality of hardware is locked in place; they can never get better or faster in any way shape or form. Then the big tech race will be optimizing software. I personally think that there would be a 10x to even 100x increase in software speed that is possible through many optimizations. The current software incentive is geared more towards adding more features rather than optimizing performance since software engineers know they can always know hardware will keep getting better which will keep their
slower, less optimize software at similar speeds. This isn’t a critique of software engineers, simply a statement of the incentives under which they operate.
xbar 4 hours ago [-]
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.
datsci_est_2015 3 hours ago [-]
The title is a disservice to the author’s point of view, then, because the article also reads as a “look what agents can do to optimize a toy problem” blog post.
Maybe the author should be a bit more careful about what titles they give their blog posts, lest they be misinterpreted by mere mortals such as myself.
BobbyTables2 3 hours ago [-]
I get the paradox for adding a few lanes…
Imagine traffic not getting any better after adding 1000 lanes in a medium sized town… not just to one area but to every single damn road.
Yet we’ve done this with RAM, CPU, and storage…
wolpoli 3 hours ago [-]
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).
w-ll 4 hours ago [-]
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.
Grimburger 4 hours ago [-]
Still a struggle to get coworkers to write docs or tests despite it being effortless.
At the end of the day its a mindset.
panzi 4 hours ago [-]
What's the public transport of software development? Where can I get good train service here?
AdieuToLogic 4 hours ago [-]
> What's the public transport of software development?
Understanding.
m463 4 hours ago [-]
just¹ prompt like the lotus philosophy:
Simplify, then add lightness.
[1] hn favorite word
phucphungbk 3 hours ago [-]
[flagged]
bell-cot 5 hours ago [-]
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.
ungreased0675 5 hours ago [-]
But software seems to be getting slower and less user friendly by the hour.
mortenjorck 5 hours ago [-]
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.
stopIiiiit 5 hours ago [-]
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.
rochak 5 hours ago [-]
Isn't this just enshittification? Where money is the driver, enshittification is just bound to happen.
stopIiiiit 5 hours ago [-]
If that euphemism makes sense of it for you, sure.
an0malous 4 hours ago [-]
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.
we should just have the LLM rewrite everything in Rust :D
problem solved
wseqyrku 2 hours ago [-]
- Computer, enhance.
hardaker 4 hours ago [-]
What if we need pretty, rounded, softly opaque corners on all our transparent windows hovering above a gently shadowed background?
userbinator 2 hours ago [-]
The demoscene could do that, and much more, on 90s hardware.
m463 4 hours ago [-]
apple might sue you for infringing on their primary money maker
jeffbee 5 hours ago [-]
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.
tekne 4 hours ago [-]
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.
jeffbee 3 hours ago [-]
What I want is the PMU in the loop.
nicekiwi 28 seconds ago [-]
[dead]
malixp 2 hours ago [-]
[flagged]
luciana1u 1 hours ago [-]
[dead]
solarized 3 hours ago [-]
[flagged]
theturtle 4 hours ago [-]
[dead]
theturtle 4 hours ago [-]
[dead]
tobinfekkes 5 hours ago [-]
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.
jaggederest 4 hours ago [-]
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"
vessenes 4 hours ago [-]
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.
4 hours ago [-]
userbinator 2 hours ago [-]
What exactly do you mean by "make it approachable"? Is the content-to-fluff ratio too high for you? This page is exactly what I want the majority of websites to look like: no fluff, no idiotic "modern design" trendchasing bullshit, just pure and simple content.
Also, perhaps you should learn how to make use of the user stylesheet feature of your browser, or ask an AI to tell you how...
4 hours ago [-]
vagab0nd 3 hours ago [-]
"There's no reason for websites to be ugly anymore"
beyonddream 5 hours ago [-]
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.
privong 4 hours ago [-]
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.
I think he might subscribe to the philosophy of everyone should style websites however they like and not be prescribed by the author.
markdown 4 hours ago [-]
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.
tom_ 4 hours ago [-]
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.
markdown 4 hours ago [-]
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.
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.
Try turning off wifi and see if it improves.
Don’t know about that, pretty much everything is hosted on Cloudflare, Azure or S3 these days and all of them have at least one CDN on each continent.
With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU).
With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger.
Now the network to you is distance to the server (not your rail/nextjs backend taking 400ms). Things like 4G and 3G are fine. The real problem is when you have such bad signal you effectively have no down or up.
* Must feel very responsive * Network requests can take up to 500ms end to end
This gave me a chuckle because I personally hate things like watching the browser jump through 50+ redirects when logging into a website.
Obviously agent access goes away with internet failure but the state doesn’t need to… we use CRDTs and a virtual FS. There’s a toy-ish version of the harness at https://ourhearth.ai … if local first is interesting to you I’d love your feedback
https://nextjs.org/docs/app/guides/prefetching#hover-trigger...
In my view, websites should not take seconds to load with gigabit fiber. Whatever happened to "mobile first"?
I don't think the current crop of fullstack engineers would be hard pressed to know what a "markov chain" is, but in theory yes, you could emit a bunch of speculation rules[1] based on your predictions.
I should also say that markov chain based approaches have been used for fraud detection, e.g. identifying checkout anomalies by detecting the sequence of web pages that they clicked on, amongst other factors.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Speculation...
This might seem wasteful, but if the web were content addressed instead of server addressed you could then be serving that cache to your municipality even after it became disconnected from the rest of the internet. Which sort of recasts it not like wastefulness but instead like fault tolerance and preparedness.
We could maybe even dispense with the servers entirely.
There are so many different ways to build a web. Why does it feel like we've landed on the worst possible one?
This is already possible without content addressing with CDNs. They can serve content from a local cache even when the host is disconnected from the internet.
Welcome to Next.js
The .js part makes me think not.
But all these things will change in time. Hell is other people's software.
There is no technical reason that animation should take that long.
Someone said, "good enough" and let it be visibly slow. The reasons for that could be anything, including non-performant code in dependencies, written by other people. But it just does not take much computing power by today's standards to composite code-generated animation.
Somehow, despite year after year of percentage-speed hardware improvements, there are cultural and structural reasons people ship code visibly slower than it needs to be. And faster compute appears to be irrelevant.
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.
My Java profiling knowledge is... let's call it "antique". I was really not looking forward to ramping back up for this work. Turns out, I didn't have to do any of it. The LLM chose the tools (flight recorder) and even built a JMH (also new to me) harness to experiment with different algorithms.
About half of the optimizations were things that I would have figured out on my own; the other half were definitely "wow" moments.
The whole thing was done in a couple hours, with just a few back-and-forths. Sans AI, it would have taken a week, with nowhere near the same gain. I'm impressed.
"Figure out how to make this process fast" is really a perfect activity for LLMs. And the prompt doesn't really have to be much more sophisticated than that.
do you have some samples? It would be interesting to learn what it might be.
JMH as the framework to write microbenchmarks. It takes care of dealing with JIT warmup, etc. It's the standard way to write rigorous Java microbenchmarks.
async-profiler (https://github.com/async-profiler/async-profiler) for profiling. Java has a problem where many profilers are based on safepoints, which are biased toward particular program points. async-profiler is not biased in this way.
Java Flight Recorder for memory allocation data.
One thing I've observed in all of this is that it's really useful to have expertise in the programming language and ecosystem you're writing in, otherwise it's all Greek to you and you can't really guide the agent to do the right thing. I have opinions about e.g. profilers and I can point the agent to one that I think is more accurate than other options.
> 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.
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.
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).
A story.
I have a friend, who is - like me - interested in the CRDT / collaborative editing space. He asked ChatGPT to write him a CRDT. Then he grabbed every good CRDT implementation, and asked chatgpt to benchmark and optimise his CRDT, using tricks and techniques from existing hand-optimised CRDTs. He got massive performance gains by doing this - which is really interesting! I think it helped that he had a clear objective function, and chatgpt could look at other projects for ideas on how to optimise.
He proudly boasted that his resulting code outperformed my diamond-types library. I asked him if he was comparing against the native implementation, or the -Oz webassembly build, running in a wasm vm. It was the latter. When he tested it properly, his CRDT was - and is - significantly slower than diamond types. As far as I know, chatgpt still hasn't been able to catch up. I tried myself using fable. Even with reference to my source code, Fable still doesn't understand what I did in diamond types and why. (... Maybe I should document what I did!)
I think his technique itself is solid though. I tried it myself. I asked fable to write a custom binary serialization format & parser. Then optimise. Then optimise, with explicit reference to existing libraries. Optimising with reference to other code made a huge additional difference. It is now nearly as fast as those libraries. (But still not faster than them.)
My takeaway is this: I think LLMs are exceptionally good at reading and understanding code. If you guide them to do so, they're good at profiling and benchmarking. But it seems like they're not very good at coming up with novel optimisations. If you have an obviously slow program (for example, some slop claude wrote), you can often get big speedups by asking it to benchmark and optimise. But if you have a complex, already well optimised codebase, like the zig compiler, claude doesn't seem very good at figuring out novel ways to improve things on its own.
This is good news for the 95% of slow software out there. But bad news for the 5% of us who write fast code already, but want our code to go even faster.
Of course that doesn't mean they have a human level mental model and associated novel ideas. Brute force can be effective but remains entirely unsatisfying from an academic perspective.
Reasons this doesn't follow: (1) Benchmarks never match real world use, and many optimizations the improve benchmarks degrade cases that aren't measured (think about how CPU cache behavior can be surprising) (2) In software performance optimization, frequently there is significant noise, from many sources. This makes it difficult to guarantee that a measured change is actually an improvement.
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.
The app and service are measurably and subjectively faster. Because I chose to have the LLM focus on solving those problems. It obviously can. It described the issues in big-O.
It is a priority problem, as it always has been, not a knowledge or skill problem, like it always has been.
The author is one of the most knowledgeable people about performance there is
> The other day, I saw a viral tweet saying [...]
I've already posted this elsewhere, but here it is again: https://news.ycombinator.com/item?id=49226923
A vibe-coded OS that runs on an 8088 with 256KB of RAM.
As proof, I'm can literally feel the web getting slower and I bet many others feel this as well.
"It's not the tool, it's how you use it..."
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'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?
Maybe hugged but feels really sluggish to me for it is.
Should note the server is on USW and I don't have edge servers for it at the moment.
I’ve also worked on projects where the people in charge added 1mb client-side mapping libraries to render a static map and ignored my push back. Those website were slow
If only we had a sufficiently smart™ compiler, it could do the inkling, dead code elimination, and WPO across the application. (Oh we do have that, as long as you don’t write in JavaScript…)
You can't exhaustively write down all the possible ways for software to execute, especially since many programs run forever (e.g. servers, GUIs etc)
So when you say in your spec "when the user clicks here it shows this stuff" there is the tacit expectation that this will always happen and isn't dependent on the entire execution path up to this point. You also wouldn't expect a server to just finish execution after processing a request because you forgot to write "finally, cede control back to the main loop" at the end.
These assumptions are the framework. Almost everything you read is likely written in a framework, unless you limit yourself to non-technical writing for younger readers.
You could try to formalise the framework in your specs. But you'll then end up copy and pasting these paragraphs every time you want another server program. These context frameworks will probably get names, just like today.
Or you could skip that entirely and pretend you're not using a framework, but you are. It's just that the most has already learned tons of frameworks. What worries me here is stagnation. There's no way for the model to learn new frameworks. But this might be a short term effect. Maybe software in the next few years will look quite odd to those in the future as we keep writing it in the language of frameworks we already know. Maybe they'll look back at these relics and ask "what is a view, and why did the model understand that?"
Maybe if this philosophy / approach has a catchy name it might be more widely adopted and we all can have better more performant web and apps.
I somehow managed to avoid the entire SPA scene. I feel so vindicated because I am absolutely zooming with my tried and true Vanilla JS these days. I have tried React, Vue, Angular, and ever just plain TS, and I hate them all.
Whether it can apply it directly from the codebase, I’m unsure and depends on many factors.
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
So going on a tangent: an additional mechanism you have that becomes feasible with LLM assistance today is proving your code correct.
Off-topic, but Dan, in the name of all that is holy, throw a `max-width: 40em;` on your blog!
A crude example is how, when building a large forum project years ago, I had a checklist I ran on every new http route: authentication, authorization, validation, etc. just because it's trivial to forget one of them. Yet now the LLM can come up with a lintable/verifiable way to ensure every route has the whole kit by construction.
Almost every way I feel like I can provide unique value to the automated AI workflow (aside from deciding what to build at all, and taste) feels like it can be automated by better markdown.
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.
- 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.
If your boss doesn't care about your software being slow he's incompetent.
https://services.google.com/fh/files/blogs/google_delayexp.p...
https://business.google.com/ca-en/think/marketing-strategies...
https://medium.com/ft-product-technology/a-faster-ft-com-10e...
https://www.pingdom.com/blog/page-load-time-really-affect-bo...
It’s often been hard for me to make coworkers care as well which is even more frustrating.
Unless your job really prioritizes performance and builds in benchmarking people often focus on finishing a feature as fast as possible and ignore performance (and accessibility, bugs, UI polish, etc.)
It obviously depends a lot on what you do, but often that doesn't matter.
Do you not add sleep to your programs?
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
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.
Not sure how either of those things are conducive to performance
I haven’t seen as big of an impact on the “good” side. People with attention to detail and craft can use it with great results but they’re not pumping things out at the speed of the slip slingers.
https://www.dgtlgrove.com/p/near-the-zero-point
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.
Not even close to being true. Prior to the advent of LLMs writing good SIMD was hard. Writing good SIMD for arbitrary tasks was _extra_ hard. Having the entire application be written with SIMD in mind was nigh impossible, from simple string parsing to data pipelining. Having arbitrary OpenCL/CUDA offloading to GPUs was a monstrous task. And even the people who were experts in these domains didn't have the time to do it in an afternoon.
But now you can. You can literally instruct your agent to write SIMD accelerated code everywhere, or to optimize down to it. And it just _does_.
> The essence of the problem is that the LLM does exactly what you tell it.
This is correct. I implore people to try writing a SaaS with an LLM, but instead of going the classic agentic project style of "design me an app", tell it to use C++ or Rust, use extensive SIMD intrinsics and inline assembly wherever possible. Just off those two instructions the difference in code quality is staggering.
LLMs can now write perfect code in low-level languages, that is frankly _safer_ and _exponentially_ faster than implementations in high-level languages.
When will we start using LLMs to write my web backend directly in UEFI and assembler? (Although uefi is an OS, so maybe more fair to exit the boot services)
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.
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.
Fun story, I was writing some 3D graphics animations for a website, and the only dependency I allowed was three.js. It ran well, but the site was loading slightly too slow so I told the LLM to optimize. It essentially hit a hard wall and told me something along the lines of "I can't optimize further, three.js is the bottleneck due to blablabla, but you don't need it. If you want I can rewrite it with pure WebGL". I said sure and load times were cut by like 90% and framerate went up too. Staggering.
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.
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.
I get that LLMs would make it faster to write distinct copies for different operating systems and maintain them both but thats still more costly than a single system.
Sorry if I’m misunderstanding the goal of Electron but it still seems cheaper and easier (although admittedly worse than multiple native apps)
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.
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.
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.
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.
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 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.
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.
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"
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.
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?
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
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.
Most of these things are just true as of today.
> You protect your job by learning how to use new tools as the technology advances.
Sure and the more you learn the more you see how hyped they were and reality untangle
> Engineers don't ask a tool to write code.
And what they ask? They create loops or graphs? These tools ultimately vomit code anyways
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.
> one-shot secure, performant code.
I call it reverse skill issue; it feels secure and performant because you can't verify properly, it feels right but it's actually broken in many nuanced ways. You can measure performance and produce a broken measurement as well. It's not as simple as you make it
And the list will be all really good issues. Fully automated. The only limitation being tokens and time.
Now do this as part of your normal, automated development cycle.
Software is basically solved. We're just figuring out the ideal harness and token thift to automate high quality.
Can you give a concrete example of that being the case? I’d love to see the prompt and harness. And understand the scale of problem you’re talking about solving with a one-shot approach.
How long will it take to write the right spec? How will you know ahead of time that the spec is correct?
Which agentic guardrails do you mean? How can they be set up?
-
I’d say the job of software engineering is still firmly being able to stand by the work you present and being reasonably confident that it’s correct according to yours and others’ understanding of the problem you’re attempting to solve.
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.
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 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
And they weren’t before AI?
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?
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”.
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.
The people are to blame. You get what you vote for.
Both the traffic engineer and the author of this blogpost are well-qualified enough in their fields of expertise to be careful about the claims that they make with regards to speed and efficiency.
A big issue is how those claims are interpreted by non-technical people, especially in leadership. Would hate for my CEO to stumble upon this blog post and believe, based on the title and a brief skimming, that his engineers just aren’t using AI correctly and that’s why the website still takes a few seconds to load its content.
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.
As you imply, some of them are not because spending time on optimization seems relatively expensive compared to value. But some of them are.
Maybe the author should be a bit more careful about what titles they give their blog posts, lest they be misinterpreted by mere mortals such as myself.
Imagine traffic not getting any better after adding 1000 lanes in a medium sized town… not just to one area but to every single damn road.
Yet we’ve done this with RAM, CPU, and storage…
At the end of the day its a mindset.
Understanding.
Simplify, then add lightness.
[1] hn favorite word
And Munger's Law never cares if you hate its consequences.
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.
Big tech funds startups (through obfuscated legal and financial means) and that funding goes straight back into big tech cloud hosting and SaaS services.
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.
problem solved
But you need a really solid workflow, solid benchmarks which run quickly, and a lot of tokens -- plus a rigorous profiling workflow.
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.
Also, perhaps you should learn how to make use of the user stylesheet feature of your browser, or ask an AI to tell you how...
> 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
I think he might subscribe to the philosophy of everyone should style websites however they like and not be prescribed by the author.
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.
> 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.