When Vibecoding Goes Wrong

The interface looked perfect. The code compiled. I deployed it.

Users couldn’t send messages to each other.

When I dug into the code, I discovered something horrifying: the AI had implemented the core messaging functions three different ways. None of them talked to each other. The modules were duplicated, broken, completely non-functional.

This is the dark side of vibecoding that nobody talks about. AI coding tools let non-technical product managers build complex applications. But without the right approach, you’re building a house of cards. It collapses the moment someone tries to use it.

What I learned: Vibecoding isn't the problem. Vibecoding without a system is.

Tools like ChatGPT, Claude, and Cursor can generate entire features from a prompt. A PM who can’t write a React component can suddenly spin up full-stack applications.

The promise is seductive. The reality is brutal.

AI coding without proper oversight creates specific, predictable disasters:

Endless error loops. The AI fixes one bug and creates three more. You spend hours going in circles.

Massive technical debt. Workarounds pile up. The AI creates fallback logic that masks errors instead of fixing them.

Security holes. The AI implements authentication but forgets rate limiting. It validates inputs but misses SQL injection vectors.

Duplicate functions. The AI forgets what it built yesterday. It recreates the same logic in a different file.

Half-baked implementations. The AI starts a feature, gets distracted, leaves partially completed code scattered throughout your codebase.

Unmaintainable spaghetti. Without clear architectural guidance, the AI creates tangled dependencies. Every change becomes risky.

I experienced all of this. My early versions of CoachAssistAI had duplicated functions, partially implemented capabilities, obvious security flaws, missing tests. The codebase worked enough to be dangerous. It looked functional but was fundamentally broken.

AI tools are good at coding. They’re terrible at project management, architecture, and quality control.

The solution isn’t to abandon AI coding. It’s to adopt engineering practices adapted for AI tools.

Traditional engineering teams use requirements documents, technical architecture specs, work breakdown and ticketing, code review processes, testing protocols, security audits. Most PMs think this is too complicated for them.

But you don’t need to understand all the technical details. AI will help you with the engineering work.

You need a system to control the AI and prevent the chaos.

Your product sense and judgment guide the process. AI handles the technical execution. The workflow keeps both on track.

After refactoring that broken chat system and rebuilding CoachAssistAI with a structured approach, I identified five specific innovations that prevent vibecoding disasters.

Before you can prevent duplication, you need to know what you already have.

The system automatically scans your codebase and catalogs every reusable component. Authentication services, email handlers, database access patterns, validation logic. Everything. It’s like taking inventory of your toolbox before you start a project.

Each service gets a reuse score: HIGH (80 percent or more fit for new features), MEDIUM (50-80 percent fit), or LOW (less than 50 percent fit). This scoring determines what gets reused versus what gets rebuilt.

In my chat system disaster, AI created three different email implementations because it had no idea an EmailService already existed. It wasn’t being lazy. It genuinely didn’t know what was already available.

With service inventory, AI knows exactly what exists before it writes a single line of code.

Real example from CoachAssistAI:

This prevents the “reinvent the wheel every time” problem that makes AI-generated code unmaintainable.

The Service inventory becomes actionable here. Adaptation sits between planning and implementation, transforming the inventory into explicit implementation guidance.

Before AI writes any code, Adaptation creates a detailed blueprint: which services to reuse, how to extend them, where to integrate with existing patterns, what genuinely needs to be built new.

Without Adaptation, AI treats every feature as a blank slate and reimplements everything from scratch.

With Adaptation, AI gets precise instructions: “EmailService already handles 80 percent of what you need. Extend it here, reuse this method, integrate with these existing patterns.”

In my email verification feature, Adaptation used the service inventory to identify eight existing services. It calculated an 89 percent reuse score and created explicit guidance:

The result: AI wrote only 521 lines of orchestration code that tied together thousands of lines of existing infrastructure.

No duplication. Clean integration.

This phase prevented what would have been at least three duplicate implementations: email sending, rate limiting, security monitoring.

AI has no persistent memory. It forgets what it built yesterday. Without external memory, it will recreate solved problems and lose architectural context.

The solution: Your ticketing system becomes AI’s external brain.

But here’s the key innovation—the system creates and updates tickets automatically as you work. You’re not manually copy-pasting context.

I built this using Linear’s MCP (Model Context Protocol) integration. As you run each workflow phase, the system automatically creates tickets with appropriate structure, updates ticket comments with discovery findings, documents architectural decisions, links related tickets, preserves implementation guidance.

This works with Linear now, but the approach adapts to any ticketing system with API access. Jira, GitHub Issues, whatever you use.

Every discovery finding, every architectural decision, every implementation detail gets captured automatically. The ticket becomes a complete record that travels through your workflow.

Six months later, when you need a similar feature, you reference the ticket. AI has the full context: what was built, why decisions were made, what patterns to follow. The knowledge doesn’t disappear.

Context Engineering for AI AND Humans Unlike RAG systems or vector embeddings (which are black boxes), you can read what the AI knows. You can see the context it’s using. You can correct it when it’s wrong.

When I needed to enhance the feature, I referenced the original ticket. AI adapted the new work into the existing pattern in minutes because all the context was preserved and accessible.

Instead of one generic “AI coding assistant,” you work with specialized expert agents—each focused on one phase of development.

Think of it like having a full engineering team:

Each agent has deep expertise in its specialty. Strict boundaries about what it can do.

The workflow enforces these boundaries through phases:

Each agent focuses on its specialty. The architect doesn’t write code—it only creates guidance. The implementation agent doesn’t make architectural decisions—it follows the blueprint. The code reviewer doesn’t add features—it finds problems.

This prevents scope creep. Catches issues before they compound. Creates natural checkpoints where you verify quality.

I’ve built this for both Claude Code and Codex—different implementations of the same workflow concept.

