Why Vibe Coding Keeps You Awake but Writing a PRD Knocks You Out

I bet you’ve all been there. You just woke up. Coffee in hand. Eyes wide open. You sit down to finally tackle that one project that’s been lingering so long you’re tempted to quit your job just to avoid it.

Twenty minutes in, your eyelids feel like they’re glued shut.

But here’s the weird part. The same brain that just nearly face-planted into a half-written PRD can vibe code until 2 AM on a Saturday and feel sharper at hour six than at hour one. Same brain. Same person. Wildly different output.

I’ve been living this contradiction for years. By day I write PRDs as a PM. By night and on weekends I build prototypes and home projects. I can vibe code Node.js for hours and feel like I just had three espressos. But ask me to draft a PRD and I’m yawning before paragraph two. For a long time I assumed I just didn’t like writing. Then I noticed something. I do like writing. I like it a lot. The thing I don’t like is waiting to know if it worked.

That’s when it clicked. The problem isn’t the task. It’s the feedback loop.

Your Brain Is a Slot Machine, Not a Bank Account

Here’s the part nobody tells you about dopamine. It’s not the chemical of pleasure. It’s the chemical of anticipation.

When you write a function and run it, your brain knows within seconds whether it worked. Green test, red test. Console output, stack trace. That tiny moment of finding out is a hit. Even when the test fails, your brain still gets a reward, because something happened. The uncertainty resolved. Researchers call this “reward prediction error”, and it’s basically the engine your brain uses to learn anything.

Coding is a slot machine you control. Every keystroke pulls the lever. Every save-and-run is a spin.

Now compare that to writing a PRD.

You write a section. Then another. You don’t know if it’s clear. You don’t know if engineering will buy in. You don’t know if the prioritization holds when leadership reads it. You won’t know any of this for days, maybe weeks, maybe a full quarter. You’re not pulling a lever. You’re putting a coin in a vending machine that may or may not deliver in three months.

Your brain hates that.

There’s actual research on this. A 2021 study in Science Advances trained mice to wait for water rewards and watched what their dopamine neurons did. The mice that could wait longer had dopamine activity that ramped up steadily during the waiting period. The ones who couldn’t wait had no ramp. They just gave up. The brain physically needs a sustained signal to tolerate long delays, and most of us have spent the last decade training ours to expect rewards in milliseconds.

Speaking of which, many of us check our phones repeatedly throughout the day. Every check is another short feedback loop. Over time, those repeated loops can make small, slow rewards feel even slower—which helps explain our goldfish-like patience for any task that doesn’t beep at us.

The Programmer’s Cheat Code

Programming exploits this on purpose. The whole development environment is a feedback machine.

Mihaly Csikszentmihalyi, the guy who literally wrote the book on flow, said three conditions are needed to enter it. Clear goals. Optimal challenge. Immediate feedback. Coding nails all three by default. The write-build-run cycle delivers a verdict in seconds. Tests pass or fail. The function returns or throws. The UI renders or breaks. There’s no “we’ll get back to you in two weeks.” Your work either works or it doesn’t, and you find out right now.

Writing a PRD nails the first condition if you’re lucky and basically zero of the other two.

Why the Long Game Feels Like Lead Boots

I want to be clear about something. The reason a PRD or a strategy doc or a quarterly roadmap makes you sleepy isn’t because the work is unimportant. It’s because the brain didn’t evolve for delayed feedback at scale.

Our ancestors got rewarded for things like spotting fruit, killing dinner, or finishing a shelter before nightfall. All of these had visible output within hours. The idea of writing a 20-page PRD today that may or may not ship as a feature in six months is, evolutionarily speaking, completely insane. There’s no fruit to grab. There’s no animal to chase. There’s just a screen and a guess.

When you sit down to do this kind of work, your prefrontal cortex (the “cool” thinking system) is fighting against your limbic system (the “hot” reward-seeking system). The limbic system wants the cookie now. The prefrontal cortex is trying to convince it that the cookie comes in three months. The prefrontal cortex is not winning that argument when you’re tired, low on caffeine, or surrounded by Slack notifications.

