AI coding can create a short productivity spike while leaving behind persistent complexity and static analysis warnings.
2
Human reviewers often accept incorrect AI advice, so code needs independent automated verification.
3
AI coding agents should receive constraints before coding, run verification inside the inner loop, and fix detected issues before continuing.
Summary
Anirban Chatterjee argues that AI-generated code needs a verification process built around zero trust and multiple review methods. A Carnegie Mellon study of GitHub projects found that the productivity increase from AI coding lasted about three months, while static analysis warnings and code complexity remained elevated. Human review is also unreliable under heavy load. Chatterjee cites a Wharton study in which participants followed AI advice 92.7% of the time when it was correct and nearly 80% of the time when it was wrong. His proposed agentic development cycle, ACDC, has three parts: guide the agent with architecture, dependencies, coding standards, and quality criteria; verify its output with independent computational and reasoning-based checks; then let an agent solve the issues found. Verification should run both while the agent writes code and later in the CI/CD and pull request process.
AI coding can leave a lasting verification debt after its productivity gain fades
Chatterjee describes a Carnegie Mellon study that sorted GitHub projects by whether an AI tool, in this case Cursor, wrote the code. The projects showed a temporary productivity increase that lasted about three months. Static analysis warnings and code complexity increased at the same time, and those problems persisted after the productivity spike ended. He calls the resulting gap between the quality an AI tool produces and the quality an application needs verification debt. A short-lived internal project may tolerate that gap. A large codebase with many users and possible adversaries needs a much higher quality level before release.
Models lack the business and codebase context that engineers carry
Chatterjee says AI models still make mistakes and have quality issues because of how they are built. They only know the context given to them. They do not automatically know what is happening elsewhere in the codebase, what the business needs, or what was decided in a meeting two weeks earlier. That missing context can make the generated implementation differ from the software the team actually needs. He also says models have different strengths and different failure patterns, so teams should not assume that one model will produce the best result on every quality measure.
Model selection should depend on the quality property the task requires
Sonar's LLM leaderboard evaluates major models on about 4,000 coding tasks with the metrics SonarQube uses for code. It compares correctness, task-solving performance, complexity, maintainability, reliability, and security. Chatterjee uses Claude Opus 4.6 and Claude Sonnet 4.6 as an example. Sonnet performs well for correctness and solving tasks, while Opus may be a better choice when maintainability, security, or lower complexity matters more. The comparison is meant to show where each model performs well and where verification remains necessary.
Human review can become rubber stamping when AI output grows
Chatterjee cites a Wharton study in which participants used an AI tool that had been instructed to lie confidently some of the time. They followed the AI's advice 92.7% of the time when it was correct, and nearly 80% of the time when it was wrong. He expects a similar problem in code review, especially when several agents write code at once and people must combine large amounts of output. Reviewers have limited time and still need to ship, which creates pressure to accept suggestions without enough scrutiny. Automated verification is his proposed backstop.
Independent verification should assume the code came from anywhere
For Chatterjee, zero trust means treating code as though it could have been written by a person, an AI, or any one of several different models. The system that wrote the code should not be the only system validating it, because it may carry the same blind spots. Verification should use a different method, apply the same process regardless of the code's origin, and produce results that are auditable, explainable, algorithmic, repeatable, and consistent. This creates a standard check instead of relying on the identity or reputation of the generator.
Chatterjee says no single technique can find every type of software problem. Verification therefore needs multiple layers, including computational review and LLM-driven reasoning review. SonarQube checks syntax, data flow, architecture, and control flow, while the reasoning-based layer can inspect code in another way. His ACDC, or agent-centric development cycle, puts verification at the center of the agent loop. The process also covers quality, security, and compliance, so a team can check more than whether the code simply runs.
Agents should receive constraints first and fix findings inside the coding loop
ACDC has a guidance phase before generation, a verification phase during the loop, and a solve phase after issues are found. Guidance gives the agent guardrails, relevant context, architecture constraints, allowed dependencies, coding patterns, logging and observability practices, and quality criteria. Verification then reports problems while the code is being written. The agent can use available tools to remediate those findings immediately and repeat the loop. Chatterjee says this prevents issues from propagating into later loops that build more of the project.
The same verification regime should run in both inner and outer development loops
Chatterjee separates the inner agentic loop from the outer CI/CD loop. In the inner loop, a coding agent gets focused context, writes code, calls verification, and fixes issues before moving on. In the outer loop, a pull request receives a broad automated review. Gitarr provides an LLM-driven review, while SonarQube performs computational checks and assigns grades for quality, security, and maintainability. A fix agent can address findings, but the pull request cannot proceed to testing, building, and deployment until it passes the quality gate.
"You're not going to want to use that same AI to validate the code because you're going to want a diversity of tools being used to make sure that you're catching all the different issues that can happen."09:40
Who should watch
You are deploying AI-generated code into a large or security-sensitive application and need checks that do not depend on the model that wrote it.
Your team is relying on human review but reviewers are handling more generated code than they can inspect carefully.
You are building agentic coding workflows and need a concrete pattern for supplying context, checking output, and remediating issues before they spread.
