---
url: "https://youtube.com/watch?v=03l29gJXpCE&is=-Z6CiSqH1mVxamtH"
title: Guide, Verify, Solve — Anirban Chatterjee, Sonar
source_kind: youtube
author: AI Engineer
captured: "2026-08-17T00:10:08+00:00"
comment_tree: false
topics: [ai-impact]
summary: Anirban Chatterjee from Sonar discusses how AI coding tools cause temporary productivity spikes but lead to persistent code complexity and quality issues, emphasizing the need for safety and trust in AI-assisted development.
status: ok
---

# Guide, Verify, Solve — Anirban Chatterjee, Sonar

Channel: AI Engineer

## Transcript

[1s] [music]
[13s] >> All right.
[14s] >> [applause]
[17s] >> Thank you. That's very helpful. My name
[18s] is Anirban Chatterjee. I do product
[20s] marketing at Sonar. I'm really excited
[22s] to be talking to this group today. It's
[23s] actually my first time here at this
[25s] conference.
[26s] Um and so I've been having a blast uh
[29s] along with my team here
[31s] uh meeting a whole bunch of AI engineers
[33s] as well as leaders and
[35s] you know, influencers and
[38s] founders. Uh there's a lot going on in
[40s] this space. I think this year there's
[42s] really been a turning point from
[44s] experimentation to engineering. And that
[46s] makes me that warms my heart very deeply
[48s] because I started my career many many
[51s] many many many years ago as a software
[54s] engineer uh writing code for for
[56s] servers, if you can believe it. Um
[59s] and I think there's a turning point
[61s] that's happening right now where we're
[64s] starting to add the capabilities that we
[67s] need to add to these systems in order to
[68s] make them repeatable, make them
[69s] scalable, make them consistent much in
[71s] the way we were doing with cloud
[72s] computing not too long ago in order to
[74s] expand the access that IT technology
[78s] gave to small businesses and other
[80s] innovators. I think AI is going to do
[81s] the same thing for software development
[83s] going forward. But in order to do that,
[85s] in order to get there,
[86s] we need to start adding safety and trust
[88s] to these systems so that they can be
[90s] used more widely across a wide variety
[92s] of use cases so we can build new things
[95s] and solve bigger problems. And how we
[97s] get there is what we're going to talk
[98s] about today.
[99s] And uh for those of you who were in uh
[101s] Tarik's keynote yesterday, uh he
[103s] presented some of this data and I'm
[104s] going to talk about it a little bit
[105s] deeper today. So there was a study that
[107s] Carnegie Mellon did
[109s] um where they actually looked at
[111s] projects that were posted on GitHub. And
[113s] they were able to use the metadata to
[114s] support to sort them into projects where
[118s] uh there were just traditional tools
[119s] that were being used and projects where
[121s] an AI tool was used to write the code.
[122s] In this case, it was Cursor, although it
[124s] could have been any AI tool. And what
[126s] they found was interesting. They found
[127s] that there was, in fact, a temporary
[129s] spike in productivity, um
[132s] but it lasted about 3 months and then it
[135s] went back down.
[136s] And the reason for that, we think, is
[138s] because there was also a persistent
[139s] increase in static analysis warnings and
[142s] code complexity. They're actually using
[143s] SonarQube uh to actually collect the
[146s] data on this and they saw that there was
[148s] a persistent increase in these types of
[149s] issues that went beyond the 3-month mark
[152s] and persisted well into the future. And
[154s] so, it's these types of issues that end
[156s] up actually slowing developers down even
[158s] more and and making And this is what
[160s] makes it a challenge to deliver
[162s] high-quality code using AI tools.
[166s] The reason for this is that there's a
[167s] differing need for quality depending on
[169s] the criticality of the application,
[171s] right? If you're experimenting, if
[173s] you're playing around, if you're just
[174s] one person building things to see what's
[176s] possible, um if it's an internal
[178s] non-critical application which has a few
[180s] users, maybe it's just you, maybe it's a
[181s] small team, maybe it's just a
[183s] short-lived project that's not going to
[184s] last very long, the gap between the
[186s] quality that you're getting from the AI
[188s] tool and the quality you need from the
[189s] application is quite small, right? And
[191s] so, you can And you can live with uh
[193s] that gap. But as you move to higher
[196s] levels of criticality, as you run into
[198s] situations where you're supporting many,
[200s] many users, it's a larger code base with
[202s] many lines of code and many changes
[203s] happening across that code base all the
[206s] time. Uh you have many, many users. Some
[208s] of them could be adversaries that are
[210s] actively trying to break your software,
[212s] right? And so, in those cases, the
[214s] quality level you need is quite a bit
[216s] higher than the quality level you're
[218s] getting by default from these AI tools.
[219s] And that's where this verification debt
[221s] comes in. That's where you have to bring
[224s] the humans in, bring your software
[225s] engineers in to try to close that gap
[228s] and make sure that the quality level is
[230s] is up to an acceptable level before you
[232s] ship that code
[234s] into production. So, why is this
[235s] happening? Why is this gap actually
[237s] occurring? We know these models are
[238s] excellent. They're getting better and
[239s] better all the time. I'm really excited
[241s] to start playing with Fable now that
[242s] that's out to see what levels of
[245s] of code we can get out of Fable going
[247s] forward. But, we do know that because of
[249s] the technology, because of the way that
[250s] these models are built, they will still
[252s] make mistakes. They will still have
[254s] quality issues. They are still somewhat
[256s] error-prone. And if you let these errors
[259s] go into production code, you could have
[260s] a catastrophic effect to your
[262s] organization. They're also missing
[264s] context, right? They only know what you
[265s] tell it. They don't know the broader
[267s] things that are happening elsewhere in
[269s] the code base. They don't know what's
[270s] happening with your business. They don't
[271s] know what happened in the meeting you
[273s] had with somebody else 2 weeks ago
[274s] that's going to influence the code
[275s] you're writing today. They don't have
[277s] all of the context that you have as an
[278s] engineer, right? And so, they don't
[280s] always know your objectives the way you
[282s] do. And that is going to also cause gaps
[284s] between what you need from the software
[286s] and the way it's built.
[291s] We also know that models are diverse. No
[293s] two models are the same and they have
[294s] diverse quality issues. And we actually
[296s] want to explore this. And so, we
[298s] actually have a leaderboard that you can
[299s] go to on our website right now. It's
[300s] called the LLM leaderboard. And what we
[303s] do is we take all of the major new
[304s] models that come out and we evaluate
[306s] them. We give them, you know, 4,000 or
[308s] so coding tasks and we evaluate them
[310s] using all of the metrics that SonarCube
[312s] uses to evaluate code, right? We look at
[314s] their correctness, complexity,
[316s] the way the rate at which they're
[317s] solving the tasks we assign them, and
[319s] then our classic things maintainability,
[320s] reliability, and security. And we're
[322s] able to kind of graph all of these
[324s] models across these different axes and
[325s] show you where models perform well and
[327s] where they have room to improve. And
[329s] what you're looking at on the screen
[330s] right now is actually Claude Opus 4.6
[332s] and Claude Sonnet 4.6. If you're a
[334s] Claude customer, you might be toggling
[336s] between these two models to control your
[338s] token burn rates. And you'll see that
[340s] Claude Sonnet is actually quite good
[342s] from a correctness standpoint, from from
[344s] solving tasks, and from a standpoint.
[347s] But if you're requiring higher levels of
[349s] maintainability or higher levels of
[350s] security, if you're trying to get a
[352s] lower complexity out of your code, you
[353s] might benefit from switching to Opus for
[355s] tasks like that. And so we run these
[357s] kinds of analyses across a lot of
[359s] different models, and you're always able
[360s] to go to our website to get the latest
[362s] analyses that we run. I think we're
[363s] actually doing the latest Claude and and
[365s] OpenAI models pretty soon.
[367s] But this kind of data is helpful, right?
[369s] Because it tells you what where models
[370s] are good and where models are not good.
[372s] It also serves to put some sunlight on
[374s] the fact that you still need to be
[375s] vigilant with these models, right? None
[377s] of these models are ever going to be
[378s] perfect. You're always going to have
[380s] some kind of need for verification in
[381s] the loop to make sure
[384s] that the code that you're getting is the
[386s] code you actually want to ship. Now,
[387s] classically, that verification can be
[389s] human verification. It can be you. Your
[391s] own eyes reading the code, your own
[393s] intellect reviewing the code to make
[395s] sure that it's successful. But we know,
[397s] based on experience and now based on
[398s] research, that human review can also be
[400s] compromised. This is a study that was
[402s] done earlier this year by Wharton, and
[404s] they actually gave quite a lot of human
[406s] participants tasks to complete, and they
[408s] gave those human participants the use of
[410s] an AI
[412s] tool to complete those tasks. But
[413s] unbeknownst to those participants, the
[415s] AI was told to confidently lie to these
[419s] participants some of the time.
[421s] And what they found in the data is that
[422s] while participants did follow the AI
[424s] advice 92.7% of the time when the AI was
[427s] correct, they unfortunately also
[429s] listened to the AI nearly 80% of the
[431s] time when the AI was wrong.
[433s] This is almost surely happening in code
[436s] review as well, right? Especially when
[438s] there's higher amounts of code being
[439s] written, when there's multiple agents
[441s] writing code simultaneously, when you
[443s] now have to bring all those pieces
[444s] together into a single software
[445s] application, the load is just too great.
[447s] There's there's only so many hours in
[448s] the day, right? And you still have to
[450s] ship something. And so there's a lot of
[452s] rubber stamping that I'm sure is
[453s] happening in all of your organizations.
[455s] It's happening everywhere. And so we
[456s] need to backstop that somehow with an
[459s] automated verification tool. What can we
[461s] do about it, right?
[462s] As Tarek was talking about yesterday,
[465s] you know, I think all of us sort of when
[467s] we got involved with software, one of
[469s] the things that we find most attractive
[470s] about it is that code is is quite, you
[474s] know, once you write code properly, it's
[475s] going to run the same way every single
[477s] time and there's a certain level of
[478s] comfort in that, right? There's a
[480s] certain level of comfort in knowing that
[481s] if I write this function the right way,
[484s] it is going to work this way every
[485s] single time. And there's there's a
[487s] clarity that comes to that and there's
[489s] there's a certain confidence you get out
[491s] of being able to build something that
[492s] you know is going to work well for every
[494s] user going forward, but we also know
[496s] that code's written by humans, humans
[498s] have requirements, and those
[500s] requirements and externalities have
[501s] impact in how this code functions. And
[504s] as you add more and more and more code
[505s] to the application, they can interact in
[508s] unpredictable ways. As you now allow
[509s] users to use those applications, those
[511s] users can do all kinds of things you
[513s] didn't expect, and so software is not
[515s] provable in the same way that code is
[517s] provable. Software can break in
[519s] interesting and novel ways, and as
[521s] you're using AI to write more and more
[523s] software to solve bigger and bigger
[525s] problems,
[526s] um you're going to run into these
[528s] limitations more and more often. And so
[529s] having automatic verification as part of
[532s] this process is an important part of the
[534s] solution. It's going to help you control
[537s] some of the risks that you're
[538s] introducing by
[540s] maybe releasing some of the control you
[541s] have over the code that's actually being
[543s] written. And so we believe that
[544s] verification is going to be a key
[546s] enabler and a and a key unblocker for
[549s] all of the amazing things that we're
[551s] going to be able to achieve with with
[552s] the AI-driven software development going
[555s] forward.
[556s] And so when we say verification, what do
[557s] we mean, right? We think there's two
[559s] core elements
[561s] to successful automated verification
[562s] when it comes to AI coding. One is that
[565s] needs to be zero trust. What do we mean
[566s] by that? Zero trust in this context
[568s] basically means that the code could
[569s] really have come from anywhere.
[571s] It could still be written by a human, it
[572s] could be written by an AI as I just
[574s] showed you a few slides ago. Different
[576s] AIs will write code in different ways,
[578s] and you're not going to want to be able
[580s] You're not going to want to use that
[581s] same AI to to validate the code because
[584s] you're going to want a diversity of of
[586s] tools being used to make sure that
[588s] you're catching all the different issues
[589s] that can happen. And so, no matter where
[591s] the code is coming from, you want to
[593s] have a a similar comprehensive regime to
[595s] verify that code that works the same no
[598s] matter how that code was written, right?
[600s] Use a different methodology to review
[601s] the code that was used to write the
[603s] code. Uh it's completely auditable,
[605s] completely explainable, so you can prove
[607s] that verification was run the same way
[609s] every single time, and it's algorithmic
[611s] and repeatable and consistent no matter
[612s] how you run it.
[613s] It also needs to be multi-layered. You
[615s] need to have multiple ways uh a multiple
[618s] techniques being used, multiple
[620s] approaches being used to review the code
[621s] that is being generated, right? Um
[623s] because you're never going to be able to
[624s] find every single
[626s] problem that can occur in software by
[628s] just using one or two methods. You need
[629s] to use computational review, you also
[631s] need to use LLM driven review,
[634s] and everything else in between, right?
[638s] You heard a little bit about agentic I'm
[639s] I'm really I've been hearing a lot about
[640s] agentic loops this week, uh and Tarik uh
[643s] talked yesterday about our framework for
[645s] agentic loops. We call it ACDC, or
[647s] agentic agent-centric development cycle.
[649s] And there's three phases in in the ACDC
[652s] that we that we like to talk about. The
[654s] the easiest one By easiest, I mean the
[656s] the fastest one to implement now, the
[658s] one that many of you are probably
[659s] already on a path to implementing, is
[660s] the verification step, which is front
[662s] which is top center, right? This is the
[664s] most important piece that allows you to
[667s] to write code in these agentic loops in
[669s] a way that is going to be easily
[670s] shippable. Uh it needs to be
[672s] multi-layered, it needs to be reasoning
[674s] based, and it needs to cut across
[676s] quality issues, security issues, and
[677s] compliance issues to make sure that
[678s] you're shipping quality that you can
[680s] stand behind, right? Um before the
[683s] verification step, there's a guidance
[684s] step.
[685s] And what guide allows you to do is
[686s] provide guardrails and context and
[689s] constraints to make sure that the agent
[691s] has everything it needs up front to
[693s] write better code uh uh uh the first
[695s] time, right? And then finally, after
[697s] verification, you need to solve the
[699s] issues that come up, right? And that's
[700s] where the solve state come. That's where
[701s] you can remediate any issues that are
[702s] found in the code. You Hopefully, you're
[704s] allowing the agent to have the agency to
[706s] do so itself by providing access to the
[709s] tools it needs to to find the issues and
[712s] fix them itself and then just repeat the
[713s] loop. And so these these agentic loops
[715s] with verification at the core is how you
[717s] can get to shipping quality software
[719s] using AI agents.
[721s] And there are prior there's different
[724s] reasons why you would want to do this.
[725s] And when we talk to customers, and we've
[726s] talked to a lot of customers about this,
[728s] uh the driving functions that are
[730s] forcing them to adopt verification
[732s] across all of their AI coding processes
[735s] are are very similar, right? They want
[737s] to make sure that AI code is verified
[738s] consistently. They don't want to have
[740s] different methods of verification
[742s] applying to different projects or
[743s] different teams. They want to have a
[744s] standard rulebook that applies
[746s] everywhere, no matter what tool is being
[748s] used. They all also want to make sure
[749s] they're using their AI tools
[750s] effectively, right? Some of that a big
[753s] part of this is token efficiency or just
[754s] efficiency in general, but also just
[756s] making sure that the tools are being
[757s] used for the things they're being
[758s] designed to do in ways that we know
[760s] they're good at doing, right? So we talk
[762s] a lot about token efficiency, and we
[763s] talk a lot about making sure that the
[765s] right models are used for the right
[766s] projects, and so on. Finally, third,
[769s] catching issues from a security
[771s] standpoint as early as possible in
[773s] development cycle. Shifting left on
[775s] security issues has been very important
[777s] for a number of years now, and now that
[778s] AI is writing more and more code,
[780s] catching security issues up front is
[782s] extremely critical, especially now that
[784s] we're in a world where CVEs are
[787s] announced and then immediately exploited
[789s] uh by bad actors almost often the same
[791s] day. And so you need to make sure that
[793s] your code is as hardened as possible
[795s] from those types of issues creeping into
[796s] production. And finally, maintaining
[798s] compliance. Many of you, I'm sure, work
[800s] in a regulated industry,
[801s] uh and for those types of situations
[803s] where you need to be able to prove that
[804s] verification is run constantly and
[806s] consistently across the board.
[808s] Maintaining an audit trail that allows
[809s] you to prove that is extremely
[811s] important.
[812s] We have a number of solutions that that
[814s] help with that. SonarQube has been
[816s] around for quite a while. There are
[817s] probably quite a few of you that are
[818s] already SonarQube users. It is a zero
[820s] trust multi-layered verification
[822s] platform that works across syntax
[824s] issues, data flow issues, architectural
[825s] issues, control flow issues. And it
[827s] works across basically any language you
[829s] would be using. We have a lot of deep
[831s] hooks that I'm going to take you through
[832s] in a moment that allow agents to have
[835s] first party access to the SonarQube
[837s] verification so they can more
[838s] effectively write high quality code. And
[840s] we also just recently, and by recently I
[842s] mean just a few weeks ago, acquired a
[844s] company called Gitarr, based right here
[846s] in San Mateo. And they do AI code
[848s] review.
[849s] And more than that, they actually
[851s] build a full they build and automate the
[853s] full CI workflow so that you can not
[855s] only find issues using an using our LM
[860s] approach, but you can also automatically
[862s] block if those issues cause a quality
[864s] issue that you would want to push
[865s] forward. It can write fixes and it can
[867s] approve those fixes and merge those PRs
[868s] completely automatically if you wanted
[870s] to. Now, we'd want to earn that trust.
[872s] It doesn't happen that way by default
[873s] usually.
[875s] By default they'll just find the issues
[876s] and show them to you and enter a
[878s] dialogue with you so you can have those
[879s] issues fixed. But as you use it more and
[882s] more and gain confidence, you can turn
[883s] on more and more features and completely
[885s] automate the PR review workflow if you
[887s] like using Gitarr.
[890s] So, the other big news from earlier this
[893s] week, and Tarik alluded to this during
[894s] his talk yesterday, is that we also
[896s] announced a new agentic loop capability
[898s] with a product called Sonar Vortex. And
[900s] Sonar Vortex,
[901s] I'm going to I'm going to show another
[903s] flowchart that shows what it does, but
[904s] basically it is providing your
[906s] agents with tools in the inner loop, in
[909s] the agentic loop, to not only get
[911s] constraints and guardrails up front to
[912s] write better code, but also run
[914s] verification as it's writing code in
[916s] real time so it can find and fix the
[918s] issues that are being created. And then
[919s] we also released the remediation agent.
[921s] And the remediation agent allows you to
[923s] tackle backlog issues
[925s] and and take down your tech debt at a
[927s] scale that you might not have the
[928s] bandwidth to do now with human
[930s] developers, right? You can basically
[931s] take your your tech debt or your older
[934s] issues, your legacy code, point them at
[935s] remediation agent, and it can then
[937s] improve your code base almost in the
[939s] background while you focus on the on the
[941s] innovation work at the front end that
[942s] you're working on now.
[944s] And those are both GA as of this week.
[946s] Now,
[948s] there was a very detailed chart that was
[951s] shown during the keynote yesterday that
[952s] I'm going to kind of break down for you
[953s] and really explain what the different
[955s] pieces of this chart mean. This is kind
[956s] of how we see the ACDC applying not only
[960s] to the inner agentic loops, but also the
[962s] outer
[963s] CICD loops that we're all working in to
[965s] develop code. Before you start either of
[968s] those loops though, it is really
[969s] important to have a sense of the
[972s] specifications of what you actually are
[974s] going to want to accomplish with the
[975s] software that's being written. This is
[978s] This is your architectural constraints.
[979s] This is the way your desired
[981s] architecture for the software. This is
[982s] your coding standards and your coding
[984s] patterns that are acceptable. These are
[985s] the list of dependencies that you are
[987s] and are not allowed to use. These are
[989s] your coding standards and and syntax
[991s] standards that you obey in your
[992s] organization. This could be your your
[994s] logging practices or your observability
[996s] and tracing practices. All of that goes
[999s] into your specs and then you also need
[1001s] to define what your quality criteria
[1003s] are, right? And we have quality criteria
[1005s] that we ship with that you can use by
[1006s] default or you can adjust them as it
[1008s] makes sense for your organization, but
[1009s] this is like what are the levels of
[1011s] security, of quality, of maintainability
[1013s] that you're willing to accept in your
[1015s] code that you're pushing into
[1016s] production. You need to basically write
[1017s] that down and encode it. And now you're
[1019s] ready to start using LLM coding agents
[1021s] to write code. And whenever you're
[1024s] initiating a coding task with an with an
[1026s] with an agent, one of the first things
[1028s] that we can help is providing context
[1031s] and constraints
[1032s] so that the agent starts from the ground
[1034s] floor with an understanding of the code
[1036s] base and the guardrails that is relevant
[1038s] to it in that moment. You have to manage
[1040s] the context window of the agent you
[1041s] can't just throw your entire code base
[1043s] at the agent up front. It's going to
[1045s] spend a lot of time thrashing and
[1046s] exploring and burning tokens while it's
[1047s] doing it. We
[1050s] are able to efficiently provide just the
[1051s] context that it needs based on the work
[1053s] that it's being given so that it can get
[1055s] to work writing productive code very
[1057s] quickly. It then generates the source
[1058s] code as you can see and we also provide
[1061s] in loop verification to the agent as
[1063s] it's writing. It can call in to us and
[1065s] provide and get a list of issues that we
[1067s] are finding in real time in the code
[1069s] that's being written and the great thing
[1070s] about that is those issues can then be
[1072s] fixed immediately by the agent so they
[1073s] don't propagate into future agentic
[1075s] loops that are going to run in order to
[1077s] fully build out the software project
[1079s] that you're doing. This is being enabled
[1080s] by Sonar Vortex as of this week.
[1083s] Once all of the inner loops have run
[1086s] you get you reach a point later on when
[1088s] you have to start entering the formal
[1089s] review and shipping process for the code
[1091s] and this is the CICD process, right? And
[1093s] so there's a PR flow that gets initiated
[1096s] that I'm sure we're all familiar with.
[1097s] Guitar can live in that flow, SonarQube
[1099s] also lives in that flow in order to run
[1101s] a broad automated review of all of the
[1103s] code that is in the PR
[1105s] and an automated verification that
[1107s] actually returns issues across quality,
[1109s] security and maintainability. There's a
[1111s] superhuman review that is LLM driven by
[1113s] Guitar and there's a computational
[1115s] review that is run by SonarQube that
[1116s] actually assigns grades for all three of
[1118s] those things and won't allow the PR to
[1121s] go past into production unless it gets a
[1122s] passing grade across that criteria. So
[1125s] if there are issues that come up, you
[1126s] can actually use a fix agent to fix all
[1129s] the issues that are discovered there and
[1130s] then once you're actually able to pass
[1132s] that quality gate, that is when you're
[1133s] able to proceed in the test and build
[1136s] and deploy in the application.
[1138s] The verification needs to run in both
[1140s] the inner agentic loop and also in the
[1142s] outer loop for CICD.
[1145s] I'm running low on time so I'm going to
[1147s] hope this video completes. This is
[1148s] basically a video demo of the inner
[1150s] loop, the agentic loop. It's a it's a
[1151s] demo of Sonar Vortex, basically. And
[1153s] what you've just seen happen is we've
[1155s] given it a task and in starting that
[1157s] task, this is this is actually Cursor
[1159s] that's running right now. Cursor called
[1160s] into our Sonar Vortex context tool to
[1163s] get some context up front to to get give
[1166s] it an understanding of the code that's
[1167s] working and so it knows how to um how to
[1170s] write the code. It is now writing the
[1171s] code and once it's completed uh the
[1174s] initial write, it's going to call into
[1176s] our verification process to get a list
[1178s] of issues that it finds. And then if it
[1180s] and if issues get provided, it will
[1183s] actually fix those issues immediately in
[1185s] the inner loop. This is all happening
[1187s] automatically through an integration
[1189s] that we have directly with Cursor. We
[1190s] have similar integrations with uh with
[1193s] Claude Code, with Codex, with Any
[1195s] Gravity, with basically any major AI
[1197s] coding tool that you would have.
[1199s] And you can sort of get the gist. It It
[1200s] flagged an issue. It's got a plan. It's
[1202s] going to fix it immediately and it's
[1204s] going to run uh the analysis again and
[1206s] then it will not proceed until it
[1208s] actually is able to get a passing grade
[1209s] from us on the verification pass.
[1211s] I'm going to move past this cuz I'm out
[1212s] of time now.
[1216s] So, uh
[1218s] if you take one thing away from this
[1219s] presentation, it's that, you know, we
[1220s] believe very strongly, we're very
[1221s] convicted about this, that a governance
[1224s] and verification regime is a engine is
[1226s] extremely critical to unlock the next
[1229s] level of success that we need to be able
[1231s] to get from AI coding tools so we can
[1232s] solve bigger and bigger problems. And we
[1236s] know, based on our data,
[1237s] uh that Sonar customers and Sonar users
[1239s] are able to get higher levels of success
[1241s] from AI coding tools. I can I'm not
[1243s] going to go through all of these now cuz
[1244s] I'm out of time, but you can stop by the
[1246s] our big red booth downstairs and we'll
[1247s] be happy to talk to you about any of
[1249s] these. Um
[1251s] but, you know, the good news is I think
[1253s] many of you probably have access to this
[1254s] stuff already. Uh Sonar Cube is one of
[1256s] the most widely adopted verification
[1257s] tools in existence today. We have over 7
[1259s] million developers around the world
[1261s] using us and we analyze close to 750
[1263s] billion lines of code across our
[1264s] solutions every single day. And if there
[1266s] are a few of you in the room who care
[1268s] about Gartner at all, it's nice to know
[1269s] that we're a Gartner market uh magic
[1271s] quadrant leader as well. So,
[1273s] uh final slide, key takeaways, right?
[1275s] What are the things that we want to walk
[1276s] away from this? First, you know,
[1278s] establish some bounded autonomy
[1280s] guidelines for your AI agents. Give them
[1282s] the freedom to generate code, but also
[1284s] make sure that you're enforcing a
[1285s] centralized scheme of verification and
[1287s] constraints.
[1288s] Implement the ACDC, right? Give them
[1290s] context. Verify that they're doing the
[1292s] right work with independent metrics, and
[1295s] then use agents to solve their own
[1296s] mistakes. Empower them to do that. Make
[1298s] sure your developers are equipped with
[1300s] the orchestration tools that they need
[1301s] in order to design the context
[1303s] frameworks and the processes that are
[1305s] going to enable them to be successful
[1307s] and use AI most effectively. And
[1308s] finally, standardize on a single
[1310s] independent multi-layered verification
[1312s] platform that is used consistently
[1314s] across all projects, across all teams,
[1316s] across all developers, and all AI coding
[1318s] tools so that you can eliminate any
[1320s] blind spots that might be created by
[1321s] using silos of tools across the
[1322s] organization.
[1324s] Um that's all for me. Uh you can learn
[1327s] more by Oh, it's off the screen now. But
[1329s] uh you can come down to our big red
[1330s] booth downstairs, and we'd be happy to
[1332s] talk to you. Thank you very much.
[1348s] >> [music]