Why AI Coding Agents Start Each Session Like New Hires, and How Sonar Vortex Tries to Fix It

Killian Carlsen-Phelan introduced himself as being from Sonar, which he described as an independent code verification platform. He said the talk would focus on moving verification into the agentic coding loop.

Carlsen-Phelan said that everyone has been using agentic coding tools over the past couple of years and that this has accelerated development. However, each time a new agentic session starts in the IDE, the agent starts from scratch, like a newly hired employee. It does not know the project's existing conventions, coding guidelines or any architecture rules that have been defined in advance.

He said this becomes a problem when the agent is assigned a feature. For example, if asked to build a new API endpoint, the agent must determine how existing endpoints work by searching the code. He described that process as a roll of the dice: the agent may gather the context quickly or may have to search across the whole repository, which takes time and tokens. He called this a fixable problem.

Carlsen-Phelan said that every codebase has issues. He said it is highly likely that agents will replicate those issues and repeat their patterns. He further said that when an agent introduces new issues and they are not caught, maintaining the quality of the code is almost impossible.

Carlsen-Phelan presented Sonar Vortex as Sonar's solution. He described it as a plugin that connects to whatever coding agent is used, so the agent knows the project before it begins coding. He said the agent can also verify itself deterministically to ensure it introduces no new issues into the codebase.

He described a recorded example in which a coding agent wrote a small feature in under two minutes. He had instructed it to build a test suite for itself, but the agent introduced a security issue that Vortex caught, forcing the agent to keep iterating until the issue was fixed. The issue involved unzipping a log file into a temp file, where the permissions set for that temp file were not explicit. He said this type of issue is hard to write tests for and hard to catch, and that a senior reviewer would only catch it if explicitly looking for it, if at all.

Carlsen-Phelan said the frustration in this process is supported by data Sonar has collected. According to the speaker, Sonar surveyed over 1,100 developers and found that 96% do not fully trust AI-generated code. Of those developers, 48% said they fully verified the code before pushing it.

He said he found this troubling, describing it as a situation in which code is sent to production without being verified.

Carlsen-Phelan said agents write code quickly, but rework slows teams down, and catching problems only at the pull request leaves them already behind schedule. He used an animation to illustrate this: the agent, represented as a ball, moves across a grid in which each square is a file, checking new files each time it moves. The bar at the bottom represents the tokens, which are money and time spent on searching.

He said that when the agent gets something wrong, the team finds out at the pull request. The review fails, the work returns to the agent for another round, and the engineer keeps having to respond.

Carlsen-Phelan said that with Vortex, before the agent writes anything, it obtains the coding guidelines for the project and a map of how the code connects. This includes architecture guidelines, the approved libraries for the applications and the coding standards for a given project.

He said the developer sets these conventions and rules, and that with this information the agent goes straight to the relevant files rather than burning excess tokens or context.

Carlsen-Phelan said that as the agent works, SonarQube checks its code. Each edit the agent makes with its own tools triggers a quick check. Before the agent ends its turn, it is told to run a deeper check for security issues and cross-file data flow. When an issue is found, it goes back to the agent, which fixes its code, after which Vortex checks it again.

He said this works with the agents people currently use, naming Claude Code, Codex and Antigravity. For custom agents, open-source agents or less common tools, he said Sonar provides MCP clients that are configurable.

Carlsen-Phelan said the key takeaway is that Vortex can be easily plugged into an agent. He said it is built on the CLI and MCP tools Sonar provides and brings SonarQube into the agent, so the agent knows the project before it writes.

He cited figures from Sonar: Vortex spends 36% fewer tokens on average, with the reduction especially noticeable on tasks such as refactoring existing codebases. Sonar says people who use it have a 44% reduction in production outages. He also said the tool has a very low false positive rate so that it does not clutter coding sessions.

Carlsen-Phelan said the aim is to guide the agent and verify its changes, while bringing SonarQube's existing analysis into the process. He said SonarQube has existed for almost two decades and is traditionally a pipeline step that many teams run to deterministically analyze security, maintainability and data-flow issues, building graphs and analyzing the code in depth.

