DEV Community: Anish Basnet

[Boost]

Anish Basnet — Tue, 07 Jul 2026 16:06:48 +0000

Anish Basnet

Jul 6

Big Tech is spending $725 billion on AI this year. Who actually pays for it?

#discuss #ai #machinelearning #business

4 min read

Bubble or not? The money loop, the token revolt, and why the AI demand is still real

Anish Basnet — Mon, 06 Jul 2026 19:56:44 +0000

In part one I laid out the two numbers that make this whole AI buildout feel like a dare. Big Tech spending around $725 billion in a single year, and JP Morgan's math saying the industry needs $650 billion in fresh revenue every year, forever, just to earn a 10 percent return. If you have not read that one, start there, because it sets up the stakes.

This is the half where I stop describing the bet and start poking at whether it holds.

The money that keeps going in circles

Here is where the bubble comparison gets sharp.

A cluster of the biggest names in AI are investing in each other in ways that make demand look larger than it might actually be. Nvidia has committed money to OpenAI. OpenAI commits enormous sums to cloud providers like Oracle. Those providers turn around and buy Nvidia chips to build the capacity. Amazon invests in Anthropic, which runs heavily on Amazon's own cloud. By 2026, analysts had counted more than $800 billion of these interlocking arrangements.

Supporters call it a virtuous circle that locks in scarce supply. That is a fair reading. If you know demand is coming, tying up chips and capacity early is smart.

Critics, including the investment firm GMO, see something else. It looks a lot like the vendor financing that inflated the internet bubble, where companies bought each other's services to make growth look organic right up until it did not. The deciding question is easy to say and hard to measure: how much of the revenue comes from real customers outside the circle?

When one hundred billion dollars can show up as a chipmaker's revenue, a lab's funding, and a cloud's backlog all at once, the headline numbers stop meaning what they appear to mean. And when a single stalled negotiation between Nvidia and OpenAI rattled three of the largest companies in the world back in February, it was a reminder of how tightly wound this all is.

Enterprises noticed the bill

Now the part that I think matters more than people realize.

Through the first half of 2026, the companies actually buying AI at scale started saying out loud that it costs too much.

The unit of AI is the token, the small chunk of text a model reads and writes. Agentic tools that plan and write code and click around burn through tokens frighteningly fast. As vendors move toward metered pricing, where you pay for exactly what you use, those bills started to sting.

Then DeepSeek showed up. The Chinese lab's V4 Flash model runs at about $0.14 per million input tokens and $0.28 per million output tokens. In May it made a roughly 75 percent price cut to its heavier V4 Pro model permanent. At comparable context lengths, that lands somewhere between 20 and 100 times cheaper than the flagship Western models.

The moment it got real was June, when reports surfaced that Microsoft was weighing a self hosted version of DeepSeek's V4 for parts of its Copilot lineup, specifically because token costs were pressuring the economics. When the company most deeply tied to OpenAI is quietly pricing a Chinese alternative, the cost problem is not hypothetical anymore.

But the demand is not imaginary

It would be easy to stack all this up and call it a bubble. That would also be wrong, or at least incomplete, because the counterevidence is strong.

Cloud revenue is genuinely surging. Google's cloud business grew more than 60 percent year over year in early 2026. Nvidia's data center revenue keeps setting records on real orders. And on the software side, the money is arriving faster than almost anyone guessed.

Anthropic, the company behind Claude, passed OpenAI on annualized run rate in April 2026, reaching about $30 billion, up from roughly $9 billion at the end of 2025. Around 80 percent of that comes from enterprises and developers, not free consumers. The company projected its first operating profit as early as the second quarter. More than a thousand companies reportedly spend over a million dollars each, per year, on it.

That is not the profile of hype. That is real workflows getting replaced by software that pays for itself.

