Coding Agents: Warum persönliche Setups kein Team-Play sind

Jetzt mal ganz ehrlich: Wenn in deiner Firma gerade fleißig Coding Agents eingesetzt werden, dann hast du vermutlich ein kleines Chaos auf den Schreibtischen deiner Entwickler.

Der eine hat seine eigene MCP-Konfiguration. Der andere hat sich ein paar Prompts gebaut, die außer ihm niemand versteht. Und der Dritte? Der hat ein ganzes System aus Scripts, das nur er durchschaut. Übersicht? Fehlanzeige. Was da als "Team-Infrastruktur" durchgeht, ist meistens nur eine Ansammlung von persönlichen Shortcuts, zusammengehalten von Hoffnung und mündlicher Überlieferung.

Genau dieses Problem ist Assembled auf die Füße gefallen. Ihre Coding Agents liefen für einzelne Entwickler super. Aber drumherum? Vollständiges Chaos.

Das Dilemma der persönlichen Coding Agents

Was passiert typischerweise? Developer A nutzt Claude Code mit Anbindung an seinen GitHub-Fork und Linear. Developer B schwört auf Codex mit Sentry-Integration und persönlichen Slack-Benachrichtigungen. Developer C hat sich ein Script-Monster gebaut, das nur er bedienen kann.

Und dann? Jemand verlässt das Unternehmen. Du musst reproduzieren, was der Agent eigentlich gemacht hat. Du willst prüfen, ob die Agent-Ausgabe auch tatsächlich dem entspricht, was am Ende committed wurde.

Irrsinn.

Das eigentliche Problem ist nicht, ob Coding Agents nützlich sind – sind sie. Das Problem ist, dass wir sie behandeln wie persönliche Texteditoren, statt wie echte Team-Infrastruktur. Das führt zu drei grossen Baustellen:

1. Wissenssilos — Nur eine Person weiss, wie der Agent konfiguriert ist
2. Reproduzierbarkeitslücken — Agent-Aktionen lassen sich nicht einfach wiederholen oder prüfen
3. Zusammenarbeitshürden — Was für einen Engineer funktioniert, hilft dem Rest des Teams nicht

143.dev: Coding Agents als geteilte Infrastruktur

Assembled hat intern eine Lösung gebaut – und jetzt als Open-Source-Projekt released. Herausgekommen ist 143.dev. Die Idee dahinter: Coding Agents werden auf eine Plattform gebracht, auf die das gesamte Team Zugriff hat.

Der Ansatz ist clever: Statt Agents lokal auf einzelnen Maschinen laufen zu lassen, betreibt man sie in standardisierten Umgebungen. Gleiche Tools für alle, volle Transparenz.

Was konkret bedeutet das?

Mehrere Agents, eine Plattform. Das System bringt Codex, Claude Code, OpenCode und andere Agent-Harnesses in gVisor-Sandboxes zum Laufen. Heisst: Du kannst je nach Kosten, Capabilities und Aufgabentyp den passenden Agent wählen. Assembled nutzt zum Beispiel GLM 5.2 für routine-mäßige Automatisierungsaufgaben (günstiger, schneller) und Codex oder Claude Code für komplexere Handarbeit. Gleiche Infrastruktur, verschiedene Agents für verschiedene Jobs.

Tool-Integrationen fertig an Bord. GitHub, Linear, Sentry, Slack, PagerDuty und mehr – alles direkt angebunden. Previews lassen sich einfach generieren. Deine Agents arbeiten nicht isoliert, sondern sind in deinen bestehenden Workflow eingebettet.

Sicherheit ohne Reibungsverluste. gVisor-Sandboxes sorgen für Isolation, ohne dass du vollständige VMs managen musst. Agents können arbeiten, bleiben aber in ihrer Sandbox.

MIT-Lizenz, self-hosted. Das ist kein gehostetes SaaS, dem du deinen Code anvertrauen musst. Du kannst den Code prüfen, auf eigener Infrastruktur betreiben und an deine Bedürfnisse anpassen. Assembled hat sich von Stripe's Minions und Ramp's Inspect-System inspirieren lassen, wollte aber etwas, das die breitere Community nutzen und weiterentwickeln kann.

Warum das für Startups und wachsende Teams relevant ist

Coding Agents werden nicht weniger – sie werden mehr. Und genau deshalb funktioniert der "persönliche Script"-Ansatz irgendwann nicht mehr.

Du brauchst:

• Audit-Trails — Was hat der Agent tatsächlich verändert?
• Reproduzierbarkeit — Kannst du dieselbe Aufgabe nochmal ausführen?
• Wissensaustausch — Kann jeder im Team Agent-Workflows nutzen?
• Sicherheit — Greifen Agents nur auf das zu, was sie sollen?

143.dev adressiert genau diese Punkte. Und weil es Open Source ist, musst du nicht darauf wetten, dass ein Startup in zwei Jahren noch existiert.

Der grössere Zusammenhang

Wir bewegen uns in eine Phase, in der KI-Codierungstools keine Spielereien mehr sind – sondern Infrastruktur. Und Infrastruktur muss auch so behandelt werden: mit Transparenz, Reproduzierbarkeit und Zugriff fürs ganze Team.

Persönliche Coding Agents sind ein Anfang. Team-managed Agent-Infrastruktur ist da, wo es spannend wird.

Wenn du ein Startup leitest oder ein Engineering-Team verwaltest: Ein Blick auf 143.dev lohnt sich. Der Code liegt auf GitHub, MIT-lizenziert. Kein Vendor Lock-in, keine versteckten Kosten – einfach offene Infrastruktur, die du an die Arbeitsweise deines Teams anpassen kannst.

Manchmal sind die besten internen Tools diejenigen, die es wert sind, geteilt zu werden.