Sajeel Qureshi and Joe Jerome got on a call to talk AI code review and MCP servers, and somehow ended up twinning in matching quarter-zips instead. The AI insights survived anyway. Here's what they had to say.
AI code review tools catch a lot, but they should never be the only gate before code reaches production. Independent research shows AI-generated code introduces security vulnerabilities in roughly 45% of tasks, and AI-assisted commits leak credentials at about double the normal rate. The fix is building a layered process: AI does the first pass (checking for exposed secrets, common vulnerability patterns, and deviation from your team's coding standards), and a human editor or team lead reviews before anything ships to a client. This post breaks down why that human layer still matters and how to structure the workflow.
AI code review tools are genuinely useful. They catch things fast, they don't get tired the way a person reviewing their tenth pull request of the day does, and they can be trained on a team's own internal coding standards so every review is measured against the same bar. But "useful" isn't the same as "sufficient." AI models are inconsistent by nature. They can miss the same issue twice, approve something they flagged as risky an hour earlier, or lose context on a long, continuous review session. Treating AI output as a final answer instead of a first draft is where the real risk creeps in.
The comparison that comes up often in agency conversations is the newspaper editor. A publication doesn't skip editing because its writers are experienced. It keeps editors specifically because even good writers make mistakes, and a second set of eyes catches things the first set missed. As Sajeel Qureshi, CEO of Computan said in the UNWatchable episode 1, "It's like if you're running a newspaper, you have no editor and you're running, you're just publishing stories. That's a huge risk... we have editors and we have other senior editors, and we still make those mistakes. So now we have an AI that's also editing the tool too." AI code review works the same way, except now there are two editors: the AI and the human who reviews what the AI flagged (or didn't flag).
The statistics here aren't theoretical. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found that AI-generated code introduced security vulnerabilities in 45% of cases, with models choosing the insecure implementation almost as often as the secure one1. Independent research from Apiiro found similar patterns at the enterprise level, with high-severity vulnerabilities appearing significantly more often in AI-generated code than in human-written code3.
Credential exposure is its own problem. GitGuardian's latest research found that public commits assisted by AI coding tools leak secrets, like API keys and database credentials, at roughly double the baseline rate seen across GitHub generally2. The same research flagged a newer risk specific to agencies building AI integrations: Model Context Protocol (MCP) configuration files, where documentation often shows credentials hardcoded directly into config examples, a pattern developers then copy into production2. Once a secret is exposed, it tends to stay exposed. GitGuardian found that a majority of credentials leaked years ago were still valid and exploitable when checked again4.
None of this means AI tools are unsafe to use. It means unreviewed AI output is a liability, in the same way unreviewed human-written code has always been a liability, just faster and at higher volume now that AI accelerates how much code gets produced.
A practical way to picture an AI code review agent is as a checkpoint sitting in front of a repository, similar to a customs check at a border crossing. Before a developer's code is allowed to merge, the agent inspects what's being brought in: is there a hardcoded password in here, is there an exposed API key, is there a pattern that looks like a SQL injection risk, does this deviate from the team's own coding standard. If something doesn't belong, it gets flagged and sent back before it can move forward. Sajeel Qureshi, CEO, Computan, puts it correctly in this border analogy, "There's third party tools you can use to connect your GitHub repos that sit in front of them... these agents check in and say, hey, this can go through, this can't go through. It's kind of like if you're driving across a border. They'll say, okay, what are you bringing in? There's not a mango in this one, you can have this one. This one's got bananas, and bananas are welcome. Mangoes can't go in... it just tells you, before you can bring this one in, you gotta do this to it first."
This is the model behind a growing category of tools, credential and secret scanners like GitLeaks, paired with AI review agents trained on a company's internal standards. The AI agent isn't just checking against a generic security checklist. It's checking against rules the team itself wrote down: how they want frontend code structured, how backend logic should be handled, what an acceptable dependency looks like. That combination, general security scanning plus team-specific standards, is what makes the review meaningful rather than generic.
Even with an AI layer in place, human reviewers, typically team leads or a dedicated QC function, remain the final gate before code reaches a client. Historically, this meant senior developers reviewing every line from every team member before anything went live, a process that scales poorly as a team and its output grow. Adding an AI first pass doesn't remove that human step, it changes what the human is reviewing. Instead of reading every line cold, the reviewer is confirming or overriding what the AI already flagged, which is a faster and more focused review than starting from zero.
It's also worth being direct about a failure mode: humans miss things too. Team leads have their own projects, their own deadlines, and their own blind spots. That's exactly why the two-layer approach works better than either layer alone. The AI doesn't get tired or distracted, but it hallucinates and loses consistency. The human doesn't hallucinate, but does get tired and distracted. Neither one is a complete solution by itself.
A single AI review pass often isn't the whole review. AI models can behave inconsistently, especially across a long session where context gets diluted, sometimes referred to as the model "losing the thread" over an extended context window. In practice, this means a first review pass can miss something a second pass catches, simply by re-prompting the model to check its own work again, sometimes framed as asking it to take on a more critical role, like a security auditor, before re-checking the same code. Building this kind of re-check cycle into the process, rather than accepting the first output as final, meaningfully improves what the AI catches.
In practice, that can be as simple as a direct instruction, "The context window gets too extended from a continuous string. It does get tired and starts to get confused. Part of your prompt could be, okay, go back and check it again. Now that you did the work, put your top-end security auditor hat on and review it again." - Joe Jerome, Chief Revenue Officer, Computan.
Here's a practical structure for building this out, based on how a layered AI and human review process typically comes together for a development team:
AI review tends to be strongest at consistency and speed: checking every single submission against the same standard, every time, without fatigue, and catching pattern-based issues like exposed secrets or known vulnerability signatures almost instantly. Human review tends to be strongest at judgment calls: understanding business context, knowing which shortcuts are acceptable for a specific client's risk tolerance, and catching subtle logic errors that don't match a known pattern. Neither replaces the other. The strongest process uses AI for volume and consistency, and humans for judgment and final sign-off.
The AI is watching us, we're watching the AI. It's like the AI is kind of like another human employee... it hallucinates, it makes mistakes." - Joe Jerome, CRO, Computan.
AI code review is a genuine productivity gain, not a threat to replace with caution. It catches things faster than a manual-only process ever could, and it applies the same standard to every submission without getting tired. But the data is clear that AI-generated code carries a materially higher vulnerability rate than human-written code, and unreviewed AI output creates real liability, especially for agencies handling client data. The businesses getting this right aren't choosing between AI and human review. They're building both into the same pipeline, with AI handling first-pass volume and humans handling final judgment.
Yes. Research shows AI-generated code introduces security vulnerabilities in roughly 45% of coding tasks1, and AI-assisted commits leak credentials at about double the typical rate2. AI review tools are strong at consistency and pattern detection, but a human reviewer is still needed to make judgment calls, understand business context, and serve as the final gate before code reaches production.
A well-built AI code review process typically checks for exposed API keys and passwords, common vulnerability patterns like injection risks, outdated or inefficient code, and deviation from a team's own coding standards. Dedicated secret-scanning tools are often layered in separately to specifically catch hardcoded credentials before they reach a commit history.
No. AI review is best positioned as a first pass that filters and flags issues before a human ever sees the code, which makes the human review faster and more focused, not unnecessary. Removing the human layer entirely removes the judgment and business-context checks that AI review can't reliably replicate.
AI models can be inconsistent, particularly across long review sessions where context can get diluted. Re-prompting the AI to check its own output again, sometimes with a more targeted or critical framing, often catches issues a single pass missed. Building this kind of re-check cycle into the workflow is part of a reliable process, not an optional extra.
It can be, if access isn't scoped carefully. This applies both to AI code review tools and to AI connectors (like MCP servers) used for CRM or business data. The safest approach limits what each connection can see and do, similar to setting user roles and permissions for a human employee, so a single connection doesn't have unrestricted access to sensitive systems.