Preventing AI Software Chaos

What Vibe Coding Looks Like

Vibe coding is building software by feeding prompts to AI without engineering judgment or architectural oversight. It's not inherently bad. Prototypes built this way move fast. But when speed becomes the only metric, specific failure modes appear.

The engineer sits at the keyboard and describes what they want in natural language. Claude, Cursor, ChatGPT, or v0 generates code that looks correct. It compiles. It runs. It solves the immediate problem. Nobody asks why it was built that way, what tradeoffs were made, or whether it fits the larger product strategy. The code gets merged and shipped.

This repeats dozens of times. Each feature works in isolation. But the codebase has no coherent shape. There is no shared understanding of how things fit together. When a new engineer joins, they read code that was generated by an AI based on a vague prompt, and they have to reverse-engineer the intent. Sometimes the intent was right. Sometimes the AI solved the wrong problem confidently.

By the time you realize the system is unmaintainable, you're already six months into a codebase that would need to be rewritten. Security holes that should have been caught in code review went to production. Data models that looked reasonable in isolation break under scale. Integrations that worked once fail silently in production because nobody documented their assumptions.

The Five Failure Modes

Vibe coding produces five specific types of failure that compound over time.

Context collapse happens when AI generates code based on incomplete or vague prompts instead of structured product understanding. The AI is highly confident and the code is syntactically correct, but it solves the wrong problem or makes assumptions that contradict other parts of the system. By the time you discover this, it's already in production.

Decision erosion occurs when technical choices get made implicitly in AI prompts rather than explicitly by the team. Nobody documents why the system uses pagination instead of infinite scroll, why authentication was routed through a particular service, or why the data model has that denormalization. Six months later, a new engineer wants to refactor something and has no idea what problem it was solving.

Unchecked automation means AI gets applied to high-risk areas without proportional oversight. A developer asks an AI to "generate the database schema for user accounts" and gets code that works but has no encryption at rest, doesn't validate input, and exposes PII in logs. The AI never marked these as concerns because the prompt didn't ask for security. But security shouldn't depend on the developer remembering to ask.

Lost learning is the accumulation of the same mistakes across the codebase. The team encounters a problem, solves it with AI, ships it, and moves on. The next time the problem appears (and it always does), they solve it again the same way, sometimes worse. There's no mechanism to capture what worked, what didn't, and why. Improvement is lost.

Misaligned output is when the code is correct but serves the wrong purpose. An AI generates a feature that works perfectly but solves a problem the product no longer has, or solves it in a way that contradicts the product strategy. By the time the misalignment is discovered, the feature is live and other code depends on it.

Why This Matters Operationally

Vibe-coded systems fail silently until they don't. A prototype that works looks like a product. An investor or customer sees working software and assumes it's ready to scale. But the first time you need to add a feature that touches the core architecture, or handle 10x the load, or integrate with another system, the codebase becomes a liability.

The business impact is predictable: wasted engineering investment, rebuilding from scratch, security incidents, customer-facing outages, and missed deadlines while engineers fight with unmaintainable code instead of building new value. We've been called in after six and twelve month projects where the only responsible path was to start over.

Founders who built with AI tools don't do this deliberately. They're moving fast because they need to. They're using the best tools available. But without structure, speed becomes waste.

The Solution: CRAFT

CRAFT is a methodology for AI-assisted development that prevents these failure modes. It's not about slowing down. It's about making the right decisions visible and enforcing them before code gets written.

CRAFT stands for Context, Rationale, Automate, Fortify, Telemetry.

Context prevents context collapse. Before any code starts, the team writes an Intent Contract that defines the outcome, scope, constraints, success metrics, and kill criteria. The Intent Contract is approved by the people who understand the business and the product. This contract is the shared reference that guards against vague prompts generating confident nonsense. When an AI agent has the full context, it generates code that actually solves the problem.

Rationale prevents decision erosion. Every material technical decision is recorded in a Decision Record with reasoning. Why did we choose this authentication provider? What tradeoff did we accept? What were the alternatives? These aren't detailed design documents. They're a permanent log of why things were built the way they were. New engineers read these and understand the intent. When you need to refactor later, you know what problem you're solving for.

Automate means using AI where it's strongest (code generation, refactoring, boilerplate) but with oversight. Automation without judgment is how security holes and bad patterns get shipped. Automation with code review, quality gates, and architectural review prevents the worst failure modes. AI does the labor. Engineers do the judgment.

