ThinkRail: JetBrains baut eine IDE um Pi

Was ist ThinkRail von JetBrains?

ThinkRail ist ein JetBrains-Inkubatorprojekt, kein IntelliJ-Plugin und keine neue Oberfläche für Junie. Laut Architekturbeschreibung im versionierten README läuft Pi als eingebettete Bibliothek im Prozess der Anwendung. Pi übernimmt Modelle, Sitzungen und Kontextverwaltung. ThinkRail ergänzt Projekte, Arbeitsbereiche, Terminals und die Oberfläche zum Prüfen der Ergebnisse.

Den Agenten selbst erklärt der bestehende Pi-Grundlagenguide. Hier geht es um die Arbeit darum herum: Wo landet eine Änderung? Welche Dateien hat ein Durchlauf tatsächlich angefasst? Und welche fachlichen Regeln sollen beim nächsten Auftrag noch gelten?

Die README dokumentiert beide Oberflächen und den Modellzugang. Die offene Lizenz bedeutet keine kostenlose Inferenz; die Sterne zeigen Aufmerksamkeit, keine gemessene Qualität.

Wie startest du mit ThinkRail?

Für einen ersten Versuch ist der Desktop-Download der übersichtlichste Weg. Wähle auf der gebundenen Release-Seite das Paket für dein Betriebssystem. Die Installationsdokumentation nennt macOS 14 oder neuer für Apple Silicon und Intel, Windows x64 sowie Linux x64 und ARM64. Unter Linux benötigt die Desktop-App glibc 2.38 oder neuer und die dort aufgeführten GUI-Bibliotheken; Ubuntu 24.04 oder neuer ist die dokumentierte Basis.

Danach folgt dieser Bedienweg:

1. Voraussetzungen prüfen: Git muss im PATH liegen, ein nutzbarer Modellzugang bereitstehen. Bun und Node sind Voraussetzungen für die Entwicklung aus dem Quellcode, nicht für den ausgelieferten Launcher.
2. Modell verbinden: Im Startassistenten Datenschutzoption prüfen und über „Connect a model“ JetBrains AI oder einen von Pi unterstützten Provider anmelden. Erkannte CLI-Konfigurationen ersetzen diese Anmeldung nicht.
3. Projekt öffnen: „Open project“ verwendet ein vorhandenes Repository. „Start a new project“ legt ein Git-Repository an; „Clone repository“ nutzt bestehende Git-Zugangsdaten oder SSH-Schlüssel.
4. Arbeitsbereich anlegen: Für den Versuch einen eigenen Worktree wählen, ein Modell auswählen und eine begrenzte Aufgabe stellen.
5. Ergebnis prüfen: Änderungen lesen, Rückfragen an den Agenten senden und passende Tests ausführen. Erst danach übernimmst du die Änderung.

Dieser Ablauf ist in README und Releasebericht beschrieben. Die GitHub-CLI gh brauchst du nicht zum allgemeinen Start oder für jedes Klonen, sondern für die dokumentierten GitHub-PR-Aktionen.

Ein möglicher erster Auftrag, ausdrücklich als redaktionelles Beispiel:

Erweitere die vorhandene Eingabevalidierung um Tests für leere Eingaben und Grenzwerte. Lies vorher die relevante Modulspezifikation. Ändere keine fachfremden Dateien. Zeige anschließend den Diff und dokumentiere, welche Tests du ausgeführt hast.

Damit hast du einen überschaubaren Prüfauftrag statt einer offenen Aufforderung, das gesamte Projekt zu verbessern.

Was bringen Worktrees und Diff-Reviews?

Ein Git-Worktree ist ein zusätzliches Arbeitsverzeichnis desselben Repositorys. ThinkRail kann für eine Aufgabe einen eigenen Branch mit eigenem Checkout anlegen. So bleibt die laufende Arbeit im Hauptverzeichnis zunächst getrennt. Die README erlaubt aber auch vorhandene Worktrees und ausdrücklich die Arbeit direkt im Projektordner. Nicht jede Sitzung ist deshalb automatisch isoliert.

Beim Validierungsbeispiel landet der Versuch im Aufgaben-Worktree. Du prüfst dort Tests und Implementierung, bevor du den Branch übernimmst. Parallelität ist möglich, aber kein Selbstzweck: Überlappende Änderungen müssen beim Zusammenführen weiterhin aufgelöst werden.

Änderungen statt Agentenzusammenfassungen lesen

„Review turn“ zeigt die Änderungen eines Agentendurchlaufs. Laut Herstellerbeschreibung vergleicht der Host Snapshots vor und nach dem Durchlauf, statt nur die gemeldeten Dateitools auszuwerten. So können auch Änderungen aus Shellbefehlen auftauchen. Das erzeugt keinen Commit und verändert laut Dokumentation weder HEAD noch Index oder Reflog.

