Vibe-Coding

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: ...

Why This Caught My Eye The argument is that code you vibe-coded becomes legacy code the moment you move on, because nobody understands it well enough to maintain it confidently. That includes you, two months later. This sits in direct tension with what I write about in the “Vibe Coded and Lived to Tell” series. My take has been that vibe coding is a valid learning ramp and a legitimate prototyping tool. I think both things are true: it gets you moving fast, and the output is fragile in a specific way that earns the legacy label. Interesting read. ...

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. ...