The Brief Is the Product

14 April 2026

I started the way most people do. A Claude chat for planning, Cursor for writing the code. I'd spend time discussing the spec, refining requirements, and then have Claude produce a prompt I could paste into Cursor. New chat, new agent session, start fresh each time. For the first week or so, it worked well enough.

Then a few things happened simultaneously.

As the project grew, I noticed a shift in quality. Not dramatic — just going from prompts executing with zero bugs to finding something slightly off. I also found it increasingly cumbersome to sift between the original prompt and the output. I wanted to be able to inspect what had been asked after the fact, not just what had been delivered. Around the same time I moved from Cursor to Claude Code, which suited how I was working better.

So I made a simple change. Instead of pasting prompts into a chat, I started having Claude write the prompt as a markdown file inside the project folder, named to match the work item reference from my backlog. Then execution became a single instruction: git pull, read and execute the prompt at this location.

What I didn't anticipate was what would happen to the prompts themselves.

Without being asked, they started including schema details, API design decisions, patterns, architectural reasoning. They read like a brief written by a principal engineer to hand off to a senior engineer. The planning sessions started taking a bit longer, but the execution became remarkably clean. I went from debugging minor issues in every session to trusting the deliverables. The AI assistant feature in my current project went from zero to working MVP in two prompts, and polished in another two.

The difference between an early prompt and a later one is striking in retrospect. Prompt 4 — an expenditure import API — is roughly a page: context pointers, a task description, some implementation notes, basic tests. It's a spec. Prompt 32 — the AI assistant frontend, built about six weeks later — runs to several pages. It lists what's already built and must not be touched. It specifies state management patterns, SSE streaming behaviour, mobile keyboard handling, empty states, error codes, and a twelve-point verification checklist. I didn't write most of that detail deliberately. It emerged from the planning conversation, because by that point the model understood the codebase well enough to think about the things I'd forget to mention.

That's the shift. Early prompts are specs you write. Later prompts are briefs the system produces.

I asked Claude directly whether the prompt files actually help. The answer was honest and more interesting than I expected. Reading a structured file before execution — with objective, constraints, schema, patterns, acceptance criteria all stated upfront — is fundamentally different from a conversational session where context accumulates gradually and gets inferred from the shape of the exchange. Named references help. Written constraints stated before execution mean they're not discovered through failure. But the most useful thing Claude said was this: it probably doesn't matter whether the file helps the model technically, because the discipline of writing it helps you. You're resolving ambiguity in writing before it becomes a bug in code. That would have been true with a human contractor too. The AI is almost incidental to that insight.

What I think happened is that having a prompt file as an artifact changed the nature of the planning conversation. It wasn't a discussion that disappeared into a chat history. It was a document with a reference number, sitting in the project, available for retrospective inspection, legible to both a human engineer and to the model on the next session. When I have to iterate or fix a bug now, the model gets context in a way it didn't before.

The other thing it solved, which I didn't expect, was the iteration loop on planning and design. Claude would generate the prompt, I'd review it, and that would trigger a question or a missing detail. We'd refine it. Then I'd review again. The prompt became the site of the design work, not just a delivery mechanism for it.

My role in all of this is harder to name than I expected. Product owner, yes. But also the person asking why certain choices were made, occasionally pushing back when something feels off, running architecture reviews, checking for consistency. Claude Code on the server is my delivery team — engineers and testers both. Claude Chat is my solutions architect, principal engineer, and technical writer. Sometimes designer, sometimes product researcher.

That means I'm not just a product owner either. I find myself operating as CTO and VP and principal, interjecting at different points in the process for different reasons.

What I've ended up with is a way of working where the brief is the product. The conversation is for thinking. The file is for doing. And the gap between what I can conceive and what I can actually ship has closed in a way I wouldn't have believed eighteen months ago.

I haven't figured out all the implications of that yet. But I'm pretty sure it changes more than just the development workflow.