AI Engineer Europe 2026
Can LLMs generate Enterprise Quality Code? — Prasenjit Sarkar, Sonar
Read the talk
Can LLM-generated code meet enterprise engineering standards?
Passing tests is only the beginning: evaluating generated code also requires measuring security, maintenance cost and complexity, then feeding those findings back into the agent’s development loop.
From a talk by Prasenjit Sarkar
Before you start: Familiarity with coding agents, pull requests and continuous integration will help; the article explains the code-quality measures as they appear.
Who checks the code after the agent writes it?
You give a coding agent instructions in English, let it generate an implementation, and then review the result. What would make that code trustworthy enough to maintain in an enterprise codebase? Prasenjit Sarkar opens with this shift in responsibility, invoking Andrej Karpathy’s description of English becoming a programming language: the human increasingly specifies the work and evaluates what the agent produces.
The tooling progression runs from VS Code and JetBrains to Cursor, Windsurf and Antigravity, and then to agents such as Codex, Claude, Devin and Gemini CLI. Sarkar cites The Pragmatic Engineer’s AI tooling survey, published in March 2026: 55% of its reader-survey respondents reported regularly using AI agents. That is a measure of the survey’s respondents, not all developers. As agents take on more implementation work, the review questions remain concrete: is the output maintainable, secure and readable?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Functional correctness leaves engineering questions open
Model vendors emphasize pass rates on HumanEval, MBPP and SWE-bench. These evaluations provide evidence about satisfying tested requirements, but passing tests does not establish enterprise readiness. Security, real-world reliability, architectural fit, engineering discipline, maintainability and accumulated technical debt require additional scrutiny. A solution can meet its immediate functional requirements while leaving expensive work for the people who must operate and change it.
Sarkar describes Sonar’s evaluation as covering more than 4,444 distinct Java programming assignments from an open-source dataset, with generated solutions analyzed using SonarQube Enterprise. The additional analysis examines defects and engineering quality rather than stopping at test success. The distinction between the dataset and the evaluation system matters: the results were made public; Sarkar corrects his initial description of the analysis as open source.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A high pass rate can accompany substantial defects
In the five-model comparison, Sarkar reports an 84.17% pass rate for Gemini 3.1 Pro High, attributing it to SWE-bench. The recording does not establish how that score relates to Sonar’s Java assignment evaluation, so it should not be read as the pass rate on the Java corpus. For that corpus, he reports 307,000 generated lines, a cyclomatic-complexity value of 234, 614 bugs per million lines and 210 security issues per million lines. The complexity value has no stated aggregation or normalization, limiting its usefulness in isolation.
Sarkar then identifies Claude Sonnet 4.6 as having the highest security-issue density in the displayed comparison, correcting an initial reference to Gemini. He reports 300 security issues per million lines and 627,000 generated lines for the same assignments. He associates GPT-5.4 and GPT-5.4 Pro High with about 1.2 million generated lines, without clearly separating the two variants’ totals.
| Model or configurations | Reported generated lines |
|---|---|
| Gemini 3.1 Pro High | 307,000 |
| Claude Sonnet 4.6 | 627,000 |
| GPT-5.4 / GPT-5.4 Pro High | About 1.2 million; allocation unspecified |
These are Sarkar’s reported volumes for the same roughly 4,444 Java assignments. The comparison exposes another dimension of model selection: a model can generate much more code to address the same workload. More output gives reviewers and maintainers more material to inspect; it is not, by itself, evidence of a better solution.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Where unreliable output can come from
Sarkar offers several explanations for the mixed results, beginning with the code used to train models:
- Mixed-quality examples: training data combines sound implementations with weaker code from open source and other sources.
- Insecure patterns: vulnerable examples can be learned alongside secure ones.
- Hidden logic errors: subtle mistakes in training code can contribute to generated implementations that fail or misbehave.
These are proposed explanations for the observed quality problems; the evaluation described here does not isolate their individual causal contributions.
The model adds another source of variation. Probabilistic generation can produce different implementations—and different amounts of code—from repeated prompts. Without sufficient project context, an agent also lacks the company’s data conventions, codebase structure and architectural constraints. Sarkar closes this diagnosis with explainability: when the system produces a poor implementation, understanding why it chose that implementation can be difficult, which complicates diagnosis and improvement.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the leaderboard across several dimensions
The Sonar LLM Leaderboard makes the evaluation results available for comparison. Sarkar reports coverage of more than 53 models and versions, including different thinking configurations such as Gemini 3 Pro High and Gemini 3 Pro. Those configurations matter: model selection concerns the particular version and operating mode being evaluated, not merely the model family.
In the snapshot he presents, Gemini 3.1 Pro High leads on the reported pass rate; Sarkar describes its entry as evaluated on February 19. Alongside pass rate, he examines issue density, generated lines, cyclomatic complexity and cognitive complexity. The leaderboard is updated as models arrive, and its individual model pages provide more detail for deciding which tradeoffs suit a particular architecture.
Sarkar describes all five displayed models as exceeding 80% functional correctness. Once several candidates perform well on tested functionality, the surrounding quality measures become especially useful: they help distinguish implementations that a single accuracy ranking would otherwise place close together.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure paths through code and the effort of understanding it
Cyclomatic complexity concerns control-flow paths: decisions and loops create alternative routes through a function. Sarkar explains it through if/else, for and while. Cognitive complexity, which he describes as a Sonar proprietary measure, asks a different question: how difficult is the code for a person to read, understand and maintain?
Consider a small Java example that totals positive values. The nested version makes the reader keep the enclosing conditions in mind; the guard-clause version handles exceptional paths first and leaves the main operation less deeply nested.
java
public final class PositiveTotals {
public static int nested(int[] values) {
int total = 0;
if (values != null) {
for (int value : values) {
if (value > 0) {
total += value;
}
}
}
return total;
}
public static int withGuards(int[] values) {
if (values == null) {
return 0;
}
int total = 0;
for (int value : values) {
if (value <= 0) {
continue;
}
total += value;
}
return total;
}
}
Both methods return 5 for new int[] {3, -2, 0, 2}. They retain similar decision structure, but arrange it differently for the reader. That distinction is why counting branches alone cannot describe every aspect of maintainability.
Sarkar reports roughly one million generated lines for GPT-5.2 High, versus fewer than 250,000 for the older model he calls GPT-4.0, across the roughly 4,400-plus Java assignments. The earlier Sonar report names GPT-4o, so the spoken label should not be treated as a distinct, firmly identified model. His broader observation is that newer models in this comparison produce more code and can also produce higher cyclomatic and cognitive complexity. The maintenance question is therefore not just how many lines an agent writes, but how much branching and reasoning those lines impose on the next developer.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Improvement changes the defects reviewers must find
Sarkar reports increasing total bugs per model, while describing the bugs and security issues in more mature models as subtler. He credits reinforcement learning with addressing previously observed problems, but says newer output can contain finer-grained mistakes that are harder for a human reviewer to detect.
At the same time, he reports decreasing total vulnerabilities per model. These observations concern different measures: total bugs and total vulnerabilities need not move together, and fewer vulnerabilities do not mean that the remaining ones are easy to find. In his account, the types of vulnerability are shifting as the models improve. Verification must therefore keep adapting instead of checking only for familiar mistakes.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Guide generation before verifying its output
What should a development process do when the generated code does not meet its engineering standards? Sarkar introduces Sonar’s agent-centric development cycle, or ACDC, through three intervention stages: guide, verify and solve. These stages operate across an inner loop around code generation and an outer loop around committed changes and review.
The guide stage addresses inputs before asking the model to produce better output:
- Sonar Sweep: Sarkar describes cleaning problematic training data at its source, so insecure or defective examples are not simply carried forward into generation. The product was in private beta.
- Sonar Context Augmentation: supplies relevant project context to the coding agent so its output can better fit the existing codebase. Sarkar describes this broadly as giving the LLM the entire codebase’s context; the product’s selective guidance should not be understood as literally inserting every file into every prompt.
Context Augmentation was already announced in open beta by the time of the talk, distinct from Sweep’s private-beta status. The underlying mechanism is to improve both the examples a model learns from and the project information available when it generates code.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Return analysis findings to the agent before committing
The verify stage brings SonarQube analysis into the agent’s working loop. Sarkar presents SonarQube Agentic Analysis as an open-beta capability available through MCP to compatible tools such as Claude, Codex and Gemini CLI. Here, analysis during the agent’s run means inspecting the generated code before it is committed—not waiting for the application to execute in production.
Sarkar claims 1–5 seconds for this pre-commit analysis, compared with 1–5 minutes for CI; he does not specify workload conditions. The workflow uses the earlier feedback to repair code while the agent is still working on it:
- Generate the implementation in the coding agent.
- Request analysis before committing or opening a pull request.
- Return the reported issues to the agent and have it repair them.
- Commit the changes and submit the pull request.
- Run the pull-request analysis as well.
Earlier feedback supplements the later gate. The pre-commit loop does not remove PR analysis; it gives the agent an opportunity to resolve findings before they reach that stage.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Propose repairs, check them, and return them for review
The solve stage handles issues that still reach the pull request. If SonarQube finds problems and the quality gate fails, Sarkar describes using the SonarQube Remediation Agent to request fixes for the issues in that PR. The agent was presented as being in open beta.
The same remediation approach extends to existing technical debt. In the SonarQube dashboard, a developer selects issues and assigns them to the agent. For this backlog workflow, Sarkar describes creating one pull request per selected issue. These are proposed changes: developers review them, approve those they accept, and merge them.
Before returning a fix, the remediation agent runs the proposed change through analysis and compilation again. Sarkar says it discards fixes that produce issues, framing this verification loop as protection against regressions. Analysis and compilation can reject detected problems, but they do not establish the absence of every behavioral regression; developer review remains part of the process. The mechanism is a checked proposal, followed by human acceptance—not an automatic merge based solely on the model’s confidence.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put the checks where development already happens
Sarkar closes with the integration reach of the guide, verify and solve portfolio. He claims support for more than 40 programming languages and frameworks, alongside broad DevOps integration, IDE partnerships and marketplace availability. These connections place guidance, analysis and remediation inside the tools through which code is generated, submitted and reviewed. Trust in generated code comes from that surrounding engineering process: relevant context before generation, explicit checks on the result, and reviewed repairs when those checks find problems.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explore model pass rates alongside code volume, complexity and static-analysis issue densities.
Results from 906 reader responses about AI tools and agent usage, collected in January and February 2026.
Further reading
Sonar’s October 2025 report explains its Java evaluation approach and examines reliability, security and maintainability across an earlier model set.
The original framework announcement describes Guide, Generate, Verify and Solve and introduces the supporting product portfolio.
Explains contextual guidance, analysis inside an agent’s generation loop, and reviewed remediation for new code and existing debt.
Updates since the talk
June 2026 announcement combining Context Augmentation and Agentic Analysis into Vortex and announcing general availability of Remediation Agent.
Read the complete timestamped transcript
- 0:00
[on-hold music]
- 0:15
All right. Okay, um, sorry guys, for the little hiccup. [chuckles]
- 0:20
Um, okay. So my name is Prasenjit Sarkar, and, uh, and today's session is all about is our, uh, um, all the all, all the, all the LLMs, are they generating the code which is enterprise-ready, right?
- 0:34
Um, so let's look at the first slide. In the first slide, we are talking about, um, [lip smacks] Adrian Karpaty, who, uh, two months back said that a lot of things has been changed in the software development area.
- 0:46
Earlier, we used to write code in, uh, IDE, uh, now things has been changed. Now it's all about agentic. So you are spinning up agents, you are just giving it instructions in English, and English is now the new programming language.
- 0:58
Everybody's talking about that. Um, and, uh, then you are letting it go. But, you know, humans are actually reviewing the code that is being generated by the agent.
- 1:09
So a lot of things has been changed. Earlier, we used to start, uh, in opening up by IDE, fancy IDEs, like starting from VS Code or JetBrains, um, to Cursor now, um, or Windsurf or, uh, you know, Antigravity.
- 1:23
And now we are moving towards the agentic coding platforms, which is Codex or Claude or Devin or, uh, Gemini CLI. And according to the Pragmatic Engineer Survey, which was done in March twenty twenty-six, we have seen that fifty-five percent of the developers are now using regularly some of the AI agents, right?
- 1:43
Um, but the question is, do you trust the code that is being generated by these LLMs, right? Um, is it maintainable? Is it secure? Is it readable? Um, um, and, and those are the questions that we are going to, uh, you know, debunk right now in these sessions.
- 2:00
So let's look at, um, why, uh, let's look at, you know, by evaluating those models and what they are generating out of the box. So there are two aspects that we are saying.
- 2:12
One aspect is all the LLM leaderbo-- all the LLM leaders, all the LLM companies, they are saying that, "Okay, my pass rate is eighty, eighty plus, plus percentage, eighty-four percentage, three percent, eighty-two percent."
- 2:24
Those are, uh, you know, eval coming from HumanEval, MBPP, uh, SWE-bench. Those, those are fine. Those are the functional correctness on the test cases, which is mostly, uh, known for.
- 2:36
But what we are missing is the security aspects, the real-world, uh, reliability aspect, the engineering architectural problems, um, the engineering discipline that you have. So, uh, code maintainability and the tech debt that is going to be generated by the LLMs itself, um, and then the context of our analysis.
- 2:55
So these are things which are missing. Now, what Sonar has done, we have created an evaluation framework. That eval framework run through four thousand four hundred and forty-four plus distinct Java programming assignments.
- 3:09
It's an open source datasets. We took up, we took up the assignments, and then we run through our models. Now, when you run through the models, we saw a, a huge amount of, uh, uh, you know, uh, data that is coming out of the analysis, and that is something that we have open source.
- 3:26
Not open source. I mean, we have actually, uh, you know, put it into open, uh, world. So we did the analysis using the SonarQube Enterprise, and we, uh, got that critical insights to choose the right LLM.
- 3:38
Now, let's look at the right LLMs or, or probably not. Uh, let's look at the LLMs that we have evaluated. So here I'm showing you just about the five LLMs.
- 3:48
And here you can see that Gemini 3.1 Pro High, uh, the pass rate is coming from the SWE-bench. So you can see the eighty-four point one seven percent, but it is verbose.
- 3:59
So those four thousand four hundred and forty-four Java assignments that I talked about, that, to solve that problem, we have seen that it is creating three hundred and seven thousand line of code, right?
- 4:09
Which is pretty concise. It's not that bad. Um, we have seen the complexity, cyclomatic complexity is two thirty-four. It's really, really buggy as well, which is, uh, you know, uh, six hundred and fourteen bugs that we found out per million line of code.
- 4:23
Um, and obviously, we have the security issues per million line of code, which is two hundred and ten. So you see that although these models are generating the code, although these models are pretty much pretty higher, high-end models, uh, from the foundation models, but you see that, uh, for example, I, uh, you know, Gemini 3 Pro is
- 4:44
creating the highest, uh, no, sorry. Um, the Claude Sonnet Four point six is creating the highest risk. It's three hundred security issues per million line of code that we have seen, right?
- 4:53
Um, it is also high bloat. So for those issue, for those number of assignments, we see six hundred and twenty-seven thousand line of code, which is being generated by, uh, you know, Claude Sonnet Four point six.
- 5:04
And you'll be stunned if you look at the, you know, GPT-5.4 and GPT-5.4 Pro High model, you'll see that one point two million line of code being gen-generated for those four thousand plus, uh, Java assignments.
- 5:18
That's a huge amount of line of code that is creating, right? That's a high bloat. Now, uh, why it is happening? Well, you know, we have seen the mixed quality code.
- 5:27
So the training sets that you see, uh, the training sets actually have the mixed quality of, uh, code coming from open source, coming from some other places, and that is actually creating the problem as well.
- 5:38
Uh, a little bit of problem. Then the, uh, built-in security flaws. So the datasets that you are using to train the model that has inbuilt security flaws, and that we have seen, uh, where the models is picking up those insecure code examples along with the good examples as well.
- 5:54
Then there are hidden bugs in the data. Um, so there are subtle logic errors that slips into the training pool, um, and that is actually causing your models to produce the code, um, which fails or, you know, uh, misbehave in a different way.
- 6:08
And of course, the LLMs themselves, right? So LLMs are probabilistic, right? So, um, obviously we know that the prompt that you are gen-- that giving to one model, uh, today, tomorrow when you give the same prompt to the same model, it is not gonna generate the same code.
- 6:24
It is gonna code diff-- It is gonna create a different amount of code, a different set of code, right? Um, it does have the limited context, which is obviously it doesn't understand the company's data or company's code base or company's architecture.
- 6:37
Um, and obviously it is not explainable, so it's very hard to diagnose, um, and improve when it is generating the code.
- 6:45
So we created this, uh, leaderboard called sonar.com/leaderboard. Here we have given all the data about all the different models that we have evaluated. So far, we have fifty-three plus models, um, and all the diff-- uh, I mean, different versions.
- 7:00
Uh, so you see Gemini 3 Pro High, Gemini 3 Pro, so different, uh, you know, combination of the thinking, uh, aspect as well. So we evaluated fifty-three plus models, and we open sourced all of the data to openly p- for the people to see that how the models are now behaving in a certain way.
- 7:20
So as of now, you see the Gemini 3.1 Pro High, that's, uh, was, that was evaluated February nineteenth, and that has the highest pass rate, which is eighty-four point one seven.
- 7:31
Um, not that bad of the issue density as well. Um, and the lines of code, cyclomatic complexity and re-- uh, cognitive complexity is also fine. It's not that bad.
- 7:39
Um, but yeah, this is the mo-- uh, this is the leaderboard that we have created where we are creating, we are evaluating all the different models that is coming up continuously, and then we are evaluating that, and we are uploading the data.
- 7:50
So you can see not only that, when you go to each and every model inside, there are lot more details that we have provided that what exactly are they doing, so that you can take a concise decision about whether you are going to take this model or the other models, uh, you know, according to your architecture.
- 8:05
Um, so you see this, the key insight, which is Gemini 3.1 Pro High is eighty-four point one seven correctness. That is the functional correctness I'm talking about. Um, and that's a, uh, you know, a accuracy leader, but you have then other models which are, you know, five models that we have given, which is crossing the eighty plus,
- 8:24
uh, percentage of, uh, accuracy. Um, and these are kind of, uh, leaders that we have. So we talked about, uh, two different complexity. One is cognitive complexity, one is cyclomatic complexity.
- 8:36
Um, so cyclomatic complexity is how many branches do you have? Like how many ifs and, uh, ifs and else, how many, uh, you know, how many for loop, how many ifs and, uh, other loops, how many while loop that you have.
- 8:48
And the cognitive complexity is a Sonar proprietary one, where, uh, we measure that how difficult a code is for a human being to read and understand and maintain that code, right?
- 8:58
So these are the two different complexity that we maintain. Um, and if you look at the models, uh, the, and the kind of data, you will see that the amount of verbosity that we have seen.
- 9:07
So the newer models that we are seeing coming up, uh, uh, you know, day by day, we are seeing the kind of lines of code is, you know, uh, going to the north.
- 9:17
If you see the GPT-5.2 High, it has created actually a million line of code for those four thousand four hundred, uh, plus Java assignments, right? Um, and if you see the earlier models like GPT-4.0, that's less than two fifty thousand line of code.
- 9:31
But the model which is going up north, north, the number of line of code is, uh, you know, being written is too high. Um, you have seen the models which are also going hi- higher up that also have the higher complexity and h-- uh, cy-- higher cyclomatic and cognitive complexity.
- 9:48
You also need to see that the number of total bugs per model, that is also going high. Um, but what we have seen is that the models which are, uh, getting matured enough day by day, they are getting, uh, kind of finer bugs, uh, finer security issues rather than the old issues.
- 10:07
So they're doing a good job in terms of the, you know, re-- running the reinforcement learning, and they're securing the problems that they have seen already. But then doing that, they're also creating some more finer bugs that is very, very hard for a human being to, uh, detect.
- 10:21
Um, we have seen the total vulnerabilities per model also is now decreasing. But then the amount, the kind of vulnerabilities that we have seen is, is going in a different, uh, different genre.
- 10:32
Okay. So yeah, we have seen that it's generating the kind of code, uh, that doesn't meet your c-- you know, en-- uh, engineering standards, but what can we do?
- 10:42
So in this slide, we talked about, uh, the agent-centric, uh, development cycle. Uh, we call it as ACDC. So Sonar has... [chuckles] That's a funny name, yeah. So, uh, it's called ACDC framework.
- 10:55
So in the ACDC framework, we have three stages. We have guide stage, we have verify stage, and we have solve phase. Um, so in this one we have a inner loop, and we have a outer loop.
- 11:05
So in the guide phase, we have introduced two different product. Um, uh, one is called, uh, Sonar Context Augmentation and Sonar Sweep, uh, pri-- which is in a private beta.
- 11:14
So Sonar Sweep is basically treating the data that you act-actually have and, and the data that you are actually using to train your model. So if you have the problematic data, that means that your model is going to create the problematic code.
- 11:28
If I treat the data right there itself, the code which is going to be generated is going to be good enough, right? Um, context augmentation is going to push the context, all the entire code base into the LLM itself.
- 11:41
Then we have the verify stage. Verify stage is SonarQube. We have various different ways of, uh, you know, utilizing that. We have introduced SonarQube agentic analysis, which is in beta right now, uh, open beta, anybody can participate in that, which is actually taking your code in the runtime.
- 11:56
What does it mean is that you're using a Claude or Codex or Gemini CLI or whatever, which have an MCP inbuilt, and then you can say that, "Hey, generate this code."
- 12:05
Now, before you commit that, before you push that into PR, you just need to analyze my code. So it is going to analyze this code way before the, your CI runs, right?
- 12:14
The CI runs takes about one to five minutes, and then this analysis is going to take about one to five seconds. Within one to five seconds, the code which is being generated right now, before you even commit, it'll analyze and it'll tell you that, "Oh, these are the problems that I found."
- 12:28
Fair enough. It'll be pushed down to the agent, and agent is going to fix that problem right there before you even commit that. And then you commit, then you push that code back to the PR, and the PR analysis is going to run.
- 12:39
Now, the solve part is where we have introduced the SonarQube remediation agent. So let's say that even doing after all of that, i-if there are issues that has been slipped through your verify stage and it has gone back to the PR stage, right?
- 12:53
So you have committed the code, you push a PR, and then you found out, the SonarQube, uh, found out there are issues that we found, uh, that, that, that's there, and your quality gate fails.
- 13:03
If that fails, then the remediation agent is right there. It's right now in its open beta, where you can just click and then say that, "Okay, I want to fix all of the issues that is there in the PR."
- 13:13
Not only that. Let's say that you have a tech debt, right? Huge amount of tech debt. So you go to the SonarQube dashboard and you see these, all those tech debts that you have.
- 13:21
You just click and select all of the issues that you want to select and fix, and then say that, "Assign it to agent." And we are going to create each and every PR per issue, and we are gonna fix that one, giving it back to the developers.
- 13:33
Developers are going to review that. If they find, if they're happy, they're going to, uh, uh, you know, approve it and then merge it. The beautiful thing that we have built for the, uh, remediation agent is that the remediation agent is going to create the fix, run it through the analysis again, run it through the compilation part
- 13:49
again, and see whether that is creating any issues or not. If there is an issues, it is going to discard it. We are not going to give you the code which is going to, uh, you know, create a regression.
- 13:58
We don't do that, right? So that's a kind of a verify loop that we run through. Um, so yeah, this is, this is the entire, uh, you know, li-...
- 14:06
Uh, I mean, I would say the, the product, uh...
- 14:10
This is our product portfolio where we are providing from guide and to verify and then solve. Uh, we have all these, you know, [REDACTED:age], uh, uh, programming, uh, language and framework.
- 14:20
All the DevOps are, uh, uh, you know, supported. IDs, uh, you know, we are partnering with this. Uh, we ha- we are in the marketplace as well. So yeah, that's,
- 14:30
that's how we are solving the, the issues that you are seeing, um, where the, the LLMs are generating the code, but we are not trusting that, right? Um, yeah, so if you want some more info, uh, we are in the expo booth.
- 14:43
Uh, come and, uh, visit us, and maybe we can show you one or two demo as well for the product that we have built. [audience applauding]
- 14:50
Right. Thank you. [upbeat music]