For the last month, I have been using Codex to clear a backlog on my language project, Bosatsu. The interesting parts (type inference, optimization, compiler design) always pulled me in. The essential but repetitive parts sat for years.

A friend finally got me to try codex about a month ago. I started slow, but now I agree with most that these tools are in fact a big deal. They are great at turning "I know what should happen" into a first draft quickly.

The old model still wins where it matters

Codex is great at turn the crank type coding, but I've found I really need to look over its shoulder, especially in compiler-heavy code. The practices that worked before still work now:

1. strong static checks (Scala 3, in my case)
2. property-based tests to catch edge cases
3. design docs for bigger changes
4. code review to keep quality and test coverage honest

The workflows that worked well for me in industry and open-source are still good practices. I don't want to vibe-code and build castles of sand. I want to integrate agentic coding with a proven workflow.

Using AI as an open-source teammate

That is the point of MergeXO: use GitHub issues and PRs as the control plane, and route work to an agent by label.

It runs on a machine you control, authenticated to both GitHub and your agent, and left running as a service. Agents are still sandboxed: they focus on file edits and structured outputs, while MergeXO owns branch creation, commits, pushes, and PR creation. In feedback turns, git actions are allowlisted and explicitly requested through the orchestrator.

Default labels map to three intake flows:

1. agent:design
2. agent:bugfix
3. agent:small-job

Design flow

agent:design opens a PR that adds a markdown design doc (with summary and expected touch_paths). I review it like any other PR. After the design PR is merged, MergeXO can start an implementation PR from that merged doc, then we iterate to merge.

In my setup, MergeXO resumes the same agent session on PR comments/reviews, so doc and code revisions stay in the normal review loop.

Bugfix and small-job flows

For obvious work, I skip the design phase:

1. agent:bugfix opens a direct fix PR
2. agent:small-job opens a direct scoped-change PR

Both rely on issue context plus repo coding guidelines. Bugfix flow also enforces that at least one staged file under tests/ exists before opening the PR.

Why I keep this workflow

It is not some breakthrough idea: just the opposite, it's leveraging the success of a methodology I've found productive for years. I can manage work across repos with tools I already trust: issues, PRs, and review comments, from any browser or phone.

MergeXO lets me put the focus back on the code and the process, and almost forget that the coder on the other end of the issue or the PR is actually a bunch of matrices in a trenchcoat.