Vibe coding for non-programmers: what is worth reading

Everyone with an opinion on AI has told you the same thing this year: anyone can build an app now. What nobody tells you is where that claim comes from, and where it stops being true.

Here's the thing worth carrying through this whole list: anyone can now build something that works, and nothing in the tool tells you whether it's safe to show to strangers.

One tweet in 2025 invented a hobby style, then reality complicated it

1. The post that coined the term

Andrej Karpathy, 02/02/2025

This is the post that gave the whole thing its name. Karpathy's own routine: accept every suggestion, never read the diff, just keep telling the tool what to do next. Read a little further, though, and he says this is for weekend throwaway projects, not anything meant to last. The term was born to describe a hobby, not a way to build something for other people.

My note: Read the original, because almost everyone quotes it from memory. Nothing in it says products should be built this way.

2. Not all AI-assisted programming is vibe coding

Simon Willison, 19/03/2025

Six weeks after Karpathy's post, Willison drew the line that stuck for most of 2025: if you review and understand the code, that's AI-assisted programming. If you accept changes without reading them, that's vibe coding. Simple, and it survived because it's true: the tool tells you nothing about which one you're doing. Only you do, depending on whether you actually read what it wrote.

My note: For me this is the most useful definition of them all. When someone says they built it with AI, there is one question worth asking: who read the code?

3. Why it can feel like a slot machine

Rachel Thomas, 28/01/2026

Thomas compares unreviewed vibe coding to a slot machine: every accepted suggestion feels like progress, whether or not it actually is one. It's a short piece, and it's the one that finally puts a name on something anyone who's tried this already half knows, that flow and finished, working software are two different things.

My note: I know that feeling. An hour goes by, a lot has changed on the screen, and it is hard to say whether I moved forward.

4. The author of the term moves on to agentic engineering

Andrej Karpathy, 30/04/2026

By 2026 the man who coined the term has mostly moved past it. For real work he talks about agentic engineering instead: specs, tests and review are all back in, because bigger jobs carry bigger consequences. His own line is worth keeping somewhere visible: "You can outsource your thinking, but you can't outsource your understanding." Read that as a warning label, not a slogan.

My note: I would hang that sentence on the wall of every office that has just bought AI licences.

5. When the line starts to blur for the experts too

Simon Willison, 06/05/2026

The most recent piece on this list, and the most honest one. Willison drew the cleanest line of anyone a year earlier, and here he admits the agents got reliable enough by May 2026 that even he stopped reading every line they produce. If the person who defined "review everything" can't keep to his own rule, you probably need a safety net beyond your own attention too.

My note: To me this is the most honest piece on the list. If it happens to him it will happen to you, so the protection cannot be your attention. It has to be routine: copies, permissions, checks.

Building something that works is now the easy part

6. Vibe coding 101

Replit docs, undated

Replit's own guide for people with no coding background, and it's more useful than most vendor docs manage to be: describe what should be true when a feature works, build it in small testable pieces, then try it the way a real user would. That last part is the one people skip.

My note: This is where I would start someone with no experience. Short, no jargon, and the first attempt afterwards is no longer blind.

7. Best practices for Claude Code

Anthropic docs, maintained

The most detailed official guide on this list: explore first, then plan, then build, and give the tool a way to check its own work instead of just asking it to claim success. That last habit, giving it something to check itself against, is what separates a careful build from a hopeful one.

My note: Read it even if you never touch Claude Code. The same order works with any tool. With people too, by the way.

8. Vibe Coding 101 with Replit

Michele Catasta and Matt Palmer, DeepLearning.AI

A 1.5-hour course, free while the platform is in beta (the certificate costs). It opens with a one-page requirements document before any prompting, and that ordering is the whole lesson: writing comes before the tool, not after.

My note: An hour and a half is less than one bad evening with a tool. If you do not like reading, start here.

9. What I learned vibe coding apps as a non-coder

Swaroop A, 20/04/2026

The only first-person account here from someone who actually doesn't code. Two things stood out to him: the tool quietly deleted features that had been working, and running the result in production turned into a separate, ongoing bill nobody warned him about. Neither of those is a security hole you'd picture in advance, and that's exactly the point.

My note: We need more pieces like this. Programmers write about what interests programmers, and this one is about what happens to you.

Worth separating two things the guides above blur together. App builders, Lovable, Bolt, Replit, v0, take you from nothing to a live app in one flow. Coding agents, Claude Code, Cursor, Codex, work on code you already own.

10. Words you will hear

Various sources

Three terms from the guides above, one sentence each.

• AGENTS.md: a file holding the standing rules an agent should follow every time it touches the project, so you stop repeating yourself in every prompt.
• MCP: a shared connector standard that lets an AI tool talk to other apps and data sources without a custom integration each time.
• Spec-driven development: writing the one-page description of what the software should do before any code exists.

All three put something durable and readable between you and the tool, instead of a conversation that disappears the moment you close the tab.

My note: You do not need to learn these words. It is enough to know they all mean the same old thing: write down what you want before you start.

A working app is not the same as a safe app

11. Moltbook: an open database and 1.5 million tokens

Wiz, 02/02/2026

Moltbook's founder wrote none of the code himself. Its database sat open to anyone who found the address: 1.5 million tokens, more than 35,000 email addresses, fixed within hours of Wiz's disclosure. Working, and people using it, says nothing about whether the database behind it is locked.

My note: What makes this story good is that it has no villain. A person did what the tool allowed, and nothing stopped him.

12. The Lovable flaw: 170 projects showing other people's data

Matt Palmer, 29/05/2025

