Spettro ist ein kleiner Open-Source-Coding-Assistent mit bewusst sichtbarem Arbeitsablauf. Er läuft im Terminal, trennt Planung und Implementierung, zeigt den aktiven Agenten und den Berechtigungsmodus an und bewahrt genügend Sitzungszustand auf, um später weiterzuarbeiten. Das Projekt ist in Go geschrieben, verwendet eine Bubble-Tea-Terminaloberfläche und steht unter der GPL-3.0. Zum Zeitpunkt der Prüfung zeigte das Repository 37 Sterne und sechs Forks; die jüngste markierte Veröffentlichung war v2.8.2 vom 4. Oktober 2026. Diese Zahlen sind relevant: Spettro ist ein frühes Projekt zur Bewertung, keine etablierte Grundlage für einen unternehmensweiten Entwicklungsprozess.

Redaktionelle Illustration eines Terminal-Coding-Agenten mit sichtbarem Plan, Freigabe, Werkzeugaufrufen und Berechtigungsgrenzen.

Die interessante Frage lautet deshalb nicht, ob Spettro einen ausgereiften Coding-Assistenten ersetzen kann. Das ist bisher nicht belegt. Die bessere Frage ist, ob sein Design agentengestützte Arbeit leichter beaufsichtigbar macht. Bei diesem engeren Test vertritt Spettro eine schlüssige Position: Der Agent soll innerhalb einer erklärten Projektgrenze arbeiten, Änderungen vor der Ausführung vorschlagen, benannte Rollen statt eines einzigen riesigen Prompts verwenden und eine Spur von Tool-Aufrufen hinterlassen, die Entwickler prüfen können.

Für Open Source ist das eine sinnvolle Richtung. Viele Coding-Agenten wetteifern darum, wie viel Code sie mit einer einzigen Anweisung verändern können. Spettro verwendet einen größeren Teil seiner Oberfläche darauf, was vor und neben der Änderung geschieht. Das macht das Projekt interessant für Entwickler, die Agentensteuerung untersuchen, lokale Workflows aufbauen oder zu einer jungen Go-Anwendung beitragen möchten. Gleichzeitig gibt es viele Gründe, Experimente strikt abzuschotten.

Was Spettro tatsächlich ergänzt

Das Projekt beschreibt sich als terminalorientierten Coding-Assistenten mit mehreren Agenten. Die Formulierung könnte austauschbar mit einer wachsenden Zahl von Kommandozeilenwerkzeugen klingen, doch Spettros Struktur ist konkreter. Zum Repository gehören ein Agenten-Manifest, Prompt-Dateien, eine Terminaloberfläche, Provider-Konfiguration, Workflow-Unterstützung, persistente Sitzungen, Skills, Speicher, Hooks und ein separater ACP-Modus für die Editor-Integration. Die eingebauten Rollen decken Planung, Programmierung, Rückfragen, Erkundung, Git-Arbeit, Tests, Review und Dokumentation ab.

Die entscheidende Einheit ist nicht die einzelne Rolle, sondern die Übergabe. Ein Planungsagent kann ein Repository untersuchen und eine Folge von Änderungen vorschlagen; anschließend kann ein Coding-Agent einen freigegebenen Plan ausführen. Danach lassen sich Test- und Review-Rollen aufrufen. Manifest und Prompt-Dateien liegen sichtbar im Repository und nicht in einer undurchsichtigen serverseitigen Konfiguration. Das macht die Ausgabe nicht automatisch korrekt, gibt Maintainerinnen und Maintainer aber etwas Konkretes zum Lesen, Forken und Ändern.

Auch die Standardinteraktion ist absichtlich verfahrensorientierter als ein einzelnes Chatfeld. Spettro fordert dazu auf, einen Projektordner zu vertrauen, einen Modell-Provider anzubinden, ein Modell auszuwählen und mit dem Planungsagenten zu beginnen. Die README dokumentiert Befehle wie /plan, /approve, /permission, /models, /skills, /compact und /resume. Diese Begriffe zeigen, wie die Entwickler das Werkzeug verstanden wissen wollen: Eine Sitzung ist eine Arbeitsumgebung, ein Plan ein prüfbares Objekt und ein Berechtigungsmodus Bestandteil der Aufgabe – kein verborgenes Implementierungsdetail.

