There is a piece going around called “Chat is the wrong interface for AI.” The argument is not that the models are bad. It is that a genuinely good thinking partner got stuffed into a messenger, and the messenger eats everything. The thread gets long, the scrollbar gets small, and the best thing you said that day is buried somewhere in the middle of it.
The sharper version came up in the comments. These tools have persistent memory for the model and nothing for you. The system keeps what it inferred about you and throws away what you noticed, which was the only part that was actually yours.
I had run into that already without having words for it. What I had was a pile of half finished projects and the annoying sense that I kept re-explaining myself to something that was supposed to already know.
The Setup
Gitea had been running in my homelab for a while already. It lives on Eleven, the server that runs my core infrastructure: DNS for the whole property, the reverse proxy that fronts every internal service, remote access, automation. Gitea was on there holding a single repo of configs so I could stop losing track of what I changed on the GPU box at 11pm. Adding project repos to it cost nothing. The missing piece was the Gitea MCP server, which lets Claude Code read and write issues directly.
I build in VS Code with Claude Code. That is the whole stack. Nothing exotic, and you could run the same thing against GitHub or GitLab if you do not want to self-host.
How It Works
Every project gets a repo. Every piece of thinking gets an issue. When I sit down to work I do not describe the project, I point at issue #14.
Claude reads the issue, reads the comments, and starts from where the thinking actually is instead of where I can remember it being.
The rule that makes it work: the issue body is the current state of the decision, not a log. Comments are the working out. When something changes, I edit the body. Six weeks later I do not reconstruct a conclusion by reading forty comments in order. The conclusion is at the top and the reasoning is underneath it if I want it.
Ceres, a multi-agent garden assistant, went through eight versions of its spec that way before I wrote a line of code. Cruxwire, my self-hosted RSS reader that scores and dedupes articles with a local model, had its whole scoring approach argued out in issues. It changed twice, and both sets of reasons are still sitting there. Good luck finding that in a chat history.
Why It Fixes the Reading Problem
The complaint that stuck with me was about reading. Reading is divergent. Three thoughts spawn while you read a response, chat is linear, so exactly one of them gets typed. The other two go on a post-it or evaporate.
That stops being a problem when the surface is not linear. Three thoughts spawn, one becomes a comment on the issue I am in, one becomes a new issue, one becomes a checklist item for next month. Nothing has to win.
Here is what that looks like in practice. I was in the middle of something else on Cruxwire when I started wondering whether it could work as a filtering proxy for people who already have an RSS reader they like. Curate the feeds in Cruxwire, read them in NetNewsWire. I was not ready to build any of that, so I said exactly that: write an issue about this, I am not ready to do it yet. Claude checked the repo’s issue template and labels, wrote up the design including the parts that were still undecided, and filed it. The thought left my head and landed somewhere it will still be in six months, and I went back to what I was doing.
That one is a GitHub repo rather than Gitea, which is the point. The method does not care where the issues live.
A few weeks in, a second effect showed up: the model got better. An issue that has been edited four times as I learned things is stronger context than anything I would type fresh into a prompt. A prompt is a lossy summary of what I know at the moment I type it. The issue is the actual state of what I know.
So the record of what I think is the durable thing and the model is the disposable part. Swap models, swap tools, the repo does not care. That is backwards from how chat is designed, where the product persists and you are the thing that gets summarized.
What It Costs
There is real overhead up front. Writing the issue before you start working feels slower than just typing into a box, because it is. It pays back on the second session on the same problem, and then again on the tenth, but the first one is a tax. If you try this and quit after a day, that is why.
It is also wrong for the fuzzy front end. When I do not know what I am looking for yet, I still just talk to a chat window, and that is fine. Chat is a good scratchpad. It is a terrible filing cabinet, and the mistake was asking it to be both. And none of this is a product. It is a discipline held together by an MCP server and my willingness to keep writing things down.
It works, though. That pile of half finished projects from the top of this post is mostly gone, some shipped and some closed on purpose, with the issue saying why, which turns out to matter almost as much. The pattern does not care that the repo happens to contain code. It cares that there is a durable place where my thinking lives, and that the model has to come to it instead of the other way around.
