WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=03l29gJXpCE

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/03l29gJXpCE.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:13.440 --> 00:00:14.410
All right.

s3
00:00:14.410 --> 00:00:16.410
[applause]

s4
00:00:17.600 --> 00:00:18.000
Thank you.

s5
00:00:18.000 --> 00:00:18.720
That's very helpful.

s6
00:00:18.720 --> 00:00:19.800
My name is Anirban Chatterjee.

s7
00:00:19.800 --> 00:00:21.120
I do product marketing at Sonar.

s8
00:00:21.120 --> 00:00:23.720
I'm really excited to be talking to this group today.

s9
00:00:23.720 --> 00:00:26.480
It's actually my first time here at this conference.

s10
00:00:26.480 --> 00:00:37.160
Um and so I've been having a blast uh along with my team here uh meeting a whole bunch of AI engineers as well as leaders and you know, influencers

s11
00:00:37.160 --> 00:00:39.080
and founders.

s12
00:00:39.080 --> 00:00:40.680
Uh there's a lot going on in this space.

s13
00:00:40.680 --> 00:00:46.040
I think this year there's really been a turning point from experimentation to engineering.

s14
00:00:46.040 --> 00:00:57.840
And that makes me that warms my heart very deeply because I started my career many many many many many years ago as a software engineer uh writing code for for servers, if you can believe it.

s15
00:00:57.840 --> 00:01:11.240
Um and I think there's a turning point that's happening right now where we're starting to add the capabilities that we need to add to these systems in order to make them repeatable, make them scalable, make them consistent

s16
00:01:11.240 --> 00:01:21.000
much in the way we were doing with cloud computing not too long ago in order to expand the access that IT technology gave to small businesses and other innovators.

s17
00:01:21.000 --> 00:01:24.240
I think AI is going to do the same thing for software development going forward.

s18
00:01:24.240 --> 00:01:31.600
But in order to do that, in order to get there, we need to start adding safety and trust to these systems so that they can be used more widely

s19
00:01:31.600 --> 00:01:36.880
across a wide variety of use cases so we can build new things and solve bigger problems.

s20
00:01:36.880 --> 00:01:39.360
And how we get there is what we're going to talk about today.

s21
00:01:39.360 --> 00:01:46.320
And uh for those of you who were in uh Tarik's keynote yesterday, uh he presented some of this data and I'm going to talk about it a little bit deeper today.

s22
00:01:46.320 --> 00:01:53.080
So there was a study that Carnegie Mellon did um where they actually looked at projects that were posted on GitHub.

s23
00:01:53.080 --> 00:02:02.960
And they were able to use the metadata to support to sort them into projects where uh there were just traditional tools that were being used and projects where an AI tool was used to write the code.

s24
00:02:02.960 --> 00:02:05.840
In this case, it was Cursor, although it could have been any AI tool.

s25
00:02:05.840 --> 00:02:07.160
And what they found was interesting.

s26
00:02:07.160 --> 00:02:16.280
They found that there was, in fact, a temporary spike in productivity, um but it lasted about 3 months and then it went back down.

s27
00:02:16.280 --> 00:02:22.959
And the reason for that, we think, is because there was also a persistent increase in static analysis warnings and code complexity.

s28
00:02:22.959 --> 00:02:33.959
They're actually using SonarQube uh to actually collect the data on this and they saw that there was a persistent increase in these types of issues that went beyond the 3-month mark and persisted well into the future.

s29
00:02:33.959 --> 00:02:43.720
And so, it's these types of issues that end up actually slowing developers down even more and and making And this is what makes it a challenge to deliver high-quality code

s30
00:02:43.720 --> 00:02:46.080
using AI tools.

s31
00:02:46.080 --> 00:02:51.800
The reason for this is that there's a differing need for quality depending on the criticality of the application, right?

s32
00:02:51.800 --> 00:03:02.840
If you're experimenting, if you're playing around, if you're just one person building things to see what's possible, um if it's an internal non-critical application which has a few users, maybe it's just you, maybe it's a small team,

