Yiuno

From Zero to Building: How to think about software before you write a line of code

12 min read

From Zero to Building

You want to build software with AI. But you’ve never built software before. This article gives you the mental architecture to think clearly about what you’re doing — so you can direct the AI instead of following it blindly.

Who this is for

You have an idea. Maybe it’s a web app, maybe it’s a tool, maybe it’s a platform. You’ve heard about vibe-coding — a term coined by Andrej Karpathy1 for describing what you want and letting AI write the code. You might have even tried it. It felt magical for ten minutes, then confusing for ten hours.

This path is for you if:

  • You’ve never formally studied programming or computer science
  • You want to build something real, not just follow a tutorial
  • You want to understand what you’re building, not just ship something you can’t explain
  • You plan to use AI as your co-builder, not as a black box

What this article is NOT

This is not a coding tutorial. You won’t write code here. This is a thinking tutorial — it builds the mental models you need before code makes sense. The code comes later, and when it does, you’ll know why each line exists.

Part 1 — Software is a restaurant

The single most useful mental model for understanding software is a restaurant. If you remember nothing else from this article, remember this:

graph LR
    C[Customer] -->|places order| W[Waiter]
    W -->|brings order to| K[Kitchen]
    K -->|gets ingredients from| P[Pantry]
    P -->|sends ingredients| K
    K -->|sends dish to| W
    W -->|delivers to| C

    style C fill:#e8b84b,color:#fff
    style W fill:#4a9ede,color:#fff
    style K fill:#5cb85c,color:#fff
    style P fill:#9b59b6,color:#fff
RestaurantSoftwareWhat it does
CustomerUser (you, in a browser)Sees the experience, makes requests
Dining roomfrontendEverything the customer sees and touches
Waiter / passAPICarries orders in, carries dishes out
KitchenbackendProcesses requests, applies rules, does the work
PantryDatabaseStores all the raw ingredients (data)
MenuRoutes / pagesWhat the customer can ask for

The customer never enters the kitchen. The kitchen never seats customers. The pantry doesn’t decide what’s on the menu. Each part has one job, and they communicate through agreed-upon formats (the order ticket at the pass).

This is separation-of-concerns — a principle introduced by Edsger Dijkstra in 19742 and still the most important idea in software design. When each part handles one thing, you can change the dining room decor without rewriting the recipes. You can switch pantry suppliers without retraining the waiters.

Why this matters for you

When an AI generates code, it’s building parts of this restaurant. If you understand which part you’re working on (dining room? kitchen? pantry?) and how it connects to the others (through the pass), you can evaluate whether the AI built the right thing. Without this model, everything looks like a wall of text.

Go deeper

Open client-server-model for the full explanation of how browsers talk to servers, or separation-of-concerns for why keeping parts independent matters.

Part 2 — The four things every software system has

Zoom out from the restaurant. Every software system — regardless of size, language, or framework — is made of four elements:3

1. Components

The distinct parts. For a web app: the frontend, the backend, the database, any external services (payment, email, maps). Each component has boundaries and a clear purpose.

2. Relationships

How components talk to each other. The frontend sends a request to the backend through an API. The backend queries the database. These connections follow rules — the contract between parts.

3. Principles

The design rules that keep things clean:

4. Constraints

Non-negotiable requirements. “Data must stay in Switzerland.” “The app must work on phones.” “No user accounts.” These shape every architectural decision.

This is software architecture

The four elements above are software-architecture. You don’t need to be an expert — you just need to know these four things exist and think about them before building.

Part 3 — You are not the coder. You are the architect.

Here’s the mindset shift that changes everything:

The orchestrator principle

You don’t write code. You write intent. The AI writes code. Your job is to be clear enough about what you want that the AI builds the right thing — and to understand enough about what it built to know whether it’s correct.

This is harder than it sounds. The common failure mode:

graph LR
    A[Vague idea] -->|build me an app| B[AI generates code]
    B -->|looks impressive| C[You accept it]
    C -->|something breaks| D[You cannot fix it]
    D -->|start over| A

    style D fill:#e74c3c,color:#fff

This pattern is called the rewrite loop4 — AI generates, you don’t understand, you restart. Weeks pass with no progress.

The alternative:

