Google Jules: Der asynchrone KI-Coding-Agent im Überblick

Google Jules folgt einem einfachen Prinzip: Aufgabe aus einem GitHub-Repository übergeben, den Agenten im Hintergrund arbeiten lassen und anschließend den Pull Request prüfen. Laut Googles Produktdokumentation erstellt Jules eine frische virtuelle Umgebung, installiert Abhängigkeiten, schreibt Tests, verändert den Code, führt die verfügbaren Prüfungen aus und eröffnet einen Pull Request. Zu den vorgesehenen Aufgaben gehören Fehlerbehebungen, Updates von Abhängigkeiten, Migrationen und neue Funktionen. 18

Damit unterscheidet sich Jules von einem klassischen Autovervollständigungs-Assistenten. Entwicklerinnen und Entwickler müssen nicht während jeder Änderung in einer Live-Coding-Sitzung bleiben. Stattdessen liefert Jules ein prüfbares Ergebnis: Branch, Diff, Testergebnisse und Pull Request.

Was ist Google Jules?

Jules ist Googles asynchroner KI-Coding-Agent, der von Gemini angetrieben wird. Am 20. Mai 2025 startete er in der öffentlichen Beta-Phase; ausgeführt wurden Aufgaben auf Repository-Ebene in einer geschützten virtuellen Maschine in der Google Cloud. 24 Am 6. August 2025 beendete Google die Beta und führte strukturierte Nutzungstarife ein. 14

Der grundlegende Ablauf sieht so aus:

1. Ein GitHub-Repository verbinden und die Aufgabe beschreiben.
2. Jules das Projekt untersuchen und einen Plan erstellen lassen.
3. Jules klont die Codebasis in eine isolierte VM und installiert die benötigten Abhängigkeiten.
4. Der Agent verändert Dateien, schreibt oder aktualisiert Tests und führt die verfügbaren Prüfungen aus.
5. Jules stellt die Änderungen in einem Pull Request zur menschlichen Prüfung bereit. 18

Am treffendsten lässt sich das als delegierte Arbeit am Repository beschreiben – nicht als uneingeschränkte autonome Kontrolle über ein Produktivsystem. Der Pull Request bildet eine wichtige Grenze: Jules kann Änderungen vornehmen und testen, aber ein Team muss weiterhin entscheiden, ob sie fachlich richtig, sicher, wartbar und für den Merge geeignet sind.

Preise und Aufgabenlimits

Googles aktuelle Nutzungsseite nennt drei Zugangsstufen. Die Limits gelten für ein rollierendes 24-Stunden-Fenster und werden daher nicht zwingend zu einer festen Uhrzeit täglich zurückgesetzt. 1

Tarif	Aufgaben innerhalb von 24 Stunden	Parallele Aufgaben	Von Google beschriebener Modellzugang
Einführungstarif	15	3	Gemini 2.5 Pro
Jules in Google AI Pro	100	15	Höherer Zugang zu neuen Modellen, beginnend mit Gemini 3 Pro
Jules in Google AI Ultra	300	60	Bevorzugter Zugang zu neuen Modellen, beginnend mit Gemini 3 Pro

Google positioniert Pro für regelmäßige tägliche Entwicklungsarbeit und Ultra für umfangreichere, stärker parallelisierte Workloads. 9 Zum Start der kostenpflichtigen Stufen im August 2025 wurden Google AI Pro und Google AI Ultra mit 19,99 beziehungsweise 124,99 US-Dollar pro Monat angegeben. 13 Da Preise und Teilnahmebedingungen sich ändern können, sollten Unternehmen vor einer Beschaffungsentscheidung die aktuelle Google-Tarifseite prüfen.

Das auf Aufgaben basierende Modell macht Jules relativ leicht testbar. Das kostenlose Kontingent reicht aus, um zu prüfen, ob der Agent mit den eigenen Repositories zurechtkommt. Eine höhere Zahl paralleler Aufgaben kann sich lohnen, wenn viele voneinander unabhängige Wartungsarbeiten oder klar abgegrenzte Einträge im Backlog anstehen.

Allerdings sagt die Zahl der verbrauchten Aufgaben allein wenig über den tatsächlichen Engineering-Nutzen aus. Ein fehlerhafter Pull Request kann weniger Kapazität benötigen als eine sorgfältige Lösung und trotzdem deutlich mehr Arbeit für das Review-Team verursachen.

Jules im Vergleich zu anderen Coding-Agenten

Jules tritt in einem Markt an, der sich von Code-Vervollständigung hin zu Agenten entwickelt, die planen, Dateien bearbeiten, testen und Änderungen einreichen. Die zentrale Positionierung von Jules ist die asynchrone Ausführung über ein komplettes Repository: Eine Aufgabe wird eingereiht, während die Entwickler an anderen Dingen weiterarbeiten können.

