Guide, Verify, Solve — Anirban Chatterjee, Sonar

频道: AI Engineer
视频: https://www.youtube.com/watch?v=03l29gJXpCE
原文语言: en
统计: 共 20 轮

[0:01]

[music]

[音乐]

[0:13]

All right.

好的。

[0:14]

[applause]

[掌声]

[0:17]

Thank you. That's very helpful. My name is Anirban Chatterjee. I do product marketing at Sonar. I'm really excited to be talking to this group today. It's actually my first time here at this conference. 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 and founders. Uh there's a lot going on in this space. I think this year there's really been a turning point from experimentation to engineering. 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. 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 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. I think AI is going to do the same thing for software development going forward. 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 across a wide variety of use cases so we can build new things and solve bigger problems. And how we get there is what we're going to talk about today.

谢谢，这个开场很给力。我叫 Anirban Chatterjee，在 Sonar 做产品市场。今天能跟在座各位聊聊，我特别兴奋。这其实是我第一次来这个大会，这几天我和团队玩得非常开心，见了一大堆 AI engineer，还有各路技术负责人、意见领袖和创业者。这个领域现在的动静实在太多了。我觉得今年是个真正的转折点——从「做实验」转向「做工程」。这一点让我特别欣慰，因为很多很多很多年前，我职业生涯的起点就是软件工程师，当时是给服务器写代码，说出来你们可能都不信。我觉得眼下正在发生的转折是：我们开始给这些系统补上真正该有的能力，让它可复现、可扩展、可保持一致——就像不久前云计算走过的那条路，把 IT 技术的红利扩展给了小企业和更多创新者。我认为接下来 AI 会为软件开发带来同样的东西。但要走到那一步，我们得先给这些系统加上安全性和信任，这样它才能被用在更广泛的各种场景里，我们才能造出新东西、解决更大的问题。而怎么走到那一步，就是今天要聊的内容。

[1:39]

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. So there was a study that Carnegie Mellon did um where they actually looked at projects that were posted on GitHub. 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. In this case, it was Cursor, although it could have been any AI tool. And what they found was interesting. 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. And the reason for that, we think, is because there was also a persistent increase in static analysis warnings and code complexity. 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. 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 using AI tools.

昨天听过 Tarik 主题演讲的朋友，应该已经看到过其中一部分数据了，今天我想再往深里讲一点。Carnegie Mellon（卡内基梅隆）做过一项研究，他们去看了发布在 GitHub 上的项目，用元数据把这些项目分成两类：一类是只用传统工具写的，另一类是用 AI 工具来写代码的。这项研究里用的是 Cursor，不过换成任何一个 AI 工具其实都一样。他们的发现很有意思：生产力确实出现了一次短暂的飙升，但大概只持续了三个月，之后就掉回去了。我们认为原因在于，与此同时 static analysis 的告警和代码复杂度也出现了持续性上升。他们其实就是用 SonarQube 采集的这部分数据，结果看到这类问题的增加并没有在三个月后消失，而是一路持续到很久以后。正是这类问题最终反过来把开发者拖得更慢，也正是这一点，让「用 AI 工具交付高质量代码」变成一件难事。

[2:46]

The reason for this is that there's a differing need for quality depending on the criticality of the application, right? 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, 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? And so, you can And you can live with uh that gap. 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 across that code base all the time. Uh you have many, many users. Some of them could be adversaries that are actively trying to break your software, right? 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. And that's where this verification debt comes in. 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 into production. So, why is this happening? Why is this gap actually occurring? We know these models are excellent. They're getting better and better all the time. 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. But, we do know that because of the technology, because of the way that these models are built, they will still make mistakes. They will still have quality issues. They are still somewhat error-prone. And if you let these errors go into production code, you could have