In that email verification feature, this phased approach caught five critical bugs during code review and one security vulnerability during security review. All before deployment.

This is the philosophical foundation that makes everything work.

Three principles:

AI loves shortcuts. It will add “works for now” code that masks errors instead of fixing them. It will create fallback logic that papers over bugs. It will mock implementations that never get finished.

I learned this the hard way. My early CoachAssistAI codebase was full of try-catch blocks that swallowed exceptions, fallback logic that hid bugs, mocked functions that “temporarily” handled edge cases.

This system forbids it.

Every line of code must be production-ready from day one. No temporary solutions. No workarounds. If something requires a hack to work, you fix the underlying issue first.

AI writes lots of tests. Most are useless.

It generates tests that inflate coverage numbers without catching real bugs. Tests for getters, setters, configuration files. Tests that verify “2 + 2 = 4.”

This system focuses testing on code that matters:

Target: 70-80 percent strategic coverage instead of 90 percent or more vanity coverage.

Each test must catch real potential bugs.

For CoachAssistAI’s knowledge graph processing (complex), we have 95 percent coverage. For basic user profile updates (simple), we have 40 percent.

This isn’t lazy. It’s strategic.

AI forgets to read external documentation files. But it can’t miss documentation that lives right in the code.

The system emphasizes inline documentation for complex logic. When AI opens a file to modify it, the context is already there. No hunting for separate docs. No relying on AI to remember to check documentation folders.

This creates “ambient context”—the information AI needs is present in the code it’s already looking at.

The AI doesn’t write elegant workarounds that hide problems. It lets the code fail with detailed error messages.

Why? You can’t read code well enough to spot a clever workaround buried in a try-catch block. But you can absolutely read an error message that says “Email service connection failed: invalid API key in line 47.”

The error surfaces immediately. You see exactly what broke and where. You fix it in minutes.

The alternative is worse: the AI writes a fallback that silently swallows the error, logs it somewhere you’ll never look, and returns a generic success message. The bug sits there for weeks until a user hits it in production. Then you’re excavating through code you don’t understand, trying to find where the problem got masked.

Fail-fast means issues surface during development when they’re easy to fix, not in production when they’re expensive.

These four principles work together to ensure that AI generates production-ready code, not prototype code. No shortcuts that create technical debt. Tests that actually catch bugs. Documentation that AI can’t miss. Errors that surface immediately instead of hiding in workarounds.

Let me show you how all five innovations work together with a real feature from CoachAssistAI.

The requirement: Implement email verification for new account registration with token management, resend functionality, security controls.

Service Inventory (Innovation 1): Scanned codebase and identified existing services—EmailService, RateLimitGuard, SecurityEventService, UserRepository, EmailProcessor, others. Scored their reuse potential.

Adaptation (Innovation 2): Used inventory to create detailed guidance showing exactly how to integrate with existing services. Calculated an 89 percent reuse score. Almost all infrastructure already existed.

Automated Tickets (Innovation 3): System automatically created Linear ticket and populated it with discovery findings and adaptation guidance. No manual copy-pasting.

Specialized Agents (Innovation 4):

Production-First Quality (Innovation 5):

The outcome: Production-ready email verification that integrates cleanly with existing architecture.

No duplicate code. No security vulnerabilities. No refactoring needed.

Without this workflow, I would have had three different email sending implementations, broken rate limiting, security holes discovered by users, weeks of refactoring to untangle the mess.

The five-part system prevented all of it.

This system won’t produce elegant, highly scalable code that a team of senior engineers would write. It won’t give you cutting-edge architecture or optimize for massive scale.

What it will do: Let PMs with little technical experience move beyond prototyping by creating production-ready applications that actually work.

You can ship real features. Build complex functionality. Maintain code quality as your application grows. Avoid the spaghetti mess that makes AI-generated code unmaintainable.

CoachAssistAI is living proof. It has 24 backend modules, real-time WebSocket connections, AI orchestration, knowledge graph processing, authentication. It runs in production. It’s maintainable. New features integrate cleanly because the architecture is sound.

Is it as good as a team of experienced engineers would produce? No.

Is it production-ready and functional? Yes.

Good enough to ship. Maintainable enough to grow. Structured enough to avoid disaster.

If you’re a PM who wants to build something real, you don’t need to become a developer.

You need three things:

A system to control AI. The five-part workflow with inventory, adaptation, automated memory, specialized agents, production-first quality.

Product judgment. Your sense of what to build and why. The thing AI can’t replicate.

Willingness to follow the process. The workflow has structure for a reason. Follow it and you get production code. Skip steps and you get chaos.

The engineering work? AI handles it.

The architecture decisions? The inventory and adaptation phases guide them.

The quality control? The specialized review agents catch issues.

Your job is orchestration, not implementation. If you can manage a cross-functional team, you can manage AI agents through this workflow.

I built this system through painful trial and error while developing CoachAssistAI.

The chat system disaster taught me that AI needs structure. The email verification success showed me the system works.

I’ve packaged this workflow as a set of prompts and agent files that handle the heavy lifting. With good documentation, a non-technical PM can execute all the phases—service inventory, adaptation, code review, security review—because the prompts guide them through each step.

The system works with both Claude Code and Codex. The automated ticketing currently uses Linear’s MCP integration but could adapt to Jira or other systems with API access.

AI coding needs more structure than human coding, not less.

Vibecoding without structure creates disasters. Vibecoding with the right workflow creates production software.

You can build complex applications as a PM. You just need to know how to control the chaos.

Subscribe to my newsletter and get access to my complete system.

If you’re looking for coaching on how to level up as a Product Leader, or how use AI in your product work, have a look at my coaching practice - I’d be happy to set up a call anytime to see how I can help you succeed! https://pmcoaching.net