#224 Tariq Shaukat: How Safe Is AI-Assisted Coding?

0:00Maybe Gen AI can help with design and architecture work, but fundamentally, somebody has to sit there and think about how is the health insurance system going to work? What are the design and architecture rules that you're going to put in place? How are you going to construct this billion line code base? How are you going to maintain and migrate it? How, when you are going to move part of it into the cloud, how do you take pieces of it and do it intelligently, right? Like that, I don't want to say AI can never help with that because there's already AI tools that try to help with that. But these are real hard problems that I think require deep understanding and focus effort.

0:35AI might be the most important new computer technology ever. It's storming every industry and literally billions of dollars are being invested. So buckle up. The problem is that AI needs a lot of speed and processing power. So how do you compete without costs spiraling out of control? It's time to upgrade to the next generation of the cloud, Oracle Cloud Infrastructure, or OCI. OCI is a single platform for your infrastructure, database, application, development, and AI needs. OCI has four to eight times the bandwidth of other clouds, offers one consistent price instead of variable regional pricing, and of course nobody does data better than Oracle.

1:22So now you can train your AI models at twice the speed and less than half the cost of other clouds. If you want to do more and spend less, like Uber, 8x8, and Databricks Mosaic, Take a free test drive of OCI at oracle.com slash IonAI. That's E-Y-E-O-N-A-I, all run together. Oracle.com slash IonAI. That's oracle.com slash IonAI. Why don't you go ahead and introduce yourself and tell us how you got to Sonar? Sure. Well, I'm Tarek Shaka and I'm CEO here at Sonar. Pleasure to be on the podcast. So thank you for having me. I joined Sonar about a year and a quarter ago as co-CEO with our founder. And then more recently as CEOs, he stepped more into the founder role as opposed to the co-CEO role.

2:26So, you know, I prior to being here, I've got a long history inside of various parts of the tech world, both as a user of technology on the enterprise side, as well as as a as somebody working in the tech space. I was prior to here a president of Bumble and helped take it public the last couple of years. And prior to that, was president of the cloud group at Google for a number of years, helping to get that really off the ground and scaled to the substantial scale that it's at now. Great. And tell us what Sonar does. And the URL is Sonar Source, right? sonarsource.com. Exactly right. So Sonar is, we believe the leader in code quality and security.

3:23We started off really 15, almost 16 years ago now as an open source project, building a product called Sonar Cube that really inspects code as developers are writing that code. And it inspects it for really what we refer to as quality in general to make sure it's clean. So what that means is we look for bugs. We look for maintainability issues. We look for stylistic issues. We look for really anything that could be wrong with the code as you're writing it, including security issues as well. And we do this in 30 different programming languages. We do this globally and it's turned into not just the open source project, which is still available and a lot.

4:13We have 400 ,000 organizations who use our product. Over 7 million developers use our products. So we've got both that open source, but also commercial additions where we've got some of the largest enterprises in the world, all the way down to two person startups using our products to help improve the quality and security of the code they're writing. so that their software is better and more maintainable and has less tech debt. Is it a deterministic, rule-based system? There's still a good part of the product that is deterministic and rules-based. And we actually think that that is a real plus in a Gen AI world because one thing that Gen AI and all non-deterministic systems have is, by definition, You can't quite predict the outcome that you're going to get exactly.

5:05For things like quality control, it is helpful to be able to have repeatability and certainty as you are doing the verification and various analyses. So the history of the company has been in deterministic rules-based analysis of code. We have been supplementing that recently with a couple of different things. One is looking at how AI in general, Gen AI in particular, can be used in some of these gray areas. There's some types of problems that deterministic systems are really good at, and there's others that are a little bit more gray, where you need a little bit more judgment. You need to take into account more context.

5:43And we're starting to look at how can we use AI to really supplement what we've historically been doing. So that's certainly a key piece. And then the second is our historical business has been in finding issues in code, and then it's up to the developer to fix the issues. And what we are using is Gen.ai to help suggest fixes for the issues that we uncover. Yeah. And do you run alongside me? So many people are using Copilot or Code Whisperer. Yes. There's another one that I was introduced to yesterday. day. Yeah. Do you run alongside them? Because, yeah. Yeah. So, so SonarCube can run in the IDE.

