Anti-Patterns in Vibe Coding
Recently I participated in a project that heavily leveraged Vibe Coding under a tight timeline and produced a large amount of generated code. Initially, the project moved fast, but as iterations went on, the drawbacks of Vibe Coding started to emerge. It took great effort for the team to refactor the codebase and fix those issues. In this post, I will summarize some of the anti-patterns that I observed in Vibe Coding and share some lessons learned from this experience.
Anti-Pattern: Everyone Is a 10x Engineer Now
Until Someone Has to Review the Code
How it started:
At the beginning of the project, the team adopted an open contribution model where anyone, including people without a technical background, could work on any module and submit any amount of code without clear constraints. This gave the project a short-term boost in output, but it also blurred ownership boundaries and made it much harder to keep the architecture, implementation quality, and review standards under control.
The consequences:
So everybody was contributing code, whether the individual was a senior engineer or a non-technical person. The amount of generated code was huge: a non-technical person could generate 10k lines of code a week, leaving senior engineers to spend a lot of time reviewing and refactoring the code. The problem was not that non-technical people participated in the project, but that the project lacked strong review gates, module ownership, and architectural constraints.
Some of the core modules were modified by several different people at the same time via Vibe Coding, which made the overall architecture messy and hard to maintain. This was also partly because the project lacked clear documentation and design guidelines, which is another anti-pattern that I will discuss later.
Lesson learned: The velocity and the boundary should always be controlled by human developers.
Yes, it is true that agents nowadays can generate code at a very high speed, but speed is not the only thing that matters. For projects that need to be maintained for the long term, code quality is more important:
- The generated code should comply with the existing project architecture and coding style, which should be defined and overseen by human developers with solid engineering backgrounds. Otherwise, the codebase will gradually drift into a spaghetti architecture that is expensive to maintain.
- In a large-scale project, it is still important to have a clear ownership boundary for each module, and human developers should be responsible for the design and implementation of the module.
Anti-Pattern: Trust the Agent, Blame the Developer
The Model Hallucinates; Developers Take the Fall
How it started:
The project claimed to be AI Native-driven, and the team was encouraged to let agents do everything: backlog grooming, implementation, and writing deployment pipelines.
The consequences:
Some of the generated code did not work as intended. The QA team did not verify the features properly because the documentation was not clear enough, and the human developers did not verify them properly because they assumed the agent would do it better than they could.
Lesson learned:
Oh yes, agents facilitate a lot of things. They generate feature backlogs, code, and deployment pipelines. But in the end, when the team delivers the product to users, it is still the human team members’ responsibility to make sure the product delivers the features that users actually need and works without critical bugs.
So maybe the most important thing about Vibe Coding in an AI Native team is not simply letting agents help humans execute every step in the SDLC. Human team members should still be aware of the details, validate the agents’ output, and make sure the product is delivered to users with high quality.
Anti-Pattern: It’s Just a Prompt, Ship It Tomorrow
Planning Is Apparently Legacy Tech
How it started:
No clear feature roadmap or task management tools were used in the project. Requirements were not clear. Features were not well defined and were usually passed to the team in a very ad hoc way. When senior engineers suggested that a feature needed design work and some additional time to fit into the existing architecture, the planning effort was often underestimated: “Why does this feature even take a week? It is just a prompt, why bother to plan? Just let the agent do it; it will do even better than you. Can you finish it tomorrow?”
The consequences:
Oh yes, the cost came back. Since there was no clear feature roadmap, some requested features actually conflicted with previous ones, while others relied on upstream services or modules from different teams that were not ready yet. It was difficult to provide an exact timeline for code readiness, code review, QA testing, and eventual deployment.
The promised delivery date was purely a subjective estimation, without any clear understanding of the underlying progress.
Lesson learned:
When it comes to a large-scale project, it is still important to have a clear feature roadmap and task management tools. Leave AI to handle the most modular and atomic tasks, but human developers should still be responsible for overall project planning and management.
Conclusion
So, how should AI Native really work in a large-scale team?
In my opinion, AI Native should not mean removing engineering discipline. It should mean making engineering discipline more executable through agents. Humans should still define the ownership boundary, architecture, product requirements, delivery plan, and quality bar. Agents should accelerate the implementation within those boundaries.
The problem with Vibe Coding is not that AI writes code. The real problem is when the team starts to believe that AI can replace ownership, planning, and accountability. Once that happens, the project may look extremely productive for a short period of time, but the hidden cost will eventually come back as messy architecture, unclear responsibility, unreliable delivery dates, and a huge review burden.
In a large team, AI Native is not democracy over the codebase. It is disciplined automation under clear human ownership.