WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=8vDzncmzxyg NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/8vDzncmzxyg.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:12.560 --> 00:00:14.800 I am Killian from Sonar. s3 00:00:14.800 --> 00:00:19.640 And if you're unfamiliar with Sonar, we are an independent code verification platform. s4 00:00:19.640 --> 00:00:25.680 Um and what I'm going to be talking about today is how to move verification into the agentic coding loop. s5 00:00:25.680 --> 00:00:31.240 Um I mean as we know everybody has been doing this the past couple years. s6 00:00:31.240 --> 00:00:39.320 It's accelerated the pace and every time you start a new agentic session in your IDE, it is like starting from scratch. s7 00:00:39.320 --> 00:00:42.800 It is like a new hired employee into your project. s8 00:00:42.800 --> 00:00:45.800 It does not know your existing project conventions. s9 00:00:45.800 --> 00:00:48.320 It does not know uh your coding guidelines. s10 00:00:48.320 --> 00:00:52.840 It does not know any architecture rules that you have predefined for it. s11 00:00:52.840 --> 00:00:55.000 And that can be a problem. s12 00:00:55.000 --> 00:01:02.760 Because what it has to do then is when it's assigned a feature, it has to go look around for context, right? s13 00:01:02.760 --> 00:01:05.519 If you say, "Hey, build out a new API endpoint." s14 00:01:05.519 --> 00:01:11.360 It has to go and determine how existing API endpoints work in your code. s15 00:01:11.360 --> 00:01:16.440 And that process can, you know, it's it's a bit of a roll of the dice. s16 00:01:16.440 --> 00:01:23.120 Um it can acquire that context quickly or it can search around all over your repository. s17 00:01:23.120 --> 00:01:26.200 And that takes time and that takes tokens. s18 00:01:26.200 --> 00:01:28.760 And this is a very fixable problem. s19 00:01:28.760 --> 00:01:32.600 And if you have issues in your codebase, right? s20 00:01:32.600 --> 00:01:36.520 As I'm sorry to break it to you, every codebase does. s21 00:01:36.520 --> 00:01:44.920 That is uh unfortunately, it's highly likely that these issues will be replicated and these patterns repeated by whichever agent you're using. s22 00:01:44.920 --> 00:01:59.240 And not if, but when that agent introduces new issues, if it's not caught the ability to maintain the quality of your code is almost impossible to do. s23 00:01:59.240 --> 00:02:03.892 So um our solution to that is Sonar Vortex. s24 00:02:03.892 --> 00:02:06.412 I'm going to show you that here in a little bit. s25 00:02:06.412 --> 00:02:11.932 Um what it is it is a plug-in that connects to whatever coding agent you use. s26 00:02:11.932 --> 00:02:17.332 And uh this is so the agent knows about your project before it even begins to code. s27 00:02:17.332 --> 00:02:25.732 And it is able to verify itself deterministically to make sure that it's introducing no new issues into your code base. s28 00:02:25.732 --> 00:02:35.092 So, um I had I recorded a coding agent writing a small feature a little bit ago and it it was able to do so in under 2 minutes, but unfortunately, s29 00:02:35.092 --> 00:02:43.652 even though I had instructed it to build out a test suite for itself, it introduced a security issue that Sonar Vortex was was able to catch and forced the agent s30 00:02:43.652 --> 00:02:48.012 to continue iterating upon itself until it was fixed. s31 00:02:48.012 --> 00:03:02.252 So, um the issue ended up being, and we'll see this here momentarily, is that it wrote it it was to unzip a log file into a temp file, but unfortunately, the permissions that it set for that temp file s32 00:03:02.252 --> 00:03:04.252 um were not explicit. s33 00:03:04.252 --> 00:03:16.492 And that type of issue is hard to write tests for, it's hard to catch, and it's usually the type of thing that a senior reviewer would only catch if they're explicitly looking for it, if at all. s34 00:03:16.492 --> 00:03:26.292 And then let's say that they do catch it, now it has to be sent back for a developer or an agent to rework again and re-push and re-review and re-analyze s35 00:03:26.292 --> 00:03:32.052 and that burns time and money and it causes a lot of frustration for everyone involved. s36 00:03:32.052 --> 00:03:42.052 So, um that the frustration in that process is not just my opinion, that is uh from data that we've pulled. s37 00:03:42.052 --> 00:03:52.092 Sonar surveyed over 1,100 developers and found that 96% percent of them do not fully trust AI-generated code. s38 00:03:52.092 --> 00:03:58.492 But how many how many of those do you think actually fully verified the code before pushing it? s39 00:03:58.492 --> 00:03:59.692 It It was less than half. s40 00:03:59.692 --> 00:04:01.492 It was 48% of those. s41 00:04:01.492 --> 00:04:05.134 So, that that boggles my mind, personally. s42 00:04:05.134 --> 00:04:12.334 That terrifies me that we are just blindly setting off code into production without verifying it. s43 00:04:12.334 --> 00:04:19.174 Um but um like I said, the agents write quickly. s44 00:04:19.174 --> 00:04:26.974 Rework slows you down, and if you catch it at the PR, um you're already behind where you need to be. s45 00:04:26.974 --> 00:04:34.374 But, uh a quick animation to kind of demonstrate what I'm talking about here is as I mentioned, Sonar Vortex. s46 00:04:34.374 --> 00:04:40.094 One of the goals that we are doing is we are making your coding agents more efficient. s47 00:04:40.094 --> 00:04:42.694 In addition to providing guardrails for them. s48 00:04:42.694 --> 00:04:54.694 But, this little ball here is your coding agent, which as I said, it writes a lot of code really really fast, faster than humans can keep up with, faster than we are able to review manually. s49 00:04:54.694 --> 00:05:01.214 Unfortunately, as I said, when it starts out, this this grid is your code base. s50 00:05:01.214 --> 00:05:02.774 Every square is a file. s51 00:05:02.774 --> 00:05:04.734 It has to go searching around. s52 00:05:04.734 --> 00:05:07.694 Every time it moves, it's checking a new file. s53 00:05:07.694 --> 00:05:14.334 And that bar at the bottom is tokens, which is your money and time spent on just looking around. s54 00:05:14.334 --> 00:05:19.854 And when it gets something wrong, you get to find out at the pull request. s55 00:05:19.854 --> 00:05:31.534 The review fails, and the work goes back to the agent for another round, and it continues to iterate itself, and you got to keep pinging your senior engineer, and then he's mad at you, and then nobody has a good time. s56 00:05:31.614 --> 00:05:43.774 Before it writes anything with Sonar Vortex now, it is going to get the coding guidelines for your project and a map of how the code connects. s57 00:05:43.774 --> 00:05:47.894 So, it will pull in things like your architecture guidelines. s58 00:05:47.894 --> 00:05:56.694 It will pull in things like what the approved libraries for your applications are, what your coding standards are for uh a given project. s59 00:05:56.694 --> 00:06:00.974 And these are all things you get to set for yourself. s60 00:06:01.174 --> 00:06:03.734 So, now you can see here, it goes straight to to files. s61 00:06:03.734 --> 00:06:08.895 It does not burn excess tokens, it does not burn excess context. s62 00:06:08.895 --> 00:06:12.855 And as it works SonarQube checks its code. s63 00:06:12.855 --> 00:06:19.975 So, your agent, the edits that it makes with its own tools, every time it uses them it triggers a quick check. s64 00:06:19.975 --> 00:06:28.735 And before it ends its turn, it's told to run a deeper check um for even deeper security issues for cross-file data flow. s65 00:06:28.735 --> 00:06:36.735 And you see here that issue goes back to the agent and the agent fixes its own code and then Vortex checks it again. s66 00:06:36.735 --> 00:06:47.135 And this all works with all of the agents that people are currently using right now, be that Cloud Code, Codex, Antigravity, whatever you want to use. s67 00:06:47.135 --> 00:06:57.895 And if you have any custom agents designed or using any open-source ones or any of the non-major players, uh we have MCP clients that are very configurable for you to use s68 00:06:57.895 --> 00:07:00.495 at your own desire for that. s69 00:07:00.495 --> 00:07:07.735 So, essentially what I want you to take away from this is that Vortex is something that you can just plug in easily to your agent. s70 00:07:07.735 --> 00:07:18.495 It it isn't built on top of the CLI and MCP tools that we provide it and it brings SonarQube into the agent so that the agent knows your project s71 00:07:18.495 --> 00:07:19.135 before it writes. s72 00:07:19.135 --> 00:07:23.615 I'm going to pause it or I'm going to move back before I miss it. s73 00:07:23.615 --> 00:07:31.855 And what we found is that it spends 36% fewer tokens on average, especially on tasks like refactoring existing codebases. s74 00:07:31.855 --> 00:07:42.735 People who use it have a 44% reduction in production outages and we have a very low false positive rate as well so that we don't clutter up your coding s75 00:07:42.735 --> 00:07:44.255 sessions. s76 00:07:44.255 --> 00:07:46.575 So, um this is huge. s77 00:07:46.575 --> 00:07:47.135 This is huge. s78 00:07:47.135 --> 00:08:01.575 This the speed that this um accelerates the coding cycle to the software development cycle to is um it's we're on the new frontier being able to verify uh programming. s79 00:08:01.575 --> 00:08:07.177 So, to sum it all up we want to guide the agent and verify the change. s80 00:08:07.177 --> 00:08:11.977 And we bring SonarQube's existing intelligence into the mix. s81 00:08:11.977 --> 00:08:15.057 So, I'm sure at least some of you are familiar with SonarQube. s82 00:08:15.057 --> 00:08:27.417 We've been around for almost two decades, and we are traditionally a a pipeline step that a lot of people run that deterministically analyzes for any security issues, maintainability issues, s83 00:08:27.417 --> 00:08:32.897 any data flow issues, and we build out graphs, and we dive deep into the code. s84 00:08:32.897 --> 00:08:43.977 Now, with this knowledge already maintained within our servers, we're able to provide that context to an agent, so now it exists from the get-go. s85 00:08:43.977 --> 00:08:50.177 Um your agent knows your project before it writes, and it checks its own code as it goes. s86 00:08:50.177 --> 00:09:00.137 Your CI already has a SonarQube scan, and then Vortex reuses what that scan has learned, so it's just a quick check on your file, and it knows about the rest s87 00:09:00.137 --> 00:09:00.937 of your code. s88 00:09:00.937 --> 00:09:05.937 So, here I'm going to show it to you in a real task. s89 00:09:05.937 --> 00:09:08.617 This I actually recorded last night. s90 00:09:08.617 --> 00:09:13.897 And what you can see from the get-go, and I'll be pausing and restarting it here and there. s91 00:09:13.897 --> 00:09:20.657 Uh the first thing that I want you to see is that without having to do anything, we can see SonarQube has started up in the session. s92 00:09:20.657 --> 00:09:20.977 Right? s93 00:09:20.977 --> 00:09:26.617 Our CLI is detected, and the hook system is detected as well, and secrets detection is on. s94 00:09:26.617 --> 00:09:39.697 I'm not going to dive too much into that today, but um secrets leakage is one of the easiest things to prevent, and one of the most costly for your organization. s95 00:09:39.697 --> 00:09:47.937 Our plugin prevents uh secrets leaks into GitHub and into agent uh context memories. s96 00:09:47.937 --> 00:09:53.257 And what I want you to notice is I didn't have to paste any Sonar instructions into the prompt. s97 00:09:53.257 --> 00:09:56.657 It's just all automatically loaded. s98 00:09:56.657 --> 00:10:06.177 And so, the request that I alluded to earlier, right here, is uh it's just basically unzipping a log file into a temp file. s99 00:10:06.177 --> 00:10:11.218 It says, "Keep reusing that same file, and then write a test that proves it's reused." s100 00:10:11.218 --> 00:10:14.858 And before it writes a single line, it's going to ask Sonar two things. s101 00:10:14.858 --> 00:10:18.018 It's going to say, uh where does this class live? s102 00:10:18.018 --> 00:10:21.538 And what are the Java coding guidelines for this project? s103 00:10:21.538 --> 00:10:22.098 And it's right here. s104 00:10:22.098 --> 00:10:28.618 It's Sonar context navigation, um and we get this pattern, this single GC log file that I told it to work on. s105 00:10:28.618 --> 00:10:38.498 So, it gets parent and child architecture, um as well as existing patterns, um and and uh guidelines around that. s106 00:10:38.498 --> 00:10:41.818 As well, it says Sonar context guidelines get language is Java. s107 00:10:41.818 --> 00:10:53.898 So, we have um basic guidelines that we enforce agents use when building out Java projects, but if you have any customer requirements that you want your team to follow, s108 00:10:53.898 --> 00:10:55.578 uh that gets injected from the get-go. s109 00:10:55.578 --> 00:11:09.378 And guys, I cannot emphasize enough that outside of model choice, the context and steering from the get-go that agents receive is the single greatest lever that you can manipulate s110 00:11:09.378 --> 00:11:11.658 for agentic performance. s111 00:11:11.658 --> 00:11:22.138 Um and the more you do on the front end, the less rework and steering and correcting and intervention that you have to do when you're developing for yourself. s112 00:11:22.138 --> 00:11:28.418 So, like uh instead of searching through the files one by one like in the animation, it just gets that map. s113 00:11:28.418 --> 00:11:33.738 This is the guide phase uh that that Vortex does. s114 00:11:33.738 --> 00:11:43.498 And so, it's able to inspect the existing test, see how uh that operates, and very quickly move on into implementation. s115 00:11:43.498 --> 00:11:55.018 Now, that just took a few seconds, and obviously this changes from feature to feature, but running against this feature without Vortex takes longer as this has to grep around s116 00:11:55.018 --> 00:11:57.858 and figure out what's going on. s117 00:11:58.458 --> 00:12:07.058 So, it's running the implementation, and I will very quickly point out uh where it actually makes that temp file. s118 00:12:07.058 --> 00:12:09.138 Um it adds in its own test suite. s119 00:12:09.138 --> 00:12:10.578 So, here's the test suite. s120 00:12:10.578 --> 00:12:12.458 Uh in the recording, I scroll up. s121 00:12:12.458 --> 00:12:14.939 This a little bit right here is a temp file. s122 00:12:14.939 --> 00:12:15.899 And I hope you guys can see. s123 00:12:15.899 --> 00:12:18.339 It's probably really small for you in the audience. s124 00:12:18.339 --> 00:12:21.019 Um, but it creates that temp file right there. s125 00:12:21.019 --> 00:12:28.339 And, um, it's going to go ahead and check its own test result, and then it will run the sonar check on both of the files that it changed. s126 00:12:28.339 --> 00:12:33.859 Right here it says confirming the test result, and it says running Vortex analysis. s127 00:12:33.859 --> 00:12:40.499 Every time a file is edited or added, Vortex analysis runs. s128 00:12:40.499 --> 00:12:42.299 You do not have to enforce it. s129 00:12:42.299 --> 00:12:44.659 You do not even really have to think about it. s130 00:12:44.659 --> 00:12:49.499 It just automatically kicks in, and you can trust your code gets verified. s131 00:12:49.499 --> 00:12:59.099 If you have automated workflows set up, if you run a sophisticated, you know, factory design, or you're building these out, this is a layer of trust you need to add s132 00:12:59.099 --> 00:13:02.979 in order to make sure that no issues are being introduced. s133 00:13:02.979 --> 00:13:08.979 One point as well, this is not another AI checking AI, right? s134 00:13:08.979 --> 00:13:12.419 Um, and it's certainly not it checking itself. s135 00:13:12.419 --> 00:13:20.579 That is, unfortunately, we found one of the least reliable ways to ensure that issues are not being introduced. s136 00:13:20.579 --> 00:13:34.899 Not only do agents think orthogonally on the creation and review of themselves, um, other Asian agents are likely to miss and hallucinate when reviewing existing code. s137 00:13:34.899 --> 00:13:45.899 When you have a deterministic layer, and by that I mean, every time you run the analysis on the code, you get the same result back, that is how you are able to provide reliable, s138 00:13:45.899 --> 00:13:52.379 governable, uh, guidance and verification that is compliant and predictable. s139 00:13:52.379 --> 00:13:53.299 Don't get me wrong. s140 00:13:53.299 --> 00:13:54.619 I love AI review. s141 00:13:54.619 --> 00:13:59.179 We also have a, um, AI reviewing tool that I'm not going to talk about today. s142 00:13:59.179 --> 00:14:00.219 It's called Guitar. s143 00:14:00.219 --> 00:14:02.339 I ran a workshop earlier this week on that. s144 00:14:02.339 --> 00:14:05.259 And please come by our booth later if you'd love to hear more information. s145 00:14:05.259 --> 00:14:17.701 But, Sonar Vortex is a deterministic layer that stacks on top of your AI coding, and sandwiched between another AI review as well. s146 00:14:17.701 --> 00:14:24.181 So, we're running the Vortex analysis and it is going to catch something. s147 00:14:24.181 --> 00:14:32.461 It'll catch six findings that come back and Claude will say two of those findings are on lines that it just wrote and four on pre-existing code. s148 00:14:32.461 --> 00:14:36.301 Now, we did not engineer Vortex to be super noisy. s149 00:14:36.301 --> 00:14:41.781 We did not engineer Vortex to say, "Oh, you found one issue, but you got to fix three more." s150 00:14:41.781 --> 00:14:54.021 On new code that is created, it enforces correction and that just surfaces it to you so that you have it for your awareness and if in the future you'd like to fix it, you are able to. s151 00:14:54.021 --> 00:15:03.421 One of the findings um that that it has is a security problem, the one that I mentioned uh at the start of this, which is that Claude put the log s152 00:15:03.421 --> 00:15:06.941 in the default temp folder without saying who can read it. s153 00:15:06.941 --> 00:15:10.341 And on a lot of servers, that folder is shared. s154 00:15:10.341 --> 00:15:16.941 So, uh Claude goes ahead and it uh fixes uh the issue here. s155 00:15:16.941 --> 00:15:27.021 But, unfortunately, and we'll see this in a second, Sonar Vortex runs again and determines, "Hey, you actually did not fix the issue." s156 00:15:27.021 --> 00:15:32.221 Says, "The finding persists because the temp file is still in a shared directory." s157 00:15:32.221 --> 00:15:46.861 The first fix leaned on a Java default and on Mac uh and Linux, the default is already owner only, but the rule that we set in, which is a high bar that we set, is that this is the permissions must be set explicitly. s158 00:15:46.861 --> 00:15:49.501 We do not compromise when it comes to uh security. s159 00:15:49.501 --> 00:15:53.621 We do not compromise when it comes to quality. s160 00:15:53.621 --> 00:16:03.061 So, finally, Claude is able to implement these fixes and again, every time it runs, Vortex analysis is initiated. s161 00:16:03.061 --> 00:16:17.622 You do not want to let any issues into your PR because the quicker you can catch these, not only does the surface area of the issues get reduced, but the time and money and energy s162 00:16:17.622 --> 00:16:20.902 for remediation decreases. s163 00:16:20.902 --> 00:16:23.982 Now, uh that's it for the terminal session. s164 00:16:23.982 --> 00:16:34.862 I'm not going to make everyone stare into a tiny uh pre-recorded terminal session, but essentially, what I want everyone to take away from this is that it asked Sonar s165 00:16:34.862 --> 00:16:36.142 first. s166 00:16:36.142 --> 00:16:41.782 When Sonar flagged it's fixed, it went further and continued to remediate itself. s167 00:16:41.782 --> 00:16:51.022 And it will eventually hand it back at the end, and a deep analysis uh for data flow will be performed. s168 00:16:51.622 --> 00:16:52.302 What do you get? s169 00:16:52.302 --> 00:16:54.182 What do you get out of this? s170 00:16:54.182 --> 00:16:57.662 You get less back and forth review, and I see I have a minute left. s171 00:16:57.662 --> 00:16:59.742 I'll uh finish up here in a bit. s172 00:16:59.742 --> 00:17:09.942 You get less back and forth forth review, you get it fixed in the moment, you get more secure code, you get less time and money spent on remediation, and s173 00:17:09.942 --> 00:17:18.942 um you have more time freed up for your developers because of your ability to trust uh automating agentic workflows. s174 00:17:19.462 --> 00:17:21.062 We have a booth downstairs. s175 00:17:21.062 --> 00:17:22.302 I would love to talk to you guys. s176 00:17:22.302 --> 00:17:27.022 I'll be hanging out behind uh the room in the back uh to answer any questions. s177 00:17:27.022 --> 00:17:28.542 I would love to talk with you. s178 00:17:28.542 --> 00:17:34.982 If you're brand new to Sonar, if you're an existing Sonar customer, um you know, I'd still love to hear your input and insights. s179 00:17:34.982 --> 00:17:37.902 And um that's all I have for you today. s180 00:17:37.902 --> 00:17:40.262 Thank you very much.