Vibe Coding and Your Team: What Changes When AI Writes Most of the Code

2026-08-19 · 11 min read · Tools & Productivity

"Vibe coding" started as a half-joke — describe what you want, let the model write it, accept the diff without reading it closely, keep going while it works. The term stuck because it named something engineers were already doing quietly and weren't sure how to feel about.

For an Engineering Manager, the interesting question isn't whether vibe coding is good or bad. It's that your team is almost certainly doing some amount of it right now, on a spectrum from "AI autocompleted this function signature" to "I don't actually know how this module works." And the management problems it creates don't show up in your velocity metrics. They show up four months later.

This article is about those problems — team ownership, skill formation, and codebase coherence. The mechanics of reviewing AI-generated code are a separate topic covered in code review in the AI era; here the concern is what happens to your team when the relationship between writing code and understanding code comes apart.

The Productivity Illusion

The first thing to understand is that your team's sense of how much faster they've become is not reliable evidence that they've become faster.

This is the most counterintuitive finding in the research on AI-assisted development, and it has been replicated in various forms: developers consistently report feeling significantly more productive with AI assistance, and the measured throughput on real tasks in real codebases often does not match that perception — sometimes it moves in the opposite direction. The feeling of speed is genuine. Generating a first draft is dramatically faster. What the feeling doesn't account for is the time spent afterwards: reading the output carefully, discovering the subtle mismatch with the existing system, debugging something you didn't write, and re-deriving the reasoning you skipped.

The gap between perceived and actual speedup matters for you specifically, because it distorts planning. If your team believes they're twice as fast, they will commit to twice as much. When the delivery doesn't land, the diagnosis will be "we underestimated" rather than "our estimation baseline is now systematically wrong."

None of this means AI assistance isn't worth it. In many contexts it clearly is — boilerplate, unfamiliar APIs, test scaffolding, one-off scripts, exploratory prototypes. It means you should treat self-reported speedup as a feeling, not a measurement, and hold your planning baselines to observed delivery rather than perceived pace.

Comprehension Debt

Technical debt is code that works but will cost you later because of how it's structured. Comprehension debt is code that works but will cost you later because nobody understands it.

These are different problems with different remedies. You can refactor your way out of technical debt. You cannot refactor your way out of comprehension debt — someone has to sit down and actually learn the system, which is slower and much harder to justify on a roadmap.

Comprehension debt accumulates in a specific way with AI-assisted development:

1. An engineer generates a working solution they understand at the level of "what it does" but not "why it does it this way"
2. The PR is reviewed by someone who reads it for correctness but has no more context than the author
3. It merges. It works. Nothing bad happens.
4. Four months later, it breaks in production at 2am, and the person on call is reading it for the first time — as is everyone they escalate to

Step 3 is the trap. Nothing bad happening is not the same as the system being healthy. Comprehension debt is invisible right up until the moment you need the understanding, and by then the cost is at its maximum: an incident, under time pressure, with no one who can explain the design.

The practical signal to watch for is how your team answers "why does it work this way?" in design discussions and incident reviews. When the honest answer is increasingly "I'm not sure, that's how it was written," you are accruing this debt faster than you're paying it down.

The Three Failure Modes

Nobody actually owns the code

Ownership has always been partly a fiction — the person listed in CODEOWNERS isn't always the person who understands it best. But there was a reliable floor: whoever wrote it understood it at the time of writing.

That floor is gone. When code is generated rather than composed, authorship no longer implies understanding. You can have a module with a clear owner, a clean commit history, and passing tests, where no living person can explain the concurrency assumptions.

The fix is not a policy about AI. It's a standard about ownership: submitting code means claiming you can explain and defend it. How it was produced is your business. Being able to answer for it is not optional. This single norm resolves most of the ambiguity, because it puts the burden in the right place without policing tooling.

The codebase drifts toward incoherence

Models generate code that is locally plausible. They are considerably worse at generating code that is consistent with the specific conventions of your system — because those conventions live in the parts of your codebase the model never saw, or saw in a truncated form.

The result is a slow drift. Three different error-handling patterns. Two competing approaches to data access. Utility functions that duplicate existing ones with slightly different semantics, because the model didn't know the existing one was there. Each individual instance is defensible. The aggregate is a codebase that no longer teaches you how to work in it.

This is worth naming explicitly because it inverts a property good codebases have: normally, reading the surrounding code tells you how to write the next piece. When conventions have drifted, the surrounding code teaches you three contradictory things, and new engineers — human or model — reproduce the inconsistency.

Countermeasures that actually work: strong, machine-enforced conventions (linters, custom rules, architecture tests) so that drift fails CI rather than depending on a reviewer noticing; a small number of clearly-labelled reference implementations that people and models are pointed at; and periodic convention audits where someone deliberately looks for divergence rather than waiting to notice it in review.

