Vibe Coding for People Who Can’t Code: A five-part series. Part I — What it is, why you’d bother, and what you’d build

I last wrote code in 1980 on a TRS-80 or a Commodore 64, I forget which, but alas it doesn’t matter! Over the last two months I built three pieces of software. One of them has over 40,000 lines of code that I’ve never seen.

• A grocery list. My family emails whatever they need to an address, in whatever words they feel like using, and it deduplicates, sorts everything into aisles, puts the list on a page, and makes it easy to x items off the list while shopping.
• A professional relationship management tool. Everywhere a professional relationship leaves a trace — email, calendar, LinkedIn, a decade of archived mail — pulled into one searchable picture. Hand it a conference guest list, get back who I actually know, should know, or know people like. Everything I want LinkedIn to be and would pay for…but it doesn’t do.
• Bedrock.guide. A civic values quiz that gives you a profile and four tools built off it. Live on the internet, for anyone.

The point of this series isn’t for you to build these. They’re mine; they fit my life; yours will be different. They’re here as worked examples — what each cost, what it taught, and what I got wrong, which turns out to be the useful part.

This is the longest series of posts I’ve ever written. It’s designed for the “Vibe Code Curious” — especially people in business and leadership roles — and each part moves the difficulty somewhere you didn’t expect it to be. You think the hard part is writing the code. It’s deciding what’s worth building. You think setup will be technically over your head. It’s mostly tedium, and the danger is quitting. You think building means writing; it means specifying. You think bugs announce themselves; the expensive ones look like success. And you think doing this at work is the same as doing it at home; it isn’t.

Before anything else: three people made this better. My Markup AI colleagues Martin Hempstock and Shawn Nussbaum, and my friend and fellow nontechnical vibe coder Andrew Winston helped me shape this. Two of them turn up inside the series — Andrew co-authored pieces of this, and his tool is one of my examples below, and Martin is most of Part V. They were subjects before they were readers.

What “vibe coding” actually means

That’s the easy part. It’s natural language coding. You describe what you want in plain English, an AI writes the software, you look at what came back and say what’s wrong, and you repeat until it’s right. That’s the whole loop. Yes, it’s that simple. But…it’s not.

What it does not mean is that you get to not understand what you’re building — that misconception is why this is five parts and not a paragraph. The code is free now. The thinking isn’t.

One distinction runs underneath the whole series, and it’s worth naming once. Simon Willison draws a line between vibe coding — where you don’t read the code, you judge the thing by whether it works — and agentic engineering, where someone actually reads the code and owns its quality and security. Vibe coding is genuinely great for something only you will ever touch. But the moment other people’s information is involved, you’ve quietly promised a standard of care you aren’t meeting, because they assume a professional built it. This series is mostly about vibe coding, honestly labeled. Part V is where that promise comes due — and where the answer turns out not to be “go learn to engineer” but “build the safe place.” Simon’s articles on this are here and here and both worth reading if you are serious about this topic.

Why bother with vibe coding

Four reasons, in order of importance.

Return on investment. Something you already do, done faster or cheaper. Real, but the least interesting reason, and I’ll be honest that most first builds don’t pay for themselves in hours saved.

The previously unimaginable. Software used to get built only for markets big enough to justify a team. If the thing you needed had an addressable market of one, it simply didn’t exist. LinkedIn will never sell me the product I want from my own network — nobody else wants it. That floor just dropped to a single person, which is the actually new thing.

A real unfilled need in the world. Classic entrepreneurship, with a much cheaper first step. Bedrock is one of these. The cleaner example is my friend Andrew Winston’s Context Coach — a free Chrome extension that watches how much context your AI is carrying and tells you when a long session is quietly costing you quality and money, with a two-click path to start fresh. Andrew is a sustainability strategist and author, not a developer. The tool came straight out of his own expertise on what AI actually costs in compute and energy: a domain expert saw a gap he was positioned to see sooner than others and could now build the fix himself.

You’ll understand the technology, and it will change how you lead. Reading about AI produces opinions. Building with it produces judgment — about what’s actually hard, what’s actually fast, and what your team is really telling you when they hand you an estimate. That’s valuable if you’re a nontechnical CEO and close to mandatory if you’re a nontechnical CEO of a technology company. This reason alone justifies a weekend even if you throw the result away.

