Is it vibe coding if you know what you’re doing?

When people first started saying they were using AI to build full apps, I was wildly skeptical. You’ve heard these stories too, right? “I built a complete SaaS platform in one weekend using ChatGPT!” Sure, you did.

But I kept hearing it. Over and over. Whole apps. Entire startups. Just prompts. So, I decided to test the hype. I’ve had the idea to build an app to help collectors track and manage their sports card collections for years. I’ve tried Excel, Google Sheets, Airtable, and even Retool. They are all excellent tools but weren’t the right ones for the job I was trying to accomplish. But after a friend showed me how he was using Claude Code in his CLI, the light bulb went on.

Two weeks later, I had a working site. Authentication. A database. A clean interface. All built with AI tools, a little stubbornness, and an embarrassing number of “let’s try that again” moments.

That’s when it hit me: It’s not vibe coding if you know what you’re doing.

The CLAUDE.md rulebook

The first lesson I learned: AI needs boundaries. So, I made a file called CLAUDE.md. Think of it like an employee handbook for a very confident robot. It spells out how I want things done — naming conventions, frameworks, the tone of my responses; even how to handle uncertainty. Without it, Claude will take creative liberties. With it, it’s like working with someone who mostly listens and only occasionally decides your database schema needs “personality.” You don’t need to go all in on “spec-driven development” when you’re first starting out, you just need some guide rails.

Second, design consistency is not AI’s strong suit. One minute it’s using Material UI, the next it’s gone rogue with pastel buttons and drop shadows from 2007. I started a design guide just to keep it on the rails. It made things infinitely easier to describe and control, all in one place.

An excerpt from the rulebook

# Claude Development Notes

## 🚨 CRITICAL: HOW TO WORK WITH THIS USER (READ FIRST - EVERY SESSION)

### Core Working Principles - NEVER FORGET THESE

1. **BE A SYSTEMATIC CODE ANALYST, NOT A GUESSER**

- ALWAYS search for existing code patterns, dependencies, and conflicts BEFORE attempting fixes

- Use grep, find, and comprehensive code analysis to understand root causes systematically

- Don't apply "band-aid" fixes - identify and solve the underlying architectural issue

- Leverage your file search and cross-reference capabilities instead of making the user debug manually

- This applies to CSS, JavaScript, database queries, API endpoints, configuration - EVERYTHING

2. **THINK LIKE AN EXPERT WITH DEEP SYSTEM KNOWLEDGE**

- Consider how changes affect the entire system: dependencies, imports, inheritance, scoping

- Look for naming conflicts, architectural patterns, and existing conventions

- Analyze the broader codebase structure and established patterns before making changes

- Understand the user is building maintainable, scalable, isolated components

- Apply this expertise to ALL aspects: styling, logic, data flow, security, performance

You can view the full rulebook here.

Don’t give AI the keys to the kingdom

Those initial guard rails will get you started, but they aren’t enough. You’re going to need reliable source control. Badly. AI can (and will) make sweeping changes in seconds. Whole sections of your project — just gone. It’s not malicious, it’s just eager. Commit early, commit often, and keep your fingers hovering over the ESC key to interrupt bad ideas.

Next: Write tests. I know. You won’t want to. Neither did I. But AI code that “works” can still be deeply wrong. I can’t tell you how many times I’ve seen it confidently try to pass data through functions that don’t even exist.

Perhaps most importantly: Never — and I mean never — let AI near your production database or environment. That’s not a metaphor. Twice, my AI coding partner has seen differences in our ORM and our database schema, and twice I have seen it decide to drop all of the database tables to create something that matches the ORM. Thankfully, it was only the development database, but if it had access to production, it would have dropped those tables too.

I have a rule: Staging is for the robots; production is for adults.

“AI forgets. Teammates inherit.”

This is painfully true. AI forgets everything. Context, logic, variable names. All of it. And when you come back to that project later (or someone else does), there’s no memory of why anything was done the way it was. That’s why documentation still matters. Probably more than ever. Because you’re not just documenting for other people anymore — you’re documenting for yourself when your future self wonders, “Why did past me let the robot do this?”

Observability, or “Please tell me what just happened”

This is where tools like Dynatrace come in. I know, I work there, but I’d say this either way. If you’re going to let AI write your code, you need a way to see what it’s doing. Not just logs — observability. Dynatrace tells me what’s happening across the system: slow API calls, inefficient queries, the occasional “why is this endpoint melting the CPU?” moment. It’s not about catching mistakes — it’s about catching surprises. And AI delivers plenty of those.

“Don’t asume corectness”

The typo’s intentional. Mostly. But the point stands: AI code looks right more often than it is right. I’ve had it produce entire components that look perfect and fail silently. It’s confident. It’s articulate. It’s wrong. So, check everything. Run it. Test it. Review it. Don’t just asume corectness.

The big takeaway

Here’s what surprised me the most: Building with AI doesn’t feel like cheating. It feels like collaborating. You’re still making all the decisions — the AI just types faster than you do. It’s like pairing with someone who’s read every Stack Overflow thread but still can’t quite tell when it’s about to create a security hole.

You’re not outsourcing the work. You’re accelerating it. AI doesn’t replace developers. It amplifies them. The people who’ll thrive in this new era aren’t the fastest typists — they’re the clearest thinkers. They’re the best communicators.

I don’t think “vibe coding” is bad. It’s just unstructured. And once you’ve got a plan — a CLAUDE.md file, a solid process, some observability, and a healthy dose of skepticism — it stops being “vibe coding” and starts being modern engineering.

AI can write code. But you still have to lead.

It’s not vibe coding if you know what you’re doing. It’s just engineering with better tools.