graph LR
    A[Clear intent] -->|written PRD + spec| B[AI generates code]
    B -->|you understand it| C[You evaluate it]
    C -->|correct| D[Ship it]
    C -->|wrong| E[You know WHY]
    E -->|specific feedback| B

    style D fill:#5cb85c,color:#fff
    style E fill:#4a9ede,color:#fff

The difference: you understand enough about the restaurant to know whether the chef followed the recipe. You don’t need to know how to cook — you need to know what a correct dish looks like.

Part 4 — Before you build, write it down

The biggest mistake beginners make: jumping straight to “build me an app.” Developer surveys and practitioner reports converge on the same finding: the single highest-impact practice is writing down what you want before asking the AI to build it.5

This isn’t bureaucracy. It’s clarity.

The document chain

Every project — from a weekend hack to a production platform — benefits from writing things down in this order:

graph TD
    A[Rough idea] -->|what and why| B[PRD]
    B -->|how exactly| C[Technical spec]
    C -->|in what order| D[Plan]
    D -->|one piece at a time| E[Tasks]
    E -->|grounded in all above| F[Code]

    style A fill:#e8b84b,color:#fff
    style B fill:#4a9ede,color:#fff
    style C fill:#4a9ede,color:#fff
    style D fill:#5cb85c,color:#fff
    style E fill:#5cb85c,color:#fff
    style F fill:#9b59b6,color:#fff

You don’t need all six for a tiny project. But for anything that will take more than a day, the first three make an enormous difference:

1. The PRD (Product Requirements Document) answers: What am I building? Who is it for? What does “done” look like? And — critically — what is NOT in scope?

2. The spec translates the PRD into precise behaviour: when the user does X, the system does Y. If input is invalid, return Z. This is the recipe the AI follows.

3. ADRs capture why you chose one approach over another. “We use PostgreSQL because our data is relational and needs Swiss hosting.” These survive between sessions — when you start a new conversation with the AI, the ADRs are still there.

The PRD vs spec distinction

PRD: “Users can browse democratic instruments in their language.”

Spec: “GET /api/instruments?locale=fr returns a JSON array of instruments with French translations, sorted alphabetically, paginated at 20 per page. Missing locale returns 400. Empty result returns 200 with an empty array.”

The PRD says what. The spec says how exactly. You need the PRD before you can write the spec, and you need the spec before the AI can write correct code.

Go deeper

Open prd to learn how to write one, technical-specification for the spec format, or spec-driven-development for the full methodology.

Part 5 — Build the skeleton before the body

You have your PRD. You have a rough spec. Now what?

Don’t build everything at once. Build the thinnest possible version that works end to end — a walking-skeleton, a concept introduced by Alistair Cockburn.6

The walking skeleton

One table in the database. One API endpoint. One page in the browser. The page asks the server for data, the server queries the database, and the result appears on screen. It’s ugly. It has one item. But the entire pipeline works.

Why? Because the hardest part of software isn’t writing individual features — it’s making the parts talk to each other. The skeleton proves they can. Once it walks, everything you build afterward is adding muscle and skin to bones that are already connected.

After the skeleton, build in vertical-slices7 — one complete feature at a time, touching every layer:

graph TD
    subgraph Slice 1
        U1[Page] --> A1[API] --> D1[Database]
    end
    subgraph Slice 2
        U2[Page] --> A2[API] --> D2[Database]
    end
    subgraph Slice 3
        U3[Page] --> A3[API] --> D3[Database]
    end

Each slice is testable. Each slice teaches you something. Each slice is a natural unit for one AI session. This is iterative-development — build, test, learn, repeat.

Part 6 — The spectrum: vibe to spec

Now you understand the landscape, here’s where vibe-coding fits:

graph LR
    subgraph Vibe coding
        V1[Describe what you want]
        V2[AI generates code]
        V3[Accept or iterate]
    end
    subgraph Spec-driven development
        S1[Write PRD + spec]
        S2[AI implements to spec]
        S3[Verify against criteria]
    end

    V3 -->|project grows| S1

Vibe coding is fast, intuitive, and perfect for:

  • Exploring an idea (“could this work?“)
  • Building something tiny in one session
  • Learning how a concept translates to code

Spec-driven development8 is structured, reliable, and essential for:

  • Anything that spans multiple sessions
  • Anything where correctness matters
  • Anything you’ll need to maintain or extend