背后的原因是：应用的关键程度不同，对质量的要求也不同。如果你只是在做实验、随便玩玩，一个人捣鼓点东西看看能做到什么程度；如果这是个内部的、非关键的应用，用户就那么几个，可能只有你自己，可能是个小团队，也可能只是个活不了多久的短期项目——那么 AI 工具给你的质量，和这个应用真正需要的质量，这中间的差距是很小的，你完全可以接受这个差距。但当关键程度往上走，当你要支撑成千上万的用户，代码库更大、代码行数更多、整个代码库上时时刻刻都有大量改动；当你有非常非常多的用户，其中甚至有人是主动想搞垮你软件的攻击者——这种时候，你需要的质量水平，就比这些 AI 工具默认给你的高出一大截。这就是「验证债」（verification debt）出现的地方。这时候你必须把人拉进来，让软件工程师去补上这个差距，确保代码在上生产之前，质量达到一个可接受的水平。那这事为什么会发生？这个差距到底是怎么来的？我们知道这些模型很强，而且一直在变强。Fable 刚发布，我特别期待去玩玩看，看看接下来能从 Fable 里得到什么水准的代码。但我们也知道，受限于技术本身、受限于这些模型的构建方式，它们仍然会犯错，仍然会有质量问题，仍然多少是容易出错的。而如果你放任这些错误进到生产代码里，后果可能会……

[4:20]

a catastrophic effect to your organization. They're also missing context, right? They only know what you tell it. They don't know the broader things that are happening elsewhere in the code base. They don't know what's happening with your business. 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. They don't have all of the context that you have as an engineer, right? And so, they don't always know your objectives the way you do. And that is going to also cause gaps between what you need from the software and the way it's built. We also know that models are diverse. No two models are the same and they have diverse quality issues. And we actually want to explore this. And so, we actually have a leaderboard that you can go to on our website right now. It's called the LLM leaderboard. And what we do is we take all of the major new models that come out and we evaluate them. 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? 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. 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. 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. And you'll see that Claude Sonnet is actually quite good from a correctness standpoint, from from solving tasks, and from a standpoint.

……给你的组织带来灾难性的影响。它们还缺上下文——它只知道你告诉它的那些。它不知道代码库其他地方正在发生什么，不知道你的业务在发生什么，也不知道你两周前跟某个人开的那场会说了什么、而那件事恰恰会影响你今天写的代码。它没有你作为工程师所掌握的全部上下文，所以它并不总能像你一样清楚你的目标。这同样会造成一种落差：软件本该是什么样，和它实际被写成什么样。我们还知道，模型是多样的。没有哪两个模型是一样的，它们的质量问题也各不相同。我们想把这件事摸清楚，所以我们做了一个榜单，现在就能上我们官网看，叫 LLM leaderboard。做法是：市面上重要的新模型一出来，我们就拿来评测，给它们大约 4000 道编码任务，然后用 SonarQube 评估代码的那一整套指标去打分。我们看正确性、复杂度、它们解决所派任务的速率，还有我们的经典三项——可维护性、可靠性和安全性。这样就能把所有模型放在这些不同维度上作图，告诉你哪些模型在哪些方面表现好、哪些方面还有提升空间。现在屏幕上这张，就是 Claude Opus 4.6 和 Claude Sonnet 4.6。如果你是 Claude 的用户，你可能会在这两个模型之间来回切换，用来控制 token 的燃烧速度。你会看到 Claude Sonnet 在正确性上、在解决任务上，表现其实相当不错。

[5:47]

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. 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. I think we're actually doing the latest Claude and and OpenAI models pretty soon. But this kind of data is helpful, right? Because it tells you what where models are good and where models are not good. It also serves to put some sunlight on the fact that you still need to be vigilant with these models, right? None of these models are ever going to be perfect. 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. Now, classically, that verification can be human verification. It can be you. Your own eyes reading the code, your own intellect reviewing the code to make sure that it's successful. But we know, based on experience and now based on research, that human review can also be compromised. 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 the use of an AI tool to complete those tasks. But unbeknownst to those participants, the AI was told to confidently lie to these participants some of the time.