Zeilenbezogene Kommentare auf Dateien und Diffs lassen sich als strukturierter Kontext an den Chat schicken. Ein Hinweis wie „Dieser Grenzfall fehlt im Test“ bleibt damit an der betroffenen Stelle. Die Einzel-Turn-Ansicht ist read-only; „Keep“ gehört zur Branch-Diffansicht. Beides ist eine Reviewhilfe, kein Nachweis fachlicher Korrektheit.

Ein begrenztes externes Signal liefert MODEL: In zwei beschriebenen Linux-CLI-Durchläufen mit Version 0.2.0 und geskriptetem Modellstub erfasste das Receipt beide geänderten Dateien, obwohl die Zusammenfassung nur eine nannte. Das war kein echter LLM-Test und keine Prüfung des hier behandelten Releases; der Bericht veröffentlicht oder verlinkt keine vollständigen Testlogs. Der Bericht wurde für diesen Artikel nicht reproduziert.

Wie funktionieren Living Specs?

Living Specs halten die Absicht hinter dem Code in versionierten Markdown-Dateien fest. Im beschriebenen SDD-Ansatz stehen goal-and-requirements.md für Ziel und Anforderungen, architecture.md für Architekturentscheidungen und modulnahe SPEC.md-Dateien für Zuständigkeiten und Grenzen.

Ein YAML-Header macht die Dokumente adressierbar. id, type und title kennzeichnen die Spezifikation; Beziehungen wie parent und depends-on verbinden sie. Das folgende selbst formulierte Muster ist keine mitgelieferte Produktdatei:

---
id: module-validation
type: module-design
title: Eingabevalidierung
status: active
---

## Aufgabe

Prüft Eingaben vor der fachlichen Verarbeitung.

## Grenzen

Leere Eingaben werden abgelehnt. Fachliche Grenzwerte stehen in den Anforderungen.
Die Validierung verändert keine gespeicherten Daten.

## Prüfung

Verhaltensänderungen benötigen passende Regressionstests.
Ändert sich eine fachliche Regel, werden Spezifikation und Tests mitgeprüft.

Das Specs-Panel zeigt die Dokumente als lesbaren Baum. Der Agent kann relevante Specs suchen und ihre Beziehungen abfragen. Die Idee ist gezielter Kontext: die passende Modulbeschreibung heranziehen, statt sämtliche Projektdokumentation in jede Sitzung zu laden.

Dabei ist die Werkzeugspezifikation präziser als das Schlagwort „lebendig“: spec_get liefert Metadaten, Links und Pfad, nicht den Fließtext. spec_update ändert nur das Frontmatter. Fachliche Beschreibungen liest und bearbeitet Pi über seine normalen Dateitools. Der Specs-Viewer selbst ist read-only.

Specs trainieren keine Modellgewichte und werden nicht automatisch wahr. Die kritische DEV-Analyse, ausdrücklich ohne Installation, benennt den entscheidenden Unterschied: Ein gültiger Dokumentgraph beweist nicht, dass Text und Code übereinstimmen. Zu große Specs können außerdem den erhofften Kontextvorteil aufzehren. Halte sie deshalb modulnah und prüfe fachliche Änderungen gemeinsam mit dem Code.

Was ergänzt das betrachtete Release?

Der Herstellerbericht zu v0.3.0 beschreibt vor allem einen enger verbundenen Arbeitsablauf:

GitLab wird bei der MR-Erstellung erwähnt. Daraus folgt keine vollständige Gleichheit mit den GitHub-Reviewaktionen; der Hersteller nennt GitLab-Reviewaktionen ausdrücklich als noch fehlend.

Für wen lohnt sich ThinkRail statt Pi im Terminal?

Der Unterschied liegt im Arbeitsplatz, nicht in einem belegten Qualitätsvorsprung des Agenten. Aus Architektur und Kompatibilitätsbeschreibung ergibt sich diese Entscheidungshilfe:

Der letzte Punkt ist wichtig: Die Monaco-Konfiguration des gebundenen Tags setzt die Dateiansicht auf readOnly: true. Eine Monaco-Ansicht ist hier kein Beleg für einen frei editierbaren klassischen IDE-Ersatz. Laut README kannst du den Worktree in einer installierten externen IDE öffnen.

Welche Einschränkungen musst du kennen?

Pi-Kompatibilität ist nicht grenzenlos

ThinkRail liest normalerweise ~/.pi/agent. Ein anderer Konfigurationsordner lässt sich über „Settings → Environment“ oder PI_CODING_AGENT_DIR wählen; Änderungen in den Einstellungen greifen nach einem Neustart. Das dokumentiert die README.

