Cursor, Windsurf, Kiro, Aider: das sind die Namen, die am häufigsten fallen, wenn man über KI-gestützte IDEs und KI-Agenten spricht. Aber es gibt einen, über den man ziemlich wenig hört: Junie von JetBrains.
Ich habe immer mit PhpStorm entwickelt, da sitzen meine Gewohnheiten. Über die Jahre habe ich es so angepasst, dass es die IDE ist, die ich aus dem Effeff beherrsche, die ich in- und auswendig kenne.
Als die ersten KI-Agenten auftauchten, muss man schon sagen: JetBrains hat ewig gebraucht, um einzusteigen, und ist sogar deutlich ins Hintertreffen geraten. Der Launch von AI Assistant war ziemlich unspektakulär. Abseits der Autovervollständigung war das eingebaute Chat-Tool ziemlich begrenzt: keine Codegenerierung, langsam, keine Modellauswahl; die Integration in die Umgebung war der einzige echte Pluspunkt.
Seitdem hat sich das Tool verbessert. Sie haben ihren ersten echten KI-Agenten rausgebracht, Junie (9 Monate nach allen anderen), und der hat sich seitdem deutlich weiterentwickelt (schneller, Modellauswahl, IDE-Integration immer noch top, MCP-Unterstützung usw.).
Heute möchte ich euch zeigen, wie ich Junie im Alltag nutze, wie ich sie konfiguriert habe und ein paar Tipps, um sie möglichst gut einzusetzen. Ich behaupte nicht, dass das der beste Weg ist, aber es ist der, den ich nutze und der mir im Moment sehr gut passt (und der sich weiterentwickelt, je mehr ich damit arbeite).
Installation
Bevor wir loslegen: Junie gibt euch „gratis“ 3 Credits pro Monat für Prompts, damit kann man ein paar Prompts mit günstigen LLMs wie Gemini 3 Flash machen; mit Opus schafft man damit nicht mal einen. Ich empfehle euch deshalb mindestens den Pro-Tarif (10 Credits) mit einem günstigen LLM zum Ausprobieren. Ihr könnt auch zusätzliche Credits kaufen (1 Credit = 1 € zzgl. MwSt., 1 Jahr gültig), wenn ihr euer Monatskontingent überschreitet.
Holt euch zuerst das Plugin aus dem Marketplace. Zwei neue Icons erscheinen rechts und oben rechts in eurem Fenster.

Das Icon rechts öffnet das Junie-Panel, das oben gibt Infos zu eurem Restkontingent, Zugriff auf die Einstellungen usw.