但如果你要求更高的可维护性、更高的安全性，或者想让代码的复杂度更低，那这类任务换成 Opus 可能会更划算。我们对很多不同的模型都跑了这类分析，你随时可以去我们官网拿最新一轮的结果。我记得最新的 Claude 和 OpenAI 模型，我们很快就要跑了。这类数据是有用的，因为它告诉你模型强在哪、弱在哪。它还有另一个作用，是把一件事摆到明面上：面对这些模型，你依然必须保持警惕。没有哪个模型会做到完美。你永远都需要在流程里保留某种形式的验证，来确认你拿到的代码，就是你真正想发布出去的那份代码。传统上，这个验证可以是人工验证，可以是你自己——你亲眼去读代码，用你自己的判断去 review，确认它没问题。但我们从经验上知道、现在也从研究上知道：人工 review 同样是会失守的。这是今年早些时候 Wharton（沃顿）做的一项研究。他们找了相当多的人类参与者去完成一批任务，并且给这些参与者配了一个 AI 工具来辅助完成。但参与者并不知道的是，研究人员事先要求这个 AI 在一部分时候要理直气壮地说假话。

[7:01]

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 nearly 80% of the time when the AI was wrong. This is almost surely happening in code review as well, right? 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, the load is just too great. There's there's only so many hours in the day, right? And you still have to ship something. And so there's a lot of rubber stamping that I'm sure is happening in all of your organizations. It's happening everywhere. And so we need to backstop that somehow with an automated verification tool. What can we do about it, right? 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 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? 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. 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 we also know that code's written by humans, humans have requirements, and those requirements and externalities have impact in how this code functions. And as you add more and more and more code to the application, they can interact in unpredictable ways. 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

数据显示：当 AI 给的建议是对的时候，参与者有 92.7% 的比例会照着 AI 说的做；但很遗憾，当 AI 给的是错的时候，他们仍然有接近 80% 的比例会听 AI 的。这件事几乎可以肯定也正发生在 code review 里。尤其是当写出来的代码量更大、当多个 agent 在同时写代码、当你必须把这一堆碎片拼成一个完整的软件应用时，负担实在太重了。一天就那么点时间，而你还是得把东西发出去。所以我敢肯定，你们各自的组织里都有大量「盖个章就放行」的 review，这种事到处都在发生。因此我们需要用某种自动化的验证工具去给它兜底。那我们能做点什么？就像 Tarek 昨天讲的，我想我们当初之所以被软件吸引，其中一个原因是：代码这东西，只要你写对了，它每一次都会以同样的方式运行，这里面有一种让人安心的感觉。知道「只要我把这个函数写对了，它每一次都会这样工作」，这种确定性很让人踏实。它带来一种清晰感，也带来一种底气——你造出来的东西，你知道它对未来每一个用户都会好好工作。但我们同样知道，代码是人写的，人是有需求的，而这些需求和各种外部因素都会影响代码的运行方式。当你往应用里加进越来越多的代码，它们之间会以难以预料的方式互相影响。当你再把应用开放给用户，用户会做出各种你根本没预料到的事。所以，软件并不像代码那样是可以被证明的……

[8:37]

provable. 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. And so having automatic verification as part of this process is an important part of the solution. 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. 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. And so when we say verification, what do we mean, right? We think there's two core elements to successful automated verification when it comes to AI coding. One is that needs to be zero trust. What do we mean by that? Zero trust in this context basically means that the code could really have come from anywhere. It could still be written by a human, it could be written by an AI as I just showed you a few slides ago. 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 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. 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?

……那样可被证明。软件会以各种离奇又新鲜的方式出问题。而当你用 AI 写越来越多的软件、去解决越来越大的问题，你撞上这些局限的频率只会越来越高。所以，把自动化验证做成整个流程的一部分，是解法里很重要的一环。你放手让 AI 去写代码，等于交出了一部分对代码的控制权，而自动验证能帮你把这里面的风险控制住。所以我们相信，验证会是一个关键的使能条件、一个关键的解锁点，它决定了未来我们能靠 AI 驱动的软件开发做成多少了不起的事。那当我们说「验证」的时候，到底指的是什么？我们认为，在 AI 写代码这件事上，成功的自动化验证有两个核心要素。第一个，它必须是 zero trust（零信任）。这是什么意思？在这个语境下，zero trust 基本上意味着：这段代码可能来自任何地方。它可能仍然是人写的，也可能是 AI 写的——就像我刚才几页幻灯片里给你们看到的，不同的 AI 写代码的方式也各不相同。而且你不会想用同一个 AI 去校验它自己写的代码，因为你会希望用一组多样化的工具，才能把各种可能出现的问题都捞出来。所以不管代码是从哪儿来的，你都想要一套同样全面的验证机制，无论这段代码是怎么写出来的，把关的标准都一模一样。

