TL;DR
- Wat: Cursor's Bugbot biedt nu instelbare grondigheid bij het automatisch reviewen van code-wijzigingen (pull requests).
- Waarom relevant: Als je ontwikkelteam AI-tools inzet, bepaalt dit soort instellingen hoeveel bugs je vangt vóór ze bij klanten terechtkomen.
- Wat je ermee kunt: Bespreek met je developers of jullie AI-codereview al gebruikt, en of gedifferentieerd reviewen (kritieke code strenger) waarde zou toevoegen.
Cursor — een populaire AI-code-editor — kondigde aan dat hun reviewtool Bugbot nu een instelbaar "inspanningsniveau" heeft. Je kunt per type codewijziging bepalen hoe diep de AI graaft. Ik vind dit interessant omdat het een patroon laat zien dat breder relevant is: AI-tools worden steeds fijnmaziger in te stellen, en dat maakt ze bruikbaarder voor bedrijven die niet overal hetzelfde budget of risicoprofiel hebben.
Wat is Bugbot precies?
Even voor de context: Bugbot is een AI-tool die automatisch code-wijzigingen bekijkt voordat ze samengevoegd worden met de rest van de software. In de ontwikkelwereld heet zo'n wijziging een pull request (PR) — zeg maar een voorstel om code aan te passen. Normaal kijkt een collega-ontwikkelaar daar handmatig naar, maar Bugbot doet dat geautomatiseerd.
Wat mij opvalt aan de cijfers: Bugbot verwerkt op dit moment meer dan twee miljoen pull requests per maand. Dat is geen nichespeler meer. De tool draait acht parallelle reviewrondes per PR, in willekeurige volgorde door de code, om bugs te vinden die je bij een enkele leesbeurt zou missen. Denk aan logische fouten, beveiligingslekken, race conditions (situaties waarbij twee processen elkaar in de wielen rijden) en foutieve foutafhandeling.
Belangrijk detail: Bugbot negeert bewust stijl- en opmaakissues. Het gaat puur om échte bugs. Dat is een bewuste keuze die de tool onderscheidt van bredere codekwaliteitsplatforms zoals SonarQube of Codacy.
Drie niveaus van grondigheid
De nieuwe functie geeft teams drie opties:
Default
De standaardinstelling, geoptimaliseerd voor snelheid. Bugbot vindt gemiddeld 0,7 bugs per review, en volgens Cursor wordt 79% van die gevonden bugs daadwerkelijk opgelost voordat de code live gaat.
High effort
Een diepere analyse. Hiermee vindt Bugbot gemiddeld 0,95 bugs per run — dat is 35% meer dan bij de standaardinstelling. Het oplossingspercentage blijft stabiel op 80%. Cursor zegt zelf dat ze deze instelling intern gebruiken voor wijzigingen aan hun infrastructuur en backend, de delen van hun software waar een fout de meeste schade kan aanrichten.
Custom
De meest flexibele optie. Teams beschrijven in gewone taal wanneer Bugbot standaard of grondig moet reviewen. Bijvoorbeeld: "Gebruik high effort voor alles wat de betaaldatabase raakt." Cursor vertaalt dat automatisch naar de juiste instelling per PR.
Kun je je voorstellen wat dit betekent als je een softwareteam aanstuurt? Je hoeft niet meer te kiezen tussen "altijd snel" en "altijd grondig". Je kunt de intensiteit aanpassen aan het risico van de wijziging.
Van abonnement naar betalen per gebruik
Er zit nog een verandering aan deze update vast die ik het vermelden waard vind. Bugbot stapt over van een vast abonnement van 40 dollar per gebruiker per maand naar een model op basis van gebruik. Een gemiddelde review kost dan tussen de 1,00 en 1,50 dollar, afhankelijk van de omvang en complexiteit van de PR. Voor bestaande klanten gaat dit in bij de eerstvolgende factureringsronde na 8 juni 2026.
Ik denk dat dit voor kleinere teams voordeliger kan uitpakken. Als je twintig pull requests per maand doet, zit je op 20 tot 30 dollar in plaats van 40 per persoon. Maar voor teams die honderden PRs per maand draaien — en dan ook nog met high effort — kan de rekening juist hoger uitvallen. Het is de moeite waard om dat even door te rekenen voordat je overstapt.
Wat mij betreft is de overstap naar usage-based pricing ook een bredere trend bij AI-tools. Je betaalt voor wat je daadwerkelijk gebruikt, niet voor een vast stoeltje. Voor MKB-bedrijven met wisselende projectvolumes is dat vaak eerlijker.
Wat betekent dit voor bedrijven die software laten bouwen?
Niet elk bedrijf heeft een intern ontwikkelteam, maar veel MKB-ondernemers laten wél software bouwen — door freelancers, bureaus of een klein team. En hier wordt het interessant.
AI-codereview is niet meer experimenteel. GitHub rapporteert dat in het eerste kwartaal van 2026 meer dan 51% van alle code op hun platform geheel of grotendeels met AI-hulp is geschreven. Als er méér AI-gegenereerde code in omloop is, wordt automatische controle op bugs en beveiligingslekken relevanter — niet minder.
Stel dat je als ondernemer een webapplicatie laat bouwen voor je klanten. De code die je betalingsafhandeling regelt, wil je waarschijnlijk strenger laten controleren dan een aanpassing aan de kleur van een knop. De instelling die Cursor nu biedt — gedifferentieerde grondigheid — sluit aan bij hoe je als bedrijf ook over risico nadenkt: niet alles is even kritiek, dus niet alles verdient dezelfde investering in controle.
Dat principe is breder toepasbaar dan alleen Cursor. Tools als CodeRabbit, Qodo en andere AI-reviewplatforms bewegen dezelfde kant op. Als je developers inhuurt of aanstuurt, is het een goed moment om te vragen: gebruiken jullie al geautomatiseerde codereview? En zo ja, is die review afgestemd op wat er op het spel staat?
Een breder patroon: AI die je laat kiezen
Wat ik het meest opvallend vind aan deze update, is niet de techniek zelf. Het is het patroon. Steeds meer AI-tools geven gebruikers een schuifregelaar: hoe diep moet de AI nadenken? Hoe grondig moet de analyse zijn? OpenAI doet het met hun reasoning-modellen (je kiest hoeveel "denktijd" het model krijgt), en nu biedt Cursor hetzelfde concept voor codereview.
Dat is relevant omdat het de kosten-batenafweging expliciet maakt. Meer nadenktijd kost meer geld en meer tijd, maar levert ook meer op. Als ondernemer is dat een herkenbare afweging — het is dezelfde logica als kiezen tussen een snelle steekproefcontrole en een volledige audit bij je boekhouder.
Ik denk dat we dit patroon het komende jaar bij veel meer tools gaan zien. En voor ondernemers is het goed om te weten dat die keuze er is. Niet elk AI-gebruik hoeft op volle kracht te draaien. Soms is "goed genoeg" efficiënter dan "maximaal grondig" — en soms is het andersom.
Voor mij is dit vooral een signaal dat AI-tools volwassener worden. Ze geven je niet meer één knop die aan of uit staat, maar laten je afstemmen op je eigen situatie. En dat is, wat mij betreft, precies wat het bedrijfsleven nodig heeft.