Dude, you can go around it as much as you want. The amount of compute per input/output token is going down sharply. If you want to deny that, be my guest.
Then of course, cheaper inference means that you can do more of it, and more complex inference as well, but this does not contradict the fact that models are (and will continue to become) more and more efficient wrt the value that they produce.
The amount of power used by the tools is going up, evidenced by the huge number of data centres being built.
The context here is assisting programming. Thatâs moved from just using the tools as a glorified search engine to answering basic questions to an agentic coding assistant. Are you really telling me that power use has gone down during that process?
xAI bypassed the grid to power data centers in 2024, when the company built data centers in Memphis to house its Colossus and Colossus 2 supercomputers. The facilities are powered by a private collection of dozens of temporary, mobile gas turbines despite a ruling by the Environmental Protection Agency that they were being used illegally.
Meta, in addition to building private power stations in the short term, is pursuing a long-term strategy to build nuclear power plants, which are scheduled to come online in the early 2030s. The company committed to help build new reactors and to purchase electricity from older reactors. These deals are expected to supply more than 6 gigawatts.
Alphabet, Amazon, and Microsoft have entered into smaller agreements to obtain nuclear energy. Alphabet is working to reopen a disused nuclear plant in Iowa, Amazon invested in the reactor developer X-Energy, and Microsoft agreed to buy 10.5 gigawatts of new renewable energy capacity between 2026 and 2030 for an estimated $17 billion.
Why it matters: The rise of private power for data centers reflects a bottleneck as AI companies plan to increase their capacity faster than current energy suppliers can meet. It signals a shift in the ways AI infrastructure, power plants, and public utilities interact, with implications that go well beyond tech companies.
Demand for AI caused electricity prices to rise at more than double the rate of inflation in 2025, according to Goldman Sachs. Private power plants could help stabilize that impact by reducing the burden on the grid. However, an expert quoted by The Washington Post worries that a boom in private energy generation will drive up electricity prices by boosting demand for generation equipment and expertise.
More gas-fired power plants mean more greenhouse gases in the atmosphere, which are driving climate change. Although big AI companies work hard to use renewable energy and offset greenhouse-gas emissions, the pace of building makes fossil fuels expedient. While public announcements of private-power projects have emphasized renewable, nuclear, or hydrogen power, âthe equipment actually being installed in 2025 and 2026 is almost entirely gas-fired,â Cleanview writes.
Weâre thinking: Until recently, the cloud-computing leaders have leaned heavily on renewable energy sources such as wind and solar power, sometimes with an assist from batteries. Their move toward gas-fired power plants is an unfortunate reversal of the effort to remain carbon-neutral.
(Source: deeplearning.ai newsletter)
156 GW * 24 h/ day * 365 days / year = 1367 TWh / year. To put that in perspective:
Bitcoin mining operations worldwide consume an estimated 175+ terawatt-hours (TWh) of electricity annually, [âŚ] equivalent to the electricity usage of countries like Poland or Argentina, representing approximately 0.5% of global electricity consumption
(How Much Electricity Does Bitcoin Mining Use? 2025 Analysis)
According to Wikipedia, the total annual electric energy consumption of the United States is 4,272.91 TWh, so the newly added capacity would be about a third of that; itâs between the consumption of Russia (1,162 TWh) and India (1957 TWh).
Iâm still cautious about these things. Chiefly, as most are some kind of big tech subscription, itâs another cost that can increase later. But as an ardent adherent [1] to âdoing things the hard wayâ I wonder about cognitive atrophy if you rely on them too much and conversely burn out if they allow you to do too much at once. MIT has broached the atrophy problem a bit here:
For me itâs one thing if itâs a work task I donât much care about and am just trying to use to feed myself. I gave up on work having much meaning years ago, I donât have much agency there so I just kind of want it over as fast as I can get through it. But for my side projects that I want to use to grow myself and my knowledge? Iâm a bit leery of using these things and getting some kind of brain rot. The few times Iâve used one itâs like a sugar rush. You get a high from âoh wow, look at this neat thing I didâ followed by a realization that you didnât learn as much as you would have if you had done it by hand.
Work has also more or less mandated LLM use of late so I want them out of my personal life even more.
I also live in area where a few AI data center companies have began poking around so I have thoughts about that. Not good ones, but thatâs another discussion.
Everyone can do what they want and you guys wouldnât be the first one to tell me my cranium needs pulled out of my rectum. I just donât think thereâs a such thing as a free lunch and thereâs some Faustian Bargains at play here.
Iâm a coding wizard but not in the way where what I do appears magical to people who donât understand it but Iâve reduced my job into a series of arcane incantations I donât really understand and if I get it slightly wrong it blows up in my face.
Not quite. From my experience, LLM a) by its nature, a probability model, tends to follow the context and good context will push the LLM to better code and b) still has the tendency to write bad code, e.g. excessive checks and c) can hardly do a macro design decision.
Is a false thing. LLM still goes wrong, sometimes in a pretty subtle way as the training target is to have output âlooks rightâ which still holds a subtle difference with right. LLM can present bugs or unsound designs/concepts in a very believable way, and when it goes rouge, fixing LLM output is very expensive.
Aligns with my own experience. Brooks categorize SE complexities into accidental and essential ones [1]. Given LLM is already pretty good at trivial things, I find it quite handy at eliminating accidental complexities. But it still feels unsound to me, because abstraction holds meaning and the correct way to do this is to design good abstraction instead of applying smart copy-paste using LLM.
[1] F. P. Brooks, âNo Silver Bullet Essence and Accidents of Software Engineering,â Computer, vol. 20, no. 4, pp. 10â19, Apr. 1987, doi: 10.1109/MC.1987.1663532.
Whoops I just accidental dug up an old thread. Maybe some of the points were already stated by other people. Anyway here are my two cents
@yikerman You seem to have skipped over the last paragraph of the OP:
The whole post is about the difference between using LLMs to generate slop and using LLMs as productivity tools by skilled developers who understand their strenghts and limitations.
You have quoted a book on software engineering from 39 years ago⌠and although a rather number principles stayed the same⌠in software engineering⌠1987 is like a millennium ago!
I think one of the biggest things is in computer science that it is a very young field. And although much of the underlying mathematics is very well understood, the process itself and its application is far from.
Compare it with building bridges or roads⌠we have a 1000s years of history in what works and what doesnât, not only in the physics of it, but also in practice. The Romans did not have the level of physics understanding we have today but nevertheless they build roads and bridges effectively.
But writing software⌠so I think itâs too early to call if LLMs are a good tool or not.
In my experience it is most of the time good and sometimes bad. The only difference is that when I tell the LLM to apply the SOLID principles, use clean code methodology, make the files not longer than a 100-150 lines of code, the LLM actually takes that into account⌠in contrast to most of the junior software engineers that I worked with.
Because that is how I treat my LLM: as a junior software engineer that does know the syntax and has read the manual.
Tools are good if they are used properly, they are not good or bad in a vacuum.
A hammer is very good for driving nails, itâs very bad for slicing cheese. Different LLMs have already proven themselves to be very valuable tools for different tasks, and they will keep getting better at more and more tasks. If anybody still has doubts about the ability of LLMs to be used productively, either they have not used the right LLM for the task that they were trying to complete, or they do not have enough experience working with one.
Anecdotally, as I am writing this, an LLM is generating code, orchestrating running programs and inspecting outputs with minimal supervision from my side, doing in one afternoon what, until 2 months ago, would have required a few days of my undivided attention. Pretty damn good tool for the job, if you ask me.
I observe the same thing. But I also see another side of this. A couple weeks ago I was talking with a number of young people (early 20s) and they had and interesting remark: you can judge if AI is doing a good job: but we donât have the knowledge like you to verify that.
So while for me it very easy to judge: o AI did what I wanted, that may not that easy for the next generation of software developers.
I donât believe juniors will be able to learn without doing the hard work themselves.
If people with experience are subjecting themselves to vibe programming, I donât really have much future that those with less experience will slow down and take time to learn it.
Maybe theyâll learn something else. People are already talking about âdark factoriesâ (dark, as you donât need the lights to be on if you have an automated assembly pipeline â thatâs silly, of course, robots need to see car parts they assemble, but it sounds âcoolâ or âfrighteningâ, depending on how you look at it, so it has great media impact). In such a âfactoryâ, you pass in specs, the LLMs do the coding, the review and the testing in a loop, and you get a finished product (or an almost finished one, for manual testing if needed).
It is interesting that the same LLM may catch bugs it introduced, when reviewing its own code (just like a human may, when taking a second look).
A future developer may learn how to create good specifications. They may become a kind of architect + business analyst, instead of âcoderâ / âprogrammerâ.
(Thereâs a certain amount of hype with this âdark factoryâ image, but I donât think itâs completely unrealistic.)
It seems to me like that would create blackboxes in which nobody but an LLM would understand whatâs inside, since âprogrammersâ would stop knowing how to read and write code. Even if the AI follows the spec to a T, you wonât end up with a faithful product because at the end of the day a sufficiently detailed spec is gonna be some form of code, and if itâs gonna be code you might as well know how to read and write it. Even disregarding the autonomy problems in which the only thing which would understand that code is a product sold by trillion dollar companies, there are still many other problems, the more you look at it the more they arise.
I struggle to think of a current field with such problems, even civil engineers and architects ultimately understand what is going on in a construction project, they understand the properties of materials, thermodynamics, how everything fits together, etc, and if they need deeper understanding into a specific topic, they hire a human or get a textbook. A spec producing programmer would understand nothing of the underlying solution.
If the future of computing are these blackboxes, created by âspecsâ, running our infrastructure and services, then I will rather give up computing all together and become a goose farmer or something. That view of the future is extremely bleak. It is already a problem that many products are becoming those irreparable blackboxes, such as cars which even 20-25 years ago could be mostly repaired by anyone and even custom parts could even be made easily.
From a managerâs perspective, the software produced by the team is a black box already. My managers trust my team, that given their business requirements, we will deliver a software that does what they want. (Iâm playing the devilâs advocate here. I actually like coding, turning ideas into something that works, pulling something out of thin air.)
We, ourselves, take certain infrastructure for granted, treating them as black boxes: we donât write operating systems, compilers, and all libraries ourselves.