Dako's AI Builder Notes
⌘K
中EN
System
Color theme
Changsha HubOffline
大可 Dako
大可 Dako大可 DakoAI Builder · Agent PractitionerTurning AI into working software. Practical notes on agent engineering, vibe coding, and commercial delivery.
Platform links coming soon
Scope is one of the most important product decisions01One-line positioningFor whom, what core problem, how far02Not-doing listState what you won't touch, stopscope creep03Acceptance standardWhat counts as done, written into thespec✓ The earlier you draw the boundary, the less it costs and the closer to usable
The earlier you draw the boundary, the less you rework later.

One-Line Positioning + a Not-Doing List Draw the Boundary

A good AI product starts narrow: one line that says what it is, and a clear list of what it won't do. Scope is a product decision.

A lot of vibe coding projects fall apart not because the code is bad, but because the boundary was never clear from the start: AI does a bit of this and a bit of that, and it becomes a hodgepodge nobody is happy with. A good product starts narrow.

After reading, you should be able to answer:

  • How do you write the one-line position to capture the core answer?
  • Why does the not-doing list actually help you do it right?
  • How does scope become a verifiable completion standard?

One-line positioning

Say what you're building in one line—for whom, what core problem, how far it goes. If you can't write it, or it keeps changing as you write, you haven't thought it through yet.

Good positions look like this:

  • "An AI tool that helps product managers turn a requirement into an executable spec fast" → for whom, what, how far
  • "A CLI that refactors one class of repetitive code into a clean form with one click" → for whom, what, how far

Only pass this first gate when you can say it out loud. If you can't, don't jump into vibe coding yet—force the sentence out first.

The not-doing list

Scope and "what you won't do" are two sides of the same coin. Actively write a not-doing list; it stops project drift better than passively adding features.

A few common examples:

  • No login; build the core feature first
  • No multi-user collaboration; single user first
  • No analytics yet; get the main flow working
  • No mobile; desktop first

Every "won't do" is a product trade-off—you're answering "what's this project's center of gravity right now."

How scope becomes an acceptance standard

Just saying "I'll build an X" isn't enough; give a concrete, verifiable completion standard:

  • What the user inputs → what the system outputs
  • Which cases must work → pin them into tests
  • Which boundaries are out of scope for now → write into the not-doing list so they don't drag you in at the end

Write the scope as a one-page spec, and only then let AI start building. Do this well, and every later vibe coding conversation has something to hold onto—AI drifts far less anthropic-sdlc.

With scope settled, move into the heart of this section: turn scope into a contract AI can rely on.

References

  1. The AI-Native SDLC Playbook (Anthropic)