Vibe Coding: How I built an app with zero experience in coding
Four months ago I started vibe coding with basically zero background in code.
Today there's, FKE , one web app out there with real people using it (and some really kind feedback), and I'm deep into building a second one.
I never sat down and learned to code first. What I actually learned was how to get AI to do the work with me.
The fun part is the vibe; the leverage is the system around it. That's what I keep building — and lately it's turned into two real projects.
Most people aren't stuck for lack of an idea. They're stuck on one sentence: "I'm not that kind of person." You don't have to know how to code before you start,
You learn by doing. Begin, then figure it out and fix it as you go.
If you're standing at the door the way I was four months ago, here's what worked for me.
1. Start with the free version. Don't pay yet.
Begin with a chat AI. Ask it about things you already know, so you can watch how it thinks. Change how you ask, and notice how the answer changes.
The best prompt isn't the longest one. It's the one where you understand what the AI is doing for you, and the AI understands what you're actually trying to do. That's just analytical thinking.
2. When you're ready to pay, go monthly first.
Don't lock into annual, however tempting the discount. Models change fast — a bit like phone carriers and their promos.
I started on Claude Cowork; then ChatGPT handed me a reset and a free month of Plus, so I moved over to try it (I'm easily won over). No tool has to be your forever home.
What matters more is making your work easy to move.
I keep each project's context and progress in a .md file, so when I switch tools I just hand the new one the file.
Tools can change; your work shouldn't lose its memory along with them.
This is the prompt I use to package a chat into that file:
Read our entire conversation above and turn it into a single handoff document
so a brand-new AI session can continue this project with zero context loss.
Write it as clean Markdown with these sections, in this order:
1. Goal & Definition of Done — what we're building and how we'll know it's finished
2. Current State — what's done, what's in progress, what's broken
3. Decisions Made (and WHY) — so the next session doesn't re-open settled choices
4. Constraints — tech, tools, budget, time, my skill level
5. Key Code / Artifacts / Links — only what's needed to keep going
6. Open Questions — what's still undecided or unverified
7. Next 3 Steps — the exact things to do next, most important first
Rules:
- Be specific. Prefer concrete names, values, and file references over summaries.
- If something important is missing or unclear, list it under Open Questions instead of guessing.
- Output everything inside ONE Markdown code block so I can copy it in one click.
- No preamble, no sign-off, no filler.3. Live in the communities.
When you're stuck, just ask. Don't worry about looking like you don't know — the question you think is too basic is usually one plenty of people have hit too.
The Claude and Codex communities I'm in are the kindest I've found; people answer properly, and sometimes someone even DMs me to explain more.
Being there also shows you where "possible" currently sits: what others are building, where they get stuck, what workflows they use, and things you'd never have thought of on your own. Some people give their prompts away, too. (I gave mine away as well — the ones for KOS and MiroFish.)
4. Tell the AI what you want, plainly.
Want a website? Say what kind. You don't need to know the framework, the database, or the architecture first (if you can even type those three words, you're already further along than I was).
Your first job isn't picking technology. It's being clear about:
Who will use this, what problem they have, what it needs to do, and what "actually works" would look like.
If you're not sure how to begin, copy this into the AI first:
I want to build: [what you want to build]
Who will use it: [who]
The problem I'm solving: [problem]
The main things it must do: [3–5 things]
My constraints: [time / budget / knowledge / tools I have]
What I don't know yet: [e.g. I don't know what system this needs]
Before you propose how to build it:
1. Ask me the questions you genuinely need answered first — don't write code yet.
2. Restate the problem in your own words so we're sure we agree.
3. Propose the smallest working version — where should I start?
4. Break the work into small steps I can check one at a time, and tell me how I'll know each step is "done."
5. Warn me any time a step touches payment, personal data, or security.
Explain it like you're talking to someone with no coding background.The clearer you are about the goal, the constraints, and a concrete example, the closer it gets to the thing in your head — and you build out from there.
5. Read. Read until your eyes give out.
This is probably the part people like least. When the AI sends back a wall of text, don't just hit accept. Read what it's doing, why, what changed, and whether it's still going where you wanted.
You don't need to understand every line like a developer — just enough to know the work hasn't wandered off.
Vibe coding doesn't mean "tell the AI and let it do everything." You're holding the reins — nudging, sometimes prodding, to keep things headed where you meant. And anything that touches payment, privacy, or security, audit it often.
AI isn't a replacement for what you know. It's a multiplier on it.
I don't think vibe coding replaces developers.
People with a dev background have the edge on architecture, debugging, security, and keeping a system alive over the long run — I'm not pretending to match that. But coming from outside tech has its own edge. I was a user first, so I know the pain points from the inside. I just have to be patient, ask a lot, read closely, and keep testing and fixing (stubborn effort, mostly).
In a world where anyone can ship an app, the difference might not be who writes the best code. It might be:
Who understands the person they're building for well enough to know what's worth making — and whether the thing they made is actually good enough for real life.
If someone's already built a good app, honestly, just buy it — they've done the hard part for you. But if the thing you want doesn't exist yet, or it does and it's not quite to your taste, you can make your own. Same noodle shop, and people still season their bowls differently. 🍜
Hope you have fun finding your own way to vibe.
If this made you want to build your own small systems, that's exactly the muscle behind what I'm shipping. Wealth Tracker for money decisions, FKE for learning French — same approach, two applications. Follow whichever one fits you.
Comments