6:34We have an IDE plugin for a number of the most popular IDEs, the development environments that are out there. And then we run either on-premise or in the cloud as you're starting to do your pull requests. And really the source of the code doesn't matter to us, right? What we look at is the code itself. And so we have, I would say the majority of our customers now, anyone who's using Copilot as an example, or Codium or Code Whisperer, you know, more likely than not, they're actually taking the output of Copilot and running it through SonarCube. We've actually recently launched a specific workflow for this that we call AI code assurance, right?

7:13That is meant to, we don't see ourself as a code generator. This is not the business that we're in. We're happy to work with Google and Microsoft and Amazon and Codium and Codium and all of these other players that are out there. What we really see ourself in is providing the workflow and the assurance that the code that you get out is high quality code, that it's not going to cause you maintainability issues down the line, that it's not riddled with bugs, and that it's not riddled with security issues. And so we really work in tandem with any of the code generators that are out there. Yeah, that's interesting.

7:51So if someone's using SonarCube alongside Codium, for example, which now has its own IDE, you would copy the code from the IDE, put it into Sonar, and Sonar would check it and make fixes and then you would copy it back into the IDE or how does that work? Yeah, it's a much more integrated workflow than that. We fundamentally view ourselves as being a developer assist tool, right? For lack of a better way of saying it. So meaning we want to work really with developers to improve their workflow, improve their productivity, you know, cut down on a lot of the nuisance that they have a lot of the non-value added work that they do.

8:46And so, you know, everyone I've seen is using some level of code review for the code that is being generated by any of the code generators, including Codium. You know, what we see is the industry sort of norm at the moment is only 30 % of suggestions coming from a co-pilot, as an example, are actually put into or actually accepted by the developer, right? And so it's clear, I think most people recognize that there are issues in the code that comes out, just like there would be with a human, right? And there are different types of issues. In some cases, you don't have as many stylistic issues with, you know, Gen AI is pretty good at the spell check types of things, you know, you don't normally put a semicolon where you should have put a colon and that sort of thing.

9:32But you do have some more complex issues that sometimes it makes up variable names. Sometimes it doesn't operate in the context of your code base correctly, things like that. And so that's where we really, as you say, we sort of take the output and run it through our analyses. We do that in the IDE and then a more complex analysis as you're issuing the pull requests themselves. but it's not quite as manual as a copy-paste, copy-paste. We've actually done a lot of work with the GitHubs and GitLabs and others of the world to really integrate into the workflows that they have and be kind of seamless for the developer or as seamless as you can be for the developer.

10:10So you can run SonarCube and Copilot in the same IDE. They don't conflict? Correct. They're just different plugins inside of the same IDE. That's right. And then as you're writing code or accepting suggestions from CodePilot or Codium or any of these, the SonarCube scans that code immediately or do you have to activate it? It depends on the type of analysis that you're running, right? Inside of the IDE, we have essentially an IDE extension for SonarCube that will do, for all intents and purposes, continuous inspection of the code. Now, there are some types of analyses that require just more computation, more time, the more sophisticated analyses of the code.

11:08So that doesn't happen right as you're writing the code, but a lot of the analyses do. And our philosophy is as much as possible, not even, excuse me, there's this expression that's used of shifting left. We actually try and talk about how we start left. We want to start as early as possible with the developer and catch issues while they're being created. So there is a lot of the analysis that is being run fairly continuously in the background. We do a lot of work to make sure it doesn't slow down. The workflow that it's not distracting to the developer, I try and optimize the number of true positives and minimize the number of false positives, things like that in the IDE.

11:48But then really where the sort of next level of analysis happens is when you're issuing the pull request, the merge request, right? And you want to actually put the code into your main code base. And that's where a lot of people would do code reviews. And we essentially do the automated version of that. So we identify all the issues that we think the code has. We'll tell you how severe we think the issues are. If you click into the issue, we'll try and explain the issue to you as much as possible, like why we think this is an issue. And so there's an education component to it also. And then with our AI code fix, for certain issues where we have a high confidence, we will suggest, oh, and if you accepted this piece of code to replace that piece of code, that would fix the issue.

