JetBrains Rider AI-Agenter: Opsætning I 12 Trin [2026]

Rider har altid været kendt for at forstå din kode bedre end de fleste editorer. Med version 2026.2, udgivet 22. juli 2026, og patch-udgaven 2026.2.2 fra 16. september 2026, åbner JetBrains den viden op for AI-agenter. I stedet for at en agent som GitHub Copilot eller Claude Code skal gætte sig frem gennem filer og terminaloutput, kan den nu spørge Rider direkte om testdækning, profileringsdata og sikker refaktorering. Denne guide viser dig præcis hvordan du sætter det op, fra installation til et komplet .NET-projekt hvor agenten selv retter fejl, skriver tests og analyserer performance.

Du behøver ikke være .NET-ekspert for at følge med. Guiden bruger et lille Web API-projekt som eksempel, og hvert trin indeholder de faktiske menupunkter og kommandoer, du skal bruge. Undervejs får du også fem faldgruber andre udviklere er faldet i, otte konkrete fejlfindingsscenarier, og en sammenligning af, hvad det koster at komme i gang.

Hvad er Rider 2026.2’s AI-agent skills, og hvorfor betyder det noget?

Før 2026.2 fungerede de fleste AI-kodeagenter i Rider på samme måde som i enhver anden editor. Agenten læste filer, kørte terminalkommandoer, og forsøgte at samle et billede af kodebasen ud fra det. Det virker, men det er langsomt og upræcist, fordi agenten reelt genopfinder analyser, som Rider allerede har liggende klar.

JetBrains beskriver ændringen sådan i deres officielle udgivelsesnote: “Rider 2026.2 connects coding agents directly to the IDE’s coverage data, profiler insights, refactoring engine, and framework-specific guidance, so they find context faster and make safer changes with less guesswork and token waste” (JetBrains, juli 2026). Kort sagt: agenten låner Riders egen hjerne i stedet for at bygge sin egen fra bunden.

Det sker gennem det, JetBrains kalder Agent Skills. Det er bundtede funktioner, der eksponerer specifikke dele af Riders motor, testdækning, profilering, refaktorering og debugging, til eksterne AI-agenter via Model Context Protocol (MCP). Ifølge JetBrains rammer opdateringen fire IDE’er forskelligt: “IntelliJ IDEA, RubyMine, CLion, and Rider ship with a skill for debugging, while Rider offers skills for refactoring and performance analysis and DataGrip comes with one for database operations” (JetBrains, juli 2026). Rider får altså den bredeste pakke, fordi .NET-udvikling historisk har haft stærk værktøjsstøtte til test og profilering i forvejen.

For danske og nordiske .NET-teams betyder det konkret, at code review-tid og debugging-tid kan falde, fordi agenten arbejder med de samme data, en senior-udvikler ville bruge. Det er særligt relevant nu, hvor flere danske virksomheder har indført AI-kodeassistenter som standardværktøj i deres udviklingsteams, og hvor kravet om hurtigere leverancer presser teams til at stole mere på automatiseret refaktorering og testgenerering.

Det er værd at forstå, hvorfor JetBrains overhovedet gjorde dette skridt. De fleste AI-kodeagenter, uanset om det er Copilot, Claude Code eller en anden agent, bygger deres forståelse af et projekt ved at læse filer og gætte sig frem via mønstergenkendelse. Det fungerer, men det koster tokens, og det kan føre til fejl, når agenten misforstår en kodebases struktur. Rider har allerede investeret årtier i statisk analyse, dækningssporing og profilering gennem produkter som ReSharper og dotTrace. I stedet for at lade agenter genopfinde den analyse fra bunden, giver JetBrains dem adgang til det færdige resultat via MCP-protokollen. Det er samme grundprincip, som ligger bag MCP-servere generelt: en agent bliver bedre, når den kan spørge et specialiseret værktøj direkte, i stedet for at simulere det selv.

Konsekvensen er en anden type samarbejde mellem udvikler og agent. Hvor du tidligere skulle formulere meget detaljerede prompts for at kompensere for agentens manglende projektkendskab, kan du nu give kortere instruktioner og stole på, at JetBrains Rider fylder hullerne ud. Det ændrer også, hvordan teams bør evaluere deres AI-værktøjer: Spørgsmålet er ikke længere kun “hvilken model er bedst”, men også “hvilken IDE giver modellen mest at arbejde med”.

