session started · tool: any AI app builder · project: room booking for a shared office
Can someone with no coding background build an app with AI?
Yes, you can build a small first version with AI and no coding background. A bank? Give it a few years. What really matters is the order you do things in, and you can see mine below.
- 3 questions to answer in plain English before you type a single prompt
- 1 sentence is all your first version’s user story should need
- 1 change at a time, run and click through after each one
- 0 secrets pasted into a chat window or typed into page code
I teach a course on this, so you’d expect me to be keen, and I am. I’m also fussy about the “I kept asking the AI to fix it until I had no idea what any of it did” way of working, because that’s where most people end up if they just start typing.
So here’s the order I’d go in if I were starting from scratch tomorrow. The preview on the right changes as you scroll. There are three things to play with on the way down (a prompt builder, a secrets switch and a tiny app that goes wrong in front of you), and a sorting game near the end for the question everyone eventually asks: is this a prototype, or do I need a proper engineer?
The ordering advice comes from teaching this, so it’s my view. Every number comes from a source you can open, and they’re numbered at the bottom.
Fully give in to the vibes, embrace exponentials, and forget that the code even exists.
Andrej Karpathy, February 2025, describing the thing he named “vibe coding”1
That’s the fun version. This page is about the version where you still know what you built.
Fine. Why does the order matter? Show me the evidence.
$ run proof –why-order-matters tap a line to open the source
45%of tests, across 100+ language models, produced AI code with risky security flawsVeracode, Oct 2025 66%of developers name “almost right, but not quite” as their top frustration with AI answersStack Overflow 2025 19%longer: how much more time experienced developers took with AI tools in an early-2025 trialMETR 72%of developers said they are not vibe coding. It’s still a minority habitStack Overflow 2025# 4 lines, 3 sources, 0 made up
Mind that third line, though. It came out of a test of 16 experienced developers on 246 issues, and the people who ran it say the tools have moved on since.4 To me it’s a reason to stay in charge of the thing you’re making, not a reason to give up on it.
Step 1. Before I prompt anything, what do I do?
Step 1 · Before you prompt
Write it down first
Open a blank note and answer three questions in plain English, no tech words allowed. Who is this for? What’s the one thing they need to get done? What happens right after they’ve done it?
Then write one user story, a single sentence like “as a [person], I want to [do something], so that [I get something]”. If your idea won’t fit in one sentence, it’s too big for a first go, so chop it down. Lots of people skip this bit because it feels like homework. Don’t! It’s the bit that stops you building a lovely login page for an app with no point.
It takes ten minutes and it’s really worth it. Fill in the boxes and watch the prompt write itself, and then have a look at what most people type, which is about four words long!
The usual prompt
Your prompt
Nothing leaves this page. It’s just a template, and the habit is the point: say who, what, then how you want it built.
Explain how you’d build it first. Then do the booking form. One change only.
Plan: 1) room list, 2) booking form, 3) confirmation. I’ll stop after each so you can test.
Done: two rooms and a name field.
Step 2 · Build
Small steps, and a copy you can go back to
Go back to the tool and tell it what’s in your note. Ask how it would go about building the thing, and make it explain before it builds. If it uses a word you don’t know, ask what it means (it costs nothing and you learn loads!). After that, take it a step at a time. Home screen first, then the form, then whatever happens to the stuff people type in.
Run it after every change and have a good click about. Working? Save a copy (most tools do that for you, or use Git if you’ve met it). Broken? Go back to the copy, don’t stack fixes on top of fixes. It’s the loop below, and it’s a small habit that saves loads of evenings.
Even the people who write code for a living feel this. Asked what annoyed them most about AI, 66% of them said answers that are “almost right, but not quite”.2 Almost right is exactly what you catch by running every change, so run it every time!
Which tool? In the browser, or on my own computer?
Step 3 · Choose
Browser or your own computer?
Browser builders, Replit for example, are just a web page. Nothing to install, and you could have something running within the hour. A tool that lives on your own computer, like Cursor, gives you more say over the files, but it takes a bit more patience before it feels comfortable. I’d go with the browser one for a first project, and swap later when you know what you’re missing. Tap each side to see what you trade.
Fast to start
- Nothing to install
- Runs, saves and shares from one tab
- Less control over the files underneath
Example from our teaching stack: Replit.
More say over the files
- You see and edit the whole project
- A bit more patience before it feels comfortable
- Good once you know what you’re missing
Example from our teaching stack: Cursor.
Either way you’re building software, and that’s the bit the “no-code” label hides. We’ll cover projects, files and version control in session two of our course, in plain English.8
It wants an API key. Can I just paste it in here?
Please don’t. Add it under Secrets and I’ll read it from the environment.
Step 4 · Careful
Keep secrets out of your prompts
You’ll have things that work like a password, such as an API key or the login for your database. Never paste those into a chat window, and never type them into the page code itself, because anyone can read that with a right-click. Your tool will have a secrets area (some call it environment variables), so put them there.
The browser builder I mentioned has a Secrets tool. It locks your keys away and just hands them to the app while it runs, and the docs are very blunt about it: “Do not store API keys, passwords, or authentication tokens as configurations.”6 Most of the others work in much the same way. Flip the switch to see what a visitor can see, and watch the badge in the preview too.
// app.js
const key = "sk-live-9f3a...27c1";
const key = process.env.API_KEY;
fetch(url, { headers: { key } })What a visitor sees with right-click, View source
Your key. Anyone can copy it.
No key in sight.
Looks great. Ship it?
Not yet. You’ve only seen the happy path. Press each state in the preview.
Step 5 · Before you share
Test the boring screens
These tools love the happy path and forget the rest. So before you show anyone, open your app with nothing in it and see what a brand new user gets. A blank screen and no hint of what to do next? Fail, I’m afraid. Then slow things down. Does anything tell you it’s loading? Nielsen Norman Group call this “visibility of system status” and it’s number one on their list of usability heuristics: “The design should always keep users informed about what is going on.”7
After that, try to break it. Send a form with nothing in it, type rubbish into the email box, and switch your wifi off halfway through. Number nine on that list says error messages should be “expressed in plain language (no error codes)”, which is a bit of a relief when it’s your mum who sees one.7 Press each state and see which version you’d rather meet.
Preview controls
Then pick up your phone and try it there too, because that’s where plenty of your users will be.
Last question. Do I need a real engineer?
The grown-up bit
Prototype, or call an engineer?
Does your app touch money? Medical details? Anything where a leak would hurt real people? Then get a proper developer in before it goes live. Sort these six ideas. My rule of thumb is that a prototype is something real people can try, and I’d still pay a human to look over anything people will trust with their data.
Pre-deploy review
There’s a standard list of the worst web security problems, and the one at the top is “Broken Access Control”, which just means people seeing or doing things they shouldn’t.5 Security testers also found that AI code came with flaws in 45% of their tests.3 Read that list once and you’ll see why “it seems to work” isn’t the same as “it’s safe”.
OK. What do I do today?
todo.md Try this today: cut your idea down to one sentence
Tick them off as you go. Your progress stays on this device.
So what’s the idea? Have a go at writing it as a sentence and see if it fits! Then you can read our app development for startups post, if you’d like the bigger picture.
Deploy (this one is ours, and it’s an invitation)
$ deploy –course vibe-coding-ai-app-development
- build Vibe Coding: Build Websites & Apps with AI
- lessons 6 lessons over 3 weeks, part-time evenings
- when Tue & Thu, 6pm to 9pm
- group small group, live in Bangkok or live online
- needs no coding first. Carl created the course and teaches it
- result a working product on a live web address
Funnily enough, that’s why I made this course, for people who’d like someone sat next to them. We start with the problem, not the prompt, and then we build the screens together. We add saved data and user accounts, and we break the thing on purpose so you can see how to fix it. By the end it’s live on a web address of its own, and you’ll know what you can build yourself and when to ring an engineer.
Deploy: see the coursesources.lock
Where the numbers come from
- Vibe coding. Wikipedia. Coined by Andrej Karpathy in February 2025; “fully give in to the vibes, embrace exponentials, and forget that the code even exists”.
- 2025 Developer Survey: AI. Stack Overflow. 66% top frustration “almost right, but not quite”; “Most respondents are not vibe coding (72%)”.
- 2025 GenAI Code Security Report. Veracode, October 2025 update. Risky security flaws in 45% of tests, 100+ models.
- Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. 16 developers, 246 issues, 19% longer with AI; METR notes the tools have since moved on.
- OWASP Top 10:2025. OWASP. A01 Broken Access Control. (Project page.)
- Secrets. Replit Docs. Encrypted, exposed to the project as environment variables.
- 10 Usability Heuristics for User Interface Design. Nielsen Norman Group. Heuristics 1 and 9; last reviewed January 2024.
- Vibe Coding: Build Websites & Apps with AI. Web Courses Bangkok course page: session outline and “what this course does not promise”.
