Python

I have a text file with 26 tool ideas on it. That number keeps growing. And for the first time, that feels like a good thing. For most of this series, I’ve been writing about what happens when you vibe code a bunch of tools and let the architecture emerge. The copy-paste period. The shared library extraction. The Makefile that almost didn’t survive. This post is about what comes after. The infrastructure is in place. Starting a new tool is cheap now. So the question changes from “can I build this?” to “what’s worth building next?” ...

I was in the middle of the shared library extraction when I ran out of Claude tokens. Six repos deep, changes half-committed, migration plan half-finished. This was not ideal timing. So I opened Gemini CLI and handed it the plan. What followed was messy, instructive, and produced one idea that was better than anything I’d come up with on my own. Running Out of Tokens at the Worst Possible Moment Context windows and token budgets are real constraints when you’re vibe-coding, especially across multiple repositories. A six-repo migration with shared dependencies, coordinated test suites, and a consolidation plan burns through tokens quickly. This was also before I slimmed down the context I sent with every prompt. ...

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

I always learn something at the PyTexas training day. This year, I learned how little I actually know about Python imports. Heather Crawford ran the morning session on sys.path, modules, and packages. I have been writing Python long enough to fix ImportError messages without understanding them. The mental model she gave us helped me make sense of it. Find, then bind. Everything flows from those two steps. I had to redo my imports multiple times during the lab exercises. I still need my notes to walk someone through the whole picture, but I have a map now where I had guesses before. ...

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

How do you run a local LLM from a Python script? Install Ollama, pull a model, install uv, write one file with inline dependencies, and run it. No API key. No virtual environment to activate. No Docker. The whole setup takes under ten minutes. Why run local Three reasons: cost, privacy, and offline access. Frontier APIs charge per token. For experimentation, prototyping, and batch tasks, those costs add up before you have anything to show. A local model costs nothing per call. ...

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

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

Why This Caught My Eye Getting started with new things isn’t easy; this can hold true even in the age of AI. Time, money, and entropy can keep the best of us from getting started with learning a new technology. This post gives you sample code and the LLM provider that you need to get started on your agentic learning journey.

Last week, we got DuckDB running with three hardcoded rows. That got us started, but three rows? You can eyeball that. Let’s generate hundreds of realistic customers and build a dataset worth exploring. Python has the perfect tool: faker. It’s a library that generates realistic fake data: names, emails, addresses, dates, and anything else you’d find in a real database. Let’s use it to build a dataset we can explore for the rest of this series. ...