[10:00]

Use a different methodology to review the code that was used to write the code. 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. It also needs to be multi-layered. 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? 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. You need to use computational review, you also need to use LLM driven review, and everything else in between, right? 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. We call it ACDC, or agentic agent-centric development cycle. And there's three phases in in the ACDC that we that we like to talk about. 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? 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. 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? Um before the verification step, there's a guidance step.

要用一套跟「写代码」不同的方法论去审查代码。它完全可审计、完全可解释，所以你能证明每一次验证都是用同样的方式跑的；它是算法化的、可重复的、一致的，不管在哪儿跑结果都一样。它还必须是多层的。你得有多种方式、多种技术、多种手段去审查生成出来的代码。因为光靠一两种方法，你不可能把软件里所有可能出的问题都揪出来。你需要 computational review（计算式审查），也需要 LLM 驱动的审查，以及介于两者之间的各种手段。你们这几天也听了不少 agentic loop 的内容——我这一周听到太多 agentic loop 了——Tarik 昨天讲了我们做 agentic loop 的框架，我们管它叫 ACDC，也就是 agent-centric development cycle（以 agent 为中心的开发循环）。ACDC 里有三个阶段是我们特别想讲的。最容易的那个——我说的「容易」是指现在最快能落地的那个，也是在座很多人可能已经在往那条路上走的——就是 verification（验证）这一步，也就是图上正中偏上的那块。这是最关键的一环，它让你在这些 agentic loop 里写出来的代码真的能顺利上线。它必须是多层的、必须基于推理，而且要横跨质量问题、安全问题和合规问题，确保你交付的质量是你敢背书的。而在 verification 之前，还有一步叫 guidance（引导）。

[11:25]

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 uh uh uh the first time, right? And then finally, after verification, you need to solve the issues that come up, right? And that's where the solve state come. That's where you can remediate any issues that are found in the code. 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. And so these these agentic loops with verification at the core is how you can get to shipping quality software using AI agents. And there are prior there's different reasons why you would want to do this. 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 processes are are very similar, right? They want to make sure that AI code is verified consistently. They don't want to have different methods of verification applying to different projects or different teams. They want to have a standard rulebook that applies everywhere, no matter what tool is being used. They all also want to make sure they're using their AI tools effectively, right? 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? 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. Finally, third, catching issues from a security standpoint as early as possible in development cycle. Shifting left on security issues has been very important for a number of years now, and now that

guide 这一步的作用，是提供护栏、上下文和约束，确保 agent 在动手之前就拿到它写出更好代码所需要的一切，争取第一次就写对。最后，验证完之后，你还得把冒出来的问题解决掉——这就是 solve（解决）阶段，在这一步修掉代码里发现的问题。理想情况下，你应该让 agent 自己有这个自主权：把它需要的工具开放给它，让它自己定位问题、自己修，然后重复这个循环。所以，以 verification 为核心的 agentic loop，就是你用 AI agent 交付高质量软件的方式。做这件事的动机有好几种。我们跟客户聊过很多——在这个话题上我们聊过大量客户——推动他们在所有 AI 编码流程里落地 verification 的驱动因素其实非常相似。第一，他们希望 AI 写的代码被一致地验证，不希望不同项目、不同团队各用一套验证方法，而是希望有一本统一的规则手册，不管用什么工具都适用。第二，他们也希望自己的 AI 工具被用得高效。这里很大一部分是 token 效率，或者说整体效率，但也包括确保这些工具是被用在它们被设计来做、而且我们知道它们擅长做的事情上。所以我们会花很多篇幅讲 token 效率，讲怎么让合适的模型用在合适的项目上，等等。第三，是从安全角度出发，尽可能早地在开发周期里发现问题。安全左移（shift left）这些年一直都很重要，而现在……