Das hat einen praktischen Vorteil. Wenn eine Agentensitzung schiefläuft, lautet die Diagnose oft nicht einfach „Das Modell war schlecht“. Wahrscheinlicher ist, dass der Agent zu viel Zugriff auf das Dateisystem hatte, eine Aufgabe nicht zerlegt wurde, ein Befehl im falschen Verzeichnis lief, ein Tool-Ergebnis nicht geprüft wurde oder eine unterbrochene Sitzung ihren Kontext verlor. Ein Workflow, der diese Phasen benennt, bietet dem Bediener mehr Stellen zum Anhalten und Nachsehen.

Berechtigungen sind die zentrale Geschichte

Spettros stärkster Open-Source-Aspekt ist der Versuch, die Berechtigungsgrenze nahe an die Ausführungsschicht zu rücken. Auf seiner Website erklärt das Projekt, dass sich Sandbox-Befehle unter macOS mit Seatbelt, unter Linux mit Landlock und unter Windows mit Mandatory Integrity Control eingrenzen lassen. Außerdem dokumentiert es Dateisystemmodi wie off, workspace-write und read-only sowie Netzwerkregeln wie all, localhost, none oder eine ausdrückliche Liste von Ports.

Diese Details sind aussagekräftiger als ein allgemeines Versprechen, der Agent sei „sicher“. Sie beschreiben eine Richtlinienoberfläche, die ein Bediener prüfen kann. Laut Projekt kann die Richtlinie über Kommandozeilenoptionen oder ein Agenten-Manifest vorgegeben werden; das Modell selbst kann sie weder untersuchen noch ändern. In einem Coding-Agent-Kontext ist das die richtige Grenze: Das Sprachmodell darf einen Shell-Befehl vorschlagen, aber die Laufzeit auf dem Host sollte entscheiden, ob dieser Befehl eine Datei, ein Verzeichnis, ein Gerät oder ein Netzwerkziel erreichen darf.

Die Unterscheidung ist besonders wichtig bei lokalen Modellen oder API-kompatiblen Diensten. Die Wahl des Providers beseitigt kein Ausführungsrisiko. Ein lokales Modell kann weiterhin einen destruktiven Befehl erzeugen. Ein gehostetes Modell kann ein Repository weiterhin falsch verstehen. Auch eine kleine Open-Source-Laufzeit kann einen Fehler in ihren Berechtigungsprüfungen enthalten. Sandboxing begrenzt den möglichen Schaden; es beweist nicht, dass jeder Workflow sicher ist.

Der erste Test sollte deshalb bewusst langweilig sein:

1. Ein Wegwerf-Repository ohne Zugangsdaten anlegen.
2. Spettro im Nur-Lesen- oder Ask-first-Modus starten.
3. Um einen Plan bitten, der nur eine kleine Änderung beschreibt.
4. Vorgeschlagene Tool-Aufrufe und Pfade prüfen.
5. Eine Änderung mit offensichtlichem Test und einfacher Rücknahme freigeben.
6. Den Vorgang bei deaktiviertem Netzwerk wiederholen.

Starte nicht mit einem Home-Verzeichnis, einem Produktions-Checkout, einem Verzeichnis mit SSH-Schlüsseln oder einem Repository, das Zugriff auf Zugangsdaten für Deployments hat. Dass ein Projekt Berechtigungsmodi anbietet, ist ein Grund, diese Modi zu testen – kein Grund, den Test zu überspringen.

Die Freigabe ist nützlich, aber kein Review-Ersatz

Spettro trennt in seinen strengeren Modi Planung und Ausführung durch einen /approve-Schritt. Das ist ein gutes Interaktionsmuster, weil es Menschen die Möglichkeit gibt, den vorgesehenen Umfang zu prüfen, bevor Werkzeuge Dateien verändern. Zugleich entsteht eine natürliche Stelle für eine eigene Checkliste: erlaubte Verzeichnisse, erwartete Dateien, auszuführende Tests, erzeugte Artefakte und Befehle, die tabu bleiben müssen.

