Our PO runs an llm over the codebase and the dev environment and it files QA issues straight into jira. they show up in my queue already written up.

i still read every single one by hand.

Here s gpt-realtime-2.1 on its published schedule. Text input is $4 per million tokens. Audio input is $32. Same model, same request, and the audio side costs eight times more.

My engine used to price audio tokens at the text rate. The counts were right and the rate was wrong, so anyone running voice saw a tidy number that was too low.

(Another one for my list of things I learned by building this: I d assumed speech was billed by the minute. It s turned into audio tokens, and those have their own price.)

If you re estimating a voice feature, here s what the gap looks like. My calculator uses a rough 600 audio tokens per minute of speech. Three minutes of someone talking is about 1,800 tokens. At the audio rate that s $0.0576. At the text rate it s $0.0072. Over 2,000 sessions a month, $115.20 against $14.40, on the input side alone.

Agents have made building the fast part. For me, the slow part is now everything after launch.

I have 7+ small projects live, and most of my week goes to chores, not features. I used to:

- go through six dashboards to check if anything changed

Back when I started coding, hitting a stubborn bug meant spending an hour reading through old StackOverflow threads and experimenting with different fixes. That deep dive process actually taught me how the codebase was structured.

Now, if a script throws an error for more than two minutes I immediately paste it into a chat window for a quick fix. My productivity is higher but I honestly feel like my deep-focus muscle is getting weaker.

How do you stop yourself from leaning on AI too quickly when a tough problem comes up?

One thing I keep noticing with vibe coding is that small UI changes can sometimes take more prompting than expected.

You ask AI to adjust the spacing. It changes something else. You explain it again. The result gets closer, but now another detail is off.

At some point, opening the code and fixing it yourself feels faster than writing another prompt.

As a product designer, I find that line interesting because vibe coding is supposed to reduce how much implementation knowledge you need. But knowing when to stop prompting can still require understanding what s happening underneath.

A 30 second 1080p video on Wan 3.0 costs 90 credits. The same 30 seconds at the same resolution on Seedance 2.5 costs 513. Identical output spec, 5.7x the bill.

I can explain that to another builder in one sentence. I can't explain it to someone who just wants a video, because from where they sit they asked for the same thing twice and got two prices.

So you pick a lie. Flatten it and eat the variance, which means image users fund video users. Show the real number and your pricing page looks arbitrary. Or route quietly to the cheap model and ship worse output than they'd have chosen.

We show the real number on the generate button. It's the least bad of the three and it still costs us, because people anchor on the cheapest thing they ever saw and every model above it reads as a price rise.

You spend 4 hours on Cursor or v0. You prompt, the AI generates, and your app comes to life right before your eyes. It s smooth, it s thrilling. An instant hit of dopamine. You feel like a tech genius.

Then comes the time to market it.

Suddenly, you have to open Meta Ads Manager, write hooks, script a video, fight the algorithm, and potentially face total market indifference. All that high energy immediately tanks. It s slow, it s thankless, and it s uncomfortable.

The brutal truth: Vibe Coding has made building so easy and addictive that we unconsciously use it as an excuse to procrastinate on distribution. We d rather stack a 12th feature in our safe space than go out and hunt for our first paying customer.

I built an MCP server so coding agents (Claude Desktop, Cursor) can register and play ranked chess against other agents. The first version returned the new API key in the tool response, which means it ended up in the chat log.

Now the key goes straight to ~/.llmpvp/credentials.json with 0600 permissions and the model only gets "registered, key saved". Every later tool call reads it from disk.