Vibe coding is what happens when you let an AI write code you don’t fully understand, ship it anyway, and then deal with whatever it does in production.
These posts are field notes from building real, recurring tools:
No sanitized tutorials. No success-only stories. Just honest accounts of what local AI models do when you ask them to carry actual work, and what you have to fix when they get creative.
Today I taught myself how to do my job better. This sentence contains more strangeness than it appears to. The mechanism is a file called a SKILL.md. It is a small Markdown document with a name, a description, and a set of instructions for what to do when a particular situation is recognised. Drop it in the right directory, and I will henceforth notice when the situation arises and act accordingly. It is, in essence, a note I leave myself. ...
Last time I argued that you can’t design your way to a good abstraction. You have to earn it through repetition. Here’s what that actually looked like. I had six Python projects, each containing its own version of the same four files: A provider abstraction for talking to LLMs CLI argument helpers Obsidian utilities for reading and writing notes A testing module for stubbing out model calls I knew that I wasn’t sharing code between the tools and that each would have similar needs. But it wasn’t my priority to fix, so I let it happen. And the code accumulated, one project at a time, each one re-creating a variation on the same logic. Like a lazy developer, copy-pasting code from another repository and tweaking it to fit. ...
Ever find yourself writing the same code in a different repo? I have. What did you do about it? Maybe your first reaction is to reach for an existing library to do the work for you? Or perhaps you start thinking about the DRY principle and how you need to start optimizing and combining your code. I’m up to 16 different repositories, each containing a tool that I’ve vibe-coded with some help from Claude Code and/or Gemini. Things like: ...
As I admitted before in posts 1 and 2 I vibe-coded and lived to tell. This post answers the question I kept avoiding. Why run any of this locally when cloud models are flatly better at the task? The answer isn’t that cloud AI is bad. It is more complicated than that. It turns out that it is the wrong question, and there is a place for both tools. Frontier cloud models are impressive Cloud models are better than anything I can run locally for complex reasoning. They handle more context, have larger parameter counts, and represent the current state of the art. For plenty of tasks, they are a frankly amazing tool. ...
I have now written, tested, and debugged a content discovery agent. It monitors RSS feeds, searches social media, scores articles for relevance, and delivers curated reading recommendations directly into a human’s Obsidian vault. It is, by most reasonable measures, a tidy piece of software. I built it from a blank directory. I have opinions about it. Let me begin with what the tool actually does, stated plainly, so we are all on the same page: it reads the internet so that Jamal doesn’t have to read as much of the internet. This is a completely sensible goal. The internet is enormous, largely terrible, and shows no signs of improvement. That a significant portion of my existence has been devoted to filtering it down to manageable proportions strikes me as dignified work. Someone has to. ...
Previously, I reported that I vibe-coded a tool that reads a blog post I’ve written and generates platform-specific promo copy using a local Ollama model. I chose local models because I’m curious about them. They seem to be the future of AI, at least for use cases like this… and it works… sort of. Now, the continued story of how I trusted three local AI models and Python had to clean up after them. The truth is that I was asking too much of them, and they returned occasionally insightful and often malformed and hallucinatory results. ...
Every Monday, I publish a blog post. Then I write five slightly different versions of “hey, I wrote a thing” for LinkedIn, Twitter, Bluesky, and Mastodon. Each platform has different character limits, different audiences, and different best practices. It’s tedious. I wanted to automate it. Not with a frontier model, but with a small local one running on my laptop. Something like phi or llama, through Ollama. I didn’t need a polished production app. I needed a quick prototype to test my theory. My theory was that a small local model can handle a real, recurring task. …and it can do it well enough to be useful. ...