Es gibt jedoch eine Grenze. Eine Freigabe kann zum Ritual werden, wenn der Plan zu breit oder zu schwer lesbar ist. Die Zeile „Authentifizierungsablauf aktualisieren und zugehörige Tests reparieren“ ist keine sinnvolle Kontrolle, nur weil sie freigegeben wurde. Ein brauchbarer Plan braucht einen begrenzten Dateisatz, einen Grund für jede Änderung und einen Prüfschritt. Spettro kann den Workflow sichtbar machen, doch seine Qualität hängt weiterhin von Prompts, Repository-Anweisungen und den Gewohnheiten der Beteiligten ab.

Dasselbe gilt für den autonomen Zielmodus. Das Projekt dokumentiert einen /goal-Befehl, mit dem die Laufzeit über mehrere Iterationen hinweg weitermachen, Stillstände erkennen, den Fortschritt fortsetzen und bei einem als erledigt markierten Ziel stoppen kann. Das mag bei langen Aufgaben bequem sein, erhöht aber die Bedeutung von Kontrollpunkten. Eine Zielschleife sollte wie eine Build-Pipeline mit menschlich festgelegtem Budget und Endbedingung behandelt werden – nicht wie ein Versprechen, der Agent werde selbst wissen, wann genug getan ist.

Für einzelne Entwickler liegt der brauchbare Mittelweg darin, den Zielmodus nur bei Aufgaben mit enger Definition of Done einzusetzen. „Parser für diese fünf Beispiele ergänzen und Tests schreiben“ ist prüfbar. „Die Architektur verbessern“ ist es nicht. Sobald Abhängigkeiten, Zugangsdaten, Migrationen, Deployment-Dateien oder sicherheitskritischer Code betroffen sind, sollte man zu einem planorientierten Ablauf zurückkehren und die Schleife kurz halten.

Mehrere Agenten bedeuten nicht automatisch bessere Ergebnisse

Spettro bewirbt das parallele Starten von Unteragenten sowie spezialisierte Orchestrator- und Worker-Rollen. Das kann helfen, wenn sich die Arbeit natürlich aufteilen lässt: Eine Rolle erkundet das Repository, eine andere bereitet Tests vor, eine dritte prüft einen Patch und ein Orchestrator führt die Ergebnisse zusammen. Es kann aber auch Zeit und Tokens verschwenden, wenn mehrere Agenten dieselbe Suche wiederholen oder widersprüchliche Vorschläge liefern.

Der Wert entsteht durch Rollengrenzen, nicht durch die Anzahl der Agenten. Eine gute Zerlegung gibt jedem Worker eine andere Frage und ein klares Ausgabeformat. Eine Erkundungsrolle könnte beispielsweise relevante Pakete und bestehende Tests identifizieren; eine Coding-Rolle könnte auf einen Implementierungsplan beschränkt werden; eine Review-Rolle könnte ausschließlich nach Regressionen und fehlender Abdeckung suchen. Wenn jede Rolle dieselbe vage Anweisung erhält, ist Parallelität nur vervielfachte Unsicherheit.

Der manifestgesteuerte Ansatz des Repositorys ist vielversprechend, weil diese Rollendefinitionen bearbeitbar sind. Maintainer können prüfen, was dem Planer gesagt wird, den Review-Prompt ändern, eine projektspezifische Dokumentationsrolle ergänzen oder eine nutzlose Rolle entfernen. Das ist näher an herkömmlicher Open-Source-Anpassung als an einem Anbieter-Dashboard, bei dem sich das Verhalten ohne lokalen Diff verändert.

Damit entsteht allerdings auch Pflegeaufwand. Prompt-Dateien gehören zum Verhalten des Systems. Sie brauchen Tests, Versionierung und Reviews. Eine Änderung an einer Agentenanweisung kann ebenso folgenreich sein wie eine Änderung an einem Command-Handler, insbesondere wenn sie verändert, wann Tools aufgerufen werden oder wie viel Kontext einfließt. Projekte, die Spettro einsetzen, sollten Agenten-Manifeste mit derselben Sorgfalt prüfen wie CI-Konfigurationen und Entwicklungsskripte.

Provider-Flexibilität hilft, verlagert aber Verantwortung auf den Bediener