You should skip this if…

• …you’re an actual software engineer
• …you’re so new to AI that you just use it as a souped up search engine and haven’t set up a Claude Project or built an agent yet. But that’s an easy assignment. Go spend half an hour building one of those, then come back here. I’ll still be here waiting for you. 
• …your first idea touches money, legal exposure, health, or someone else’s data, in which case pick something else first
• …what you actually want is to have built something rather than to build it; in that case, go hire someone to do it for you.

What would I build?

The question my friends get stuck on. Here are seven frameworks/concepts so you can hold your own life up against them and see which one fits.

1. Turn messy human input into structure. Freeform in, organized out. (Grocery.) Also: receipts, meeting notes into action items, a chaotic shared inbox into a triaged queue.
2. Unify things scattered across places you already own. (The relationship tool.) Everything you’ve ever written; family records; years of a hobby’s data.
3. Do the tedious thing on a schedule while you’re asleep. A morning brief. A weekly digest. Something that stays silent until one thing changes, then tells you.
4. Apply a judgment you keep making by hand, consistently. You supply the criteria; it applies them the same way every time, which you don’t.
5. Answer questions about a pile too big to hold in your head. Everything your company has published. Four years of board decks.
6. Give other people a structured experience. (Bedrock.) The hardest shape, and the one where the responsibility line bites hardest. Not your first.
7. Fill a gap in the world. (Context Coach.) Finding out whether the gap is real now costs a weekend instead of a funding round.

And notice the delivery shapes differ. Bedrock is a web site. Context Coach is a browser extension — no server, no database, no hosting, it ships through the Chrome store. A whole category of useful thing skips most of the setup in Part II entirely.

Picking your first one

Five quick tests. Something that passes all five is a good first build.

1. You are the user. Non-negotiable — you have to be able to judge whether the answer is any good.
2. It annoys you weekly, not yearly. Weekly means you’ll finish it.
3. You’d be fine if it broke for a day.
4. The information already exists somewhere. If step one is “manually enter four years of data,” it’s a data-entry project wearing a software costume.
5. You can describe it in two sentences. If you can’t, you have a mood, not a spec.

Two things almost nobody says out loud. Make the first one small — smaller than you think; the point of build one is learning the loop, not shipping the product. And expect to rebuild it. You’ll finish and immediately see how it should have been structured. That’s tuition, and it’s cheap now — much better to pay it on a grocery list than on something that matters.

I’ll take my own medicine here. I also thought about building my company’s entire internal operating system as a side project. It got too complicated too quickly for one person and I had to stop. That’s Part V, and I’d have told anyone else not to start there.

The first real fork: can this just be an Agent or a Claude Project?

Here’s the decision most people get wrong before they write a line. The question isn’t “do I want a Project or an app.” It’s: can this be a Project? If yes, it’s a Project. Build an application only when a Project genuinely can’t do the job.

A Claude Project is a workspace where you’ve given the AI your context and instructions once, so you never re-explain yourself. It costs an hour. An app is software running on a computer somewhere that keeps running after you close your laptop. It costs weeks, and it makes you the operations department.

A Project can handle it as long as you’re the only one using it, it only needs to work while you’re in it, everything it needs fits in what you can upload or connect, and what you want back is a conversation, a document, or an analysis. Four things push you over the line into needing an app:

1. Someone else has to use it directly. My family is not going to log into my Claude account to add milk to a list.
2. It has to happen when you’re not there. Projects don’t wake up — no schedules, no triggers, nothing at 6am.
3. It has to build its own memory over time. You can hand a Project files. You can’t have it write down what it learned in March and still be building on that in September.
4. It has to look like something. A form, a page, a button. Everything in a Project is a chat.

Two things people assume that aren’t true. Connectors move the line — a Project can reach your live email, calendar, and files, so “it needs my real data” is not by itself a reason to build an app. And it isn’t either/or: all three of my apps also have a Project behind them. The Project is where you think; the app is where it runs.

Which is where the setup begins — the subject of my next post, and the part nobody writes about, because it isn’t interesting. Expect it to be tedious rather than hard, and expect that to be exactly why people quit. For that part I brought in someone who learned it all from scratch more recently than I did.