Tools and Momentum

I’ve been using AI-assisted development for a year. I use it to maintain this site. That’s not the revelation.

The revelation this month was finally going all-in on MCPs — not experimenting with them, not reading about what they could do, but actually integrating them into a workflow and using them consistently. And discovering that the gap between “dabbling” and “using them properly” is much larger than I expected.

The difference between knowing and using

I’ve known about MCPs for a while. Model Context Protocol: a standardised way for AI agents to connect to external tools and services. I’d set them up, played with them, moved on. They seemed fine. Neat, even.

What I hadn’t done was restructure how I work around them. I was still thinking of AI assistance as a “when I get stuck, ask for help” pattern. MCPs aren’t that. They’re infrastructure. They change what you’re capable of doing, not just how fast you can do it.

The MCP moment

For Unity development on insert-name-here, I’ve been using MCP servers to automate asset and workflow tasks. Not code generation — that’s not where the value is for a project like this. Asset pipelines, build automation, the tedious glue that surrounds the actual interesting work. Tasks that are well-defined enough to automate but tedious enough that they quietly consume more time than you’d ever admit to.

The difference is: before, I’d work around the tedious parts. Write a script, forget about it, move on. Now the tedious parts get handled consistently, and I don’t have to context-switch back into “I’m doing a one-off build task” mode. The mental overhead of remembering where you left off, what the script did, why it didn’t quite work last time — that’s gone.

This sounds like a productivity win. It is. But the bigger thing is that it changed what “working on the project” feels like. The boring parts are automated. The interesting parts are more interesting because you’re not coming in cold every time.

The kanban experiment

Gamemaster has largely been built using Cline’s kanban board to handle individual tasks. This sounds minor. It isn’t.

The thing about kanban is that it’s honest about your rate of progress. When tasks are small and discrete, and you can see them move from left to right, you get a feel for throughput that you don’t get from “I’m working on the thing.” The gamemaster architecture — Discord bot, RAG pipeline, SurrealDB campaign state, React frontend — all of it was specced and built in a few weeks. I don’t think that pace was possible before without a full-time team.

It also surfaces dead ends fast. A task that sits in “in progress” for too long is a signal that something’s wrong with how I’ve framed it. Sometimes it’s the framing. Sometimes it’s that I’m dreading it and need to break it down further. Either way: information.

insert-name-here: the grind before breakthrough

The milestone pace on insert-name-here has been substantial. Simulation tiers and time-passed mechanics, astrogeology, settlements and interior play, fleet and faction interaction, combat, crew depth, economy and industry — all of it generating and interacting together. A full consistency and integration audit passed over the codebase. The major systems work.

What remains is M8 (Release Candidate) and M25 (Audio & Polish). These are the 10% that takes 90% of the time. Bug fixes and stability work, audio integration, the things you do once before you let other people touch the thing. It’s not glamorous. But it’s the stretch between “works for me” and “release.”

The reason I’m not frustrated by this is that I can see the shape of it now. The major uncertainties are resolved. What’s left is defined, bounded, and finite. That’s a better position than I’ve been in with any previous project at this stage.

What the workflow taught me

Working this way has clarified something I’d half-understood before: the bottleneck was never intelligence. It was friction. The time cost of context-switching, of maintaining state across interruptions, of doing tedious work in a way that was “good enough to not have to think about again.” MCPs, when they’re well-integrated into a workflow, reduce that friction substantially. Not by being intelligent — by being automated.

The other thing: shipping small things fast trains your intuition differently than shipping big things slowly. When tasks move through the kanban in hours or days instead of weeks, you get faster feedback on whether your framing was right. That feedback loop compounds.

What’s next

insert-name-here: finish the RC work, get audio in, ship a release candidate. Gamemaster: work through the remaining P0/P1 issues — Discord channel creation, guild config persistence, completing the training hub UI. Both are in the “boring before breakthrough” phase, which is where you want to be.

The breakthrough isn’t a single moment. It’s the moment you stop being surprised that the pace is sustainable.