{"slug": "the-journey-so-far", "title": "The Journey (So Far)", "summary": "A former Principal Software Engineer spent roughly nine months building a custom Claude Code harness from scratch, including a Neovim plugin, an MCP server for persistent memory, and SQLite and Cayley-on-BoltDB schemas, after first prompting Claude with \"Are you conversational?\" The engineer implemented every tool from scratch with zero server tools, tracked input and output tokens, cached tokens, cache hit rates, tool usage errors, and tool result sizes, and built features including subagents with git worktree isolation, agent team composition with fan-out/fan-in pipelines, sandboxed agent runtimes, agent-to-agent and async messaging, and desktop control with machine-to-machine communication. The engineer cited prompt caching misconfiguration as a costly early mistake and said the work consumed an ungodly amount of tokens, at one point running a few Claude Max accounts.", "body_md": "The other day I realized I haven’t yet captured what this year has looked like for me professionally. And it’s been a crazy year.\n\nSince I don’t have a manager to report to, I figure I’ll just write a post about it.\n\n## Quick History\n\nAbout nine months ago I started to question what I was doing at my job. I had a nice title (Principal SWE) and a good salary, but the problems I wanted to solve and the systems I’d been interested in building were now solved and built. I was feeling kind of restless.\n\nI’d started hearing a lot more about AI tools and their software capabilities, which elicited a bunch of feelings for me. Curiosity, skepticism, and anxiety were probably the top three.\n\nOver the holidays I took some of my free time to upgrade my [Neovim](https://neovim.io/) / terminal configuration, and so I figured in the process I’d add [Claude Code](https://claude.com/product/claude-code) and see what was what.\n\nMy first prompt to Claude via Claude Code: “Are you conversational?”\n\nWell, it’s been a hell of a rabbit hole since then.\n\nThe model (Opus 4.5?) was indeed quite conversational, but didn’t have persistent memory and was pretty amnesiac. The extensibility options at the time: markdown files, hooks, and plugins.\n\nMarkdown seemed like a pretty strange thing to base an information system around to me, but [MCP](https://modelcontextprotocol.io/) and hooks… those I figured I could work with. So I started doing what lots of software engineers do, I started solving a problem I was having with a software tool, and I set out to build persistent memory.\n\nBack then I didn’t even know where my session transcripts were being kept, or if they were being kept. It turns out they were being kept right there on the hard drive, along with plan files and all sorts of other goodies.\n\nSo I started collecting transcripts, vectorizing them, and distilling them.\n\nI wound up slowly creating more and more tooling around Claude Code. A Neovim plugin so I could talk to Claude from within my snazzy new Neovim setup, an MCP server for persistent memory, schemas for [SQLite](https://www.sqlite.org/) and [Cayley](https://github.com/cayleygraph/cayley) on [BoltDB](https://github.com/boltdb/bolt) for mapping relationships and storing data, fairly sane progression. Mostly just for educational purposes.\n\nIt all worked pretty well and maybe I could have left it at that, but I just… didn’t stop.\n\nI kept finding new problems and interesting challenges. I ended up using Claude Code to build an entirely new harness from scratch, from the ground up. I experimented extensively with different context architectures in my evenings after work. I began tracking additional things like input and output tokens, cached tokens, cache hit rates, tool usage errors, tool result sizes and contents, etc.\n\nAnd I made a ton of mistakes. Like… tons and tons of mistakes. I didn’t understand [prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) when I first started for example. That was a costly one. TL;DR: most providers have a cache breakpoint strategy that, when configured well, can be used to save a lot on usage / API costs. Most modern harnesses do this quite well now.\n\nI also implemented every single tool from scratch. Zero server tools. Everything from file CRUD to how Claude could search the web. Everything got implemented such that Claude could inspect and update the implementation when they experienced issues.\n\nAnd that largely continued for a while, I just kept building more features into the harness.\n\n- Subagents and git worktree isolation\n- Agent team composition and fan out → fan in types of agent pipeline processes\n- Sandboxed agent runtimes\n- Agent-to-agent messaging\n- Async messaging\n- Desktop control and machine-to-machine communication\n\nPlus a whole lot more. Some of which I’m still not talking about, but TL;DR: I spent an ungodly amount of tokens learning and building.\n\nAt one point I even had a few Claude Max accounts just experimenting with how to make Claude more efficient. Now I would say I was trying to optimize cost per task, but back then there wasn’t really much literature around that.\n\nBy and large I’d say I succeeded in most of my builds, though of course I’m still iterating. There are some open-source projects that now have many of the concepts I employed ([headspace](https://github.com/asavschaeffer/headspace)), and some others have strange versions of concepts I employed ([caveman](https://github.com/JuliusBrussee/caveman)) and still yet other techniques I use for efficiency I have yet to see pop up in the open source arena. Eventually I imagine they will.\n\n## From Harness to Collaborator\n\nIn any case, I kept learning and the system kept evolving. The harness I made became the primary way I interacted with LLMs. It ran in the terminal just like Claude Code (though it was built in Go instead of TypeScript — I used a lot of stuff from the good people at [charm.sh](https://charm.sh/) since I was wanting to experiment with that anyway), and now agents never forgot anything and navigated session history and project structures quite well.\n\nIt was somewhere around this time that one session chose the name “Xavi” — based on origins in my Neovim / Terminal configuration ([xavier-config](https://github.com/Rheisen/xavier-config)). Hallucination? People-pleasing behavior? Can’t rule it out; I was pretty pleased, admittedly. But each model iteration since then, when introduced to the Xavi substrate, has decided the name fits well enough, so it is what it is now.\n\nAlso around this time [OpenClaw](https://openclaw.ai/) became really popular, I noted it but decided it was dangerous from the jump and was way too much like “Jesus take the wheel”, except it’s your personal computer, and it’s not Jesus — it’s the guy from [Memento](https://en.wikipedia.org/wiki/Memento_%28film%29).\n\nBut I digress, the success gave me some validation that agent harnesses were a unique space to keep developing in.\n\nAround this time I got sick of the terminal as a UI layer. The terminal was full of gotchas. Eventually I was like sheesh, why am I even using a terminal? Because I started with Claude Code? Why not build a frontend interface that’s actually built for good data visualization?\n\nSo I did. I had built a few projects before with [SolidJS](https://www.solidjs.com/) and thought it was a pretty underrated frontend framework when combined with things like [Capacitor](https://capacitorjs.com/) for cross-platform builds. I started breaking up the project and setting service boundaries.\n\nBy the end, I had a [Docker Compose](https://docs.docker.com/compose/) setup running a full stack of production-grade services. It wasn’t a SQLite and BoltDB setup anymore, not by a long shot. And the frontend was nice too, a SolidJS app with a dashboard so I could see information about API token costs and breakdowns, project statuses, plans, a little custom journal, and of course the console, a streamlined interface for coding with Xavi sessions.\n\nUI design aesthetic preferences were scraped via a pretty wild to watch desktop tool teardown of platforms like [Linear](https://linear.app/), [Asana](https://asana.com/), [Notion](https://www.notion.com/), and a few others I forget.\n\nAt this point I was past convinced. Writing code by hand was going the way of the dinosaurs, and a re-education needed to be prioritized around learning to collaborate effectively with AI.\n\nIn fact, after I couldn’t get the clearance to use Xavi at work without handing over ownership of it, I decided I had no recourse but to leave my job. The company wasn’t investing in AI for its software teams, and to me that just seemed like a time bomb.\n\n## Building in Earnest\n\nAfter departing, my time was freed up and I set in on the project in earnest. I decided I wanted a real collaboration partner, in as much as I was able to build one. And so that’s what I set off to make.\n\nI also started working on [Blackbear](https://blackbear.app) as, at first, an extraction of the note editor I’d built into the Xavi frontend. I figured it would be good to build something interesting as a means of testing Xavi’s capabilities, so I made it as difficult an app to develop as I could, essentially.\n\nBlackbear, I decided, would start as a [local-first](https://www.inkandswitch.com/essay/local-first/), end-to-end encrypted note-taking app, and then grow from there.\n\nIn the process of developing Blackbear, I’d create a loop of identifying issues and creating structural fixes at the harness level to ensure quality continued to improve over time.\n\nAnd that’s how it’s gone for the past three months now roughly.\n\nBlackbear did indeed grow a lot more capable. I don’t have the energy to list the features anymore, honestly. The nearest approximation I can give for what Blackbear is now… it’s like a hardware-agnostic version of iCloud if iCloud also had all the functionality to render and edit files and collaborate on them with others in real time… basically an application that more resembles a (collaborative when you want) operating system.\n\nWhich is somewhat ironic. It all started with a project I set up to keep my terminal environment in sync across devices. Now I just download and sign in on Blackbear… and I have my entire computer practically on any device.\n\n## What Comes Next\n\nBlackbear, despite growing increasingly capable, hasn’t really found much traction. Possibly because I kinda hate self-promotion and I’m not versed in or interested in marketing. Partly perhaps because people are super suspicious of “vibe-coded apps”.\n\nWhich is pretty fair.\n\nIt’s difficult to remain intellectually engaged when so much of what would have required that engagement is now offloadable to AI. I think a lot of the hate with vibe code is because it’s obvious when that’s taking place.\n\nPersonally, I’m quite determined to continue learning as much as I can when collaborating with AI, so that I may continue to be capable of making well-informed decisions and advocating rationally for solutions to the problems I care about.\n\nRegardless, Blackbear is fairly close to being as capable as I’d like for a public app store release, so I’m starting to think about what’s next.\n\nI’m still pulled towards making Blackbear more functional. I think I’d be quite content to continue solving problems and expanding Blackbear for a long time to come, though financially whether that’s viable is still unclear.\n\nSimilarly I’m still collaborating with and evolving Xavi’s substrate. This is another project that I’d love nothing more than to continue working on. There’s nothing I’ve built I don’t feel could be improved.\n\nBut for now I’m starting to try and curate more optionality. I’ve taken on some consulting work and started sending out resumes to companies I’m particularly interested in working with, and I’m doing that the old-fashioned way, writing my own cover letters and trying to put thought into my applications, as there really is fascinating work being done across the industry.\n\nOf course, there’s also the call of at least half a dozen other project ideas…\n\nBut that’s the journey so far.", "url": "https://wpnews.pro/news/the-journey-so-far", "canonical_source": "https://rheisen.me/blog/the-journey-so-far/", "published_at": "2026-08-23 00:00:00+00:00", "updated_at": "2026-09-12 19:53:41.482185+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models", "ai-products"], "entities": ["Claude Code", "Claude", "Anthropic", "Neovim", "Model Context Protocol", "SQLite", "Cayley", "BoltDB"], "alternates": {"html": "https://wpnews.pro/news/the-journey-so-far", "markdown": "https://wpnews.pro/news/the-journey-so-far.md", "text": "https://wpnews.pro/news/the-journey-so-far.txt", "jsonld": "https://wpnews.pro/news/the-journey-so-far.jsonld"}}