Meanwhile OpenAI is the counterweight. It booked about $13 billion in revenue in 2025 and hit roughly a $25 billion run rate by February 2026, which is impressive, and yet it is projected to lose around $14 billion this year, does not expect positive free cash flow until near the end of the decade, and has committed to enormous infrastructure obligations. It filed confidentially for an IPO in June. A business losing more than a dollar for every dollar it earns is asking public markets to fund years more of exactly that.

Both things are true at the same time. The technology works, the revenue is real and growing fast, and the spending may still be running ahead of what near term returns can justify. Reality does not owe anyone a clean verdict.

So, where do I land?

The most honest answer is the one JP Morgan buried in the same report with the eye watering numbers. Even if everything works, they wrote, there will be spectacular winners and probably equally spectacular losers, given the sheer amount of capital involved and the winner takes all nature of parts of this market.

That is not a bubble call. It is something more useful. It says the real question is not whether AI is real. It is who survives the race to build it.

History rhymes here. The railroads were transformative and also bankrupted a generation of the companies that laid the track. The fiber optic boom of the late 1990s wired the world for the internet age and wiped out the firms that overbuilt it. The internet itself changed everything, exactly as promised, several years after the market that bet on it crashed. Transformative technology and a brutal financial reckoning are not opposites. They tend to show up together.

So here is what I would actually watch, as a developer and not a trader:

Free cash flow at the hyperscalers, as capex eats into it.
Debt loads and credit spreads at the companies leaning hardest on borrowed money.
Whether enterprise revenue keeps compounding once the novelty wears off and the token bills come due.
How much of the demand comes from genuine outside customers, rather than the same dollars circling a small group of firms.

The tech is real. The revenue is real. Whether they justify $725 billion in a single year is the trillion dollar dare, and nobody actually knows the answer yet, not JP Morgan, not the CEOs, not the people writing confident takes in either direction.

What we will find out, probably sooner than the timelines suggest, is not whether AI matters. It is which of the giants placing this bet are still standing when the bill comes.

If you jumped straight here, go back and read part one for the two numbers this whole thing rests on. It is the setup that makes this half land.

Big Tech is spending $725 billion on AI this year. Who actually pays for it?

Anish Basnet — Mon, 06 Jul 2026 19:54:57 +0000

There is a number going around tech right now that I genuinely cannot fit in my head.

Amazon, Microsoft, Google and Meta plan to spend somewhere around $725 billion on capital expenditure in 2026. Most of that is data centers, chips, and the power to run them. That figure is up roughly 77 percent from about $410 billion the year before, based on earnings figures compiled by the Financial Times.

Read that again. It is not a plan for the decade. It is one year.

I want to walk through where this money is going and who is supposed to pay it back, because once you sit with the second number in this story, the whole thing starts to feel less like a strategy and more like a dare.

A bet the size of a small economy

The easy assumption is that spending like this cools off. It has not. If anything it is speeding up.

JP Morgan's base case has more than $5 trillion flowing into data centers and AI infrastructure worldwide over about five years. Annual funding needs climb from around $700 billion in 2026 toward roughly $1.4 trillion by 2030. Goldman Sachs has spent the whole year revising its own numbers upward and now models the four largest US hyperscalers spending on the order of $5.3 trillion between fiscal 2025 and 2030, up from an earlier $4.5 trillion.

Here is the part that actually changes the story for me.

For most of the last twenty years, the whole appeal of big software companies was that they made money without building much. Code scales for almost nothing. You write it once and ship it to a billion people. That was the magic.

Now the model has flipped. These same companies are pouring hundreds of billions into concrete, transformers, cooling systems, and Nvidia chips. Amazon's free cash flow is projected to go negative this year because of it. When Meta raised its capex guidance in the spring, its stock dropped more than 9 percent in a single day. That was the first real moment where you could see investors flinch.

So the spending is not in doubt. What happens next is.

The bill nobody wants to hold

In late 2025, JP Morgan's strategists ran the math on the entire buildout. Their conclusion is the second number that makes the first one scary.

