A talk by Prasenjit Sarkar (Sonar) examining whether LLMs can generate enterprise-quality code. Sonar ran 4,444 Java programming assignments through 53 models, measuring pass rate, cyclomatic and cognitive complexity, bug density, and security issues per million lines of code — including GPT-4o generating under 250,000 lines, "GPT 5.4" at 1.2 million, and Claude Sonnet 4.6 at 627,000 lines with the highest security issue rate (300 per million lines). The talk also presents Sonar's three-stage ACDC framework: guide (context augmentation via Sonar Sweep), verify (SonarQube agentic analysis in 1–5 seconds pre-commit vs 1–5 minutes in CI), and solve (a remediation agent producing one fix per issue, validated through analysis and compilation before presentation). Timestamps cover the evaluation methodology, LLM performance analysis, why LLMs struggle (training data and hidden flaws), the Sonar LLM leaderboard, and the full ACDC framework. # Video Identity Observations — "Can LLMs generate Enterprise Quality Code?" (Prasenjit Sarkar, Sonar) ## Explicit Self-Description Evidence - **Speaker affiliation**: The presenter identifies himself as *"my name is Prasanjit Sarkar"* and repeatedly speaks on behalf of **Sonar**, describing company products and initiatives ("what Sonar has done, we have created an evaluation framework"). - **Company product claims**: He presents a **product portfolio** spanning what Sonar calls the **"ACDC" (agent-centric development cycle) framework** — *"we have a guide stage, we have a verify stage and we have a solve phase."* - **Named products introduced**: - **Sonar context augmentation** and **Sonar sweep** (*"which is in a private beta"*) - **SonarQube agentic analysis** (*"in beta right now open beta, anybody can participate"*) - **SonarQube remediation agent** (*"it's right now on its open beta"*) - **Public resource claim**: *"we created this leader board called sonar.com/leaderboard"* with *"53 plus models"* evaluated, and the underlying data released: *"we open sourced all of the data."* ## Observable Presentation Patterns ### Claimed Scope - **Focus area**: Evaluating whether LLM-generated code is enterprise-ready, covering **security, maintainability, readability, and reliability** beyond functional correctness benchmarks (*"HumanEval, MBPP, SWE bench"*). - **Methodology scope**: An evaluation framework running **4,444+ distinct Java programming assignments** from an *"open source data sets"* through models, analyzed with *"SonarQube Enterprise."* - **Breadth claim**: Support for *"40 plus programming language and framework"* and *"all the devops"* and IDE integrations. ### Intended Audience - **Software developers and engineering leaders** deciding on LLM adoption — evidenced by framing such as *"so that you can take a concise decision about whether you are going to take this model or the other models according to your architecture."* - **Developers working with agentic coding tools** (Codex, Claude, Devin, Gemini CLI, Cursor) — the talk assumes familiarity with these platforms. - **Conference/expo attendees**: The talk closes with a direct recruitment pitch — *"we are in the expo booth. Come and visit us and maybe we can show you one or two demo."* ## Claims vs. Demonstrated Content | Creator claim | Evidence in material | |---|---| | Leaderboard exists with 53+ models at sonar.com/leaderboard | Stated repeatedly; not demonstrated beyond description | | Remediation agent prevents regressions | *"we are not going to give you the code which is going to create a regression"* — asserted, not shown | | Proprietary metric: **cognitive complexity** | Described as *"a Sonar proprietary one where we measure how difficult a code is for a human being to read"* | | Specific figures (e.g., Gemini 3.1 Pro High at 84.17% pass rate, 307k lines of code; Claude Sonnet 4.6 at 300 security issues/MLOC; GPT 5.4 generating 1.2M lines) | Quoted as results of Sonar's own analysis; presented via slides described verbally, not verifiable from transcript alone | ## Presentation Style Observed - **Technical, data-dense delivery** with heavy use of concrete statistics per model. - **Promotional underpinning**: The session functions partly as a product showcase, pivoting from analysis findings (*"LLMs are generating the code but we are not trusting that"*) directly into Sonar's guide/verify/solve product framing. - Cites third-party references: **Adnan Qureshi** (paraphrased on agentic coding shift) and a **"Pragmatic Engineer Survey… March 2026"** claiming *"55% of the developers are now regularly using some of the AI agents."* ## Notes on Trustworthiness Boundaries - All performance figures and beta-product capabilities are **self-reported by the vendor**; the transcript shows no independent verification. - No explicit channel-level mission statement appears; identity is inferred only from this video's content (a single conference talk by a Sonar representative). # Delivery Observations — Prasenjit Sarkar, "Can LLMs generate Enterprise Quality Code?" ## Tone & Register - **Conversational, demo-keynote style**: casual fillers and asides throughout — "All right. Okay. Sorry guys for the little hiccup" and "you know" appear very frequently, giving an informal, spoken-presentation register. - **Direct audience address**: repeatedly frames questions to the room — "do you trust the code that is being generated by these LLMs, right?" and "Is it maintainable? Is it secure? Is it readable?" - **Light humor / self-awareness**: joking about the framework name — "We call it as ACDC. So Sonar has That's a funny name, yeah." ## Vocabulary & Framing Habits - **Rhetorical "right?" tag**: used constantly as a confirmation device — "English is now the new programming language… right?", "That's a huge amount of line of code that is creating, right?" - **Metric-dense delivery**: leans heavily on numbers — "84.17%", "4,444 plus distinct Java programming assignments", "614 bugs… per million line of code", "53 plus models". - **Catchphrase-style framing**: "English is now the new programming language. Everybody's talking about that." - **Product-domain jargon**: SWE bench, HumanEval, MBPP, MCP, cyclomatic/cognitive complexity, tech debt — used without pause for definition except complexity, which he explicitly teaches. ## Teaching Habits & Structure - **Define-then-apply**: pauses to explain concepts before using them — "cyclomatic complexity is how many branches do you have? Like how many ifs and ifs and else…" and "the cognitive complexity is a Sonar proprietary one where we measure that how difficult a code is for a human being to read". - **Contrast structure**: sets up "what leaders claim" vs. "what's missing" — "Those are fine. Those are the functional correctness… But what we are missing is the security aspects…" - **Enumerated causes**: lists reasons in a clear sequence — "the training sets… the built-in security flaws… hidden bugs in the data… the LLMs themselves". - **Walkthrough narration**: describes product flows step by step in second person — "you can say that, hey, generate this code. Now before you commit that… you just need to analyze my code." - **Exaggeration for emphasis**: "you will be stunned if you look at… GPT 5.4… 1.2 million line of code being generated". ## Recurring Communication Patterns - **Self-corrections mid-sentence**, frequent and visible: "we have open source not open source. I mean, we have actually you know, put it into open world"; "Gemini 3 Pro is creating the highest sorry, the Claude Sonnet 4.6 is creating the highest risk". - **Filler chains and restarts**: "So it is going to code It is going to create a different amount of code"; "So yeah, this is this is the entire you know". - **Repeated intensifiers**: "really really buggy", "very very hard for a human being to detect". - **Trend narration with directional metaphor**: "the kind of lines of code is going to the north" (used twice). - **Close with call to action**: "we are in the expo booth. Come and visit us and maybe we can show you one or two demo". ## Stable Patterns vs. Isolated Moments - **Stable (repeated across the talk)**: "right?" confirmation tag; "you know" fillers; numeric evidence habit; audience-directed rhetorical questions; step-by-step process narration. - **Isolated**: the opening apology ("Sorry guys for the little hiccup") occurs once; the ACDC joke appears only once; an audience interruption "[snorts]" after the verbosity statistic is a single moment with no clear pattern. ## Uncertainty Notes - The transcript lacks audience audio beyond "[snorts]", "[applause]", "[music]", so claims about audience interaction or pacing/pauses cannot be verified. - Timestamps are sparse and bracketed only occasionally; delivery pacing (pauses, emphasis) is largely unobservable from this transcript. # Position Record: "Can LLMs generate Enterprise Quality Code?" — Prasenjit Sarkar (Sonar) ## Framing & Central Question - Sarkar opens by citing **Adnan Qureshi** (2 months prior), who said software development has shifted: developers previously wrote code in IDEs (VS Code, JetBrains, now Cursor, WindSurf, "anti-gravity"), but now it is **agentic** — giving instructions in English ("English is now the new programming language"), with humans still reviewing agent-generated code. - He cites the **Pragmatic Engineer Survey (March 2026)**: 55% of developers regularly use AI agents (per his recounting). - Core question posed: **Do you trust LLM-generated code? Is it maintainable, secure, readable?** ## Claim: Standard Benchmarks Miss Quality Dimensions - LLM leaderboard **pass rates** (80%+, e.g., 82–84%) come from HumanEval, MBPP, SWE-bench — these measure **functional correctness on test cases**. - Sarkar argues these omit: **security, real-world reliability, engineering architecture/discipline, maintainability, tech debt, and context analysis**. ## Sonar's Evaluation Framework - Sonar ran **4,444+ distinct Java programming assignments** (open-source dataset) through models, analyzed via **SonarQube Enterprise**; results published on **sonar.com/leaderboard**, covering **53+ models** (as of the talk). - Reported figures (as stated): - **Gemini 3.1 Pro High**: 84.17% pass rate (SWE-bench); ~307,000 lines of code for the assignment set; cyclomatic complexity 234; 614 bugs per million LOC; 210 security issues per million LOC. Described as "pretty concise... not that bad" though "really really buggy." - **Claude Sonnet 4.6**: described as creating the **highest security risk** — ~300 security issues per million LOC; also verbose (627,000 LOC). - **GPT 5.4 / 5.4 Pro High**: ~**1.2 million lines of code** for the same assignments — "high blow" (bloat). - Five models crossed 80%+ accuracy on the leaderboard. ## Claimed Explanations for Quality Problems - **Mixed-quality training sets** (open-source and other sources). - **Built-in security flaws** in training data — models pick up insecure examples alongside good ones. - **Hidden bugs / subtle logic errors** in training pools. - **LLM nature**: probabilistic (same prompt yields different code), limited context (no understanding of company codebase/architecture), and not explainable (hard to diagnose). ## Observed Trends Across Model Generations - **Verbosity is rising**: newer models generate far more lines (GPT 5.2 High ~1 million LOC vs. GPT 4.0 under 250,000 for the same tasks). - Higher-output models also show **higher cyclomatic and cognitive complexity** and more total bugs. - **Nuance preserved**: Sarkar notes vulnerabilities are **decreasing** overall in maturing models, and old bug classes are being fixed via reinforcement learning — but newer models produce "**finer bugs**" that are very hard for humans to detect, and vulnerabilities are shifting into different genres. ## Definitions Offered - **Cyclomatic complexity**: count of branches (ifs, loops, etc.). - **Cognitive complexity** (Sonar proprietary): how difficult code is for a human to read, understand, and maintain. ## Proposed Solution: ACDC Framework ("agent-centric development cycle") - **Guide** phase: - **Sonar Context Augmentation** — pushes the entire codebase context into the LLM. - **Sonar Sweep** (private beta) — "treats" training data so problematic data doesn't produce problematic code. - **Verify** phase: - **SonarQube agentic analysis** (open beta) — via MCP with coding agents (Claude/Codex/Gemini CLI), analyzes generated code **pre-commit in 1–5 seconds** (vs. 1–5 minutes for CI), feeding issues back to the agent to fix before commit. - **Solve** phase: - **SonarQube remediation agent** (open beta) — fixes PR issues on click; also bulk-fixes tech debt from the dashboard, creating one PR per issue for developer review. - **Guardrail claim**: the remediation agent re-runs analysis and compilation, and **discards fixes that introduce regressions** ("We don't do that"). ## Closing - Product portfolio spans guide/verify/solve across **40+ languages and frameworks**, with IDE partnerships and marketplace presence; invitation to demos at the expo booth. ## Caveats on the Record - All figures are Sarkar's own spoken claims from Sonar's internal evaluation; no independent verification is offered in the talk. - Note an internal tension: Gemini 3.1 Pro High is simultaneously called "really really buggy" (614 bugs/MLOC) and praised as "not that bad" on issue density and complexity — both statements preserved as expressed. - One transcript slip: Sarkar initially says "Gemini 3 Pro is creating the highest [risk]" then corrects himself to "Claude Sonnet 4.6"; the corrected attribution is recorded above. # Speaker Attribution & Provenance Record ## Video **Title:** Can LLMs generate Enterprise Quality Code? — Prasenjit Sarkar, Sonar ## Speakers ### Primary Speaker: Prasenjit Sarkar - **Role:** Creator / presenter (identified by self-introduction: "my name is Prasanjit Sarkar") - **Affiliation:** Sonar (per title; presents Sonar products throughout) - Delivers the entire session as a talk/presentation. ### Secondary Speakers - **Unnamed audience member(s):** - An audible **snort/reaction** after the verbosity discussion (no words). - Interjection: **"That's a funny name, yeah"** regarding the "ACDC" framework acronym. - **Audience applause and music** at the end. ## Promotional Segments ⚠️ The talk contains substantial product promotion for Sonar, explicitly flagged: - **SonarQube Enterprise** — used as the analysis tool. - **sonar.com/leaderboard** — Sonar's model evaluation leaderboard (53+ models evaluated). - **ACDC framework** (agent-centric development cycle) with: - **Sonar Context Augmentation** and **Sonar Sweep** (private beta) - **SonarQube Agentic Analysis** (open beta) - **SonarQube Remediation Agent** (open beta) - **Closing call-to-action:** invitation to visit the **Sonar expo booth** for demos. ## Referenced Sources & Third-Party Claims - **Adnan Qureshi** (quoted/paraphrased, ~2 months prior): claim that development shifted from IDEs to agentic workflows; "English is now the new programming language." - **Pragmatic Engineer Survey (March 2026):** claim that 55% of developers regularly use AI agents. - **Benchmark datasets cited:** HumanEval, MBPP, SWE-bench (functional correctness pass rates). - **Named third-party products/tools mentioned:** VS Code, JetBrains, Cursor, Windsurf, "anti-gravity," Codex, Claude, Devin, Gemini CLI. ## Presenter's Data Claims (provenance: Sonar's own evaluation) - Evaluation framework over **4,444+ Java assignments** (open source dataset), analyzed with **SonarQube Enterprise**. - Model-specific figures cited: Gemini 3.1 Pro High (84.17% pass rate, 307k LOC, 614 bugs/MLOC, 210 security issues/MLOC), Claude Sonnet 4.6 (~300 security issues/MLOC, 627k LOC), GPT 5.4 / 5.4 Pro High (1.2M LOC), GPT 5.2 High (~1M LOC), GPT 4.0 (<250k LOC). - Leaderboard data claimed to be open-sourced at sonar.com/leaderboard. ## Availability & Uncertainty - **No curated metadata was supplied** — no verified speaker list, no comment availability information. - Transcript contains transcription artifacts (e.g., "Sonar cube" vs. "SonarQube," "high blow" likely "bloat"); speaker identity spelled "Prasanjit" in audio vs. "Prasenjit" in title. - Audience participants remain **unidentified**. \>\> All right. Okay. Sorry guys for the little hiccup. Okay. So, my name is Prasanjit Sarkar and today's session is all about is our all the LLMs are they generating the code which is enterprise ready, right? So, let's look at the first slide. In the first slide we are talking about um Adnan Qureshi who 2 months back said that a lot of things has been changed in the software development area. Earlier we used to write code in IDE. Now things has been changed. Now it's all about agentic. So, you are spinning up agents. You are just giving instructions in English and English is now the new programming language. Everybody's talking about that. And then you are letting it go, but you know, humans are actually reviewing the code that is being generated by the agent. So, a lot of things has been changed. Earlier we used to start you know, opening up by IDE, fancy IDEs like starting from VS Code or JetBrains to Cursor now or Wind Surf or you know, anti-gravity. And now we are moving towards the agentic coding platforms which is Code X or Claude or Devin or Gemini CLI. And according to the Pragmatic Engineer Survey which was done in March 2026, we have seen that 55% of the developers are now using regularly some of the AI agents, right? But the question is do you trust the code that is being generated by these LLMs, right? Is it maintainable? Is it secure? Is it readable? And and those are the questions that we are going to you know, debunk right now in this session. So, let's look at why 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. One aspect is all the LLM leader board all the LLM leaders, all the LLM companies, they are saying that okay, my pass rate is 80 80 plus plus percentage. 84% 83% 82%. Those are you know, eval coming from human eval MBPP SWE bench. Those are those are fine. Those are the functional correctness on the test cases which is mostly known for. But what we are missing is the security aspects, the real world reliability aspect, the engineering architectural problems, the engineering discipline that you have. So, code maintainability and the tech debt that is going to be generated by the LLMs itself and then the context our analysis. So, these are things which are missing. Now, what Sonar has done, we have created an evaluation framework that eval framework run through 4,444 plus distinct Java programming assignments. It's an open source data sets. We took up We took up the assignments and then we run through models. Now, when you run through the models, we saw a huge amount of you know, data that is coming out of the analysis and that is something that we have open source not open source. I mean, we have actually you know, put it into open world. So, we did the analysis using the SonarQube Enterprise and we got that critical insights to choose the right LLM. Now, let's look at the right LLMs or probably not. Let's look at the LLMs that we have evaluated. So, here I'm showing you just about the five LLMs. And here you can see that Gemini 3.1 Pro High the pass rate is coming from the SWE bench. So, you can see that 84.17%. But it is verbose. So, those 4,444 Java assignments that I talked about, that to solve that problem, we have seen that it is creating 307,000 line of code, right? Which is pretty concise. It's not that bad. We have seen the complexity cyclomatic complexity is 234. It's really really buggy as well which is you know, 614 bugs that we found out per million line of code. And obviously we have the security issues per million line of code which is 210. So, you see that although these models are generating the code, although these models are pretty much pretty higher high in models from the foundation models, but you see that for an example, I you know, Gemini 3 Pro is creating the highest sorry, the Claude Sonnet 4.6 is creating the highest risk. 300 security issues per million line of code that we have seen, right? It is also high blow. So, for those issue for those number of assignments, we see 627,000 line of code which is being generated by you know, Claude Sonnet 4.6. And you will be stunned if you look at the you know, GPT 5.4 and GPT 5.4 Pro High model, you will see that 1.2 million line of code being generated for those 4,000 plus Java assignments. That's a huge amount of line of code that is creating, right? That's a high blow. \>\> \[snorts\] \>\> Now, why it is happening? Well, you know, we have seen the mixed quality code. So, the training sets that you see, the training sets actually have the mixed quality code coming from open source, coming from some other places and that is actually creating the problem as well. A little bit of problem. Then the built-in security flaws. So, the data sets that you are using to train the model that has inbuilt security flaws and that we have seen where the models is picking up those insecure code examples along with the good examples as well. Then there are hidden bugs in the data. So, there are subtle logic errors that slips into the training pool and that is actually causing your models to produce the code which fails or you know, misbehave in a different way. And of course the LLMs themselves, right? So, LLMs are probabilistic, right? So, obviously we know that the prompt that you are that giving to one model today, tomorrow when you give the same prompt to the same model, it is not going to generate the same code. It is going to code It is going to create a different amount of code, a different set of code, right? It does have the limited context which is obviously doesn't understand the company's data or company's code base or company's architecture. And obviously it is not explainable. So, it is very hard to diagnose and improve when it is generating the code. So, we created this leader board called sonar.com/leaderboard. Here we have given all the data about all the different models that we have evaluated. So far we have 53 plus models and all the I mean, different versions So, you see Gemini 3 Pro High, Gemini 3 Pro. So, different you know, combination of the thinking aspect as well. So, we evaluated 53 plus models and we open sourced all of the data to openly for the people to see that how the models are now behaving in a certain way. So, as of now you see that Gemini 3.1 Pro High that's was that was evaluated February 19th and that has a highest pass rate which is 84.17. Not that bad of the issued density as well and the lines of code cyclomatic complexity and cognitive complexity is also fine. It's not that bad. But yeah, this is the this is the leader board 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. 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 you know, according to your architecture. So, you see this the key inside which is Gemini 3.1 Pro High is 84.17 correctness. That is the functional correctness I'm talking about. And that's you know, accuracy leader, but you have then other models which are you know, five models that we have given which is crossing the 80 plus percentage of accuracy and these are kind of leaders that we have. So, we talked about two different complexity. One is cognitive complexity, one is cyclomatic complexity. So, cyclomatic complexity is how many branches do you have? Like how many ifs and ifs and else, how many you know, how many for loop, how many ifs and other loops, how many while loop that you have. And the cognitive complexity is a Sonar proprietary one where we measure that how difficult a code is for a human being to read and understand and maintain that code, right? So, these are the two different complexity that we maintain. And if you look at the models and the kind of data, you will see that the amount of verbosity that we have seen. So, the newer models that we are seeing coming up you know, day by day, we are seeing the kind of lines of code is going to the north. If you see the GPT 5.2 High, it has created actually a million line of code for those 4,400 plus Java assignments, right? And if you see the earlier models like GPT 4.0, that's less than 250,000 line of code, but the model which has going up north, the number of line of code is you know, being written is too high. You have seen the models which are also going higher up that also have the higher complexity and higher cyclomatic and cognitive complexity. You also need to see that the number of total bugs per model that is also going high, but what we have seen is that the models which are getting matured enough day by day, they are getting kind of finer bugs or finer security issues rather than the old issues. So they're doing a good job in terms of the 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 detect. 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 different genre. Okay, so yeah, we have seen that it's generating the kind of code that doesn't meet your you know engineering standards, but what can we do? So in this slide we talked about the agent-centric development cycle. We call it as ACDC. So Sonar has That's a funny name, yeah. So it's called ACDC framework. So in the ACDC framework we have three stages. We have guide stage, we have verify stage and we have solve phase. So in this one we have our inner loop and we have an outer loop. So in the guide phase we have introduced two different product. One is called Sonar context augmentation and Sonar sweep which is in a private beta. So Sonar sweep is basically treating the data that you 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. If I treat the data right there itself, the code which is going to be generated is going to be good enough, right? Context augmentation is going to push the context all the entire code base into the LLM itself. Then we have the verify stage. Verify stage is Sonar cube. We have various different ways of you know utilizing that. We have introduced Sonar cube agentic analysis which is in beta right now open beta, anybody can participate in that, which is actually taking your code in the runtime. What does it mean is that you're using a cloud or codex or Gemini CLI whatever which have an MCP inbuilt and then you can say that, hey, generate this code. 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? The CI runs takes about 1 to 5 minutes and then this analysis is going to take about 1 to 5 seconds. Within 1 to 5 seconds the code which is being generated right now, before even commit, it will analyze and it will tell you that, oh, these are the problems that I found. Fair enough, it will 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. Now the solve part is where we have introduced the Sonar cube remediation agent. So let's say that even doing after all of that, if there are issues that has been slipped through your verify stage and it has gone back to the PR stage, right? So you committed the code, you push a PR and then you found out the Sonar cube found out there are issues that we found that that's there and your quality gets fails. If that fails, then the remediation agent is right there. It's right now on 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. Not only that, let's say that you have a tech debt, right? Huge amount of tech debt. So you go to the Sonar cube dashboard and you see these all those tech debts that you have, 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 going to fix that one, giving it back to the developers. Developers are going to review that. If they find if they're happy, they're going to you know approve it and then merge it. The beautiful thing that we have built for the 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 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 you know create a regression. We don't do that, right? So that's a kind of a verify loop that we run through. So yeah, this is this is the entire you know I mean I would say that the product uh This is our product portfolio where we are providing from guide and to verify and then solve. We have all these you know 40 plus programming language and framework. All the devops are you know supported IDEs you know we are partnering with this. We have we are in the marketplace as well. So yeah, that's that's how we are solving the the issues that you are seeing where the LLMs are generating the code but we are not trusting that, right? Yeah, so if you want some more info, we are in the expo booth. Come and visit us and maybe we can show you one or two demo as well for the product that we have built. Right, thank you. \[applause\] \>\> \[music\]