The 7 deadly sins of vibe coding

What NOT to do when coding with AI agents (and what to do instead)

TLDR: Since I started building with AI almost two years ago, I’ve identified seven common mistakes that can make development more painful than it has to be. For better results and a less stressful experience, avoid the following: skipping Git commits, letting AI code without planning, not thinking about security, giving up on hard bugs, relying too much on automated testing, accepting every feature AI recommends, and letting your agent get away with sloppy work.

Also, in the “what to do instead” sections, I’ve featured work from two subscribers who completed this newsletter’s most recent build challenge.

I can’t believe I’ve been building software with AI for almost two years. I’ve probably shipped or attempted at least twenty-five different tools in that window. The list includes a few projects for paying clients, four tools I’ve published to the cloud (two of which I’ve since killed), four Chrome extensions, and a long tail of projects I paused because I found a better way to solve the problem that didn’t require building and maintaining a custom app.

AI coding agents, which can generate pages of code in minutes, are what’s made this pace possible. They’ve let me build ideas in days and weeks that would have taken me months to hand-code. But agents also come with their own specific failure modes, and most of those failure modes don’t show up until you’re already a few weeks into a project and emotionally invested.

For example, an agent might happily build a prototype that works great with 100 records and crashes when you push it to 10,000. It might ship a UI that technically works but feels off, or introduce security holes that you’d never write if you were coding by hand.

Agents can feel like magic when you’re watching them work, but they aren’t magic. They’re a new kind of tool with a unique set of limitations, and many of them are counterintuitive, especially if you’re new to software design. And, because they seem so omni-competent, it can be shocking and unexpected when they drop the ball.

In fact, the most serious mistakes made by people using AI to code involve trusting AI too much, and I made a lot of them when I first started. Here's what seven of the most common look like and what to do instead.

1. Failing to commit working code

If you’ve never used Git before, here’s the short version. A commit is a save point. Every time you commit, you’re telling Git “this version of my code is worth remembering,” and you can roll back to it later if things go sideways. A branch is a parallel copy of your code where you can experiment without breaking the main version.

If you don’t commit regularly, you risk losing your working code if AI makes a mistake. Let’s say you add a login feature that works, then a dashboard that works, and then you decide to add a report. If your AI model decides to implement the report by breaking or removing other features, they’re gone for good. (If you commit, you can roll back the code to the latest working version—it’s the buggy mess never happened.)

Most people get into trouble when they get really excited by a new feature set and keep adding onto the code without committing their work. (The is the AI-enabled version of writing a 20-page paper and forgetting to save your doc.)

What to do instead

Set up a Git repository on day one, even if your project feels too small to bother. Commit every time you have working code, not just when you’ve finished a feature. Start a new branch for any major revision, like swapping out your database or rewriting a core component.

If you’ve never used Git, spend an hour with a tutorial. Future you will thank present you. According to Claire Machado, who successfully updated her habit-tracking app as part of this newsletter’s April build project, using Git more is the main thing she’d do differently.

Builder profile: Claire Machado

Substack: Long Happy Life

Live project: https://habit-path.netlify.app (free)

Toolset: Cursor, Netlify, Claude (API), Claude chat with Sonnet 4.6

What she built: “I enhanced an existing habit tracker by migrating from Google AI to the Anthropic API, adding weekly progress tracking, and creating a subtle teal glow around each card as a visual celebration effect when all daily habits are completed. The tracker includes monthly calendars with streak tracking, a daily mood logger, a weekly reflection space, a 25-minute Pomodoro timer, and CSV and PDF export options.”

“The redesigned insights now use the Anthropic API with Claude to deliver specific, grounded feedback based on real data instead of generic motivation. I customized the visual design with my brand colors and layout style, and carefully tuned the prompt to avoid chatbot language while keeping the tone warm and observational, which reflects my voice across all my projects.”

Biggest challenge: “Getting the Claude API to respect strict output constraints. The model kept writing 3 to 4 sentences when I specified exactly 2, and I couldn’t get rid of the em dashes in the response. This taught me that explicit word count limits sometimes need to be tested and adjusted, rather than assumed to work perfectly on the first try.”

What I’d do differently: “I’d create a Git branch before making changes to production code. This way, if something broke, I could revert quickly without losing the original working version. I’d also test the API integration from the start to catch issues earlier.”

2. Not starting in plan mode

AI models are eager. They want to code, and they want to code now. If you give your AI a one-line prompt like “build me a tool that summarizes my emails,” it will happily start cranking out files based on a pile of assumptions you never agreed to. Maybe it picks a framework you don’t want to maintain. Maybe it stores data in a way that won’t work for your real use case. Maybe it builds a feature you didn’t ask for and skips one you did.

In this case, the problem is that AI is making decisions for you that may not actually be right for your specific use case. This means that the end result is likely to fall short of your expectations and may be built in a way that won’t support what you need over time.

What to do instead

Use Claude Code’s /plan mode or simply ask your agent to “plan before coding” and insist on approving any plans.

And, once AI has written your plan, review it carefully. Push back on anything that doesn’t match your vision, and iterate until you understand both what the model is going to build and why. The hour or two you spend here can save you days of cleanup later.

3. Not learning the basics of security