[12:58]

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 are announced and then immediately exploited uh by bad actors almost often the same day. And so you need to make sure that your code is as hardened as possible from those types of issues creeping into production. And finally, maintaining compliance. 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 and consistently across the board. Maintaining an audit trail that allows you to prove that is extremely important. We have a number of solutions that that help with that. SonarQube has been around for quite a while. There are probably quite a few of you that are already SonarQube users. It is a zero trust multi-layered verification platform that works across syntax issues, data flow issues, architectural issues, control flow issues. And it works across basically any language you would be using. 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. 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. And they do AI code review.

……AI 写的代码越来越多，提前抓住安全问题就变得极其关键——尤其是在今天这个 CVE 一公布、往往当天就被坏人利用的世界里。所以你得确保自己的代码尽可能加固，别让这类问题溜进生产环境。最后一点是维持合规。我相信在座不少人在受监管的行业工作，在那种场景下，你必须能证明验证是持续、一致地在全线跑的；而保留一份能证明这一点的审计轨迹（audit trail）就极其重要。我们有不少方案能帮上忙。SonarQube 已经做了挺久了，在座应该有不少人本来就是 SonarQube 用户。它是一个零信任的多层验证平台，覆盖语法问题、数据流问题、架构问题、控制流问题，而且基本上你会用到的任何语言它都支持。我们做了很多深度的挂载点，等下我会带大家过一遍，它们能让 agent 以第一方（first party）的身份直接调用 SonarQube 的验证能力，从而更高效地写出高质量代码。另外我们最近——我说的最近就是几周前——收购了一家叫 Gitar 的公司，就在 San Mateo 本地。他们做的是 AI code review。

[14:09]

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 approach, but you can also automatically block if those issues cause a quality issue that you would want to push forward. It can write fixes and it can approve those fixes and merge those PRs completely automatically if you wanted to. Now, we'd want to earn that trust. It doesn't happen that way by default usually. 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. 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. 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. 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 as it's writing code in real time so it can find and fix the issues that are being created. And then we also released the remediation agent.

而且不止 code review，他们其实是把整条 CI workflow 都搭起来并自动化了。所以你不只是能用我们的 LLM 方法把问题找出来，还能在这些问题构成质量隐患时自动拦截，不让它往下走。它可以写修复方案，可以批准这些修复，甚至如果你愿意的话，完全自动地把 PR 合掉。当然，这份信任得慢慢挣来，默认一般不会这么干。默认情况下它只会把问题找出来摆给你看，跟你对话，让这些问题被修掉。但随着你用得越来越多、信心越来越足，你可以逐步打开更多功能，直到用 Gitar 把整个 PR 审查流程完全自动化。另一条本周早些时候的大新闻——Tarik 昨天演讲里也提到了——是我们还发布了一项新的 agentic loop 能力，产品叫 Sonar Vortex。关于 Sonar Vortex，我等下会再放一张流程图讲它到底干什么，但简单说：它是在内循环、也就是 agentic loop 里给你的 agent 提供工具，不只是在动手前给它约束和护栏、让它写出更好的代码，还能在它写代码的过程中实时跑验证，让它当场发现并修掉正在产生的问题。同时我们还发布了 remediation agent（修复 agent）。

[15:21]

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? 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 while you focus on the on the innovation work at the front end that you're working on now. And those are both GA as of this week. 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. 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. 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. This is This is your architectural constraints. This is the way your desired architecture for the software. This is your coding standards and your coding patterns that are acceptable. These are the list of dependencies that you are and are not allowed to use. These are your coding standards and and syntax standards that you obey in your organization. This could be your your logging practices or your observability and tracing practices. All of that goes into your specs and then you also need to define what your quality criteria are, right? 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 in your code that you're pushing into production. You need to basically write that down and encode it. And now you're

