I recently wrote about giving Claude Code persistent memory using the MCP Memory Service. Go read that if you want the why. This post is about something else entirely.
This post is about speed.
I needed a feature in an open source project. I used an agent to write the code. A different agent reviewed it. A maintainer in Switzerland merged it three hours later. The whole thing, from “I need this” to “it’s in upstream main,” happened in a single afternoon. That’s the world we’re in now, and I don’t think most people have internalized what that means.
Writing the PR
The MCP Memory Service needed SSE (Server-Sent Events) transport. SSE is a W3C standard from 2012 that lets a server push updates to clients over a persistent HTTP connection. The default stdio transport spawns a new server process per session, which means slow, cold starts of Claude Code and redundant RAM usage for each new Claude Code terminal. SSE lets you run the server once as a systemd service and connect over HTTP. No cold starts, no redundant processes. No waiting for Claude’s MCP servers to slowly connect.
I didn’t write the fix by hand. I described what I needed to Claude Code, and it wrote PR #506: 88 lines added, 4 deleted, across 4 files. New CLI flags, configuration constants, and an ASGI app wired into the existing server architecture. It reused dependencies already in the project. No new packages, no bloat. It even chose a raw ASGI app over Starlette’s routing wrappers because those wrappers break SSE streaming. That’s a judgment call, not just code generation.
I reviewed the code myself, tested it, and opened the PR. But then something happened that I didn’t expect.
Gemini Showed Up
The mcp-memory-service repo has Gemini Code Assist configured as an automated PR reviewer. Eighteen seconds after I opened the PR, Gemini posted a summary. Five minutes later, it delivered a full code review.
Let that sink in. Code written by Anthropic’s Claude was reviewed by Google’s Gemini. Two competing agents, working in sequence on the same code, on a random Monday afternoon.
Gemini’s review was positive overall: “excellent addition,” “well-executed,” “code is clean.” But it also flagged two medium-priority issues.
First, it caught a log statement in config.py that fired at module import time. Every server startup would print SSE configuration details, even when running in stdio mode. Confusing for users, and redundant since there was already a log statement inside the actual run_sse() function. Legit.
Second, it found an unreachable return statement after a while True loop. Dead code. The loop only exits via an internal return on shutdown, so the trailing return never runs. Also legit.
Neither was a showstopper, but they’re the kind of thing you miss when you’ve been staring at your own code. The review wasn’t a gimmick. It found real things. Agent-generated code still needs review, and it turns out agent reviewers can do useful work.
Three Hours
Henry, the creator and maintainer of mcp-memory-service, merged the PR three hours and one minute after I opened it. I submitted the PR at 10:20 AM EST on February 24th. He merged it at 1:22 PM EST the same day. He works in enterprise data migration consulting out of Switzerland and maintains this project alongside his day job.
I had already drafted a blog post telling people to use my fork, figuring the PR would take weeks or months to get merged. I figured I could have Claude Code clean it all up if and when it landed. I also wasn’t sure how friendly he might be to PRs developed with Claude. None of that mattered. Three hours.
Much of the open source community still needs to leverage automated code reviews. It’s the only way they’re going to survive. As I commented recently, maintainer burnout is real. People show up with AI-generated PRs, maintainers invest time reviewing and coaching, and then the contributors ghost. Half-solved PRs get closed. Tickets go back to “good first issue.” It’s mentally draining. Automated reviews like Gemini Code Assist don’t fix that problem entirely, but they take a real chunk of the review burden off maintainers’ plates. Henry still made the judgment call to merge, but he didn’t have to do the line-by-line grunt work alone. Thank you, Henry.
The Speed of Everything
Step back and look at the timeline:
- Morning: I have a problem with stdio transport.
- Afternoon: I describe the fix to an agent. It writes the code. I test it. I open a PR.
- 18 seconds later: A different agent summarizes the change.
- 5 minutes later: That agent delivers a full code review with two valid findings.
- While waiting: I have the same agent draft the previous blog post.
- 3 hours later: A human in Switzerland merges it into the upstream project.
- Minutes later: I update the draft and publish it.
A year ago, I’d have gotten stymied and probably never finished the code. If I did, it might have taken weeks, another week to get the code reviewed, and maybe another month to get it merged. Now the bottleneck is my typing speed.
This is the part that’s hard to explain to people who aren’t living in it. The cycle time on everything is collapsing. Writing code, reviewing code, getting code into production. The humans are still in the loop, still making the important decisions. Henry made a judgment call to merge. I made a judgment call to trust the agent’s output after testing it. But the mechanical work, the grunt work, the waiting: that’s evaporating.
I don’t know exactly where this goes. But I know that the distance between “I have an idea” and “it’s shipped” has never been shorter, and it’s still shrinking.
If you want to set up the memory server yourself, start with the previous post. SSE transport is now a first-class feature upstream. Pull the latest code, run memory server --sse, and you’re done.