Timingen er heller ikke tilfældig. Gennem 2026 har flere IDE-leverandører kæmpet om at blive standardplatformen for agent-baseret udvikling, og JetBrains svarer med en strategi, der satser på dybde frem for at bygge endnu en editor fra bunden. I stedet for at konkurrere direkte med rene AI-editorer forsøger JetBrains at gøre eksisterende Rider-brugere mere effektive, uanset hvilken agent de i forvejen har valgt at stole på.

Forudsætninger: Dette skal du bruge før du starter

Du skal bruge fire ting for at følge denne guide: en opdateret Rider-installation, et .NET SDK, en AI-agent du kan koble på, og et testprojekt. Tabellen nedenfor viser de versioner, denne guide er testet med.

Komponent	Krævet version	Bemærkning
JetBrains Rider	2026.2.2 (16. september 2026) eller nyere	2026.2 introducerer skills, 2026.2.1 tilføjer refaktorering og debugging, 2026.2.2 tilføjer AI Agent Setup-widget’en
.NET SDK	.NET 8 eller nyere	Skills fungerer med C#, F# og C++/mixed-language-projekter
AI-agent	GitHub Copilot, Claude Code eller Codex	Copilot er nu indbygget nativt i Rider 2026.2, de øvrige tilkobles via AI Assistant-indstillingerne
Styresystem	Windows, macOS eller Linux	Rider er krydsplatform, samme skills virker på alle tre
dotTrace	Nyeste version (valgfri)	Kun nødvendig hvis du vil bruge profilerings-skillet dottrace-analyze

Har du allerede en licens til JetBrains AI Assistant, kan du genbruge den samme konto. Har du i forvejen sat MCP-servere op til andre værktøjer, fungerer den samme protokol her, fordi Rider taler MCP i begge retninger.

En detalje, mange overser: skills og hooks kræver ikke en separat licens oven på din Rider-abonnement. Det, der derimod kræver særskilt opsætning, er selve agenten. GitHub Copilot er nu bygget direkte ind i Rider, så du logger blot ind med din eksisterende konto. Claude Code og Codex kører som eksterne CLI-værktøjer, som Rider taler med, hvilket betyder, at du skal installere dem separat på din maskine, før Rider kan pege på dem. Har du et team, der allerede kører flere agenter på tværs af projekter, er det en god idé at afklare, hvilken agent der er standard for netop dette projekt, før du går videre til trin 1.

Endelig bør du sikre dig, at dit projekt rent faktisk har en teststruktur, dotCover kan læse. Uden eksisterende tests eller uden en genkendelig mappestruktur til tests, har finding-tests-skillet intet mønster at arbejde ud fra, og resultatet bliver mindre præcist. Har projektet slet ingen tests endnu, er det bedre at oprette én manuel eksempel-test først, og lade agenten bygge videre derfra.

Trin 1-3: Installer Rider, opdater til nyeste patch og aktivér AI Assistant

Trin 1: Installer eller opdater Rider til 2026.2.2

Åbn JetBrains Toolbox App og tjek, om Rider viser en opdatering. Har du ikke Toolbox, kan du hente installationsfilen direkte fra jetbrains.com/rider/download. Har du allerede Rider 2026.2 installeret, skal du specifikt opdatere til 2026.2.2, fordi det er patch-udgaven, der tilføjer AI Agent Setup-widget’en i statuslinjen nederst til højre. Uden den widget skal du konfigurere hver skill manuelt gennem indstillingsmenuen, hvilket tager længere tid.

Toolbox App viser versionsnummeret ved siden af Rider-ikonet. Står der 2026.2 eller 2026.2.1 uden et efterfølgende “.2”, skal du klikke på de tre prikker ved siden af appen og vælge Update. Opdateringen tager typisk et par minutter afhængigt af din internetforbindelse, og Rider genstarter automatisk, når den er færdig. Kør IDE’en mindst én gang efter opdateringen, før du går videre, så den kan fuldføre sin egen indeksering af eventuelt åbne projekter.

Trin 2: Opret et testprojekt

Brug et eksisterende projekt, eller opret et nyt Web API-projekt til at følge med i guiden. Åbn terminalen i Rider (Alt+F12 på Windows/Linux, Option+F12 på macOS) og kør:

dotnet new webapi -n RiderAgentDemo
cd RiderAgentDemo
dotnet add package Microsoft.AspNetCore.OpenApi
dotnet build

Åbn mappen i Rider via File → Open. Rider indekserer projektet automatisk, og det er netop det indeks, agenterne senere får adgang til. Indekseringen kører i baggrunden og vises som en fremdriftslinje nederst i vinduet. Vent til den er færdig, før du beder en agent om noget, der kræver projektkontekst, ellers risikerer skillet at arbejde med et ufuldstændigt billede af koden.

