Was ist xNaut und für wen ist es?

Zu viele Fenster

Anfang 2026 habe ich mich hingesetzt und gefragt, was aus xNaut werden könnte. Ich hatte bereits eine CLI, die meiner eigenen Arbeit diente, aber mein Entwicklungs-Setup bedeutete immer noch, dass ich zwischen zu vielen Fenstern wechseln musste. Ich wollte die meisten dieser Tools in einem Arbeitsbereich haben.

Ich arbeite hauptsächlich in der Shell. Ausserdem habe ich viel Zeit in Zed verbracht und verschiedene Coding-Agent-Werkzeuge ausprobiert. Einige passten zu Teilen meines Ablaufs, andere frustrierten mich im Alltag. Ich schrieb auf, welche Terminalfunktionen ich wollte, und machte dasselbe für Coding-Agenten.

Diese Liste hat xNaut geprägt. Ich habe Ideen übernommen, die mir in anderen Tools gefallen haben, und sie in meine Arbeitsweise integriert. Ich verwende immer noch andere Anwendungen und manchmal sind zwei Fenster schneller. Ziel war es, den störenden Wechsel zu reduzieren.

Was ist xNaut?

xNaut vereint Projektterminals, Dokumente, Git-Worktrees und Codierungsagenten in einer Desktop-Anwendung. Sie können laufende Arbeiten verfolgen, Änderungen prüfen und die Informationen aufbewahren, die Sie zur Überprüfung eines Projekts neben seiner Ausführung benötigen.

Für durch Tickets koordinierte Arbeiten weist NautBot Aufgaben zu und verfolgt deren Ergebnisse. Ein Implementierungsagent nimmt die Änderungen in einem separaten Worktree vor. Ein Verifizierungsagent überprüft den Code und führt Tests durch, bevor das Ergebnis zur menschlichen Überprüfung zurückgegeben wird. Es können mehrere Tickets parallel ablaufen.

NautFlow und der gesamte Entwicklungslebenszyklus

Als Entwickler wollte ich, dass xNaut den gesamten Softwareentwicklungslebenszyklus unterstützt. Das Schreiben von Code ist ein Teil dieser Arbeit. Sie müssen ausserdem feststellen, ob es sich lohnt, das Produkt zu bauen, seine Anforderungen definieren und entscheiden, wie das Ergebnis getestet werden soll.

Im Jahr 2024 habe ich ein Tool entwickelt, das bei der Bewertung einer Produktidee und der Entwicklung ihres Geschäftsszenarios hilft. Ich habe auch mit einer Build-Schleife experimentiert, die Anweisungen aus einer Markdown-Datei nahm, die resultierenden Tickets durcharbeitete und ihre Arbeit im Laufe der Zeit überprüfte. Diese Projekte waren der Ausgangspunkt für NautFlow.

Ich habe mehrere Tools und Arbeitsabläufe ausprobiert, bevor ich meinen eigenen Ansatz in xNaut eingebracht habe. NautFlow verbindet den Geschäftsfall, die Anforderungen, die Architektur und die Tickets mit der Implementierung, dem Testen und der Veröffentlichung. Der vorgesehene Umfang umfasst sowohl die Produktwebsite als auch die Anwendung.

1. 01Geschäftlicher Bedarf
2. 02Anforderungen
3. 03Architektur
4. 04Tickets
5. 05Umsetzung
6. 06Test und Prüfung
7. 07Veröffentlichung

Beantwortung der Fragen vor dem Bau

NautFlow stellt in jeder Phase Fragen, prüft die Antworten und kehrt zu Punkten zurück, die einer Klärung bedürfen. Im geführten Prozess steuern Sie die Arbeit durch diese Gespräche. Im Expertenmodus haben Sie mehr Kontrolle darüber, wie die Phasen definiert werden.

Das braucht Zeit. Bei meiner eigenen Verwendung kann die Beantwortung von Fragen ein bis zwei Stunden dauern, bevor der Build beginnt, und die darauf folgende Arbeit kann viele Stunden in Anspruch nehmen. Die Fragen helfen herauszufinden, was die Anwendung tun soll und wie wir wissen, dass sie funktioniert.

Ich nenne das Speed-Coding. Ziel ist es, jemanden eine Idee in definierten Phasen entwickeln zu lassen, ohne jeden technischen Schritt im Voraus kennen zu müssen. xNaut ist der Ort, an dem ich diesen Prozess zusammenführe. Technische Entscheidungen und abgeschlossene Arbeiten müssen noch überprüft werden.

Einen Agenten dazu bringen, ein Ticket zu erledigen

