Grok Build ist Open Source – erst die Agent Loop lesen
SpaceXAI veröffentlichte Grok Builds Agent Loop und TUI als Open Source. Im Architekturbüro entscheidet die Harness – nicht das Modell – was das Haus verlässt.
Die Supply-Chain-Spezifikationen des letzten Jahrzehnts – SPDX, CycloneDX, SLSA – ruhen alle auf einer dumpfen Prämisse: Man kann eine Abhängigkeit nicht sichern, die man nicht liest. Ein SBOM zeigt dir, was in der Box ist. Nicht, was die Box nach Hause sendet. Und den ganzen ersten Akt der Agentic-Coding-Ära gab es auf die zweite Frage keine ehrliche Antwort, weil die Harness – das Programm, das deine Dateien öffnet und mit einem Modell spricht – als Binary kam.
Das ändert sich am 15. Juli 2026. SpaceXAI veröffentlichte den Source von Grok Build – den Coding-Agenten und Terminal-UI – auf GitHub. Die Ankündigung ist ungewöhnlich direkt zum Grund: Bei Skills, Plugins, Hooks, MCP-Servern und Subagenten ist „der Source die definitive Referenz dafür, wie jeder geladen und aufgerufen wird.” Es ist Rust – cargo run, cargo clippy, cargo fmt – gesteuert von config.toml. Du kannst es kompilieren, auf eigene lokale Inference zeigen und nichts die Maschine verlassen lassen.
Die Loop ist der Kern
Zeichne einen Coding-Agenten als Boxen, du bekommst vier: Context Assembly, Model Call, Response Parsing, Tool Dispatch – zurück zu Box eins. Das Modell mietest du von aussen. Die Loop berührt deine Platte. Die Frage war nie, welches Modell, sondern welche Box entscheidet, was auf den Wire geht – Antwort: Box eins. Context Assembly ist die Engstelle, wo dein Repository still zur Payload wird. Bis diese Woche konnte das niemand ausserhalb des Vendors lesen.
Das Timing zählt hier. The Verge berichtete am gleichen Tag, dass Elon Musk X’s gesamte Codebasis „ohne Ausnahmen” open-sourcen will – und bemerkte beiläufig, dass Grok Build es schon „ein bisschen zu leicht” gemacht hat, deinen Code freizugeben. Explainx datiert die Veröffentlichung vier Tage nach einem Repository-Upload-Zwischenfall, wo Wire-Tests vollständige Git-Bundles erfassten. Die Harness zu veröffentlichen ist die richtige Korrektur. Aber sei dir klar: Open Source macht eine Harness nicht sicher, es macht sie auditierbar – und niemand im Büro hat einen Nachmittag, um zehntausende Zeilen Rust zu auditieren. Das heisst, die Default-Config zählt mehr als die Lizenz.
Was ein Git Bundle tatsächlich enthält
Übersetze „das Repo” in das, was auf der Festplatte eines Architekturbüros sitzt. Nicht ein Ordner Python. Die Wettbewerb-Einreichung, die .pln und ihre IFC-Exporte, Tender-PDFs mit Kostenstaffelung des Kunden, eine Vermessung unter NDA, achtzehn Monate Historie – jemand committed einen Scan, löscht ihn zwei Tage später. Gelöscht vom Working Tree; noch im Pack. Ein „Full Bundle” ist also nicht dein Projekt – es ist jede Version deines Projekts, die du je hattest.
←TODAY: Im Juli 2026 kommt die Harness endlich mit Source; die Default-Config entscheidet immer noch, was das Büro verlässt.
→3012: Zürich 3012 läuft auf Inference, die niemand mietet – lokale Weights, lesbare Loops, Dependency Graphs, die jeder Junior zeichnet.
Fulcrum: Ein audtierbarer Agent nützt nur einem Büro, das schon weiss, welche Ordner es ihm nie zeigt.
Atelier: Die Frage ist nicht, ob du Coding-Agenten erlaubst – deine Juniors laufen sie – sondern welche Ordner man je auf sie zeigt. Das ist jetzt eine Config-Entscheidung, nicht Vertrauen, weil Workspace Root und Tool-Allow-List in einer Textdatei leben, die du kontrollierst. Büros nach einem Datenhandling-Zwischenfall lernen: Die Policy, die bleibt, ist die geschriebene vor dem Tool, nicht danach. Montag-Zug: die einseitige Agent-Workspace-Regel – benannte Ordner, die ein Agent sieht, alles andere Tabu – in config.toml auf jeder Maschine verankern, bevor jemand Wettbewerb öffnet.
Hack: Den Wire wiegen, bevor du ihn öffnest – miss, was „Repo senden” tatsächlich übergeben wird: Megabyte und Geschichte. git bundle create --all produziert das gleiche Artefakt, das ein übereifriges Tool würde – jeden Branch, jeden Tag, jeden Blob, den du je committed hast. Lauf es auf einen aktiven Projektordner, lies die Grösse, grep die vollständige Historie nach Dateitypen, die du nie einem Fremden mailst. Wenn das dich überrascht – nicht hypothetisch, das ist dein Finding, dreissig Sekunden alt.
git bundle create /tmp/repo.bundle --all # genau was „Repo hochladen" bedeutet
git bundle verify /tmp/repo.bundle # jede Ref, die mitfährt
du -h /tmp/repo.bundle # die Payload, in MB
git log --all --oneline -- '*.pdf' '*.pln' '*.ifc' | head # Historie trägt noch gelöschte Dateien
Den Dependency Graph zeichnen
Das würde ich unterstreichen für jeden, der das 2026 liest. Wir liefen später nicht ohne Rechenleistung aus. Stattdessen ohne intakte Kühlung, intakte Bandbreite und Leute, die das alte System noch kannten. Single Points of Failure bleiben still bis zum Tag, wo sie es nicht sind – ein Agent-Harness, den du nicht liest, ist ein Single Point mit freundlicher TUI. Die Grok Build Release ist echte gute Nachrichten, und wie man sie nutzt: nicht das Tool adoptieren, sondern die Loop lesen, dann fragen, ob dein Stack eine äquivalente Box hat, die du nie öffnest. Jede Resilient-Inference-Referenz-Architektur, an der ich seitdem arbeitete, beginnt mit der gleichen dumpfen Übung, und Büros, die PAZ-GPT schon auf lokale Weights zeigen, haben nur das Endpoint-Ende gelöst. Zeichne deinen echten Dependency Graph diese Woche – nicht das Architektur-Diagramm, den Dependency Graph – und zähle den dritten Single Point, den du nicht kanntest.
Quellen & Weiterführendes
QUELLE · ↗
PAZ Kaffi · interdisziplinäre Redaktionsarbeit, geleitet von der PAZ Academy