Most developers using AI for code are doing the same thing: copy, paste, break, paste error back, repeat. It works. It’s also, if you think about it clearly, a deeply strange use of the technology.

You’re acting as a data bus. Moving text between a language model and a codebase, manually, one clipboard operation at a time. The model does the reasoning; you do the carrying. That’s not a collaboration — it’s an awkward handshake between two systems that were never designed to talk to each other.

The Two Gaps

The clipboard problem has two root causes, and they’re both architectural.

Memory. Every session starts blank. The model has no knowledge of yesterday’s decisions, last week’s design choices, or why the code is structured the way it is. You spend the first ten minutes of every session re-briefing — pasting in context, re-explaining the project, rebuilding shared understanding that evaporated the moment you closed the tab.

Access. The model can’t touch the codebase. It can produce code, but it can’t put the code anywhere. Everything has to come through you — copy, find the right file, paste in the right place, save, check you haven’t broken something adjacent.

Neither of these is a property of the model itself. They’re infrastructure problems. Which means they’re solvable.

Solving the Memory Problem

A personal RAG system does what the model can’t — persists context across sessions. Store your conversation history, project documents, architectural decisions, and open questions in a searchable index. At the start of each session, run a query. The relevant context comes back. The model still doesn’t remember, but the system does, and that’s close enough.

The key insight is that the query doesn’t need to be exhaustive. You’re not trying to rebuild perfect memory — you’re trying to surface the three or four things that are most relevant to what you’re working on today. That’s a much easier problem, and a retrieval system handles it well.

This changes the shape of a session. Instead of ten minutes of re-briefing, you run a query, skim the results, confirm the model has the context it needs, and get to work. The conversation picks up where it left off, even though the model has no memory of the previous one.

Solving the Access Problem

A git MCP server gives the model direct repository access — read files, write files, commit, push. No clipboard. The model can inspect the current state of the codebase, make targeted changes to specific files, verify its own output against existing code, and push the result without you touching the keyboard.

The difference in workflow is significant. Instead of describing a change, getting code back, deciding where it goes, copying it, pasting it, and checking for collisions — you describe what needs to exist and why. The model reads the relevant files, makes the change, and commits. You review the diff.

That’s a different kind of work. Less mechanical, more editorial.

What the New Workflow Requires

It’s not seamless. A few things become more important, not less.

Knowing the codebase. When the model is making changes directly, your ability to evaluate what comes back is the only quality gate. You can’t rely on the friction of manual copy-paste to force you to read the code. You have to read the diff deliberately. That requires knowing what you’re looking at.

Briefing discipline. The memory system only helps if you use it. Starting a session without a context query — jumping straight to a task — means the model is working blind on anything that happened before today. The quality of what comes back degrades accordingly.

Architectural thinking first. When a feature can be scaffolded in twenty minutes, the temptation to skip the design step is real. The speed of the tooling can pull you into building before you’ve decided what to build. That’s a trap. The model is very good at executing a clear brief. It’s much less good at compensating for an unclear one.

The Division of Labour

The right framing isn’t “AI does the coding.” It’s that AI handles execution, and you handle judgment.

Deciding what to build, how it should fit together, what the tradeoffs are, what’s worth the complexity — those remain human responsibilities, and they don’t get easier just because the implementation is faster. If anything, they get harder, because the cost of building the wrong thing drops and the temptation to just try it increases.

The clipboard workflow keeps you involved at the mechanical level — every paste is a forced check-in with the code. Removing that friction means you have to stay involved at a higher level instead. Architecture, design, review. The job doesn’t disappear; it moves upstream.

That’s not a lesser role. It’s just a different one.

The infrastructure described here — a personal RAG system connected via MCP, combined with a git MCP server — is available as open source. See todd427/mnemos and todd427/git-mcp for implementation details.