Trin 3: Aktivér AI Assistant og vælg din agent

Gå til Settings/Preferences → Tools → AI Assistant. Her vælger du, hvilken agent du vil bruge. GitHub Copilot er nu en indbygget agent i Rider som følge af et direkte samarbejde mellem JetBrains og Microsoft, så den kræver kun login med din eksisterende Copilot-konto. Vil du i stedet bruge Claude Code eller Codex, tilføjer du dem under samme menu ved at pege på deres CLI-installation. Har du allerede sat op agent-konfiguration i et AGENTS.md-format i andre projekter, kan Rider læse den samme fil, når den findes i rodmappen.

Når agenten er valgt, åbner du AI-chat-panelet, typisk placeret som en fane i højre side af Rider-vinduet. Skriv en simpel testbesked som “hvilket projekt arbejder jeg i?” for at bekræfte, at agenten faktisk har adgang til projektindekset. Svarer den korrekt med projektnavn og struktur, er forbindelsen sat rigtigt op. Svarer den generisk eller beder om at få filer indsat manuelt, er agenten ikke koblet korrekt på Riders kontekst, og du bør tjekke login-status under samme indstillingsside.

Trin 4: Installer de indbyggede agent-skills

Naviger til Settings/Preferences → Tools → AI Assistant → Skills. Brug søgefeltet til at finde det skill, du vil bruge, marker det, og klik Install. Nogle skills, som refactoring-code, er allerede bundtet med IDE’en og kræver ingen installation. De aktiveres automatisk, når en agent bliver bedt om at refaktorere C#-kode.

Skills-panelet fungerer lidt som et lille plugin-marked. Hvert skill har en kort beskrivelse, en versionsangivelse og en installationsknap. Er skillet allerede installeret, viser panelet i stedet en Update-knap, hvis der findes en nyere version. Det er værd at tjekke dette panel efter hver Rider-opdatering, fordi JetBrains løbende har udvidet skill-samlingen gennem hele 2026, og nye skills dukker typisk op uden en stor markedsføringskampagne.

Tabellen herunder viser de fire centrale skills i Rider 2026.2/2026.2.1, hvad de gør, og hvad de kræver.

Skill	Indført i	Funktion
finding-tests	Rider 2026.2	Bruger dotCover-dækningsdata til at finde eksisterende relaterede tests og placere nye tests korrekt
dottrace-analyze	Rider 2026.2	Læser en dotTrace-snapshot og sporer CPU-flaskehalse tilbage til den konkrete kode
refactoring-code	Rider 2026.2.1	Lader agenten kalde Riders egne refaktoreringsoperationer i stedet for tekstbaserede gæt
debugging-code	Rider 2026.2.1	Giver agenten adgang til breakpoints, variabelværdier og trådkontekst i C#, F#, C++, Unity og Unreal Engine

Trin 5: Automatisk testgenerering med finding-tests

Med finding-tests slipper du for at agenten placerer en ny test i en tilfældig fil, eller genopfinder en test, der allerede findes. JetBrains forklarer princippet sådan: “When you ask your AI agent to generate tests, Rider can use dotCover coverage insights to find existing related tests, follow your project’s testing style, and generate the perfect tests with no manual guidance or costly wandering round the codebase” (JetBrains, maj 2026).

Åbn AI-chatten (typisk med genvejen der er sat i din agent-konfiguration) og bed om en test til en controller-metode. Et eksempel på en prompt, du kan skrive direkte i Rider:

Skriv en unit test til WeatherForecastController.Get().
Brug finding-tests skillet til at følge projektets
eksisterende teststil og placere testen korrekt.

Agenten spørger herefter Rider om, hvilken teststruktur projektet allerede bruger (xUnit, NUnit eller MSTest), finder den mappe, hvor lignende tests ligger, og genererer en ny testfil, der matcher navngivning og opsætning. Resultatet lander typisk i en Tests-mappe med samme namespace-struktur som produktionskoden, ikke i rodmappen, som mange agenter uden dette skill ville gøre. Et typisk resultat ser sådan ud:

public class WeatherForecastControllerTests
{
    private readonly WeatherForecastController _controller;

    public WeatherForecastControllerTests()
    {
        _controller = new WeatherForecastController();
    }

    [Fact]
    public void Get_ReturnsFiveForecastEntries()
    {
        var result = _controller.Get();
        Assert.Equal(5, result.Count());
    }
}

Læg mærke til, at klassen hedder WeatherForecastControllerTests, ikke et generisk navn som Test1, og at den ligger i samme namespace som produktionskoden. Det er netop den type detalje, finding-tests-skillet henter fra Riders eksisterende dækningsdata, i stedet for at agenten selv skal gætte på en fornuftig navngivningskonvention.