12:35But it really happens. We try and have it happen as early as possible in the development process in the IDE and at that pull request phase. Yeah. And then when you accept a piece of code or a fix, does then it trigger a new analysis to ensure that that hasn't introduced a bug or something? Yeah, at the moment, we're doing a lot of pre-training, if you will, of the model so that we are... The acceptance rates we're seeing are about double the acceptance rates of your standard code generator, because we have a lot more context than a typical effort to create new code has, right? We know what the issue is.

13:21We know what was causing it. We can kind of use that to create the prompt and put it into the LLMs in a specific way. So it's not pre-training exactly, but it really is a higher fidelity way of generating the response. And you can absolutely have the option of running the analysis again. What we find is that most people at that point then subject to the human code review as well, Because all good code reviews have an automated component and a kind of expertise component to it. And rather than getting stuck in this do loop that goes over and over and over again, we find that developers just want to see the fix.

14:00They look at it. They agree to accept it or not. And then they go on with their process. So you can, but it's not the typical way. You know, I'm not a coder, but I've tried coding simple applications with, and from my experience, you end up in this endless rabbit hole where, you know, the code doesn't work. and then the Gen AI says, ah, I see the issue, and then it fixes the issue, and then it doesn't work, and it's, well, let me try a different approach, and it just goes on and on and on. And certainly with a coder, with a copilot or a codium, they would have the skills and the context to not accept code when they see that it's going to be problematic but has gen ai there's so much written about how much code is now being generated by code assistants but not as much as written about how much bad code is being written by code assistants and whether that counteracts some of the productivity gains of having a coding assistant.

15:34I mean, how do you guys view that? Yeah, I think there's actually, there's a couple of different aspects to this. One of them is, you're absolutely right. Right. Gen AI code has bugs. It has stylistic issues. It's got maintainability issues. It has security issues that are getting introduced. And in many cases, it's actually introducing new vectors on which you can have a problem, right? There are new ways of potentially causing security issues inside of your code base using Gen AI that really didn't exist as much. I mean, they kind of exist, but they didn't exist as much in the more traditional world.

16:19So you do have Gen AI code is not perfect. And it's not for English language search things either. This weekend, I was trying to write something for a board and I said, oh, chat GPT, give me a bunch of sources. And it turned out it made up three of the sources. Right. And thank goodness I double checked the URLs that it gave me. Right. So, you know, and it's a good lesson learned that, you know, the way the math works on the Gen.AI systems is it is going to have hallucinations. They're a feature, not a bug. Right. In many cases. And that does have real world implications on your code base. Right.

16:58and on your security and on the reliability of the software that you're shipping. But I'd say that's a known problem. It may be not a fully appreciated problem, but it's a known problem. You can look at the research. There's a lot of research that's been published recently that talks about this issue. The part that we think is as big a problem and maybe a bigger problem is that while people kind of, if you push them on it, they understand that there's issues. there is this accountability crisis. And I really think crisis is starting to be the real word here of who's actually responsible for the AI-generated code, right?

17:36And it's very easy to say, oh, the developer that's using the code generator is, but it's almost human nature. You don't hire a software developer. They didn't go to school. They didn't learn how to write code to become a copy editor for AI, right? And what one of my customers, large financial institution, told us a story a couple of months ago now. They were starting to have a minor outage a week because of AI, code generated. And it's not because the systems are flawed. The systems are actually quite good. They're just not perfect, right? And they have this one example of they figured out there was this line of code that was buggy.

18:16They traced it back to the developer who checked it and they went to the developer and said, hey, so what happened here? Let's do the postmortem. And the response was, well, that's not my code. What do you mean you checked it in? Well, yeah, but the AI gave me the code and I just accepted it. Right. And I'm not at all saying that developers are being lazy, not doing their job, etc. It's that we're asking them to do a job that really is not what they signed up for, what they're trained to do. And humans, unless this is your skill set, you're not trained to sit there and look at hundreds of lines of code that are being written by AI and double checking it.