To earn a modest 10 percent return on all this money going in, the industry would need about $650 billion of new revenue every single year. Not once. On repeat, forever.

The bank put it in terms you can actually feel. That is roughly 58 basis points of global GDP. It is the equivalent of every current iPhone user paying an extra $35 a month, or every Netflix subscriber handing over $180 a month, in perpetuity.

Now, before anyone panics about their streaming bill, that is not the prediction. JP Morgan is clear that consumers will not foot this directly. The iPhone and Netflix lines are there to show you the scale, not to warn you that Netflix is about to cost two hundred bucks.

The real theory is that businesses pay. Enterprises fold AI into healthcare, finance, manufacturing, and customer service, their workers and systems get productive enough to justify the cost, and that productivity becomes revenue that flows back to the people who built the infrastructure.

That is the plan. It is a reasonable plan. It might even work.

But there is a hole in it, and JP Morgan admits it themselves.

The gap they cannot close

Even after counting everything on the table today, hyperscaler cash flow, high grade bonds, leveraged finance, and data center securitizations, the bank still finds a $1.4 trillion funding gap.

That gap has to be filled by private credit, and possibly by government support if AI ends up folded into national defense spending.

Sit with that for a second. The plan does not fund itself. The people modeling the plan know the plan does not fund itself. The bet is that the money will show up, that enterprises will turn AI into enough profit fast enough, and that private lenders will keep the taps open while everyone waits.

That is a lot of faith stacked on top of a lot of concrete.

So is it a bubble?

If you stop reading here, the honest answer is that it looks shaky. Free cash flow going negative, a trillion dollar hole, a return that depends entirely on a productivity story that has not fully arrived yet.

But stopping here would be lazy, and it would give you the wrong picture.

Because there is a whole other side to this. The revenue is genuinely showing up in places, faster than most people predicted. Enterprises are also starting to revolt over how much AI costs to actually run, and a cheap Chinese model is quietly reshaping the math. And there is a strange loop of money flowing between a small handful of companies that makes all this demand look bigger than it might really be.

That is where this gets interesting, and honestly where I land on the whole bubble question.

I broke that out into part two: Bubble or not? The money loop, the token revolt, and why the demand is still real. If part one convinced you this is doomed, part two is going to complicate that. And if it convinced you everything is fine, part two will complicate that too.

Go read it. That is the half where I actually make up my mind.

I've relied on AI coding tools for a year. Here's the honest version.

Anish Basnet — Mon, 06 Jul 2026 17:29:00 +0000

Junior to junior. No hype, no doom. Just what a year of actually using these tools taught me.

Where they're great

Boilerplate I've written a hundred times. Syntax in a language I barely know. The "wait, what's that method called again" moments. First drafts of tests. And the best one for me: taking a terrifying stack trace and explaining it back in plain English so I can stop panicking and start reading.

For that stuff they save real time, and I'd fight to keep them.

Where they quietly cost me

This one took a while to notice. I started accepting code that worked without understanding why it worked. It compiled, the tests passed, I moved on.

Then a few weeks later a bug showed up in that same feature, and I sat there staring at code I technically wrote but couldn't actually reason about. It was never really mine. I'd shipped a stranger's solution with my name on the commit.

That's the trap. On day one it doesn't feel like a problem. It feels like speed.

The rule I use now

I don't paste anything I can't explain out loud.

The AI can write the first draft. I have to earn the second one. If I can't walk through a block of code, line by line, in my own words, it doesn't go in. Sometimes that means I retype it slower. Sometimes it means I keep asking the AI to explain it until it clicks. Either way, the thinking stays with me.

The part people get wrong

Companies are paying real money for these tools, somewhere in the $100 to $200 a month per developer range once you stack the premium seats. They're not a fad, and I'm not here to tell you to quit them.

But for a junior, the danger was never that the AI writes bad code. The danger is that it lets you skip the exact thinking that turns you into an engineer. The struggling, the "why does this break," the slow build of a mental model in your head. That is the job. That's the part that makes you good.