Trin 6: Sikker refaktorering med refactoring-code

Dette er formentlig det skill, der sparer mest tid i praksis. JetBrains skriver direkte: “The bundled refactoring-code skill helps AI agents refactor code faster and at lower cost” (JetBrains, august 2026). Forskellen fra almindelig AI-refaktorering er, at agenten ikke længere skriver om koden som ren tekst. Den kalder i stedet Riders symbol-bevidste refaktoreringsmotor, den samme motor, en udvikler selv ville bruge via Shift+F6 til at omdøbe en metode.

Skillet dækker konkret disse operationer: rename_refactoring, extract_method, extract_interface, extract_base_class, change_api_signature, move_type_to_namespace og reorganize_namespaces. Prøv det selv med en prompt som denne:

Udtræk metoden CalculateForecast fra WeatherForecastController
til en separat service-klasse ved navn ForecastService,
og opdater alle referencer i projektet.

Fordi det er Riders egen extract_method-operation, der udføres, opdateres alle referencer automatisk i hele løsningen, ikke kun i den fil, agenten kigger på. Det reducerer risikoen for, at agenten glemmer et sted, hvor metoden bliver kaldt fra et andet projekt i samme solution. Resultatet af ovenstående prompt kan for eksempel se sådan ud i den nye service-klasse:

public class ForecastService
{
    public IEnumerable<WeatherForecast> CalculateForecast()
    {
        var summaries = new[] { "Freezing", "Mild", "Warm" };
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = summaries[Random.Shared.Next(summaries.Length)]
        });
    }
}

Kald i WeatherForecastController opdateres samtidig automatisk til at pege på den nye ForecastService, uden at du selv skal søge og erstatte referencer manuelt.

Trin 7: Performance-fejlfinding med dottrace-analyze

Dette skill kræver, at du allerede har en dotTrace-snapshot liggende, enten optaget i Rider eller i en selvstændig dotTrace-session. Uden en snapshot har agenten intet at analysere. Sådan tager du en:

Kør din applikation via Run → Attach Profiler to Process, eller start den direkte med profileringsknappen i værktøjslinjen. Lad den køre gennem det scenarie, du oplever er langsomt, og gem snapshotten via File → Save Snapshot As.

Analysér snapshotten forecast-slow.dtp med dottrace-analyze
og find den metode, der bruger mest CPU-tid.
Foreslå en konkret rettelse.

JetBrains beskriver funktionen sådan: “The bundled dottrace-analyze skill can read a dotTrace .dtp snapshot you hand to it, find where the CPU actually went, and trace the hot path back into your code” (JetBrains, juli 2026). Med 2026.2.1-opdateringen håndterer skillet også Unity-profileringssnapshots, hvilket gør det relevant for spiludviklere, ikke kun backend-teams.

Agentens svar kommer typisk tilbage som almindelig tekst i chatpanelet, struktureret omkring den faktiske hot path. Et eksempel på, hvordan et svar kan se ud:

Analyse af forecast-slow.dtp:
- 68% af CPU-tiden bruges i ForecastService.CalculateForecast
- Årsag: Random.Shared.Next kaldes i en løkke med
  unødvendig genberegning af summaries-arrayet
- Forslag: Flyt summaries-arrayet uden for løkken,
  og cache resultatet mellem kald

Fordi agenten sporer flaskehalsen tilbage til en konkret linje i en konkret metode, kan du bede den om at implementere rettelsen med det samme, og derefter bruge refactoring-code eller finding-tests til at verificere, at ændringen ikke har brudt eksisterende funktionalitet.

Trin 8: Runtime-debugging med debugging-code

debugging-code lader agenten sætte breakpoints, træde gennem kode linje for linje, inspicere variabelværdier og tjekke trådkontekst, uden at du selv skal styre debuggeren manuelt. Det virker på tværs af C#, F#, C++ og blandede projekter bygget med .NET, Unity eller Unreal Engine.

Sæt et breakpoint i ForecastService.Calculate() på linje 24
og undersøg, hvorfor temperature-værdien nogle gange er null.
Brug debugging-code til at inspicere variablerne live.

Agenten kører derefter applikationen i debug-tilstand, stopper ved breakpointet, læser variabelværdierne, og rapporterer tilbage med den faktiske runtime-tilstand i stedet for at gætte ud fra statisk kodeanalyse. Det er særligt nyttigt ved race conditions og null-reference-fejl, som er svære at spotte ved at læse kode alene.