You don’t need to choose one forever. Start vibe, add structure as the project grows. The learning path naturally moves you from left to right as your understanding deepens.

The key question

Ask yourself: “If I started a fresh AI session right now with no memory of this conversation, would the AI know what to build?” If the answer is no, you need more written structure — a PRD, a spec, ADRs.

Part 7 — The map so far

Here’s everything from this article as a single picture:

graph TD
    SW[Software] --> SA[Architecture]
    SA --> SoC[Separation of Concerns]
    SA --> CI[Contracts]
    SA --> AL[Abstraction Layers]

    SW --> CS[Client-Server Model]
    CS --> FE[Frontend]
    CS --> API[API]
    CS --> BE[Backend]
    CS --> DB[Database]

    SW --> PR[Product Requirements]
    PR --> PRD[PRD]
    PR --> SPEC[Spec]
    PR --> ADR[ADRs]

    SW --> ID[Building Strategy]
    ID --> WS[Walking Skeleton]
    ID --> VS[Vertical Slices]
    ID --> SDD[Spec-Driven Dev]
    ID --> VC[Vibe Coding]

    style SW fill:#4a9ede,color:#fff

Every node above is a concept card you can open for a deeper dive. You don’t need to read them all now. You need to know they exist and roughly what each one means.

What you now understand

If you’ve read this far, you can:

Concepts you've gained

  • The restaurant model — how frontend, API, backend, and database relate to each other
  • Software architecture — components, relationships, principles, constraints
  • The orchestrator mindset — you write intent, AI writes code, you evaluate the result
  • The document chain — rough idea → PRD → spec → plan → code
  • Walking skeleton + vertical slices — build thin, build complete, build iteratively
  • The vibe-to-spec spectrum — when to freestyle, when to structure

Check your understanding

Where to go next

This article gave you the mental architecture. Now choose your path based on what you want to do:

Path A: Build a specific project

You have a project in mind and want to build it from foundations. Use the learning pipeline to turn your idea into a structured learning path tailored to your project. The pipeline walks you through intake, graph matching, and guided learning with comprehension gates at every step.

Best for: People who learn best by building something real.

Path B: Learn the technologies first

You want to understand the tech stack before committing to a project. Work through the concept cards in this order:

  1. client-server-model → frontend → backend → databases
  2. apis → contracts-and-interfaces
  3. iterative-development → walking-skeleton → vertical-slices
  4. spec-driven-development → prd → technical-specification

Best for: People who prefer understanding theory before practice.

Path C: Start vibe coding now, add structure as you go

Jump in with vibe-coding. Build something small in one session. When it starts to feel chaotic, add a prd. When the PRD isn’t enough, add a technical-specification. Move along the spectrum naturally.

Best for: People who learn by doing and get bored by theory.

Sources

Further reading

Resources

Footnotes

  1. Karpathy, A. (2025). Referenced in daily.dev. Vibe Coding in 2026: How AI Is Changing the Way Developers Write Code. daily.dev. ↩

  2. Dijkstra, E. (1974). “On the role of scientific thought.” Reprinted in Selected Writings on Computing: A Personal Perspective. Springer-Verlag, 1982. ↩

  3. Fowler, M. (2003). Software Architecture Guide. martinfowler.com. The four-element framework (components, relationships, principles, constraints) is a synthesis adapted from Fowler’s architectural thinking and the IEEE 1471 standard. ↩

  4. KruN. (2026). AI Code Without Architecture: Why AI Generated Projects Collapse Later. krun.pro. ↩

  5. Osmani, A. (2026). How to Write a Good Spec for AI Agents. addyosmani.com. Also: GitHub Blog (2026). Spec-Driven Development. GitHub. ↩

  6. Cockburn, A. (2004). Walking Skeleton. c2.com wiki. Also described in Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley. ↩

  7. Vertical slicing is a widely used agile practice. See: A Guide to Vertical Slice Architecture in Modern Web Apps. Clean Code Guy, 2026. ↩

  8. Gandhi, V. (2026). Spec-Driven Development and Agentic Coding. The Data Column. Also: GitHub Blog (2026). Spec-Driven Development with AI. GitHub. ↩

Graph View

Backlinks