Die Einstellungen
Mehrere Optionen lassen sich in den Settings von Junie konfigurieren:
Action Allowlist, um festzulegen, welche Befehle Junie ohne eure Bestätigung ausführen darfMcp Settings, um die MCPs zu konfigurieren, auf die Junie zugreifen kann. Achtung: über dieses Fenster fügt ihr MCPs für alle Projekte hinzu. Wollt ihr projektspezifische MCPs, legt ihre Konfiguration in.junie/mcpab.
{
"mcpServers":
{
"nuxt-ui" : {
"command": "npx",
"args": ["mcp-remote", "https://ui.nuxt.com/mcp"]
},
"nuxt": {
"command": "npx",
"args": ["mcp-remote", "https://mcp.nuxt.com/sse"]
},
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp", "--api-key", "YOUR_API_KEY"]
}
}
}
Models, um das zu verwendende Modell zu wählenProject Settings, um den Projektpfad und den Pfad zu euren Guidelines oder zum Rules-Ordner festzulegen
Guidelines und Skills: Junie steuern
Genau wie Cursor mit seinen Cursor Rules hat Junie ein eigenes Guidelines-System, um eure Entwicklungsregeln festzulegen.
Alles läuft über euer Verzeichnis .junie.
Die Guidelines
Standardmäßig stützt sich Junie auf .junie/guidelines.md, das ihr im Root eures Projekts anlegen müsst. In dieser Datei stehen all eure projektspezifischen Regeln: Architektur, Best Practices der verwendeten Sprachen und Frameworks usw.
Weil das schnell unübersichtlich wird, wenn ihr alles in eine einzige Datei packt, kann Junie seit Kurzem auch auf ein Rules-Verzeichnis statt auf eine einzelne Datei zurückgreifen (ja, Cursor kann das schon lange). In den Einstellungen von Junie zeigt ihr die Guidelines also nicht auf guidelines.md, sondern auf .junie/rules. Darin könnt ihr dann eure verschiedenen Regeldateien ablegen.
project-root/
|-- .junie/
|--rules/
|--typescript.md
|--nuxt.md
|--zod.md
Diese Rule-Dateien werden von Junie bei jedem neuen Prompt-Fenster geladen und gelesen (also nur beim ersten Prompt). Wenn ihr diese Rules bearbeitet, müsst ihr ein neues Prompt-Fenster öffnen.
Skills
Während ich diesen Artikel geschrieben habe, hat Junie ein Update rausgebracht, das die Unterstützung für Agents Skills. hinzufügt.
Kurz gesagt: ein Skill sagt Junie, wie sie bestimmte Aufgaben ausführen soll, zum Beispiel das Erzeugen eines PDFs. Die offizielle Doku schaut ihr euch am besten selbst an, aber es ist ein echtes Plus, damit Junie nicht zu sehr macht, was sie will.
Skills können in .junie/skills liegen.
project-root/
|-- .junie/
|--rules/
|--typescript.md
|--nuxt.md
|--zod.md
|--skills
|--my-super-skill
|--SKILL.md # Pflicht, enthält die Anweisungen
|--scripts/ # optional, ausführbarer Code
|--references/ # optional, Dokumentation
|--assets/ # optional, enthält Templates, Ressourcen, usw....
Ein Beispiel für einen Skill wäre ein doctrine-migration, der Junie sagt, wie sie eine Doctrine-Migration umsetzen soll.
Prompt-Fenster
Öffnet euer Junie-Panel.

Links habt ihr euer Prompt-Fenster, rechts die Liste der zuletzt ausgeführten Prompts und ein paar Beispiel-Prompts von JetBrains.
Im Prompt-Fenster gibt es mehrere Optionen:
+gibt euch Zugriff auf mehrere Optionen:- Ein Bild an euren Prompt anhängen
- Auf die Guidelines zugreifen (dazu später mehr)
- Eine
.aiignoreanlegen (gleiche Idee wie.gitignore, damit könnt ihr Dateien/Ordner vom Agenten ausschließen) - Eine kürzlich geöffnete Datei an euer Prompt-Fenster anhängen
- Neben dem
+habt ihr 3 Wahlmöglichkeiten (Autostandardmäßig), um Junie zu sagen, was sie tun soll:Autolässt Junie entscheiden, ob sie euch nur antworten, Code schreiben oder beides tun sollCode: Junie muss Code erzeugenAsk: Junie antwortet euch in einem.md
- Dann gibt es den
Brave Mode, um Junie zu erlauben (oder nicht), Befehle ohne Nachfrage auszuführen (seid damit vorsichtig) - Und zum Schluss
Think More, um Junie mehr Zeit für die Anfrage zu geben (oder nicht). Bei komplexen Anfragen kann das das Ergebnis verbessern, verbraucht aber natürlich mehr Credits.
Let's prompt
Jetzt, wo eure Junie konfiguriert ist, können wir loslegen.
Den Prompt strukturieren
Das weiß man inzwischen, aber ein Prompt muss so präzise wie möglich zur Feature sein, die ihr entwickeln lassen wollt, oder zu dem, was der Agent tun soll. Die implementier mir Feature X-Prompts, die dem Agenten zu viel Freiheit lassen, lassen wir sein. Ziel ist auch nicht, den Inhalt der Rules zu kopieren, sondern die KI so klar wie möglich zu steuern. Dafür teile ich meine Prompts in mehrere Teile:
Objective: wir definieren das übergeordnete Ziel des PromptsRules: wir definieren die Regeln, die für die Feature geltenSteps: die Schritte, denen unser Agent folgen sollExamples: wir können auch Beispiele hinzufügen, um Junie noch mehr zu helfen.
Nehmen wir als Beispiel diesen Prompt:
# Objective
Be able to create income types
# Rules
* The entity is called "income type".
* The entity has the folowing parameters
* id --> auto generated UUID
* name --> string, length 255, mandatory
* user --> The user who created the income type. It's a Uer object.
* A User can be associated with multiple income types, but an income type is linked to only one User.
* This entity must be exposed as an API resource with GET, GET collection, POST, PUT, and DELETE operations.
* It must be secured: only the User associated with the income type can PUT, GET (both collection and single), and DELETE it (based on JWT).
# Steps
* Create the IncomeType entity
* Run `make migration`
* DO NOT run `make exec-migration`
Formatiert euren Prompt ruhig in einem Scratch, zum Beispiel.
Wenn euer Prompt fertig ist, führt ihn aus, und Junie fängt an zu arbeiten.
Bevor sie den Code erzeugt, legt Junie einen Plan auf Basis eures Prompts an. Beispiel:

Danach erzeugt Junie den nötigen Code, und nach einer mehr oder weniger langen Wartezeit:

Das Ergebnis prüfen
Super, euer kleines done erscheint, plus eine kurze Zusammenfassung und die geänderten/hinzugefügten/gelöschten Dateien. Ein Klick darauf zeigt euch die Änderungen direkt per Git-Diff. An diesem Punkt solltet ihr immer gegenchecken, was Junie geliefert hat. Wenn euch wirklich gar nichts passt, könnt ihr immer noch ein Rollback aus dem Ergebnis in Junie machen.
Achtung allerdings: ihr könnt nicht nur einen Teil des erzeugten Codes zurückrollen, bestenfalls eine bestimmte Datei. Genauso: wenn ihr in demselben Fenster einen neuen Prompt ausführt, könnt ihr den vorherigen Prompt nicht mehr rollbacken, außer ihr rollt die späteren zuerst zurück.
Beim Gegenlesen solltet ihr Junie nicht zu viele Korrekturen abverlangen, vor allem keine kleinen: ihr verbraucht Credits für nichts, bläht den Kontext auf und riskiert, in einer Endlosschleife zu landen, in der sich die KI verläuft (und ihr mit ihr).
Wenn das Ergebnis passt, könnt ihr committen und zum nächsten übergehen! Versucht auch, ein Fenster pro Feature zu nutzen, damit die Kontexte klar und leicht bleiben.
Meine Meinung
Ich habe euch ein bisschen meine Arbeitsweise mit Junie gezeigt, wie man sie konfiguriert und wie sie im Großen und Ganzen funktioniert. Ich weiß nicht so recht, wie ich meine Meinung formulieren soll, also machen wir's klassisch mit Pro und Contra.
- Die
+- Perfekte Integration in die IDE, die direkten Zugriff auf das gesamte Projekt gibt
- Endlich eine große Modellauswahl
- Dass Junie ihren Plan vor der Ausführung anzeigt
- Relativ klares Quota-Tracking
- Die
-- Etwas langsam
- Die interessanten Features, die Monate nach der Konkurrenz kommen (auch wenn es sich inzwischen beschleunigt)
- Der Verlauf verschwindet bei jedem Update
- Eine Vorschau der verbrauchten Credits am Ende einer Ausführung wäre nicht schlecht
- Teuer (Ultimate mit 36 €/Monat Pflicht, Pro mit 10 € viel zu begrenzt vom Nutzungskontingent)
Ein paar Ressourcen
Ich hoffe, ich konnte euch einen klaren Überblick geben, wie man Junie möglichst gut nutzt. Ich setze sie seit bald einem Jahr regelmäßig ein, und auch wenn sie nicht perfekt ist, entwickelt sie sich weiter und macht den Job.
Aktualisiert am 24. Februar 2026