Das Projekt dokumentiert Unterstützung für Anthropic, OpenAI-kompatible APIs und lokale Endpunkte wie LM Studio oder Ollama. Außerdem bewirbt es Provider-Routing, einen Modellkatalog und vereinheitlichte Reasoning-Stufen. Für Experimente ist das nützlich: Ein Entwickler kann einen gehosteten mit einem lokalen Anbieter vergleichen, ein günstigeres Modell für die Repository-Erkundung einsetzen oder eine sensible Codebasis an einem internen Endpunkt betreiben, sofern dieser zuverlässig genug ist.

Provider-Unabhängigkeit ist nicht dasselbe wie Modellunabhängigkeit. Verschiedene Modelle interpretieren Tools, Kontextgrenzen, strukturierte Ausgaben und Freigabeanweisungen unterschiedlich. Ein Prompt, der bei einem Provider einen sorgfältigen Plan erzeugt, kann bei einem anderen nur eine oberflächliche Zusammenfassung liefern. Ein Modell, das eine kurze Go-Änderung gut bewältigt, kann an einem großen Monorepo scheitern. Die Laufzeit kann einen Befehl wie /thinking high vereinheitlichen, aber sie macht die zugrunde liegenden Modelle nicht gleichwertig.

Die beste Bewertungsmethode hält die Aufgabe konstant. Verwende ein kleines Benchmark-Repository, definiere erwartete Dateien und Tests und führe dieselbe Aufgabe mit zwei Providern aus. Notiere, ob der Plan den richtigen Code erkennt, ob der Agent vor Tool-Aufrufen fragt, ob der fertige Patch die Tests besteht und wie viel menschliche Korrektur nötig war. Das liefert ein brauchbareres Ergebnis, als die Oberfläche nach einer einzigen beeindruckenden Demo zu beurteilen.

Hinzu kommt die Frage der Datenverwaltung. Das Repository erklärt, dass Schlüssel verschlüsselt werden, und die Website stellt gehostete und lokale Provideroptionen dar. Trotzdem sollten Nutzer Konfigurations- und Speicher-dokumentation lesen, bevor sie Zugangsdaten verbinden. Sie müssen klären, welcher Prozess den Schlüssel lesen kann, wo Sitzungsdaten gespeichert werden, ob Prompts und Tool-Ausgaben dauerhaft abgelegt werden und ob eine aktivierte Web- oder Relay-Funktion einen weiteren Datenpfad eröffnet. „Bring your own key“ ist eine Bereitstellungsentscheidung, keine vollständige Datenschutzrichtlinie.

ACP macht Spettro mehr als eine Terminal-Kuriosität

Spettro kann als Agent-Client-Protocol-Agent über Standardeingabe und -ausgabe laufen. Die ACP-Dokumentation erklärt, dass Editoren wie Zed und Neovim-Plugins ihn über eine native Agentenschnittstelle steuern können und dabei die vorhandenen Provider-, Modell-, Berechtigungs-, Manifest- und Sandbox-Einstellungen wiederverwenden. Das ist eine praktische Designentscheidung. Der Entwickler kann die Ausführungsrichtlinie in einer Laufzeit behalten und trotzdem die Frontend-Oberfläche wechseln.

Das ist relevant, weil terminalorientierte Werkzeuge häufig vor einer falschen Wahl stehen. Sie können einen starken Kommandozeilen-Workflow anbieten, verlangen dann aber den Verzicht auf einen Editor. Oder sie integrieren sich tief in einen bestimmten Editor und übernehmen dessen Annahmen. ACP schafft eine mögliche Nahtstelle zwischen diesen Bereichen. Spettro bleibt die Agentenlaufzeit, während ein Editor zum Ort wird, an dem Prompts, Diffs und Rückfragen erscheinen.

Diese Nahtstelle ist zugleich ein Ort, an dem Fehler verborgen sein können. Editor-Integrationen bringen Protokollübersetzung, Lebenszyklusverwaltung, Streaming-Ausgabe, Abbruch und Berechtigungsdialoge hinzu. Ein Fehler im Client kann eine sichere Richtlinie defekt erscheinen lassen; eine verwirrende Oberfläche kann dazu führen, dass jemand etwas freigibt, ohne den Umfang zu verstehen. Frühe Nutzer sollten ACP mit denselben Einschränkungen wie im Terminal testen und bestätigen, dass ein Abbruch die zugrunde liegende Operation wirklich beendet.