AI is great at handing you answers. It's bad at making you understand them. That gap is still yours to close.

So I'm curious how other juniors are handling this. Where are you drawing the line for yourself?

ArtificialIntelligence #SoftwareDevelopment #Coding #JuniorDeveloper

A Banking API Is Not Just CRUD: What Building a Money-Movement Ledger Taught Me

Anish Basnet — Sun, 28 Jun 2026 21:00:49 +0000

I thought a banking API would be mostly CRUD.

Make an account. Read a balance. Update a row. I had that working in a weekend with Spring Boot and Postgres, and for a moment I figured the project was basically done.

Then I tried to actually move money from one account to another, and the easy part was over.

This post is about the gap between storing data and moving money safely. That gap is the whole reason I built a personal project called Ledger-Core, a money-movement REST API I made to learn backend correctness properly. It's not production software and I'm not going to pretend it is. But I wanted it to behave the way a real system has to, because that's where the interesting problems showed up.

I'm a junior developer. I didn't know most of this when I started. Here are the problems that taught me, roughly in the order they punched me in the face.

Problem 1: Money and floating point don't mix

The first thing I got wrong was the type I used for money.

If you've never hit this, open a REPL in almost any language and try 0.1 + 0.2. You get 0.30000000000000004.

That's not a bug. Floating point numbers (float, double) are just binary approximations, and a lot of normal decimal values can't be stored exactly. The errors are tiny. But they pile up, and "tiny error on someone's balance" is not a sentence you want to be explaining later.

In Java the fix is BigDecimal with a fixed scale. I store money as NUMERIC(19,2) in Postgres and BigDecimal with scale 2 in Java, the same way everywhere.

@Column(name = "balance", nullable = false, precision = 19, scale = 2)
private BigDecimal balance;

Two things bit me here.

First, you compare with compareTo, not equals. new BigDecimal("1.0").equals(new BigDecimal("1.00")) is false, because equals cares about scale. compareTo returns 0. That one cost me a confusing afternoon staring at a failing test before I understood why.

Second, pick your scale once and pin it. I call .setScale(2) after every add and subtract, so a balance can't quietly drift to some other scale behind my back.

Small stuff. But this was the first moment Ledger-Core stopped feeling like a CRUD app and started feeling like a system with rules.

Problem 2: Two requests at once can make money disappear

This one humbled me, because every test I'd written was green.

Picture an account with $100 in it, and two withdrawals of $80 landing at the exact same moment.

With no concurrency control, both transactions read the balance as 100. Both ask "is 100 at least 80?" and both say yes. Both subtract and write back 20. One whole withdrawal just vanished, the account is now wrong, and $80 left the system that nothing can account for.

This is the classic lost update problem. The reason my tests never caught it is a little embarrassing: I was only ever sending one request at a time. Green tests told me nothing about what happens under pressure, because I'd never written the test that mattered.

The fix I went with is optimistic locking, and in JPA it's almost too easy to turn on. You add a version column to the entity:

@Version
private Long version;

Now every update checks the version. When Hibernate writes, it basically runs UPDATE account SET balance = ?, version = version + 1 WHERE id = ? AND version = ?, where that last version is the one the transaction first read. If another transaction already changed the row, this update matches zero rows, and Hibernate throws an optimistic lock exception. The stale write gets thrown out instead of silently winning.

What clicked for me is that there's no clever Java doing the detection. It's just SQL. An update with an old version matches nothing, and "zero rows updated" is the whole signal. The database does the work.

I picked optimistic over pessimistic locking (SELECT ... FOR UPDATE) on purpose. Optimistic assumes conflicts are rare and only costs you something when one actually happens, which fits a system that isn't getting hammered. Pessimistic holds a lock for the whole transaction, which is safer when one row is under constant fire but slows everything down. For this project, optimistic was the lighter choice.

