I’m back from LangDev 2026 where I presented mops. Other tools to make MPS accessible to agents generally take the form of MCP plugins and are designed for pair-programming with an agent. mops, on the other hand, makes it possible to give agents autonomous tasks and fire off several agents running on separate worktrees or separate repositories using various MPS versions. To make use of this new capability, I have long wanted to build some sort of automation to review pull requests on MPS-extensions. I am pleased to report that it is taking shape, though not exactly in the form that I envisioned.

I was originally thinking that I would build some kind of autonomous workflow using codex exec or claude -p – these ways of invoking Codex or Claude let you give the agent a single prompt, have it work on something, and exit once done. The obstacle to setting this up turned out to be technical as well as financial: the automation setups I looked at would have required API billing and looked too complicated.

Around the same time, I noticed that Matt Pocock had published a new skill, chief-of-staff, that also reminded me of the efforts I reported previously where I started using long-running agent sessions for managing long-term efforts. This is probably not as efficient as starting a new session for each new task (because coming back after a long break means the cache has expired and the LLM has to reprocess the complete input from the beginning) but so far my subscription limits were enough for this, and being able to come back and pick up where I left off without having to reexplain everything to the agent has been very valuable. Thus, I decided to take a similar approach and started a new session with the chief-of-staff skill:

/chief-of-staff In this long-running conversation I want to continuously monitor MPS-extensions for new pull requests and review them on this computer in a worktree, using mops. Exclude cascading merge PRs from reviews. At first, we should automate the initial repo/worktree and mops wrapper setup (including full build), these automations should not be part of MPS-extensions but a separate repo. Suggest improvements to mops and skills. Reviewers shouldn’t need to run tests because the CI already does it.

Do not comment on PRs, present review findings to me for approval first.

Flag any issues.

Make sure to use appropriate agent/effort levels so that we don’t burn our usage limits unnecessarily.

Restate what I want you to do in your own words before continuing.

This has worked out quite well: the agent starts reviews automatically, and presents me with the findings that I can look at and either approve for posting or ask the agent to dig deeper into something. You can see a few instances of “my lawyeragent talking to your lawyeragent” in PR #1910 where Sascha Lißon has been working on adding view models to MPS (a long-overdue piece of infrastructure that could become very useful potentially for showing data in the editor that does not exist directly in the model but has to be computed).

I am still not letting my agent do things completely unattended because I need to get some feeling for its strong and weak spots in order to trust it more. I find that I do need to steer it at times. Not as much because it produces bad code – Opus 5.5 has been very so far – but because it still can’t read my mind.

Another useful skill besides chief-of-staff has been Dex Horthy’s show-me which presents PRs visually. And simply asking Claude or Codex to produce an HTML page explaining a pull request or, say, some bugs it found in the MPS code, has also been useful. You can find an example of such a web page explaining some fixes in celllayout here (see PR #1919 for context).

The downside of this is that I feel that I am becoming more of a bottleneck as a reviewer. Agents generate so much action and momentum that I have no time to review it all. This is the next problem to solve. Several AI leaders suggest that the solution to this problem is to replace parts of human review with automated guardrails: tests, checks, linters, etc. E.g. the /correct skill of pstack by Lauren Tan (aka @poteto, a SpaceX AI engineer working on Grok Bot) lists four levels of guardrails:

  1. Eliminate it with architecture. Give each piece of state one owner and each task one supported way. Hide internals so the wrong import fails. Replace hand-synced lists with one source of truth. Delete old ways and dead code an agent would copy.
  2. Enforce it with types so the bad state can’t be written. If bad code still compiles, add a lint or CI check whose error names the file, type, or function to use instead. If the pattern is already common, fail only when a change adds more.
  3. Test the behavior. Fix or delete any test that still passes when the behavior it checks breaks, or that fails when only the internals change.
  4. Write docs or agent rules last, only for judgment calls. Nothing fails when an agent skips them.

And guardrails are what I want to explore next. Well, after I finish all those pending reviews, I guess.

P.S.: If you want to exchange experiences about using AI in MPS, I am organizing an informal “fireside chat” about MPS and AI. It will take place on Tuesday at 14:30 CEST in Google Meet. See you there!