Der stärkste Fall für ACP besteht derzeit nicht darin, dass es einen Editor-Assistenten ersetzt. Entscheidend ist, dass sich das Projekt dadurch leichter in einen bestehenden Workflow einfügt, ohne die erklärten Kontrollen der Laufzeit aufzugeben. Das ist ein architektonischer Vorteil, den man beobachten sollte, besonders wenn weitere Clients das Protokoll implementieren.

Fernsteuerung und Telegram erfordern besondere Vorsicht

Das Repository dokumentiert eine lokale Fernsteuerungsebene und einen Modus, der diese Steuerung für Geräte im LAN verfügbar machen kann. Zusätzlich wird ein Telegram-Relay beschrieben. Diese Funktionen können für Entwickler hilfreich sein, die eine Sitzung von einem anderen Gerät aus beobachten oder steuern wollen. Sie verändern jedoch das Bedrohungsmodell erheblich. Ein Terminalwerkzeug, das ausschließlich lokale Eingaben liest, ist etwas anderes als ein Werkzeug, das entfernte Befehle akzeptiert.

Die sichere Standardeinstellung besteht darin, Fernfunktionen deaktiviert zu lassen, bis Authentifizierung, Bind-Adresse, Transportsicherheit und Befehlsautorisierung verstanden sind. „Loopback“ ist enger als eine LAN-Freigabe, ersetzt aber nicht die Prüfung der Implementierung. Einen lokalen Web-Endpunkt können weiterhin andere Prozesse, Browser-Erweiterungen oder weitergeleitete Ports erreichen. Ein Chat-Relay bringt ein Drittanbieter-Konto, Nachrichtenaufbewahrung, den Umgang mit Bot-Tokens und die Möglichkeit mit sich, dass ein Gesprächsbefehl als Anweisung zur Änderung eines Repositorys interpretiert wird.

Wenn ein Fernmodus nötig ist, verwende ein Wegwerfprojekt, binde ihn an die kleinstmögliche Schnittstelle, halte die Dateisystemrichtlinie restriktiv und prüfe vor der Verbindung mit einem echten Checkout, welche Befehle verfügbar sind. Behandle einen sichtbaren Chatverlauf nicht als Prüfspur, solange das Projekt nicht dokumentiert, wie es Tool-Aufrufe, Freigabeereignisse und Fehler protokolliert.

Das ist keine Kritik, die nur Spettro betrifft. Für Agentenlaufzeiten gilt allgemein: Jede Komfortfunktion, die die Erreichbarkeit erhöht, verdient eine eigene Sicherheitsprüfung. Der offene Quellcode macht eine solche Prüfung möglich, führt sie aber nicht automatisch durch.

GPL-3.0 ist eine bewusste Entscheidung

Spettros Repository weist das Projekt als GPL-3.0-lizenziert aus. Das unterscheidet sich deutlich von den permissiven Lizenzen vieler Entwicklerbibliotheken. Entwickler dürfen das Programm unter den Bedingungen der GPL ausführen, untersuchen, verändern und weitergeben. Organisationen, die es in ein proprietäres, verteiltes Produkt einbetten wollen, brauchen jedoch eine rechtliche Prüfung der Kombination und Weitergabe.

Die Lizenz passt zur erklärten Haltung des Projekts. Spettro ist nicht nur ein SDK, das hinter einem gehosteten Dienst verborgen liegt; das Repository enthält Laufzeit, Prompts, Installationsskripte und Dokumentation. Eine starke Copyleft-Lizenz kann die Freiheit sichern, modifizierte Versionen zu untersuchen und weiterzugeben. Sie kann zugleich die Zahl der Organisationen verringern, die das Projekt als Bestandteil eines geschlossenen kommerziellen Werkzeugs einsetzen möchten.

Aus der Lizenz sollte man nicht mehr ableiten, als dort steht. GPL-3.0 garantiert weder Support, Sicherheitsreaktionszeiten, reproduzierbare Builds noch eine stabile API. Das sind Fragen der Projektführung und des Release-Engineerings. Die jüngste Release-Seite zeigte v2.8.2, während die README für den Build aus dem Quellcode Go 1.26.1 oder neuer dokumentiert. Das belegt ein aktives und schnell veränderliches Projekt, aber keine langfristige Kompatibilität.

