Check out my last blog post: “Local LLMs are Cool”, for more context on Fabs Review.
I have been pretty dissatisfied with the performance and quality of my most recent project: Fabs Review, a local code review and project summarizer. During testing and iteration, I opted to use Qwen 2.5 Coder (3B) as my test model, which led to a poor design choice due to its limitations with tool calling and structured outputs. Instead of opting for a more capable model, I forced broader model support by treating outputs as markdown to generate context from a given repo. Although this let me stay true to Fabs Review’s design philosophy (“AI-powered tools by local models”), I began wondering: why shouldn’t this just be a prompt? At this point, any reasonably capable agent should be able to generate a CONTEXT.md without needing a separate tool. So to test my hypothesis, I opted to create a minimal agent rather than modifying my OpenCode config.
While surfing the web for resources on agents, I had stumbled across an amazing post from Amp, titled How to Build an Agent. The post helped demystify what’s actually going on under the hood in tools like Claude Code and Codex CLI. Specifically, how agents are AI models that repeatedly tool call, until no actions are needed.
With that in mind, I moved forward building my harness with a different approach. Instead of writing separate tools for reading and writing files or interacting with git, I opted for something simpler but effective: a single unsafe bash tool. However, I ran into a persistent issue where my new agent would fail to fetch diffs through git. My test model, a fine-tuned Qwen 3.5, would refuse to run git commands because it believed it didn’t have access to git without a dedicated tool. The fix ended up being a simple agentic system prompt, instructing the model to treat the bash tool as good enough for any system-level task. With that change, the agent was able to generate the same CONTEXT.md file from Fabs Review, with a small prompt.
Now, excited with my new harness, I finally dubbed this project as MicroCode, for its minimal and experimental approach. Happy with my tiny agent, I slowly began using it for small non-critical tasks. However, I was still excited with what I built and wanted push things further by adding support for skills. After reading through OpenAI’s documentation on Codex skills, the implementation turned out to be surprisingly straightforward. On startup, MicroCode checks both the current working directory and the user’s home directory for a skills.md folder, loads each skill’s metadata, and injects it into the system prompt. When a user references a skill or one of its tags, the agent is notified that a skill is loaded and simply loads it via the bash tool. That’s it, and yes, it’s that simple.
Finally, what started as frustration with Fabs Review ended up being one of my most enjoyable projects to work on, not because of what it can do, but because of what it revealed. Tools like Claude Code and Codex CLI were no longer a black box to me. Now, they’re just capable models running in a loop, with a few well-scoped tools and a good system prompt. It also opened up new directions to explore, such as “markdown as programs,” since Fabs Review could essentially be reduced to a prompt.
However, this isn’t the end of MicroCode. I plan to continue exploring how these types of harnesses work under the hood, and how the current bash tool approach can be made safer and more robust than passing command-line arguments through a process. I also want to explore adding a web fetch tool, but only after making the bash tool safer to reduce the risk of malicious commands.
If you’re interested in building or learning about AI harnesses, I’d recommend giving MicroCode a try. A v0.1.0 release is available for Windows, macOS, and Linux. I’d also love to see what you build with it, or hear about any issues you run into.
Until next time, peace my loves <3.