Do It Live

There’s a famous leaked outtake from Bill O’Reilly’s early days anchoring Inside Edition. He’s trying to close out the show, but the teleprompter hands him a line he can’t make sense of — “to play us out” — and he unravels on camera. He asks what it means. Nobody gives him an answer he likes. The frustration builds until he throws the script aside and delivers the line that became the meme: “F*** it, we’ll do it live!”

Everyone knows the clip. What strikes me about it now is not the anger. It’s the decision underneath it. He didn’t understand what was on the page, and instead of doing the work to get the words right, he trashed the script and winged it.

That’s how products are getting built right now. We are all Bill O’Reilly, and we are all doing it live.

I understand the temptation, because I feel it too. AI has accelerated how fast engineering can produce output, and the output is no longer precious. Code has become ephemeral — easy to change, easy to throw away, easy to mold in real time while everyone watches. So why write anything down? Why labor over a PRD or a stack of user stories when the change can be vibed into place on a video call before the meeting ends? The script feels like an obstacle. The live take feels like shipping.

Underneath that temptation sits a more corrosive feeling: that we don’t have to get clear on the problem we’re solving, or the vision we’re building toward, because we can change it all so quickly. Pivot on our pivots. Nothing is load-bearing, so nothing needs to be thought through. Speed starts to pass for clarity, and the two are not the same thing.

I’ve lived this. There have been very few artifacts to work from — almost everything coordinated through a Slack channel, a video session, a one-on-one live vibe-coding session. And with it came a huge breakdown in communication about what we were actually building. The product existed mostly as a shared feeling among the people who happened to be in the room. Everyone left the call confident. No two people left with the same product in their head.

It got backwards enough that I found myself implementing what I can only call posthumous documentation — backfilling user stories based on what we ended up building, so there would be some record of what the thing was supposed to do. That is exactly the reverse of how I believe this is supposed to work. It felt like leaving breadcrumbs behind me while wandering through the forest, instead of deciding where I was going before setting out.

Sounds easy enough to dismiss: the thing shipped, didn’t it? And for an MVP, honestly, doing it live might be fine. If the goal is to learn something fast and throw the result away, the speed is the whole point. But in my experience, building a real product — scalable, maintained by a team, alive longer than one demo cycle — this way leaves nothing clamping feature creep and nothing keeping the focus. Every session targets output. Nobody owns the question of what we’re not building. The scope expands one enthusiastic screen-share at a time, and the vision dilutes with every pivot nobody wrote down.

Here’s the part I think gets missed. The old handoff had a hidden safety valve, and we removed it without noticing. When a developer picked up a vague spec, they did something no agent does: they stopped and asked. “What do you actually mean by this?” That question — that annoying, slow, human bit of friction — caught bad assumptions before they became bad code. An LLM doesn’t ask. It fills every gap in the thinking with plausible inference and ships the ambiguity as working software, the same afternoon. The vagueness doesn’t get caught anymore. It gets built.

So the spec didn’t become less important because AI can code. It became the most important artifact in the whole pipeline, because it’s now consumed by a literal executor that never pushes back.

This is the same chasm I wrote about developers crossing, arriving on product’s doorstep. Developers had to move from writing code by hand to producing deterministic output from nondeterministic models. I believe the onus now sits with product and design to make the same crossing: to use those same agentic skills to get to clarity fast, and to produce artifacts a human can trust and a delivery-side LLM can consume without guessing.

Here is what that actually looks like for me, because I’ve stopped talking about this in the abstract. I work in Claude, and I’ve built a set of skills — one for each step in the pipeline. The first is an exploration skill. Its job is to dig into a product idea with me: what problem this solves, who it’s for, what the core value of each feature really is, what we are deliberately not building. The output of that skill is a PRD. The second skill takes that PRD and elaborates it into a series of user stories and sprints, keeping the context tight and focused on delivery the whole way. Those stories are the artifacts that get handed off. On the delivery side, the LLMs ingest the user stories along with a clearly defined AGENTS.md or CLAUDE.md in the codebase, and out comes high-quality code that traces back to something someone actually decided.

flowchart TD
  idea[Product idea] --> explore["Exploration skill (interview)"]
  explore -->|"questions until the<br/>ambiguity runs dry"| explore
  explore --> prd[PRD]
  prd --> elaborate["Elaboration skill (interrogate the PRD)"]
  elaborate -->|"gaps and edge cases,<br/>one at a time"| elaborate
  elaborate --> stories["User stories / sprints"]
  stories --> handoff{{"The handoff"}}
  handoff --> delivery["Delivery-side LLMs"]
  agentsmd["AGENTS.md / CLAUDE.md in the codebase"] --> delivery
  delivery --> code["High-quality code that<br/>traces back to a decision"]

