There's a new term floating around engineering circles: "vibe coding."
It describes a development approach where you prompt an AI, get working code, ship it, and move on—without ever deeply understanding what you built. The code compiles. The tests pass. The feature works. Who cares how?
This approach is seductive. It's fast. It feels productive. And it's creating a slow-motion disaster in codebases everywhere.
The Abstraction Problem
Good software is built on abstractions. A well-designed system has layers: data access, business logic, presentation. Each layer has clear responsibilities. Changes in one layer don't ripple unpredictably through others.
Building these abstractions requires understanding. You need to know:
- What belongs in each layer
- How layers communicate
- What invariants must be maintained
- Where the system's extension points are
Vibe coding bypasses all of this. The AI generates code that works in the moment but ignores architectural context. Over time, the clean layers blur. Responsibilities leak. The system becomes what one developer described as "a huge mess where everything depends on everything."
What This Looks Like in Practice
The God Function
An AI is asked to "add a feature that sends an email when an order ships." It generates a function that:
- Queries the database directly (bypassing the data layer)
- Contains business logic (order validation, shipping rules)
- Formats HTML (presentation logic)
- Calls the email API (integration logic)
- Logs to the console (observability logic)
The function works. But it violates every architectural principle. When requirements change—different email provider, new validation rules, logging to a different system—you have to rewrite the entire thing.
The Copy-Paste Cascade
An AI generates a pattern for handling API errors. It works, so the developer prompts it again for the next endpoint. And the next. Soon there are 47 nearly-identical error handling blocks scattered across the codebase.
A senior engineer would have extracted this into a shared utility after the second occurrence. A vibe coder doesn't notice the pattern because they never read the code deeply enough to see it.
The Configuration Explosion
Instead of understanding how the system's configuration works, a vibe coder prompts the AI to "make this configurable." The AI adds a new config file, because it doesn't know about the existing configuration system. Now there are two configuration systems. Then three. Then nobody knows where settings live.
Measuring the Damage
These problems are visible in the data, if you know where to look.
Complexity Trends
Track cyclomatic complexity and file coupling over time. A healthy codebase maintains stable complexity as it grows. A vibe-coded codebase shows accelerating complexity—each new feature makes the next one harder.
Churn Concentration
If the same files are churned repeatedly, it often indicates poor abstraction. Changes that should be isolated to one area touch many files because concerns aren't separated.
In Velocinator, we surface High Churn Files: files modified in more than 30% of recent PRs. These are often architectural pain points.
Rework Patterns
Vibe-coded solutions often need to be rewritten when requirements evolve. Track how often recently-written code gets significantly modified or deleted.
High rework isn't always bad—sometimes requirements change. But consistently high rework on certain developers' code suggests they're not building for the long term.
The Junior Developer Risk
Vibe coding is particularly dangerous for junior developers.
A junior who struggles through implementing a feature the "hard way" learns:
- How the system is structured
- Why certain patterns exist
- What happens when you violate conventions
- How to debug when things break
A junior who prompts their way to a working feature learns none of this. They become dependent on the AI not just for productivity, but for understanding. When the AI is wrong—and it will be—they can't detect or fix the error.
We're seeing this in the data. At organizations with heavy AI adoption, junior developers show:
- Higher initial velocity (they ship features faster)
- Lower debugging efficiency (they take longer to fix bugs in their own code)
- Reduced code review quality (they miss issues that require architectural understanding)
The short-term productivity gain may be creating a long-term skills gap.
Maintaining Abstractions
How do you get the speed benefits of AI assistance without the architectural degradation?
1. Document Your Architecture for AI
AI tools work better when they have context. Create documentation specifically designed to be fed to AI:
- Architecture decision records (ADRs)
- Layer responsibilities and boundaries
- Code style and pattern guides
- "Don't do this" anti-patterns
When prompting, include this context: "Given our architecture where [X], implement [Y] following our pattern of [Z]."
2. Review for Architecture, Not Just Function
Train reviewers to ask architectural questions:
- Does this belong in this layer?
- Are we creating duplication that should be abstracted?
- Does this follow our established patterns?
- Would a new team member understand why this is here?
Code review is the last line of defense against vibe-coded mess.
3. Require Understanding, Not Just Implementation
Before merging, require authors to explain their code. Not just "what it does" but "why this approach" and "what alternatives were considered."
If a developer can't explain why the AI chose a particular pattern, they shouldn't be shipping it.
4. Pair AI Work with Refactoring Time
After using AI to quickly implement a feature, allocate time for cleanup:
- Extract common patterns
- Align with existing architecture
- Add appropriate documentation
- Write comprehensive tests
The AI got you 80% there fast. The last 20% is human judgment work.
5. Track Architectural Health Metrics
Make the invisible visible:
- Complexity scores by module
- Coupling between layers
- Files touched per feature (a proxy for proper separation)
- Technical debt indicators
When the metrics trend badly, investigate before the codebase becomes unmaintainable.
The Balance
AI coding assistants are powerful tools. Used well, they accelerate implementation of well-understood patterns. Used poorly, they accelerate the creation of unmaintainable systems.
The difference is whether developers are engineering—deliberately designing systems with clear abstractions—or vibing—prompting their way to something that works today but creates problems tomorrow.
Velocity without architecture is just building debt faster.
