The machine was confident. That was the problem.

Sun, 16 Aug 2026 20:13:14 +0200

I am rarely on LinkedIn, but because its timeline is full of things I never asked to see, it occasionally shows me a post so flabbergastingly stupid that it deserves to be archived.

The example that set me off this week was a post from a senior engineer with a LinkedIn profile full of leadership titles. He used Claude to help migrate side projects from DigitalOcean to Cloudflare, trusted the result, deployed it, and ended up with a $21,937.25 bill because the generated code kept rewriting the same data in a loop.

He presents this as an embarrassing accident and a cautionary tale about cloud billing. To me, much more interesting than the invoice itself, is the mindset that caused it.

Lately, I’ve had the feeling that a lot of apparently successful people seem to completely switch their brains off the moment an LLM enters the room.

The screenshot is not the scandal

Sure, the amount is absurd. Of course, the billing model is dumb. Usage-based cloud pricing is full of footguns and vendors should absolutely offer options and defaults that help you avoid costly mistakes (they won’t). But that is not what this will be about.

To me, it is simply laughable that there were people in the comments insisting that the provider simply had to reimburse him. No, they do not. I am not on the vendor’s side whatsoever, but “play stupid games, win stupid prizes” still applies.

If you ship unreviewed, high-risk generated code into production and let it hammer a paid system, you do not magically stop being responsible because the resulting failure was mediated through an LLM.

But even if Cloudflare’s billing UX is bad, IMO that is not the main scandal here.

The scandal is that a person claiming decades of engineering experience apparently did all of this.

Used an LLM to perform a migration touching production systems
Accepted generated code that wrote to a database on a timer
Failed to notice a loop repeatedly rewriting millions of rows
Failed to set cost guardrails
Failed to monitor the migration closely enough to catch runaway writes early
Only discovered the problem after the bill arrived

That is not “AI made a mistake.” That is engineering hara-kiri with an LLM as the weapon of choice.

The machine said it was fine

One phrase in the post says almost everything.

Claude assures me we’ve done it

There it is. The whole disease in one sentence.

Why on earth would anybody treat reassurance from an LLM as meaningful evidence?

Repeat after me!

LLMs do not know shit. They predict text.

They present utter nonsense with the same confidence they use for things that are entirely correct. They can explain broken code with the same smooth tone they use to explain correct code. They can “check their work” in the same sense that a student can grade their own exam with an answer sheet they also hallucinated.

This is also why all those dramatic stories about LLMs “going rogue” irk me so much. LLMs have no concept of truth. They do not know when they are right, they do not know when they are wrong, and they do not possess intent in any meaningful sense. They cannot betray you. They cannot deceive you. They can only generate plausible output that people, who definitely should know better, then choose to trust far too much.

I could imagine that the confidence with which LLMs produce plausible answers to almost any prompt is part of what makes them so appealing to venture capitalists. It feels a lot like the usual “trust me bro, it works” promises you get when somebody is pitching or hyping their next big startup idea.

I recently gave a presentation at work to about 30 people from our development department. My point was that even if this new tool seems powerful and absurdly confident, we still need to remain accountable for how we use it. We need to know when to say no, when to stop and think, when to slow down and when to make careful decisions.

I also used the image from Simon Willison’s blog post A computer can never be held accountable on my slides.

Experience clearly does not shield people against hype

What makes this story so fascinating to me is that it was not a junior engineer making a mistake. Juniors will often make mistakes. Everyone does. Over time, though, you learn from them and avoid at least some of them.

But this came from someone with a LinkedIn profile full of senior titles: CTO, director, VP, senior engineer, leadership, strategy, migrations, scale, operations… It reads as a profile constructed to signal judgement.

And yet the behaviour described in the post shows a complete collapse of judgement at a moment when human, deliberate judgement was direly needed.

I guess this is what bothers me most about the current LLM wave. It is not merely enabling beginners to make beginner mistakes faster. It is convincing experienced people that they can skip the slow parts of engineering.

Understanding a system
Validating assumptions
Testing failure modes
Constraining blast radius
Reading the fucking code
Watching production like a hawk during critical migrations

Those are not optional bureaucratic rituals. Those are the job.

Charity Majors makes a similar point in AI demands more engineering discipline. Not less. Using LLMs does not lower the bar for engineering rigour. It raises it.

The comments are more useful than the post

The comments under the post are full of people pointing out the obvious.

Don’t ship code you did not review
Put budget alerts and hard limits in place for SaaS subscriptions
Use credit cards with lower limits or virtual cards
Watch for loops, retries and timeouts
Do not let an LLM near production without guardrails
Above all, take responsibility for what you deploy

Exactly.

Several commenters also point out something important. Runaway usage billing existed long before “vibe coding”, and cloud footguns are old news.

But LLMs make this worse because they lower the friction to producing dangerous nonsense. They create code quickly, they explain it persuasively, and they flatter the user into thinking they are moving fast instead of cutting corners.

What “vibe coding” actually means in practice

People like to joke about vibe coding as if it merely means being casual or experimental. But this story is a much better definition.

Vibe coding is what happens when you replace verification with vibes.

It is what happens when people blindly accept plausible output in place of actual verification because they lack time or simply could not be bothered.

Then, when the obvious happens, people act shocked that the overhyped autocomplete did not behave like a cautious senior engineer.

Paternity leave is not a change-management strategy

The post also mentions that this happened during paternity leave.

Frankly, that explains a lot and excuses very little.

Sleep deprivation, stress and time pressure are exactly the conditions under which you should become more conservative, not less. If your attention is fragmented and your priorities are elsewhere, that is a reason to slow down, postpone the migration, or choose the more boring path.

It is definitely not a reason to hand the keys to a plausible-sounding machine and hope for the best.

Optimising away the wrong thing

The saddest part is that this was apparently all done to save around $200 a month.

This is the trap a lot of people are in right now. They are so obsessed with optimising away effort that they stop valuing judgement. Every task becomes a candidate for “just throw it at the LLM.” What they call saving time is often just borrowing failure from the future at obscene interest rates.

Then they end up as a screenshot, a cautionary tale, and a near-perfect r/leopardsatemyface case study. If you are unfamiliar with it, that subreddit is basically dedicated to people being shocked when the obviously predictable consequences of their own choices finally hit them in the face.

The header image of this post is the original Leopards Eating People’s Faces Party meme, which felt fitting.

Use LLMs all you want. But slow the fuck down.

Now, let me make something clear. I am not arguing that nobody should use LLMs. I use them too, although I have my qualms. I believe they can be useful.

But if you use them for real engineering work, especially around infrastructure, billing, data migrations or production systems, then you need to slow the fuck down.

You still need to do a few very basic things:

Read the generated code
Understand what the code is actually doing
Put guardrails in place before you run anything
Verify behaviour with logs, tests and metrics
Expect the model to be wrong in subtle ways
Review anything that could cause damage, data loss or unexpected cost
Keep the blast radius as small as possible

In other words, you need to do engineering.

Vibe Coding on totoroot's blog