Your AI Agent Starts Every Session Like a New Hire - Killian Carlsen-Phelan, Sonar
Killian Carlsen-Phelan of Sonar introduces Sonar Vortex, a plugin that gives coding agents a map of a codebase and its guidelines before they write, then deterministically verifies every edit. In a live demo, it catches a temp-file permissions bug that the agent's own tests missed and rejects the agent's first fix.
Coding agents start every session cold. A new agentic session in an IDE behaves like a newly hired engineer: it knows nothing about the project’s conventions, coding guidelines, or architecture rules, so it has to rediscover them by searching the repository for every feature. That search is a gamble. Sometimes the agent gathers context quickly, and sometimes it wanders across dozens of files. Either way it costs time and tokens. The bigger problem is that every codebase already has issues, and agents tend to replicate existing patterns, including the bad ones, while adding new problems of their own. Without a check inside the loop, keeping code quality up becomes nearly impossible.
Moving verification into the agent loop
Sonar Vortex is a plugin that connects to whichever coding agent a team uses. Before the agent writes anything, it receives the project’s coding guidelines, architecture rules, approved libraries, and a map of how the code connects. As it edits, Vortex verifies each change deterministically. Before the agent ends its turn, a deeper analysis checks for cross-file data flow issues. Findings go back to the agent, which fixes its own code and gets checked again.
The approach builds on SonarQube’s existing analysis. Teams that already run a SonarQube scan in CI have that knowledge stored on Sonar’s servers, and Vortex reuses it. A quick check on a changed file therefore still reflects the rest of the codebase. Sonar says the plugin works with agents such as Claude Code, Codex, and Antigravity, and offers configurable MCP clients for custom or open-source agents.
The speaker’s central point is that the context an agent receives before it writes code is the largest lever for agent performance after model choice. The more that is handled up front, the less rework, steering, and correction is needed later.
The bug a test wouldn’t catch
The demo task was a small feature: unzip a GC log file into a temp file, reuse that same file, and write a test proving the reuse. The agent wrote its own tests, and they passed. But it created the temp file without setting permissions explicitly. A flaw like this is hard to test for and easy for a human reviewer to miss unless they are specifically looking for it. When it is found late, it triggers another round of rework, re-review, and re-analysis, which burns time, money, and patience.
In the demo, secrets detection and the hook system were active from the start, with no Sonar instructions pasted into the prompt. Before writing a line of code, the agent asked Sonar where the class lived and what the Java guidelines were. It received parent and child architecture, existing patterns, and the project’s rules.
Vortex flagged the log being written to the default temp folder, which on many servers is shared, without any restriction on who can read it. The agent’s first fix relied on Java’s default permissions, which on macOS and Linux are already owner-only. But the team’s standard requires permissions to be set explicitly. Vortex re-ran and reported that the finding persisted. Only the explicit fix cleared it.
Deterministic checks, not AI reviewing AI
A key argument is that asking another AI to check an AI’s code is one of the least reliable ways to prevent issues. Agents reviewing their own work, or other agents reviewing existing code, tend to miss problems and hallucinate. A deterministic layer returns the same result every time it analyzes the same code, which makes verification reliable, governable, and predictable. The speaker supports AI review tools and notes that Sonar has one of its own. He frames Vortex as a deterministic layer stacked on top of AI coding and sandwiched between it and any AI review.
In the demo, Vortex returned six findings. Two were on lines the agent had just written, and four were in pre-existing code. Vortex is not designed to be noisy. It enforces correction on new code and surfaces pre-existing issues for awareness, so they can be addressed later if the team chooses.
Results and what teams gain
Sonar reports that agents using Vortex spend 36% fewer tokens on average, with especially large savings on refactoring existing codebases. Users see a 44% reduction in production outages. The false-positive rate is kept low so that sessions are not cluttered.
The broader context is a survey of more than 1,100 developers. 96% said they do not fully trust AI-generated code, yet only 48% of those said they fully verify it before pushing. The speaker finds that gap alarming, because it means unverified code is reaching production.
The practical benefits are fewer back-and-forth reviews, problems fixed in the moment instead of at the pull request, more secure code, lower remediation costs, and developer time freed up because teams can trust automated agentic workflows. Verification runs automatically whenever a file is edited or added, so it does not depend on developers remembering to run it.