Autocomplete doesn't fix bugs

It's 9:14 on a Tuesday. Sentry fires an alert: TypeError: Cannot read property 'url' of undefined. 340 users affected. The error is in the profile view.

What happens next?

Someone sees the notification in Slack. Someone opens Sentry and reads the stack trace. Someone goes to GitHub to find which commits last touched that file. Someone opens the repo locally, switches branch, spins up the environment. Someone writes three lines of code. Someone opens a PR. Someone files a ticket in ClickUp so it can be followed up.

Usually it's the same person. And of the four hours the average bug takes to resolve, maybe five minutes went into actually writing the fix.

The rest was transport.

Writing the code isn't the problem

AI tools have become extremely good at one thing in recent years: suggesting code when you're already in the editor, already have the right file open, already know what's wrong.

That's real value. But notice how many "alreadys" it takes before it's useful.

Code suggestions help with the last step. They don't help you debug, find the right file, work out which commit introduced the regression, run the test suite, or package the result so a colleague can review it.

In other words: they help with the five minutes. Not the four hours.

That's why developers still spend roughly 30 percent of their week on bug reports, even though every editor now ships with an AI assistant. The bottleneck never moved. It was never at the keyboard.

The bottleneck is context switching

Every step in the chain above is a tool switch. Sentry, GitHub, the terminal, ClickUp, back to Sentry to verify. Every switch costs focus, and focus is the most expensive thing an engineering team has.

The worst part isn't the time itself. It's that the interruption is unplanned. A bug lands in the middle of a deep work session, and whoever picks it up loses half a day that was meant for something else.

You can't schedule it away. You can only move the work somewhere else.

What happens when an agent owns the whole chain

Metis doesn't start in the editor. It starts at the trigger.

An error shows up in Sentry. A task gets tagged in ClickUp. A cron schedule fires. Another agent hands off. Whichever it is, the same chain kicks off:

It reads the error. Stack trace, affected users, which environment, how often it happens.

It reads your code. Not a generic idea of what React usually looks like — your repo, your files, your recent commits. It compares when the error started with what actually changed, and lands on a root cause rather than a guess.

It writes the fix. In an isolated environment, and then it runs your real tests. Not to certify that the code is pretty, but to show that nothing else broke.

It opens a PR. With the change, an explanation of what was wrong and why, and the test results.

From alert to open pull request: 45 seconds.

But the number isn't the point. The point is that nobody on the team had to switch context to get there.

The pull request is the boundary — on purpose

It would have been technically simpler to let the agent merge on its own. We chose not to, and that's a deliberate design decision, not a limitation we haven't got around yet.

A pull request is where machine work becomes a human decision. It can be reviewed, commented on and closed. It leaves a trail. It requires a yes from someone who owns the outcome.

Think of Metis as your most capable junior developer: fast, tireless, reads the codebase more carefully than most — and always hands its work over for review before it goes any further.

That's also why the agent puts effort into explaining itself. A PR that only contains a diff just moves the problem: now someone else has to figure out what happened. A PR that explains the root cause makes the team a little better at the codebase every time.

It's also why agent permissions are intentionally narrow. They read code and open pull requests. They can't access secrets, they don't deploy anything and they never touch production. Autonomy without reach is a far safer thing to have in your stack.

Bugs are just the first workflow

Bug fixing is a good starting point because the problem is clearly bounded: there's a trigger, a measurable outcome and a natural handoff moment.

But the pattern is general. Something happens → an agent reads the context → the agent does the work → a human approves.

That pattern fits far more than bugs. Dependency updates. Routine refactors. Triage of incoming tickets. QA runs before a release. Anything repetitive, context-dependent and tedious enough to get pushed to Friday.

That's why Metis is built as an agent platform, not a bug-fixing tool. You connect agents to your repos, hook up your tools, decide what triggers them and let them work. All from the admin panel, no code required.

Integrations work the same way. Sentry, GitHub and ClickUp are built in, Linear and Jira are on the way — and any other tool can be connected via MCP and picked up by the agent straight away. No custom glue code, no waiting for us to build your particular integration.

And the agents don't forget. Give feedback once on naming conventions, coding standards or how you want a PR to look, and it sticks for next time.

What we're really building

Much of the conversation about AI and code is about whether models can write good code. At this point, that's the wrong question. They can.

The interesting question is who carries the work between problem and solution — all that transport between tools, tabs and contexts that nobody ever put in a sprint plan but that still eats a third of the week.

We think that part should be automated, and that humans should stay where judgement matters: in review, in architecture, in deciding what to build next.

Next time Sentry fires at 9:14, nobody has to switch context. The pull request is already waiting when you open your laptop.

Metis is in early access. Get early access and let us take the next bug.