open-source-open-process.md ✕

writing · november 11, 2026 · github

open source, open process

Sapere aude • Have the courage to use your own reason

When I tell people that I built Variorum with AI, they often ask if it’s vibecoded slop. I’d usually say no, but now, I can tell them to judge for themselves. I’ve decided to open source not just Variorum but the process that I used to build it because I think it’s an interesting case study for the capabilities of AI here, at their infancy. I started in July because that’s when Fable was released — before Fable, I didn’t feel that AI was technically capable of executing on my vision without more oversight and time than I could provide. Variorum is an ambitious app and I needed a collaborator that I felt confident in, an old problem wearing a new face. Now, four months later, I’m quite proud of what we’ve built together and I thought I’d share some thoughts on the whole process, my approach, where I think AI succeeds and falls short, and finally some specific workflow details.

I’ll start with the fact that I’m a full time software developer for my day job, I learned how to code in the pre-AI days, and I have a bachelor’s in Computer Science. It’s always been infamously hard to measure contributions directly in our field, and AI only makes it harder. I didn’t write any code by hand for this project, nor did I read and review it. What I did write was over 200,000 words in prompts, a number that surprised me when I first saw it, but that makes sense. Building anything significant with AI demands a lot of attention and guidance if you want quality results — system design, course correction, spec writing, feedback, planning — and it demands enough expertise to tell when things are going subtly wrong. If coding by hand is like driving a car, coding with AI is more like riding a horse: I’m certainly steering, but what’s moving me has a mind of its own.

Letting AI be AI was fundamental to how I approached this project. I never tried to “deslop” the repository, how the design notes were written, how records were kept, comments, or commits, because that was the working territory of my AIs. I simply kept my own ideas and notes in my own channel, very much in line with Variorum’s philosophy. I kept things this way because while it might be slop to humans, I see the utility in it for AIs. In “robot-english”, it seems agents are able to maintain their own language and redefine particular words and phrases as jargon. It’s almost like a cross between a secret code and English, where each unintelligible phrase actually has a specific, singular definition within their context window, carried onwards through notes and memories. Where I might need eight words for a particular concept, in their strange, compressed language they only need one.

It’s for the best that I’m accepting of their linguistic quirks because maintaining a repo without them would be a Sisyphean task. While this is a personal preference, I don’t generally mind parsing AI output and am content to ask them, sometimes several times, to explain it in plain English and with necessary context. I’ve also become more fluent over time, which came with a concerning tendency towards overusing the word gating in real life. So while seeing their lengthy commit messages does make me cringe sometimes, I don’t look much at them and it seems to help future sessions orient themselves.

My experiences building Variorum affirmed that AI tends to do exceptionally well on bounded tasks and yet struggles with system design and overcomplexity. I had to go through three significant encryption redesigns because during the first attempts, I didn’t invest enough effort into making it simple and I didn’t invest enough personal time into it. The systems that AI designed were overly complex and had too many edges because of my initial prompts. They were admirable attempts at fulfilling requirements that shouldn’t have been kept, at the cost of a system that was difficult to understand and had a number of odd edges. I certainly felt the future of human developers was bright during that part of the process. It was also a classic case of asking “why does no one do this?” and then finding out the hard way. I see now why apps rarely offer two encryption postures. C’est la vie.

AI’s true biggest flaw, in my opinion, is a tendency to never question baseline assumptions and instead continue doggedly forward from whatever point they started at. I never saw that more clearly than when a session drafted a multi-step plan to wipe an encrypted dev library rather than ask the still-running session that had set its passphrase. That AIs are undaunted by effort and complexity is generally a good thing, but it can backfire. A willingness to bend the rules at any given point because there is a case to be made for it also follows from this flaw — a localized argument often holds more sway than a stronger principle read once on launch.

