Channel Update - May 2026

Hi everyone. This is the first installment of what should be semi-regular updates about things I've been working on. I've recently been trying to post 30 to 60 minutes of material to this channel every month, but some topics and some projects are bigger or smaller than others, so I'm not always going to hit that mark. As a compromise then, I'll be posting updates like this when I need to fill in the gaps and when I have smaller things to talk about that don't necessarily warrant their own videos. First off, you should be aware of this URL where I'm trying to consolidate everything I make into one place. Every video I make will be linked here and most videos will have an accompanying article of some kind, whether just notes or a full text equivalent of the video. Note at the top of the table of contents, you'll find an update log that tracks any notable additions. In the last month, I've published three things. The first is a post entitled Procedural Programming How-To. This is something I might make into a video later, but it needs some work and fleshing out. Honestly, the title might not be super apt, so if there is a video version, it might have a different name. The post is an attempt to articulate in very broad strokes what I think good macro-level program design looks like and for lack of a better term, I'm calling that procedural programming. The post starts with a quick recap of the performance and structural problems of object-oriented programming. The structural problems I boil down to two basic things. First, an over-enthusiasm for fine-grained modularity and second, an aversion to sequential code and flat data. The post then briefly describes the alternative mental model for programming as a data transformation pipeline. Data enters one end of a pipeline, gets transformed by various stages along the pipeline, and comes out the other end. The main argument is that this mental model is the easiest thing to reason about because it's naturally debuggable. If the data comes out wrong, you can simply bisect the pipeline to find the problem. The rest of the post though then tries to explain why even this simple mental model doesn't magically make all programming easy. How it too can get overly complicated and hard to reason about, uh but also I talk about how you can mitigate these problems. Specifically, the main problems are one, poor handling of mutable state, two, overly complex data design, and three, the context surrounding your data pipeline. This is the part of the article that's probably too brief and too abstract, so it's something I should probably expand upon at some point later. The second post describes my recent experience doing full AI coding for the first time. For a while, I had been meaning to completely overhaul my Japanese vocab drilling application, and I finally got around to that using mostly Claude and Codex to make a completely new version. Before this project, I really only used AI as a Google and Stack Overflow replacement, so this was my first time properly using agents. In all, the project took me about three or four weeks to build out, though that was actually interleaved with work on other projects. Also, because adding features was so quick and easy that tempted me to expand the scope significantly. So, the program ended up actually quite a bit more than just a a vocab drilling app. Uh anyway, if token limits weren't a concern, and if the AI's simply worked faster, I I imagine I could have done the same project in less than a week. Currently, the project is in a state where there seem to be at least no major bugs, and I feel like I just have to use it for a few months myself to work out the design issues. As I describe in the post, I eventually did a full audit of the approximately 15,000 lines of code, and I found very little to complain about. To what extent that's to the credit of the AI or to the fact that I prompted very incrementally, I'm not really sure. I'll leave it to others to experiment with one-shotting whole programs, but as far as I found, the incremental prompting style seems to produce perfectly fine results far faster than what I could have done manually. So, I was overall very impressed by the AI's capabilities, though to be sure, this is in the context of a simple CRUD app. I have many more thoughts about AI, software quality, and where this is all going, so you'll probably see a post or video about that soon. The last post I made in the last month is about a regex builder library I made for Go. I've long hated regexes, primarily because of the syntax, the annoying non-standardization, and then the quirks of its concepts and terminology. So, this is something that's been on my backlog to-do list for a long time. There are of course many regex builders out there, but none that I really found matched the kind of API I was looking for. Uh for example, the Go library called Rex has two problems for me. First, it's too interested in closely mirroring the concepts and terminology of regular expressions, whereas I wanted something that isn't weighed down by that legacy. Uh and second, I want the the patterns to be composable. Meaning, having defined a pattern, you should be able to use it as an element of another pattern. Something which Rex and actually very few other regex builder libraries allow. So, the core concept in my builder API is to construct patterns as sequences of other patterns, and each parent or child pattern can have a few modifiers, such as the expected number of min and max repetitions. There's also a fairly novel approach for the equivalent of capture groups. This is another kind of side project that I probably never would have gotten around to without AI. I just have too many things on my backlog, too many things I want to do. But, thanks to AI, it's something I could very quickly experiment with. It only took me like a few sessions over a handful of days. So, most of the 1,000 lines of code were written by Opus 4.7. So, I can really only take credit for the API design. The code ended up being very simple, but offloading the actual code into AI just helped me focus on the design, and again, iterate extremely quickly. Even if the end result isn't a polished product for other people to use, it's at least satisfying for me to clear out some old mental clutter from my backlog. So, just be clear, if you take a look, this is very much an experiment. It's something that I'd again have to use over many months or years to refine and fill in the gaps, but in the meantime, I thought the core design choices were promising enough to share. As for what's next, I have a few things in the works that use Odin, which is partly why I made those recent Odin videos. I wanted to get people on the same page about Odin. Also, I've long been writing a big polemic about software quality. Hopefully, it'll be done relatively soon, though I'll definitely have to make some major adjustments to account for recent AI developments. Anyway, those are most likely the things you'll see from me next.