I built a tool that won't let you merge AI-written code until you can explain it. And it completely changed how my team uses AI assistants in production.
It started with a 3:00 AM incident. A new developer had used an AI assistant to write a small payment validation function. It passed code review. It passed our tests. Then a customer on a legacy plan triggered an edge case, and the function charged them twice. When we looked at the code, no one — not even the developer — could explain what the regex was doing. We spent three hours unspooling a 20-line function that an AI had generated in seconds.
That's the hidden cost of vibe coding: you merge code you don't understand, and the technical debt comes due at the worst moment.
The Vibe Coding Trap
"Vibe coding" — the practice of writing prompts and letting an LLM produce entire functions or modules — is everywhere. It's seductive because it works. For simple CRUD endpoints, config files, and boilerplate, AI code is often better than what a tired developer would write on a Friday afternoon.
But there's a difference between generating code and understanding it. In a 2023 study published at ACM CCS, researchers found that developers using AI assistants were significantly more likely to believe their code was secure — while actually writing less secure code. The tools made them overconfident. That overconfidence carries straight into merge requests.
When you merge AI code you can't explain, you are signing a contract on behalf of your future self and your whole team. If it breaks, you have no mental model to debug it. If a security issue appears, you can't assess the blast radius. If a junior developer introduces a subtle logic error, no reviewer will catch it because the code "looks generated" — and somehow that makes it seem safer.
Why "Explain It or Block It" Works
I built a simple tool that solves this by attacking the root cause: the sheer ease of merging something you don't understand.
The tool hooks into your existing merge workflow. It listens to pull request events on GitHub and runs as a branch protection rule. It doesn't care which AI assistant wrote the code — it only checks that you can explain it. (ASI Biont supports connecting to GitHub via API — learn more at asibiont.com/courses.)
When you open a pull request that contains AI-generated code, it runs a check. But it doesn't try to detect AI code by scanning for patterns or comments. Instead, it asks you a question:
"Explain what this code does and why it's correct."
Your answer has to be a genuine technical explanation: what the function does, how it handles edge cases, why the algorithm is the right one. The tool uses an LLM to score the explanation against the diff. If the answer is vague, high-level, or just repeats the code comments, the merge is blocked.
The key is that the explanation must be in your own words, not an AI's summary. I tried letting the LLM generate the explanation automatically — it worked logically, but it didn't improve anyone's understanding. The point is not to document the code; it's to force a human to engage with it.
What Happened When We Used It
We rolled this out on a real production repository for a microservices platform with twelve developers. In the first two weeks, the tool blocked about 30% of all merges that contained AI-generated code. The most common explanation was "the AI wrote it and the tests passed." That's exactly what we wanted to stop.
One specific case stayed with me. A developer tried to merge a change to our subscription renewal logic. When asked to explain the code, he froze. He couldn't explain why the new date calculation worked. That lack of explanation led him to actually hand-trace the logic with a calculator — and he found that the AI had off-by-one errors for 31-day months. The tests didn't catch it because they used a stub clock. That single explanation gate prevented a billing bug that would have hit thousands of customers.
Here's a before-and-after look at how the gate changed our team's relationship with AI code:
| Metric | Before (merge and hope) | After (explain to merge) |
|---|---|---|
| Merge time for AI changes | 10-15 minutes | 25-30 minutes |
| Hotfixes caused by AI code | 5-6 per sprint | 1 per sprint |
| Developer confidence in AI code | Low, but ignored | Genuine understanding |
| Code review quality | Superficial ("tests pass") | Focused on design and edge cases |
The extra 15 minutes per merge is nothing compared to the hours we used to spend debugging AI-generated code in production.
How You Can Do This Without a Custom Tool
You don't need my tool to get the benefit. Even if you're working solo or with a small team, you can apply the same principle manually.
Before you let Copilot, Cursor, or ChatGPT write production code, require yourself to answer these three questions:
- In one sentence, what does this function do? If you can't, you don't understand it.
- What's the edge case the code handles? If you don't see one, you haven't read carefully enough.
- Can you trace the logic for a concrete input? Pick a real value and walk through the code line by line.
This is essentially rubber-duck debugging applied to the merge process. The Atlassian guide to code review points out that the act of explaining your own code is one of the most effective ways to find bugs — even before a human reviewer looks at it. Combining that with AI-generated code is a powerful self-check.
I now treat the AI as a junior developer on the team. I wouldn't let a junior merge a module they couldn't explain at a whiteboard. Why would I let an AI — or a human riding the AI's output — do the same?
The Merge Gate Is a Mindset
The tool I built is simple — a script, a prompt, and an LLM call. The hard part was convincing my team that a 20-minute deep dive into AI code is worth it. It took one production incident to make the case.
There is no such thing as "zero-click code." If you're not paying for understanding, you'll be paying for it in incidents, rollbacks, and onboarding slowdowns. The most important code reviewer is not the one on your team — it's the one in your own head.
A merge gate that asks for an explanation is just a forcing function. The real gate is your own willingness to say: "I don't get this yet." In 2026, when AI writes more code than we do, that's the skill that separates developers from people who just assemble autocomplete.
Comments