Guide, Verify, Solve: The Engineering Discipline Agentic Development Demands

What makes AI-assisted development repeatable enough to move from experiments into software that other people depend on? The transition resembles an earlier shift in cloud computing: powerful technology becomes broadly useful when engineers make it consistent, scalable, and trustworthy. Anirban Chatterjee, a former software engineer who introduces himself as working in product marketing at Sonar, places safety and trust at the center of that transition.

The opening evidence is a study of Cursor adoption in GitHub projects. Chatterjee describes a temporary productivity increase that disappears around the three-month mark, alongside a persistent increase in static-analysis warnings and code complexity. The corresponding paper, Speed at the Cost of Quality, makes the measurement more precise: repository velocity means commits and lines added, and the gains dissipate after two months. Configuration files serve as a proxy for Cursor adoption; they do not establish which tool authored each change.

SonarQube supplied the study’s warning and cognitive-complexity measurements. Warnings identify potential issues, not necessarily confirmed defects, but their persistence matters: a burst of additional code can leave a larger maintenance burden after the initial velocity gain has faded. Chatterjee proposes that this burden helps explain the slowdown. That is a plausible mechanism, rather than a causal conclusion established by the account presented in the talk.

A short-lived internal experiment can tolerate a relatively small gap between generated code and acceptable code. Perhaps its only user is its author; perhaps a small team will discard it next week. The requirements change when the same development approach serves a large, frequently changing codebase, many users, and adversaries actively trying to break the application.

Verification debt is the work required to close the gap between the agent’s default output and the quality the application needs. Engineers must close that gap before shipping. The slide’s rising required-quality curve and flat agent-quality line illustrate this relationship conceptually; they are not measured quality scores.

Model improvements do not remove the underlying problem. Chatterjee mentions wanting to try the newly available Fable, but emphasizes that even strong models remain error-prone. Errors that are tolerable during exploration can have serious organizational consequences in production.

Missing context creates another source of failure. An agent may not know about changes elsewhere in the repository, the business objective behind a feature, or a decision made in a meeting two weeks earlier. The engineer carries those constraints into the task; the model only has the context supplied to it. A locally reasonable implementation can therefore miss the actual objective.

Models also make different kinds of mistakes. Chatterjee describes the Sonar LLM Leaderboard as evaluating models on approximately 4,000 coding tasks. Its evaluation considers correctness, task-solving rate, complexity, maintainability, reliability, and security. A single success score cannot express all of those properties.

The displayed comparison pairs Claude Sonnet 4.6 with Claude Opus 4.6. Chatterjee’s interpretation is that Sonnet performs well on correctness, task solving, and reliability, while Opus may be useful when maintainability, security, or lower complexity matters more. Switching models to manage token spending can therefore change the quality profile of the resulting code. These are the profiles discussed in the recording; the leaderboard changes as new evaluations arrive.

Model selection and verification solve different problems. Selecting a model can improve the starting point for a particular task, but the selected model can still produce code that should not ship. Verification remains part of the loop regardless of which model generates the change.

Reading the generated code is an obvious verification step, but confidence in an assistant can undermine the reviewer’s independence. Chatterjee introduces Wharton research in which participants could use an AI assistant that was instructed to give confidently incorrect answers on some trials. In Study 1 of Thinking—Fast, Slow, and Artificial, participants followed the advice on 92.7% of AI-accurate trials and 79.8% of AI-faulty trials, conditional on using the chatbot. The tasks were adapted Cognitive Reflection Test questions, not code reviews.

The code-review connection is Chatterjee’s extrapolation: several agents can generate changes simultaneously, while a human still has to understand the combined application and ship on a deadline. Higher volume and integration work create pressure to rubber-stamp plausible output. Automated checks provide a backstop that does not depend entirely on the reviewer resisting that pressure.

There is also a distinction between understanding a function and understanding the software around it. A correctly written function can behave predictably under its assumptions. Requirements, external dependencies, interactions with other code, and unexpected user behavior make whole-system behavior harder to establish. Chatterjee frames this as the difference between provable code and software that breaks in novel ways. Automated verification controls some of the risk introduced when developers delegate more of the implementation; it does not make the surrounding system disappear.

The first requirement is zero-trust verification: apply the same comprehensive checking regime whether a human, one model, or another model wrote the code. The verifier should use a different methodology from the generator. Algorithmic checks provide an auditable, explainable, repeatable basis for deciding whether the change satisfies a rule, instead of asking the generating model to endorse its own work.

The second requirement is multilayer verification. Computational analysis and LLM-driven review contribute different forms of scrutiny. The demand for independence does not exclude LLM review; it means that LLM review cannot be the only basis for trust. One or two techniques will not uncover every problem in software.

Sonar calls its framework AC/DC, the agent-centric development cycle. Chatterjee introduces verification first because he sees it as the fastest phase to implement now: a multilayer review spanning quality, security, and compliance. He then places guidance before it and remediation after it.

The resulting execution order is:

1. Guide: Supply the context, guardrails, and constraints the agent needs before it writes code.
2. Verify: Evaluate the generated change against the required criteria.
3. Solve: Give the agent access to the tools and findings needed to repair detected problems, then repeat the loop.

The useful unit of work is therefore not just a generated patch. It is a patch that has passed through a feedback cycle in which detected issues can be corrected.

The organizational reasons for adopting this cycle extend beyond finding individual bugs:

