AI Agents in Software Development: How Muro Takes Work Off Our Hands in Slack

At smartive, autonomous AI agents are now actively working right inside Slack. They don't just answer questions—they get things done.

One of them is named Muro.

Muro can independently open repositories, modify code, run tests, update merge requests, and resolve issues in CI/CD pipelines. We assign it a task on Slack—and, ideally, get the result back a few minutes later.

For example: @muro, can you fix all the pending Playwright updates on our corporate websites?

Muro then searches for the relevant merge requests, checks out the repositories, makes the necessary changes, runs the existing checks, and pushes the fixes.

That's where AI is becoming particularly exciting for us right now. Not because an LLM generates even better code, but because we can assign entire tasks to it. And by now, we've figured out pretty well which ones work.

What Muro Actually Does Here

At first, it was just a few small experiments. Now there are several categories of work that we regularly assign to Muro.

He keeps our dependencies alive

Renovate and Dependabot reliably generate updates—and just as reliably, there will eventually be merge requests that no longer go through automatically. Lockfile conflict. Breaking change. TypeScript error. Customized CI configuration.

Muro rebasizes such branches, analyzes the errors, modifies the code, and then runs the existing checks. This is especially useful when making changes across multiple repositories. Does a Playwright update affect ten websites? Then no one has to do practically the same work ten times. Muro can find the affected merge requests, apply the change to all of them, and update each branch individually. Copy-paste without copy-pasting.

He cleans up after broken pipelines

A test suite is failing. A Vercel build is failing. An E2E test no longer works after an update. Often, these aren't incredibly complicated problems—but someone has to take care of them.

Muro can read logs, locate the relevant section in the codebase, try out a fix, and then run the tests again. It doesn't take difficult architectural decisions off our hands—but it does remove a surprising number of minor roadblocks.

It resolves security findings

Security tools are also excellent at generating work. For example, a scanner like Aikido reports a problem. This might result in a change to the Dockerfile, an additional role check, or an adjustment to a server action. Such clearly defined findings make for pretty good agent tasks: problem known, goal known, code in place, checks in place. Zagg.

He's taking on minor features and fixes

Update a Content Security Policy. Customize an SSO integration. Build a small UI extension. Fix a configuration. These are tasks that might take a person 30 minutes—but they rarely actually take just 30 minutes. First, you have to find the repository, get back into the context, locate the relevant section, and figure out how the project works. The actual coding is sometimes the smallest part of the work. Muro pays a much lower price for this context switch than we do.

He reads merge requests before we do

Muro doesn't just write code—he can also analyze existing changes. For example, when there are major dependency updates, we have him figure out:

• What has changed?
• Which breaking changes are relevant?
• Which parts of our code might be affected?
• How high is the risk?
• What should we pay special attention to during the review?

This isn't a substitute for a review. But it shortens the path from "What's actually going on here?" to "Okay, I need to look at these three things."

It serves as a search engine for our own codebases

“Where do we actually configure that?” “Why is this project doing things differently from the others?” “How does the authentication flow work here?” An agent can answer questions like these differently than a standard LLM. It doesn’t make guesses based on its training data about what our code might look like. It actually checks. This is surprisingly useful, especially during onboarding or in projects where someone hasn’t worked on them for a while.

And sometimes he works without anyone asking him to

Some tasks can be automated even further. Muro can periodically check for open pull requests, builds, or other technical statuses and respond to problems. This shifts the pattern from “Human detects problem → Human assigns task to agent” to “Agent detects problem → Agent resolves problem → Human receives result.” That’s when “autonomous” actually starts to become the right term.

Why These Tasks in Particular Work Well

The longer we use Muro, the clearer a pattern becomes. Agents are currently particularly strong when four factors come together:

• The problem is clearly defined.
• The agent has access to the necessary context and the right tools.
• The desired result can be verified technically.
• A mistake can be corrected without having to completely reinvent half the architecture.

A broken dependency merge request is almost ideal for this. There's an existing branch. There's a specific error message. There's code. There are tests. And there's a pretty clear state called "green."

When it comes to questions like “How should we structure this product architecturally over the next three years?”, things get more difficult. There’s rarely a test that can tell you after five minutes: “Architectural decision successful. 17 tests passed.” Unfortunately. I might try to write something about our Software Factory approach in Part 3 or 4 of this series.

Hoping is not a testing strategy

For us, that’s currently one of the most important differences between “AI writes code” and “AI completes a development task.” Muro doesn’t just modify files and then claim to be done. It can review its own work. Depending on the project, for example, using:

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

If a check fails, the agent receives new feedback. It analyzes the error, modifies the code, and tries again. That sounds trivial—but it’s actually quite crucial. A language model can explain very convincingly why its code should work. The compiler is less easily impressed.

The best agent is only as good as the environment he works in

As a result, our experiments have revealed something else: The model used is important. But the environment in which the agent operates is at least as important.

A well-structured repository helps. Tests help. Linting helps. Clear architectural patterns help. Good documentation helps. Machine-readable error messages help. The better a project can tell the agent whether it’s correct, the more independently the agent can work on it.

The reverse is also true. If there are no tests, Muro can’t run any tests. If a business logic error technically produces a completely valid build, a green build won’t save it. And if the task is vague, an agent can run in the wrong direction quite efficiently at an impressive speed. Agents therefore do not make good engineering practices any less important. Quite the opposite, in fact.

We're not trying to do away with developers right now

The obvious question that quickly comes to mind is: How much software development can be automated this way? For us, another question is more interesting right now: What work should people still be doing themselves?

• Want to discuss a difficult architectural decision? I'd be happy to.
• Work with a customer to figure out what problem we're actually solving? Absolutely.
• Understanding a complex field and designing a good system based on it? That’s very human work.
• Rebase a Renovate branch for the seventeenth time, and then pnpm test Execute it? Maybe not.

But how does that actually work?

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.