Non-Vibe Coding: How to Build a Real App in About Half an Hour

#vibecoding #ai #programming #coding

Vibe coding gets a bad name because of bad prompting and lack of planning. So this is non-vibe coding.

Non-vibe coding is the lightly structured version: you spend five extra minutes thinking before you let the AI loose, and you end the half hour with something that actually ships.

We built Pizza Dealers, a Dope Wars clone themed around pizza, with a deterministic 6-hour market seed and a local leaderboard in roughly 30 minutes using this workflow out of a vague idea.

The framework (5 steps)

Take a half-formed idea to an AI cofounder. Tell it to ask supporting questions until you have a design doc.
Have it write a file (in this case we called it AI.MD but it doesn't matter what it's called). This is the briefing your coding agent will actually read.
Make a GitHub repo and drop the AI.MD in it. Use the desktop client. Anyone who needs CLI instructions for this already knows how to use git.
Hand it to a coding agent and let it ask more questions. Then tell it to execute the plan in phases, testing each one.
Ship it on GitHub Pages. Ask the AI to write the GitHub Action.
Steps 1 and 2 are the parts most people skip. They're also the difference between vibe coding and the structured version.

Step 1: The cofounder conversation

Open whatever free general-purpose chatbot you prefer. I used DeepSeek on Expert Mode with DeepThink on, but Claude, Gemini, ChatGPT all work.

I need you to act like a co-founder.
Please help me flesh out this into a design document. Ask supporting questions. Let's get this to a state where I can give the file to my coding agent to execute the plan.

Then I described the idea: a game like Dope Wars, themed around pizza (because some models hesitate to play along with the dope wars mechanics I thought pizza would be a safer rebrand). Web-based. 6-hour market seeds shared by all players. Three-letter score entry like an old arcade. That was it.

The AI came back with a list of questions: how many pizza types, do you want a map, do you want random events, how does the run end, leaderboard scope, hosting preference. These are mostly "just like Dope Wars" decisions, not architectural ones. I answered each.

It suggested React + a serverless backend "for the leaderboard." For a single-player game with deterministic prices. I pushed back.

I would rather not need a server just to serve a price list. Could this not be done without a server? It seemed like overkill when I could post this on GitHub Pages. We landed on pure-static with browser local storage.

Step 2: The AI.MD file

Once the design doc feels complete, ask the AI to write an AI.MD you can hand off. This is your project brief, it tells the coding agent what to build, what stack, what the rules are.

One thing that happens from time to time, when the AI generates the markdown file in the chat, the rendered preview will look fine but the underlying text gets cut off by the chat's markdown renderer.

Copy the raw output into a plain text file, look for stray opening tags or missing closing fences, clean it up by hand.

Step 3: The repo

GitHub Desktop. New repository → name it → MIT license (if you're feeling generous) → publish. Done.

The desktop client has a "Publish" button. If you need command-line instructions, you already know how to use git and don't need me to write them.

Drop the AI.MD file in the repo, commit, push. You now have a versioned home for your project. While you're there, ask your coding agent (next step) to make you a .gitignore and add anything sensitive: API keys, .env files, local build artifacts. Anything you don't want up on github.

Step 4: Hand it to the coding agent

Open your favorite agent-capable editor. I used OpenCode with Kimi K2.6, but Claude Code, Codex, Antigravity. Anything will work pretty much as long as the model can call tools. Open the repo folder.

Then the prompt:

I am building a game like Dope Wars called Pizza Dealers. Ignore any other name in the document. Read AI.MD. Are there any potential improvements? Ask supporting questions, please.

"Ignore any other name in the document." During the cofounder phase, the AI may have called your project something else (mine started life as "Pizza Wars" before I changed my mind).

"Ask supporting questions." Same as before you want the agent to surface ambiguity right away
.
Kimi came back with refinements for deepseek's plans, with a volatility profile per pizza type so prices don't all move together, weight-based inventory caps instead of a hard count, event scoping rules. I answered the questions, told it to update AI.MD, and off it went.

Kimi scaffolded Vite + React + Tailwind, installed dependencies, wrote the game logic, the seeded RNG, the leaderboard, the social sharing, the GitHub Action for deploying to Pages. It even wrote the deploy workflow without me asking explicitly.

Step 5: Ship it on GitHub Pages

Push the code. In GitHub: Settings → Pages → change source to "GitHub Actions."

The first deploy failed for me. Big red X on the GitHub Pages section. I clicked into the action, copied the entire error log, came back to OpenCode, and pasted it with one line:

GitHub Actions failed, I pasted the error to Kimi, who diagnosed that package-lock.json hadn't been committed and gave me the fix. After a commit the action passed and the site was live.

Note: GitHub Pages with the free github.io URL only works for public repos. Private repos require a paid plan.

Common Pitfalls

Truncated AI.MD files when copying from chat. Clean up the raw text, look for obvious issues.

AI proposing infrastructure you don't need. Servers, databases, auth, queues. Push back if you need to. This is especially true when it falls into patterns of corporate sales that it has picked up in training. 


Phase your testing. "Execute phase 1, then stop so I can test." Don't let it write the entire app and leave you with one giant npm run dev to debug.