Googles asynchroner KI-Coding-Agent Jules ist jetzt für alle verfügbar

 (blog.google)
3 Punkte von GN⁺ 2025-08-08 | 1 Kommentare | Auf WhatsApp teilen
  • Google hat Googles asynchronen KI-Coding-Agenten Jules aus der Beta herausgenommen und offiziell gestartet
  • Mit Gemini 2.5 Pro ist jetzt eine weiterentwickelte Code-Generierung und die Erarbeitung von Arbeitsplänen möglich
  • In der Beta-Phase haben Entwickler:innen tausende Aufgaben abgearbeitet und über 140.000 Code-Verbesserungen geteilt
  • Basierend auf Nutzerfeedback wurden UI-Verbesserungen, Bugfixes, die Wiederverwendung von Voreinstellungen, GitHub-Issues-Integration und Multimodal-Unterstützung als neue Funktionen hinzugefügt
  • Durch die erweiterten Denkfähigkeiten von Gemini 2.5 Pro können anspruchsvollere Coding-Pläne und hochwertigerer Code erzeugt werden
  • Einführung neuer Abonnement-Stufen: Introductory (Basis-Hands-on), Pro (5-fach Limit), Ultra (20-fach Limit), Studierende erhalten 1 Jahr kostenlosen Pro-Zugang

Offizieller Start von Jules und wichtigste Verbesserungen

  • Google hat den asynchronen KI-Coding-Agenten Jules nach Abschluss der Beta offiziell gestartet
  • Jules nutzt die Funktion Advanced Thinking von Gemini 2.5 Pro, um vorab einen Coding-Plan (Plan) zu erstellen und dadurch qualitativ hochwertigeren Code zu erzeugen
  • Während der Beta führten tausende Entwickler:innen zehntausende Aufgaben durch und teilten über 140.000 Code-Optimierungen

Nutzererlebnis und Feedback-Integration

  • Auf Basis von Entwicklerfeedback wurde die Benutzeroberfläche (UI) neu gestaltet und Hunderte von Fehlern behoben
  • Mit der Funktion Wiederverwendung früherer Einstellungen wurde die Ausführung wiederkehrender Aufgaben beschleunigt
  • Die Integration von GitHub Issues ermöglicht eine bessere Einbindung in den Entwicklungsworkflow
  • Mit Multimodaler Eingabe lassen sich nun verschiedene Datentypen verarbeiten

Abonnementstufen und Nutzungsmodell

  • Jules wird in strukturierten Abonnementstufen (Introductory, AI Pro, Ultra) angeboten und kann je nach Anwendungsfall gewählt werden
    • Introductory: Basis- onboarding und Einstieg für Einsteiger:innen
    • Google AI Pro: fünfmal das Standardkontingent, geeignet für den täglichen Coding-Einsatz
    • Google AI Ultra: zwanzigfaches Standardkontingent, optimal für großskalige Multi-Agenten-Workflows
  • Abonnent:innen von Google AI Pro und Ultra erhalten die neuen Konditionen ab sofort schrittweise, Studierende erhalten ein Jahr kostenlose Nutzung von AI Pro

