Arbejdsgangen er bygget, så ændringen fortsat kan gennemgås af mennesker:

1. SonarQube-analysen identificerer et problem.
2. Agenten genererer et muligt kodefix.
3. Rettelsen anvendes i en isoleret sandkasse.
4. Sonars analyseværktøj kontrollerer, om det oprindelige problem er løst, og om ændringen har introduceret nye problemer.
5. Mislykkede forslag kan kasseres eller forsøges igen. Et forslag, der består kontrollen, tilbydes som en ændring eller pull request til udviklerens godkendelse.

Produktet angiver i øjeblikket Java, JavaScript, TypeScript og Python blandt de understøttede programmeringssprog. Integrationen er centreret omkring SonarQube Cloud og forbundne kodeplatforme. Dokumentationen beskriver projekter tilknyttet GitHub eller Azure DevOps, mens afhjælpning direkte i pull requests er tilgængelig for GitHub-tilknyttede projekter.

Den afgørende forskel fra en bred kodeassistent er derfor ikke bare, at agenten skriver kode. Den arbejder på problemer, SonarQube allerede har registreret, og kontrollerer den foreslåede løsning efter de samme analyseprincipper, før en udvikler ser den.

Fra NUS-forskning til et kommercielt Sonar-produkt

Teknologien begyndte som AutoCodeRover, en autonom AI-agentplatform udviklet af professor Abhik Roychoudhury og hans team ved NUS Computings forskningsgruppe Trustworthy and Secure Software. Systemet kombinerede store sprogmodeller med teknikker til kodesøgning og kunne bruges til blandt andet fejlfinding, afhjælpning af problemer og refaktorering.

Sonar købte AutoCodeRover-spinout-teknologien i februar 2025. Opkøbet gav virksomheden et forskningsbaseret fundament for at integrere agentbaseret programreparation i sin eksisterende platform til kodekvalitet og sikkerhed.

Forskningsbaggrunden rummer dog en vigtig nuance: Resultater på benchmarks og stabil drift i kommercielle miljøer er ikke det samme. NUS Computing oplyste, at AutoCodeRover placerede sig blandt de tre bedste systemer på SWE-bench, en benchmark baseret på virkelige softwareproblemer. Det peger på stærke forskningsresultater, men er ikke en garanti for, at alle problemer i produktionskode kan løses automatisk.

Testet i Singapore og lanceret globalt

Agenten blev udviklet og testet i Singapore sammen med ingeniører og Infocomm Media Development Authority (IMDA), Singapores myndighed for informations- og medieudvikling, før den globale lancering. Sonar oplyste, at SonarQube Remediation Agent blev lanceret globalt på ATxSummit 2026 i Singapore i maj 2026.

Singapore spiller dermed en central rolle i produktets historie: NUS-forskningen leverede teknologien til programreparation, Sonar tilpassede den til virksomheders arbejdsgange for kodekontrol, og samarbejdet med IMDA bidrog til at afprøve teknologien i en ramme med fokus på ansvarlig anvendelse af AI-genereret software.

Hvorfor automatiseret afhjælpning er vigtig i AI-æraen

AI-værktøjer kan øge tempoet i softwareudviklingen, men mere kode på kortere tid kan også betyde flere fejl, sikkerhedsproblemer og vedligeholdelsesopgaver, der skal gennemgås. Udfordringen gælder ikke kun kode skrevet af AI – menneskeskrevet kode kan indeholde de samme problemer.

SonarQube Remediation Agent er udviklet til at håndtere begge dele. Den kan bruge SonarQube-fund til at foreslå rettelser i kode, der er skrevet af mennesker eller AI-systemer, mens udviklerne fortsat beslutter, om ændringen skal accepteres.

Det menneskelige kontrolpunkt er vigtigt for virksomheder. Et verificeret forslag kan mindske gentagen fejlfinding og hjælpe teams med at nedbringe teknisk gæld. Men kontrollen er stadig begrænset af de problemer, SonarQube kan opdage, de understøttede sprog og integrationer samt kvaliteten af projektets tests og reviewproces.

Hvad værktøjet kan – og ikke kan – løse

Forretningsargumentet er delvist defensivt. Hvis AI-udvikling øger hastigheden, som software bliver produceret med, har virksomheder brug for metoder til at opdage fejl og sikkerhedssvagheder uden at skulle fordoble den manuelle kontrol. Singaporske medier har beskrevet agenten som et middel til at håndtere cybersikkerheds- og driftsrisici forbundet med AI-genereret kode, herunder risikoen for, at fejl kan føre til driftsproblemer.

Agenten er ikke en generel garanti for, at software er sikker. Modellen er mere afgrænset og praktisk: Find et konkret problem, generér en rettelse, analysér rettelsen uafhængigt, og lad udviklerne træffe den endelige beslutning. Værktøjet kan forkorte vejen fra fund til foreslået løsning, men det fjerner ikke behovet for test, kodegennemgang, sikkerhedskontroller eller governance.

