Spend Your Tokens Where You Have Taste

The short version

AI tools let me contribute well beyond my role. This has been genuinely exciting. But work produced outside your craft has hidden costs. AI makes it easy to produce something fast that looks good. But looking good isn't the bar. The people who own that craft hold a standard they'd be proud to ship themselves, and they inherit the work of pulling your output up to it.

AI is a mirror: it reflects your skills back at you. And now that tokens are getting priced, there's an economic version of the same point. The simplest read on whether you're spending them effectively is how much of your agent's work happens inside your own craft. That's not "stay in your lane." Crossing domains for context and learning is healthy; handing off deliverables you can't judge is where it leaks.

All of this will keep evolving as AI does, but one thing holds: we each have real strengths, and as long as we're in the loop, they matter.

Three years ago, the best tool I had for showing a customer an idea was a slide deck. Then v0 arrived, and I could get on a call with a clickable prototype instead of a picture of one. That felt like a superpower.

But the possibilities kept improving. I can make the v0 prototypes look more like our product. Then, with Claude Code, they could just be built in our real codebase, running locally, on our real components. It wasn't long before the lowest friction thing was to just ship the code.

There was a second thrill underneath the speed. That feeling of empowerment, a seat at the table, the ability to use the idea of "code wins arguments" to push my ideas forward that otherwise may have received more scrutiny. Being able to share a working implementation forces attention in a way that a doc or ppt deck can never get.

Anyone who's been near or using agentic tools to creep outside of your domain likely knows this arc. Every step felt like progress. And there's little incentive to slow down because the outputs come quickly, look good (enough) and seem to progress the team as a whole. The answer to "mind if I use Claude to take a crack at this?" is usually an indifferent "sure, why not?".

But after a couple months, I think I'm seeing the costs it's had on my day-to-day workflows (and likely the work I'm inadvertently handing to others).

The road to vibing has no signposts

Every step on that path is locally reasonable, and there's no marker telling you when you've crossed from discovery into something else.

Every step is locally reasonable. There's no signpost that says "you have left discovery."

The logic that carries you down the slope is real product logic. Speed to feedback for me is the prize, and live behavior from customers using our product beats a demo reaction. Why show a customer a prototype when you could flag the real thing into their account? I wasn't being reckless when I followed that reasoning, I just wanted to improve the feedback loops.

But three things started nagging at me.

My time was leaking. I'd look up from hours of wrangling code in a part of the system I didn't understand and realize the agent had made the work possible without making it a good use of me.

What I shipped wasn't finished. I see the part of a PR above the water: it exists, it runs. What I can't see, because I've never lived it, is everything below: the review burden on an engineer who has to understand code I don't fully understand myself, the rework, the on-call rotation that inherits it. Along with the code, I was pushing cognitive load (downstream to a colleague). My PR felt like a contribution to me. To the reviewing engineer, it was unpriced work.

Most of shipping happens after the merge, and none of it happens to the person who vibe-coded it.

But this realization didn't really sink in until being on the receiving end.

AI is a mirror

There's a motif I've picked up from Ben Thompson and others: AI is a mirror. It reflects your own skills back at you. Your agent is roughly as good as you are at the thing you're pointing it at, because the output is bounded by your ability to steer, push back, and recognize when it's wrong.

I know this because I've also lived the receiving end. When someone who isn't a PM sends me AI-generated "product" output, I can tell within seconds: confident assumptions, a list of features where a problem statement should be, no sense of what was deliberately left out. What makes it frustrating is that the assumptions and requests are plausible. If it were simply bad, it'd be easy to spot and hand back. But because it's plausible, I have to unpack the bias and uncover what the root problem in the source material actually was. The output created work instead of saving it.

Then the uncomfortable reflection: that's exactly what my PRs look like to an engineer. Same mirror, other side. I can smell when PM work is off. I cannot smell when Go code is off. The agent papers right over that gap.

And it generalizes. A PM doing engineering produces code that looks done and reads like risk. An engineer, sales, or customer success role doing product produces feature lists that look like strategy, minus everything that matters: which problem, what was cut, what the customer meant. Anyone doing design produces screens that look good, which is the trap, because the surface is most of what non-designers can perceive. The hierarchy, the coherence, the states nobody screenshots are underwater.

AI raises the floor of what you can produce outside your domain, but it raises the ceiling inside it. Cross-domain output is plausible. In-domain output is good. And plausible-but-not-good is the most expensive kind of artifact, because someone qualified has to take it apart.

The token subsidy is ending

There's an economic reason this question is getting sharper right now.

For the past couple of years we've been living in a token surplus. Like cloud credits in the 2010s or subsidized Uber rides, usage was priced below its real value, so the rational move was to max out. Throw tokens at everything, including everything outside your lane. I'd defend that era. Token maxing was how we found out what these tools could do, and doing the coding myself is how I learned where the walls are. You can't see the iceberg from a doc.

But subsidies end. Token costs are becoming real line items, and the leaderboard question is shifting from "who's using AI the most" to "who's using it most effectively."

When usage was free, exploration was the strategy. When usage is priced, allocation is the strategy.

This is where the two frames snap together. When tokens are free, a PM spending a week of them on engineering work costs nothing visible. When they're priced, it becomes an allocation question, and the mirror gives you the answer: tokens compound inside your domain and leak outside it. The same thousand tokens make me meaningfully better at problem framing, or a mediocre, expensive junior engineer.

There's also a cost that never shows up in the PR. Every hour I spent wrangling code outside my expertise was an hour I didn't spend on the compounding stuff, and it's simply less efficient for me to grind on engineering tasks when the same hours pointed at the problem space go so much further. Used well, AI could 10x my PM output if I stay focused there. Every time I slipped into the next steps without the people who own them, I was trading that multiplier away.

Measuring this task-by-task will be hard, and I'm skeptical anyone gets a clean per-task ROI metric soon. But there's a first cut that's almost embarrassingly available: the category of work. Is this person spending tokens inside the craft they've built judgment in, or outside it? That one question probably explains more variance in AI effectiveness than any prompt technique or model choice.

The danger quadrant is crossing domains and then handing off the artifact.

Note what the 2x2 doesn't say: never leave your lane. The bridging quadrant is real. Prototyping in the codebase taught me things no shaping doc could. The line is which artifacts you ask other people to own.

The mirror test

Before pointing an agent at a task, ask: am I the person whose judgment makes this output good, or just the person whose prompting makes it exist?

Three commitments follow.

Spend tokens where you have taste. My ceiling with AI is the problem space: sharper discovery, better-framed problems, faster synthesis of customer evidence. That's where my agent is genuinely good, because I can catch it being wrong.

Cross domains for context, not deliverables. Prototypes and technical discovery are in. But the output should be understanding I carry back to my own craft, not artifacts someone else has to own. The moment a prototype is "pretty close, might as well flip the switch," it's leaked. Hard constraints help: prototype spaces that structurally can't merge.

Feed context to the people who own the craft. If I want engineering to go faster, the highest-leverage move is loading the engineer, and increasingly the engineer's agent, with the problem, the evidence, the constraints, what we cut and why. Their agent reflects their skill, and it does its best work when the inputs carry mine.

That last one resolves the equal seat I was chasing. What I actually wanted was to be heard at the speed of code, and context travels that fast now too.

The binding constraint is the judgment of whoever's steering, and judgment doesn't transfer through a prompt. The tools will keep making it easier to produce plausible work outside your craft, which makes the discipline of not doing so more valuable, not less.

The companies that win the next phase will be the ones that figure out fastest where their tokens compound.