Home/ Part VI — Practical Vibe Coding Workflows (The Stuff You'll Actually Use Daily)/17. Vibe Coding for Greenfield Projects/17.4 Building the "walking skeleton"

17.4 Building the "walking skeleton"

Overview and links for this section of the guide.

On this page

What a walking skeleton is

A walking skeleton is the smallest end-to-end path through your system that proves the architecture is correct.

It is not:

  • all features,
  • all edge cases,
  • perfect UX.

It is:

  • runnable,
  • verifiable,
  • a base for iteration.
Why it matters

Once you have an end-to-end skeleton, every subsequent change is a small diff on top of a known-good path. That’s where vibe speed compounds.

How to choose the first slice

Pick a slice that is:

  • easy to verify: you can tell if it worked
  • representative: touches each layer at least once
  • low risk: minimal side effects
  • small: doable in 1–3 iterations

For AI apps, a common skeleton slice is:

  • read input → build request → call LLM adapter (even stubbed) → validate output → render

Step-by-step: build the skeleton

  1. Make the entrypoint run: CLI/HTTP returns a placeholder result.
  2. Wire domain function: route input through a core function.
  3. Wire LLM adapter: initially a fake or stub returning deterministic output.
  4. Validate output shape: schema validation even for stub output.
  5. Render output: CLI prints or UI displays.

This gives you a complete pipeline without depending on real model calls yet.

Stub first, then swap in real calls

When you build the pipeline with a stub, you can test everything deterministically. Then you swap the stub for the real model call behind the adapter boundary.

Minimal tests for the skeleton

Minimum tests for SP3:

  • one smoke test that runs the entrypoint with a small input and checks output shape
  • one validation failure test (empty input or too-long input)
  • one “invalid output” test (fake adapter returns bad data; app handles it)

These tests are small but powerful: they protect your pipeline during refactors.

Ship point: “runnable end-to-end”

SP3 means:

  • one command runs the pipeline end-to-end
  • one command runs tests/checks
  • the result is stable enough to iterate on
  • you commit the state

Copy-paste prompts

Prompt: implement skeleton with stubbed adapter

Implement the walking skeleton for this scaffold.

Constraints:
- Keep diffs small and reviewable
- Use a fake/stub LLM adapter (no real API calls yet)
- Add minimal smoke tests
- Output diff-only changes

Prompt: swap stub for real call (still behind adapter)

Now replace the stubbed LLM adapter implementation with a real model call.

Constraints:
- Only modify the adapter module and config
- Add timeouts and basic error categories
- Do not change domain logic or UI layers
- Diff-only changes

Where to go next