Google Jules har på under et år bevæget sig fra et eksperiment i Google Labs til et af de mest omtalte navne blandt AI-kodeagenter. Agenten arbejder asynkront: du giver den en opgave, den kloner dit repository i en isoleret cloud-VM, skriver koden, kører testene og åbner en pull request, mens du render dig med noget andet. For udviklere i Danmark og resten af Norden, hvor GitHub og Google Cloud allerede er en fast del af mange teams’ værktøjskasse, er Jules et naturligt sted at starte, hvis I vil afprøve autonom AI-kodning uden at binde jer til en fuld agent-platform. Denne guide viser dig, trin for trin, hvordan du kommer i gang, hvad du skal passe på, og hvordan du bygger et helt lille projekt fra bunden med Jules som medudvikler.
Guiden kræver ingen forudgående erfaring med agentbaserede kodeværktøjer. Du finder konkrete kommandoer til både webgrænsefladen, den officielle CLI og REST-API’et, så du kan vælge den indgang, der passer bedst til dit team, uanset om I foretrækker at klikke jer igennem en browser eller styre det hele fra terminalen og jeres CI-pipeline.
Hvad er Google Jules, og hvorfor taler alle om det?
Jules er Googles asynkrone, agentbaserede kodeværktøj, bygget af teamet bag Google Labs. I modsætning til autocomplete-værktøjer som GitHub Copilot arbejder Jules ikke inde i din editor, mens du skriver. Den får i stedet en afgrænset opgave, f.eks. “ret rate limiting-fejlen på /api/search” eller “tilføj en test for parseQueryString-funktionen”, og løser den selvstændigt i baggrunden.
Google skriver det sådan i sin officielle lancering: “Jules is an asynchronous, agentic coding assistant that integrates directly with your existing repositories.” (Jules er en asynkron, agentbaseret kodeassistent, der integrerer direkte med dine eksisterende repositories.) Værktøjet gik i offentlig beta den 20. maj 2025 og blev alment tilgængeligt for alle den 6. august 2025. Siden har Google rullet en CLI, et alpha-API og adgang til flere Gemini-modeller ud.
Hver opgave kører i sin egen Ubuntu-baserede virtuelle maskine med Node.js, Python, Go, Java, Rust og Docker forudinstalleret. Jules klóner dit repo, læser din README og en eventuel AGENTS.md-fil, installerer afhængigheder, laver en plan, som du skal godkende, og retter først koden bagefter. Resultatet lander som en pull request, du kan gennemgå på helt normal vis. Det gør Jules velegnet til opgaver som fejlrettelser, testdækning, mindre refaktorering og dokumentation, altså de opgaver, teams ofte skubber foran sig.
Jules sammenlignet med GitHub Copilot, Cursor og Claude Code
Det vigtigste at forstå, før du sætter Jules op, er hvad den ikke er. Den er ikke en editor-udvidelse, og den erstatter ikke inline-forslag, mens du taster. Copilot, Cursor og Claude Code arbejder synkront: du sidder ved tastaturet, og forslagene dukker op med det samme. Jules arbejder modsat: du skriver en opgave, lukker laptoppen, og finder en færdig pull request, når du kommer tilbage.
| Værktøj | Arbejdsmåde | Model | Gratis niveau | Output |
|---|---|---|---|---|
| Google Jules | Asynkron agent i cloud-VM | Gemini 2.5 Pro / Gemini 3 Pro | 15 opgaver/dag, 3 samtidige | Pull request på GitHub |
| GitHub Copilot | Synkron, inline i editor | Flere modeller (GPT, Claude m.fl.) | Begrænset gratis niveau | Kodeforslag / chat |
| Cursor | Synkron editor + agent-tilstand | Flere modeller, valgfrit | Begrænset prøveperiode | Kodeforslag / agent-diffs |
| Claude Code | Terminal-agent, synkron/semi-async | Claude-modeller | Ingen fast gratis niveau | Terminal-output / commits |
Pointen er ikke, at det ene værktøj slår det andet. De fleste teams, vi taler med i den danske udviklerscene, bruger Copilot eller Cursor til det daglige arbejde og lægger de kedelige, veldefinerede opgaver over til en asynkron agent som Jules. Har I allerede en opsætning med GitHub Copilot eller Claude Code, kan Jules sagtens leve side om side med dem, fordi den kun rører de repositories, du eksplicit giver den adgang til.
Hvornår giver Jules mening, og hvornår gør det ikke?
Jules skinner mest på opgaver, der er kedelige at starte på, men lette at verificere bagefter. Tænk testdækning af eksisterende funktioner, opdatering af forældede afhængigheder, mindre bugfixes med en klar reproduktion, og dokumentation, der aldrig bliver skrevet, fordi ingen har tid. Fælles for dem er, at et menneske hurtigt kan tjekke, om resultatet er korrekt, uden at skulle forstå hele forretningslogikken fra bunden.
Omvendt er Jules et dårligt valg til opgaver, der kræver produktbeslutninger, ændringer i datamodeller med reelle brugerdata, eller arkitektur-valg, der påvirker hele systemet i årevis fremover. Her mangler agenten den kontekst, et menneske har fra møder, kundefeedback og tavs viden om, hvorfor systemet ser ud, som det gør. Brug tommelfingerreglen: kan du forklare opgaven fuldt ud i tre til fem sætninger uden at nævne “det afhænger af”, er det sandsynligvis en god kandidat til Jules.
Forudsætninger: dette skal du bruge, før du starter
Opsætningen kræver ikke meget lokalt udstyr, fordi selve kodearbejdet foregår i Googles cloud-VM’er. Men der er nogle konkrete krav, du skal have styr på, før du går i gang:
- En Google-konto (privat @gmail.com-konto, hvis du vil abonnere på Pro eller Ultra, da virksomheds- og Workspace-konti endnu ikke kan tegne betalte Jules-abonnementer direkte)
- En GitHub-konto med mindst ét repository, du har administratoradgang til
- Node.js 18 eller nyere lokalt, hvis du vil bruge Jules Tools CLI’en (Jules’ egne VM’er kører Node.js v22.16.0 og npm 11.4.2)
- En moderne browser til jules.google.com (Chrome, Firefox eller Edge, nyeste version)
- Grundlæggende kendskab til Git og pull request-workflowet på GitHub
- Valgfrit: en API-nøgle fra Jules’ indstillinger, hvis du vil kalde det alpha-REST-API
Har du et repository med en usædvanlig build-opsætning, monorepo eller flere sprog blandet sammen, bør du afsætte lidt ekstra tid til trin 7 nedenfor, hvor vi konfigurerer et setup-script. Jules kan selv gætte sig til simple opsætninger, men komplekse projekter kører markant mere stabilt med et eksplicit script.
Hvad kører der i Jules’ virtuelle maskiner?
Det er værd at kende det tekniske fundament, før du læner dig for meget op ad agentens gæt. Hver opgave starter en frisk Ubuntu Linux-VM, og Google holder en offentlig liste over, hvilke versioner der er installeret på ethvert givet tidspunkt. Kør du et projekt, der kræver en bestemt sprogversion, bør du tjekke denne liste eller eksplicit låse versionen i dit setup-script, fordi Jules’ standardmiljø opdateres løbende.
| Værktøj | Version i Jules’ VM |
|---|---|
| Python | 3.12.11 |
| Node.js | v22.16.0 (også v18 og v20 tilgængelig via nvm) |
| Go | 1.24.3 |
| Rust | 1.87.0 |
| Java (OpenJDK) | 21.0.7 |
| Docker | 28.2.2 med Docker Compose v2.36.2 |
Bemærk, at listen ovenfor er et øjebliksbillede, og Google opdaterer den ofte. Har dit projekt en hård afhængighed af en specifik patch-version, f.eks. en bestemt Python-version til et machine learning-projekt, er det tryggest at pin’e versionen eksplicit i dit setup-script frem for at stole blindt på, hvad VM’en tilfældigvis kører den dag, opgaven starter.
Ud over sprogene selv er en række almindelige udviklerværktøjer forudinstalleret, blandt andet ESLint, Prettier, pytest, Poetry, Maven, Gradle og standard C/C++-kompilere som gcc og clang. Det betyder, at de fleste web- og backend-projekter kan køre uden nogen ekstra installation overhovedet, mens mere specialiserede stacks, f.eks. embedded-udvikling eller GPU-tunge machine learning-pipelines, sandsynligvis kræver et tilpasset setup-script for at fungere pålideligt.
Trin 1: Opret adgang på jules.google.com
Gå til jules.google.com og log ind med din Google-konto. Første gang du logger ind, bliver du bedt om at acceptere en privatlivserklæring. Det er en engangshandling, og du behøver ikke gøre det igen, medmindre Google opdaterer vilkårene markant. Bemærk, at Jules stadig er markeret som eksperimentel, så forvent løbende ændringer i grænsefladen fra måned til måned.
Når du er logget ind, lander du på et tomt dashboard uden forbundne repositories. Det er meningen. Næste trin handler om at give Jules adgang til den kode, den skal arbejde med.
Trin 2: Forbind din GitHub-konto
Klik på “Connect to GitHub account” i dashboardet. Du bliver sendt gennem GitHubs almindelige OAuth-login, hvor du vælger, om Jules skal have adgang til alle dine repositories eller kun udvalgte. Vi anbefaler, at du starter med ét eller to repositories, gerne et sideprojekt uden produktionstrafik, indtil du har en fornemmelse for, hvordan agenten arbejder.
Efter godkendelsen bliver du sendt tilbage til Jules, hvor en repo-vælger nu viser dine forbundne projekter. Virker redirect ikke, er den mest almindelige fejl en blokeret pop-up eller en cachet session, og et almindeligt sideopdatering løser som regel problemet. Vil du senere give adgang til flere repositories, går du ind på github.com, klikker på din profil, vælger Settings, Applications, finder “Google Labs Jules” og tilføjer flere repositories under “Repository access”.
Trin 3: Vælg repository og branch til din opgave
Vælg det repository, du vil have Jules til at arbejde i, fra dropdown-menuen. Som standard vælger Jules din hovedgren (typisk main eller master), men du kan pege agenten mod en anden branch, hvis du f.eks. arbejder i en feature-branch, hvor teamet allerede har lagt grundarbejdet.
Hvert kald til Jules starter sin egen isolerede VM med sit eget sæt logfiler, miljøopsætning og kodeændringer. Det betyder, at du roligt kan starte flere opgaver samtidig i samme repository, uden at de forstyrrer hinanden. Det gratis niveau tillader op til tre samtidige opgaver, mens Pro og Ultra hæver loftet betydeligt, som vi kommer ind på i afsnittet om priser.
Trin 4: Skriv din første opgave til Jules
Nu kommer den vigtigste del af hele opsætningen: prompten. Jules fungerer bedst med konkrete, afgrænsede opgaver frem for brede ønsker som “gør koden bedre”. Skriv i stedet noget, du selv kunne have skrevet i en GitHub-issue til en kollega.
Tilføj en test for funktionen parseQueryString i utils.js.
Testen skal dække tomme strenge, flere query-parametre adskilt
med "&" og URL-encodede specialtegn. Brug det eksisterende
testframework i projektet, og placer testen i mappen /tests.Klik derefter på “Give me a plan”. Jules læser din kode, dine eksisterende tests og en eventuel AGENTS.md-fil, og genererer en trinvis plan for, hvordan den vil løse opgaven. Planen bliver ikke udført automatisk, den venter på din godkendelse i næste trin.
Trin 5: Gennemgå og godkend planen
Dette trin er det, der adskiller Jules fra rene automatiseringsscripts. Før agenten rører en eneste linje kode, får du planen at se som en liste af konkrete handlinger, f.eks. “opret testfil”, “importer eksisterende utils-modul”, “kør testsuiten og verificer resultatet”. Læs planen grundigt. Er den for bred, for smal, eller misforstår den konteksten, kan du afvise den og omformulere din oprindelige opgave i stedet for at lade Jules gætte videre.
Når du godkender planen, starter Jules VM’en, kloner koden, installerer afhængigheder og begynder arbejdet. Du kan roligt lukke browserfanen her, fordi Jules arbejder videre i baggrunden uanset om du er til stede.
Et typisk output fra planlægningstrinnet, for opgaven med parseQueryString-testen, ser nogenlunde sådan ud, når Jules har analyseret repositoriet:
Plan:
1. Aabn utils.js og analyser parseQueryString-funktionen
2. Identificer det eksisterende testframework (Jest fundet i package.json)
3. Opret tests/utils.test.js med tre testcases:
- tom streng returnerer tomt objekt
- flere parametre adskilt med "&" parses korrekt
- URL-encodede tegn afkodes korrekt
4. Koer "npm test" og bekraeft at alle tests bestaar
5. Opret pull request med aendringerne
Estimeret tid: 3-6 minutterTrin 6: Tilføj en AGENTS.md-fil til dit repository
Jules leder automatisk efter en fil ved navn AGENTS.md i roden af dit repository. Filen beskriver, hvordan dit projekt er bygget op: hvilke moduler der findes, hvilke konventioner der gælder, og hvordan man kører tests eller bygger projektet. Jo bedre denne fil er, jo mere præcise bliver Jules’ planer og kodeændringer.
# AGENTS.md
## Projektoversigt
Node.js-API til en ordreservice. Bruger Express og PostgreSQL.
## Struktur
- /src/routes - HTTP-endpoints
- /src/services - forretningslogik
- /tests - Jest-tests, kør med "npm test"
## Konventioner
- Brug async/await, ikke callbacks
- Alle nye endpoints skal have en tilhørende test
- Kør "npm run lint" før commit
## Kør lokalt
npm install
npm run devBehandl AGENTS.md som en levende del af projektet, ikke et engangsdokument. Google fremhæver selv i sin dokumentation, at filen både hjælper Jules og menneskelige teammedlemmer med at arbejde mere effektivt i repositoriet, så det er en investering, der betaler sig tilbage uden for selve agenten.
Trin 7: Konfigurer miljøet med et setup-script
For simple projekter kan Jules selv regne ud, hvordan miljøet skal sættes op, ved at kigge på README og pakkefiler. For projekter med usædvanlige build-trin, private pakke-registre eller flere services, der skal startes samtidig, bør du levere et eksplicit setup-script. Uden det er den hyppigste årsag til fejlede opgaver netop et mangelfuldt eller manglende opsætningsscript.
#!/bin/bash
set -e
echo "Installerer afhaengigheder..."
npm ci
echo "Saetter miljoevariabler..."
export NODE_ENV=test
export DATABASE_URL="postgres://localhost:5432/test_db"
echo "Starter testdatabase..."
docker compose up -d db
sleep 5
echo "Klar til at koere tests"
npm testUndgå at lægge langvarige processer som “npm run dev” ind i setup-scriptet. Jules’ dokumentation peger direkte på dette som en af de mest almindelige fejlkilder, fordi en proces, der aldrig afslutter sig selv, blokerer resten af opgaven fra at køre færdig.
Trin 8: Installer og brug Jules Tools CLI’en
Vil du styre Jules fra terminalen i stedet for browseren, kan du installere den officielle CLI, Jules Tools. Den fungerer som et kommandolinje-dashboard, hvor du kan starte opgaver, følge fremdrift og administrere sessioner uden at skifte til browseren.
# Installer CLI'en globalt
npm install -g @google/jules
# Log ind med din Google-konto
jules login
# Se generel hjaelp
jules help
# Se hjaelp til en specifik kommando
jules remote --help
# Skift til lyst tema i terminalen
jules --theme lightKommandoen jules login åbner et browservindue, hvor du gennemfører den samme Google-godkendelse som på jules.google.com. Er du på en server uden browser, f.eks. i en CI-pipeline, skal du i stedet bruge API-nøgler, som vi dækker i næste trin. Log ud igen med jules logout, hvis du deler maskinen med andre.
Trin 9: Automatiser opgaver med Jules’ REST-API
Jules tilbyder også et REST-API, som Google selv beskriver som en mulighed for at automatisere og forbedre softwareudviklingens livscyklus ved at bygge egne workflows omkring agenten. Bemærk, at API’et stadig er i alpha, så specifikationer og nøgler kan ændre sig, mens Google arbejder mod en stabil version.
Generer først en API-nøgle under Indstillinger i Jules’ webapp (du kan have op til tre nøgler ad gangen). Brug herefter nøglen i headeren x-goog-api-key på dine kald:
# List dine forbundne kilder (repositories)
curl -H "x-goog-api-key: $JULES_API_KEY" \
https://jules.googleapis.com/v1alpha/sources
# Opret en ny session/opgave
curl 'https://jules.googleapis.com/v1alpha/sessions' \
-X POST \
-H "Content-Type: application/json" \
-H "x-goog-api-key: $JULES_API_KEY" \
-d '{
"prompt": "Tilfoej en test for parseQueryString-funktionen",
"sourceContext": {
"source": "sources/github/dit-brugernavn/dit-repo",
"githubRepoContext": { "startingBranch": "main" }
},
"automationMode": "AUTO_CREATE_PR",
"title": "Test af parseQueryString"
}'Feltet automationMode er valgfrit. Sætter du det ikke, opretter Jules ikke automatisk en pull request, men venter på, at du selv trigger det. Du kan efterfølgende polle status på sessionen med GetSession eller ListSessions for at se, om opgaven er færdig, og om der er en tilhørende PR at gennemgå. Opbevar altid din API-nøgle uden for versioneret kode, da Google automatisk deaktiverer nøgler, der findes eksponeret offentligt.
API’et bliver særligt nyttigt, når I vil koble Jules til værktøjer, Google ikke selv har bygget en færdig integration til. Modtager teamet f.eks. supportsager i et internt system, kan et lille script omdanne udvalgte sager til Jules-sessioner automatisk, så en fejlrapport bliver til et konkret forslag til rettelse, uden at nogen manuelt skal kopiere teksten over i webgrænsefladen. Husk blot, at automationMode: AUTO_CREATE_PR betyder, at pull requesten oprettes uden menneskelig godkendelse af selve planen først, så brug den indstilling med omtanke i repositories med høj risiko.
Trin 10: Opsæt planlagte opgaver til løbende vedligeholdelse
Ud over enkeltstående opgaver kan du gøre en opgave tilbagevendende. Klik på dropdown-menuen “Planning” i opgavefeltet, vælg “Scheduled Task”, og angiv en kadence som dagligt eller ugentligt. Google har selv lagt tre skabeloner ind, hentet fra deres interne designværktøj Stitch: en performance-fokuseret agent, der løbende leder efter optimeringer, en UX-agent, der finpudser tilgængelighed, og en sikkerhedsagent, der scanner for sårbarheder.
Planlagte opgaver dukker op under fanen “Scheduled” i dit dashboard, hvor du kan se, hvornår opgaven sidst kørte, og hvornår den kører næste gang. Vær opmærksom på, at du i skrivende stund ikke kan redigere en planlagt opgave direkte, du skal slette den og oprette en ny, hvis kadencen eller prompten skal ændres.
Trin 11: Forbind integrationer og CI/CD-pipelines
Jules kan kobles til dine deployment-pipelines, så den selv opdager build-fejl og læser logfiler uden manuel indblanding. Alle integrationer er som udgangspunkt read-only, og API-nøgler krypteres og deles aldrig mellem sessioner, ifølge Googles egen dokumentation. Det betyder, at Jules kan vågne op og reagere på en webhook, f.eks. et fejlet build, i stedet for kun at reagere på en prompt, du selv skriver.
Har I allerede et setup med MCP-servere til andre AI-assistenter, er det værd at holde adgangsrettighederne adskilt. Giv Jules kun adgang til de repositories og integrationer, opgaven reelt kræver, i stedet for at genbruge en bred adgangstoken på tværs af flere agenter.
Sikkerhed: hvad sker der med din kode og dine hemmeligheder?
Det naturlige spørgsmål, når en agent får skrive-adgang til jeres repositories, er hvad der egentlig sker med koden undervejs. Hver Jules-opgave kører isoleret i sin egen kortlivede VM, som destrueres, når opgaven er færdig eller slettet. Det betyder, at én sessions filer og miljøvariabler ikke deles med en anden session, heller ikke hvis begge arbejder i samme repository samtidig.
På integrationssiden gælder samme princip: adgang er som udgangspunkt read-only, medmindre du eksplicit giver Jules lov til at skrive, og API-nøgler til tredjepartsværktøjer opbevares krypteret. Vil du minimere risikoen yderligere, kan du starte med at give Jules adgang til et testrepository uden følsomme data eller produktionshemmeligheder, indtil I har opbygget tillid til, hvordan agenten opfører sig i praksis. Har koden brug for adgang til rigtige API-nøgler under testkørsler, bør de altid injiceres som miljøvariabler i setup-scriptet, aldrig hardkodet i selve prompten eller i AGENTS.md, da begge dele kan ende synligt i logfiler.
Det er også værd at huske, at Jules stadig er markeret som eksperimentel teknologi. Betragt den derfor som et ekstra sæt hænder, der arbejder under opsyn, ikke som en erstatning for jeres almindelige code review-proces. Kør statisk analyse og sikkerhedsscanning på Jules’ pull requests, præcis som I ville gøre med kode skrevet af et nyt teammedlem, indtil I har data nok til at vurdere, hvor pålidelig agenten er i netop jeres kodebase.
Trin 12: Gennemgå, test og merge pull requesten
Når Jules er færdig, lander ændringerne som en almindelig pull request i dit GitHub-repository, præcis som hvis en kollega havde skrevet den. Behandl den også sådan. Læs diffen linje for linje, kør testene lokalt eller i jeres CI, og vurder om ændringerne rammer den kontekst, I faktisk har i produktionen, som Jules ikke nødvendigvis kender til.
Er du ikke tilfreds med resultatet, kan du bede Jules om at rette specifikke dele af koden direkte i sessionen, i stedet for at starte helt forfra. Er opgaven kørt fast eller løber løbsk, kan du pause den fra opgavevisningen, eller slette den permanent, hvis den ikke længere er relevant. Aktiver browser-notifikationer under Indstillinger, så du får besked, når en opgave er færdig eller har brug for din godkendelse, i stedet for at skulle tjekke ind manuelt.
Priser: gratis niveau, Pro og Ultra sammenlignet
Jules har tre niveauer, og alle deler adgang til de samme Gemini-modeller, blot med forskellige loft over antal opgaver. Betalte abonnementer sælges gennem Googles AI-abonnementer og er ved lanceringen kun tilgængelige for private @gmail.com-konti, mens Workspace- og virksomhedskonti henvises til en separat interesseformular hos Google.
| Niveau | Pris | Opgaver/24 timer | Samtidige opgaver | Modeladgang |
|---|---|---|---|---|
| Jules (gratis) | 0 kr. | 15 | 3 | Gemini 2.5 Pro |
| Jules i Pro | Følger Google AI Pro-abonnementet (ca. 19,99 USD/md.) | 100 | 15 | Højere adgang til Gemini 3 Pro |
| Jules i Ultra | Følger Google AI Ultra-abonnementet (fra ca. 124,99 USD/md.) | 300 | 60 | Prioriteret adgang til Gemini 3 Pro |
Ud over de tre standardniveauer indførte Google i maj 2026 separate udviklerorienterede Ultra-tilvalg til power users med markant flere opgaver om dagen, prissat omkring 100 og 200 USD om måneden, målrettet teams der kører agent-tunge workflows i stor skala. Bruges Jules kun til at teste konceptet af, er det gratis niveau med 15 daglige opgaver rigeligt til at danne sig et indtryk, før man betaler for mere kapacitet.
Værd at bemærke er, at prisen ikke stiger lineært med antallet af opgaver. Springet fra gratis til Pro giver en femdobling af antallet af daglige opgaver for prisen af et almindeligt streamingabonnement, mens springet videre til Ultra primært giver mening, hvis flere teammedlemmer deler samme kvote, eller hvis I kører mange planlagte opgaver oven i det daglige arbejde. Regn på jeres reelle forbrug, før I opgraderer, i stedet for automatisk at vælge det dyreste niveau.
Byg et komplet mini-projekt med Jules fra bund til pull request
Teori er godt, men den bedste måde at forstå Jules på er at se hele forløbet i praksis. Nedenfor bygger vi et lille, men helt funktionsdygtigt projekt fra en tom mappe til to merged pull requests, uden at skrive en eneste linje kode selv. Formålet er ikke at vise, at Jules kan erstatte en udvikler, men at vise realistisk, hvor meget der kan opnås med velformulerede opgaver og et par godkendte planer.
Lad os samle det hele i et konkret eksempel: en lille Node.js-service, der validerer e-mailadresser via et API-endpoint, bygget næsten udelukkende gennem Jules.
- Opret et nyt, tomt GitHub-repository kaldet “email-validator-api” og giv Jules adgang til det under repo-vælgeren
- Skriv en kort README.md med formålet: “Express-API med endpointet POST /validate, der returnerer om en e-mail er gyldig”
- Send den første opgave til Jules: “Opsæt et Express-projekt med endpointet POST /validate. Body er { email: string }. Returner { valid: boolean }. Brug et simpelt regex til validering, og tilføj tre tests med Jest.”
- Godkend planen, og lad Jules oprette package.json, server.js og testfilerne i sin VM
- Tilføj derefter en AGENTS.md, når det første udkast er landet, så fremtidige opgaver kender konventionerne
- Send en opfølgende opgave: “Tilføj rate limiting på 10 requests i minuttet pr. IP-adresse til /validate-endpointet”
- Gennemgå de to pull requests, kør “npm test” lokalt, og merge dem enkeltvis
// server.js (eksempel paa output fra Jules' foerste opgave)
const express = require('express');
const app = express();
app.use(express.json());
const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
app.post('/validate', (req, res) => {
const { email } = req.body;
const valid = typeof email === 'string' && EMAIL_REGEX.test(email);
res.json({ valid });
});
app.listen(3000, () => console.log('Server koerer paa port 3000'));Hele forløbet, fra første prompt til to merged pull requests, tager typisk mellem 20 og 45 minutter, afhængigt af hvor travlt der er på Googles infrastruktur, og hvor kompleks opgaven er. Det giver et realistisk billede af, hvor meget tid I reelt sparer sammenlignet med at skrive samme kode manuelt, samtidig med at I stadig bevarer det sidste ord i hver eneste pull request.
5 almindelige faldgruber, når du bruger Jules
De fleste dårlige oplevelser med Jules skyldes ikke agenten selv, men hvordan den bliver brugt. Nedenfor er de faldgruber, vi oftest ser hos teams, der lige er begyndt at eksperimentere med asynkrone kodeagenter, uanset om det er Jules eller et konkurrerende værktøj.
- For brede prompts. “Forbedre koden” giver en vag plan og et resultat, der sjældent rammer det, du faktisk mente. Skriv opgaver, som en ny kollega kunne løse ud fra teksten alene.
- Manglende AGENTS.md i komplekse repos. Uden konteksten om projektstruktur og konventioner gætter Jules sig frem, hvilket ofte giver kode, der virker, men ikke følger jeres stil.
- Langvarige processer i setup-scriptet. Kommandoer som “npm run dev”, der aldrig afslutter sig selv, blokerer resten af opgaven og ender som en fejlet task.
- For bred GitHub-adgang fra start. At give Jules adgang til alle repositories med det samme øger overfladen for fejl. Start smalt, og udvid adgangen, når I stoler på resultaterne.
- At merge uden at læse diffen. Jules leverer ofte solid kode, men den kender ikke jeres produktionskontekst, kundedata eller uskrevne regler. Behandl hver PR som fra en ny udvikler, ikke en garanteret facit.
Fejlfinding: 8 typiske problemer og løsninger
Selv med en velskrevet AGENTS.md og et solidt setup-script vil du før eller siden løbe ind i en fejlet opgave. Skemaet nedenfor dækker de problemer, der oftest bliver rapporteret af nye brugere, og hvordan du løser dem uden at skulle grave dig gennem hele dokumentationen hver gang.
| Problem | Sandsynlig årsag | Løsning |
|---|---|---|
| Redirect fra GitHub virker ikke efter login | Blokeret pop-up eller cachet session | Genindlæs siden manuelt, eller prøv i et nyt browservindue |
| Opgave fejler under miljøopsætning | Manglende eller mangelfuldt setup-script | Tilføj et eksplicit script, der installerer afhængigheder og sætter miljøvariabler |
| Task hænger på “installing dependencies” | Langsom pakkeopløsning eller netværksudsving | Jules forsøger automatisk igen, og fejler det gentagne gange, bør du forenkle afhængighedstræet |
| Planen matcher ikke det, du bad om | For vag eller for bred prompt | Afvis planen, og omformulér opgaven mere konkret og afgrænset |
| API-kald svarer 401/403 | Forkert eller udløbet API-nøgle | Generér en ny nøgle under Indstillinger, og tjek headeren x-goog-api-key |
| Kan ikke tegne Pro eller Ultra | Workspace- eller virksomhedskonto | Brug en privat @gmail.com-konto, eller udfyld Googles interesseformular for erhverv |
| Ingen notifikationer ved færdig opgave | Browser-notifikationer er ikke aktiveret | Aktivér dem under Indstillinger, eller tjek Scheduled/Task-fanen manuelt |
| Uventet build-fejl i pull requesten | Repoet har en ikke-standard build-proces, Jules ikke kunne gennemskue | Tilføj build-trinnene eksplicit i AGENTS.md eller setup-scriptet |
Avancerede tips til erfarne brugere
Når de grundlæggende trin sidder fast, er der flere måder at presse mere værdi ud af Jules. Kør flere afgrænsede opgaver parallelt i stedet for én stor opgave. Jules håndterer samtidige sessioner fint inden for jeres plangrænse, og mindre opgaver giver bedre planer og lettere pull requests at gennemgå. Del store opgaver op, ligesom I ville gøre med et almindeligt GitHub-issue: én PR til selve funktionaliteten, én til testene, og eventuelt en tredje til dokumentationen, i stedet for at bede om det hele i én enkelt prompt.
Brug scheduled tasks til det, teams typisk udskyder: en ugentlig sikkerhedsgennemgang, en performance-optimering eller en oprydning i forældede afhængigheder. Kombinér det gerne med jeres eksisterende CI, så en fejlet build automatisk trigger en Jules-session, der undersøger logfilerne, i stedet for at et menneske skal opdage fejlen manuelt om morgenen. Har I allerede erfaring med agent-baserede værktøjer som OpenCode CLI eller Warp AI Agent CLI, vil arbejdsgangen med at skrive klare, afgrænsede prompts føles velkendt, selvom Jules kører sine opgaver i skyen frem for lokalt.
Endelig: brug API’et til at bygge jeres egen kø af opgaver, f.eks. ud fra åbne GitHub-issues tagget “good first issue” eller “tech-debt”. Google beskriver selv ambitionen med API’et sådan: “Jules helps developers go from idea to working code faster by assisting with tasks across the software development workflow: generating code, fixing bugs, writing tests, improving performance and more.” (Jules hjælper udviklere med hurtigere at gå fra idé til fungerende kode ved at assistere med opgaver på tværs af softwareudviklingens livscyklus: at generere kode, rette fejl, skrive tests, forbedre performance og mere.) Byg den kø forsigtigt, og lad et menneske stadig godkende hver eneste plan, indtil I har måneders erfaring med, hvor Jules er stærk, og hvor den fejler.
Brug community-prompts til at komme hurtigere i gang
Googles egen dokumentation peger nye brugere mod et repository kaldet “Jules Awesome Prompts”, en samling af rigtige prompts fra andre udviklere, sorteret efter opgavetype som fejlrettelse, dokumentation og testdækning. Er du i tvivl om, hvordan en god Jules-opgave formuleres, er det ofte hurtigere at læse fem eksempler fra samlingen end at gætte sig frem selv. Tilpas dem til jeres eget kodebase-sprog og konventioner, og gem de bedste formuleringer i jeres egen interne playbook, så nye teammedlemmer ikke skal opfinde den dybe tallerken hver gang de starter en opgave.
Ofte stillede spørgsmål om Google Jules
Er Google Jules helt gratis at bruge?
Ja, det gratis niveau giver 15 opgaver om dagen med op til tre samtidige opgaver og adgang til Gemini 2.5 Pro. Det kræver kun en Google-konto og en forbundet GitHub-konto, ingen betalingsoplysninger.
Kan Jules arbejde med private repositories?
Ja. Du styrer selv, hvilke repositories Jules får adgang til gennem GitHubs OAuth-flow, uanset om de er offentlige eller private. Adgangen kan til enhver tid udvides eller trækkes tilbage fra din GitHub-kontoindstillinger.
Understøtter Jules andre versionsstyringssystemer end GitHub?
Nej, i den nuværende version arbejder Jules udelukkende med repositories, du eksplicit har givet adgang til via GitHub. Google har antydet planer om at understøtte flere systemer på sigt, men der er ingen bekræftet dato for det.
Hvor lang tid tager en typisk Jules-opgave?
Det varierer meget efter opgavens kompleksitet og belastningen på Googles infrastruktur, men enkle opgaver som en fejlrettelse eller en enkelt test tager typisk et sted mellem få minutter og en halv time fra godkendt plan til færdig pull request.
Kan jeg redigere en planlagt opgave, når den først er oprettet?
Nej, ifølge Googles egen dokumentation er det ikke muligt at redigere en eksisterende scheduled task. Du skal slette den og oprette en ny med den ønskede kadence eller prompt.
Er Jules’ REST-API stabilt nok til produktion?
Google klassificerer selv API’et som en alpha-udgivelse, hvilket betyder, at specifikationer, nøgleformater og adfærd kan ændre sig, mens de arbejder mod en stabil version. Byg gerne prototyper og interne værktøjer på det, men undgå at gøre kritiske produktionsflows fuldstændig afhængige af det endnu.
Kan Workspace- eller virksomhedskonti bruge betalte Jules-planer?
Ikke direkte i skrivende stund. Betalte Jules-planer sælges gennem Google AI Pro og Google AI Ultra, som ved lancering kun understøtter private @gmail.com-konti. Virksomheder med behov for større kapacitet henvises til en separat interesseformular hos Google.
Hvad sker der, hvis jeg bruger alle mine opgaver for dagen?
Når du rammer dit daglige loft, kan du ikke starte nye opgaver, før det rullende 24-timers vindue nulstiller sig. Jules viser i så fald en opfordring til at opgradere til et højere niveau, hvis du har brug for flere opgaver med det samme.
