A refined concept is the product
The most important thing you co-create with Claude is a clean, refined concept of what you’re building: what it is, why it exists, who it’s for, what it looks like, how it behaves, and how it evolves. That concept is the real product. Everything else you ship is generated from it.
One boundary to set before the thesis: the thing you’re building is regular, deterministic software. Claude is the builder and operator, agents included; the product itself runs predictably, reaching for LLM judgment only in narrow, internal places (classifying, summarizing, drafting). Putting an LLM at the center of an end-user product adds problems this course doesn’t cover: sanitizing inputs and outputs, prompt iteration, evals. Deterministic where possible, Claude where valuable.
The thesis
The concept lives mostly in markdown (human-readable and machine-readable, diffable, version-controlled, connectable), with higher-fidelity pieces where words are the wrong tool: diagrams, HTML mockups, clickable prototypes. Claude reads all of it, writes it with you, and generates the artifacts from it.
refined concept
│
├──▶ code
├──▶ design
├──▶ marketing
├──▶ operational playbooks
├──▶ strategy
└──▶ everything else you ship
The “feature” Claude implements was in the spec. The “design” Claude produces extends the concept. The “operational task” Claude runs was described in the concept. When the concept is sharp, the artifacts are sharp. When the concept drifts, every artifact drifts with it.
Fixed core, fluid surface
Not everything in the concept deserves the same rigidity, and one of the most important decisions you make while building is which parts are changeable and which are not.
- Specify rigidly: invariants and core capabilities. The things that must stay true even as the product’s surface changes. What the product guarantees. The capabilities it must always have. The data concepts it’s built on. The hard requirements: compliance, contracts, money handling. Write these down precisely and change them deliberately.
- Specify loosely: manifestations. Screens, layouts, copy, visual styling, and large parts of the implementation. Describe these at whatever fidelity the moment needs and regenerate them freely, as long as the invariants hold.
A redesign that changes every screen but preserves the invariants is routine. A “small” change that silently violates an invariant is the dangerous one. The spec’s job is to make that difference visible.
Specification is a spectrum
The evergreen spec holds the durable core. Around it, specifying happens at whatever fidelity fits the question you’re trying to answer:
- a sentence in a markdown doc
- a user flow as a mermaid diagram
- an HTML mockup of one part of the product, in your styling
- a clickable prototype running on realistic mock data
Most of the higher-fidelity artifacts are temporary. They exist to drive the creative process: see a direction, react to it, decide, and fold the decision back into the durable spec. Markdown stays the backbone because it’s the cheapest medium to write, diff, and keep current, but it’s the base of the spectrum, not the whole of it.
Why this changes everything
Before AI that could reason over text, a product spec was a reference document. Someone read it once, built something, then the doc drifted out of sync. The real work happened in code, in Figma files, in tickets.
With Claude, the spec is operative. Claude reads it on every task. Claude can rebuild code from it, generate design from it, draft ops playbooks from it. The concept stays the source of truth because generating from it is cheap and regenerating is constant.
Three practical implications:
- Invest in the concept disproportionately. If you have a day to put in this week, put it into refining the concept, not into writing a specific file. The file comes out of the concept. Do it five times.
- Version the concept. Track how it changes. That history is the real record of how the product evolved.
- Connect everything to it. Research notes, competitor analyses, user interviews, decisions: all linked to the concept. The more Claude can see the concept and its context, the better it generates.
A corollary worth naming: the models are already more capable than most users know how to drive, and they keep getting better. What matters more and more is the precision of the concept you can articulate.
Two stages, always
The whole of this approach reduces to two stages, applied continuously.
Stage 1: Curate the context. The concept. The data. The rules for engaging with it. The hopes and dreams of what you’re trying to realize. Who it’s for. What it should feel like. This is constantly open, always being refined, revised, extended.
Stage 2: Generate artifacts. At chosen moments, produce the concrete outputs: an application, a report, a PowerPoint, a blog post, a research summary, a data pipeline. Each artifact is a projection of the curated context into a specific form.
You oscillate between the two. Stage 1 is continuous; Stage 2 is episodic. Most of your time goes into Stage 1, even when the visible output is the Stage 2 thing. The output is cheap once the curation is sharp.
If you notice yourself reaching for a shiny new tool to generate a better artifact, pause: the improvement almost always lives further upstream, in the curation.
What the rest of this course is about
The course is organized around this thesis.
- Markdown as the medium: why the concept’s backbone belongs in
.md, and where higher-fidelity media take over. - How Claude works: minimum-viable mechanics so the rest makes sense.
- Building the concept: research, spec writing, context management, skills, connecting sources. The real work.
- Artifacts: code, design, implementation, operations. What you generate once the concept is sharp.
- The harness: Claude Code and its tools, in service of the above.
- Shipping real things: infrastructure and the edges where artifacts meet the world.
- Compounding: how the system gets sharper over time.