Killian Carlsen-Phelan on Guiding and Verifying Coding Agents

I’m Killian from Sonar, an independent code verification platform. I want to move verification into the agentic coding loop, where a new session often starts without knowing the project’s conventions, coding guidelines or architectural rules.

When you ask an agent to add an API endpoint, it must first discover how existing endpoints work. It may find that context quickly, or search widely across the repository, consuming time and tokens. Existing code problems can also become patterns the agent repeats.

If newly introduced issues go unnoticed, maintaining code quality becomes difficult. Our proposed solution is Sonar Vortex, a plugin intended to give a coding agent project context before it writes and deterministic checks as it works.

In a recorded example, an agent implemented a feature and wrote tests in under two minutes, but introduced a security issue involving a temporary file. Vortex flagged the issue and required further iterations. The missing detail was an explicit permission setting, which a test or reviewer might not catch.

Sonar surveyed more than 1,100 developers. I cite its findings that 96% did not fully trust AI-generated code and 48% fully verified it before pushing. These are survey results I’m presenting, not a measure of every team’s practices.

My animation shows an agent moving through a grid of files while a token counter rises. If a problem appears only at pull-request review, work returns to the agent and reviewers must repeat their checks. The goal is to shorten that loop.

Before the agent writes, Vortex supplies a map of code relationships and the project’s own standards, such as architecture guidelines and approved libraries. Those requirements can be set for the project rather than rediscovered during every task.

As the agent edits files, SonarQube runs a quick check. Before the turn ends, the agent is instructed to run a deeper analysis, including cross-file data flow. When a finding comes back, the agent can revise the code and run the check again.

I describe support for commonly used coding agents and configurable MCP clients for other or custom agents. The intended workflow is to bring SonarQube’s existing knowledge into the coding session, rather than wait for a later pipeline step.

I report that Vortex uses 36% fewer tokens on average, particularly in tasks such as refactoring, and that users experience 44% fewer production outages. These figures are Sonar’s claims from the talk; the presentation does not explain the study design.

SonarQube traditionally analyzes a pipeline for security, maintainability and data-flow issues. Vortex reuses knowledge from an existing CI scan so a file-level check can be interpreted alongside information about the rest of the project.

In the recorded task, the session detects the Sonar CLI and hook system, with secrets detection enabled. I say the plugin is intended to prevent secrets from leaking into GitHub and agent context, without requiring me to paste instructions into the prompt.

The requested feature unzips a log into a temporary file, reuses that file and adds a test proving reuse. Before coding, the agent asks Sonar where the relevant class lives and what Java guidelines apply.

The returned context includes parent and child architecture, existing patterns and language-specific rules. Teams can also add their own requirements. In my view, the context and steering given at the start are a major influence on agent performance.

The agent inspects the existing tests and proceeds to implementation. In the demonstration I compare that guided phase with a run that would otherwise search the repository to discover the same information.

The agent creates the temporary file and adds tests, then confirms the test result and runs Vortex analysis on the changed files. I say the analysis is automatically triggered when a file is added or edited.

I distinguish deterministic code analysis from asking an AI model to review its own output. By deterministic I mean that running the same analysis on the same code returns the same result. I present it as a layer that can complement a separate AI review.

The analysis returns six findings: the agent identifies two on newly written lines and four in existing code. I explain that Vortex enforces correction for issues in new code while surfacing pre-existing findings for awareness.

One new finding concerns the log file in a default temporary directory that may be shared on a server. The agent attempts a fix, but the next analysis says the issue persists: the rule requires permissions to be set explicitly.

The first fix relied on Java defaults, which are owner-only on Mac and Linux in the example. Sonar’s rule applies a stricter requirement for an explicit setting. The agent makes another change and the analysis runs again.

My point is to find problems during the coding session, when the scope of a change is still small, instead of waiting for another review cycle. After the agent’s iterations, a deeper data-flow analysis is performed before it hands the work back.

I close with the intended benefits: less review back-and-forth, earlier remediation and more time for developers. The demonstration illustrates the workflow; the reliability and savings figures I discussed are the company’s reported claims.