This also explains why so many people procrastinate on the most important work. A study published in the Journal of Consumer Research found that people can quit boring tasks because those tasks don’t take up enough attention to keep them engaged. The brain isn’t being lazy. It’s looking for stimulation. If your task doesn’t provide it, the brain goes searching elsewhere, and “elsewhere” usually means X.

How to Trick Your Brain Into Caring About Slow Work

Okay, enough theory. Here’s what actually works. I’ve been testing these on myself for the past year, and a few have moved the needle hard.

1. Build fake feedback loops. This is the biggest unlock. Programming feels good because every save shows you something. PRDs don’t have that, so you have to invent it. I read each section out loud the second I finish it. I send a single paragraph to a teammate before I’m done with the whole thing, just to get a reaction. I write the success metrics first so I have something concrete to test the rest of the doc against. Each of these is a fake save-and-run. The brain doesn’t care that the “compile” is just a teammate reading two paragraphs. It still gets the hit.

2. Stack a low-stim task with a high-stim one. Researchers call this tangential immersion. The study I mentioned earlier found that pairing a boring task with something that takes a small chunk of attention can increase persistence. I write PRDs while standing at my desk now and throwing balls into a mini basketball hoop across my home office in the garage. The throwing eats just enough cognitive load to keep my brain from drifting toward sleep, but not enough to mess up the writing.

In case you want to see the picture:

3. Make the wait shorter, on purpose. If your normal feedback cycle is “write a PRD, get it reviewed, ship in six months,” that’s too long for your brain to care. Cut it down. Send a single section to your eng lead and ask one specific question. Walk through the user story with a designer. Run the problem statement past a customer. You’re not avoiding the long game. You’re stitching together fake short games inside it.

4. Caffeine is a tool, not a personality. Coffee can temporarily increase alertness, which is why it feels like it works on slow tasks. I save my second cup for the 30-minute mark of a hard writing session, not the start. The first cup wakes me up. The second helps when the work gets hard.

5. Move your body before slow work, not after. Conventional wisdom says you exercise after work to wind down. For long-wait tasks, flip it. For me, a 20-minute walk before opening the doc makes a bigger difference than a 4-hour grind through fog. Starting with more energy makes the slow trickle of reward from writing easier to notice.

6. Make the goal physical. Write down what you’re trying to do for this session before you start. Not a giant goal. A tiny, specific one. “Finish the problem statement.” “Outline three user stories.” Keep it on paper next to you. Programmers have an IDE that constantly reminds them what they’re doing. PM docs are a blank page that doesn’t. Bring your own scoreboard.

7. Treat boredom as a signal, not a failure. When you start to feel sleepy on a long-wait task, your brain is telling you something. Either the task is unclear, the feedback is too far away, or you’ve been at it past your useful window. Don’t push through stupidly. Stop, fix one of those three, and come back. Most of my best writing comes from a 10-minute break I almost didn’t take.

The Real Lesson

The reason I can vibe code at midnight but doze off writing a PRD isn’t because I’m lazy or because writing is harder. It’s because my brain was built for a world where you knew, within hours, whether the thing you did mattered. Modern work is the exact opposite. We marinate in delay. Quarterly reviews. Roadmap revisions. Brand campaigns. Pipeline metrics. Half the things we do today won’t pay off until next month, next quarter, next year, and our reward system is sitting there going, “why are you torturing me?”

The fix isn’t more discipline. The fix is engineering your brain into the kind of feedback environment it actually thrives in. Shorten the loop. Stack the task. Score your own progress. Move your body. Reward yourself for showing up, not just for winning.

The ability to do slow, patient work in a fast-feedback world is going to be a rare skill in the next decade. Maybe the rarest one. A machine can draft the PRD for you, but it can’t sit there and care about it for the six months it takes to know if it shipped right. That part is still ours.

So the next time your eyelids start drooping at 9:43 AM on a Tuesday, don’t blame yourself. You’re not broken. You’re just running ancestral hardware on a workload it was never designed for.

The question is what you build around it.