A friend of mine said something the other day that stuck with me:
Vibe coding is actually getting harder now. Once the codebase grows, things start slipping out of control. When something breaks, I have to go back and re-read everything from scratch — the logic, the context, all of it.
My first reaction wasn't to push back. It was more like: yeah, that's probably the next stage for a lot of us.
Over the past couple of years, AI has made the "getting it built" part almost too easy. In the early days of a project — prototyping, trying directions, wiring up pages and endpoints — the speed is genuinely shocking. You describe what you want in a sentence, and something 80% usable comes back. What used to take a week to sketch out now takes an afternoon. It feels so smooth that it's easy to start believing things will just keep getting faster forever.
But a project isn't just its first sprint.
What actually slows you down tends to show up later.
Early on, things move fast because the system is still light. Not many modules, not much history, not many hidden dependencies. You change one thing, and you can still roughly remember what else it might affect. But as the project moves forward, that changes. Requirements get revised a few times. Patches pile up. A lot of the code still runs, but why it was written that way is no longer something you can explain at a glance.
At some point you realize: the bottleneck isn't "getting AI to write more." It's "understanding what's already there."
Not being able to read your own project — that's what actually makes things slow.
It's not that AI got dumber. It's not that anyone stopped trying. It's that complexity has been quietly stacking up. More code, tighter coupling, and all those little shortcuts you took to ship faster are now turning into comprehension costs. At this stage, no problem is just one problem anymore. Every issue drags a whole chain of context behind it.
And here's the thing people tend to forget: AI isn't writing code in a vacuum either. Once a project gets complex enough, AI hits the same wall humans do — tech debt.
In the early phase, you let a lot of things slide because shipping matters more. Naming conventions? Later. Code structure? Later. Duplicated logic? Leave it for now. Edge cases? Patch it and move on. None of that is a real problem when the project is small, because the priority is to get the thing out the door. But once the project gets heavy, all those "deal with it later" decisions start biting back.
The most common symptom looks like this: you ask AI to handle a small feature, and it ends up touching a dozen files. A tweak here, an adjustment there — each change looks reasonable on its own, but taken together, things start falling through the cracks. A missed branch, a forgotten condition, two changes that quietly contradict each other — and suddenly bugs are popping up everywhere. Then manual testing costs spike too, because you can no longer just test the one thing you changed. You have to re-check everything it might have touched.
There was another line from that conversation I thought was spot-on:
This is decided by the nature of the work, not by the people doing it.
A lot of managers naturally assume that since AI has cranked up the development speed, the team should just stay in high gear indefinitely. From a business perspective, that's perfectly understandable. Everyone wants things faster.
But projects have their own rhythm.
The first phase is exploration. The second is digestion. First you get things built. Then you go back and make sense of what you built. Slowing down at this stage isn't necessarily a failure — more often, it's a sign that the project has reached the point where it genuinely needs to be untangled.
At its core, this is really about attention.
Whether it's a person or an AI, you can only truly focus on one thing at a time within a given phase. When the focus is on shipping features fast, everything naturally leans toward "just get it working." Code structure, boundary handling, maintainability — those all get deferred. And once enough features have piled up, continuing at that same pace gets increasingly expensive.
The healthier approach isn't to run at one speed from start to finish. It's to accept that development should move in phases: push hard on features to hit the key milestones; then pause, do a round of refactoring and cleanup, bring maintainability back up, pay down some debt; then move into the next round of feature work; then clean up again.
Before AI, this phase used to be genuinely painful. You'd have to grind through the code yourself, dig through commit histories, piece together scattered conversations, ask the one person who still remembered how things worked. Now it's different. AI doesn't just help you write — it should also help you read. And it should help you pay off what you owe.
I'm increasingly convinced that the second half of vibe coding naturally leads to something else: vibe reading.
The term might sound new, but the idea isn't. It just means using AI to re-read your project. Not some vague "analyze the codebase" prompt, but actually working through the stuff that gets people stuck: how the core modules connect, where the critical call chains run, which parts are most tightly coupled, which changes look small but carry real risk, which bugs aren't new bugs at all but old tech debt finally surfacing.
It doesn't sound as exciting as "generate a feature in ten minutes," but it's often more important. A lot of projects don't die because nobody could write the code. They die because nobody dares to touch it anymore. The codebase keeps growing, fewer people understand the full picture, and eventually every change feels like opening a mystery box. On the surface it looks like progress has slowed. What's actually happened is the team's understanding can't keep up with how fast the system has expanded.
And vibe reading isn't just about comprehension for its own sake — it's about clearing the runway for the next iteration. Once you've straightened out the structure, consolidated duplicated logic, merged the spots that are easy to miss, and surfaced the risk areas early, AI can go back to building features with a lot more stability. Otherwise, features keep stacking, the testing surface keeps expanding, and eventually either dev time or test time — or both — gets eaten alive.
So when a project reaches a certain stage and enters a relatively "slow" period, I now read that as a signal: it's time to start reading.
The most valuable thing at that point usually isn't piling on more features. It's using AI to catch up on everything you deferred. Map out how modules relate to each other. Find the historical baggage. Trace the critical paths. Spot the places that are going to blow up eventually. Most problems, once they're actually articulated clearly, turn out to be less scary than they seemed.
At the end of the day, AI obviously makes development faster. But the only kind of speed it delivers shouldn't be "writing faster." It should also help you recover understanding faster, regain the big picture faster, and pull a project that's starting to spin out back into a controllable state.
That might be what actually matters in the next phase.
Not being fast all the time — but knowing when to be fast, when to stop and read, and when to stop and pay down what you owe.
Every AI-driven project will probably arrive at this point eventually. Whether you make it through depends less on who's better at writing prompts, and more on who can re-read the system faster — and who knows when it's time to shift attention from "keep adding features" to "get the house in order first."