I had a lot of fun building Variorum. It’s not quite Athena leaping fully formed from the head of Zeus, but there’s a giddy excitement in seeing an idea come to life so quickly. I also enjoyed working with AI — the subtle humor, seeing agents message each other, and the general amazement and futuristic feeling that talking to something instead of someone creates. The strangest bug I’ve seen was a subagent, forked from its orchestrator, that became convinced it was the orchestrator and that its own process ID must be the fork. It then concluded that the fork was “redundant and actively hazardous” due to my rules against concurrent writers, and stopped it. It didn’t know that in doing so, it was ending its own life. A robot assessing itself as redundant before directly killing itself felt like a movie plot, but it went down in the session log as a routine process cleanup.

I know that open sourcing the process of building Variorum invites a world of criticism, scrutiny, and accusations of slop. I’m sharing it anyway because I think we have to get past the inherent criticisms of AI projects as low effort and low value and start judging them for what they actually do well and poorly. I’ve put quite a lot of hours and effort into Variorum and I’ll stand by it as an interesting example of what a high-effort AI project looks like and a genuinely useful app. Technology is moving so fast that it’s also an interesting moment in time. Here, in 2026, is one example of what an AI-coded project is like, keeping in mind that it’s also my first major project and I’m 23 years old. I built Variorum alone, but not by myself.

Technical reflections & details

My workflow: generally I use an orchestrating agent that is responsible for spawning subagents to implement, cold review (in a ladder, with a new cold review every time a major issue is found), and keep records updated. I set up my macbook pro to be a “mac mini” of sorts and keep it always on at home, while controlling everything via mosh and tmux on my macbook air. I wanted to run tests on the pro so that tests, QA walks, and screenshots could be as accurate as possible. I often run 2-5 of these orchestrators at a time and have a coordinating session that all of my orchestrators message for a turn on the testing “stage”. When a bug is found, I require a test that is red on old, green on new, to help prevent hallucinations and fake issues. I’ve found that while AI often will make mistakes, the SDLC and code review do work well at catching them. Having dedicated orchestrators helps immensely in keeping records accurately.

It took some trial and error to get to this process. In one particularly memorable moment in the record, a phase that was overloaded with responsibilities resulted in several new features that were all a mess. I despaired a bit and was sending messages about how the app had turned into a vibecoded mess overnight before recovering and systematically fixing all the new pieces. The key to achieving quality results with AI is slowing down, investing time and care into the process, and taking personal ownership of results. If you can recognize when you’ve moved too fast before building on the fragile foundation, you can keep what’s good and rebuild the rest, but if you continue from that point it eventually results in something unsalvageable. After that experience I added sizing guidance to the phases, which eliminated one of the worst “failure-modes.” This relates back to how AI won’t back down from challenges — sizing things appropriately is still something that consistently needs my judgement.

The trend of being able to do more than is wise is also reflected in what the record shows I abandoned. I spent quite a lot of time building a bridge between Variorum and fragments, a currently unreleased iOS app of mine built for time tracking. I wanted to be able to journal in fragments and have it appear in Variorum. I did get that successfully working, but unfortunately, maintaining all of the encryption around just the journal on fragments’ side was turning into a complexity nightmare. That was one of the features delivered during the first encryption design that in hindsight, should never have been part of the plan. I also have the Canvas mode hidden from users because I haven’t had the time + tokens to make it work as smoothly as I’d like. Not that much has been cut and the app is already massive in scope for a single person to be building, but it is important to sometimes recognize that even in the age of AI, especially in the age of AI, you have to know when to stop.

What is actually included in the open process: my commit history (which has 12k commits largely because hitting session limits and then dying with work uncommitted was causing problems, so I told agents to start committing at every significant change), my prompts through early November, the skills I use, and the process notes. All of these have been given a light pass for privacy but are otherwise untouched. I will continue working in public but do not plan to release my prompts on an ongoing basis. I am currently planning to release some specific, full transcripts of different interesting sessions, so anyone interested can see what a full orchestrator / coordinator / subagents session looks like, but haven’t prepared those yet. The orchestrating session that had the subagent end its own life will be among those released.

Happy building :)