Wat er gebeurde
Sonar heeft de overname van Gitar aangekondigd, een bedrijf voor AI-native code review. Daarmee wil SonarQube uitgroeien tot een bredere verificatielaag voor agentic softwareontwikkeling. Volgens Sonar moet het gecombineerde platform code controleren vanaf het moment dat AI-agents die genereren tot aan deployment in productie.
De deal draait niet om nog een coding assistant, maar om de controlelaag rondom coding agents. Sonar zegt dat SonarQube wordt gebruikt door meer dan 7 miljoen developers en AI-agents, en dat meer dan 75 procent van de Fortune 100 erop vertrouwt voor kwaliteitscontrole, security en architecturale integriteit. Gitar voegt AI-gedreven code review toe voor teams waar agents, niet alleen mensen, wijzigingen produceren.
Sonar maakt ook het kosten- en betrouwbaarheidsargument expliciet. Het bedrijf claimt dat teams met Sonar 44 procent minder kans hebben op outages door AI-gegenereerde code, en dat codebases die met SonarQube zijn opgeschoond tot 8 procent minder AI-tokengebruik kunnen opleveren. Dat zijn vendorclaims, dus die moet je als zodanig lezen. Maar de richting is relevant: de markt verschuift van generatiesnelheid naar verificatie, governance en operationele kosten.
Waarom dit ertoe doet
Enterprise AI verlaat de demofase. Dat betekent niet alleen betere modellen. Het betekent ook dat meer AI-output terechtkomt in systemen waar fouten geld kosten: productiecode, klantprocessen, backofficebesluiten, compliancecontroles, documenten en operationele dossiers. Zodra output echt werk verandert, wordt de vraag niet meer alleen of de agent iets bruikbaars kan genereren, maar of de organisatie kan vertrouwen, controleren en besturen wat de agent heeft gemaakt.
Daarom wordt verificatie een eigen categorie. Een coding agent die een pull request maakt, heeft tests nodig, architectuurcontroles, securityanalyse, afhankelijkheidsinzicht en een log van wat er is veranderd. Een document- of workflow-agent heeft hetzelfde principe nodig: bronverwijzingen, permissies, confidence-drempels, businessregels, menselijke goedkeuring waar nodig en een audit trail van elke actie.
Er zit ook een kostenles in. Tokenkosten komen niet alleen uit prompts van gebruikers. Ze komen uit rommelige context, herhaalde pogingen, onduidelijke standaarden en agents die moeten redeneren over lawaaiige systemen. Wie voorspelbare AI-kosten wil, heeft schonere input nodig, herbruikbare context en automatische controles die dure fouten vroeg stoppen.
Laava-perspectief
Voor Laava laat dit precies zien waarom een AI-agent geen losse chatbot of toolaccount moet zijn. De waarde zit in het beheerde systeem eromheen: context, redenering, actie, monitoring en duidelijke grenzen. Bij softwareteams heet dat codeverificatie. In document- en workflowintensieve organisaties heet het permission-aware retrieval, workflowvalidatie, antwoorden met bronnen, escalatielogica en veilige integratie met ERP, CRM, SharePoint, e-mail of ticketsystemen.
Dit past ook bij de managed runtime-benadering. Een sovereign runtime of Laava Box-opstelling is niet waardevol omdat er ergens een doos staat. Het is waardevol wanneer de organisatie één beheerde AI-omgeving krijgt voor agents, logging, modelkeuze, datatoegang en operationele controle. Verificatie wordt eenvoudiger wanneer agents draaien in een bekende omgeving, in plaats van verspreid te zijn over persoonlijke AI-accounts en losse SaaS-tools.
Hetzelfde geldt voor modelkeuze. Een model-agnostische runtime laat een bedrijf het juiste model per taak gebruiken, maar modelkeuze heeft pas waarde als het proces eromheen strak is ingericht. De agent heeft nog steeds de juiste context nodig, de juiste integratiepunten, een manier om zijn werk te bewijzen en een heldere grens tussen een actie voorbereiden en een actie uitvoeren.
Wat je kunt doen
Als je al met AI-agents experimenteert, controleer dan eerst de verificatielaag voordat je meer use cases toevoegt. Vraag welk bewijs de agent gebruikt, welke systemen hij mag raken, hoe output wordt gecontroleerd, waar menselijke goedkeuring nodig is en hoe fouten worden gelogd. Als die antwoorden vaag zijn, vergroot opschalen vooral het risico.
Een praktische volgende stap is één operationele bottleneck kiezen en de agent vanaf dag één met controles ontwerpen. Bijvoorbeeld: een documentagent die bronnen citeert, permissies respecteert, onzekere gevallen naar een mens routeert en elke beslissing in een audit trail vastlegt. Dat is minder spectaculair dan een live demo, maar het is het verschil tussen AI die één keer indruk maakt en AI die veilig in de operatie kan draaien.