He said this knowledge is maintained on Sonar's servers and can now be provided to the agent as context from the start. He added that the CI pipeline already runs a SonarQube scan and that Vortex reuses what that scan has learned, so a check on a file also accounts for the rest of the code.

Carlsen-Phelan showed a task he had recorded the previous night. He said that without any action, SonarQube had started in the session, the CLI and hook system were detected, and secret detection was on. He said he would not go into detail on that, but noted that secret leakage is one of the easiest and most costly problems to prevent, and that the plugin prevents secret leaks into GitHub and into agent context memory.

He said he did not paste any Sonar instructions into the prompt; they were loaded automatically. The task was to unzip a log file into a temp file, with the instruction to keep reusing the same file and write a test proving it is reused.

Carlsen-Phelan said that before writing a single line, the agent asks Sonar two questions: where does this class live, and what are the Java coding guidelines for this project. He said the answer comes through Sonar context navigation. The agent receives the parent and child architecture, existing patterns and guidelines around the single GC log file it was asked to work on.

He said Sonar enforces basic guidelines for Java projects by default, and that customer requirements can be injected from the start. He stressed that, apart from model choice, the context and steering agents receive at the start is the single greatest lever for agentic performance, and that more work at the front end means less rework and correction later.

Carlsen-Phelan said that instead of searching through files one by one, as in the animation, the agent simply gets the map. He described this as the guide phase that Vortex performs. The agent can inspect the existing test, see how it operates and move quickly into implementation.

He said the task took only a few seconds, though this varies by feature. He said running the same feature without Vortex takes longer because the agent has to grep around and work out what is going on.

Carlsen-Phelan said the agent ran the implementation and created a temp file within its own test suite. He pointed out the temp file on screen. The agent then checked its own test results and ran the Sonar check on both changed files, displaying messages confirming the test result and running Vortex analysis.

He said Vortex analysis runs every time a file is edited or added, and users do not have to enforce it. He described this as a layer of trust teams need to add to automated workflows to ensure no issues are introduced. He also argued that this is not AI checking AI, which he said is one of the least reliable ways to ensure issues are not introduced. He said agents may think orthogonally about their own creation and review, and that other AI agents are likely to miss and hallucinate when reviewing existing code. A deterministic layer returns the same result each time the analysis runs on the same code, which he said makes guidance reliable, governable and compliant. He added that Sonar also offers an AI review tool, called Guitar, which he did not discuss in the talk.

Carlsen-Phelan said that when the Vortex analysis ran, it caught six findings. The agent said two were on lines it had just written and four were on pre-existing code.

He said Vortex was not engineered to be noisy and not designed to say that a team has found one issue but must fix three more. For new code, it enforces correction. For pre-existing issues, it surfaces them for awareness so that they can be fixed later if the team chooses.

Carlsen-Phelan said one of the findings was the security problem he had mentioned earlier. The agent had put the log in the default temp folder without specifying who can read it, and on many servers that folder is shared. The agent then made a fix.

When Vortex ran again, it determined the issue had not actually been fixed, because the temp file was still in a shared directory. He explained that the first fix relied on a Java default, while on Mac and Linux the default is already owner-only. However, the rule Sonar set requires that permissions be set explicitly. He said Sonar does not compromise on security or quality.

Carlsen-Phelan said that the agent was finally able to implement the fixes, and that Vortex analysis was initiated again each time it ran. He said teams do not want issues to enter their pull request, because the earlier issues are caught, the smaller the surface area of the problems and the less time, money and energy is needed for remediation.

He summarized the terminal session: the agent asked Sonar first, and when Sonar flagged an issue, the agent fixed it and kept remediating its own code. A deep data-flow analysis is performed at the end. He listed the benefits as less back-and-forth review, fixes made in the moment, more secure code, less time and money spent on remediation, and more time freed for developers because they can trust automated agentic workflows. He invited questions at the Sonar booth downstairs.