I Tried Vibe Coding for Two Weeks. It Worked Until It Didn't.

Andrej Karpathy — OpenAI co-founder — posted about this in early 2025 and the term stuck. The idea is simple: describe what you want in plain English, let the AI write it, run the output, tell the AI what's off, repeat. You're not reading every line of code. You're steering by whether the thing works.

"Fully give in to the vibes, embrace exponentials, and forget that the code even exists," he wrote. That is either exciting or reckless depending on who you are. I thought it was reckless. I decided to test it anyway.

I've been using Cursor for a while. For two weeks, any new side project or internal tool — vibe coding only. Don't write code unless absolutely necessary.

First project: a script to take a messy folder of photos, read the date from each file's EXIF data, rename the file to that date, and move it into a year/month subfolder. I've wanted this for ages and kept putting it off because EXIF parsing in Python has options and I always forget which library.

I described it in plain English in Cursor. It wrote the whole thing. I ran it on a test folder of 10 images. Six worked. Four failed on files that didn't have EXIF data — the script just crashed on those instead of skipping them.

Told Cursor: "it's crashing on files without EXIF data, should skip those and log them instead." One iteration. Fixed. Ran it on the full folder, worked on everything.

Total time: maybe 20 minutes. Writing that from scratch would have taken me 45 minutes minimum including looking up the library, handling the path logic, and testing edge cases. That's a real win.

This is the part I didn't expect to admit publicly but here it is. I built a small nightly automation — reads a folder, processes some files, moves them to an output directory. Tested it manually a few times, worked fine, deployed it.

Three days later I noticed the output directory was empty. The script had been running — logs showed it starting — but it was silently hitting an edge case and exiting without error and without moving anything. I hadn't actually read the file-handling logic carefully when Cursor generated it. I just ran it, saw it work on my test case, and shipped it.

The edge case was a filename with a space in it. The path handling broke silently. If I'd read the code for five minutes before deploying, I would have caught it. I did not do that because the whole point was to not read the code.

Lesson: vibe coding speeds up writing. It does not speed up the thinking about what can go wrong.

Anything you can test immediately and completely. If the thing works or doesn't work in a way that's obvious — a script that processes files, a form that submits, a function that returns a value — the iteration loop is tight and fast. Run it, see what's wrong, say what's wrong, run again.

Technology you don't know well. I'm not a Python person. I write it occasionally but always forget things like how pandas handles NaN values or which argparse syntax does what. Describing the goal and letting AI handle syntax I'd look up anyway is just faster.

Prototyping when you don't know if the idea is worth building. Getting a rough working version in an hour lets you test the idea before investing a week on it. The code quality is irrelevant at that stage.

If you are still learning programming, vibe coding as your main approach is a mistake. Not because AI-generated code is bad. It is often fine. The problem is that when something breaks, you need to know where to look. If you never read the code you submit, you cannot explain it in a viva, you cannot fix it in an interview, and you cannot extend it when requirements change.

I am saying this from my own experience. In college, if you submit code you do not understand, the practical exams become extremely difficult. Copying from AI without reading is the same category of risk.

Use AI as a tutor instead. Paste the error, ask it to explain the cause before giving you a fix, then write the fix yourself once you understand it. That is a very different workflow from blindly accepting whatever the model generates.

Cursor is the right tool for vibe coding because you stay in the editor. Describe the change, see the diff, accept or reject. No copy-pasting between tabs. The feedback loop staying tight is what makes the whole approach work.

Claude via browser chat also works but is slower because of the copy-paste friction. I use Claude when I want an explanation alongside the code — "write this AND tell me why the previous approach was wrong." For pure vibe coding iteration, Cursor is faster.

One habit that matters regardless of tool: before you push anything, read the diff like it's someone else's code. Not every line — just understand what changed and why. That one habit prevents most of the "it worked in testing" disasters.

Yes, for the right things. The EXIF script, a Google Sheets form integration, two small internal tools — I built all of these faster with vibe coding than I would have without it. That's real.

But the automation that silently failed for three days is also real. That happened because I trusted the output more than the task deserved.

The honest summary: vibe coding is fast. It's fast in a way that can make you sloppy if you let it. Use it on things you can fully test, read the critical parts of what it generates, and never deploy anything automated without thinking about what happens when the input is unexpected. Try it on something that doesn't matter if it breaks first.