Es ist 16 Uhr, und seit der Mittagspause arbeiten drei Coding-Agents im selben Repository. Einer hat die Rundung der Warenkorbsumme korrigiert, einer einen Rabattcode eingebaut, einer Tests geschrieben. Alle drei melden "done". Bevor irgendetwas main berührt, willst du zwei Dinge wissen: Haben zwei von ihnen dieselbe Funktion umgeschrieben, und laufen die drei Änderungen zusammen noch durch?
Drei Ansichten für eine Codebasis
osFoundry ist eine Desktop-App, die Chat, Agents, Dateien und Tools in einem Fenster bündelt, und für Code gibt es drei zusammenhängende Ansichten. In Code verteilst du Aufgaben an mehrere Agents gleichzeitig: Jeder Run bekommt einen eigenen Git-Branch und einen eigenen Arbeitsordner (einen Worktree), und du reviewst, testest und schaust dir den Merge in der Vorschau an, bevor du irgendetwas entscheidest. Nichts wird von selbst gemergt. Die IDE ist ein Code-Editor für einen lokalen Ordner, mit Explorer, Versionsverwaltung, Terminal, Problems- und Tests-Panel und einer Assistant-Spalte, die die gerade geöffnete Datei sieht. Wiki liest ein Repository auf deinem Rechner, schreibt Dokumentationsseiten mit path:line-Verweisen und markiert eine Seite, sobald sich der zitierte Code ändert. Code und Wiki liegen als Tabs neben Maestro, Model chat, Multi chat und Research; die IDE hat einen eigenen Eintrag in der Seitenleiste. Wer VS Code mit Git-Panel kennt, findet sich in der IDE sofort zurecht. Code ähnelt eher einer Pull-Request-Inbox, nur dass die Autoren deine Agents sind und die Branches deinen Laptop nie verlassen haben.
Ein Blick auf den Code-Tab
Was du auf diesem Screen siehst (die Runs sind Beispieldaten):
- Das Banner oben in der Leiste. "3 agents finished · they disagree on 1 file" nennt die Datei, hier
src/cart.js, noch bevor du einen einzigen Diff öffnest. Der Button Review together startet ein gemeinsames Review. - Die Run-Leiste. Runs sind danach gruppiert, was sie von dir brauchen: Ready to review, Needs attention und eine eingeklappte History. Jede Zeile zeigt die Aufgabe, hinzugefügte und entfernte Zeilen, wie lange der Agent gearbeitet hat, und den Branch.
- Die Unterhaltung in der Mitte. Klick auf einen Run, und du liest, worum der Agent gebeten wurde und was er während der Arbeit geschrieben hat.
- Das rechte Panel. Die Tabs Changes, Files, Commits, Review und PR zeigen den echten Diff jedes Runs, zuerst die nicht committete Arbeit, dann das, was auf seinen Branch committet wurde.
- Die Merge station unten rechts. Du wählst abgeschlossene Runs aus und testest sie hier und siehst dir in der Vorschau an, wie sie zusammen gemergt aussehen.
Anwendungsfall: eine Tech Lead mit drei Agents in einem Repo
Dana leitet ein kleines Webteam und teilt einen Checkout-Sprint auf drei Agent-Runs auf: Rundung in den Warenkorbsummen korrigieren, einen Rabattcode im Checkout ergänzen, Tests für den Preisformatierer schreiben. Jeder Run wurde über New run mit einer einzeiligen Aufgabe und einem passenden Agent gestartet. Jeder hat also seinen eigenen Branch und Ordner, und keiner kann den anderen bei der Arbeit in die Dateien pfuschen.
Als das Banner meldet, dass sie sich widersprechen, hakt sie alle drei Runs an und klickt Review together. Das Merge-Panel zeigt "3 runs · conflicts not checked yet · 3 not yet tested", ein ehrliches "wissen wir noch nicht" statt grünem Licht. Darunter ist src/cart.js als contested markiert, und die Hunks aus jedem Branch stehen nebeneinander: Sowohl der Rundungsfix als auch der Rabattcode haben total() umgeschrieben.
Als Nächstes drückt sie bei jedem Run auf test. Die Tests laufen im Worktree des jeweiligen Runs, ihr eigener Checkout bleibt also unangetastet. Standardmäßig gilt "Tests must pass before a branch can merge", und diese Regel lässt sich in den Settings ändern. Alle drei sind grün, aber einzeln grün ist nicht dasselbe wie zusammen grün, also drückt sie Preview combined merge. Die App mergt die Branches zuerst in einer Wegwerfkopie und meldet zurück: Zwei lassen sich sauber mergen, einer hat einen Konflikt.
Sie mergt die beiden sauberen Branches in ihren aktuellen Branch. Erst in diesem Moment ändert sich ihr Branch. Der Rabattcode-Branch bleibt bestehen, damit der Agent seine Änderung auf Basis des Rundungsfixes neu machen kann. Hätte sie statt ganzer Branches lieber das Beste aus jedem Versuch gewollt, hätte sie mit Combine into a branch einzelne Hunks anhaken und daraus einen neuen Branch bauen können.
Noch ein Detail, das an langen Tagen zählt: Wenn die App beendet wird, während ein Run arbeitet, kommt der Run als Interrupted zurück, nicht als "running", mit dem Hinweis, dass sein Branch erhalten bleibt.
Anwendungsfall: ein Solo-Entwickler refaktoriert mit einem Assistenten
Kenji betreut allein das Frontend eines Onlineshops. Heute Morgen muss er formatPrice ändern und weiß nicht genau, wer die Funktion aufruft. Er öffnet den Projektordner über die Seitenleiste in der IDE. Das Editor-Layout ist das übliche: Explorer und Source Control links, Tabs in der Mitte, Terminal, Output, Problems und Tests unten und rechts der Assistant, in dem er einen synchronisierten Chat oder einen lokalen Chat starten kann, der auf dem Gerät bleibt.
Er klickt mit rechts auf formatPrice und wählt Show Code Graph. Das Panel listet Callers und Calls. Ein gefüllter Punkt heißt, dass der Aufruf direkt aus dem Code gelesen wurde; ein hohler Punkt heißt, dass er erschlossen wurde, den sollte man sich also selbst ansehen. Impact of change verfolgt auch die Aufrufer der Aufrufer und zeigt in diesem Beispiel "15 symbols · 14 files · 3 tests". Ein Klick auf eine Zeile springt zu dieser Stelle, und Send to chat gibt den ganzen Graphen als Kontext an den Assistenten weiter.
Später bearbeitet der Assistent für ihn eine Konfigurationsdatei. In Source Control erscheint die Datei als geändert, und beim Öffnen zeigen ein kleines Roboter-Symbol und die Statuszeile, dass sie zuletzt von der KI geschrieben wurde, samt Modell und angegebenem Grund. Review öffnet einen Side-by-side-Diff gegen die Kopie, die direkt vor diesem Schreibvorgang gesichert wurde, er sieht also nur genau diese Änderung. Hier zeigt sie einen Timeout, der von 30 Sekunden auf 3 gekürzt wurde, direkt unter einem Kommentar, laut dem große Uploads 20 Sekunden oder länger dauern. Er bemerkt es vor dem Commit.
Schreibt ein Agent in eine Datei, in der er noch ungespeicherte Änderungen hat, meldet der Editor, dass sich die Datei während der Bearbeitung auf der Festplatte geändert hat, und bietet Keep mine oder Use the disk version an, statt stillschweigend eine Version zu wählen.
Anwendungsfall: eine Support-Engineerin, die den Code verstehen, nicht ändern will
Priya arbeitet im Kundensupport und wird oft gefragt, wie sich ein Teil des Produkts verhält. Sie kann Code lesen, will sich aber nicht per grep durch ein Repository wühlen, das nicht ihr gehört. In Wiki nutzt sie Open a folder (oder Clone a public repository mit einer https- oder git@-URL), und die App liest die Struktur des Projekts auf ihrem Rechner.
Bevor Wiki irgendetwas ins Projekt schreibt, fragt es nach. Ein Dialog nennt den genauen Ordner, den es im Repo anlegen wird, und wenn sie auf Not now klickt, wird nichts geschrieben. Sobald sie zustimmt, nutzt sie Generate pages oder Write a page für ein einzelnes Thema. In den Einstellungen legt sie fest, aus wie viel Quellcode jede Seite geschrieben wird (Depth: Quick, Standard oder Deep) und wie viele Aussagen geprüft werden (Verification: Off, Sample oder Full, wobei Full die Kosten ungefähr verdoppelt). Die Kosten werden angezeigt, bevor eine Seite generiert wird.
Jede Seite zitiert path:line, und ein Klick auf ein Zitat öffnet diese Zeile in der IDE. Einen Monat später ist eine Seite in der Leiste markiert, weil "a file this page cites has changed since it was written". Das sagt ihr, dass sie die Seite neu generieren sollte, bevor sie ihr vertraut. Für eine schnelle Einzelfrage nutzt sie den Chat neben den Seiten, dessen Antworten ebenfalls path:line aus diesem Projekt zitieren und in dem sie auch in normalen Worten eine neue Seite anfordern kann, etwa "write a page about the retry policy". Die Seiten selbst sind Markdown-Dateien im Repository, das Team kann sie also in denselben Pull Requests reviewen wie den Code.
Wo Code, IDE und Wiki übergeben
Diese drei Ansichten reichen sich gegenseitig und dem Rest der App Arbeit weiter. Ein Wiki-Zitat öffnet die IDE an der zitierten Zeile, und die IDE hat für den Rückweg einen Button Wiki for this folder. Der Assistant der IDE und der Chat neben den Wiki-Seiten basieren auf Maestro, demselben Assistenten, den du überall in osFoundry nutzt, Fragen dort funktionieren also wie in jedem Maestro-Chat. Um eine Codebasis nach Bedeutung statt nach exakten Wörtern zu durchsuchen, baut Indexes einen lokalen Suchindex, den Maestro nutzen kann. Und wenn ein Code-Run bereit ist, deinen Laptop zu verlassen, öffnet Open PR einen Pull Request für seinen Branch.
Die Produktseiten zeigen interaktive Demos von beiden: Code und die IDE.
Was Leute zuerst fragen
Brauche ich die Desktop-App?
Ja. Code, die IDE und Wiki arbeiten mit lokalen Ordnern, Git-Worktrees, einer Shell und Language Servern, deshalb laufen sie in der Desktop-App von osFoundry.
Mergt ein Agent jemals von selbst in meinen Branch?
Nein. Runs arbeiten auf eigenen Branches in eigenen Ordnern. Dein aktueller Branch ändert sich nur, wenn du auf merge drückst, und standardmäßig nur für Branches, deren Tests bestanden haben.
Ist Wiki ein Team-Wiki wie Notion?
Nein. Es schreibt Dokumentation aus einem Code-Repository, mit Datei- und Zeilenverweisen, und markiert Seiten, wenn sich dieser Code ändert. Es ist für Codebasis-Doku gedacht, etwa einen Architekturüberblick oder Onboarding-Notizen.
Was passiert mit einem Branch, der einen Konflikt hat?
Er bleibt, wo er ist. Du kannst die sauberen Branches jetzt mergen und den Agent den konfliktbehafteten darauf aufbauend neu machen lassen, oder mit Combine into a branch einzelne Hunks auswählen.
Die Desktop-App kannst du kostenlos unter osfoundry.io/de/download herunterladen.