Then I wrote the test I should've written from day one: ten withdrawals fired at the same instant at an account that can only cover a few of them, lined up with a latch so they genuinely race instead of going one by one. When I ran it, exactly one succeeded, the rest got rejected, and the balance never went negative. Watching that pass taught me more than any blog post about isolation levels ever did.

A green test is only as good as the cases it covers. Obvious when you write it down. Not obvious to me while I was happily watching my happy-path tests go green.

Problem 3: A retry can run the same transfer twice

Here's a sequence that looks harmless until you actually think about it.

A client sends a transfer. The server does the work. But the response gets lost on the way back, maybe a dropped connection or a timeout. The client never hears "success," so it does the reasonable thing and retries. Now the same transfer might run twice.

This part surprised me the most. On a network, a request arriving more than once is the normal case, not the weird edge case. You can't assume something happens exactly once, so the server has to be able to say "I've already done this one."

The pattern is an idempotency key. The client makes up a unique key and sends it as a header:

POST /api/transfers
Idempotency-Key: 9f1c0a3e-1b77-4f2a-9b1e-2c4d5e6f7a8b

First time I see that key, I do the transfer and save the result against it. Next time the same key shows up, I skip the work entirely and just hand back the saved result. Money moves once.

Two details I didn't get right the first time.

The first was the race. Two copies of a retry can land at almost the same instant, both check "seen this key before?", both see no, and both go ahead. I fixed it the same way as the lost update: let the database referee it. The key has a unique constraint, so when two identical requests race, one insert wins and the other blows up on the constraint. Since that insert lives in the same transaction as the money movement, the loser's whole transaction rolls back. The money never moves twice, and I never had to babysit any of it in Java.

The second detail was sneakier, and I'm a little proud I caught it. What if a client reuses the same key for a genuinely different request, same key but a different amount? If I just returned the saved result, I'd be reporting success for a transfer that never happened. So along with the key, I store a hash of the request itself. Same key plus same request means a real retry, so I replay the saved result. Same key plus a different request means something is off, so I reject it loudly instead of guessing. The key on its own isn't enough. The key plus a fingerprint of what it was for is what makes it safe.

Problem 4: A `balance` column can't tell you the truth

My first instinct was one balance column I could read and update. It's the obvious move, and it works right up until someone asks a question you can't answer: how did this balance get to this number?

A column has no memory. It holds today's value and nothing about how it got there. If a balance looks wrong, there's no trail to follow and nothing to audit.

So I moved Ledger-Core to an append-only, double-entry ledger, and it's the decision I'm most glad I made.

The idea is that money never just "moves." Every transfer is two entries, a debit on one account and a credit on another, that add up to zero. A $50 transfer from A to B writes a DEBIT of 50 against A and a CREDIT of 50 against B. Entries are append-only, so nothing ever gets updated or deleted. A correction is a brand new entry, never an edit.

This caused a problem I didn't see coming, and figuring it out is where I feel like I finally got double-entry. A transfer between two of my accounts balances on its own, one debit and one credit. But what about a deposit? Money shows up from outside, so the customer gets a credit, but where does the matching debit go? If there's no other side, the books don't balance and the whole idea falls apart.

The answer real ledgers use is a system settlement account. A deposit is really a transfer from the bank's settlement account to the customer. The customer is credited, the settlement account is debited, and the books stay balanced. That settlement account is allowed to go negative, because a negative there isn't a bug, it's the bank correctly tracking how much it owes its depositors in total. Modeling that was the moment double-entry stopped being a thing I'd read about and became a thing I understood.

To actually make the ledger untouchable, I dropped below the application. I added a Postgres trigger that rejects any UPDATE or DELETE on the ledger table. Inserts still work, so history can grow, but nothing can be changed or erased, not from a raw psql session, not even by me. Append-only stops being a promise I make and becomes a rule the database enforces on everyone, including its author.

The payoff is auditability. The ledger is the source of truth, and the balance is just a fast cached view of it that I keep in sync inside the same transaction. If the two ever disagree, the ledger wins, and I can rebuild any balance from scratch by replaying its entries.