The pipeline: two product-side skills that interview before they write, artifacts as the only thing crossing the handoff, and delivery-side LLMs grounded by the codebase’s agent files. The loops are the point — nothing moves downstream until the questions run dry.

The important part is what the LLM is doing in those product-side skills, because it is not writing a document in one shot. It interviews me. It keeps asking questions until the ambiguity runs dry. Then it drafts from my raw input, and I prune. Then it turns critic — red-teaming the artifact for gaps, contradictions, and the edge cases I didn’t think to mention. Only then does it structure the result into something the delivery side can consume. The machine handles the typing; the interrogation is the point. Every question it asks me is a gap that would otherwise have been filled by inference in somebody’s codebase.

And this whole pipeline is fast. With voice input landing in Claude Code and the other tools, I can talk my way through the exploration on a walk if I want to. Speaking a product into existence still feels like science fiction to me — an amazing world we live in. But the speed only works because each step forces clarity before anything moves downstream. It’s doing it live, pointed at the script instead of the broadcast.

Don’t get me wrong — this is not a return to the hundred-page requirements document nobody reads. Bloat is as much a failure as vagueness, and an LLM will happily generate either one. A beautiful, confident, wrong PRD is more dangerous than a rough one, because polish gets approved without scrutiny. The work is in the thinking, not the typing — it takes real effort to organize thought, and I don’t want my artifacts to suffer just because producing one has gotten easy. The ease is exactly why I no longer have an excuse.

I hold an artifact to a simple bar before it leaves my hands. The problem and the vision are stated before any solution detail. What we are not building is written down, because every gap I leave is a gap an agent will fill for me. Someone with zero context — a new hire, or an agent — could build from it without guessing. And it’s structured so the delivery-side LLM can take it directly, no translation layer, no meeting to explain what it really means. If it fails any of those, it isn’t done, no matter how polished it looks.

That coordinated handoff — clear problem, clear scope, clear stories, cleanly consumable on the other side — is the product team’s product. It is the deliverable. Quality doesn’t live in the PRD or in the code; it lives in the handoff between them, and both sides now have LLMs pointed at that seam. More work put into getting clear, and agentic AI used to arrive at that clarity faster, is the skill I’m watching for on every product team I work with — and the one I’m working to sharpen in myself.

I can no longer operate in vague. The live take is for the demo — not for deciding what we’re building.

O’Reilly did it live because he didn’t want to do the work of understanding the script. It made for a great meme. It makes for a terrible product.

---

Two basic example prompts for the product-side phases — simplified starting points, not the full skills. The delivery-side setup (CLAUDE.md / AGENTS.md) is too much to include here and deserves its own post.

Exploring an idea into a PRD:

I have a product idea I want to explore. Do not write anything yet.
Interview me first — one question at a time — about the problem it
solves, who it's for, the core value of each feature, and what should
be out of scope. Challenge anything vague. When the ambiguity runs
dry, and only then, draft a tight PRD from my answers using exactly
this structure. No filler.

# <Product name>

## Problem
One paragraph. The pain, who has it, and why it matters now.

## Vision
One paragraph. What the world looks like when this works.

## Users
The target user(s), stated plainly.

## Features
For each feature:
### <Feature name>
- Core value: the one reason this feature exists
- Behavior: what it does, stated concretely
- Open questions: anything still unresolved

## Out of scope
Explicit list of what we are NOT building, and why.

## Success criteria
How we will know the problem is actually solved.

Elaborating a PRD into user stories:

Here is a PRD. Do not generate user stories yet. First interrogate it:
list every gap, contradiction, and missing edge case a developer — or
an agent — would have to guess at, and ask me to resolve them one at a
time. When there is nothing left to guess, elaborate the PRD into
tightly scoped user stories grouped into sprints, in the Jira style,
using exactly this structure for every story. Acceptance criteria must
be concrete enough that a delivery-side LLM could build from them
without asking a single question.

## Sprint <n>: <sprint goal>

### Story: <short title>
As a <type of user>, I want <goal> so that <benefit>.

Acceptance criteria:
- Given <context>, when <action>, then <expected result>
- Given <context>, when <action>, then <expected result>

Out of scope for this story:
- <explicitly excluded behavior>

Dependencies: <stories or decisions this depends on, or "none">