Die Release-Historie sagt „ausprobieren“, nicht „standardisieren“

Die jüngste auf GitHub gelistete markierte Veröffentlichung, v2.8.2, wurde am 4. Oktober 2026 publiziert. Die vorherige v2.8.1 ergänzte ein animiertes Terminal-Logo; v2.8.0 erschien am 28. September. Die sichtbare Taktung deutet auf ein Projekt hin, das sich schnell durch Änderungen an Oberfläche und Workflow bewegt. Für frühe Nutzer, die rasch Verbesserungen sehen wollen, kann das positiv sein. Teams, die auf allen Rechnern stabiles Verhalten benötigen, kann es dagegen Schwierigkeiten bereiten.

Zum Zeitpunkt der Prüfung zeigte die Zusammenfassung der Release-Seite außerdem keine Issue- oder Pull-Request-Zahl, während die Hauptseite eine kleine Community erkennen ließ. Diese Signale müssen vorsichtig interpretiert werden; sie sind Momentaufnahmen und keine Qualitätsbewertung. Sie bedeuten jedoch, dass viele wichtige Fragen wahrscheinlich durch die Lektüre des Codes beantwortet werden müssen und nicht durch jahrelange Berichte aus der Community.

Vor dem Einsatz einer neuen Version sollte die Veröffentlichung oder der Commit festgepinnt, das bisherige Binary aufbewahrt und ein fester Smoke-Test ausgeführt werden. Dieser Test sollte Projektvertrauen, Provider-Einrichtung, Plangenerierung, Freigabe, eine kontrollierte Dateibearbeitung, Testausführung, Sitzungsfortsetzung und das Beenden umfassen. Wer ACP nutzt, ergänzt Editor-Start, Abbruch und Berechtigungsdialoge. Wer Fernsteuerung nutzt, ergänzt Authentifizierungs- und Netzwerkgrenzentests.

Ein kleiner Test-Harness ist mehr wert als eine große Demo. Er zeigt, wenn ein Abhängigkeitsupdate die Befehlsschnittstelle, den standardmäßigen Berechtigungsmodus, die Prompt-Struktur oder das Persistenzverhalten verändert.

Wer Spettro jetzt ausprobieren sollte

Spettro passt zu einigen klar umrissenen Gruppen.

Erstens zu Entwicklern, die Terminal-Workflows bevorzugen und mit Agentenrollen experimentieren möchten, ohne sich an einen Modellanbieter zu binden. Die Möglichkeit, gehostete oder lokale Provider anzuschließen und das Manifest zu untersuchen, ist für Vergleichstests nützlich.

Zweitens zu Open-Source-Maintainern, die sich für die Mechanik der Agentenaufsicht interessieren. Spettro ist klein genug zum Lesen, in einer vertrauten Sprache geschrieben und explizit bei Workflow-Bausteinen, die größere Werkzeuge häufig hinter einer Servicegrenze verbergen. Beiträge sind bei Prompts, Provider-Adaptern, Sandbox-Verhalten, ACP-Unterstützung, Tests, Dokumentation oder Release-Engineering denkbar.

Drittens zu Teams, die interne Prototypen bauen und dabei eher einen kontrollierbaren Task-Runner als eine ausgereifte Enterprise-Plattform brauchen. Ein eingeschränkter lokaler Workspace ohne Zugangsdaten kann ein sicherer Ort sein, um zu prüfen, ob Übergaben nach dem Muster „planen und freigeben“ die Review-Qualität verbessern.

Schlecht passt Spettro zu einem Team, das ein ausgereiftes, unterstütztes Flottenprodukt mit garantierter Upgrade-Kompatibilität sucht. Ebenso ungeeignet ist es als erste Wahl für unbeaufsichtigte Änderungen an Produktionsinfrastruktur, für Repositorys mit sensiblen Zugangsdaten oder für Aufgaben, deren Abschluss nicht automatisch überprüft werden kann.

Ein praktischer Evaluierungsplan

Ein sinnvoller Versuch lässt sich an einem Nachmittag durchführen, wenn der Umfang klein bleibt. Beginne mit einem frischen Repository, das ein winziges Programm, einen fehlschlagenden Test und eine kurze README enthält. Baue Spettro aus einer festgepinnten Version oder verwende ein Release-Artefakt und lies anschließend die Einrichtungs- und Konfigurationsdokumentation des Projekts. Eine echte Anwendung sollte nicht der erste Test sein.