Sonar oplyser, at agenten kun arbejder på verificerede SonarQube-fund, og har rapporteret en falsk positiv-rate på 3,2 procent for de problemer, agenten håndterer. Det er et leverandørrapporteret produktmål og bør derfor læses som dokumentation for Sonars egen arbejdsgang – ikke som en uafhængig garanti for nøjagtighed i alle kodebaser.

Skala og position på markedet

Sonar oplyser, at virksomhedens samlede platform analyserer 750 milliarder kodelinjer dagligt og bruges af mere end syv millioner udviklere, herunder organisationer, der repræsenterer 75 procent af Fortune 100. Tallene er virksomhedens egne oplysninger om Sonars bredere platform og må ikke forveksles med antallet af rettelser, som Remediation Agent selv udfører.

Sonar positionerer produktet som et lag til kodekontrol og afhjælpning i AI-understøttet udvikling. Det adskiller sig fra værktøjer, hvis primære opgave er at generere kode: Remediation Agent starter med registrerede problemer og validerer de foreslåede ændringer, før de sendes til udviklerens gennemgang.

Hvad betyder det i praksis for udviklingsteams?

Løftet kan kort opsummeres sådan:

AI foreslår en rettelse til et verificeret problem, og analysesystemet kontrollerer rettelsen, før en udvikler accepterer den.

For teams, der overvejer løsningen, er de praktiske spørgsmål vigtigere end selve AI-markedsføringen:

• Understøtter agenten projektets programmeringssprog og repository-integration?
• Er teamets SonarQube-fund tilstrækkeligt konkrete til at give brugbare rettelser?
• Kan udviklerne gennemgå de resulterende pull requests og teste funktionaliteten ud over den statiske analyse?
• Har organisationen kontrolmekanismer for sikkerhed, afhængigheder og AI-genererede ændringer?

Historien fra NUS til Sonar viser, hvordan forskning i automatisk programreparation kan flytte ind i en kommerciel udviklerarbejdsgang. Produktets reelle værdi vil dog i sidste ende afhænge mindre af nyheden i at generere kode og mere af kvaliteten af de identificerede problemer, pålideligheden i verificeringssløjfen og den grundighed, mennesker lægger i den afsluttende gennemgang.

Arbejdsgangen er bygget, så ændringen fortsat kan gennemgås af mennesker:

1. SonarQube-analysen identificerer et problem.
2. Agenten genererer et muligt kodefix.
3. Rettelsen anvendes i en isoleret sandkasse.
4. Sonars analyseværktøj kontrollerer, om det oprindelige problem er løst, og om ændringen har introduceret nye problemer.
5. Mislykkede forslag kan kasseres eller forsøges igen. Et forslag, der består kontrollen, tilbydes som en ændring eller pull request til udviklerens godkendelse.

Produktet angiver i øjeblikket Java, JavaScript, TypeScript og Python blandt de understøttede programmeringssprog. Integrationen er centreret omkring SonarQube Cloud og forbundne kodeplatforme. Dokumentationen beskriver projekter tilknyttet GitHub eller Azure DevOps, mens afhjælpning direkte i pull requests er tilgængelig for GitHub-tilknyttede projekter.

Den afgørende forskel fra en bred kodeassistent er derfor ikke bare, at agenten skriver kode. Den arbejder på problemer, SonarQube allerede har registreret, og kontrollerer den foreslåede løsning efter de samme analyseprincipper, før en udvikler ser den.

Fra NUS-forskning til et kommercielt Sonar-produkt

Teknologien begyndte som AutoCodeRover, en autonom AI-agentplatform udviklet af professor Abhik Roychoudhury og hans team ved NUS Computings forskningsgruppe Trustworthy and Secure Software. Systemet kombinerede store sprogmodeller med teknikker til kodesøgning og kunne bruges til blandt andet fejlfinding, afhjælpning af problemer og refaktorering.

Sonar købte AutoCodeRover-spinout-teknologien i februar 2025. Opkøbet gav virksomheden et forskningsbaseret fundament for at integrere agentbaseret programreparation i sin eksisterende platform til kodekvalitet og sikkerhed.

Forskningsbaggrunden rummer dog en vigtig nuance: Resultater på benchmarks og stabil drift i kommercielle miljøer er ikke det samme. NUS Computing oplyste, at AutoCodeRover placerede sig blandt de tre bedste systemer på SWE-bench, en benchmark baseret på virkelige softwareproblemer. Det peger på stærke forskningsresultater, men er ikke en garanti for, at alle problemer i produktionskode kan løses automatisk.

Testet i Singapore og lanceret globalt