s33
00:03:02.840 --> 00:03:11.880
maybe it's just a short-lived project that's not going to last very long, the gap between the quality that you're getting from the AI tool and the quality you need from the application is quite small, right?

s34
00:03:11.880 --> 00:03:14.400
And so, you can And you can live with uh that gap.

s35
00:03:14.400 --> 00:03:24.320
But as you move to higher levels of criticality, as you run into situations where you're supporting many, many users, it's a larger code base with many lines of code and many changes happening

s36
00:03:24.320 --> 00:03:27.080
across that code base all the time.

s37
00:03:27.080 --> 00:03:28.680
Uh you have many, many users.

s38
00:03:28.680 --> 00:03:32.920
Some of them could be adversaries that are actively trying to break your software, right?

s39
00:03:32.920 --> 00:03:39.920
And so, in those cases, the quality level you need is quite a bit higher than the quality level you're getting by default from these AI tools.

s40
00:03:39.920 --> 00:03:42.160
And that's where this verification debt comes in.

s41
00:03:42.160 --> 00:03:54.200
That's where you have to bring the humans in, bring your software engineers in to try to close that gap and make sure that the quality level is is up to an acceptable level before you ship that code

s42
00:03:54.200 --> 00:03:55.160
into production.

s43
00:03:55.160 --> 00:03:56.080
So, why is this happening?

s44
00:03:56.080 --> 00:03:57.360
Why is this gap actually occurring?

s45
00:03:57.360 --> 00:03:58.800
We know these models are excellent.

s46
00:03:58.800 --> 00:04:00.240
They're getting better and better all the time.

s47
00:04:00.240 --> 00:04:08.000
I'm really excited to start playing with Fable now that that's out to see what levels of of code we can get out of Fable going forward.

s48
00:04:08.000 --> 00:04:13.800
But, we do know that because of the technology, because of the way that these models are built, they will still make mistakes.

s49
00:04:13.800 --> 00:04:15.400
They will still have quality issues.

s50
00:04:15.400 --> 00:04:17.160
They are still somewhat error-prone.

s51
00:04:17.160 --> 00:04:23.320
And if you let these errors go into production code, you could have a catastrophic effect to your organization.

s52
00:04:23.320 --> 00:04:24.760
They're also missing context, right?

s53
00:04:24.760 --> 00:04:26.280
They only know what you tell it.

s54
00:04:26.280 --> 00:04:29.840
They don't know the broader things that are happening elsewhere in the code base.

s55
00:04:29.840 --> 00:04:31.520
They don't know what's happening with your business.

s56
00:04:31.520 --> 00:04:36.840
They don't know what happened in the meeting you had with somebody else 2 weeks ago that's going to influence the code you're writing today.

s57
00:04:36.840 --> 00:04:40.160
They don't have all of the context that you have as an engineer, right?

s58
00:04:40.160 --> 00:04:42.600
And so, they don't always know your objectives the way you do.

s59
00:04:42.600 --> 00:04:49.040
And that is going to also cause gaps between what you need from the software and the way it's built.

s60
00:04:51.000 --> 00:04:53.400
We also know that models are diverse.

s61
00:04:53.400 --> 00:04:55.840
No two models are the same and they have diverse quality issues.

s62
00:04:55.840 --> 00:04:57.880
And we actually want to explore this.

s63
00:04:57.880 --> 00:05:00.600
And so, we actually have a leaderboard that you can go to on our website right now.

s64
00:05:00.600 --> 00:05:02.520
It's called the LLM leaderboard.

s65
00:05:02.520 --> 00:05:06.440
And what we do is we take all of the major new models that come out and we evaluate them.

s66
00:05:06.440 --> 00:05:13.800
We give them, you know, 4,000 or so coding tasks and we evaluate them using all of the metrics that SonarCube uses to evaluate code, right?

s67
00:05:13.800 --> 00:05:22.560
We look at their correctness, complexity, the way the rate at which they're solving the tasks we assign them, and then our classic things maintainability, reliability, and security.

s68
00:05:22.560 --> 00:05:29.160
And we're able to kind of graph all of these models across these different axes and show you where models perform well and where they have room to improve.

