Lol, I could kind of understand (not really support) his use of AI. While I doubt it’s something you can do for long without starting to make compromises, people who were a really good programmers before will probably use it responsibly for a while, until their skills inevitably erode and (more importantly) their willpower slowly runs out.
But this argument made me loose all my respect for him. It’s so utterly stupid. I hate it when i have to check my assembly code line by line, because it’s not guaranteed that the compiler will compile the same code I’ve written deterministically, and basically just randomizes what it outputs. Or when my editor does not save what I typed, and instead decides based on a random language statistics what to actually save, so I have to double-check my text word-by-word every time.
Oh, wait. No, because the tools are deterministic, and that doesn’t happen. But of course, adding randomness into your workflow, where you have to focus and review everything line-by-line, is the same as using deterministic tools, lol.
His point is that an LLM is just another tool for increasing productivity, the same as a compiler or IDE. The quality of the code is the only metric that should be judged.
Assuming you didn’t know what tools were used to write the code that you are reviewing, how would reviewing it be any different? You would still ask the human author questions about intent if that were not clear. The quality of their responses may or may not be impacted by their use of LLMs, but that is up for you to reason about as the reviewer, and it’s perfectly fine to tell someone they are being a jackass for only sending slop to you.
Except they’re not? Very few tools are deterministic. Only Mathematics is, and that’s only a small subset of tools.
You’re free to argue that non-deterministic tools lack value, but that’s clearly false: OCR only exists because of lossy training machine learning algorithms. Or, going even more basic, Monte Carlo simulations are by far the most efficient method of testing entire categories of problems that are intractable deterministically.
LLMs can be shitty, as a business practice, due to their unpredictability, but (hopefully obviously) that depends on how it’s used.
The point is a tool is something you wield. Your skill is needed for and improved by the use of a tool. An LLM is an automation. You don’t wield it, you give directives. Your skill is unnecessary for its use and is left untrained. The worst part is that, unlike a good, deterministic automation (like cruise control), where you understand the limitations and can take over to avoid them, you can’t do that with LLMs. The best you can do is carefully review the slop output.
I’d argue that Monte Carlo is a bad example here, and is an example of a deterministic tool.
You use a tool to create an outcome, you’re looking for an answer or a solution that you can trust.
If you want to examine behavior of a system that has input variables across some known range, you could brute force it, try every single possible combination and wait a millennia. Or you use a monte carlo strategy, let randomness enter the simulation to build out a basic characterization. You want more detail? More confidence? Increase the number of runs. I can trust that if I increase the number of runs I gain higher fidelity, if the tool/strategy was non deterministic I couldn’t do that
You do that inherently when you are writing the code. Every line you write has already had that focus, because you had to come up with it.
That you should also not trust every line of the compiled assembly after you wrote the code, and check it lime by line, is an extremely stupid argument.
Of course, you should get someone else, with a fresh/unbiased opinion to review your code too, but just the act of figuring out every line you write is in some sense a rewiev, that there is at least a plan or reason why it was written.
AI just randomly generates code without thought or reason, and you have to check everything. Unlike assembly generated from code.
That you should also not trust every line of the compiled assembly after you wrote the code, and check it lime by line, is an extremely stupid argument.
I guess it’s good that no one is making that argument then.
that is the argument linus is making… he is comparing a deterministic tool (a compiler that outputs the same assembly every time) to a non-deterministic tool and saying that they are the same type of tool. that require the same level of review, when they do not.
he is comparing a deterministic tool with a non-deterministic tool
Yes, but that’s not the argument Mikina was stating. Linus was never advocating for reading assembly line by line. Linus was using that as a satirical example, not suggesting anyone should actually do that.
Not parent commenter, but no, not to the same degree.
The level of trust I have in a source greatly changes how I review it. If I know that I’m reviewing code from a competent developer, I’m going to see a for loop and look for why is this here, how does it play into the larger objective and if I’m happy with it, I move on. But if I don’t trust the developer as much, I’m looking at far more like what data type is being used in the indexing, what’s the break condition, can go off the rails into random memory.
Competent developers make mistakes too. I think it’s worth at least skimming every line in a PR. Things like indexing out of bounds should probably be handled by testing or using a memory safe language.
I don’t think code review is the place where you should be trying to catch bugs in the minutia of the code. You should be assessing readability/maintainability, architectural decisions, risk, and testing strategy. That does involve reading all of the code, even if only by skimming.
I guess I don’t really count skimming as reading haha
When looking for readability, maintainability, etc what I mainly look for are design patterns. If you’re using the same boilerplate and layout I’m going to start skipping over sections
I also mainly work on high performance embedded systems that are difficult/nearly impossible to unit test and I dont always have line coverage metrics. A lot more verification by inspection in my corner of the world
There’s a couple big reasons, sometimes you only have to deal with one or two, other times you’re hit with all of them.
The data source for the algorithms often comes from arbitrary memory addresses that live outside the context of the C, C++, or Rust runtime. If I want to read CPU core temp I send magic numbers to one address to configure ADC channel conversion, another magic number somewhere else to do the conversion, wait a few dozen microseconds, then read a third new address that I squint one eye, spin around 10 times, and do a handstand and I’ll get a number that looks like temperature.
If I’m running on the microcontroller, I’m essentially in production environment and I can’t control what the data is. If I recompile for a different system (say x86 Linux) then I’m almost certainly going to segfault. I could abstract out the reading of the data, but then on my tiny 8MHz microcontroller that has to run it’s main loop at 1000Hz, I only have a few thousand clock cycles to get everything done, calling functions, pushing/popping the stack takes a lot of time.
Adding to the pile-on most microcontrollers have <1MB of RAM, many in the tens of kilobytes range so I don’t have much of a stack to work with and I need to keep even the number of instructions down.
Even if you do all the abstractions, you then have extra logic you have to write to simulate what is happening and subtle behaviors that are timing dependant. It frequently is extremely difficult to do that as the documentation rarely fully describes everything, so you can lull yourself into a false sense of security that you’ve tested the code and it’s correct, but then you get stuck on a register value that never changes and a watchdog timer comes along and resets the hardware on you.
And that’s not the getting into the runtime or build environments, flashing procedures, limited flash cycles, and a million other business constraints that technically you can do it, but at that point your dev team has all taken the month off to go play Half Life 3
That definitely increases the challenge of writing tests or trusting that they are faithfully representing your production environment.
I could abstract out the reading of the data
I was going to suggest this, and it sounds like that ends up being expensive. It seems like you need some kind of test harness that’s able to emulate your specific hardware while still allowing for testing hooks that don’t impede the tight clock scheduling.
If unit tests are being done, some kind of emulator is usually what gets used and the scope of testing is significantly limited.
The more common approach is to abandon unit tests all together and go for board functional tests where as many of the external interfaces are controlled and put through representative loads. The complexity of the software is rarely that high so we can be pretty confident that we’re covering everything we need to care about anyways.
“Deterministic” compilers and reproducible builds are actually fairly difficult problems. (Yes I know technically the compiler is deterministic, but AI is also technically deterministic since you can set the seed).
It’s not just about being deterministic. A compiler crucially follows clearly defined formal rules on what is a correct output given some input, which the programmer can fully rely on.
Most of the time, today. Mid 90s I was constantly checking compiler output for bugs, and finding them. Early 90s the compiler bugs were finding me, particularly in Borland Turbo C++. I turned off the linker optimizer in 1992 and couldn’t turn it back on until 2008 without getting difficult to identify bugs.
There is a clear line between deterministic code and what comes out of an LLM. One of the bigger problems there is that LLMs have a rather large “context window” they operate from, and human operators don’t readily “grok” how the content of that context window enhances and degrades the desirability of the outputs you get.
I almost exclusively use LLMs to generate, review and test deterministic code, then use that code for “the real tasks” with zero LLM involvement. The output of LLMs is still unpredictable, but once they’ve “said” something valuable, recognizing and using that value is a deterministic activity.
Indeed, my code has never been more rich in unit tests now that coding assistants make them so easy to add. If the coding assistant subsequently does something weird that changes program behaviour it knows immediately.
They check to make sure that the code continues producing the expected results. For example if I had some code that added up numbers, I might have a unit test that calls that function with the parameters “2” and “2” and checks to make sure the result is “4”. If something changes that makes it start returning something else then a flag is immediately raised.
Are these tests written by AI? Have you reviewed the tests? Do they cover all code paths and all the possible inputs and outputs? Do the tests have requirements cited (traceability)?
Unit tests have been around for a long time. They tended to be under-utilized in the past because they’re such a maintenance headache - changes / improvements in the production code that used to be a simple 5 minute thing can easily balloon to an hour or more of headache in necessary adjustments to perfectly good unit tests for “the old way” that happened to be impacted by the change.
Unit tests are a good way of keeping under-experienced programmers from accidentally breaking old things as they work on new things. They are VERY appropriate tools for LLM agent assisted development.
Indeed, my code has never been more rich in unit tests now that coding assistants make them so easy to add
Me as well. A year ago there was significant trouble with those unit tests not adding much value but that has improved a lot over the past several model updates. The unit tests aren’t 100% as good as they could or even should be (neither are human generated unit tests that take 10x as long to add) - but in terms of time invested vs value derived, they’re excellent value for effort.
If the coding assistant subsequently does something weird that changes program behaviour it knows immediately.
people who were a really good programmers before will probably use it responsibly for a while, until their skills inevitably erode
Damn, dude, I had mad 6502 assembly skillz in 1985, I could even write it out by hand - pencil on paper, and those slowly eroded through use of compilers for higher level languages until my last assembly experience in 1996, today… I’d be learning everyhing specific to assembly code from scratch. I guess I’m just useless now.
the people I respect and call intelligent are not the ones that shy away from using new and interesting tools.
Gotta agree there. We had two clear camps of programmers before LLM agents came along, and the camp I least enjoyed reviewing the code of before (and now) of is the camp that resisted adoption of new interesting tools the most loudly.
I think there is no equivalency between compilers and other tools, and LLMs. As the comment states, they are just the statistical prediction of what would come next. Compilers may sometimes give unexpected outcomes, but they are working to a defined set of rules and there is potential to see how they actually came to that outcome and address it.
Added to this is the prevalence of people thinking that LLMs can allow them to do anything, whether or not they understand it, it’s even sold like that. In my own organisation I have an operations manager thinking he can make pages for our Intranet - where does it store the data? How is access controlled? So many basic questions that an actual programmer would know to think of. Sure you can just keep asking people if they can fly a plane and maybe one will do well enough that they get you all the way there, till it comes to landing and it’s too late - maybe better to just ask a pilot to do it.
Our software engineers use it really well, they can read what it’s outputting to understand if it’s wrong, they know how to prompt it to avoid issues, they use it for snippets and fixes and that it won’t just write a whole program. However, it’s benefit to us (and the world) is nowhere near worth the monetary and environmental cost. The investors pouring in money are hoping they can be the company that people become reliant on, so they can survive the bubble and their ultimate goal of replacing real people.
Added to this is the prevalence of people thinking that LLMs can allow them to do anything, whether or not they understand it
1971, Willy Wonka and the Chocolate Factory depicted a computer which could (but was refusing to for comedic effect) predict the location of the remaining golden tickets. There were, and probably still are, a shocking number of people who believe that was a realistic scene.
I have an operations manager thinking he can make pages for our Intranet - where does it store the data? How is access controlled? So many basic questions that an actual programmer would know to think of.
Option 1: hold his hand and educate him on what he lacks
Option 2: let him flounder and make fun of his mistakes (the making fun part should be done anonymously if you value your job)
Option 3: he’s bright enough to ask the important questions to you or the LLM and get reasonable answers
Option 3 has a very realistic chance of working, if 1) you have documentation for how you do these things today - even informal documentation, anything the LLM can read and extract the relevant patterns from, 2) the LLM must have access to that documentation, and 3) your manager needs the patience and perseverence to work the discovery process until it’s viable and sustainable.
Odds are, your operations manager is going to fall short on the patience and perseverence dimensions and offload the boring parts to you, after all why did he become a manager in the first place?
maybe better to just ask a pilot to do it.
Yeah, except you can’t make nightly backups of the plane’s passenger manifest. If you’re not making nightly backups, you’re already in catchup territory LLM or no.
it’s benefit to us (and the world) is nowhere near worth the monetary and environmental cost.
I suggest doing a little research into what exactly the monetary and environmental cost of YOUR usage is. People engaged in low-value usages (too many to even begin to imagine, Rule 34 needs expansion to start to cover them) are burning a lot of un-necessary tokens.
What I have read, consistently from various sources, is that my $20/month Claude code subscription burns $11 to 12 in electricity to serve my responses. My house burns over $13 in electricity per day in the summer, mostly for the air conditioning.
Lol, I could kind of understand (not really support) his use of AI. While I doubt it’s something you can do for long without starting to make compromises, people who were a really good programmers before will probably use it responsibly for a while, until their skills inevitably erode and (more importantly) their willpower slowly runs out.
But this argument made me loose all my respect for him. It’s so utterly stupid. I hate it when i have to check my assembly code line by line, because it’s not guaranteed that the compiler will compile the same code I’ve written deterministically, and basically just randomizes what it outputs. Or when my editor does not save what I typed, and instead decides based on a random language statistics what to actually save, so I have to double-check my text word-by-word every time.
Oh, wait. No, because the tools are deterministic, and that doesn’t happen. But of course, adding randomness into your workflow, where you have to focus and review everything line-by-line, is the same as using deterministic tools, lol.
His point is that an LLM is just another tool for increasing productivity, the same as a compiler or IDE. The quality of the code is the only metric that should be judged.
Reviewing AI code is harder than reviewing human code. I’ll judge humans on what they do, and LLMs on what they are.
Assuming you didn’t know what tools were used to write the code that you are reviewing, how would reviewing it be any different? You would still ask the human author questions about intent if that were not clear. The quality of their responses may or may not be impacted by their use of LLMs, but that is up for you to reason about as the reviewer, and it’s perfectly fine to tell someone they are being a jackass for only sending slop to you.
And the person you replied to is saying it is not just another tool because tools are deterministic.
Except they’re not? Very few tools are deterministic. Only Mathematics is, and that’s only a small subset of tools.
You’re free to argue that non-deterministic tools lack value, but that’s clearly false: OCR only exists because of lossy training machine learning algorithms. Or, going even more basic, Monte Carlo simulations are by far the most efficient method of testing entire categories of problems that are intractable deterministically.
LLMs can be shitty, as a business practice, due to their unpredictability, but (hopefully obviously) that depends on how it’s used.
The point is a tool is something you wield. Your skill is needed for and improved by the use of a tool. An LLM is an automation. You don’t wield it, you give directives. Your skill is unnecessary for its use and is left untrained. The worst part is that, unlike a good, deterministic automation (like cruise control), where you understand the limitations and can take over to avoid them, you can’t do that with LLMs. The best you can do is carefully review the slop output.
tell us of a software tool that isn’t deterministic.
I’d argue that Monte Carlo is a bad example here, and is an example of a deterministic tool.
You use a tool to create an outcome, you’re looking for an answer or a solution that you can trust.
If you want to examine behavior of a system that has input variables across some known range, you could brute force it, try every single possible combination and wait a millennia. Or you use a monte carlo strategy, let randomness enter the simulation to build out a basic characterization. You want more detail? More confidence? Increase the number of runs. I can trust that if I increase the number of runs I gain higher fidelity, if the tool/strategy was non deterministic I couldn’t do that
Do you not think all code deserves this level of focus?
You do that inherently when you are writing the code. Every line you write has already had that focus, because you had to come up with it.
That you should also not trust every line of the compiled assembly after you wrote the code, and check it lime by line, is an extremely stupid argument.
Of course, you should get someone else, with a fresh/unbiased opinion to review your code too, but just the act of figuring out every line you write is in some sense a rewiev, that there is at least a plan or reason why it was written.
AI just randomly generates code without thought or reason, and you have to check everything. Unlike assembly generated from code.
I guess it’s good that no one is making that argument then.
that is the argument linus is making… he is comparing a deterministic tool (a compiler that outputs the same assembly every time) to a non-deterministic tool and saying that they are the same type of tool. that require the same level of review, when they do not.
Yes, but that’s not the argument Mikina was stating. Linus was never advocating for reading assembly line by line. Linus was using that as a satirical example, not suggesting anyone should actually do that.
Not parent commenter, but no, not to the same degree.
The level of trust I have in a source greatly changes how I review it. If I know that I’m reviewing code from a competent developer, I’m going to see a for loop and look for why is this here, how does it play into the larger objective and if I’m happy with it, I move on. But if I don’t trust the developer as much, I’m looking at far more like what data type is being used in the indexing, what’s the break condition, can go off the rails into random memory.
Competent developers make mistakes too. I think it’s worth at least skimming every line in a PR. Things like indexing out of bounds should probably be handled by testing or using a memory safe language.
I don’t think code review is the place where you should be trying to catch bugs in the minutia of the code. You should be assessing readability/maintainability, architectural decisions, risk, and testing strategy. That does involve reading all of the code, even if only by skimming.
I guess I don’t really count skimming as reading haha
When looking for readability, maintainability, etc what I mainly look for are design patterns. If you’re using the same boilerplate and layout I’m going to start skipping over sections
I also mainly work on high performance embedded systems that are difficult/nearly impossible to unit test and I dont always have line coverage metrics. A lot more verification by inspection in my corner of the world
Sort of a change in topic, but I’m curious why that would be so difficult to test.
There’s a couple big reasons, sometimes you only have to deal with one or two, other times you’re hit with all of them.
The data source for the algorithms often comes from arbitrary memory addresses that live outside the context of the C, C++, or Rust runtime. If I want to read CPU core temp I send magic numbers to one address to configure ADC channel conversion, another magic number somewhere else to do the conversion, wait a few dozen microseconds, then read a third new address that I squint one eye, spin around 10 times, and do a handstand and I’ll get a number that looks like temperature.
If I’m running on the microcontroller, I’m essentially in production environment and I can’t control what the data is. If I recompile for a different system (say x86 Linux) then I’m almost certainly going to segfault. I could abstract out the reading of the data, but then on my tiny 8MHz microcontroller that has to run it’s main loop at 1000Hz, I only have a few thousand clock cycles to get everything done, calling functions, pushing/popping the stack takes a lot of time.
Adding to the pile-on most microcontrollers have <1MB of RAM, many in the tens of kilobytes range so I don’t have much of a stack to work with and I need to keep even the number of instructions down.
Even if you do all the abstractions, you then have extra logic you have to write to simulate what is happening and subtle behaviors that are timing dependant. It frequently is extremely difficult to do that as the documentation rarely fully describes everything, so you can lull yourself into a false sense of security that you’ve tested the code and it’s correct, but then you get stuck on a register value that never changes and a watchdog timer comes along and resets the hardware on you.
And that’s not the getting into the runtime or build environments, flashing procedures, limited flash cycles, and a million other business constraints that technically you can do it, but at that point your dev team has all taken the month off to go play Half Life 3
That definitely increases the challenge of writing tests or trusting that they are faithfully representing your production environment.
I was going to suggest this, and it sounds like that ends up being expensive. It seems like you need some kind of test harness that’s able to emulate your specific hardware while still allowing for testing hooks that don’t impede the tight clock scheduling.
If unit tests are being done, some kind of emulator is usually what gets used and the scope of testing is significantly limited.
The more common approach is to abandon unit tests all together and go for board functional tests where as many of the external interfaces are controlled and put through representative loads. The complexity of the software is rarely that high so we can be pretty confident that we’re covering everything we need to care about anyways.
“Deterministic” compilers and reproducible builds are actually fairly difficult problems. (Yes I know technically the compiler is deterministic, but AI is also technically deterministic since you can set the seed).
It’s not just about being deterministic. A compiler crucially follows clearly defined formal rules on what is a correct output given some input, which the programmer can fully rely on.
Most of the time, today. Mid 90s I was constantly checking compiler output for bugs, and finding them. Early 90s the compiler bugs were finding me, particularly in Borland Turbo C++. I turned off the linker optimizer in 1992 and couldn’t turn it back on until 2008 without getting difficult to identify bugs.
There is a clear line between deterministic code and what comes out of an LLM. One of the bigger problems there is that LLMs have a rather large “context window” they operate from, and human operators don’t readily “grok” how the content of that context window enhances and degrades the desirability of the outputs you get.
I almost exclusively use LLMs to generate, review and test deterministic code, then use that code for “the real tasks” with zero LLM involvement. The output of LLMs is still unpredictable, but once they’ve “said” something valuable, recognizing and using that value is a deterministic activity.
You can add deterministic testing to AI output though?
Indeed, my code has never been more rich in unit tests now that coding assistants make them so easy to add. If the coding assistant subsequently does something weird that changes program behaviour it knows immediately.
What do the tests do?
They check to make sure that the code continues producing the expected results. For example if I had some code that added up numbers, I might have a unit test that calls that function with the parameters “2” and “2” and checks to make sure the result is “4”. If something changes that makes it start returning something else then a flag is immediately raised.
Are these tests written by AI? Have you reviewed the tests? Do they cover all code paths and all the possible inputs and outputs? Do the tests have requirements cited (traceability)?
Unit tests have been around for a long time. They tended to be under-utilized in the past because they’re such a maintenance headache - changes / improvements in the production code that used to be a simple 5 minute thing can easily balloon to an hour or more of headache in necessary adjustments to perfectly good unit tests for “the old way” that happened to be impacted by the change.
Unit tests are a good way of keeping under-experienced programmers from accidentally breaking old things as they work on new things. They are VERY appropriate tools for LLM agent assisted development.
Absolutely not. In a world where hallucinating machines are writing code, humans should be writing the tests at a bare minimum.
AI writing code to pass tests written by AI will get people killed.
Boeing managed to kill plenty of people without a single bit of help from AI / LLMs in their MAX 10 software.
Used properly, LLMs could have articulated why their approach would lead to multiple crashes.
Used improperly, any tool is dangerous, from a chainsaw to a plastic spoon, the potential for injuries and deaths are unlimited.
Me as well. A year ago there was significant trouble with those unit tests not adding much value but that has improved a lot over the past several model updates. The unit tests aren’t 100% as good as they could or even should be (neither are human generated unit tests that take 10x as long to add) - but in terms of time invested vs value derived, they’re excellent value for effort.
About 90% of the time for me now, in Opus 5.5.
Damn, dude, I had mad 6502 assembly skillz in 1985, I could even write it out by hand - pencil on paper, and those slowly eroded through use of compilers for higher level languages until my last assembly experience in 1996, today… I’d be learning everyhing specific to assembly code from scratch. I guess I’m just useless now.
Gotta agree there. We had two clear camps of programmers before LLM agents came along, and the camp I least enjoyed reviewing the code of before (and now) of is the camp that resisted adoption of new interesting tools the most loudly.
I think there is no equivalency between compilers and other tools, and LLMs. As the comment states, they are just the statistical prediction of what would come next. Compilers may sometimes give unexpected outcomes, but they are working to a defined set of rules and there is potential to see how they actually came to that outcome and address it.
Added to this is the prevalence of people thinking that LLMs can allow them to do anything, whether or not they understand it, it’s even sold like that. In my own organisation I have an operations manager thinking he can make pages for our Intranet - where does it store the data? How is access controlled? So many basic questions that an actual programmer would know to think of. Sure you can just keep asking people if they can fly a plane and maybe one will do well enough that they get you all the way there, till it comes to landing and it’s too late - maybe better to just ask a pilot to do it.
Our software engineers use it really well, they can read what it’s outputting to understand if it’s wrong, they know how to prompt it to avoid issues, they use it for snippets and fixes and that it won’t just write a whole program. However, it’s benefit to us (and the world) is nowhere near worth the monetary and environmental cost. The investors pouring in money are hoping they can be the company that people become reliant on, so they can survive the bubble and their ultimate goal of replacing real people.
1971, Willy Wonka and the Chocolate Factory depicted a computer which could (but was refusing to for comedic effect) predict the location of the remaining golden tickets. There were, and probably still are, a shocking number of people who believe that was a realistic scene.
Option 1: hold his hand and educate him on what he lacks
Option 2: let him flounder and make fun of his mistakes (the making fun part should be done anonymously if you value your job)
Option 3: he’s bright enough to ask the important questions to you or the LLM and get reasonable answers
Option 3 has a very realistic chance of working, if 1) you have documentation for how you do these things today - even informal documentation, anything the LLM can read and extract the relevant patterns from, 2) the LLM must have access to that documentation, and 3) your manager needs the patience and perseverence to work the discovery process until it’s viable and sustainable.
Odds are, your operations manager is going to fall short on the patience and perseverence dimensions and offload the boring parts to you, after all why did he become a manager in the first place?
Yeah, except you can’t make nightly backups of the plane’s passenger manifest. If you’re not making nightly backups, you’re already in catchup territory LLM or no.
I suggest doing a little research into what exactly the monetary and environmental cost of YOUR usage is. People engaged in low-value usages (too many to even begin to imagine, Rule 34 needs expansion to start to cover them) are burning a lot of un-necessary tokens.
What I have read, consistently from various sources, is that my $20/month Claude code subscription burns $11 to 12 in electricity to serve my responses. My house burns over $13 in electricity per day in the summer, mostly for the air conditioning.