> Really the main issue [is] ... energy production
I know that's what the rhetoric focuses on, but is it the real issue? The people I know personally who are against "data centers" are really just against AI, period. "It takes jobs from artists, it's going to take my job, it's going to enrich a handful of oligarchs," etc.
I suspect that even if some magical breakthrough meant that AI usage could grow and grow without building a single new data center, these guys would still oppose AI.
And understandably so! "I'm worried that AI will take my job" is a reasonable worry, for many jobs! But I feel like "data centers" is, for many people, a pretext.
This is like a plot point in the old sci-fi movie Colossus: the Forbin Project.[0]
In the movie, America and the Soviet Union have both developed an AI. The two AIs are linked, and they rapidly shift from speaking human languages, to speaking in sequences of numbers that the onlooking humans can't understand.
Spoiler alert: this all goes horribly wrong for humanity.
```
/* 2026-06-01 Dear diary, today I increased GLOBAL_WINDOW_PADDING from 8 to 16 because the user (who hurt my feelings with his crude language!) said that the app felt too crowded. */
const GLOBAL_WINDOW_PADDING = 8;
```
You're absolutely right. I did not increase it to 16, and it's my fault that the seam—which was right there the entire time—was not flipped towards the bucket that drips into the ocean—want me to correct this before we move onto the real story?
My favorite, on being told to commit and merge to a branch and saying that "this is done"...
"You're right, I'm sorry. You told me to do it, I said I would do it and I did not do it and I said that I had when I did not do it. Would you like me to do it now?"
Me, thinking: that depends, Claude, will you actually do it this time?
and better is when it moves onto "want me to do this before doing x?" where x is some vaguely discussed idea/long term thing that was never greenlit but now all of a sudden it's the next step
> I figure that it's basically making notes for itself, when it has to revisit the same code in a fresh session.
That sounds like a great thing to do even if you are a human writing code for other humans. Most codebases out there are terrible for newcomers because of how little they explain why they are doing what they are doing, both in the code and in the often non-existent design notes.
In principle, I would agree, however, the types of comments Claude writes are sometimes absurd. It will leave a 25 line comment above a variable talking about how in a debug session, it turned out that this value was too low, so it was increased on the current date to account for whatever. It will also leave giant comments like, reference security review from 2026-05-21. Even when that document is not committed
It will also inject a tons of information that it shouldn't. I do a lot of data pipelines and comments will be like, "this line is because there's 943,048,032 events in the blah table and it forms a conjunctive set with the 43,390,042 rows of the bar table..." but doesn't include the context that was run against a dev instance.
And if I don't catch these and remove the bad information, subsequent passes will flag those comments and get stuck on the fact that numbers don't match and start digging into that "problem" instead of staying on topic.
these comments are not helpful and in fact hurt readability. i just delete them and would love to automatically do that honestly. cuz claude still drops long winded comments on every method even if i ask it not to
Post edit hook that reject edit based on comment density, mine is at 5% you will also need to heed deny file edit in automode as the rascal will try that to preserve prose
I agree it _sounds like a great thing to do_ but the comments Claude creates make me want to never read code again. They're so obtuse and often completely pointless.
as others have pointed out, the reality is not this. id go further and say almost all comments are evil.
Excuse me if I am harsh, read the damn code. If you do not understand the language, that is a skill issue. If the code is confusing, then the code is bad and no amount of comments will ever change that. Professional engineering isnt an intro to databases class.
I am excusing language conventions which may have comments as part of its idiosyncratic nature.
"If the code is confusing, then the code is bad and no amount of comments will ever change that."
I've worked on a lot of terrible legacy code in my career and I'm very thankful for the comments that others have left. This is becoming less necessary now that LLMs can explain a project, but comments have historically been a godsend in bad code.
No, really: comments should be telling you what the code shouldn’t or physically can’t. Code is for execution and the exact details of what and how; it has no business knowing why or why not and that’s where comments are required.
If you are only encoding intent through "self-documenting code", and not with comments, then you are purposefully not using all the tools at your disposal to encode meaning as efficiently as possible.
Imagine a complicated section of application logic. You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x, or you could write a short comment explaining the intent in natural language. What's more effective? I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.
Not to mention complex numerical optimization code that mixes closed-form approximations and something like Newton.
Without guides as to why a particular hairy expression is a good idea as a first estimate, the code is pretty much unreadable. (E.g. is it setting derivatives to zero, using a polynomial approximation, or something else?)
To put it another way, comments are for irreducible complexity ir external systems outside your control.
I work between systems and app dev. Systems have comments more often esp in shaders but my god informing me that a variable named isActive is for if something is…active, is useless noise. Same with the majority of comments that a type system already tells you. In my career, these have been ~90% of the comments I see. Since ai, all new code it is 100%.
Most of the replies examples are a sign of bad system/code but it is not always controllable. A legacy code comment of, the api requires strings for boolean values in the form “yes” and “no”. That is useful but it is also a code smell.
A concrete example, a vendor decided to define a proto with a flattened array of objects so there are some 1800 uniquely named fields on it. In many downstream consumers, this is a real performance issue besides being confusing. A comment may be good there. The thing is, this was still solvable if up at the root of where this vendor’s hardware logs
data remapped it
to something sane so every downstream system wouldnt need a comment explaining wtf is going on.
I see comments as when you want to explicitly answer why code smells right when a reader is smelling it.
> You could break it up into 5 separate functions that document their intent semantically, thus blowing up the LOC by 5x
I do this all the time and the "blowup" is not anywhere near that bad.
> or you could write a short comment explaining the intent in natural language.
You really can't. Or rather, you aren't going to convey the information that the new function signatures convey, shorter than the signatures themselves.
> What's more effective?
In my literal dozens of years of experience, the function refactoring. You also get the benefits of less deeply nested code, and more things the compiler can check automatically.
> I'd argue it's always going to be using all the tools at your disposal when and where it makes sense to use them, whether that is comments or self-documenting code.
Sure. Comments allow you, for example, to explain the external pressures and motivations for the semantics of those smaller functions.
Yeah, I am just providing one contrived example. The cost benefit analysis won't always be so obvious as that in reality. My point was that if you're not using a blend of both comments and code semantics to explain your code, then you're leaving explanatory power on the table. It's unlikely that you're explaining the code in the most efficient manner if you're not using all the explanatory power you have available.
The code tells you what the code does. It does not explain why it is doing that, and not something else. That is, among other things, what documentation does, and that includes comments.
IIUC, Bowling Alone pointed the finger at TV. If you looked at time-use surveys in the 50s, versus when Putnam was writing in the late 90s, it looked like TV watching had eaten much of the time that used to be spent doing IRL social activities.
TV was one factor, along with migration/ commuting, two-income households (and now divided households), and more generally that boomers were more individualistic, though he didn't explain why really.
Those , and other factors are more influential than facebook. If anything, facebook helped remote friendships stay connected ( better than phone, letters).
It's a Substack that reports good things happening around the world, divided into sections like "Conservation and Restoration," "Climate and Energy," "Medicine," etc. And they also give part of their profits directly to projects in those categories.
(I'm not affiliated with them, I'm just a subscriber.)
Their pitch is like, "we take your COBOL code, and all the real-world data you can give us. Then we model your COBOL program as a graph, where each node has inputs and outputs. Then we use AI to port each node, making sure that it has the same (input => output) mapping for all the test data you gave us."
This is the secret sauce. You'll be responsible for any defects if you didn't prepare your test data to act like a massive unit test. Wonder how hard is to prepare the ideal test data vs writing the unit tests themselves in COBOL and verifying their translation. I guess if you throw enough data at it, the effort is minimal while the coverage becomes good enough to fix any bugs manually.
Maybe so, but our weakness is that we depend on new debt to finance our government spending. If investors stopped buying that debt, the US government would have to make sudden, dramatic spending cuts.
And that's not a problem that's solvable with military might! "Investors around the world are declining to buy US government bonds" can't be bombed the way an oil refinery can be.
It always gives me an ominous feeling to see these headlines. It's like we're walking out further and further on a frozen lake. "Hey, it's OK, the ice hasn't cracked yet! Let's keep going!"
Total debt / GDP is the wrong metric for that. There's no limit to the serviceability of debt in a currency you print.
It makes more sense to conceptualise it as the total size of a giant savings account run by the government.
We are walking further out on the ice but that is measured more in other ways - with harder metrics like inflation, access to cheap energy, resources, industrial density and capabilities and access to technology - not this headline number.
Even if we just ignore inflation and other issues, there's still a hard limit because governments don't literally just print money, but sells bonds at market rates. As confidence in the economic stability declines the interest rates the government is required to offer on those bonds trends upward. So right now even 10 year treasuries are selling with just under 5% interest. As a result we're now paying $1.4 trillion per year in interest alone, and that number is going up far faster than the economy is growing. This [1] graph looks quite disconcerting. And it's a vicious cycle. The less confidence there is in the stability of this game, the more the government will have to pay to sell that debt. And the more they have to pay, the more debt they end up needing.
>governments don't literally just print money, but sells bonds at market rates
no, sometimes they literally do exactly that.
google for quantitative easing. that's what it is and it's a tool that can always be used by monetarily sovereign countries to bring bond interest rates down by as much as they want.
That is a valid point, however if you look at Germany you will see that as soon as your money is worthless people will want payment in something else.
If a country ever decides to use your 'monetary sovereignty' they might as well just stop playing their debts as any holder of the debt will see that as the same thing. They're not getting their money back, or when they do they get it in a currency now worth a lot less. At this point you can say you're still solvent in the same way as you can say you did repay all your debts.
Search for the phrase "gold marks" in your link. This is the key. Gold denominated debts != paper denominated debts and Weimar debts were always gold denominated.
It might seem like a minor distinction but it's actually very important. Gold can't be printed, whereas currency can be, so insolvency when your debts are denominated in gold is very possible.
Argentina is also another example of a country that suffered hyperinflation because it had debts denominated in something it could not print (dollars).
Whereas Japan had even higher debt / GDP than Argentina and got deflation instead.
I understand your distinction, and I reiterate that this is a valid point.
However, it's a bit moot in my opinion. When the US owes me $100B and they pay that by 'creating' $100B through the central bank, in terms of value of the currency that's bad because there value of that payment dropped.
You can do this, it's what the quantitative easing policy did, but only in very limited amounts. If you were to do it because you were no longer solvent I would expect it to be the end of the trust and value of your currency. So in a sense it's not very different.
The reason Federal Reserve banks are independent in most/all countries is precisely to avoid this sort of scenario where the government just relies on their ability to print money to finance infinite deficit spending. Governments want to do this because it's politically beneficial in the short-run (e.g. before an election) but it's catastrophic in the longer term due to inflation, economic instability, and other consequent issues. And QE drives up inflation in a scenario where the US is already having relatively high rates and high inflation. QE in this scenario would be like throwing fuel on a fire.
Maybe you can argue that if the alternative was complete insolvency then the Fed would feel obligated to comply, but you find yourself in a scenario where you're choosing between immediate economic collapse and rapid economic collapse.
This idea is based on the fantasy idea of "it's fine because the US can just inflate away its currency to reduce its debts". This is also often used as an argument for why countries shouldn't join the Euro because they'd be giving up an important tool.
The reality is that purposefully inflating your currency to reduce your debt burden is going to upset your creditors just as much as if you just defaulted on your debts, but will have the added affect of crippling your economy with inflation. Look at how much Americans freaked out over a year or two of 6% yearly inflation. How do you think Americans would respond to 30% *monthly* inflation like in Argentina or Turkey?
It's not like lenders won't notice if the USA tried to print its way out of debt.
> It's not like lenders won't notice if the USA tried to print its way out of debt.
For historical context, this is exactly what happened when the US was on the brink of leaving the gold standard.
> From 1963 to 1966, France secretly implemented Operation Vide-Gousset to repatriate 3,313 tons of gold reserves from the Bank of England and the New York Federal Reserve. It took over 44 boat trips and 129 flights to export the gold back to the Banque de France. Since France converted its dollar holdings into gold, the French made out well when the dollar fell during the Bretton Woods period and lost 96% of its value against gold. France then withdrew from the London Gold Pool in 1966 after recovering its gold holdings to force the US to endure heavier losses.
To be fair, it wasn't 6%. The consumer basket gets manipulated in all sorts of ways, but in general it's just not an accurate representation of day to day impact. Food and housing went up much much higher than 6%.
Whatever the number is, we know for a fact that it was
1. Extremely painful to Americans, and became one of the main pillars of their election.
2. Nowhere near high enough to cause any reduction in the USA's debt burden.
I think modern Americans are way too soft to even imagine the sort of inflation that'd be required to erase their debts. Things have been too good and too stable for too long to understand what country-wide economic hardship would be like, and even if they somehow decided to choose that path, they'd panic quit it long before it was done long enough to have any effect.
1. Markets are aware of that and lend to China accordingly (the ones who are free to choose who to lend to).
2. Do you think Americans would tolerate having a government that purposefully suppresses their purchasing power through structurally low wages, and buying up foreign assets to supress the value of their own currency?
3. The part where China spends all their cash to buy US Treasuries to supress the value of their currency wouldn't really work as well for the USA when international trade is dollar denominated anyways, and the bulk of their GDP comes from domestic consumption.
4. The USA has a deficit. It'd need to borrow even more in order to finance the suppression of their currency, whereas China just redirects the money they earn from export surpluses.
they might be pissed off, but would lack standing to take land or something else instead. Ultimately you are fine, just without the ability to take on more debt. you get to keep your assets.
the scale of problem is much worse when Haiti was forced to pay France a debt for freeing itself of slavery. Having to produce physical goods and sell them is much harder than giving out paper or adjusting numbers
What you're describing is identical with simply defaulting on loans and say "we're not going to pay you back".
Inflating away your currency has the same effect with the added downside of destroying your economy simultaneously.
________
In fact, the only time I can really see the argument for wanting the ability to inflate away currency to escape debt is if the country is weak and in a precarious enough position that they are legitimately worried that actually formally defaulting would lead to an invasion.
This used to be true, but less so after the US started alienating the rest of the world with tariffs and other erratic behavior. The US military has also been revealed to be incapable of controlling the strait of Hormuz.
The quiet part you're not supposed to say out loud is the "if you don't use our currency to transact for energy and thereby let us tax it via inflation we'll regime change you" implication it comes with.
Except it's not a bank, it's a country with a few hundred million people that need to work and eat. Once the lenders have a problem, it would already be the end for Americans.
There are also games like that for trading-card stores, video arcades, and record stores.
(I'm probably going to buy the record store one, "Wax Heads." Being a music-genre nerd and recommending bands to people is a fantasy that I was born 10 years too late to do in real life.)
I know that's what the rhetoric focuses on, but is it the real issue? The people I know personally who are against "data centers" are really just against AI, period. "It takes jobs from artists, it's going to take my job, it's going to enrich a handful of oligarchs," etc.
I suspect that even if some magical breakthrough meant that AI usage could grow and grow without building a single new data center, these guys would still oppose AI.
And understandably so! "I'm worried that AI will take my job" is a reasonable worry, for many jobs! But I feel like "data centers" is, for many people, a pretext.
reply