s69
00:05:29.160 --> 00:05:39.240
And what you're looking at on the screen right now is actually Claude Opus 4.6 and Claude Sonnet 4.6. If you're a Claude customer, you might be toggling between these two models to control your token burn rates.

s70
00:05:39.240 --> 00:05:47.880
And you'll see that Claude Sonnet is actually quite good from a correctness standpoint, from from solving tasks, and from a standpoint.

s71
00:05:47.880 --> 00:05:56.640
But if you're requiring higher levels of maintainability or higher levels of security, if you're trying to get a lower complexity out of your code, you might benefit from switching to Opus for tasks like that.

s72
00:05:56.640 --> 00:06:03.040
And so we run these kinds of analyses across a lot of different models, and you're always able to go to our website to get the latest analyses that we run.

s73
00:06:03.040 --> 00:06:07.400
I think we're actually doing the latest Claude and and OpenAI models pretty soon.

s74
00:06:07.400 --> 00:06:09.160
But this kind of data is helpful, right?

s75
00:06:09.160 --> 00:06:12.120
Because it tells you what where models are good and where models are not good.

s76
00:06:12.120 --> 00:06:17.240
It also serves to put some sunlight on the fact that you still need to be vigilant with these models, right?

s77
00:06:17.240 --> 00:06:19.280
None of these models are ever going to be perfect.

s78
00:06:19.280 --> 00:06:27.520
You're always going to have some kind of need for verification in the loop to make sure that the code that you're getting is the code you actually want to ship.

s79
00:06:27.520 --> 00:06:30.320
Now, classically, that verification can be human verification.

s80
00:06:30.320 --> 00:06:31.480
It can be you.

s81
00:06:31.480 --> 00:06:36.080
Your own eyes reading the code, your own intellect reviewing the code to make sure that it's successful.

s82
00:06:36.080 --> 00:06:41.440
But we know, based on experience and now based on research, that human review can also be compromised.

s83
00:06:41.440 --> 00:06:50.440
This is a study that was done earlier this year by Wharton, and they actually gave quite a lot of human participants tasks to complete, and they gave those human participants

s84
00:06:50.440 --> 00:06:53.800
the use of an AI tool to complete those tasks.

s85
00:06:53.800 --> 00:07:01.000
But unbeknownst to those participants, the AI was told to confidently lie to these participants some of the time.

s86
00:07:01.000 --> 00:07:10.720
And what they found in the data is that while participants did follow the AI advice 92.7% of the time when the AI was correct, they unfortunately also listened to the AI

s87
00:07:10.720 --> 00:07:13.760
nearly 80% of the time when the AI was wrong.

s88
00:07:13.760 --> 00:07:17.440
This is almost surely happening in code review as well, right?

s89
00:07:17.440 --> 00:07:26.600
Especially when there's higher amounts of code being written, when there's multiple agents writing code simultaneously, when you now have to bring all those pieces together into a single software application,

s90
00:07:26.600 --> 00:07:27.760
the load is just too great.

s91
00:07:27.760 --> 00:07:29.800
There's there's only so many hours in the day, right?

s92
00:07:29.800 --> 00:07:31.440
And you still have to ship something.

s93
00:07:31.440 --> 00:07:35.760
And so there's a lot of rubber stamping that I'm sure is happening in all of your organizations.

s94
00:07:35.760 --> 00:07:36.560
It's happening everywhere.

s95
00:07:36.560 --> 00:07:41.000
And so we need to backstop that somehow with an automated verification tool.

s96
00:07:41.000 --> 00:07:42.920
What can we do about it, right?

s97
00:07:42.920 --> 00:07:53.200
As Tarek was talking about yesterday, you know, I think all of us sort of when we got involved with software, one of the things that we find most attractive about it is that code

s98
00:07:53.200 --> 00:07:59.760
is is quite, you know, once you write code properly, it's going to run the same way every single time and there's a certain level of comfort in that, right?