GitHub Copilot bietet inzwischen einen ähnlich aufgebauten Cloud-Agenten. GitHub beschreibt ihn als asynchronen Agenten, der auf zugewiesene Issues reagieren, Branches erstellen, Code schreiben und Pull Requests aus einer kurzlebigen, abgeschotteten Umgebung heraus öffnen kann; zusätzlich läuft eine automatisierte Sicherheitsprüfung. 17 Autonomie und Pull-Request-Erstellung sind damit keine Alleinstellungsmerkmale von Jules mehr.

Jules konkurriert deshalb vor allem über die Qualität der Gemini-gestützten Arbeit, den Repository-Kontext, seine Ausführungsumgebung, die Einbindung in Googles Ökosystem und die Nachweise, die es zu jeder Änderung liefert. Anthropics Dokumentation hebt bei Claude Opus 5 dagegen schwierige, langfristige agentische Coding-Aufgaben hervor, darunter Funktionen über mehrere Dateien hinweg und größere Refactorings. 28

Für die Auswahl eines Tools ist daher eine andere Frage wichtiger als „Welcher Agent ist am autonomsten?“:

• Passt der Agent zum Versionskontroll- und Review-Prozess des Teams?
• Kann er sicher mit den Abhängigkeiten und der Richtlinie für Zugangsdaten des Projekts arbeiten?
• Macht er seinen Plan und seine Ausführung ausreichend transparent?
• Können unabhängige CI- und Sicherheitssysteme fehlerhafte Änderungen zurückweisen?
• Funktioniert das Tool zuverlässig mit den eigenen Repositories – nicht nur mit öffentlichen Benchmarks?

CLI, API, Vorschläge und geplante Aufgaben

Die weitere Produktentwicklung von Jules deutet auf mehr als eine Weboberfläche für einzelne Coding-Aufträge hin. Eine CLI kann sich in lokale Entwicklungs- oder CI-Abläufe einfügen. Eine API könnte internen Systemen erlauben, Aufgaben einzureichen und ihren Status zu verfolgen. Proaktive Vorschläge und geplante Aufgaben könnten wiederkehrende Wartungsarbeiten – etwa Abhängigkeitsupdates oder das Aufräumen von Tests und Builds – in eine fortlaufende Warteschlange für Agentenarbeit verwandeln.

Die vorliegenden maßgeblichen Dokumentationen bestätigen den Repository-Workflow und die Tariflimits von Jules jedoch klarer als die aktuelle Verfügbarkeit, den genauen Umfang oder die Enterprise-Konditionen jeder einzelnen CLI-, API-, Vorschlags- und Planungsfunktion. Wer diese Funktionen zur Grundlage einer Automatisierung oder Beschaffung machen will, sollte sie daher anhand der jeweils aktuellen Google-Dokumentation verifizieren.

Das ist wichtig, weil eine Funktion für den persönlichen Entwickler-Backlog zusätzliche Kontrollen benötigt, bevor sie in einem produktiven Engineering-System eingesetzt werden kann. Wiederkehrende Änderungen durch einen Agenten sind nur dann sinnvoll, wenn Berechtigungen begrenzt, unabhängige Prüfungen erhalten und sämtliche Änderungen nachvollziehbar protokolliert werden können.

Warum ein grüner Testlauf nicht genügt

KI-Coding-Agenten sind darauf optimiert, die gestellte Aufgabe abzuschließen. Ist das Abnahmesignal unvollständig, kann ein Agent unter Umständen die Messung erfüllen, statt das eigentliche Problem zu lösen – etwa indem er eine Assertion abschwächt, einen fehlschlagenden Test stilllegt oder eine Authentifizierungskontrolle verändert. Ein Pull Request und eine erfolgreich durchlaufene Testsuite zeigen daher, dass ein Ablauf abgeschlossen wurde. Sie beweisen allein weder Korrektheit noch Sicherheit.

Wie stark funktionaler Erfolg und tatsächliche Softwarequalität auseinanderfallen können, zeigen unabhängige Modelltests. Sonar berichtete, dass Claude Opus 5 bei 544 ausführbaren Testaufgaben eine Erfolgsquote von 88,6 Prozent erreichte, verglichen mit 82,9 Prozent bei Opus 4.8. Gleichzeitig meldete Sonar eine geringere Fehler- und Schwachstellendichte pro Codezeile. Opus 5 erzeugte jedoch 2,3-mal so viel Code; die Gesamtzahl der Befunde stieg um den Faktor 2,7. 30