• Consistent verification: Apply a standard rulebook across projects, teams, and coding tools.
• Effective AI use: Manage token spending and match models to work they handle well.
• Earlier security detection: Find security issues before they reach production. Chatterjee points to the possibility of exploitation on the day a CVE is announced as a reason to shorten that window.
• Provable compliance: Preserve an audit trail showing that required checks ran consistently, especially in regulated environments.

SonarQube supplies computational verification across syntax, data flow, architecture, and control flow. Chatterjee describes broad language coverage and agent-facing integration points that expose those checks directly to coding tools. He then introduces Gitar, the San Mateo company Sonar had recently acquired, as the complementary AI code-review component.

Gitar’s role extends into CI workflow automation: it can identify issues with LLM review and block changes that fail the required quality standard. Chatterjee describes optional capabilities to write fixes, approve them, and merge pull requests automatically. In the default behavior he presents, it surfaces issues and starts a dialogue instead. Teams enable additional automation as they gain confidence; automatic merging is not the starting assumption.

Sonar Vortex brings guidance and verification into the agent’s inner development loop. It provides constraints before generation and checks while the agent works, so the same agent can find and fix issues before continuing. The SonarQube Remediation Agent starts from a different input: existing issues in the backlog, technical debt, or legacy code. Its purpose is to let repair work proceed while developers focus on new functionality.

Chatterjee presents both capabilities as generally available during the week of the talk. The Remediation Agent’s published launch announcement describes a staged rollout, so that announcement should not be read as establishing one universal availability date for both products. The functional distinction is more durable:

Both apply verification to agent work, but at different points in the codebase’s life.

The cycle operates at two levels: the inner loop where an agent develops a change, and the outer CI/CD loop where that change is reviewed and shipped. Before either begins, the team needs explicit specifications. These include the desired architecture and architectural boundaries, acceptable coding patterns and syntax, allowed and prohibited dependencies, and logging, observability, and tracing practices.

Specifications describe how the software should be built; acceptance criteria determine what may reach production. Security, quality, and maintainability thresholds must be written down and encoded. Sonar supplies defaults, but Chatterjee emphasizes adjusting them to the organization’s requirements.

For example, a repository could make part of its guidance concrete with a small JSON document:

{
  "architecture": {
    "databaseAccess": "repository layer only"
  },
  "dependencies": {
    "allowed": ["existing project dependencies"],
    "newPackages": "require approval"
  },
  "observability": {
    "logs": "structured",
    "requestTracing": "preserve request identifiers"
  },
  "releaseCriteria": {
    "security": "pass configured security gate",
    "quality": "pass configured quality gate",
    "maintainability": "pass configured maintainability gate"
  }
}

These illustrative policy values express the kinds of constraints discussed here; this is not a Sonar configuration schema. Guidance must be supplied to the agent, while release criteria must also be enforced by the verification workflow.

At task initiation, the agent needs the relevant slice of those specifications and the codebase. Sending the entire repository into its context window can lead to unnecessary exploration and token spending. Chatterjee describes Vortex as selecting context for the assigned work so the agent can begin with the constraints that matter to that change.

After generation begins, the agent can call verification and receive an issue list for the code it is writing. It can then repair those issues immediately. This placement matters because an unfixed defect can become an assumption in subsequent development: later agent loops may build additional code around it. Repairing the problem near its introduction prevents that propagation.

The outer loop begins when the work enters formal pull-request review. Gitar supplies LLM-driven review alongside SonarQube’s computational analysis of the code in the PR. Findings cover quality, security, and maintainability; the configured quality gate determines whether the change may advance.

If the PR fails that gate, a Fix Agent can address the findings. In the flow presented, passing the gate permits progression through testing, building, and deployment. The two verification points have complementary scopes:

Inner-loop verification does not replace the outer release gate.

The recorded demonstration puts the inner loop into Cursor. At the start of the assigned task, Cursor calls the Sonar Vortex context tool to obtain information about the code it is about to change. It then writes an initial implementation and calls verification to obtain findings. The integration lets the agent respond to those findings inside the same task rather than handing them off as a separate review chore.

Chatterjee also names Claude Code, Codex, and Antigravity integrations. Their invocation behavior should not be inferred from this Cursor example: the separate Claude Code setup guide requires prior CI analysis and notes that context retrieval may need an explicit request.

Near the end of the demo, Chatterjee points out a flagged issue and describes the next steps: fix it, run analysis again, and do not proceed until verification passes. The presentation moves on before establishing a completed passing result. The demonstrated mechanism is the feedback path—an issue becomes input to the agent’s next repair action, and the repaired code must face another verification pass.

Chatterjee closes by positioning governance and verification as infrastructure for tackling larger problems with coding agents. He refers to customer data showing greater success with AI tools but skips the detailed results. His practical adoption point is that teams may already have access to some of the required tooling.

Sonar reports more than seven million developers using its tools and close to 750 billion lines of code analyzed across its solutions each day. Those are vendor-reported scale figures, not measurements of the effectiveness of this particular workflow. Chatterjee also cites Gartner Magic Quadrant leader status without specifying a category or year.

The operational destination is bounded autonomy: agents have freedom to generate code within centralized constraints, and independent verification determines whether their work is acceptable. Context guides the work, checks expose mistakes, and agents receive the tools and authority to repair those mistakes.

That shifts developer responsibility toward orchestration. Engineers need tools to design the context frameworks and processes in which agents operate. At the organizational level, Chatterjee recommends one independent, multilayer verification platform used consistently across projects, teams, developers, and coding tools. The purpose is to prevent separate tool silos from creating blind spots: teams can vary how they generate code while retaining a shared, enforceable standard for what they ship.