The Alert
It was January 15th. Our AWS cost anomaly alert fired — S3 request costs had spiked overnight. Not by 10%, not by 50%, but by an order of magnitude that made us double-check whether we were looking at the right account.
The culprit? An auto-archival cron job that was supposed to save us money by moving cold video files to Glacier. Instead, it made 369 million PutObjectTagging API calls in a single run.
The root cause was absurdly simple: one function was missing a 3-line guard that another function in the same file already had. But the deeper cause wasn't a missing guard — it was a missing thought. Nobody, at any point in the authoring or review of that code, asked "what if the input is malformed?"
This is not a story about AI writing bad code. It's a story about cognitive offloading — the quiet, almost invisible handoff of reasoning from the developer to the model — and why that handoff is where bugs like this are born.
The Simple Logic That Broke
We have a video platform. Videos are stored in S3 as segmented files. The archival job does something straightforward:
- Get a video's storage path from the database (e.g.,
videos/region/12345/) - List all segment files under that path
- Tag each file for archival
The problem? One malformed URL in the database.
Most videos had well-structured paths like videos/us-east/12345/ — pointing to a specific directory with ~200 files. But one entry had a malformed path that resolved to a broad prefix matching 332,000 files.
The function processed this bad entry. It listed 332,000 files. It tagged all of them. Then it found another similar entry. And another. 1,113 entries with this bad URL pattern.
1,113 bad entries × 332,000 files = 369 million API calls
Cognitive Offloading: The Real Failure Mode
The code was syntactically perfect. It compiled. It handled errors gracefully. It used proper concurrency patterns. By every metric that AI optimizes for, it was good code.
But here's what didn't happen: nobody thought about bad URLs.
Cognitive offloading is the phenomenon where we hand off mental work to an external system — a calculator, a GPS, a search engine. In small doses it's a superpower; it frees our attention for higher-order reasoning. But offloading only works when you're aware of what you've offloaded. Vibe coding is dangerous precisely because the offloading is invisible. You feel like you're engineering. You're actually just approving.
The Brain Checked Out — Without Noticing
When you write code line by line, your working memory is constantly loaded with the problem:
- What values can this parameter have?
- What happens if the input is malformed?
- What's the worst case for this loop?
That load is uncomfortable — and it's exactly the discomfort that produces defensive code.
When AI writes the code and you review it, the cognitive load drops to near zero. Your brain, helpfully, stops doing the hard work it's no longer being asked to do. The mental mode silently shifts from constructing failure models to pattern matching on generated text: Does this look right? Does it compile? Are there obvious bugs?
You're scanning for red flags, not building a mental model. And critically, you don't feel the difference. Reviewing feels like engineering. It isn't.
A human writing this function from scratch would naturally ask: "What if the URL is malformed? What if it points to a directory with millions of files?" Those questions don't come from discipline — they come from the fact that your brain cannot write code without simulating it. Offload the writing, and you offload the simulation with it.
The TDD Instinct Atrophies
When developers write code manually, there's a natural instinct to think about edge cases — even without formal TDD. You're building a function that takes a URL, so you think: What if it's empty? What if it's malformed? What if it points somewhere unexpected?
This isn't just good practice. It's how the brain naturally works when engaged with a problem. You anticipate failure because you're the one constructing the solution.
Vibe coding short-circuits this. The solution appears. It looks correct. The mental energy that would have gone into "what could go wrong?" is never spent.
If we had written this function manually, we almost certainly would have added validation:
// Natural defensive thinking when writing code yourselfif !isValidVideoPath(url) { return fmt.Errorf("invalid video path: %s", url)}if countPathSegments(prefix) < 3 { return fmt.Errorf("prefix too broad, refusing to process")}
These guards weren't added because nobody was thinking at that level. The AI produced working code, and working code doesn't invite scrutiny.
Sibling Functions Drift Apart — Because Context Was Never Loaded
Our codebase had two similar functions — one older, one newer. The older function had a guard against bad URL patterns. The newer one (AI-generated) didn't.
A developer who hand-wrote both functions would carry context between them. "Oh, I need that same guard here." That cross-function memory isn't discipline — it's a natural side effect of having done the reasoning yourself.
With vibe coding, that context is never loaded into the developer's head in the first place. The AI generates each function in isolation from the developer's mental model. The AI doesn't know what guards exist in sibling functions, and the developer — who outsourced the construction — doesn't have the kind of hot, working-memory familiarity that would make the gap obvious.
This is the cognitive-offloading tax: you don't just lose the output of the thinking you skipped, you lose the cross-connections that thinking would have built.
The Real Cost: An Engineer Who Stopped Reasoning
The dollar figure wasn't the real cost. The real cost was discovering that an entire feature had been authored, reviewed, and shipped without anyone ever holding the problem in their head.
Vibe coding creates an illusion of productivity by swapping a hard cognitive task (designing correct behavior under adversarial inputs) for an easy one (evaluating plausible-looking code). The brain happily accepts the trade. But:
- You didn't think about what inputs could break it
- You didn't consider the data shapes in production
- You didn't ask "what's the blast radius if this goes wrong?"
The speed came from offloading the thinking. And the thinking was the important part.
Worse, cognitive offloading is self-reinforcing. Every task you complete without thinking deeply makes the next "just prompt it" choice feel more normal. The muscle atrophies. The discomfort of deep reasoning — the very discomfort that catches bugs — starts to feel unnecessary.
The Case for Slow Coding: Re-Onloading the Thinking
The solution isn't to abandon AI assistance. It's to deliberately pull the cognitive work back — to re-onload the reasoning that vibe coding silently takes from you.
What is Slow Coding?
Slow coding means: even when using AI, you refuse to offload the parts of thinking that matter. You let the AI offload typing, syntax, boilerplate. You keep, for yourself, the reasoning about inputs, failure modes, blast radius, and codebase fit.
It's not about typing slower. It's about noticing when your brain is checking out and forcing it back in.
Why Rules Won't Save You
It's tempting to respond to an incident like ours with a checklist: always validate URLs, always cap loop sizes, always diff against sibling functions. We tried drafting one. It didn't survive contact with the next feature.
Rules are finite. The shapes of failure are not. For every guard you codify, the next bug will arrive in a form your list didn't anticipate — a new data type, a new integration, a new assumption quietly baked into the prompt. You cannot out-rule the space of possible edge cases; you can only think your way through them, one function at a time.
So the answer isn't a longer checklist. The answer is a working style that keeps your brain in the loop.
The Slow Coding Pattern: Small Steps, TDD-Style, Even With AI
The fix for cognitive offloading isn't more discipline — it's smaller units of work. If the prompt is big, the generated code is big, and reviewing big generated code offloads your thinking just as surely as writing it did. The only way to stay engaged is to keep every step small enough that your brain actually processes it.
1. Build a blueprint before you prompt anything
Before any code is generated, sketch the shape of what you're building: the functions, their inputs, their outputs, and how they connect. Not in a design doc — just enough to know what the first small piece is. If you can't describe the first piece in a sentence, the piece is too big.
2. Do one piece at a time — TDD-style, even with vibe coding
Treat AI-assisted work the way TDD treats manual work: tiny loops.
- Pick the smallest useful unit (one function, one branch, one behavior).
- Write — or have the AI write — a test for it, including the failure cases you expect.
- Generate the implementation.
- Run it. Actually run it. Watch the test pass. Watch it fail on the inputs you expect to fail.
- Only then move to the next piece.
The act of running and observing each small piece is what forces your brain to build a real mental model. A large prompt that generates ten functions at once skips all ten of those observation points.
3. Resist the temptation of the "magic" prompt
The most dangerous prompt is the one that produces a lot of working code in one shot. It feels efficient. It is the purest form of cognitive offloading: you've traded thinking about ten decisions for skimming one diff.
If a prompt generates more code than you'd comfortably write yourself in one sitting, it's generating more code than you'll meaningfully review. Break it up — not because the AI can't handle the larger task, but because you can't stay engaged across it. Reading a large generated codebase offloads cognition just as much as generating it did; your eyes move, but your brain coasts.
A good heuristic: if you can't name, out loud, every decision the AI just made, the step was too big.
4. Let the running code, not the reading, be your feedback loop
Manual TDD works because the red/green cycle keeps reality in the loop — you can't fool yourself when the test fails. Vibe coding without this loop is pure trust in generated text. Adding the loop back — small piece, test, run, observe — is what converts "it looks right" into "I've seen it behave right."
This is slower per step. It is dramatically faster per bug avoided.
The Mindset Shift: Offload Typing, Not Thinking
Vibe coding optimizes for time to working code by offloading as much cognition as possible.
Slow coding optimizes for confidence in correct code by being deliberate about what you offload and what you keep.
The irony is that slow coding is often faster in total. Our archival feature was "done" quickly with vibe coding. The debugging, investigation, and fixes that followed took far longer than writing it thoughtfully would have.
Keep Thinking, Even With AI
The core principle is simple: AI should reduce your keystrokes, not your engagement.
- AI writes the code → you still think about edge cases
- AI handles syntax → you still reason about data shapes
- AI produces working code → you still ask "what could go wrong?"
The moment you stop asking these questions because "the AI handled it," you've offloaded the one thing you shouldn't — and traded engineering for hope.
Final Thought
Vibe coding isn't going away. AI assistance is too powerful to abandon. But the way we use it needs to change — because the failure mode isn't the tool, it's what the tool does to our attention.
The value of a developer isn't in typing code. It's in holding context and reasoning about it. The codebase knowledge, the historical decisions, the mental simulation of adversarial inputs — this is exactly the work that cognitive offloading makes disappear. AI doesn't do it for you; it just makes it feel like someone did.
Slow coding is the practice of refusing that illusion. It means reading the surrounding code before generating new code. It means asking "what already exists that handles this?" before writing something fresh. It means deliberately re-onloading the thinking that vibe coding silently outsourced.
The 369 million API calls happened because a guard existed in one function and not another. A developer whose brain was still engaged with the problem would have noticed. Ours wasn't — because we'd let the AI do the thinking we should have kept for ourselves.
Don't vibe code in the dark. Offload the typing. Keep the thinking. That boundary is the difference between acceleration and abdication.
This postmortem is based on a real incident in our video archival system, January 2026. The 369 million API calls and $1,850 cost are from the actual investigation.