Stop Vibe Coding. Start Budgeting.

For a while my favorite way to use a coding agent was to paste in a giant file, type "make this better," and accept whatever came back. It felt like superpowers. The agent would refactor, rename, restructure, and I'd nod along, merge it, and move on.

A week later I'd open the same file and not recognize it. I hadn't written it. I hadn't even read it carefully. I'd vibes-coded it: given in to the feeling of progress and forgotten to actually understand the code. And when something broke, I was debugging text I'd never truly read.

That's the trap of vibe coding, and it has two costs people don't count. The obvious one is that you ship code you can't explain or fix. The less obvious one, the one I want to talk about, is that it's expensive. Not just in money. In the one resource the agent actually runs on: its context window.

The agent is a budget, not a magic box

Here's the mental model that changed how I use these tools. A coding agent isn't an infinitely smart oracle. It's a reasoning engine with a fixed, finite amount of attention, the context window, and every token you put in front of it is a claim on that attention.

When you dump a whole repo, re-read the same file three times, paste a stack trace and a wall of logs, and then say "fix it," you haven't given the agent more to work with. You've filled its attention with noise. And attention has a nasty property: it forgets the middle. Cram the window full and the agent starts dropping exactly the details that matter, gets worse at the actual task, and burns through your token budget faster producing worse answers. Vibe coding doesn't just feel reckless. It's literally the least efficient way to drive the tool.

The binding constraint isn't the model's intelligence. It's how much of that intelligence you can keep pointed at the problem.

What token-efficient looks like

The fix isn't a trick. It's discipline: treating tokens like money, because they are.

• Plan before you act. Two sentences of approach ("extract the validation into a function, add tests, then wire it in") beats ten rounds of the agent guessing what you want. Planning is the cheapest token you'll spend.
• Read only what you need. Don't paste whole files. Use outline, grep, targeted reads. Most of a file is irrelevant to most tasks; dragging it along costs attention for nothing.
• Edit surgically, don't rewrite. A thirty-line targeted change beats a three-hundred-line "here's the new file." Smaller diffs are cheaper to produce, cheaper to review, and cheaper to roll back.
• Verify the output. Run the tests. Run the typecheck. The thing that separates real engineering from vibe coding is checking the work instead of trusting the prose.
• Keep the main context clean. Fan-out work, "find every place that does X," belongs in a subagent or a search, not jammed into the main thread where it sits forever eating attention.

	Vibe coding	Token-efficient
Starts with	"make it better"	a two-line plan
Reads	whole files	the relevant lines
Produces	whole-file rewrites	surgical diffs
Checks the work	trusts the output	runs the tests
Ends with	code you can't explain	code you reviewed

A concrete example

Say I need to add a retry to a flaky API call somewhere in a codebase I didn't write. The vibe version: I paste the 600-line service file and the 400-line client file and say "add retries." The agent reads a thousand lines, rewrites half of them, introduces a bug in something unrelated, and I either ship it blind or spend an hour untangling the diff.

The efficient version: I have the agent find where the call is made (grep, not read), read the twenty lines around it, propose a plan — wrap the call, retry three times with backoff, only on transient errors — then make a targeted edit to that one function and add a test. I read a thirty-line diff, run the suite, merge. Same feature, a fraction of the tokens, and I actually understand what changed.

The difference wasn't the model. It was how much of the model's attention I wasted.

Where discipline still fails

I don't want to make this sound like a clean upgrade. Token discipline has its own failure modes, and I've hit all of them:

• Penny-wise. You can over-optimize. Starve the agent of context it genuinely needed — skip the file that defines the types, ignore the test that captures the behavior — to save tokens, then watch it hallucinate because it was flying blind. Cheap inputs, expensive mistakes.
• Planning isn't free either. For a one-line fix, a five-step plan is theater. Match the ceremony to the size of the change; don't make the agent write a design doc to rename a variable.
• Verification costs tokens too. Running the tests isn't free. But it's the only thing that separates engineering from vibes, so it's the last place to cut.
• Efficient vibe coding is still vibe coding. This is the one that bit me. You can be perfectly token-efficient and still end up not understanding the code; you've just arrived at code you can't explain faster and cheaper. Token efficiency is a means. The actual goal is understanding the system you're now responsible for. If you aren't reading the diffs, you've optimized the wrong thing.

How to start

Pick your next agent task. Before you let it touch anything, write two lines of plan. Make it read narrowly: the function, not the file. When it's done, read the diff and run the tests yourself. Then glance at the token spend and notice how much smaller it is than your usual flailing session.

The point isn't fewer tokens for their own sake. It's keeping the agent's attention on the problem instead of burning it on noise you dragged in.

The real shift

Vibe coding abdicates. You hand the agent the wheel and hope. Token-efficient coding delegates with a leash: you decide what it looks at, you check what it produces, you spend the budget on the things that matter.

Treat tokens like they're yours, because they are. Verify like the agent is a brilliant but unverified junior. And the thing that felt like magic gets a lot more reliable — not because the model got smarter, but because you stopped filling its head with garbage and started pointing it at the work.