s99
00:07:59.760 --> 00:08:06.520
There's a certain level of comfort in knowing that if I write this function the right way, it is going to work this way every single time.

s100
00:08:06.520 --> 00:08:16.120
And there's there's a clarity that comes to that and there's there's a certain confidence you get out of being able to build something that you know is going to work well for every user going forward, but

s101
00:08:16.120 --> 00:08:24.160
we also know that code's written by humans, humans have requirements, and those requirements and externalities have impact in how this code functions.

s102
00:08:24.160 --> 00:08:29.040
And as you add more and more and more code to the application, they can interact in unpredictable ways.

s103
00:08:29.040 --> 00:08:37.680
As you now allow users to use those applications, those users can do all kinds of things you didn't expect, and so software is not provable in the same way that code is provable.

s104
00:08:37.680 --> 00:08:49.360
Software can break in interesting and novel ways, and as you're using AI to write more and more software to solve bigger and bigger problems, um you're going to run into these limitations more and more often.

s105
00:08:49.360 --> 00:08:55.680
And so having automatic verification as part of this process is an important part of the solution.

s106
00:08:55.680 --> 00:09:04.000
It's going to help you control some of the risks that you're introducing by maybe releasing some of the control you have over the code that's actually being written.

s107
00:09:04.000 --> 00:09:16.080
And so we believe that verification is going to be a key enabler and a and a key unblocker for all of the amazing things that we're going to be able to achieve with with the AI-driven software development going forward.

s108
00:09:16.080 --> 00:09:18.680
And so when we say verification, what do we mean, right?

s109
00:09:18.680 --> 00:09:23.880
We think there's two core elements to successful automated verification when it comes to AI coding.

s110
00:09:23.880 --> 00:09:26.280
One is that needs to be zero trust.

s111
00:09:26.280 --> 00:09:27.560
What do we mean by that?

s112
00:09:27.560 --> 00:09:31.520
Zero trust in this context basically means that the code could really have come from anywhere.

s113
00:09:31.520 --> 00:09:35.920
It could still be written by a human, it could be written by an AI as I just showed you a few slides ago.

s114
00:09:35.920 --> 00:09:44.680
Different AIs will write code in different ways, and you're not going to want to be able You're not going to want to use that same AI to to validate the code because

s115
00:09:44.680 --> 00:09:50.600
you're going to want a diversity of of tools being used to make sure that you're catching all the different issues that can happen.

s116
00:09:50.600 --> 00:10:00.480
And so, no matter where the code is coming from, you want to have a a similar comprehensive regime to verify that code that works the same no matter how that code was written, right?

s117
00:10:00.480 --> 00:10:04.000
Use a different methodology to review the code that was used to write the code.

s118
00:10:04.000 --> 00:10:13.880
Uh it's completely auditable, completely explainable, so you can prove that verification was run the same way every single time, and it's algorithmic and repeatable and consistent no matter how you run it.

s119
00:10:13.880 --> 00:10:15.360
It also needs to be multi-layered.

s120
00:10:15.360 --> 00:10:23.480
You need to have multiple ways uh a multiple techniques being used, multiple approaches being used to review the code that is being generated, right?

s121
00:10:23.480 --> 00:10:29.520
Um because you're never going to be able to find every single problem that can occur in software by just using one or two methods.

s122
00:10:29.520 --> 00:10:37.480
You need to use computational review, you also need to use LLM driven review, and everything else in between, right?

s123
00:10:38.200 --> 00:10:46.200
You heard a little bit about agentic I'm I'm really I've been hearing a lot about agentic loops this week, uh and Tarik uh talked yesterday about our framework for agentic loops.

s124
00:10:46.200 --> 00:10:49.920
We call it ACDC, or agentic agent-centric development cycle.

s125
00:10:49.920 --> 00:10:53.880
And there's three phases in in the ACDC that we that we like to talk about.

s126
00:10:53.880 --> 00:11:03.880
The the easiest one By easiest, I mean the the fastest one to implement now, the one that many of you are probably already on a path to implementing, is the verification step, which is front which is top center, right?

