2.2.3 - Understanding the Shape of the System

System shape

Is the system shape clear?

The call

Map the boundaries before building across them. Otherwise AI helps you connect parts that should have stayed separate.

Why it matters

Understanding the shape of the system means making boundaries visible before complexity spreads. AI can generate implementation options quickly, but human judgement decides which path preserves reliability and clarity for users. The difference is between a system that scales with confidence and one that accumulates hidden risk.

Explainer

System shape is not an abstract architecture diagram. It is the practical boundary between parts, the dependencies they carry and the handoffs that matter. Until you can name one boundary, one dependency and one handoff between parts, design decisions stay fuzzy. AI can help sketch architecture, but it cannot decide which boundary reduces risk in your system.

Make the system shape concrete

Compare the broad version with a version you can actually test.

• Too vague: The system has a few services that connect together.
• Concrete enough to test: The frontend handles the search interface and user context. The Worker orchestrates auth checks, database reads and AI search calls. The database stores preferences and history. Auth is handled externally. Each part has one job and one clear handoff to the next.

The second version lets two people draw the same core boundaries from it.

Check the system shape

• Pass: You can say which part owns what, what each part depends on and where the important handoff happens.
• Fail: If architecture still means a rough stack or a list of services, the system shape is not clear enough yet.

Do not move into system design or implementation work until this passes.

How to use AI for the system shape

• AI chat: Rewrite the system shape until you can state all three parts clearly.
• vibeCoding: Build the thinnest flow that tests this system shape in practice before broader build work.
• AI-assisted coding: Carry the same system shape into implementation and review so the live system keeps the same decision.

Sharpen the system shape

Copy this prompt into AI chat, replace the bracketed lines with your real system shape and keep the instruction exactly as visible here.

You are checking whether this system shape is clear enough before you move forward.

Constraint:
The system shape must be specific enough that two people would draw the same core boundaries from it.

Working draft:
Part or boundary: [which part owns what]
Dependency or handoff: [where the important dependency or handoff happens]
Ownership boundary: [what each part should not own]

Task:
Decide whether this system shape is specific enough to guide the next decision. If it is vague, rewrite it so two people would make the same decision from this system shape.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can say which part owns what, what each part depends on and where the important handoff happens.

Return:
- A corrected system shape
- A short explanation of what was vague

Evaluation

Before accepting the result, check whether two people would draw the same core boundaries from it.

Example

To help you work through this, here is a real example. StartWithYourContext is an AI search tool built as part of the vibe2value project. Here is how its system shape was written using the three parts:

• Part or boundary: The frontend owns the search interface and context display. The Worker owns orchestration: auth checks, database reads and AI search calls. The database owns preferences and query history. Auth is external.
• Dependency or handoff: The Worker is the single point where a user request becomes a context-shaped AI search call. Everything flows through it.
• Ownership boundary: The frontend does not call the database or AI directly. The Worker does not store state. Auth does not know about search context.

That system shape is specific enough that two people would draw the same core boundaries from it.

When there is more than one side

Not every product has a single system shape. When a system serves more than one side, each side interacts with different parts of the architecture and a boundary that is clear for one side may be invisible to the other.

Multi-sided worked example

For example, StartWithYourContext has two different views of the system shape:

• Content creator: They see a search box and results. The system shape behind it is invisible. What matters is that context shapes results and the handoff between entering a question and seeing relevant output feels instant.
• Developer: They see the layers: frontend, Worker, database, auth, AI search. What matters is that each layer has one job, clear boundaries and a handoff they can trace through the code.

Both views are real, but they describe different systems. If only one is mapped, the other side’s experience degrades without anyone noticing.

Risk and mitigation

• Risk: Letting system shape drift while features expand, which creates unclear ownership and fragile behaviour under load.
• Mitigation: Define one boundary decision per change and validate it against a real user-critical flow before release.

Key takeaway

Do not move forward until you can say which part owns what, what each part depends on and where the important handoff happens.

Work through this in a workshop

If your system shape is still unclear, bring it to a free weekly workshop. Bring the messy part of your AI-assisted build and leave with a clearer next step. In some sessions, we walk through practical examples on the Cloudflare Workers stack to show how a rough idea turns into something that actually runs.

What do you think?

How are you keeping the shape of your system clear as it grows and how is AI helping you make better boundary decisions?