Jules kann direkt über jules.google gestartet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-08
Hacker News Kommentare

  • Ich frage mich, warum Googles Abonnementmodell so kompliziert geworden ist: Bei „Google AI Ultra“ sind Jules, die Gemini App und Notebook enthalten, aber um Gemini CLI nutzen zu können, muss man in GCP ein separates Abonnement und ein Abrechnungs-/Konto anlegen und Google Code Assist kaufen usw., was äußerst umständlich ist. Und dann ist wieder mal die Gemini App nicht verfügbar. Zusätzlich fällt bei Google AI auch YouTube Premium dazu – ich verstehe nicht, warum diese Dinge gekoppelt sind.

    • Es wirkt, als gäbe es intern bei Google zwei separate Gruppen, die KI-Produkte liefern. Bei uns im Unternehmen ist im Workspace-Abonnement bereits Gemini, Veo 3 und Jules enthalten, mit einem Abonnement kann man (wenn auch begrenzt) nahezu unbegrenzt nutzen. Der Hauptzugang ist gemini.google.com. Wenn allerdings API-Nutzung benötigt wird, muss man getrennt GCP verwenden, wo man Modelle wie Veo3 und zusätzliche Funktionen nutzen kann, aber nach Verbrauch zahlt man. Der Eintrittspunkt ist GCP Vertex AI. Die beiden Organisationen sind ziemlich getrennt und scheinen nicht recht zu wissen, was die andere macht.

    • Wer früher über Google for Domains ein Workspace eingerichtet hat, hat es wirklich schwer – nichts funktioniert ordentlich.

    • Während die KI den Code schreibt, kann man parallel YouTube schauen.

    • Googles Kerngeschäft ist der Verkauf von Werbung und deren Marktbeherrschung (Analytics, Chrome, Chromebook, Android, Google SSO usw.). Entwicklerprodukte sind Nebenprojekte innerhalb verschiedener Bereiche von Google und können niemals zu einem Fokus oder einer Priorität werden.

    • Anders als bei manchen Inhalten im Ultra-Abonnement kann YouTube Premium nicht geteilt werden; am Ende muss man beide Produkte separat nutzen, obwohl Google wiederholt davor warnt, das nicht zu tun.

  • Ich habe Jules kürzlich in einem Side-Project (React Native App) ausprobiert: Während ich auf dem Weg zur und von der Arbeit spazieren war, dachte ich über neue Ideen/Features nach, plante und nahm Änderungen mit der GitHub-App vor. Ich habe Jules mit einigen Aufgaben beauftragt, und abends nach der Arbeit gab es ein erstelltes PR. Die Codequalität ist nicht perfekt, aber meistens läuft alles, sodass ich sofort testen und dann direkt selbst korrigieren kann, was schnellen Wiederholungstest erlaubt. Als Nächstes will ich allen PRs einen automatischen Build hinzufügen, um auf dem Handy auf dem Heimweg direkt die Branches einsehen zu können.

    • Vielleicht ist es bei React Native ähnlich, ich weiß es nicht, aber bei Vercel-Deployments mit Neon als DB ist es sehr praktisch, eine Live-Vorschau für jeden Branch/Commit/PR als fertige Site zu haben. Als ich aus dem Python-Umfeld kam, hat diese Commit-zu-Deployment-Werkzeugkette Exploration und experimentelles Coding deutlich reibungsloser gemacht: Entscheidend wird eher, was ich nach dem Bauen wirklich baue. Natürlich funktioniert dieser Ansatz nur, wenn das Feature so einfach ist, dass ein LLM es in einem Schritt erledigen kann.

    • Asynchrones exploratives Coding ist gerade ein Trend. Auch der GitHub Copilot Coding Agent (ein separater Agent statt des VSCode-Plugins von GitHub Copilot) wird empfohlen.

    • Ich habe früher einmal einen unbetreuten GitHub-Repo angebunden und Kleinigkeiten übergeben wie Dependency-Updates, Refactoring, kleine Feature-Änderungen und Stiländerungen. In solchen Fällen funktioniert es ganz ordentlich; wichtige Entwicklung würde ich da aber nicht hineinlegen.

    • Genau aus diesem Grund habe ich superconductor.dev gebaut: Live-Previews sind für jede Agent-Sitzung verfügbar; unterstützt werden Claude Code, Gemini, Codex und Amp. Wer Interesse hat, kann beim Registrieren den HN-Hinweis nennen, dann bekommt ihr vorrangigen Zugang.

  • Während der Jules-Preview habe ich ihn mehrfach verwendet und er war von allen Cloud-Coding-Assistenten, die ich bisher ausprobiert habe, der schlechteste. Ich nahm an, es sei ein kurzfristiges Experiment gewesen und würde wieder eingestellt werden; ich hätte nie erwartet, dass er als echtes Produkt veröffentlicht wird. Ähnlich war es bei GH Copilot Spaces, bevor es zum Copilot Agent wurde: Jules macht, was es will, sagt „fertig“ und redet beim Follow-up oft wirr. Die Umgebung bleibt nicht stabil und manchmal funktioniert es gar nicht. Realistisch gemergte PRs gab es fast nur einen; der Rest wurde verworfen und anderen Agenten zugewiesen. Meine persönliche Reihenfolge ist Claude Code (mit gh action Nutzung)> ChatGPT Codex > GitHub Copilot Agent > Jules. Ich habe jetzt erneut für 3 Monate Testzeit bekommen und möchte es heute wieder testen; falls es unverändert bleibt, investiere ich weder Geld noch Zeit in Jules und empfehle stattdessen Codex oder GitHub Agent. Bitte entschuldigt die schlechte Bewertung.

    • Heute habe ich Jules noch einmal „fair“ getestet, und es ist immer noch schlecht:

      • Ich habe einen Plan vorgeschlagen, Feedback gegeben und freigegeben; nach ein paar Minuten wartete Jules wieder nur darauf, dass ich erneut „weiter“ eingebe. Ich musste erneut bestätigen, damit es startete.
      • Bun ist in der Umgebung installiert, aber Jules findet den bun-Befehl nicht, installiert ihn immer wieder neu und wiederholt den Installationsversuch. Wenn ich Feedback gebe, ist Bun wieder weg; bei jedem Befehl wird install_bun.sh erneut gestartet.
      • Die angeforderte Aufgabe wurde erledigt, aber dann brechen Tests; dann sagt Jules, das habe nichts mit den Änderungen zu tun. Ich habe „Bitte alles beheben“ gesagt, aber es konnte es nicht lösen. Genau dieselbe Einstellung funktioniert bei Codex, Copilot Agent und Claude Code, aber nicht bei Jules.
      • Ich wollte es selbst übernehmen, aber es hatte den „Abschluss“ nicht erreicht, daher wurde kein Branch erstellt. Als ich Branch-Push anforderte, blieb es lange stehen und führte mehrfach Tests/Linting aus, bis am Ende doch ein Branch entstand.
      • Selbst kleinste Änderungen dauerten sehr lange, und jeder Feedback-Zyklus kostete zu viel Zeit. Ich weiß nicht, warum Bun oder Testausführungsfehler auftreten. Ich hoffe auf künftige Verbesserungen, plane aber derzeit, nur die anderen drei Agenten zu nutzen.

    • Ähnliche Erfahrung. Persönlich bewerte ich bei großzügigen Rate Limits Codex höher als Claude. Jules ist zu zerstreut, und mir gefällt nicht, dass es nur Git-Pull-Requests erstellt. Codex ist deutlich besser, weil man den Git-Patch sofort kopieren, dann nach Wunsch anpassen und committen kann.

    • Ich habe es selbst noch nicht ausprobiert, aber ich habe Zweifel, ob asynchrone Agenten genauso hilfreich sind wie Claude Code lokal. Man muss weiterhin eingreifen, um zu prüfen, ob es funktioniert. Ein asynchroner Agent braucht den kompletten Ablauf von Code-Pull, Build, Run und Test und scheint dadurch mühsam. Lokales Arbeiten in heißer Umgebung ist dagegen wesentlich effizienter.

    • Ich denke, was hier beschrieben wurde, ist genau das, was ich in GH Copilot Spaces gesehen habe. Wahrscheinlich bereitet Google das als Zukunftsplan vor. Selbst wenn KI das heute nicht perfekt kann, wäre es zu spät, erst beim großen Wandel die richtigen Features einzubauen. Persönlich zweifle ich daran, dass LLMs das vollständig lösen; nach jedem LLM wird immer etwas Menschliches übrig bleiben.

  • Bei der kostenlosen Stufe sind die täglichen Arbeitsgrenzen von 60 auf 15 gesunken. Ich habe bei meinen vielen Änderungen selbst nie an die Grenze geraten. Wer direkt mit dem Jules-Team sprechen will, kann über discord.gg/googlelabs Kontakt aufnehmen.

    • Bei mir wurde es auf 100 Aufgaben angehoben, je nachdem ob man Google Pro oder kostenlos ist. Selbst wenn ich am Wochenende viele Jobs mache, überschreite ich kaum 10. Für kostenlose Nutzer sind 15 meist genug; 100 Jobs würden ich vermutlich persönlich nie ganz ausschöpfen.

  • Mit dem Prompt „Implementiere einen grundlegenden Raytracer in Rust“ habe ich Jules vor ein bis zwei Monaten und jetzt erneut getestet. Damals wurde zwar wohl immerhin kompiliert, aber diesmal wurde kein Push auf einen Branch durchgeführt, egal wie oft ich es verlangte; ich konnte nicht einmal prüfen, ob der Code wirklich läuft. Diesmal hat Jules zwei main.rs in verschiedenen Verzeichnissen angelegt und den Code durcheinander verteilt. Als ich das Problem erklärte, durchforstete es das Dateisystem und gab schließlich auf.

    • Das Interaktionsmodell rund um den Commit-Push ist so verwirrend, dass es schwer zu verstehen ist.

    • Das ist kein Zero-Shot-Tool; ich verstehe nicht, warum alle es als Zero Shot versuchen.

  • Ich freue mich über die Entstehung eines Konkurrenzverhältnisses zu Codex. Ich glaube, dass Cloud-async agents wie Codex und Jules besser sind als lokale integrierte Modelle wie Claude Code/Aider/Cursor. Diese sind komplett getrennt von meiner lokalen Umgebung, also sicherer. Außerdem ist es besser, nur Kommandos zu senden, auf dem PC anders zu arbeiten und den PR später zu prüfen, statt selbst Sandbox-Aufbau oder git worktree zu verwenden.

    • Codex und Jules sind völlig anders als CC und Cursor. In der Software-Diskussion „Cathedral vs Bazaar“ wie hier ist:

      1. Beim Cathedral-Modell gibt es eine kontrollierte Umgebung, einfachen Rollout und begrenztes Upside; OpenAI ist hier ein Beispiel.
      2. Beim Bazaar-Modell geht der Agent in die Nutzerumgebung und interagiert mit vielen Apps und Variablen direkt, was deutlich anspruchsvoller ist, aber ein viel höheres Potenzial bringt. Konfigurationsprobleme sind temporär und lösbar.

    • Vollständige Trennung ist zwar sicher, aber langsam und teurer. Wenn CC mal spinnt, kann man sofort abbrechen; beim asynchronen Modell könnte man erst nach Stunden zurückkehren und eine Katastrophe vorfinden, plus hohen Tokenverbrauch.

    • PR-basierte Vorschläge auf bestehenden Code-Basen sind die Entwicklerfreundlichste Einstiegsmethode, weil man mit dem Review-Flow bereits vertraut ist. Wenn man diesen klassischen Menschen-Workflows aber zu viele Agenten-Outputs aufzwingt, stößt man schnell an Grenzen. Deshalb braucht es automatisierte Workflows, die effizient eine größere Menge von Vorschlägen prüfen. Deshalb halte ich Command-Line-basierte Claude- und Aider-Ansätze für den besten Weg, Async-/parallele Agenten wirklich zu skalieren. Dazu habe ich auch eine Helferbibliothek für Aider/Claude bereitgestellt: Hilfsbibliothek für Aider/Claude. Und eine solche Entwickler-Umgebung muss Open Source bleiben, sonst bleibt man bei Infrastrukturabhängigkeiten von MS oder OpenAI gefangen. Tipps fürs Review per CLI dokumentiere ich auch in Fallstudien.

    • Übrigens kann Claude code auch mit GitHub Actions asynchron arbeiten; automatisches Setup wird über den Claude code Slash-Befehl unterstützt.

    • Die produktivste Konfiguration wirkt wie eine Kombination aus Cloud-basierten async-Agents und lokal aktivierten Modellen (Claude Code, Cursor, Aider): Wiederkehrende, einfache Aufgaben an Codex geben, den Rest lokal machen. Ich bin bei der langsamen Codex-Maschine unzufrieden, weil Kompilierung, Rebuild und Dependency-Caching immer wiederholt werden. Wenn UI, Tooling und State lokal verwaltet würden und nur LLM-Inferenz remote stattfände, wäre der Ablauf deutlich schneller.

  • Als ich Jules im Side-Project eingesetzt habe, war die Codequalität deutlich schlechter als bei GH Copilot (Claude Sonnet), Gemini CLI und Claude Code; besonders im Monorepo verhedderte sich die Logik bei Verzeichniswechseln immer wieder. Obwohl ich im backend-Ordner bin, hat es wiederholt cd-Kommandos ausgeführt und konnte die Logik nicht korrekt interpretieren.

    • Neu bewirbt Jules die erweiterte Planerstellung von Gemini 2.5 Pro, also könnte ein weiterer Versuch sinnvoll sein.

    • Beim ersten Einsatz war die vollständige Umstrukturierung der Datenschicht erstaunlich gut; ich war bereits bei Copilot beeindruckt, aber mit längerer Nutzung wird die KI langsam und verwirrt, sodass es Zeit verschwendet wird. Das ist der derzeitige Zustand KI-Coding-Agenten.

    • Ich habe einen kleinen PR für farbige Terminalausgaben in einem Side-Project gegeben; das Ergebnis war hervorragend. LLM-Coding-Agenten scheinen bei bestimmten Aufgaben Stärken zu haben und bei anderen Schwächen, daher scheinen die Ergebnisse fast zufällig. Dennoch bleibt die Belastung gering, weil bei einem Fehlschlag durch einen One-Liner-Prompt trotzdem wieder eine erneute Anfrage einfach möglich ist.

  • Mir gefällt der Begriff „asynchroner Coding Agent“, der Beitrag von LangChain zu Open-Source Async Agenten sowie das Beispiel zu einem Copilot Coding Agent unterstützt diesen Trend. Ich hoffe, dass sich diese Bewegung etabliert.

    • Wenn Simon (der Autor dieses Kommentars) den Begriff verwendet, wird er wahrscheinlich zum Standard werden.

  • Für 2025 ist Claude Code der einzige echte Agent, obwohl Gemini bei langen Kontexten stark ist. Zum Vergleich: Reddit-Diskussion

    • Stimme zu: Google hat starke Benchmark-Ergebnisse, und Modellankündigungen wie World Models Genie 3 sind beeindruckend. Aber Gemini CLI-Empfehlungen/Änderungen sind zu stereotyp, es wirkt wie ein OCD-Coder, der sich mehr um Tabs und Leerzeichen kümmert als um tatsächlich nützliche Funktionen. Als Beispiel habe ich in einem aktuellen Projekt mein tägliches Token-Limit mit trivialen Arbeiten wie ESLint-Einstellungen oder unnötiger Code-Modularisierung aufgebraucht. Claude Code hingegen setzt Anforderungen besser in echte Nutzerfeatures um. Vielleicht liegt es am Prompting; mir scheint aber, Claude Code versteht mich besser.

    • Ich stimme zu: Der PR-Review-Workflow stört dazwischen. Die Killerfunktion von Claude Code ist, dass man sofort eingreifen kann, wenn er in die falsche Richtung driftet, mit leichter Zwischenintervention direkt zu coden. Genau wie ein Junior nur dann prüfen sollte, wenn er ein komplettes Feature ohne Hilfe aufgeben würde.

    • Sourcegraph Amp ist auch ganz gut. Es hat nicht die Ausgereiftheit oder Featuretiefe von Claude Code, aber ich nutze oft das 'oracle'-Tool mit o3 für Code-Reviews.

  • Ich verstehe nicht, warum die Preisinfo so versteckt ist – man muss fast auf Grok gehen, um etwas zu finden. Bei der Google-Seite muss man in die AGB einwilligen, um selbst eine Tarifübersicht zu sehen. Der Blick auf Pläne/Preise ist hier möglich: gemini.google/subscriptions (möglicherweise ist ein Login erforderlich).

    • Die Formulierung „> Highest task limits“ oder das spätere Ändern von Nutzungsbedingungen wie bei Claude oder Cursor sollte rechtlich verboten sein.

    • Was bedeutet es, dass man auf Grok zurückgreifen musste? Kannst du erklären, ob andere Modelle auch schiefgelaufen sind oder ob du einfach oft Grok benutzt?