Junior engineers stop developing

This is the one with the longest tail and the least visibility, and it deserves its own treatment — see growing a junior engineer into a senior one for the development practice in depth.

The short version: engineers develop judgment by struggling productively. The 40 minutes a junior spends confused about why their approach doesn't work is not waste — that is the mechanism by which they build a model of the system. AI assistance can remove exactly that friction, delivering a working answer before the struggle does its job.

A junior who ships more but understands less looks like a high performer for about two quarters. Then they hit a problem the model can't solve, and there's no foundation underneath.

Seniors are largely insulated from this. They have the judgment already; AI amplifies it. The asymmetry is the point — AI assistance is most valuable to the people who need it least, and most risky for the people it appears to help most.

Setting Team Norms

Most teams have no explicit position on this, which means every engineer has invented their own. Getting the team to agree on a few things is more valuable than any specific policy you might choose.

Define what requires understanding. Not all code deserves the same standard. A one-off migration script and your payment authorisation logic are not the same risk. Draw the line explicitly rather than leaving it to individual judgment:

The fourth row is the one people skip. It's also where the expensive mistakes live.

Require the "why" in PR descriptions. Not process theatre — a genuine signal. If someone can articulate what problem this solves, what they considered and rejected, and what edge cases they're aware of, they understood their change. If the description is a restatement of the diff, they may not have.

Make it socially safe to say "I don't fully understand this yet." This is the norm that makes the others work. If admitting incomplete understanding is embarrassing, engineers will bluff, and you will find out during an incident. This is psychological safety applied to a new situation — the specific fear is looking slow or unskilled in an environment where everyone else appears to be shipping effortlessly.

Protect deliberate practice for juniors. Some work should be done without assistance, on purpose, because the point is the learning rather than the output. This has to be explicit and blessed by you, or it reads as being handed the slow path while peers move fast.

Trade-offs You Actually Have to Make

Throughput vs. resilience. More AI leverage genuinely means more shipped per engineer-week. It also means fewer humans who deeply understand the system. A team optimised purely for throughput becomes brittle in a way that only shows up under stress — an outage, a key departure, a major migration. You are choosing a point on this curve whether or not you do it consciously.

Consistency vs. autonomy. You can standardise heavily — same tools, same conventions, machine-enforced — and get a coherent codebase at the cost of engineers feeling managed. Or you can let people work how they want and accept drift. Small senior teams can survive the latter. Growing teams generally can't.

Speed of delivery vs. speed of development. These diverge. A team can deliver features quickly while the individual engineers stop developing. You will feel great about this for two or three quarters. The bill arrives when you need someone to step up into a senior role and discover that shipping volume didn't produce the judgment you assumed it did.

Hiring signal vs. hiring reality. If your interview process tests unassisted coding but the job is 70% AI-assisted, you're selecting for something you don't need. If you allow AI in interviews, you have to work considerably harder to assess judgment rather than prompting skill. Neither is obviously right, but the mismatch between how you hire and how the work actually happens is worth closing deliberately.

What This Means for Hiring and Levelling

Two second-order effects are worth planning for.

The junior hiring case gets harder to make. If AI handles much of the work juniors used to do, the short-term argument for hiring juniors weakens considerably. The medium-term consequence is an industry with no pipeline into senior roles — and for your team specifically, a dependency on hiring seniors in a market where everyone else is doing the same. Whatever you decide, decide it deliberately rather than letting it happen through hiring-freeze inertia.

Your levelling criteria may be measuring the wrong thing. If your career ladder describes progression partly in terms of implementation capability, some of what it measures has been substantially commoditised. The dimensions that have become more discriminating are judgment, system-level reasoning, knowing which problem to solve, and the ability to evaluate a plausible-looking solution and identify why it's wrong. If your ladder doesn't emphasise these, it will increasingly fail to distinguish between engineers who look similar on output and are very different in capability.

What Good Looks Like

A team handling this well is not a team that has banned AI or embraced it uncritically:

• People use AI heavily and can still explain every line they ship
• The team has an explicit, written position on where the bar is highest — and it's highest on the risky code, not uniformly
• Conventions are machine-enforced, so drift fails CI rather than depending on a reviewer's attention
• Juniors get deliberate unassisted practice, framed as investment rather than punishment
• "I don't fully understand this yet" is a normal thing to say in a PR or a standup
• Planning baselines come from observed delivery, not from how fast the team feels
• Nobody is embarrassed about using AI, and nobody is defensive when asked to explain their code

The underlying principle is simple even though the practice isn't: the tool changed, the responsibility didn't. Your team is accountable for the systems they build — how the code got written was never the thing that mattered.

Track how your team is actually developing — not just what they're shipping — with 1:1 notes, goals, and GitHub activity in one place. Try Emtricks free for 30 days — no credit card required.