How Vibe Coding Actually Works (or Doesn't...)

News screenshot: CNBC, Annie Palmer, October 27, 2026. Reproduced as a short visual reference for commentary. Read the source article.

Everyone has something to sell, especially if they've invested hundreds of billions of dollars in compute. But I've got nothing to sell you, and I'll tell you straight about my experience using the latest and greatest frontier models to code.

Amazon is apparently telling its engineers to ease up on the AI cheese. After encouraging AI adoption, its engineering leadership is now warning against "tokenmaxxing" and mistaking AI usage for actual productivity. To be precise, Amazon still encourages AI adoption; its published engineering memo argues that outcomes matter more than token counts or lines of code.

Well, it's about kitten time.

The ninety-minute honeymoon

0:00 — Give the agent a task.

1:00 — This is AMAZING. Look how fast we're going!

1:30 — Waitaminute...

1:35 — Something smells funny here. Bro, can you take another look?

1:40 — AI: "You're absolutely right. I apologize for the oversight. I'll correct it."

1:50 — AI: "Done! All issues addressed."

1:51 — I look at the code again.

1:52 — WHAT THE KITTEN?!

An actual example, in the order it happened

I'm running Codex on GPT-6.1 Sol at xhigh reasoning effort, mind you. That's supposed to be somewhere in the superintelligence neighborhood, or at least that's how we're selling it these days.

So I asked Codex to go over some of the signatures it had modified, especially in the contextual file renderer. Wasn't the data it needed already available on the instance?

And sure enough, it found one. The renderer accepted both request and call_context, even though request.call_context already had the same information. Worse, the two could disagree until refresh_current_source() copied one over the other.

Codex agreed. Redundant argument. Should be removed.

Then it promised to remove it, clean up another parameter, and retest. Even showed me the files it changed.

So I looked again.

The argument was still there.

WHAT THE KITTEN?!

I told it to look through all the unstaged files too. And wouldn't you know it, the next sweep found even more redundant inputs. Helpers passing analysis already sitting in the instance cache. Methods accepting arguments they never even read.

And once again, Codex announced it was removing them.

That's what drives me nuts. It wasn't that the AI couldn't figure out the problem. It found the problem, explained why it was a problem, promised to fix it, and somehow I still had to find it again.

Again this is GPT-6.1 Sol, xhigh. A real coding champ, supposedly.

I doubt superintelligence was ever wrong. It probably just needs someone to keep it honest.

Working code isn't correct code

There's a big difference between producing working code and correct code.

The first is practically a meme. You've heard it before: "Works on my machine."

The second is code that survives adversarial environments, corner cases, weird idiosyncrasies, non-functional requirements, and 1,000 rewrites before earning user acceptance.

That's a much higher bar.

AI makes saying "Works on my machine" and "LGTM" easier than ever.

It also makes the knowability problem bigger than ever.

But I barely look at the code anymore!

Some of you might say you barely look at AI-generated code anymore. Fair enough. Some kinds of defects are easy to verify by observation.

Take UX. Wrong color? You can see it. Something renders slowly, gets clipped, or overlaps another element? You can see and interact with that too.

But how do you establish that a system processing 100 transactions per second remains idempotent under concurrent retries, network failures, and partial writes?

Watching a million successful transactions doesn't prove the next one won't fail. You have to reason about the invariants, the ordering of operations, the failure model, and the boundaries of the guarantee. Even then, your conclusion only holds under the assumptions you've actually checked.

For non-engineers, imagine trying to prove aliens have never visited Earth. You can't simply look around and declare victory, especially if the Men in Black have neuralyzers. You can reason from the speed of light, interstellar distances, and what we know about nearby potentially habitable planets to assess how plausible a visit would be.

Some things can be checked by looking at the result. Others require reasoning about the rules that govern the result.

And AI is becoming remarkably good at producing results while leaving us with the rather inconvenient job of establishing whether they're correct.

That's the real engineering problem.

Does this mean computer science is safe?

Not remotely. None of this means computer science isn't in trouble.

But how many of you work on systems where correctness isn't directly observable? Show of hands.

How do you test a million concurrent customers hitting your service? What does querying 3 PB of data actually look like at production scale? And how do you establish that your distributed data remains consistent, even if only eventually, when failures happen in combinations you never thought to simulate?

For those riding the latest AI wave, here's another one: train your own model.

How do you know it hasn't regressed somewhere? Will training converge? Did you set the learning rate too high or too low? If cross-entropy loss starts rising, do you stop the experiment, adjust the learning rate, or keep going?

What if the loss is decreasing beautifully during training, but the model fails miserably at test time?

You can observe the metrics. But do you know what they're telling you?

It's the same knowability problem. At scale, the hard things can't be proven by inspecting the result. You have to build the proof from axioms, using mathematical induction.

You can, however, build statistics. But statistics are habitual liars.

And that brings me to test-driven development. Some engineers hold TDD as something close to gospel.

I don't.

Tests can tell you what happened under the conditions you tested. They can't, by themselves, tell you what happens under every condition you didn't. A test suite isn't a substitute for understanding your invariants, architecture, failure modes, or the limits of your assumptions.

That doesn't mean testing is useless. It means passing tests and knowing a system is correct are two different things.

But I'll stop here. That's a subject for another blog.

---

References: CNBC article by Annie Palmer; Amazon's published guidance on AI and software engineering; Amazon Builders' Library on idempotent APIs; Stanford Encyclopedia of Philosophy on inductive logic.