Trin 9: Kvalitetstjek-hooks og AI Agent Setup-widget’en

Ud over skills tilbyder Rider hooks, der kører automatisk, hver gang en agent laver en ændring. Rider tilbyder en Run files inspections-hook og en Reformat file-hook. Med 2026.2.2-opdateringen blev inspektions-hooket forbedret, så det kun rapporterer resultater for den kode, agenten selv har tilføjet, i stedet for hele filen, hvilket gør feedbacken langt mere præcis.

Aktivér hooks under Settings/Preferences → Tools → AI Assistant → Hooks. Vælg, hvilken agent hooket skal gælde for, Claude Code og Codex understøttes begge fra 2026.2.1. Herefter tjekker Rider automatisk kodekvaliteten, hver gang agenten skriver en ændring, uden at du selv skal bede om det.

Den nyeste tilføjelse er AI Agent Setup-widget’en fra 2026.2.2. Den ligger i statuslinjen nederst til højre i Rider-vinduet og fungerer som en samlet indgang til alt AI-relateret opsætning, MCP-værktøjer, skills og hooks, i stedet for at du skal lede efter dem tre forskellige steder i indstillingerne. Klik på widget’en for at se en oversigt over, hvad der allerede er aktiveret i det aktuelle projekt.

Trin 10-12: Microsoft-skills, Aspire/Azure-workflows og det samlede projekt

Trin 10: Tilføj officielle Microsoft .NET-skills

Ud over JetBrains’ egne skills kan du browse og installere Microsofts officielle skill-repositories direkte fra Rider under Settings/Preferences → Tools → AI Assistant → Skills → Microsoft/.NET. Her finder du separate pakker til almindelig .NET-udvikling, .NET Aspire og Azure. Det er relevant, hvis dit projekt trækker på cloud-ressourcer, fordi skillet giver agenten kontekst om Azure-specifikke konventioner, som Rider ellers ikke kender til.

Trin 11: Konfigurer Aspire og Azure-workflows

Hvis dit projekt bruger .NET Aspire til orkestrering af flere services, installerer du Aspire-skillet fra samme menu. Det giver agenten adgang til at forstå AppHost-projektets struktur, så den kan foreslå ændringer i service-referencer uden at bryde orkestreringen. Det samme gælder Azure-skillet, som hjælper agenten med at følge de konventioner, Microsoft anbefaler til ressourcenavngivning og konfiguration.

Disse Microsoft-skills er ikke bygget af JetBrains selv, men vedligeholdes af Microsoft og distribueres gennem det samme skill-register, som JetBrains Rider bruger til sine egne skills. Det betyder, at opdateringer til Aspire- og Azure-skillene ruller ud uafhængigt af selve Rider-udgivelserne, så det er værd at tjekke Skills-panelet for opdateringer selv i perioder, hvor JetBrains ikke selv har udgivet en ny Rider-version.

Trin 12: Saml det hele i et komplet projekt

Med alle skills installeret ser en typisk arbejdsgang sådan ud i praksis: Du beder agenten om at implementere en ny endpoint, agenten skriver koden, refactoring-code renser strukturen op, finding-tests genererer tests, debugging-code verificerer, at endpointet faktisk returnerer korrekt data ved runtime, og dottrace-analyze bekræfter, at ændringen ikke har introduceret en performance-regression. Det samlede resultat er et projekt, hvor hvert trin fra kode til verificeret ændring er dækket af mindst ét skill, uden at du skifter værktøj undervejs.

Byg projektet en sidste gang for at bekræfte, at alt hænger sammen:

dotnet build
dotnet test
dotnet run

Ser du grønne tests og en fejlfri build, har du et fungerende projekt, hvor Rider og din valgte agent samarbejder gennem alle fire skills.

5 almindelige faldgruber, du skal undgå

De fleste problemer med Rider-skills stammer ikke fra selve funktionerne, men fra forkerte antagelser om, hvordan de hænger sammen med licens, agent og version. Her er de fem faldgruber, der oftest sender udviklere tilbage til dokumentationen.