s127
00:11:03.880 --> 00:11:11.680
This is the most important piece that allows you to to write code in these agentic loops in a way that is going to be easily shippable.

s128
00:11:11.680 --> 00:11:22.120
Uh it needs to be multi-layered, it needs to be reasoning based, and it needs to cut across quality issues, security issues, and compliance issues to make sure that you're shipping quality that you can stand behind, right?

s129
00:11:22.120 --> 00:11:25.480
Um before the verification step, there's a guidance step.

s130
00:11:25.480 --> 00:11:34.720
And what guide allows you to do is provide guardrails and context and constraints to make sure that the agent has everything it needs up front to write better code

s131
00:11:34.720 --> 00:11:36.360
uh uh uh the first time, right?

s132
00:11:36.360 --> 00:11:39.960
And then finally, after verification, you need to solve the issues that come up, right?

s133
00:11:39.960 --> 00:11:41.080
And that's where the solve state come.

s134
00:11:41.080 --> 00:11:44.120
That's where you can remediate any issues that are found in the code.

s135
00:11:44.120 --> 00:11:53.640
You Hopefully, you're allowing the agent to have the agency to do so itself by providing access to the tools it needs to to find the issues and fix them itself and then just repeat the loop.

s136
00:11:53.640 --> 00:12:01.600
And so these these agentic loops with verification at the core is how you can get to shipping quality software using AI agents.

s137
00:12:01.960 --> 00:12:05.360
And there are prior there's different reasons why you would want to do this.

s138
00:12:05.360 --> 00:12:14.720
And when we talk to customers, and we've talked to a lot of customers about this, uh the driving functions that are forcing them to adopt verification across all of their AI coding

s139
00:12:14.720 --> 00:12:17.360
processes are are very similar, right?

s140
00:12:17.360 --> 00:12:19.840
They want to make sure that AI code is verified consistently.

s141
00:12:19.840 --> 00:12:24.320
They don't want to have different methods of verification applying to different projects or different teams.

s142
00:12:24.320 --> 00:12:28.800
They want to have a standard rulebook that applies everywhere, no matter what tool is being used.

s143
00:12:28.800 --> 00:12:32.320
They all also want to make sure they're using their AI tools effectively, right?

s144
00:12:32.320 --> 00:12:42.040
Some of that a big part of this is token efficiency or just efficiency in general, but also just making sure that the tools are being used for the things they're being designed to do in ways that we know they're good at doing, right?

s145
00:12:42.040 --> 00:12:48.240
So we talk a lot about token efficiency, and we talk a lot about making sure that the right models are used for the right projects, and so on.

s146
00:12:48.240 --> 00:12:54.680
Finally, third, catching issues from a security standpoint as early as possible in development cycle.

s147
00:12:54.680 --> 00:13:06.720
Shifting left on security issues has been very important for a number of years now, and now that AI is writing more and more code, catching security issues up front is extremely critical, especially now that we're in a world where CVEs

s148
00:13:06.720 --> 00:13:12.600
are announced and then immediately exploited uh by bad actors almost often the same day.

s149
00:13:12.600 --> 00:13:17.240
And so you need to make sure that your code is as hardened as possible from those types of issues creeping into production.

s150
00:13:17.240 --> 00:13:19.160
And finally, maintaining compliance.

s151
00:13:19.160 --> 00:13:26.320
Many of you, I'm sure, work in a regulated industry, uh and for those types of situations where you need to be able to prove that verification is run constantly

s152
00:13:26.320 --> 00:13:28.440
and consistently across the board.

s153
00:13:28.440 --> 00:13:32.800
Maintaining an audit trail that allows you to prove that is extremely important.

s154
00:13:32.800 --> 00:13:35.680
We have a number of solutions that that help with that.

s155
00:13:35.680 --> 00:13:37.320
SonarQube has been around for quite a while.

s156
00:13:37.320 --> 00:13:40.080
There are probably quite a few of you that are already SonarQube users.

s157
00:13:40.080 --> 00:13:46.880
It is a zero trust multi-layered verification platform that works across syntax issues, data flow issues, architectural issues, control flow issues.