Laut Kompatibilitätspost kann das eingebettete Pi von deiner separat installierten Version abweichen. Terminalthemes und andere TUI-Anpassungen funktionieren nicht wie im Terminal; Erweiterungen können zudem um Toolnamen konkurrieren. Volle dynamische Erweiterungsunterstützung steht im gebundenen README noch als Ausblick. Funktionen aus dem aktuellen Entwicklungsbranch sind deshalb keine automatische Releasegarantie.

Worktrees sind keine Sandbox

Getrennte Checkouts begrenzen nicht die Betriebssystemrechte des Agenten. Shellbefehle laufen mit den Rechten des ausführenden Benutzers; Worktrees isolieren weder Netzwerk noch Secrets oder Prozesse. Auch die dokumentierten MCP-Freigabedialoge sind kein allgemeines Shell-Berechtigungsmodell. Die read-only-Kennzeichnung eines MCP-Tools stammt vom Server, nicht aus einer unabhängigen Sicherheitsprüfung.

Lokale Oberfläche bedeutet nicht lokale Verarbeitung

Bei Cloudmodellen kann der übergebene Kontext zum Provider gelangen. Zusätzlich dokumentiert die Datenschutzsektion grundlegende Nutzungsereignisse und Fehlerberichte unter einer zufälligen Installations-ID sowie PostHog als Dienstleister. Laut Hersteller enthalten diese keine Prompts, Code oder Zugangsdaten; das ist eine dokumentierte Policy, keine eigene Netzwerkmessung.

--no-analytics, THINKRAIL_NO_ANALYTICS=1 und der Schalter für zusätzliche Nutzungsdaten deaktivieren nur zusätzliche Datenteilung, nicht die Basiserfassung. Eine zufällige ID beweist keine Anonymität. Vor Teamnutzung mit Produktivcode gehören Providerfreigabe, Secret-Regeln und Telemetrie deshalb auf die Prüfliste.

In den ausgewerteten Quellen fehlen unabhängige Messungen zu weniger Fehlern oder geringeren Token- und Gesamtkosten. Die geordnete Oberfläche ist ein nachvollziehbarer Ansatz, aber noch kein Produktivitätsbenchmark.

FAQ: Häufig gestellte Fragen zu ThinkRail

Brauchst du ein JetBrains-AI-Abo?

Nein. Laut README kannst du auch einen eigenen, von Pi unterstützten Provider verbinden. Dessen Nutzungsbedingungen und Kosten gelten weiterhin.

Musst du Pi vorher separat installieren?

Nein. ThinkRail bringt Pi als eingebettete Bibliothek mit. Eine vorhandene Pi-Konfiguration kann es weiterverwenden.

Kannst du Dateien direkt wie in einer klassischen IDE bearbeiten?

Die geprüfte Dateiansicht ist read-only. Für manuelles Editieren kannst du den Worktree laut README in einer externen IDE öffnen.

Verhindern Living Specs falsche Änderungen?

Nicht automatisch. Die Spec-Werkzeuge organisieren Dokumente und Metadaten; fachliche Korrektheit musst du weiterhin mit Review und Tests prüfen.

Fazit

ThinkRail ist einen begrenzten Versuch wert, wenn du Pi-Aufgaben, Git-Worktrees und Reviews bisher mühsam zusammenhältst: Starte mit einem kleinen Repository und einer klar prüfbaren Änderung. Erwarte einen organisierten Agentenarbeitsplatz, keinen belegten Qualitäts- oder Kostensprung und keinen vollständigen Ersatz für deine bisherige IDE. Die Grundlagen stehen im Pi-Guide; persistente Agententeams mit OpenRig behandeln einen anderen Organisationsansatz.

Quellen

Alle Quellen abgerufen am 31.10.2026. Produktfunktionen sind auf den gebundenen Release-Stand bezogen.

Primärquellen

• JetBrains: README v0.3.0, Release und Downloads, Lizenz und Repository-Metadaten.
• ThinkRail: Releasebericht, Review-turn-Konzept, Spec-Driven Development und Pi-Kompatibilität.
• Versionierter Quellcode: Spec-Graph-Spezifikation und read-only-Dateiansicht.

Externe Einordnung

• MODEL Editors: Begrenzter Receipt-Funktionsbericht mit Modellstub, keine eigene Reproduktion.
• DEV Community: Kritische Spec-Analyse ohne Installation, kein Wirkungsbenchmark.

Synthese

• Recherche-Notebook in NotebookLM: Syntheseschicht, nicht Ersatz für die verlinkten Originalquellen.