How We're Trying to Solve Vibe-Coded PRs

When companies start embracing AI, it's only a matter of time before it reaches the engineering teams. For competent developers, AI makes their lives easier. The benefits of tools like Cursor or Copilot are often invisible because developers use them as tools to accelerate their workflow, not replace it. It's confusing when companies claim a specific percentage of their code is "AI-generated," since these tools function as assistants. With that logic in mind, could we say a certain percentage of code was "StackOverflow copy-pasted"?

But every now and then, someone starts using AI to completely take over their position. They write a prompt to generate code that fixes a task, test that the task is resolved, and then commit the code. Sometimes the code is committed without any further review. These commits typically involve a large number of lines changed, a coding style that differs from the team's conventions, and changes that sometimes make no sense at all.

Many developers treat PR reviews as personal criticism, which can feel harsh or rude. Meaning people hold back and let nonsensical code get merged. To avoid these issues and the politics of "AI vs. Anti-AI", we started implementing a process that helps us address vibe-coded PRs without the criticism.

The Staged Review

I asked my most senior developer to vibe-code a solution to a relatively simple ticket. After a couple of people approved it, I scheduled a video call (including known vibe-coders) where the senior develoer had to explain the PR. Since this was a staged review, I asked detailed questions: Why were certain choices made? Why did the coding style change? Why create a new endpoint instead of adding functionality to existing code? We scrutinized every part of the code.

Changes were made, we reviewed again, and the team began to understand what the bar is for our work.

Why go through this dance instead of simply saying "don't vibe code" or "review your code thoroughly"? Because people use LLMs to save time. If they don't have time to write the code, they certainly won't spend time reading it. What they do is generate code, test it, and if the functionality works, move it forward. It's rare for any vibe-coder to actually read the code they've generated.

But seeing the scrutiny placed on these PRs forces developers to spend more time with their code. They realize they need to understand what they're submitting.

Raising the Bar

It's one thing to quickly create features when building an MVP, but the bar is much higher when contributing to existing software. When you write code, part of the process is thinking about your future self and how other developers will read and extend your work. You need to be consistent with the team's style, even if it's not always the optimal choice. The goal is for any developer to read the codebase as if it were written by one person.

Just a few days ago, I wrote about how when we use LLMs, we tend not to read the results before passing them to the next person down the chain. Putting a system in place that forces you to understand your work helps both developers and reviewers contribute meaningfully.

---

This is an experiment, and so far, I think it's working. But the world of LLMs is ever-changing, and we haven't settled on the rules yet. Maybe six months from now, vibe-coding will be reliable enough. But until we get there, we need to find ways to ensure we're still producing high-quality code that teams can collectively understand and maintain.

---