s158
00:13:46.880 --> 00:13:50.280
And it works across basically any language you would be using.

s159
00:13:50.280 --> 00:14:00.760
We have a lot of deep hooks that I'm going to take you through in a moment that allow agents to have first party access to the SonarQube verification so they can more effectively write high quality code.

s160
00:14:00.760 --> 00:14:06.960
And we also just recently, and by recently I mean just a few weeks ago, acquired a company called Gitarr, based right here in San Mateo.

s161
00:14:06.960 --> 00:14:09.120
And they do AI code review.

s162
00:14:09.120 --> 00:14:20.040
And more than that, they actually build a full they build and automate the full CI workflow so that you can not only find issues using an using our LM

s163
00:14:20.040 --> 00:14:26.040
approach, but you can also automatically block if those issues cause a quality issue that you would want to push forward.

s164
00:14:26.040 --> 00:14:31.000
It can write fixes and it can approve those fixes and merge those PRs completely automatically if you wanted to.

s165
00:14:31.000 --> 00:14:32.360
Now, we'd want to earn that trust.

s166
00:14:32.360 --> 00:14:35.320
It doesn't happen that way by default usually.

s167
00:14:35.320 --> 00:14:40.920
By default they'll just find the issues and show them to you and enter a dialogue with you so you can have those issues fixed.

s168
00:14:40.920 --> 00:14:50.360
But as you use it more and more and gain confidence, you can turn on more and more features and completely automate the PR review workflow if you like using Gitarr.

s169
00:14:50.680 --> 00:15:00.080
So, the other big news from earlier this week, and Tarik alluded to this during his talk yesterday, is that we also announced a new agentic loop capability with a product called Sonar Vortex.

s170
00:15:00.080 --> 00:15:15.160
And Sonar Vortex, I'm going to I'm going to show another flowchart that shows what it does, but basically it is providing your agents with tools in the inner loop, in the agentic loop, to not only get constraints and guardrails up front to write better code, but also run verification

s171
00:15:15.160 --> 00:15:19.720
as it's writing code in real time so it can find and fix the issues that are being created.

s172
00:15:19.720 --> 00:15:21.760
And then we also released the remediation agent.

s173
00:15:21.760 --> 00:15:30.760
And the remediation agent allows you to tackle backlog issues and and take down your tech debt at a scale that you might not have the bandwidth to do now with human developers, right?

s174
00:15:30.760 --> 00:15:39.760
You can basically take your your tech debt or your older issues, your legacy code, point them at remediation agent, and it can then improve your code base almost in the background

s175
00:15:39.760 --> 00:15:44.800
while you focus on the on the innovation work at the front end that you're working on now.

s176
00:15:44.840 --> 00:15:46.760
And those are both GA as of this week.

s177
00:15:46.760 --> 00:15:56.320
Now, there was a very detailed chart that was shown during the keynote yesterday that I'm going to kind of break down for you and really explain what the different pieces of this chart mean.

s178
00:15:56.320 --> 00:16:06.800
This is kind of how we see the ACDC applying not only to the inner agentic loops, but also the outer CICD loops that we're all working in to develop code.

s179
00:16:06.800 --> 00:16:17.080
Before you start either of those loops though, it is really important to have a sense of the specifications of what you actually are going to want to accomplish with the software that's being written.

s180
00:16:17.080 --> 00:16:19.640
This is This is your architectural constraints.

s181
00:16:19.640 --> 00:16:22.520
This is the way your desired architecture for the software.

s182
00:16:22.520 --> 00:16:25.480
This is your coding standards and your coding patterns that are acceptable.

s183
00:16:25.480 --> 00:16:29.000
These are the list of dependencies that you are and are not allowed to use.

s184
00:16:29.000 --> 00:16:33.680
These are your coding standards and and syntax standards that you obey in your organization.

s185
00:16:33.680 --> 00:16:38.000
This could be your your logging practices or your observability and tracing practices.

s186
00:16:38.000 --> 00:16:44.680
All of that goes into your specs and then you also need to define what your quality criteria are, right?

