Spontaneous vs Deliberate: Two Ways I Vibe Coded

Same builder, same AI coding tools, two very different processes: BeatKeeper was built by following the idea wherever it led, MealPartner by locking the requirements first and then building test by test.

I built BeatKeeper in January 2026 and MealPartner in June 2026. Both were vibe coded, in the loose sense: I described what I wanted to an AI coding agent and steered by results rather than by typing the code myself. What changed between them was not the tooling. It was where the thinking happened: in the conversation with the agent, or before it started.

This post compares the two processes in technical detail, and is honest about what each one bought me and what each one cost. In my earlier post, Agile, Waterfall and the Vibe, I argued for a hybrid in principle. This is the evidence from my own builds.

The two projects at a glance

The projects are different enough in shape that the process difference is not just style; each process suited, and strained against, a different kind of system.

BeatKeeper: the spontaneous build

BeatKeeper started as an idea and a first prompt, not a document; its architecture was discovered in the build and then hardened after the fact.

The idea was simple to say: agents that watch a professional's domain, an editor that picks topics, a writer that drafts, and a checker that catches mistakes. I opened VS Code with an AI coding assistant and asked for exactly that. Here is how it unfolded, technically.

1. Scaffold from a sentence. The first session produced a working pipeline: a Python script that called the Claude API once per role, passing plain strings between them. It ran end to end within a day, which was exhilarating and is the main argument for this way of working.
2. Grow one role at a time. Each new idea became a prompt to the agent: add a regulatory watcher, add a repurposer for short formats, add a visual designer. Each role arrived with its own prompt text inline and its own way of calling the model. The system grew sideways, not by design.
3. Hit the coupling wall. Once there were around eight roles, roles had started calling each other directly and passing loosely shaped dictionaries. A change to the writer's output broke the fact checker downstream, silently. The agent fixed each break locally, which often created the next one.
4. Refactor into the structure it needed. I stepped back and asked for the architecture the system had been hinting at: five layers (Sense, Decide, Produce, Assure, Package) with one orchestrator as the only component allowed to call a role. Typed data contracts checked by mypy replaced the dictionaries. All model calls were routed through one logged client, and prompts were pulled out into versioned files per role.
5. Retrofit quality and rules. Output quality was judged by reading drafts until I built a golden dataset of reference cases and ran evals against it. The non-negotiables, such as citation-enforced claims, mandatory human approval of the topic and of the final pack, no auto-posting, no scraping of login-walled sites, and respecting robots.txt, became pytest tests only after the behaviour already existed.

The finished prototype is disciplined. The path to it was not: a large share of the effort went into restructuring code that had been generated quickly in the first place.

MealPartner: the deliberate build

MealPartner did not get a line of code until its requirements reached version 2.3 with every open question closed; then a coding agent built it in tested slices against that document.

1. Requirements as the product. Several sessions produced only a requirements document. It defined the user (a university student), the conversation flow (pick a food type first: main meal, dessert, cocktail or mocktail; protein and carb questions only for main meals), and the reply rule (show the best-ranked match, then offer more options).
2. Decide what the model may and may not do. The key design decision was a boundary: the code decides, the model assists. Free text is matched in stages, exact then fuzzy then a constrained LLM call, and the LLM only ever returns schema-constrained output. It never writes recipe content or links. That single rule removed most hallucination and prompt-injection risk before any code existed.
3. Write the failure modes down. Confidence tiers decide whether a match is shown, shown with a caveat, or not shown. When nothing fits, the bot says so and logs the request to a ranked queue for the recipe curator; silence counts as failure. These were requirements, so they became test cases rather than afterthoughts.
4. Fix scope and constraints explicitly. One test user, designed for 100+. English only. Allergies and dietary restrictions out of scope. No encryption at rest. Target machine: Windows 11, AMD Ryzen AI, 32 GB RAM, which is why a small local model on Ollama and SQLite vector search, not a hosted stack. The model and messaging layers sit behind interfaces so a hosted LLM or the official WhatsApp API can be swapped in later.
5. Hand off, then build test-first. The finalised document went to Claude Code as the source of truth. Each slice (intent detection, the state machine, filtering and hybrid ranking, confidence tiers, templated replies) started from tests derived from the acceptance criteria, then implementation to make them pass, then my review of the diff.

The first code arrived much later than BeatKeeper's did. Very little of it has had to be rewritten.

Process compared, stage by stage

The difference is not whether each stage happened, but when it happened and what forced it.

Pros and cons

Spontaneous building buys speed and discovery at the price of rework; deliberate building buys correctness and safety at the price of a slow start.

Spontaneous (BeatKeeper)

Deliberate (MealPartner)

When to use which, and what I would do next time

Neither process wins outright; the right one depends on how well you understand the problem and how much damage a wrong answer can do.

Next time I will run both, in sequence, on purpose:

1. Spike spontaneously for a day or two. Vibe a throwaway prototype to learn what the problem really is. Treat the code as disposable.
2. Write the requirements from what the spike taught. Including the LLM boundary, the failure modes and the out-of-scope list, which are exactly what BeatKeeper discovered painfully.
3. Rebuild deliberately. Fresh repository, the document as the agent's source of truth, test-first slices, every diff read.

Since writing this, I came across Lightsprint, a Y Combinator-backed platform that packages much of this hybrid for teams rather than solo builders. A PM, designer or engineer describes a change in plain language, the team agrees on a visual plan grounded in the existing codebase, cloud agents build it in parallel, and everyone clicks through a live preview before the change arrives as a pull request for engineers to review and merge. In the terms of this post, it keeps the speed of spontaneous building while putting the deliberate parts, agreement up front and review at the end, where they belong. If you would rather try this way of working than assemble the process yourself, it is worth a look at lightsprint.ai.

BeatKeeper taught me the first; MealPartner taught me the second. The mistake is using either one for the other's job.