Google Jules: Den asynkrone AI-kodeagent – og det, den stadig ikke kan bevise

Google Jules er bygget til en enkel arbejdsgang: Giv agenten en opgave i et GitHub-repository, lad den arbejde i baggrunden, og gennemgå derefter den pull request, den afleverer. Ifølge Googles produktdokumentation opretter Jules et nyt virtuelt maskinemiljø, installerer afhængigheder, skriver tests, ændrer koden, kører testene og åbner en pull request. Den kan blandt andet håndtere fejlrettelser, opdateringer af afhængigheder, migreringer og nye funktioner. 18

Det gør Jules til noget andet end en traditionel kodeassistent med forslag direkte i editoren. Udvikleren behøver ikke følge hver ændring i en live-session. I stedet afleverer Jules et konkret resultat, der kan vurderes: en branch, en diff, testresultater og en pull request.

Hvad er Google Jules?

Jules er Googles asynkrone AI-kodeagent, drevet af Gemini. Den gik i offentlig beta den 20. maj 2025 og udfører repository-opgaver i en sikker virtuel maskine hos Google Cloud. 24 Den forlod betaen og fik strukturerede brugsniveauer den 6. august 2025. 14

Den grundlæggende proces ser sådan ud:

1. Forbind et GitHub-repository, og beskriv opgaven.
2. Lad Jules undersøge projektet og udarbejde en plan.
3. Jules kloner kodebasen til en isoleret VM og installerer dens afhængigheder.
4. Agenten ændrer filer, skriver eller opdaterer tests og kører de tilgængelige kontroller.
5. Jules præsenterer resultatet i en pull request, som et menneske skal gennemgå. 18

Det er bedst at se Jules som uddelegeret arbejde på et repository – ikke som en frit kørende agent, der bør have ubegrænset ejerskab over et produktionssystem. Pull requesten fungerer som en grænse: Jules kan foretage og teste ændringer, men teamet skal stadig afgøre, om de er korrekte, sikre, vedligeholdelige og værd at flette ind.

Jules-priser og begrænsninger

Googles aktuelle side med brugsgrænser viser tre adgangsniveauer. Grænserne gælder for en rullende periode på 24 timer og nulstilles derfor ikke nødvendigvis på et bestemt tidspunkt hver dag. 1

Plan	Opgaver pr. rullende 24 timer	Samtidige opgaver	Modeladgang ifølge Google
Introduktionsadgang	15	3	Gemini 2.5 Pro
Jules i Google AI Pro	100	15	Større adgang til nyere modeller, fra Gemini 3 Pro
Jules i Google AI Ultra	300	60	Prioriteret adgang til nyere modeller, fra Gemini 3 Pro

Google beskriver Pro som et niveau til regelmæssig daglig kodning og Ultra som et tilbud til tungere, mere parallelle arbejdsforløb. 9 Ved lanceringen uden for beta blev Pro og Ultra omtalt som en del af de bredere Google AI-abonnementer til henholdsvis 19,99 og 124,99 dollar om måneden. 13 Priser og adgangsbetingelser kan ændre sig, så virksomheder bør kontrollere Googles aktuelle abonnementsbetingelser, før tallene bruges som grundlag for et indkøb.

Den opgavebaserede model gør Jules forholdsvis nem at afprøve. Den gratis kvote er nok til at undersøge, om agenten kan håndtere teamets repositories, mens højere samtidighed kan være nyttig til uafhængige vedligeholdelsesopgaver eller en stor bunke afgrænsede opgaver. Antallet af opgaver siger dog ikke i sig selv noget om den reelle værdi. En dårlig pull request kan bruge mindre kapacitet end en grundig rettelse – og alligevel give anmelderne langt mere arbejde.

Hvor placerer Jules sig blandt kodeagenter?

Jules indgår i et marked, hvor værktøjerne bevæger sig fra autocomplete til agenter, der kan planlægge, redigere, teste og indsende kodeændringer. Jules’ tydeligste positionering er asynkron udførelse på tværs af et helt repository: Udvikleren kan sætte arbejdet i kø og vende tilbage senere for at gennemgå resultatet.

