Who's Checking the AI's Work? Building Vinya

The problem I kept running into

AI coding agents have gotten genuinely good at writing code. What they haven't gotten good at is knowing when their own work is wrong. An agent will confidently ship a change that breaks an edge case, misunderstands a requirement, or quietly introduces a regression — and nothing in the loop catches it, because the thing doing the work and the thing checking the work are the same system, with the same blind spots.

Human code review was supposed to be that check. But as agents write more and more of the code, review becomes the bottleneck — a person can't keep pace with an AI that ships changes continuously, and rubber-stamping a diff you didn't have time to really read isn't review, it's a formality.

That gap is what led me to start building Vinya: a QA layer that runs alongside coding agents, continuously, watching the work as it happens rather than waiting to be asked.

The core idea

Vinya isn't a linter and it isn't a second AI generating more code. It's an independent layer whose only job is verification — watching what an agent does, checking it against what was actually intended, and surfacing problems before they become someone else's bug report. It runs always-on, in the background, rather than as a step someone has to remember to trigger.

The distinction that matters most: Vinya is deliberately separate from the agent doing the building. A system grading its own homework inherits all of its own assumptions and blind spots. A separate layer, built specifically to notice when work doesn't match intent, catches a different category of mistake — the kind that looks fine to the system that made it, but isn't fine at all.

Why this matters

A few beliefs are driving this project:

• Autonomy without verification isn't a feature, it's a liability. The more independently an agent operates, the more critical it becomes that something is actually checking its work — not just trusting that it went well.

• Review has to scale with generation, or it becomes theater. If agents can produce work faster than humans can meaningfully review it, "a human looked at it" stops meaning anything unless the review itself is supported by continuous, automated verification.

• Catching a problem is only useful if it happens early. QA that runs after the fact, once code is already merged and shipped, is far less valuable than QA that's watching continuously as work happens.

Where this is headed

The current build proves the core loop: an always-on layer that observes agent activity and evaluates it against intent, running quietly alongside the coding agents doing the actual building. From here, the focus is refining how much nuance that verification layer can catch, and how naturally the results surface to the humans who need to act on them.

I'm always glad to talk through the thinking in more depth — just reach out.