s187
00:16:44.680 --> 00:16:55.240
And we have quality criteria that we ship with that you can use by default or you can adjust them as it makes sense for your organization, but this is like what are the levels of security, of quality, of maintainability that you're willing to accept

s188
00:16:55.240 --> 00:16:57.120
in your code that you're pushing into production.

s189
00:16:57.120 --> 00:16:59.080
You need to basically write that down and encode it.

s190
00:16:59.080 --> 00:17:02.960
And now you're ready to start using LLM coding agents to write code.

s191
00:17:02.960 --> 00:17:14.280
And whenever you're initiating a coding task with an with an with an agent, one of the first things that we can help is providing context and constraints so that the agent starts

s192
00:17:14.280 --> 00:17:19.560
from the ground floor with an understanding of the code base and the guardrails that is relevant to it in that moment.

s193
00:17:19.560 --> 00:17:24.360
You have to manage the context window of the agent you can't just throw your entire code base at the agent up front.

s194
00:17:24.360 --> 00:17:28.640
It's going to spend a lot of time thrashing and exploring and burning tokens while it's doing it.

s195
00:17:28.640 --> 00:17:37.800
We are able to efficiently provide just the context that it needs based on the work that it's being given so that it can get to work writing productive code very quickly.

s196
00:17:37.800 --> 00:17:44.360
It then generates the source code as you can see and we also provide in loop verification to the agent as it's writing.

s197
00:17:44.360 --> 00:17:54.960
It can call in to us and provide and get a list of issues that we are finding in real time in the code that's being written and the great thing about that is those issues can then be fixed immediately by the agent so they don't propagate

s198
00:17:54.960 --> 00:17:59.920
into future agentic loops that are going to run in order to fully build out the software project that you're doing.

s199
00:17:59.920 --> 00:18:03.760
This is being enabled by Sonar Vortex as of this week.

s200
00:18:03.760 --> 00:18:13.680
Once all of the inner loops have run you get you reach a point later on when you have to start entering the formal review and shipping process for the code and this is the CICD process, right?

s201
00:18:13.680 --> 00:18:17.760
And so there's a PR flow that gets initiated that I'm sure we're all familiar with.

s202
00:18:17.760 --> 00:18:25.640
Guitar can live in that flow, SonarQube also lives in that flow in order to run a broad automated review of all of the code that is in the PR

s203
00:18:25.640 --> 00:18:31.240
and an automated verification that actually returns issues across quality, security and maintainability.

s204
00:18:31.240 --> 00:18:45.040
There's a superhuman review that is LLM driven by Guitar and there's a computational review that is run by SonarQube that actually assigns grades for all three of those things and won't allow the PR to go past into production unless it gets a passing grade across that criteria.

s205
00:18:45.040 --> 00:18:55.600
So if there are issues that come up, you can actually use a fix agent to fix all the issues that are discovered there and then once you're actually able to pass that quality gate, that is when you're able to proceed in the test

s206
00:18:55.600 --> 00:18:58.240
and build and deploy in the application.

s207
00:18:58.240 --> 00:19:05.440
The verification needs to run in both the inner agentic loop and also in the outer loop for CICD.

s208
00:19:05.440 --> 00:19:08.440
I'm running low on time so I'm going to hope this video completes.

s209
00:19:08.440 --> 00:19:11.200
This is basically a video demo of the inner loop, the agentic loop.

s210
00:19:11.200 --> 00:19:13.680
It's a it's a demo of Sonar Vortex, basically.

s211
00:19:13.680 --> 00:19:20.080
And what you've just seen happen is we've given it a task and in starting that task, this is this is actually Cursor that's running right now.

s212
00:19:20.080 --> 00:19:29.440
Cursor called into our Sonar Vortex context tool to get some context up front to to get give it an understanding of the code that's working and so it knows

s213
00:19:29.440 --> 00:19:31.160
how to um how to write the code.

s214
00:19:31.160 --> 00:19:40.200
It is now writing the code and once it's completed uh the initial write, it's going to call into our verification process to get a list of issues that it finds.