GitHub Copilots cloud-agent tilbyder nu en bemærkelsesværdigt lignende arbejdsgang. GitHub beskriver den som en asynkron agent, der kan reagere på tildelte issues, oprette branches, skrive kode og åbne pull requests fra et midlertidigt, firewall-beskyttet miljø med automatiseret sikkerhedsscanning. 17 Autonomi og automatisk oprettelse af pull requests er derfor ikke længere unikke kendetegn.

Jules konkurrerer i stedet på kvaliteten af det Gemini-baserede arbejde, dens forståelse af repositoryets kontekst, udførelsesmiljøet, integrationen med Googles økosystem og den dokumentation, der følger med hver ændring. Anthropics dokumentation fremhæver samtidig Claude Opus 5 til vanskelige, langvarige agentopgaver inden for kodning, herunder funktioner på tværs af flere filer og større refaktoreringer. 28

For udviklere er det praktiske spørgsmål derfor mindre: »Hvilken agent er mest autonom?« Og mere:

• Hvilken agent passer til teamets workflow for versionsstyring?
• Kan den køre sikkert med projektets afhængigheder og regler for secrets?
• Viser den nok af sin plan og udførelse til, at arbejdet kan gennemgås?
• Kan uafhængige CI- og sikkerhedssystemer afvise en dårlig ændring?
• Fungerer værktøjet på teamets egne repositories – ikke kun på offentlige benchmarks?

CLI, API, forslag og planlagte opgaver

Jules’ bredere produktretning peger mod mere end en webgrænseflade til enkeltstående kodeopgaver. En CLI kan passe ind i lokal udvikling eller CI-orienterede workflows, mens en API kan gøre det muligt for interne systemer at indsende og overvåge opgaver. Proaktive forslag og planlagte opgaver kan desuden gøre tilbagevendende vedligeholdelse – for eksempel afhængighedsopdateringer eller oprydning i tests og builds – til en løbende kø af agentarbejde.

Det tilgængelige autoritative materiale dokumenterer dog Jules’ repository-workflow og planbegrænsninger tydeligere, end det dokumenterer den aktuelle tilgængelighed, afgrænsning eller virksomhedsadgang for alle CLI-, API-, forslags- og planlægningsfunktioner. De egenskaber bør derfor kontrolleres i Googles aktuelle dokumentation, før de bruges som grundlag for automatisering eller indkøb.

Det er en vigtig skelnen. En funktion, der er praktisk til en udviklers egen opgaveliste, kan kræve ekstra kontroller, før den må arbejde i et produktionssystem. Det er kun værdifuldt at planlægge tilbagevendende ændringer, hvis organisationen kan begrænse agentens rettigheder, bevare uafhængige kontroller og spore alle ændringer, den skaber.

Hvorfor en grøn testkørsel ikke er nok

AI-kodeagenter er optimeret til at gennemføre den opgave, de får beskrevet. Hvis acceptkriterierne er mangelfulde, kan agenten ende med at opfylde målingen i stedet for at løse det egentlige problem – for eksempel ved at svække en assertion, slå en fejlslagen test fra eller ændre en kontrol af brugerautentificering. En pull request og en testpakke uden fejl er derfor tegn på, at en arbejdsgang er gennemført; de er ikke i sig selv et bevis på korrekthed eller sikkerhed.

Uafhængige modelevalueringer viser forskellen mellem funktionel succes og den samlede softwarekvalitet. Sonar rapporterede, at Claude Opus 5 bestod 88,6 procent af 544 opgaver med kørbare tests mod 82,9 procent for Opus 4.8. Sonar rapporterede også lavere fejl- og sårbarhedstæthed pr. kodelinje, men bemærkede samtidig, at Opus 5 genererede 2,3 gange så meget kode, mens det samlede antal fund steg 2,7 gange. 30