AI agents are optimized to ship working code, not secure code. Left unsupervised, they will do things like hardcode your API keys directly into your source files, store passwords in plaintext, leave your database open to prompt injection, and skip authentication on routes that absolutely need it.

The good news is that most of these problems are easy to fix once you know they exist. The bad news is that you have to know enough to ask.

What to do instead

Follow security people who cover the latest issues, and look up any terminology that you don’t understand. (I read ToxSec). Load a few security tutorials and OWASP docs into NotebookLM so you can ask questions about your own project.

And before you deploy anything to the public internet, ask your agent to do a security review of the codebase and flag any concerns. Then ask a second agent to review the first one’s work.

4. Giving up when AI can’t fix a bug

Sometimes your agent will hit a wall. You’ll watch it cycle through three variations of the same broken solution, get more confident with each attempt, and end up exactly nowhere. This is when a lot of people give up and conclude that the problem is “too hard for AI.” It usually isn’t.

What to do instead

Treat this as a collaboration and approach it as an educational challenge. A few things that work for me:

• Clear the context window and start fresh. Long sessions accumulate context rot, and a clean slate often unsticks a stuck model.

• Ask your agent to propose four or five completely different approaches to the problem, then pick one and have it implement that.

• Do some research yourself. Read the docs, search the relevant GitHub issues, and bring your agent a specific direction.

• Run the problem by a different model and pass its answer back to your primary coding agent.

Worst case, you genuinely do need to rethink the feature. Constraints are part of systems design, and a stuck bug is often the signal that an earlier decision needs revisiting.

5. Failing to test your app

Your agent will often run automated tests on its own, and you should let it. Unit tests (small tests that check individual functions) and integration tests (tests that check how parts of your app work together) catch a huge percentage of regressions before they reach you.

But even with computer vision and tools like Playwright, your agent doesn’t fully understand what your UI feels like from a human point of view. It can’t tell you that a button is in the wrong place, or that the loading state is confusing, or that the form is impossible to fill out on mobile.

What to do instead

Test early and often, before you’ve generated a mountain of interdependent code on top of an unverified foundation. Click through your app yourself after every significant feature. Try it on your phone. Try to break it. The earlier you catch something, the fewer dependencies you have to untangle to fix it.

If you have a child older than, say, eight or nine years old, have them use your tool and try to make it crash. This can uncover edge cases you never thought of, and it’s also hilarious.

6. Accepting every idea Claude suggests

Claude is a “generous” collaborator. Ask it to help you build a tool, and it will happily suggest twelve features you didn’t ask for, most of which sound reasonable. The trap is that every feature you accept is more code to maintain, more surface area for bugs, and more things your users have to learn. And a lot of these suggestions are features your actual users don’t care about, which means they end up diluting whatever the real value of your app was supposed to be.

What to do instead

Write a spec before you start building, and stick to it. When Claude suggests something interesting that’s out of scope, add it to a “Explore in Phase 2” list and keep going. If the idea is still exciting in a week, build it. Most of them won’t be.

7. Letting Claude get away with slacking

AI is optimized to deliver fast, functional code. That’s not the same as great code or great UX. (Note: I borrowed this idea from @JennyOuyang who write about it last year.) Your agent will sometimes hand you something that technically complies with your spec but offers a poor experience.

Depending on your app, you might see redundant UI elements, a flow that works but feels clunky, data that gets written almost correctly, performance that’s just slightly slow. But just because your agent delivered it doesn’t mean you have to accept it.

What to do instead

Treat any issue you notice as worth investigating, even small ones. Redundant elements, results that are only 80% faithful to your spec, sluggish responses, anything that makes you cringe a little.

Push back, ask questions, and don’t settle. If your agent gets stuck trying to fix it, fall back on the debugging moves from sin #4: clear context, ask for alternate approaches, do your own research.

Planning can also involve making sure you’re prepared for an important build. Denise Wakeman got started with a small project to get ready for customer-facing work.

Builder: Denise Wakeman

Substack: Your Visibility Edge

Live project: Running locally

What she built: Denise worked through a templated habit tracker project as practice, with the goal of eventually building a Visibility Tracker tool for her business. “I followed the prompts and then added a few of the suggested ‘nice to haves’: my brand colors, title on the tracker, confetti, motivational quote.”

Biggest challenge: “It wasn’t clear to me where to set up the index.html file. I tried to add it in my Google Drive, but that didn’t work, so I set it up in my documents folder. Otherwise it was easy to follow the prompts one by one, save, refresh and then decide what’s next.”

What she’d do differently: “What it created is just for me. Next I’ll create a Visibility Tracker for clients, so I’ll have to figure out how to [get it into the cloud].”

The takeaway

None of these mistakes are fatal on their own. I’ve made every single one of them, sometimes more than once, and my projects survived. But they’re a tax. Every sin you commit costs you time, energy, and momentum, and the projects that die are often the ones where the taxes pile up faster than the progress.

The shorter version of all seven sins is this: vibe coding works best when you pay attention and don’t trust AI too much. Use the agent for speed, but stay engaged on direction, security, testing, scope, and quality. The agent isn’t doing the work for you. You’re doing the work together, and your job is to stay sharp enough to catch what it misses.

If all of this sounds like a lot when you’re just starting out, consider a templated “warm up project” you can learn from before tackling something for your business or workplace.

What sins would you add to the list? Reply and let me know.