I'm doing my best to embrace vibe coding, but here's where I draw the line.
Picture this scenario: You receive a PR to review. You look at the code and don't understand what it does. You ask the developer who wrote it, let's call him the "viber". You ask the viber to explain his changes. His response? Can't tell you what the code does either.
Sure, we might agree on the high-level goal: "this PR will fix bug X." That's a start. But here's the problem: both you as the reviewer and the viber now have to reverse-engineer the solution together. You're both staring at code trying to figure out not just whether it works, but what it's actually supposed to do.
This breaks down for a simple reason: if you're pushing a large PR that you can't fully explain, you won't be able to help anyone else understand it either. When bugs inevitably surface, when edge cases emerge, or when someone needs to modify this code six months from now, the viber becomes a bottleneck they can't even unclog themselves.
Vibe coding has its place: rapid prototyping, creative exploration, getting unstuck when overthinking blocks progress. But the moment you ask someone else to review, approve, and maintain your code, you cross from personal experimentation into collaborative responsibility. At that point, being able to articulate what your code does isn't just helpful—it's essential.
The line between creative coding and professional responsibility runs right through the PR process. Thread softly.