Bifröst (AI Workspace) vs. OpenCode – Gaps und Arbeitsplan

Stand: 22.10.2026

Die größte Lücke unseres Chats gegenüber OpenCode ist die fehlende Rückmeldung zur Codequalität (Tests, Build, Diagnosen). Die übrigen Lücken schließen wir in Phasen, ohne neue Infrastruktur; Ausführung von Code (Sandbox) wird später als eigenes Thema geklärt.

Grundunterschied

OpenCode ist ein Coding-Agent für eine Person: lokal im Terminal, direkt im Arbeitsverzeichnis, mit den Rechten dieser Person. Unser Chat ist eine Team-Plattform: Er arbeitet auf dem Server mit einem eigenen Klon des Repositorys, führt keinen Code aus und protokolliert alles. Nach außen wirkt nur der Klick eines Menschen.

Die Angaben zu OpenCode beruhen auf dem Wissensstand von Claude, nicht auf einer aktuellen Recherche.

Vergleich

Thema	OpenCode	Unser Chat
Code ausführen (Tests, Build, Linter)	Ja, per Shell-Tool	Nein
Dateien bearbeiten	edit, write, patch direkt im Arbeitsverzeichnis	`commit_change` (ersetzen, neu schreiben, löschen) als Commit auf den Chat-Branch
Prüfung nach dem Bearbeiten	LSP-Diagnosen gehen an das Modell zurück	Keine; Fehler zeigen sich erst in CI oder Review
Suchen und Lesen	grep, glob, read, list, Web-Abruf	Lesende Git-Tools; kein Web-Abruf
Planung	Plan-Modus, Todo-Liste, Subagenten	Keine eigene Planungsstufe
Projektregeln	`AGENTS.md` mit Konventionen und Befehlen	Fehlt
Langer Kontext	Automatische Verdichtung	Token-Budget, Arbeitsnotiz, Weiterarbeiten
Rückgängig machen	Undo und Redo über Snapshots	Letzten nicht übertragenen Commit zurücknehmen
Berechtigungen	ask, allow, deny je Tool und Shell-Befehl, für eine Person	Risikoklassen, Policies, Freigaben, Rollen, Audit-Log, für viele Nutzer
Git und Pull Request	Macht die Person selbst oder der Agent per Shell	Branch je Chat; Push und PR per Klick; PR-Status und Review-Kommentare kommen zurück
Daten außer Code	Über MCP	Datenbanken, Uploads mit DuckDB, MCP, Gedächtnis
Betrieb und Kosten	Lokal, eigener API-Schlüssel	Zentral: Kontingente, Kosten, Monitoring, Backup

Lücken

Aufwand: S bis 1 Tag, M einige Tage, L mehr als eine Woche oder abhängig von Infrastruktur.

Lücke	Wirkung	Aufwand	Phase
Keine Rückmeldung zur Qualität (Tests, Build, Diagnosen)	Hoch: Die KI kann nicht prüfen, ob ihr Code funktioniert	L	später
Keine Projektregeln aus dem Repo	Hoch: Stil und Konventionen werden nicht eingehalten	S	1
Kein Plan-Modus, keine Todo-Liste	Mittel: Große Aufgaben laufen ohne abgestimmten Plan	M	2
Keine statische Prüfung beim Commit (Syntax, JSON, YAML)	Mittel: Offensichtliche Fehler gehen durch	S	3
Werkzeuge für große Änderungen (Patch, Pfadsuche)	Mittel: Viele Schritte und Tokens bei Änderungen über mehrere Dateien	M	3
Keine Subagenten	Niedrig: Der Hauptkontext füllt sich bei Recherchen	M	4

Entscheidungen (22.10.2026)

Projektregeln: nur AGENTS.md.
Plan-Modus: per Schalter, nicht automatisch.
Statische Prüfung: bei Fehlern zunächst nur warnen, der Commit wird angelegt.
CI: bleibt vorerst außen vor (kein Build-Status aus Bitbucket).
Sandbox: ob und wie, wird später festgelegt. Container sind eine Möglichkeit; das wird als eigenes, späteres Thema vertieft. Konzept (OpenShift, ohne privilegierte Container): sandbox-konzept.md.

Arbeitsplan

Phase 1: Projektregeln aus dem Repo (S) – erledigt

AGENTS.md vom Stand des Chat-Branches bzw. des Ziel-Branches lesen
Größe begrenzen (z. B. 8 KB) und als Projektkonventionen in den Prompt geben, nachrangig zu den Plattform-Regeln
Im Chat anzeigen, welche Regeldatei aktiv ist
Tests, README, Konzept

Phase 2: Plan-Modus und Todo-Liste (M) – erledigt

Tool update_plan (write_internal): Die KI pflegt eine Todo-Liste je Chat (offen, in Arbeit, erledigt)
Liste sichtbar im Chat; Weiterarbeiten setzt beim nächsten offenen Punkt an
Schalter „Erst planen“: In diesem Modus bekommt die KI nur lesende Tools und das Plan-Tool, mit dem Knopf „Plan umsetzen“ gibt es die schreibenden dazu
Todo-Liste geht in die Arbeitsnotiz und die PR-Beschreibung ein
Tests, Doku

Phase 3: Werkzeuge und statische Prüfung (M) – erledigt

Statische Prüfung beim Commit, ohne Code auszuführen: Python-Syntax, JSON, TOML, XML, YAML; Warnungen gehen an die KI zurück und stehen am Commit
commit_change nimmt auch einen Unified Diff (Patch) über mehrere Dateien an, inkl. Löschen und Umbenennen
Pfadsuche (Glob) als lesendes Tool: gab es schon als git_find_files
Tests, Doku

Phase 4: Subagenten (optional, M)

Lesende Teilaufgaben (z. B. „alle Aufrufer finden“) mit eigenem Kontext ausführen; zurück kommt nur das Ergebnis

Später, eigenes Thema: Rückmeldung zur Qualität

Sandbox: ein abgeschotteter Container je Lauf, ohne Netz, ohne Secrets, mit Zeit- und Speicherlimit; führt vom Workspace-Admin je Repo festgelegte Befehle aus (Tests, Linter), als Tool run_checks. Keine freien Shell-Befehle.
Build-Status aus Bitbucket: nur, falls die CI auf ai/*-Branches läuft und den Status meldet.

Bewusst nicht übernehmen

Freie Shell auf dem Server: widerspricht dem Sicherheitsmodell. Ausgeführt wird höchstens in einer Sandbox, mit festgelegten Befehlen.
Schreiben ohne Commit: Jede Änderung bleibt ein nachvollziehbarer Commit auf dem Chat-Branch.
Push oder PR durch die KI: bleibt ein Klick eines Menschen.

5.6 KiB Raw Permalink Blame History Unescape Escape