Problem 5: How do you actually know the books are right?

Keeping a cached balance and a ledger in sync sounds fine until you ask the obvious next question. What if they drift apart anyway, because of a bug I haven't found yet?

So I built a reconciliation job. It's a scheduled task that walks every account, recomputes the real balance from the ledger, compares it to the stored balance, and records a "break" for any account where the two don't match. It doesn't quietly fix anything, because quietly fixing a mismatch would erase the evidence that something went wrong. It detects and it reports. That's what a real end-of-day reconciliation does.

And then it caught something real.

The first time I ran it against my own dev database, it flagged seventeen accounts whose stored balance didn't match their ledger. For a second I thought the job was broken. It wasn't. Those accounts were leftovers from early in the project, before the double-entry refactor, when my deposit code was still writing balances without full ledger entries. The job was correctly catching damage left behind by an older, buggier version of my own code.

That was the moment the whole project clicked for me. I'd built the thing that catches wrong numbers, and it caught my wrong numbers before I even went looking. A break doesn't tell you which number is right, only that two of them disagree, and working out which one to trust is its own little investigation. That's the real job reconciliation does, and I got to do it for real, on my own data.

What actually ties all of this together: invariants

Looking back, every one of these was the same problem in a different outfit.

CRUD is about storing data correctly. Moving money is about protecting invariants when things go wrong: when requests retry, when they land at the same instant, when a connection dies halfway through.

The invariants Ledger-Core protects are small and specific. A balance is always exact, no floating-point drift. The same transfer never applies twice. A withdrawal never reads a stale balance and overdraws. Every transfer's entries sum to zero, the ledger can never be altered, and a separate job keeps checking that the books still balance.

Once I started thinking in invariants instead of features, the design got easier, because every new feature now had to answer one thing: what could go wrong here, and what keeps this true?

Where I'm at, and what's next

I built Ledger-Core slowly, one guarantee at a time, and I wouldn't let myself move on from a piece until I had a test that actually proved the property held. The slow pace was the point. I didn't want to assemble a system I couldn't explain. I wanted to understand one.

There's stuff I've deliberately left for later, and knowing what you haven't done yet feels like part of the job too. The big one is auth. Right now the endpoints are open, which is fine for a demo I label as a demo, but a real money API has to know who you are and stop you from touching accounts that aren't yours. That's the next phase I'm building.

If you've worked on payment, ledger, or banking systems for real, I'd genuinely like to hear how you handle retries and concurrency in production, and anything I got subtly wrong above. I'm a junior dev learning this on purpose, and a correction from someone who's actually shipped it is worth more to me than any tutorial.

This is the kind of backend work I want to grow into. The kind where correctness isn't a nice-to-have. It's the whole product.

DEV Community: Anish Basnet

[Boost]

Big Tech is spending $725 billion on AI this year. Who actually pays for it?

Bubble or not? The money loop, the token revolt, and why the AI demand is still real

The money that keeps going in circles

Enterprises noticed the bill

But the demand is not imaginary

So, where do I land?

Big Tech is spending $725 billion on AI this year. Who actually pays for it?

A bet the size of a small economy

The bill nobody wants to hold

The gap they cannot close

So is it a bubble?

I've relied on AI coding tools for a year. Here's the honest version.

Where they're great

Where they quietly cost me

The rule I use now

The part people get wrong

ArtificialIntelligence #SoftwareDevelopment #Coding #JuniorDeveloper

A Banking API Is Not Just CRUD: What Building a Money-Movement Ledger Taught Me

Problem 1: Money and floating point don't mix

Problem 2: Two requests at once can make money disappear

Problem 3: A retry can run the same transfer twice

Problem 4: A balance column can't tell you the truth

Problem 5: How do you actually know the books are right?

What actually ties all of this together: invariants

Where I'm at, and what's next

Problem 4: A `balance` column can't tell you the truth