At glemme opdateringen til 2026.2.2. Uden den mangler du AI Agent Setup-widget’en og de forbedrede hooks, og du ender med at konfigurere alt manuelt gennem tre forskellige indstillingsmenuer i stedet for én samlet oversigt. Tjek versionsnummeret først, hver gang noget ikke opfører sig som beskrevet i denne guide.
At tro, alle skills er aktive fra start. refactoring-code er bundtet og kræver ingen installation, men finding-tests og dottrace-analyze skal installeres eksplicit via Skills-panelet. Mange udviklere antager, at hele pakken følger med IDE’en, og bliver forvirrede, når en agent ikke reagerer på en skill-specifik kommando.
At bruge dottrace-analyze uden en snapshot. Skillet kan ikke analysere noget, det ikke har adgang til. Optag altid en profileringssession, før du beder agenten om en analyse, ellers får du en fejlbesked i stedet for et svar.
At blande Rider-licensen sammen med AI Assistant-adgang. En gyldig Rider-licens giver dig ikke automatisk adgang til alle tredjeparts-agenter. GitHub Copilot, Claude Code og Codex kræver hver deres egen konto eller abonnement, og det er let at glemme, når man først har vænnet sig til, at skills selv er gratis inkluderet.
At forvente, at hooks virker med enhver agent. Kvalitetstjek-hooks er dokumenteret til at fungere med Claude Code og Codex. Bruger du en anden agent, skal du selv teste, om hooket faktisk trigges, i stedet for at antage, at det virker ens på tværs af alle integrationer.

Fejlfinding: 8 problemer og løsninger

Selv med korrekt opsætning støder du sandsynligvis på et par af disse scenarier undervejs. Listen bygger på de fejlmønstre, JetBrains selv har dokumenteret i deres udgivelsesnoter, samt de mest oplagte konfigurationsfejl, der opstår, når skills, agenter og hooks skal spille sammen.

Problem	Sandsynlig årsag	Løsning
Skills-panelet viser ingen resultater ved søgning	Rider er ikke opdateret til 2026.2 eller nyere	Tjek versionen under Help → About, og opdater via Toolbox
dottrace-analyze fejler med “no snapshot found”	Der er ikke optaget en profileringssession endnu	Kør profileringen via Run → Attach Profiler, og gem en .dtp-fil først
Agenten ignorerer refactoring-code og skriver ren tekst	Ændringen ligger uden for de dokumenterede operationer	Formuler prompten med et af de navngivne kald, fx extract_method eller rename_refactoring
GitHub Copilot vises ikke som mulig agent	Copilot-integrationen er ikke logget ind	Log ind under Settings → Tools → AI Assistant med din eksisterende Copilot-konto
Hooks kører ikke automatisk efter agentens ændringer	Hooket er ikke bundet til den aktive agent	Åbn Settings → Tools → AI Assistant → Hooks, og vælg din agent eksplicit under hver hook
finding-tests placerer testen i rodmappen	Projektet mangler en genkendelig eksisterende teststruktur	Opret mindst én eksisterende test i standardmappen, så skillet har et mønster at følge
AI Agent Setup-widget’en mangler i statuslinjen	Du kører stadig 2026.2 eller 2026.2.1	Opdater specifikt til 2026.2.2, hvor widget’en først blev introduceret
debugging-code kan ikke sætte breakpoints i Unity-projekt	Unity-processen er ikke korrekt attachet til Rider	Brug Run → Attach to Unity Process, før du beder agenten om at fejlsøge

Går et problem igen, efter du har prøvet løsningen i tabellen, er det ofte hurtigere at deaktivere og geninstallere det pågældende skill fra Skills-panelet end at fejlsøge indstillinger manuelt. Skills er små, selvstændige komponenter, så en geninstallation tager sjældent mere end et minut.

Avancerede tips til daglig brug

Når du har de fire grundlæggende skills sat op, kan du kombinere dem i en enkelt prompt i stedet for at bede om ét trin ad gangen. Bed for eksempel agenten om at “refaktorer, generér tests, og bekræft med debugging-code” i samme besked. JetBrains Rider håndterer rækkefølgen internt, fordi hvert skill kalder sin egen del af IDE’en uafhængigt af de andre.

Et andet tip er at lade nye teammedlemmer starte med finding-tests, før de rører ved refactoring-code. Fordi testgenerering er mindre invasiv end en strukturel refaktorering, får nye brugere en tryg introduktion til, hvordan skills arbejder sammen med Riders eksisterende analyse, uden risikoen for at en fejlslagen refaktorering ender i en stor, uoverskuelig diff. Når tilliden til skillet er etableret, er det naturligt at bevæge sig videre til de mere indgribende operationer som extract_method og change_api_signature.

Brug quality-check hooks aktivt på større refaktoreringer, ikke kun nye features. Fordi hooket i 2026.2.2 kun rapporterer inspektioner for den kode, agenten selv har rørt ved, kan du lade det køre kontinuerligt uden at drukne i støj fra resten af kodebasen.

