Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar

Ask a fresh coding agent to add an API endpoint and its first job is to find out how this project builds endpoints. Killian Carlsen-Phelan of Sonar compares it to a new hire. The team already knows its architecture and coding conventions. The agent has to piece them together from the files it opens. It may find a good example immediately, spend tokens searching the repository, or find a pattern the team would rather it stopped copying.

Sonar Vortex is a plugin that gives the agent project context up front and checks the code it writes. Consider a feature that took the agent under two minutes to write. It unzipped a log into a temporary file and added a test for reusing that file. The implementation left the file's read permissions implicit. A test can establish that a second request reuses the same file while saying nothing about who else can read the log.

A senior reviewer might spot that detail. By then, even a successful catch costs another edit, push, analysis run and review. Sonar surveyed over 1,100 developers. Carlsen-Phelan put two figures side by side: 96% expressed less than full trust in AI-generated code, yet only 48% reported fully verifying it before pushing. Moving the check into the coding session gives the agent a chance to repair the file while it is still working on the feature.

Where do the tokens go before the first edit? In Carlsen-Phelan's animation, a ball moves across a grid. Each square is a file, each move is another inspection, and a bar tracks the tokens spent looking around. The agent can pay for all that exploration and still discover at pull-request review that it followed the wrong example.

Vortex supplies two things the agent would otherwise have to infer. A map of how the code connects points it toward relevant files. Team-defined guidelines tell it which architectural rules, approved libraries and coding standards apply once it gets there. The distinction matters when an existing file uses a pattern the team no longer wants in new code.

Once the agent starts writing, each edit made with its usual tools triggers a quick SonarQube check. Findings go back to the agent, and an edit to fix one triggers another check. Before the turn ends, the agent is instructed to run a deeper analysis that can follow data across files. Vortex builds on Sonar's CLI and MCP tools. The integrations described include Claude Code, Codex and Antigravity, with configurable MCP clients for custom agents.

Sonar reports 36% fewer tokens spent on average, highlighting refactoring work on existing codebases, and 44% fewer production outages among users. It also describes false positives as infrequent. The comparison baselines and measurement methods are unspecified, so the figures give little basis for predicting the savings on a particular team's workload.

How can a quick check on one file use knowledge of the rest of the project? SonarQube already builds graphs of the code during continuous integration (CI), where it analyzes security, maintainability and data flow. Sonar retains that project context on its servers. Vortex reuses what the CI scan learned, so a fresh agent session can start with relationships the pipeline has already worked out.

The recorded terminal session starts with the Sonar CLI and edit hooks detected. Secrets detection is also on, intended to keep credentials out of GitHub and the agent's stored context. The developer can keep the prompt about the feature itself: unzip the log into a temporary file, keep reusing that same file, and write a test that proves reuse. The plugin loads its own instructions.

What does Claude need to know before it edits SingleGCLogFile? Its first two lookups serve different purposes.

• Class navigation. The agent asks where SingleGCLogFile lives. Sonar returns its parent and child relationships and nearby implementation patterns, giving the agent a place to start reading.
• Java guidelines. The agent requests the coding guidelines for Java. The project can supply custom team requirements alongside the basic Java guidance, so those requirements reach the agent before it chooses an implementation.

With the class located, Claude inspects the existing test to see how the project exercises this code. That part of the session takes a few seconds. The map narrows the search while leaving the agent to read the code that matters for the change.

Claude adds the temporary-file creation code and its tests, then checks the test result. Vortex analyzes both files the agent changed. Adding or editing a file triggers analysis automatically, so running the reuse test and enforcing the project's rules are separate operations. The developer didn't have to anticipate a permissions mistake in the prompt to get it checked.

Claude owns the edit. SonarQube decides whether the edit satisfies the rule. Deterministic has a specific meaning here: run the same analysis on the same code and the finding is repeatable. A model reviewing its own work, or a second model reviewing it, can overlook a problem or invent one. An AI reviewer such as Sonar's Gitar can still review the change later.

The scan returns six findings. Claude identifies two on lines it just wrote and four on preexisting code. Vortex requires correction of the two new findings. The other four remain visible for later work. That policy keeps a small feature from turning into an obligation to clean up every issue in a file the agent touches.

One of the new findings points to the decompressed log. Claude created it in the default temporary directory, a location often shared on servers, without specifying who could read the file. The directory and the file matter in different ways. Other users may share the directory. Whether they can read this particular log depends on the file's permissions.

Why does the finding survive Claude's first fix? The revised code still creates the file in a shared directory and relies on a Java default. On macOS and Linux, Carlsen-Phelan explains, that default already gives only the owner access in this case. But the configured rule requires the code to set the permissions explicitly. Even observing owner-only access on a test machine would leave that requirement unresolved.

The repeated finding sends Claude back to the file to make the permissions explicit. That edit triggers analysis again. At handoff, the workflow calls for the deeper cross-file data-flow check. The practical gain in this session is that the first attempted fix could fail and get another edit before anyone had to open a pull request, ask a senior reviewer to check the permissions, and send the work back.