Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
TLDR
The main flaw with AI coding agents is that they produce code that is syntactically correct but violates business logic or access control rules. Sonar's Hunter Agent addresses this by using playbooks to understand the intended rules and then hunting for violations, proving each issue before surfacing it. This is a useful development for teams using AI coding agents, as it fills a gap that traditional code review tools miss.
Key points
AI coding agents often produce code that is syntactically correct but violates business rules or access control.
Sonar's Hunter Agent uses playbooks to enforce business rules.
Hunter Agent proves each issue before surfacing it to the user.
Hunter Agent is generally available for SonarCube Cloud enterprise plan.
Techniques
- playbook-driven code review
- automated business rule validation
- issue verification before reporting
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
I've spent a lot of time this year helping companies roll out AI coding agents. And when the results aren't the best, at least at first, it's really not the model's fault. It's that everything
that they use to check the output is made to check for code that is wrong. Code that is syntactically broken or unsafe. The kind of thing you can pattern match against, like SQL
injection, cross-sight scripting, path traversal, and these issues and vulnerabilities are important, but they're not the only risk. Most of what goes wrong with agent written code isn't
strictly bad code. Exactly like the examples that I have on screen right here. It's code that runs as the agent intended, but it's just not what we or the business needed. Usually, what the
agent gets wrong is access control, business logic, the rules that the product runs on. Now, the thing is a business rule doesn't really have a shape. Unfortunately, nothing in the
syntax can really tell you whether code that violates a rule looks any different from code that doesn't. for things like, for example, access control with specific functionality. The only way to
tell is knowing what the business rule was supposed to be in the first place. Okay, cool. I understand that this is a problem, but now what in the world is the solution? Well, Sonar has built a
new agent called Hunter Agent. You're looking at the UI for it right here. And for this class of problem, it works out everything for you. And what I love about Hunter Agent is they don't just
have their agent rumage around your repo trying to find these different problems or perform more of a traditional code review. They have a process for this. They run playbooks. It figures out what
your app is supposed to enforce. Then it hunts for any instances where it doesn't. And then it proves each one before it ever surfaces anything to you. And if you run it on the same code
twice, you're going to get the same answer twice. The kind of reliability that we don't usually have with apps built on top of LLMs. broken access control, business logic, authentication,
and sessions. It all shows up as regular issues in Sonar Cube cloud, so there's nothing new to learn. And this is generally available now for the cloud enterprise plan. I have loved working
with the Sonar team this year and even helping other companies incorporate all their products in the Sonar Cube cloud. So, thanks to them for working with me on this.