AI Agents in der Softwareentwicklung: Wie Muro uns in Slack Arbeit abnimmt

Bei smartive laufen inzwischen autonome AI Agents direkt in Slack herum. Sie beantworten nicht einfach Fragen. Sie arbeiten.

Einer davon heisst Muro.

Muro kann selbstständig Repositories öffnen, Code verändern, Tests ausführen, Merge Requests aktualisieren und Probleme in CI/CD-Pipelines beheben. Wir schreiben ihm in Slack eine Aufgabe – und bekommen im Idealfall einige Minuten später das Resultat zurück.

Zum Beispiel: @muro kannst du alle offenen Playwright-Updates in unseren Corporate Websites fixen?

Danach sucht Muro die betroffenen Merge Requests, checkt die Repositories aus, macht die notwendigen Änderungen, führt die vorhandenen Checks aus und pusht die Fixes.

Das ist der Punkt, an dem AI für uns gerade besonders spannend wird. Nicht weil ein LLM noch besseren Code generiert. Sondern weil wir ihm ganze Aufgaben übergeben können. Und inzwischen haben wir ziemlich gut herausgefunden, welche davon funktionieren.

Was Muro bei uns tatsächlich macht

Am Anfang waren es einzelne kleine Experimente. Inzwischen gibt es einige Kategorien von Arbeit, die wir regelmässig an Muro abgeben.

Er hält unsere Dependencies am Leben

Renovate und Dependabot erzeugen zuverlässig Updates — und genauso zuverlässig gibt es irgendwann Merge Requests, die nicht mehr automatisch durchlaufen. Lockfile-Konflikt. Breaking Change. TypeScript-Fehler. Angepasste CI-Konfiguration.

Muro rebased solche Branches, analysiert die Fehler, verändert den Code und führt danach die vorhandenen Checks aus. Besonders praktisch wird das bei Änderungen über mehrere Repositories hinweg. Ein Playwright-Update betrifft zehn Websites? Dann muss nicht jemand zehnmal praktisch dieselbe Arbeit machen. Muro kann die betroffenen Merge Requests finden, die Änderung auf alle anwenden und jeden Branch einzeln aktualisieren. Copy-Paste ohne Copy-Paste.

Er räumt hinter kaputten Pipelines auf

Eine Test-Suite ist rot. Ein Vercel-Build schlägt fehl. Ein E2E-Test funktioniert nach einem Update nicht mehr. Oft sind das keine wahnsinnig komplizierten Probleme — aber jemand muss sich darum kümmern.

Muro kann Logs lesen, die relevante Stelle in der Codebase suchen, einen Fix ausprobieren und danach die Tests erneut ausführen. Das nimmt uns keine schwierigen Architekturentscheide ab — aber erstaunlich viele kleine Blockaden.

Er behebt Security-Findings

Auch Security-Tools sind hervorragend darin, Arbeit zu produzieren. Ein Scanner wie Aikido meldet beispielsweise ein Problem. Daraus folgt vielleicht eine Änderung im Dockerfile, eine zusätzliche Rollenprüfung oder eine Anpassung an einer Server Action. Solche klar abgegrenzten Findings sind ziemlich gute Agent-Tasks: Problem bekannt, Ziel bekannt, Code vorhanden, Checks vorhanden. Zagg.

Er übernimmt kleinere Features und Fixes

Content Security Policy ergänzen. Eine SSO-Integration anpassen. Eine kleine UI-Erweiterung bauen. Eine Konfiguration korrigieren. Dinge, für die ein Mensch vielleicht 30 Minuten braucht — nur sind es selten wirklich 30 Minuten. Du musst zuerst das Repository finden, den Kontext wieder verstehen, die relevante Stelle suchen und herausfinden, wie das Projekt funktioniert. Der eigentliche Code ist manchmal der kleinste Teil der Arbeit. Muro bezahlt diesen Context-Switch deutlich billiger als wir.

Er liest Merge Requests, bevor wir es tun

Muro schreibt nicht nur Code — er kann auch bestehende Änderungen analysieren. Bei grösseren Dependency-Updates lassen wir ihn beispielsweise herausfinden:

• Was wurde verändert?
• Welche Breaking Changes sind relevant?
• Welche Bereiche unseres Codes könnten betroffen sein?
• Wie hoch ist das Risiko?
• Worauf sollten wir beim Review besonders achten?

Das ersetzt kein Review. Aber es verkürzt den Weg von «Was passiert hier eigentlich?» zu «Okay, auf diese drei Dinge muss ich schauen».

Er dient als Suchmaschine für unsere eigenen Codebases

«Wo konfigurieren wir das eigentlich?» «Warum macht dieses Projekt das anders als die anderen?» «Wie funktioniert der Auth-Flow hier?» Ein Agent kann solche Fragen anders beantworten als ein normales LLM. Er rät nicht anhand seines Trainingswissens, wie unser Code vermutlich aussieht. Er schaut nach. Gerade beim Onboarding oder in Projekten, in denen jemand länger nicht gearbeitet hat, ist das überraschend nützlich.