Fortify prevents shipping broken or insecure code. Quality gates are mandatory before deployment. This includes code review, security scanning, performance testing, and integration testing. These aren't optional reviews that busy teams skip. They're gates that must be passed. If a piece of code doesn't meet the standards, it doesn't ship. The earlier you enforce this, the less waste.

Telemetry prevents lost learning. Every system in production gets observability. Logs, metrics, alerts, and session recordings. When something breaks, you know what happened and why. When a feature isn't used, you see it in the data. The team captures what works and learns from what doesn't. This creates compounding improvement instead of the same problems recurring.

What Structured AI-Assisted Development Looks Like

In practice, structured AI-assisted development is faster than vibe coding in the long term because it prevents waste.

Day one: The team writes an Intent Contract. This takes a few hours. It forces the hard conversations. What are we trying to achieve? What are we not doing? What does success look like? What would cause us to kill this effort? By the end, everyone agrees on the shape of the work.

Day two: Developers use AI as a tool to write code faster. They feed the Intent Contract into Claude or Cursor as context. They write prompts that reference specific decisions and constraints. The AI generates code that's aligned with the product strategy and architectural decisions, not just what fits a vague description.

Day three: Code review catches alignment issues before they're merged. Is this code consistent with the architecture? Does it follow the patterns the team established? Does it satisfy the Intent Contract? If it doesn't, it gets fixed before it reaches the codebase. The cost of fixing an architectural problem here is hours. The cost of fixing it six months later is weeks.

The system gets deployed when it passes quality gates. Observability tells the team if it's working and how it's being used. Decisions get recorded. The next time a similar problem appears, the team references the Decision Record, considers whether the old solution still applies, and either reuses it or documents a new decision.

This isn't bureaucracy. It's the opposite. It's preventing the waste that comes from building without structure. It's moving fast on things that matter and preventing waste on things that don't.

Vibe Coding Rescue

The market is full of teams who used AI tools to build something quickly and now need real engineering to make it real. We call this vibe coding rescue.

A founder built a prototype with v0 in two weeks. It worked. They showed investors. The investors wanted the product in two months. Six months later, they've added 80k lines of code to the codebase. The system is unmaintainable. New features take longer to ship than they did in month two. The team is arguing about architecture because nobody documented why anything was built the way it was. The code is slow and has security holes. The founder is exhausted.

This is where we get called in. We don't throw the code away. We audit the codebase, capture the decisions that matter, document the architecture, enforce quality gates, and teach the team to build with structure. We extract the parts worth keeping and rebuild the parts that need it. The rescue typically takes 6-12 weeks depending on the size and the damage. After that, the system works reliably and the team can move fast again.

Vibe coding rescue is an inflection point. It's cheaper and faster than rebuilding from scratch. But it's also a signal that the next phase of growth requires engineering discipline. The team learns to build differently.

FAQ

Q: Does structured development slow us down?

A: In the short term, it feels slower because you're writing Intent Contracts and Decision Records before code. But it's faster overall because you prevent the waste that comes from building the wrong thing confidently, from rework due to misaligned code, and from unmaintainable systems that slow you down for months. The Intent Contract takes a few hours. The time it saves is measured in weeks.

Q: Isn't this just "do design upfront"?

A: No. Design upfront assumes you know what you're building. An Intent Contract assumes you know what problem you're solving and what success looks like. The design decisions emerge from code and feedback. The Intent Contract is the guard rail, not the blueprint. There's a real difference.

Q: Can we retrofit CRAFT to an existing codebase?

A: Yes. It's harder than starting with it, but it's possible. You audit the codebase, extract the architecture and decisions, document them retroactively, and then enforce structure going forward. This is vibe coding rescue.

Q: Does CRAFT require more people or more process?

A: It requires the same people but with better guardrails. The team size doesn't need to change. The process is lighter than traditional waterfall. The difference is that decisions are visible and enforced before code gets written, not after.

Q: How does CRAFT work with different AI tools?

A: CRAFT is tool-agnostic. Whether you use Claude, ChatGPT, Cursor, or v0, the methodology is the same. You give the AI agent the Intent Contract as context. You use it to generate code faster. You enforce quality gates and record decisions. The tool is the accelerator. CRAFT is the structure that keeps the acceleration useful.

Q: What if we disagree with the Intent Contract after we start?

A: Then you update it. The Intent Contract isn't carved in stone. But updating it is a team decision with rationale. You don't just drift and hope the system still makes sense. When the scope changes or the success metrics shift, you record the change and decide how it affects the work in progress. This is how teams stay aligned instead of diverging into chaos.