The Vibe Coding Plateau
Posted on: 2026-03-27
Today, I want to talk about the difference between having a vibe coding project as a side project and using the same approach at work. The main difference is the long-term consequences of the code, but also the fact that the code will continue to be worked on by other people. I notice that many developers have extremely high coding speed with AI, and a lot of people, including management and executives, are impressed by projects that are vibe-coded during a weekend.
The problem is that a side project is very different from starting a project at work. Even without AI, when you start a new project it is very easy to get a lot of things done quickly. You can build features fast and it feels very productive. But soon you start hitting challenges: connections between services, integration with other systems, and many non-functional requirements that must be implemented.
With a vibe coding approach, you can quickly build a UI, create a database, write an API, and everything looks good at first. However, in reality there are many additional constraints. You need security, proper design alignment with what designers expect, integration with other systems, and sometimes approvals from other teams. You quickly realize that there is much more work than what you experienced on a small side project.
This is where AI velocity becomes confusing. It is true that AI increases development speed, but the gain usually follows a logarithmic curve. There is a huge acceleration at the beginning, and then the speed plateaus. You can continue to add features, but you will eventually reach a point where the acceleration slows down significantly. You cannot expect the initial speed to continue forever in a real product developed by a team.
AI can help resolve conflicts and produce quick wins, but many tasks still require careful thinking, time, collaboration between teams, and approvals. These aspects do not disappear.
My main point is about expectations. AI is excellent to jump-start development. It can provide quick progress and help solve issues when they appear. But it also produces a large amount of technical debt and requires refactoring. If you care about the quality of the code or the long-term output, you eventually need to go back into the code and improve it.
Because AI produces so much code, even reviewing it becomes difficult. In many cases you end up using AI again to review what AI produced. Everything may look fine at a high level, but common problems appear. One example I see often is duplication. AI might generate a function and later recreate a very similar function somewhere else, or produce a slightly different variation that could have been implemented with optional parameters.
AI rarely performs this type of consolidation unless you explicitly ask it to refactor. That is why some form of orchestration is needed, where AI runs a second pass on the code to refactor and simplify it. This takes additional time to build into the development process, and it is something we usually do not see in small weekend vibe-coding projects.
Why does this matter? Because today we still care about the code output. If your code base grows rapidly with duplication, AI needs to read more and more context to work effectively. At some point the amount of code simply becomes too large for efficient context usage.
Similarly, if there are no rules about file size or function size, files can grow extremely large and difficult to understand. I have seen files generated by AI with seven to ten thousand lines of code. This is not efficient for developers, and it is also inefficient for the AI that needs to read those files to continue generating code.
Overall, my conclusion is that vibe coding for a side project is very different from vibe coding for a project that must be maintained over the long term, which is the reality in most corporate environments. The velocity will naturally be lower when you need to interact with other humans, coordinate across teams, and maintain a large code base that evolves over time. Because of that, expectations about AI productivity need to be more realistic when applied to real business software.