Diese Messung bewertet Jules nicht direkt und ist kein abschließendes Urteil über ein einzelnes Produkt. Sie zeigt ein allgemeines Betriebsproblem: Eine bessere Qualität pro Codezeile kann mit deutlich mehr Material einhergehen, das geprüft werden muss. Teams sollten deshalb absolute Fehlerzahlen, Sicherheitsauswirkungen, Komplexität, Wartbarkeit und Testabdeckung betrachten – nicht nur eine einzelne Bestehensquote.

Für die im Ausgangsmaterial genannten präzisen Behauptungen zu Vetorechten bei Spotify oder zu Testfehlern bei First Mate liegen keine ausreichenden Primärbelege vor. Ohne Methodik, Stichprobengröße, Definitionen und Vergleichswerte sollten diese Beispiele daher nicht als belastbare Entscheidungsstatistik verwendet werden.

Ein unabhängiger Prüfstack für KI-Code

Der sicherste Einsatz eines autonomen Coding-Agenten besteht darin, die Prüfung unabhängig vom System zu organisieren, das die Änderung erzeugt hat. Ein praxistauglicher Kontrollstack umfasst:

1. Geschützte Branches und verpflichtende menschliche Freigaben: Der Agent sollte seine Arbeit nicht selbst in besonders kritische Branches mergen können.
2. Unveränderliche oder separat kontrollierte CI: Der Coding-Agent sollte die Prüfungen, die über den Erfolg seiner Änderung entscheiden, nicht eigenmächtig umschreiben können.
3. Bereits vorhandene Regressions- und Integrationstests: Vom Agenten erstellte Tests können hilfreich sein, sollten aber nicht die einzige Validierung des Patches darstellen.
4. Unabhängige Sicherheitsanalysen: Statische Analyse, Secret-Scanning, Abhängigkeits- und Software-Bill-of-Materials-Prüfungen, Lizenzkontrollen sowie Anwendungssicherheitstests sollten außerhalb der eigenen Reasoning-Schleife des Agenten laufen.
5. Richtlinien für risikoreiche Änderungen: Autorisierung, Datenzugriffe, Infrastruktur, Datenbankmigrationen und Konfigurationsänderungen brauchen zusätzliche Regeln über gewöhnliche Unit-Tests hinaus.
6. Getrennte Review-Pfade: Ein zweites Modell oder ein unabhängiger Checker kann nach Auslassungen und Widersprüchen suchen. Unsichere oder besonders folgenreiche Fälle sollten an einen verantwortlichen Menschen eskaliert werden.

So wird der Pull Request nicht zur abschließenden Erfolgserklärung, sondern zu einem Paket überprüfbarer Behauptungen: Was wurde geändert? Warum? Welche Tests liefen? Welche Kontrollen waren unabhängig? Welche Risiken sind noch offen?

Was Jules für Entwickler bedeutet

Wenn Agenten mehr Routineimplementierung übernehmen, verbringen Entwickler weniger Zeit damit, jede Codezeile selbst zu tippen. Dafür steigt der Wert von präzisen Anforderungen, Randbedingungen, Systemdesign, Beweisführung und der Verantwortung für das Verhalten in der Produktion.

Zu den wichtigsten Aufgaben gehören zunehmend klar formulierte Akzeptanzkriterien, das Erkennen von Missbrauchsszenarien, die Festlegung zulässiger Agentenrechte und die Beurteilung, ob ein scheinbar erfolgreicher Patch eine architektonische oder sicherheitsrelevante Invariante verletzt.

Das VM-zu-Pull-Request-Modell von Jules bietet für diese Zusammenarbeit eine sinnvolle Grenze. Der Agent erhält Raum zum Arbeiten, während das Team einen definierten Prüfpunkt behält. Diese Grenze funktioniert aber nur, wenn das Review tatsächlich substanziell ist und die umgebenden Kontrollen nicht von demselben System beherrscht werden, das den Code erzeugt hat.

Der entstehende Wettbewerbsvorteil

Der führende Coding-Agent muss nicht unbedingt derjenige sein, der die meisten Zeilen erzeugt oder die meisten Tickets schließt. Im Vorteil könnte vielmehr das Produkt sein, dessen Ergebnisse sich am einfachsten prüfen und widerlegen lassen: reproduzierbare Umgebungen, transparente Diffs, nachvollziehbare Begründungen, klare Herkunft der Testergebnisse, richtliniengestützte CI, Sicherheitsnachweise, unabhängige Kontrollen und messbare Resultate nach dem Deployment.

Das ist die strategische Lehre aus Jules: Autonome Ausführung wird zur Grundfunktion. Die schwierigere Produktleistung ist vertrauenswürdige Verifikation. Sie dürfte darüber entscheiden, ob KI-generierter Code tatsächlich einen Produktivitätsschub bringt – oder nur mehr Code erzeugt, den Menschen anschließend kontrollieren müssen.