18:50Right. And so this is why we think having some automated checks, tools like SonarCube, this AI assurance workflow we've put in place is so important because you have this accountability crisis. And the solution to that is to make sure you've got really robust workflows and you're doing rigorous code reviews. And by the way, most developers who are listening would say, duh, of course, this is what you should do. This is like best practice in software development in general. And that's true, but I think there's been this misperception in a way of this will be easy in the AI world. And I actually am finding that it is substantially harder for the reasons that I said just a minute ago.

19:31Yeah. And in that case, that code would have gone through a code review after that developer submitted it, right? So it was also missed by the code review. Yeah, and code reviews will miss things as well, because we're only human. And I guess at this point, we're also only Gen AI, right? And there's going to be bugs in the system, if you will. I think part of the question is, we find that organizations that employ rigorous quality gates, which is something our product offers, which means that you just can't go forward until you resolve these issues, have substantially better reliability. and security and developer productivity actually than people who don't.

20:19And, you know, because there's a lot of judgment and it comes into code reviews. Not only is this an issue, but is it an issue that needs to stop production, right? I mean, this is the key thing that you're always, there's always a trade-off. There's always a time pressure. Part of the reason we want to shift left or start left as much as possible is because when you're at the point where the product's supposed to ship, you know, in two hours and you just find the bug, now you're the person holding this up, right? This is not a position anyone wants to be in. And you cut corners knowingly or not knowingly.

20:50I don't think anyone would describe it as cutting corners, but you do because that's just life, right? That is the way that that's the way time pressures and things like that operate. So the earlier you can detect these issues, the more likely you are to fix them and the cheaper it is to fix them as well. Yeah. And that anecdote also points to something else that I've been talking to people about, which is automation bias, that if a coder is using a coding assistant and it's generating good code for, you know, 50 times, and you just get lazy and just start accepting it without worrying about it.

21:39And that's when bad code slips through. So you're adding a Gen.ai component, but it sounds like what you really want in this kind of a product is a deterministic system. You don't want to introduce another layer of probability. Well, I think there are certain types of problems where the deterministic model works really well. And if it ain't broke, don't fix it. Right. And there's other areas where it doesn't work that well. And these are problems that have not been addressable in the past. And so I think those are areas where new techniques are really good. And so our approach is very pragmatic, almost transactional.

22:29transactional. If this problem can be solved deterministically, we like the predictability of it. We like the cost of it. We like the efficiency of it. There's a lot to like about that. If the quality can be improved or if it can't be solved with deterministic models, then how do we supplement those models with other approaches? And it could be Gen AI. It could be other more probabilistic analyses, analytical approaches as well. I think fundamentally, I believe that a lot of these systems are going to end up being a hybrid of deterministic and non-deterministic approaches that are brought together, you know, where the use determines which, where the problem itself determines what type of solution is being used.

23:16Yeah. And actually, why not then build out a coding assistant on top of SonarCube? Or why wouldn't Copilot or Codium integrate something like SonarCube into their system so that they're not two different systems? It's all one thing. Yeah, I mean, so to tackle the second part first, and I'll talk about the first part, you know, we view GitHub and GitLab and Bitbucket and all of these different players as really good partners, we do a lot to integrate with them, right? There are certain things that we're really good at. And we've got over a decade of experience with, we've got deep IP and we understand the nuances of this sort of code analysis, particularly for quality and security, we think as well or better than anybody out there, right?

24:20And so to us, the question is, absolutely, if we can integrate this so it is completely seamless for a Codium user or for a co-pilot user or a Gemini user, whatever it is, that we would love to do that. And that is what we are doing. So that is very much kind of part of the strategy. We think that there's some pieces of IP and context that we have that's pretty unique that helps you, as I mentioned, solve some of these problems earlier. So you can throw brute force analytics at certain problems, right? But in some cases, just really understanding exactly what's causing the issue and having that sort of full set of know-how helps you get to the answer faster than just the brute force piece.