Hvis dit team allerede bruger tilladelsesstyring i GitHub Copilot til at begrænse, hvad agenten må gøre autonomt, så tjek om de samme principper giver mening for Riders hooks. Kør fx quality-check-hooket som en obligatorisk port, før en agent-genereret ændring committes, i stedet for at stole blindt på agentens egen vurdering.

For Unreal Engine- og Unity-udviklere er dottrace-analyze værd at køre efter enhver større content-opdatering, ikke kun ved oplevede performance-problemer. Fordi skillet fra 2026.2.1 håndterer Unity-profileringssnapshots direkte, kan du bygge det ind som et fast trin, hver gang en agent laver ændringer i rendering-koden.

Endelig: brug AI Agent Setup-widget’en som dit faste udgangspunkt, når du fejlfinder en skill-relateret opsætning. Fordi widget’en samler status for MCP-værktøjer, skills og hooks ét sted, sparer den dig for at klikke gennem tre separate indstillingssider, hver gang du skal bekræfte, om en given funktion rent faktisk er aktiv i det projekt, du står i.

Priser: Hvad koster Rider i 2026?

Selve AI-agent-skills er inkluderet i din eksisterende Rider-licens, du betaler ikke ekstra for dem oven i din IDE-licens. Det, du derimod skal budgettere med separat, er adgangen til den agent, du vælger at koble på: GitHub Copilot, Claude Code eller Codex kræver hver deres eget abonnement uden for JetBrains’ økosystem. Har du allerede en aktiv Copilot-aftale gennem dit team, kan du genbruge den direkte, fordi integrationen i Rider 2026.2 er native.

For teams, der overvejer at opgradere specifikt for at få adgang til skills, er den praktiske pointe, at investeringen ligger i selve Rider- eller dotUltimate-abonnementet, du allerede har eller alligevel skal have for at bruge IDE’en. Der findes ikke en separat “AI-tilføjelse”, du skal lægge oven i prisen, sådan som visse konkurrerende IDE’er kræver et ekstra AI-abonnement ved siden af selve editoren. Det gør beslutningen enklere for indkøbsansvarlige, fordi der ikke er en skjult ekstraomkostning at forhandle om, ud over selve agent-licensen.

Licenstype	Inkluderer AI-agent skills	Ekstra du selv skal betale for
Rider individuel/kommerciel licens	Ja, inkluderet fra 2026.2	Abonnement til den valgte AI-agent (Copilot, Claude Code eller Codex)
Rider non-commercial licens	Ja, inkluderet fra 2026.2	Samme som ovenfor, agent-abonnementet er separat
dotUltimate-pakken (Rider + ReSharper + øvrige .NET-værktøjer)	Ja, alle værktøjer opdateres samlet til 2026.2-generationen	Agent-abonnement, samt evt. dotTrace-licens hvis den ikke allerede indgår

Rider vs. Visual Studio: Hvordan adskiller AI-funktionerne sig?

Den centrale forskel er arkitektonisk, ikke bare en liste af funktioner. Rider eksponerer sin egen interne intelligens, profileringsdata, dækningskort og refaktoreringsmotor, direkte til eksterne agenter via MCP. Visual Studio har historisk bygget sin AI-integration tættere op ad Copilot specifikt, mens Rider fra 2026.2 er agent-agnostisk: du kan koble Copilot, Claude Code eller Codex på samme underliggende skills uden at skifte IDE.

For teams, der allerede har investeret i JetBrains AI Assistant på tværs af flere IDE’er, betyder det, at den samme skill-arkitektur genbruges i IntelliJ IDEA, CLion, RubyMine og DataGrip, blot tilpasset hver sprogs behov. Det gør det lettere at standardisere AI-arbejdsgange på tværs af et team, der bruger flere forskellige JetBrains-produkter, end hvis hvert værktøj havde sin egen isolerede AI-implementering.

Det er værd at holde øje med, hvordan JetBrains’ egne AI-produkter udvikler sig i konkurrence med hinanden. Deres agent Junie har for eksempel oplevet skiftende placeringer på uafhængige benchmarks i løbet af 2026, hvilket viser, at feltet stadig bevæger sig hurtigt, og at dagens bedste værktøj ikke nødvendigvis er det samme om seks måneder.

En praktisk konsekvens af arkitekturvalget er, at du ikke behøver vente på, at JetBrains selv laver den bedste model. Fordi skills fungerer uafhængigt af, hvilken agent der kalder dem, kan du frit skifte til en ny model eller agent, den dag en bedre en dukker op, uden at miste adgangen til Riders refaktorerings- og profileringsdata. Visual Studio-brugere, der ønsker samme fleksibilitet, må typisk vente på, at Microsoft selv bygger understøttelse for en ny model ind i deres Copilot-integration, før den er tilgængelig i IDE’en.