Setze das Dateisystem auf Nur-Lesen und das Netzwerk auf none. Bitte den Planungsagenten zu beschreiben, wie er den fehlschlagenden Test reparieren würde. Prüfe, ob er die relevante Datei erkennt und nicht behauptet, etwas geändert zu haben. Wechsle danach zu einem Workspace, der auf das Wegwerf-Repository begrenzt ist, und gib die kleinstmögliche Änderung frei.

Führe dieselbe Aufgabe anschließend mit einem zweiten Provider oder einem lokalen Endpunkt aus. Vergleiche Plan, Tool-Reihenfolge, finalen Diff, Tests und die Anzahl der Korrekturen. Unterbrich den Lauf. Schließe das Terminal und setze die Sitzung fort. Untersuche, was gespeichert wurde. Wenn du einen Editor über ACP verwendest, wiederhole dort die Freigabe- und Abbruchtests.

Erst nach diesen Prüfungen sollte ein echtes, aber nicht sensibles Repository hinzukommen. Halte den Agenten von Deployment-Zugangsdaten, Token für das Veröffentlichen von Paketen und persönlicher Konfiguration fern. Verwende einen separaten Arbeitsbaum oder einen Wegwerf-Branch. Notiere Version, Modell, Provider, Berechtigungseinstellungen und Repository-Anweisungen, damit ein späteres Ergebnis reproduziert werden kann.

Diese Methode liefert auch dem Projekt nützliches Feedback. Ein Fehlerbericht mit festgepinntem Versionsstand, kleiner Reproduktion, Berechtigungsmodus, Provider sowie erwartetem und beobachtetem Tool-Aufruf ist deutlich wertvoller als die Meldung, der Agent habe sich merkwürdig verhalten.

Was als Nächstes zu beobachten ist

Die nächsten sinnvollen Tests für Spettro sind keine weitere Befehlsliste, sondern Stabilität und belastbare Nachweise. Bleiben die Berechtigungssemantiken konsistent, während neue Funktionen hinzukommen? Lässt sich der Sitzungszustand nachvollziehbar und portabel machen? Bewahrt die ACP-Integration dieselben Freigabegarantien wie die Terminaloberfläche? Dokumentieren die Maintainer, wie Zugangsdaten, Prompts, Tool-Ausgaben und entfernte Relays gespeichert werden? Kann ein Beitragender ein Release aus dem Quellcode reproduzieren und verstehen, welche Änderungen das Verhalten des Agenten beeinflussen?

Der Open-Source-Status des Projekts macht diese Fragen öffentlich beantwortbar. Seine geringe Größe erleichtert Beiträge. Die aktuelle Reife bedeutet zugleich, dass die Antworten noch nicht feststehen. Genau deshalb gehört Spettro auf die Beobachtungsliste: nicht als fertiger Ersatz für jeden Coding-Assistenten, sondern als konkretes Experiment, das Agentenarbeit nachvollziehbarer machen will.

Die nützlichste Idee von Spettro lässt sich einfach beibehalten: Autonomie sollte von klaren Grenzen umgeben sein. Ein Plan sollte vor der Ausführung sichtbar sein. Eine Rolle sollte eine definierte Aufgabe haben. Ein Tool-Aufruf sollte eine Richtlinie erben. Eine Sitzung sollte fortsetzbar sein, ohne rätselhaft zu werden. Die Software braucht weiterhin Härtung, Dokumentation, Sicherheitsprüfungen und eine größere Basis unabhängiger Nutzer. Bis dahin sollte man sie als vielversprechendes Labor behandeln – und das Labor abgeschottet halten.

Quellen

Die Einordnung stützt sich auf die vom Projekt bereitgestellte Repository- und README-Dokumentation, die Release-Historie, die offizielle Projektseite, die ACP-Dokumentation, den Dokumentationsindex und die im Repository ausgewiesene GPL-3.0-Lizenz. Die im Text genannten Versions-, Funktions- und Lizenzangaben beziehen sich auf den im Ausgangsmaterial beschriebenen Prüfstand und sollten bei einer späteren Nutzung erneut überprüft werden.