remediation agent 让你能去啃积压的问题、去还技术债，而那个规模可能是你现在靠人类开发者的人力根本吃不下的。你基本上可以把技术债、陈年老问题、遗留代码丢给 remediation agent，它就能在后台默默改进你的代码库，而你专心做手头那些创新的活儿。这两个产品本周都已经 GA 了。昨天 keynote 上放过一张非常细的图，我现在给大家拆开讲讲，说清楚图里各个部分到底是什么意思。这大概就是我们理解的 ACDC 的适用范围——不只是内层的 agentic loop，也包括我们做开发时都在跑的外层 CI/CD 循环。不过在你开始这两个循环之前，非常重要的一件事是：先搞清楚你到底想让这套软件完成什么，也就是规格（specification）。这包括你的架构约束，你想要的软件架构长什么样；包括你能接受的编码规范和编码模式；包括哪些依赖可以用、哪些不许用；包括你们组织遵守的编码规范和语法规范；也可能包括你们的日志实践、可观测性和链路追踪实践。所有这些都进到你的 specs 里。然后你还得定义质量标准。我们出厂就自带一套质量标准，你可以直接用默认值，也可以按你们组织的情况调整。它其实就是在回答：你推到生产环境的代码，在安全性、质量、可维护性上你愿意接受什么水位。你得把它写下来、编码固化。到这一步，你才……

[16:59]

ready to start using LLM coding agents to write code. 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 from the ground floor with an understanding of the code base and the guardrails that is relevant to it in that moment. You have to manage the context window of the agent you can't just throw your entire code base at the agent up front. It's going to spend a lot of time thrashing and exploring and burning tokens while it's doing it. 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. It then generates the source code as you can see and we also provide in loop verification to the agent as it's writing. 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 into future agentic loops that are going to run in order to fully build out the software project that you're doing. This is being enabled by Sonar Vortex as of this week.

……算准备好开始用 LLM 编码 agent 写代码了。每当你给 agent 派一个编码任务时，我们能帮上忙的头一件事，就是提供上下文和约束，让 agent 从一开始就理解这个代码库、以及此刻跟它相关的护栏是什么。你必须管理 agent 的上下文窗口，不能一上来就把整个代码库全砸给它——那样它会花大量时间来回折腾、四处探索，还一路烧 token。我们能做到只根据它接到的活儿，高效地给它刚好需要的那部分上下文，让它很快就开始写有产出的代码。接着如你所见，它生成源代码；同时我们还在它写的过程中提供 in-loop verification（循环内验证）。它可以回调我们，实时拿到我们在它正在写的代码里发现的问题列表。这件事的妙处在于，这些问题能被 agent 当场修掉，不会继续传播到后面那些为了把整个软件项目搭完而要跑的 agentic loop 里去。这个能力从本周起由 Sonar Vortex 提供。

[18:03]

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? And so there's a PR flow that gets initiated that I'm sure we're all familiar with. 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 and an automated verification that actually returns issues across quality, security and maintainability. 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. 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 and build and deploy in the application. The verification needs to run in both the inner agentic loop and also in the outer loop for CICD. I'm running low on time so I'm going to hope this video completes. This is basically a video demo of the inner loop, the agentic loop. It's a it's a demo of Sonar Vortex, basically. 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. 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 how to um how to write the code. 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. And then if it and if issues get provided, it will actually fix those issues immediately in

等所有内循环跑完，到了后面某个节点，你就得进入正式的代码评审和发布流程了，也就是 CI/CD 流程。于是会发起一个 PR 流程，这个大家肯定都很熟。Gitar 可以活在这条流程里，SonarQube 也在这条流程里，对 PR 里的全部代码跑一遍广泛的自动化审查，以及一次自动化验证，把质量、安全、可维护性三方面的问题都返回给你。这里有一个由 Gitar 的 LLM 驱动的「超人级审查」（superhuman review），还有一个由 SonarQube 跑的计算式审查，后者会给这三项分别打分，除非各项都达标，否则不让这个 PR 往生产环境走。所以如果确实冒出了问题，你可以用 fix agent 把发现的问题全修掉；等真正过了这道质量门禁，你才能继续走应用的测试、构建和部署。验证既要在内层的 agentic loop 里跑，也要在外层的 CI/CD 循环里跑。我时间不多了，希望这段视频能放完。这基本上就是内循环、也就是 agentic loop 的视频演示，其实就是 Sonar Vortex 的 demo。你刚才看到的是：我们给了它一个任务，而在启动这个任务时——现在跑的其实是 Cursor——Cursor 调用了我们 Sonar Vortex 的 context 工具，先拿到一些上下文，好让它理解手上这份代码、知道该怎么写。现在它在写代码；等初版写完，它会调用我们的验证流程，拿到它发现的问题列表。如果真返回了问题，它就会在……