25:08And so that's why we find that our code fix suggestions have a 2x higher acceptance rate than your sort of generic code generated fixes. It's because we can supply it with that much more details of the analytics of your code base and things like that. And by the way, the same thing holds true on the first part. There is very little inside of Sonar that makes us likely to be the best at generating code from scratch. We're not good at foundation models. Right. And none of these players are building their own foundation models to my understanding. Maybe Microsoft is right, but we're not good at foundation models.

25:54We don't have proprietary data sets, you know, for code model training. Most of them are trained on the same code bases of open source and competitive coding, you know, competitions and things like that. So it really comes down to it's, I think, a different problem than what we're trying to solve. What we believe we're really good at is taking a billion lines of code, which is the size of a lot of the code base of a lot of our customers, and really decomposing it, deconstructing it, a better word, right? And figuring out how do we make sense of it so we can find these problems. And that's a different, we think equally valuable, but different problem than creating code from scratch.

26:37Yeah. And so you not only have kind of a live code review as a coder is, a programmer is writing code, you can apply this to an entire code base retroactively. Is that right? Yeah, this is not just for your new code that's being written. Most of our customers apply this. They kind of manage their code using SonarQ. And we've got some customers who do this on 2 billion lines of code. And then there's others who do it on 10 million lines of code or 100 ,000 lines of code. So it really depends on the size of your code base. But as you think about the challenge that code generation has, you know, fitting into the code base of a large health insurer, something like that, you need to not only understand how does Java work, right?

27:37And how do you solve this one line problem that you're trying to solve? You have to figure out, okay, what's the structure of the code? What's the architecture been? What's the syntax you use? What's the style that you use? things like this, right, that are kind of unique to every customer. And so that's one of the challenges that I think a lot of the code generation companies are trying to get at as they launch fine tuning and things like that. So you can fine tune on your code base and make it that much more tailored for you. We think that's super important because otherwise you're going to end up with a hobbyist tool or an autocomplete, right?

28:13Like, you know, you'll end up with autocomplete or a hobbyist tool, tailoring to your specific code base is really important. And then analyzing the code that's generated in the context of your specific code base is really important, right? So in part, to analyze the new code well, we have to understand all of your code base, right? Because that's what determines if it's a good fit. It's not just a circle, but it's the right size circle to fit into your code base, right? And you can use it to reduce your tech debt that you've got because it'll show you here's all the issues that you have and you can slowly work your way through those issues as well yeah how long does it take to review a billion lines of code this is something i've never really understood and um maybe uh for for you guys it seems obvious but do you do you give uh well anyway tell me how you do it i mean it's um without getting into all of the sort of math behind it you know you've got your your repos that hold your code right you've got your different branches and sub branches and all of that and essentially to make it fast if you just tried brute force to get your way through a billion lines of code, it's going to take you a long time.

29:30And so part of what we do, part of what others in the space do is think about how do you deconstruct the code into pieces that are analyzable, and then how do you add it all back up together, for lack of a better way of saying it. And that makes the analytical problem much more tractable. In most cases, it's not, by the way, one, the right way to say it, it's not one piece of software that has a billion lines of code. It's in, you know, thousands of different software programs in, you know, you have your, you have your online banking system, then you have your core banking system, then you've got your risk management system or whatever.

30:12So there's kind of natural structure to the code base that we use and, and you analyze it, you know, both in parallel and, and sequentially in different ways. One of our offerings is what we call a data center edition. And part of the value of the data center edition is high availability because you have multiple instances of Sonar Cube working in tandem, but it's also high performance because you can actually break down your code base into, you can essentially apply more and more instances, right? So analyze more in parallel, which makes things faster and higher performance. Yeah. And so in that review, when it lists all these various issues, does SonarCube offer, as you were saying with the kind of live coding, does it offer fixes for every issue or is it just flagging them?

31:19So it is certainly flagging them and it will provide you with metadata around them in most cases, right? So the simplest example is, do we think it's high, medium or low severity, right? So what's a criticality? We launched this thing we call the Clean Code Taxonomy. Gosh, nine months ago, maybe 10 months ago, which is really a taxonomy for describing code problems, right? So is this a responsibility problem, right? And what does responsible coding mean? It would be things like, do we think it's inefficient from a power consumption standpoint, things like that, or is it a maintainability issue?