Und manchmal arbeitet er, ohne dass jemand fragt

Einige Aufgaben lassen sich noch einen Schritt weiter automatisieren. Muro kann periodisch offene Pull Requests, Builds oder andere technische Zustände überprüfen und auf Probleme reagieren. Damit verschiebt sich das Pattern von «Mensch entdeckt Problem → Mensch beauftragt Agent» zu «Agent entdeckt Problem → Agent bearbeitet Problem → Mensch bekommt Resultat». Da beginnt «autonom» langsam tatsächlich die richtige Bezeichnung zu werden.

Warum gerade diese Aufgaben gut funktionieren

Je länger wir Muro einsetzen, desto klarer wird ein Muster. Agents sind aktuell besonders stark, wenn vier Dinge zusammenkommen:

• Das Problem ist klar abgegrenzt.
• Der Agent hat Zugriff auf den benötigten Kontext und die richtigen Tools.
• Das gewünschte Resultat lässt sich technisch überprüfen.
• Ein Fehler ist korrigierbar, ohne dass gleich die halbe Architektur neu erfunden werden muss.

Ein kaputter Dependency-Merge-Request ist dafür fast ideal. Es gibt einen bestehenden Branch. Es gibt eine konkrete Fehlermeldung. Es gibt Code. Es gibt Tests. Und es gibt einen ziemlich eindeutigen Zustand namens grün.

Bei Fragen wie «Wie sollten wir dieses Produkt in den nächsten drei Jahren architektonisch aufbauen?» wird es schwieriger. Dort gibt es selten einen Test, der nach fünf Minuten sagt: Architekturentscheidung erfolgreich. 17 Tests passed. Leider. Dazu versuch ich vielleicht in Teil 3 oder 4 dieser Serie mal was zu unseren Software Factory Ansatz zu schreiben.

Hoffen ist keine Teststrategie

Das ist für uns momentan einer der wichtigsten Unterschiede zwischen «AI schreibt Code» und «AI erledigt eine Entwicklungsaufgabe». Muro verändert nicht einfach Dateien und behauptet danach, fertig zu sein. Er kann seine Arbeit überprüfen. Je nach Projekt beispielsweise mit:

• TypeScript
• ESLint
• Unit Tests
• Integration Tests
• Playwright
• Builds

Wenn ein Check fehlschlägt, bekommt der Agent neues Feedback. Er analysiert den Fehler, verändert den Code und probiert es erneut. Das klingt banal — ist aber ziemlich zentral. Ein Sprachmodell kann sehr überzeugend erklären, warum sein Code funktionieren sollte. Der Compiler ist weniger leicht zu beeindrucken.

Der beste Agent ist nur so gut wie seine Umgebung

Dadurch haben unsere Experimente noch etwas anderes sichtbar gemacht: Das verwendete Modell ist wichtig. Aber mindestens genauso wichtig ist die Umgebung, in der der Agent arbeitet.

Ein gut strukturiertes Repository hilft. Tests helfen. Linting hilft. Klare Architektur-Patterns helfen. Gute Dokumentation hilft. Maschinenlesbare Fehlermeldungen helfen. Je besser ein Projekt dem Agent sagen kann, ob er richtigliegt, desto selbstständiger kann er darin arbeiten.

Umgekehrt gilt das ebenfalls. Wenn es keine Tests gibt, kann Muro keine Tests ausführen. Wenn ein fachlicher Fehler technisch einen völlig gültigen Build produziert, wird ein grüner Build ihn nicht retten. Und wenn die Aufgabe schwammig ist, kann ein Agent mit beeindruckender Geschwindigkeit ziemlich effizient in die falsche Richtung laufen. Agents machen gute Engineering-Praktiken deshalb nicht weniger wichtig. Eher das Gegenteil.

Wir versuchen gerade nicht, Entwickler*innen abzuschaffen

Die offensichtliche Frage lautet schnell: Wie viel Softwareentwicklung kann man damit automatisieren? Für uns ist momentan eine andere interessanter: Welche Arbeit sollten Menschen überhaupt noch selbst machen?

• Einen schwierigen Architekturentscheid diskutieren? Gerne.
• Mit einer Kundin herausfinden, welches Problem wir eigentlich lösen? Unbedingt.
• Eine komplexe Domain verstehen und daraus ein gutes System entwerfen? Sehr menschliche Arbeit.
• Zum siebzehnten Mal einen Renovate-Branch rebasen und danach pnpm test ausführen? Vielleicht nicht.

Aber wie funktioniert das eigentlich?

Bis hierhin haben wir bewusst eine Frage ausgelassen: Wie kommt ein Agent überhaupt von einer Slack-Nachricht zu einem veränderten Merge Request? Denn dafür braucht es einiges mehr als ein LLM und einen Slack-Bot.

Mehr dazu in Teil 2 . Dort schauen wir uns Muro unter der Haube an: vom Slack-Event über OpenCode und die isolierte Arbeitsumgebung bis zur Frage, welche unser Agent bekommt.