[19:45]

the inner loop. This is all happening automatically through an integration that we have directly with Cursor. 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. And you can sort of get the gist. It It flagged an issue. It's got a plan. 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. I'm going to move past this cuz I'm out of time now. 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 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. 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. 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. Um but, you know, the good news is I think many of you probably have access to this stuff already. Uh Sonar Cube is one of the most widely adopted verification tools in existence today. 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. 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. So, uh final slide, key takeaways, right?

……内循环里立刻把这些问题修掉。这一切都是通过我们和 Cursor 的直接集成自动完成的。我们跟 Claude Code、Codex、Antigravity，以及基本上你会用到的任何主流 AI 编码工具，都有类似的集成。你大概能看出意思了：它标出了一个问题，给出了一个计划，马上去修，然后再跑一遍分析；在它真正从我们这边拿到验证通过的评级之前，它不会往下走。时间到了，这段我就跳过。所以，如果这场演讲你只带走一件事，那就是：我们非常坚定地相信——这一点我们的信念很强——一套治理与验证的机制极其关键，它才能解锁我们下一个层级的成功，让我们靠 AI 编码工具去解决越来越大的问题。而根据我们自己的数据，Sonar 的客户和用户确实能从 AI 编码工具里拿到更高的成功率。时间不够，这些我就不一条条讲了，大家可以到楼下我们那个大红色展台来，我们很乐意聊其中任何一条。不过好消息是，我想在座很多人可能本来就已经能用上这些东西了。SonarQube 是当今世界上采用最广泛的验证工具之一，全球有超过 700 万开发者在用我们，我们各条产品线每天分析近 7500 亿行代码。如果在座有人比较在意 Gartner 的话，也可以知道我们同样是 Gartner 魔力象限（Magic Quadrant）的领导者。好，最后一页，关键要点。

[21:15]

What are the things that we want to walk away from this? First, you know, establish some bounded autonomy guidelines for your AI agents. Give them the freedom to generate code, but also make sure that you're enforcing a centralized scheme of verification and constraints. Implement the ACDC, right? Give them context. Verify that they're doing the right work with independent metrics, and then use agents to solve their own mistakes. Empower them to do that. 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. 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. Um that's all for me. Uh you can learn more by Oh, it's off the screen now. But uh you can come down to our big red booth downstairs, and we'd be happy to talk to you. Thank you very much.

我们希望大家从这场演讲里带走什么？第一，给你的 AI agent 立一套「有边界的自主权」（bounded autonomy）准则。给它们生成代码的自由，但同时确保你在强制执行一套集中式的验证与约束方案。第二，把 ACDC 落地：给它们上下文，用独立的度量去验证它们做的活儿对不对，然后让 agent 去解决它们自己犯的错——把这个权限给它们。第三，确保你的开发者手里有他们需要的编排（orchestration）工具，好让他们能设计出那些让自己成功、把 AI 用到最有效的上下文框架和流程。最后，统一到一个独立的、多层的验证平台上，在所有项目、所有团队、所有开发者、所有 AI 编码工具上都一致地使用它，这样才能消除组织里因为工具各自为政、形成孤岛而产生的盲区。我就讲到这儿。想了解更多可以——哦，已经翻过去了。不过你们可以到楼下我们那个大红色展台来，我们很乐意跟你聊。非常感谢。

[22:28]

[music]

[音乐]