I’m a marketing manager. I have a journalism degree. The last time I “wrote code,” I was twelve years old, copy-pasting HTML into a Neopets profile page.
Last weekend, I shipped a working app.
It tracks the books my partner and I have lent to friends — who has what, when they took it, and a polite nudge button that emails them after 60 days. It has a login screen. It has a database. It has a working “forgot password” flow. I built the whole thing on Saturday and Sunday, between coffee and dinner, while watching a show in the background.
I did not write the code. An AI did.
This is my honest account of what people are now calling vibe coding — what it actually feels like as a non-technical person, where it genuinely surprised me, and the one moment I almost did something stupid that could have cost me real money.
What Vibe Coding Actually Is (In Plain English)
Vibe coding is building software by describing what you want in normal language and letting an AI write the code for you. You don’t learn syntax. You don’t memorize functions. You type something like “make a login page where users sign in with email and password,” and a tool generates the actual working page.
The phrase was coined in February 2025 by Andrej Karpathy, a co-founder of OpenAI. He described it as “fully giving in to the vibes” — letting the AI handle the code while you focus on what you want it to do.
For most of 2025 it was a niche thing for engineers. By 2026 it’s how my non-technical friends are quietly shipping side projects.
Why I Tried It
I’d been complaining about the book-lending problem for months. Every time we lent a book to a friend, I’d write it on a Post-it. The Post-it would fall behind the bookshelf. The book would never come back.
I’d looked for an app to solve it. Nothing fit. The closest options wanted $4.99/month for features I didn’t need.
A friend who works at a startup told me, casually, “Why don’t you just build it? It would take you a weekend now.”
I laughed. He didn’t.
The Setup (Total Time: 11 Minutes)
I picked a tool called Lovable — one of several apps in this space, alongside Bolt, Cursor, and Replit Agent. Lovable felt the most beginner-friendly because it shows you a live preview of your app while you describe it.
I signed up on Saturday morning at 9:14 AM. By 9:25, I was typing my first prompt:
“I want a simple app where I can log books I’ve lent to friends. Each entry should have the book title, the friend’s name, the date I lent it, and a button to mark it returned.”
Twenty seconds later, a working version appeared on the right side of my screen.
I almost cried. Not from joy — from a strange, slightly destabilizing feeling that something I had assumed was hard had just stopped being hard.
What Surprised Me
1. It understood vague instructions better than I expected.
When I typed “make it look nicer, more like a journal,” it actually did. Cream background, serif font, soft shadows. It made taste decisions I would have made.
2. It made mistakes I could see.
When I asked for an email reminder feature, it generated something that looked like it would send emails — a button that said “Send Reminder” — but nothing actually happened when you clicked it. The AI had built the visual part and skipped the actual sending. I had to specifically prompt: “the button should send a real email through a service, not just pretend to.”
3. It made mistakes I couldn’t see.
This is the part that scared me, and it’s why I’m writing this article instead of just posting screenshots.
The Moment I Almost Did Something Stupid
By Sunday afternoon, my app worked. Login, database, the works. I was about to share it with my partner when I noticed something off.
I had asked the AI to “let users see all the books they’ve lent.” The button worked. But when I tested it with a second account I’d created, that account could also see my books. And edit them. And delete them.
The AI had built a feature that fetched book records — but had not added a check to make sure the person looking at the records was the person who owned them.
If this had been a real app, with real users, anyone could have seen anyone else’s data.
I only caught it because I happened to test with two accounts. If I’d shipped it as-is and posted it on Twitter, I would have leaked the personal data of every user.
I went down a rabbit hole that night and learned that this is the most common security flaw in vibe-coded apps. It’s called Insecure Direct Object Reference (IDOR), and it’s been on the OWASP Top 10 list of web vulnerabilities for years.
I stumbled onto a really clear breakdown of this — and four other risks I hadn’t thought about — in a guide written by engineers at a software firm called Valletta. Their piece, Vibe Coding Explained: What It Is & 5 Risks to Avoid, walks through SQL injection, missing authentication, hardcoded secrets, and outdated dependencies — all in plain language. It’s the article I wish I’d read before my weekend project, not after. If you’re going to vibe code anything that touches real people’s data, read it first.
What I’d Tell Anyone Else Trying This
After two days of building, breaking, fixing, and re-prompting, here’s what I think actually matters:
Start absurdly small. Don’t say “build me a Notion competitor.” Say “build a page with one form that saves names to a list.” Add features one at a time. The AI handles small specific requests beautifully and large vague ones badly.
Test with two accounts. This is the single most important habit I picked up. Anything that handles user data needs to be tested from a second user’s perspective. If account B can see account A’s stuff, you have a problem.
Read what it generated, even if you don’t understand it. I don’t read code fluently. But I learned to skim it for words like password, email, and delete. If something dramatic was happening in the code, I’d ask the AI to explain that section in plain English. It always did.
Don’t ship it to strangers. My book app is for me and my partner. That’s the right scale for a weekend project. The moment you imagine real strangers using something you vibe-coded, the bar shifts dramatically — and the risks I mentioned above become concrete liabilities, not theoretical worries.
Write down what you built. Before going to bed Sunday night, I wrote a one-page document explaining what each part of my app does. Not the code — the features. “The reminder button sends an email through this service.” “The login uses this method.” Future-me, trying to fix something six months from now, will thank past-me.
The Honest Verdict
Vibe coding didn’t make me a developer. I still don’t know what most of the code in my app does. If something breaks, I’ll have to ask the AI to fix it, because I can’t.
But it did something I didn’t expect: it made the gap between I have an idea and the idea exists in the world about ten times smaller. For a problem like mine — a personal annoyance worth zero dollars to solve — that’s enough.
I don’t think this replaces real software engineering. I read enough this weekend to understand that there are good reasons people spend years learning this stuff. The apps that handle your money, your medical records, your private messages — those should not be vibe-coded by someone like me.
But the small, weird, personal problems that aren’t worth a startup? The ones we used to solve with spreadsheets and Post-its and a vague hope?
We can just build them now.
It’s a strange feeling. I’m still getting used to it.
Have you tried vibe coding? What did you build, and what surprised you? Drop a comment below — I want to know I’m not the only one who suddenly has a small empire of weekend apps.