Agenten blev udviklet og testet i Singapore sammen med ingeniører og Infocomm Media Development Authority (IMDA), Singapores myndighed for informations- og medieudvikling, før den globale lancering. Sonar oplyste, at SonarQube Remediation Agent blev lanceret globalt på ATxSummit 2026 i Singapore i maj 2026.

Singapore spiller dermed en central rolle i produktets historie: NUS-forskningen leverede teknologien til programreparation, Sonar tilpassede den til virksomheders arbejdsgange for kodekontrol, og samarbejdet med IMDA bidrog til at afprøve teknologien i en ramme med fokus på ansvarlig anvendelse af AI-genereret software.

Hvorfor automatiseret afhjælpning er vigtig i AI-æraen

AI-værktøjer kan øge tempoet i softwareudviklingen, men mere kode på kortere tid kan også betyde flere fejl, sikkerhedsproblemer og vedligeholdelsesopgaver, der skal gennemgås. Udfordringen gælder ikke kun kode skrevet af AI – menneskeskrevet kode kan indeholde de samme problemer.

SonarQube Remediation Agent er udviklet til at håndtere begge dele. Den kan bruge SonarQube-fund til at foreslå rettelser i kode, der er skrevet af mennesker eller AI-systemer, mens udviklerne fortsat beslutter, om ændringen skal accepteres.

Det menneskelige kontrolpunkt er vigtigt for virksomheder. Et verificeret forslag kan mindske gentagen fejlfinding og hjælpe teams med at nedbringe teknisk gæld. Men kontrollen er stadig begrænset af de problemer, SonarQube kan opdage, de understøttede sprog og integrationer samt kvaliteten af projektets tests og reviewproces.

Hvad værktøjet kan – og ikke kan – løse

Forretningsargumentet er delvist defensivt. Hvis AI-udvikling øger hastigheden, som software bliver produceret med, har virksomheder brug for metoder til at opdage fejl og sikkerhedssvagheder uden at skulle fordoble den manuelle kontrol. Singaporske medier har beskrevet agenten som et middel til at håndtere cybersikkerheds- og driftsrisici forbundet med AI-genereret kode, herunder risikoen for, at fejl kan føre til driftsproblemer.

Agenten er ikke en generel garanti for, at software er sikker. Modellen er mere afgrænset og praktisk: Find et konkret problem, generér en rettelse, analysér rettelsen uafhængigt, og lad udviklerne træffe den endelige beslutning. Værktøjet kan forkorte vejen fra fund til foreslået løsning, men det fjerner ikke behovet for test, kodegennemgang, sikkerhedskontroller eller governance.

Sonar oplyser, at agenten kun arbejder på verificerede SonarQube-fund, og har rapporteret en falsk positiv-rate på 3,2 procent for de problemer, agenten håndterer. Det er et leverandørrapporteret produktmål og bør derfor læses som dokumentation for Sonars egen arbejdsgang – ikke som en uafhængig garanti for nøjagtighed i alle kodebaser.

Skala og position på markedet

Sonar oplyser, at virksomhedens samlede platform analyserer 750 milliarder kodelinjer dagligt og bruges af mere end syv millioner udviklere, herunder organisationer, der repræsenterer 75 procent af Fortune 100. Tallene er virksomhedens egne oplysninger om Sonars bredere platform og må ikke forveksles med antallet af rettelser, som Remediation Agent selv udfører.

Sonar positionerer produktet som et lag til kodekontrol og afhjælpning i AI-understøttet udvikling. Det adskiller sig fra værktøjer, hvis primære opgave er at generere kode: Remediation Agent starter med registrerede problemer og validerer de foreslåede ændringer, før de sendes til udviklerens gennemgang.

Hvad betyder det i praksis for udviklingsteams?

Løftet kan kort opsummeres sådan:

AI foreslår en rettelse til et verificeret problem, og analysesystemet kontrollerer rettelsen, før en udvikler accepterer den.

For teams, der overvejer løsningen, er de praktiske spørgsmål vigtigere end selve AI-markedsføringen:

• Understøtter agenten projektets programmeringssprog og repository-integration?
• Er teamets SonarQube-fund tilstrækkeligt konkrete til at give brugbare rettelser?
• Kan udviklerne gennemgå de resulterende pull requests og teste funktionaliteten ud over den statiske analyse?
• Har organisationen kontrolmekanismer for sikkerhed, afhængigheder og AI-genererede ændringer?

Historien fra NUS til Sonar viser, hvordan forskning i automatisk programreparation kan flytte ind i en kommerciel udviklerarbejdsgang. Produktets reelle værdi vil dog i sidste ende afhænge mindre af nyheden i at generere kode og mere af kvaliteten af de identificerede problemer, pålideligheden i verificeringssløjfen og den grundighed, mennesker lægger i den afsluttende gennemgang.