Over the last few weeks, I picked up an old codebase of mine again: miniOS, a small x86_64 hobby operating system kernel that dates back to my university days. It had been sitting around for a long time in that familiar state many personal systems projects eventually reach: promising, educational, and full of interesting ideas, but also weighed down by old design decisions and unresolved blockers.
That combination makes such projects oddly difficult to resume. You still remember why they matter to you. You still know there is something worthwhile inside them. But every attempt to continue starts with the same exhausting phase of reconstructing context, rediscovering broken edges, and trying to remember why some piece of code was written that way in the first place.
For years, that was more or less the state miniOS was stuck in.
Why I started looking for a better workflow
Like many others, I first approached AI-assisted development in the obvious way: open a chat, ask for a fix, paste some code, repeat. That can be surprisingly helpful for small, isolated tasks. But it also falls apart fairly quickly once a project has any real size or history.
The problem is not only whether the model can generate code. The problem is whether it can hold on to the thread of a larger effort.
For a codebase like miniOS, I need more than snippets. I need:
- a clear understanding of the current codebase
- context that survives across sessions
- requirements that are written down explicitly
- a roadmap for larger work
- a way to resume later without starting from zero
That is exactly the gap that get-shit-done is trying to close. Instead of treating an AI model as a glorified autocomplete engine, it treats it more like a partner inside a structured engineering workflow. The point is not just to generate output, but to preserve the state of the work in durable artifacts.
In practice, that means files such as PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, and phase plans.
Those files are documentation, but they are also working memory.
Claude Code as the main driver
In my own workflow, Claude Code has clearly become the main environment for this sort of work. That is where I spend most of my time, and in practice I mostly use the Sonnet and Haiku models.
The reason is not particularly glamorous. It is mostly about cost and day-to-day practicality. Opus may be attractive for some tasks, but it becomes expensive quickly. And even a Claude Pro plan is exhausted surprisingly easily once you are doing sustained, iterative work in a real repository.
So my default tends to be:
- Sonnet when I want solid reasoning depth for substantial codebase work
- Haiku when I want a lighter, faster pass without burning through expensive usage
I do sometimes fall back to Gemini or OpenAI Codex when Claude has hit its quota. That happens. But I do not think that is the most interesting part of the story. The more interesting part is what happened once I combined Claude Code with a workflow that was disciplined enough to handle an old, complicated project.
Returning to miniOS
Once I approached miniOS through get-shit-done rather than through ad hoc prompting, the character of the work changed. The project stopped feeling like a pile of old decisions that first had to be excavated. It started to feel like something I could methodically move forward again.
That was the crucial shift. I was no longer asking a model random questions about an operating system kernel and hoping the answers would somehow add up. Instead, I could re-enter the codebase with structure:
- inspect what was already there
- identify blockers
- preserve decisions in writing
- break work into phases
- keep enough continuity that the next session could continue instead of restart
For a project like miniOS, that matters enormously. Operating system development is not forgiving. There are too many moving parts, too many places where an old shortcut can come back to haunt you, and too many moments where a small misunderstanding of the system leads you into a dead end.
The results surprised me
What I find most exciting is that this was not just a productivity trick in the abstract. It led to concrete progress.
With the help of Claude and the get-shit-done workflow, I was able to work around functional blockers that had effectively been sitting there since my university days. miniOS now boots into a complete shell environment. It has gained SMP support. It also has filesystem support.
Those are not cosmetic changes. They fundamentally change how “alive” the project feels. The system has crossed an important threshold from “interesting old hobby kernel” toward something that is genuinely becoming usable as a learning platform.
Why that matters to me
I think this is the part that often gets lost in discussions about AI coding tools. People focus on benchmarks, model rankings, and one-shot code generation demos. But that misses something much more relevant:
Can a workflow help you get unstuck in a codebase that has real history?
For me, miniOS has become a clear yes to that question. The success here was not that AI magically produced an operating system. The success was that it helped me bridge the distance between the project I once built and the project I wanted to continue.
That is a much more interesting capability.
Workflow matters more than model tribalism
This is also why I care less and less about model tribalism. Of course, the choice of model matters. Of course, tools differ. But a strong model without durable context will still lose track of a larger effort.
A disciplined workflow, on the other hand, lets you preserve the important parts:
- what the project is
- what the current goals are
- what has already been decided
- where the blockers are
- what comes next
Once that structure exists, even switching tools becomes less painful because the important context is not trapped inside a single chat history.
Looking ahead
I am genuinely happy with where miniOS has landed over these last weeks. It has become something I actually want to release soon.
If you are interested in operating system development and want to learn how things work at a lower level, I think it may turn into a worthwhile little project to look at. That, more than anything else, is what makes this workflow feel valuable to me: it helped turn a long-stalled university-era codebase into something that feels alive again.
If there is one point I would take from this experience, it is this: if you want reliable outcomes from AI-assisted development, do not only compare models. Compare workflows.