Sikkerhed: Hvilke data deler JetBrains Rider med din AI-agent?

Som sikkerhedsredaktion synes vi, det er værd at stoppe op ved det åbenlyse spørgsmål: Når JetBrains Rider giver en ekstern agent adgang til dækningsdata, profileringssnapshots og din kodebases struktur, hvor havner de data så? Svaret afhænger af, hvilken agent du vælger. GitHub Copilot, Claude Code og Codex kører alle som cloud-baserede tjenester, hvilket betyder, at den kontekst, Rider sender via MCP, i praksis forlader din maskine og behandles på leverandørens servere, uanset om det er Microsoft, Anthropic eller OpenAI.

Det er en anden risikoprofil end almindelig kodefærdiggørelse, fordi skills som dottrace-analyze og debugging-code potentielt eksponerer runtime-værdier, ikke kun statisk kode. Kører din applikation med rigtige data under en debug-session, kan de værdier i teorien indgå i den kontekst, agenten modtager. For projekter med følsomme data, personoplysninger eller forretningshemmeligheder, bør du derfor undgå at køre debugging-code eller dottrace-analyze direkte mod produktionsdata eller mod en kopi af en produktionsdatabase.

En praktisk anbefaling til danske teams, der arbejder under GDPR, er at bruge syntetiske testdata i det projekt, hvor du eksperimenterer med Rider-skills, i hvert fald indtil dit team har vurderet, hvilken databehandleraftale der gælder for den valgte agent-leverandør. Tjek desuden, om din organisation allerede har en virksomhedsaftale med GitHub, Anthropic eller OpenAI, der dækker databehandling, inden du ruller skills bredt ud til et team, der arbejder med kundedata.

Kvalitetstjek-hooks ændrer ikke ved denne grundlæggende risiko, men de tilføjer et ekstra lag af automatiseret gennemsyn, som i sig selv sender kode til agenten hyppigere, fordi hooket kører ved hver ændring. Overvej derfor at afgrænse, hvilke projekter og mapper hooks er aktive i, i stedet for at slå dem til globalt for alle projekter i din Rider-installation.

Ofte stillede spørgsmål

Skal jeg betale ekstra for AI-agent skills i Rider?
Nej. Skills følger med din eksisterende Rider-licens fra version 2026.2. Du betaler kun for selve AI-agenten (Copilot, Claude Code eller Codex), hvis du ikke allerede har adgang gennem en anden aftale.

Virker skills med både C# og F#?
Ja. debugging-code dækker eksplicit C#, F#, C++ og blandede projekter bygget med .NET, Unity eller Unreal Engine. refactoring-code er primært dokumenteret til C#.

Kan jeg bruge skills uden en AI-agent tilkoblet?
Nej. Skills er en bro mellem Rider og en ekstern agent. Uden en konfigureret agent, GitHub Copilot, Claude Code eller Codex, har skillet ingen agent at levere data til.

Hvad er forskellen på 2026.2, 2026.2.1 og 2026.2.2?
2026.2 (22. juli 2026) introducerede skills-arkitekturen med finding-tests og dottrace-analyze. 2026.2.1 (19. august 2026) tilføjede refactoring-code og debugging-code. 2026.2.2 (16. september 2026) tilføjede AI Agent Setup-widget’en og forbedrede hooks.

Understøtter skillet dottrace-analyze Unity-projekter?
Ja, fra version 2026.2.1 kan skillet også læse Unity-specifikke profileringssnapshots, ikke kun almindelige .NET-snapshots.

Kan jeg bruge Rider-skills sammen med Aspire og Azure?
Ja. Under Skills-panelet finder du separate, officielle Microsoft-repositories til .NET, Aspire og Azure-workflows, som du installerer på samme måde som JetBrains’ egne skills.

Kræver hooks en bestemt agent?
Kvalitetstjek-hooks er dokumenteret til at fungere med Claude Code og Codex. Brug af hooks med andre agenter er ikke officielt bekræftet, og du bør teste det selv, før du stoler på det i et team-workflow.

Er dette kun relevant for .NET-udviklere?
De fleste skills, refactoring-code, finding-tests og dottrace-analyze, er bygget til .NET, C++ og relaterede sprog i Rider. Bruger du IntelliJ IDEA, CLion, RubyMine eller DataGrip, får du en tilsvarende men sprogspecifik version af den samme skill-arkitektur.

JetBrains Rider: AI-Agenter I 12 Trin, 45 Min [2026]