I get this same feeling when I see people taking photos for social media. I see the number of photos people take and I think of how sad it is that they are ruining their own experience for a photo that they might not ever see again.
Even the purported reason for these photos existing is sad, that they want to be able remember or relive the experience. Just get new experiences? That idea is much more uplifting to me.
Caveat, this obviously doesn't include once in a lifetime experiences that in my opinion it's justified to take photos of like marriage or things involving milestones of children etc.
The argument is that doing it all on a single thread will result in high cpu utilization and that is what makes the power usage spike and the pc feel hot. Thats it.
A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code.
> If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
Put up the code and prove it. We already know exactly how fast golang is in comparison to nodejs on basic numeric computations, it's roughly 40 to 50% faster.
Drawing to the terminal / rendering / whatever, this is all arguing semantics and very uninteresting and not insightful.
> they need a high powered game engine rendering loop
Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop.
> It needs to stream text to stdout
These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui.
If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization.
It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.
It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
The fundamental problem with all Js based apps is how they are very single threaded.
With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu.
Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto.
But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.
Hardware wearing out is not common at the individual component level. It only becomes common when you are running a large number of servers, those individual small probabilities add up.
There's another approach of responding to hard problems that I've used to great success: making the problem easier.
This approach only works when the problem isn't actually the problem. Meaning you are trying to solve a problem A with solution X but implementing solution X turns out to be difficult and becomes a problem in itself.
I used to get bogged down on making solution X work but solution X is not the actual problem I'm trying to solve. Problem A is.
So try easier to implement solution Y instead of solution X and bang problem solved.
Anthropic's willingness to completely change how claude code works is one of the stated reasons why the Pi coding agent exists. When people are dedicating significant time to building workflows on your product, consistency is very important.
One of the hard issues was supporting full text search locally and in the cloud. Also it's not that the entire app needed to be written twice but that parts of it needed it needed to be written twice.
> We considered completely rebuilding the application from the ground up, or even splitting it into separate applications for online and offline use
This is actually non-trivial. There's an app I was working on where I wanted to have a local first mode that allowed people to use the app for free without an account and there was also a cloud hosted version that allowed for team collaboration, etc.
For this kind of thing to work chunks of the app essentially need to be written twice. So, not fun.
I used to row and even the tiniest of waves could make it annoying. You'd slide to the front of your seat and try to insert your oar and catch air instead of water. Then if you overcompensated by trying to insert your oar farther in you'd catch a crab (having the oar ripped out of your control). This is on a lake with tiny waves.
Rowing across an entire ocean is absolutely amazing.
> but ultimately the only reliable way I've seen to close the gap is hire disciplined people who care about, and thoughtfully consider, what they build.
You were able to turn around a codebase that was growing its bug count exponentially by changing an entire company's hiring practices?
I really don't believe in the "just don't be stupid" or "don't hire stupid people" approach to things. If it works, it only works at a small scale and once things become urgent enough, things fall apart.
> The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.
I was on a platform team and I had a constant backlog of bugs (introduced by others) that I was working on and the two most impactful things for preventing bugs were Typescript and Cypress (playwright-like testing before playwright).
I've dealt with many shitty code bases and the only way that worked for removing bugs was automation. It didn't matter how many bodies you threw at the problem.
> Then why are you saying you have so many annoying bugs in the Zig code? What happened to the test suite being sufficient to catch everything?
You can't use tests for trying to catch use after frees and other memory bugs for the same reason you can't use unit tests as a replacement for type checking, the combinatorial explosion of possible inputs into functions makes unit testing types across an entire project impossible.
Anyway, Jared donated $60k a year to this project and tried to resolve this in the most diplomatic way possible and still got personally attacked. The lesson from this article is don't donate to the Zig project because if you migrate away from it they will try to ruin your reputation.
This is just another example of the bitter lesson. In a year a model will come out that will make none of these model specific optimizations you made matter.
> I understand the arguments for a margin collapse, but I don't see any historical analogues. It seems that enterprises will pay top dollar for service guarantees, integration, and someone they can sue.
Intelligence has diminishing returns, the analogues are with humans. It's a waste to hire Albert Einstein for $X million to operate the cash register in a gas station.
Artificial super intelligence will not have many customers.
Personal site: https://vmg.dev Twitter: https://x.com/vmg__0