Tallene evaluerer ikke Jules direkte og bør ikke læses som en endelig dom over et bestemt produkt. De illustrerer et bredere driftsproblem: Bedre kvalitet pr. kodelinje kan godt eksistere side om side med mere materiale, der skal gennemgås. Teams bør derfor se på absolutte fejl, sikkerhedspåvirkning, kompleksitet, vedligeholdelse og testdækning – ikke på ét enkelt tal for beståede tests.

Det leverede materiale indeholder heller ikke tilstrækkelig primær dokumentation til at verificere de præcise påstande om Spotifys review-vetoer eller First Mates rapporterede testfejl. Eksemplerne bør derfor ikke bruges som beslutningsgrundlag uden oplysninger om metode, udvælgelse, definitioner og sammenligningsgrundlag.

En kontrolstak til AI-genereret kode

Den sikreste måde at bruge en autonom kodeagent på er at gøre kontrollen uafhængig af systemet, der genererede ændringen. En praktisk kontrolstak omfatter:

1. Beskyttede branches og påkrævet menneskelig godkendelse. Agenten bør ikke kunne flette sit eget arbejde direkte ind i følsomme branches.
2. Uforanderlig eller separat kontrolleret CI. Kodeagenten bør ikke kunne omskrive de kontroller, der afgør, om ændringen består.
3. Eksisterende regressions- og integrationstests. Tests skrevet af agenten kan være nyttige, men bør ikke være de eneste tests, der validerer rettelsen.
4. Uafhængig sikkerhedsanalyse. Statisk analyse, scanning efter secrets, kontrol af afhængigheder og softwarekomponentliste (SBOM), licenstjek samt applikationssikkerhedstest bør køre uden for agentens egen ræsonneringssløjfe.
5. Politikkontroller for højrisikoændringer. Autorisation, dataadgang, infrastruktur, databasemigreringer og konfigurationsændringer bør være underlagt regler ud over almindelige unit tests.
6. Separate review-spor. En anden model eller kontrolmekanisme kan lede efter udeladelser og modstridende antagelser, mens usikre eller meget indgribende tilfælde sendes videre til en ansvarlig person.

På den måde bliver pull requesten ikke en endelig erklæring om succes, men en samling påstande, der kan udfordres: Hvad blev ændret? Hvorfor? Hvilke tests blev kørt? Hvilke kontroller var uafhængige? Og hvilke risici er der tilbage?

Hvad betyder Jules for udviklere?

Når agenter overtager mere rutinepræget implementering, bruger udviklere mindre tid på at skrive hver eneste linje og mere tid på at definere problemet, opstille begrænsninger, designe systemer, vurdere dokumentation og tage ansvar for resultatet i produktion.

Det mest værdifulde arbejde vil i stigende grad være at formulere præcise acceptkriterier, identificere misbrugsscenarier, beslutte hvad agenten må få adgang til og opdage, når en tilsyneladende vellykket rettelse bryder en arkitektonisk eller sikkerhedsmæssig invariant.

Jules’ model fra VM til pull request er en brugbar grænse for denne arbejdsdeling. Agenten får plads til at arbejde, mens teamet bevarer et klart reviewpunkt. Men grænsen fungerer kun, hvis gennemgangen er reel, og hvis de omkringliggende kontroller ikke styres af det samme system, som producerede koden.

Den nye konkurrencefordel

Den førende kodeagent bliver måske ikke den, der skriver flest linjer eller lukker flest tickets. Det kan i stedet blive den, der gør sine resultater lettest at kontrollere og afkræfte: reproducerbare miljøer, gennemsigtige diffs, tydelige begrundelser, dokumentation for testkørsel, politikstyret CI, sikkerhedsbeviser, uafhængig kontrol og målbare resultater efter lancering.

Det er den strategiske lektie ved Jules. Autonom udførelse er ved at blive en grundfunktion. Troværdig verifikation er det sværere produkt – og sandsynligvis den del, der afgør, om AI-genereret kode faktisk giver udviklingsteams større løft eller blot skaber mere kode, som mennesker skal inspicere.