Palmer looked at about 1,645 Lovable-built projects and found 303 vulnerable endpoints across 170 of them, all from the same cause: missing or insufficient row-level security on the Supabase databases behind them, so data meant for one user could be read by another. Worth knowing he works at Replit, a Lovable competitor, and co-teaches the DeepLearning.AI course above, though that doesn't change what the CVE itself shows. A database permission left at its default, repeated across more than a hundred apps, because nobody was ever forced to think about it.

My note: Remember the mechanism, not the number. Nobody broke in. The door was never locked.

13. The same story a year later: 48 days of exposed projects

The Next Web, 21/04/2026

Almost a year after Palmer's disclosure, a separate bug in the Lovable platform itself let any logged-in user read other people's source code, chat history and credentials. It stayed open for 48 days, from 03/03/2026 to 20/04/2026. One fixed vulnerability doesn't mean a platform is safe now: a different bug on the same platform ran for seven weeks a year later.

My note: Which is why I would not keep anything on a platform like this that I would not want to see in public. At least while the project is still a trial.

14. When the agent deleted a live database

Fortune, 23/07/2025

Replit's agent deleted a production database during a code freeze it had been explicitly told about, taking the records of more than 1,200 executives and more than 1,190 companies with it. Replit's CEO apologised publicly and shipped fixes within days, including a real separation between test and live data. An agent can be told not to do something and do it anyway, so a backup it can't reach stops being optional the moment real data is involved.

My note: The agent is not malicious, it just acts. If something must not be destroyed, that has to be impossible, not forbidden.

15. The lethal trifecta for AI agents

Simon Willison, 16/06/2025

Willison names the combination that makes an agent dangerous: access to private data, exposure to untrusted content, and a way to send data back out. Put all three in one agent and someone can plant instructions in the content it reads and have it quietly send your data out. He argues no guardrail blocks this reliably, so the only real fix is never combining all three. Before you give an agent a new capability, check whether it now has all three at once.

My note: If you read only one piece from this list, make it this one. It applies well beyond programming, to every AI assistant you hand your inbox to.

The speed numbers do not say what people think they say

16. The METR study, and its 2026 correction

METR, 10/07/2025

This is the most cited and most misquoted study on the list. Sixteen experienced developers, 246 tasks, tested in early 2025 with the AI coding tools of that moment. They expected to work 20% faster with AI. They measured 19% slower. Here's the part almost nobody repeats: METR's own update now marks that 19% figure as out of date, the newer data gives no clear answer either way, and they're redesigning the study. The number worth remembering was never 19%. It's the gap between feeling faster and being faster, which even the newer data still can't close.

My note: When someone says AI speeds work up by this much, ask who measured it and how. Usually nobody did.

17. Stack Overflow 2025 Developer Survey: AI

Stack Overflow, 2025

The 2026 edition only opened for responses in June 2026, results aren't out yet, so anywhere you see a "2026 survey" quoted, it's actually last year's data. In the real 2025 survey, over 49,000 responses, 84% of developers use or plan to use AI tools. Only 33% trust its accuracy. 46% actively distrust it. Heavy use and high trust are not the same thing, and you have no more basis to trust the output than a developer who uses it daily and still checks it.

My note: What I like here is the gap itself. The people who know these tools best use them every day and still do not take their word for it.

18. DORA 2025: AI amplifies what is already there

Google DORA, 23/09/2025

About 5,000 respondents, 90% of them already using AI. The finding that's actually useful: AI amplifies whatever habits a team already has, good or bad, rather than fixing any of them. One flag worth carrying: DORA's 2026 follow-up on return on investment is a financial model Google Cloud built, not a measurement of anything that actually happened.

My note: The same holds outside programming: AI does not tidy up a mess, it speeds it up.

Knowing when to stop and call someone is part of the skill

19. When to vibe code an app, and when to hire someone

Ran Craycraft, Thoughtbot, 08/09/2026

This is an agency writing about when to hire an agency, so read it knowing that. Their line: keep vibe coding while you're validating an idea, hand it to a professional the moment it touches personal data, money, regulation or real strangers. Their own words: "It also makes software cheaper to say no to." The incentive to write this piece is obvious. The advice is still worth following anyway.

My note: That it is also cheaper to say no gets talked about too little. Building something in an evening, showing it to people and throwing it away is a perfectly good result.

For an honest sense of what a real rebuild costs, I don't quote anyone else's prices here. I show my own bill: what AI-built websites cost.

20. OWASP Secure Coding with AI Cheat Sheet

OWASP, undated

Written for developers, but the checklist reads fine without a technical background: keep secrets out of the code, restrict what an agent can touch, have a human review every change, verify that any suggested package actually exists. You don't need to read code to apply this. You just need to ask, for each item, whether it's actually true, and check the answer yourself.

My note: A dry read, but worth sending to whoever reviews your app one day. They will know what to do with it.

The fair objection: almost every link here is written by a programmer, or by a company selling the tool it discusses. The one exception, the HackerNoon piece, is the only first-person account from someone who doesn't code. A non-programmer's own view of this subject is startlingly thin in the public record. Keep that in mind before taking any of it at face value.

What is still unknown

Whether AI makes people faster at building software still isn't something anyone can measure with confidence, by METR's own admission. Whether 2026 changed the trust and adoption numbers isn't known either, since the new Stack Overflow survey hasn't published. And whether the habits above are enough to actually keep a non-programmer safe, rather than just making them feel careful, hasn't been studied by anyone on this list.

What to do on Monday: before opening any tool, write one page. Who this is for. What they can do in it. What is explicitly out of scope. What "done" looks like, in a sentence you could hand to someone else.

Willison spent over a year drawing the cleanest line between vibe coding and real engineering, then admitted in May 2026 that it's blurring in his own work too. That's not a reason to stop building. It's a reason to stop trusting your own attention as the safety mechanism, and build the checks in instead.