Schwieriger war es, Agenten Aufgaben zuverlässig erledigen zu lassen. Nach meiner Erfahrung braucht ein Modell mehr als ein Ziel und die Erlaubnis, loszulegen. Es braucht Zugriffsgrenzen, eine kontrollierte Ausführungsumgebung und Prüfungen seiner Ergebnisse. In diesen umgebenden Ablauf ist ein grosser Teil meiner Arbeit an xNaut geflossen.

Der Workflow, den ich möchte, beginnt mit einem Ticket. Der Agent untersucht es, stellt Fragen und entwickelt einen Plan zur Überprüfung. Nach der Genehmigung implementiert es die Änderung, erstellt und testet sie in einer Sandbox und übermittelt das Ergebnis zur Überprüfung. Anschliessend werden die Änderungen festgeschrieben und gepusht, eine Pull-Anfrage vorbereitet und berichtet, was ausgeführt wurde, wobei die Prüfungen zur Überprüfung verfügbar sind.

Meiner Meinung nach ist der Workflow zu etwa 90 % auf dem Weg dorthin, wo ich ihn haben möchte. Das ist meine Einschätzung seiner Entwicklung, keine gemessene Erfolgsquote für Agentenläufe. Es funktioniert, aber die Zuverlässigkeit des gesamten Prozesses ist noch nicht abgeschlossen.

Wie die Teile zusammenpassen

Das Desktop-Fenster vereint Terminals, Projektdateien, Dokumente und Agentensteuerungen. Darunter verwaltet ein Rust-Backend die Terminalprozesse und bietet Zugriff auf Dateien, Git und konfigurierte Dienste. Tauri verbindet das Fenster mit diesem Backend.

Ein Terminalagent läuft als Prozess in seiner Sitzung. Der integrierte Agenten-Chat stellt eine Verbindung über die konfigurierten Modellanbieter her. Remote-Ausführung und Sandbox-Integrationen bieten andere Orte zum Ausführen von Arbeiten, während das Projekt seinen Code und seine Dokumente in Dateien und Git-Repositorys speichert.

Überprüfen Sie Ihre Arbeit per Telefon

Mir gefiel auch die Idee, die laufende Arbeit von einem Telefon aus zu verfolgen. Das veranlasste mich, einen mobilen Begleiter für xNaut zu entwickeln, der Sitzungstransparenz und Zugriff auf die Aktivitäten von Coding-Agenten bietet.

Die mobile Erweiterung ist noch nicht veröffentlicht. Es verbindet einen Telefonbrowser mit einer Bridge in der Desktop-Anwendung.

Für Entwickler, die mit Agenten arbeiten

Wenn Ihre Arbeit über Terminalfenster, Agentengespräche und Git-Zweige verteilt ist, bietet Ihnen xNaut einen Ort, an dem Sie sie gemeinsam verwalten können. Sie können sehen, welcher Agent an welcher Aufgabe arbeitet, und die von ihm erzeugten Änderungen prüfen.

Die Open-Source-Edition ist für den individuellen Gebrauch bestimmt. Es richtet sich an Personen, die bereits mit Entwicklungstools arbeiten und neben ihren Projekten auch ihre Coding Agents verwalten möchten.

Für Entwicklungsteams und technische Leiter

Teams müssen wissen, wem eine Aufgabe gehört, welche Revision getestet wurde und wer das Ergebnis genehmigt. xNaut verbindet Tickets mit der Implementierung, Verifizierung und abschliessenden Überprüfung, sodass diese Entscheidungen anhand der aufgezeichneten Arbeit getroffen werden können.

Die Enterprise Edition verwendet eine eigene Registrierung, um xNaut-Clients für die Teamzusammenarbeit zu verbinden. Dieser gemeinsame Workflow hat einen anderen Umfang und andere Bedingungen als die einzelne Open-Source-Edition.

Was Sie vor der Einführung überprüfen sollten

xNaut befindet sich in einem frühen Stadium. Überprüfen Sie, ob Ihre Agenten, Modellverbindungen und Ausführungsumgebungen unterstützt werden. Lokale Modelle sind eine Option, sofern sie kompatibel sind; Eine Modellverbindung allein stellt nicht sicher, dass ein bestimmter Agenten-Workflow funktioniert.

Probieren Sie ein repräsentatives Ticket aus und überprüfen Sie dessen Codeänderungen, Testergebnisse und Übergabe. Die Entscheidung, ob das Ticket geschlossen wird, obliegt der Person, die die Arbeit überprüft. Im nächsten Kapitel werden die Sitzungen, Worktrees und optionalen signierten Datensätze erläutert, die diesem Prozess zugrunde liegen.