Bugbot learned rules: Nu begynder AI-kodereview faktisk at lære af dit team

Cursor har lanceret Bugbot learned rules, en ny funktion der gør deres AI-baserede code review mindre generisk og mere lokalt tilpasset. Sammen med den nye MCP-support til Bugbot er det faktisk en ret vigtig nyhed, hvis man arbejder seriøst med pull requests, review-flows og agentisk udvikling. Det interessante er ikke bare, at endnu en coding-agent er blevet bedre. Det interessante er, at review-agenten nu begynder at lære af, hvordan netop dit team reagerer på dens kommentarer.

Det flytter AI-kodereview et hak op i modenhed. Hidtil har mange teams oplevet, at AI-review enten er imponerende eller irriterende, men ofte begge dele på samme tid. Den finder ting hurtigt, men den mangler fornemmelse for kodebasens lokale normer, historiske kompromiser og de fejlmønstre, som netop jeres system er sårbart overfor. Med Bugbot learned rules prøver Cursor at løse præcis det problem.

Fra statisk AI-review til feedback-loop

Ifølge Cursor blev Bugbot lanceret ud af beta i juli 2025, og dengang blev 52 procent af de fejl, værktøjet markerede, faktisk rettet inden pull requestet blev merged. I den nye annoncering siger Cursor, at værktøjets såkaldte resolution rate nu er steget til 78,13 procent, målt på 50.310 analyserede pull requests i offentlige repositories. Til sammenligning angiver Cursor selv Greptile til 63,49 procent, CodeRabbit til 48,96 procent, GitHub Copilot til 46,69 procent, Codex til 45,07 procent og Gemini Code Assist til 30,93 procent.

De tal skal selvfølgelig læses med det sædvanlige forbehold: benchmarken kommer fra leverandøren selv, og Cursor skriver også, at de brugte en LLM judge til at afgøre, om en kommentar blev adresseret før merge. Men selv med det forbehold er retningen vigtig. Cursor forsøger ikke længere kun at gøre modellen generelt klogere. De bygger et system, hvor review-agenten lærer af produktionen.

Det er kernen i Bugbot learned rules. Bugbot ser på tre typer signaler: reaktioner på dens kommentarer, svar fra udviklere og kommentarer fra menneskelige reviewers. De signaler bliver omsat til kandidatregler, som senere kan promoveres til aktive regler, hvis de viser sig nyttige over tid. Hvis en regel begynder at skabe negativt signal, kan den deaktiveres igen. Med andre ord: review-agenten går fra at være en statisk kommentarmaskine til at være et løbende feedback-loop.

Hvad det betyder i praksis for udviklere

For udviklere er det her mere interessant end endnu en modelopdatering, fordi ændringen rammer direkte ind i den daglige workflow. Når en AI-reviewer lærer af, hvilke kommentarer der bliver accepteret, afvist eller omformuleret, kan den begynde at tale mere præcist ind i teamets reelle standarder. Det betyder potentielt færre støjende kommentarer om petitesser og flere relevante fund om ting, som faktisk bliver rettet.

I en travl pull request-strøm er det en stor forskel. Mange teams bruger allerede agenter til at skrive kode, sådan som vi også har set med Cursor 3 og andre agent-first værktøjer. Men når flere ændringer bliver produceret hurtigere, bliver review-kapacitet pludselig den nye flaskehals. Derfor er det logisk, at næste bølge ikke kun handler om at generere kode, men om at få review-laget til at skalere med.

Bugbot learned rules peger mod en fremtid, hvor AI-review ikke bare checker generelle fejltyper, men også opdager mønstre som er lokale for en given kodebase. Det kan være navngivningskonventioner, sikkerhedsregler, specifikke integrationskrav eller anti-patterns, som kun giver mening i netop jeres system. Her er værdien ikke bare bedre kommentarer, men kortere vej fra pull request til merge.

Den nye MCP-support er også vigtig. MCP står for Model Context Protocol og gør det muligt at give en agent adgang til eksterne værktøjer og datakilder på en mere struktureret måde. I Bugbots tilfælde betyder det, at review-agenten kan få mere kontekst under review, uden at alt skal presses ind i en prompt eller hardcodes i regler. Det gør review mere interessant i miljøer, hvor kode ikke kan forstås isoleret, for eksempel når en ændring afhænger af interne API-kontrakter, policies eller runtime-data.

Den rigtige gevinst, og den rigtige risiko

Den praktiske gevinst er ret enkel: Hvis en review-agent kan lære af teamets faktiske adfærd, så kan den blive mere brugbar uge for uge i stedet for kun ved næste model-release. Cursor oplyser, at mere end 110.000 repositories allerede har aktiveret learning i beta, og at det har skabt mere end 44.000 learned rules. Det er et tegn på, at markedet bevæger sig mod agenter, som ikke bare har en stærk grundmodel, men også en lokal hukommelse om, hvad der virker i et konkret team.

Men der er også en risiko. Hvis agenten lærer af et teams eksisterende adfærd, kan den lige så vel lære dårlige vaner, blinde vinkler og teknisk gæld. Et team, der konsekvent ignorerer bestemte sikkerhedsadvarsler, kan i værste fald lære agenten, at netop de advarsler ikke er vigtige. Derfor bør Bugbot learned rules ikke ses som autopilot, men som et system der kræver governance. Nogen skal eje, hvilke signaler der er sunde at lære af, og hvornår en lokal regel er nyttig kontra bare bekvem.

Netop derfor er denne udvikling interessant i den bredere agentdebat. Vi har allerede set, hvordan platforme som Claude Managed Agents flytter fokus fra enkeltstående modelkald til hele agent-systemer. Cursor gør noget lignende i review-laget: værdien ligger ikke kun i modellen, men i sløjfen mellem model, værktøjer, feedback og arbejdsgange.

Min vurdering er derfor, at Bugbot learned rules er vigtigere, end den korte changelog antyder. Ikke fordi funktionen alene revolutionerer code review, men fordi den viser, hvor markedet bevæger sig hen. Den næste konkurrence mellem AI-værktøjer for udviklere bliver ikke kun afgjort af, hvem der har den bedste model. Den bliver også afgjort af, hvem der bedst kan omsætte teamets egne signaler til bedre agentadfærd i den daglige udvikling.