s215
00:19:40.200 --> 00:19:46.800
And then if it and if issues get provided, it will actually fix those issues immediately in the inner loop.

s216
00:19:46.800 --> 00:19:50.680
This is all happening automatically through an integration that we have directly with Cursor.

s217
00:19:50.680 --> 00:19:59.360
We have similar integrations with uh with Claude Code, with Codex, with Any Gravity, with basically any major AI coding tool that you would have.

s218
00:19:59.360 --> 00:20:00.480
And you can sort of get the gist.

s219
00:20:00.480 --> 00:20:01.960
It It flagged an issue.

s220
00:20:01.960 --> 00:20:02.440
It's got a plan.

s221
00:20:02.440 --> 00:20:11.680
It's going to fix it immediately and it's going to run uh the analysis again and then it will not proceed until it actually is able to get a passing grade from us on the verification pass.

s222
00:20:11.680 --> 00:20:15.080
I'm going to move past this cuz I'm out of time now.

s223
00:20:16.800 --> 00:20:27.880
So, uh if you take one thing away from this presentation, it's that, you know, we believe very strongly, we're very convicted about this, that a governance and verification regime is a engine is extremely critical

s224
00:20:27.880 --> 00:20:35.560
to unlock the next level of success that we need to be able to get from AI coding tools so we can solve bigger and bigger problems.

s225
00:20:35.560 --> 00:20:42.600
And we know, based on our data, uh that Sonar customers and Sonar users are able to get higher levels of success from AI coding tools.

s226
00:20:42.600 --> 00:20:49.920
I can I'm not going to go through all of these now cuz I'm out of time, but you can stop by the our big red booth downstairs and we'll be happy to talk to you about any of these.

s227
00:20:49.920 --> 00:20:55.600
Um but, you know, the good news is I think many of you probably have access to this stuff already.

s228
00:20:55.600 --> 00:20:58.840
Uh Sonar Cube is one of the most widely adopted verification tools in existence today.

s229
00:20:58.840 --> 00:21:06.520
We have over 7 million developers around the world using us and we analyze close to 750 billion lines of code across our solutions every single day.

s230
00:21:06.520 --> 00:21:12.520
And if there are a few of you in the room who care about Gartner at all, it's nice to know that we're a Gartner market uh magic quadrant leader as well.

s231
00:21:12.520 --> 00:21:15.840
So, uh final slide, key takeaways, right?

s232
00:21:15.840 --> 00:21:17.320
What are the things that we want to walk away from this?

s233
00:21:17.320 --> 00:21:22.040
First, you know, establish some bounded autonomy guidelines for your AI agents.

s234
00:21:22.040 --> 00:21:28.840
Give them the freedom to generate code, but also make sure that you're enforcing a centralized scheme of verification and constraints.

s235
00:21:28.840 --> 00:21:30.160
Implement the ACDC, right?

s236
00:21:30.160 --> 00:21:31.800
Give them context.

s237
00:21:31.800 --> 00:21:36.880
Verify that they're doing the right work with independent metrics, and then use agents to solve their own mistakes.

s238
00:21:36.880 --> 00:21:38.200
Empower them to do that.

s239
00:21:38.200 --> 00:21:48.320
Make sure your developers are equipped with the orchestration tools that they need in order to design the context frameworks and the processes that are going to enable them to be successful and use AI most effectively.

s240
00:21:48.320 --> 00:22:04.800
And finally, standardize on a single independent multi-layered verification platform that is used consistently across all projects, across all teams, across all developers, and all AI coding tools so that you can eliminate any blind spots that might be created by using silos of tools across the organization.

s241
00:22:04.800 --> 00:22:06.120
Um that's all for me.

s242
00:22:06.120 --> 00:22:09.040
Uh you can learn more by Oh, it's off the screen now.

s243
00:22:09.040 --> 00:22:12.440
But uh you can come down to our big red booth downstairs, and we'd be happy to talk to you.

s244
00:22:12.440 --> 00:22:14.800
Thank you very much.

s245
00:22:28.660 --> 00:22:30.660
[music]