Paul Dix
· 6 min · Original

The Software Factory and the Inevitability of Recursively Self-Improving Software

I’ve been working this year towards building a software factory for InfluxDB, the time series database I’ve spent the last 13 years working on. I’ve referred to this software factory effort as building the machine that builds the machine. If you’re not familiar with the phrase software factory, what I’m referring to is a running software system that continuously builds improvements (bug fixes, features, performance enhancements) for the product we sell to customers, which is InfluxDB. So far, most of my focus has been on building elaborate test and verification infrastructure that agents can use to validate software changes. Which, I think, is not what most people think of when they think of software factories. However, a software factory can’t work without proper verification (but that’s a topic for a future post). As I move into what I think is more traditional software factory building (i.e. creating workflows and agents running them), I had a realization that seems rather obvious in retrospect, but it struck me as pretty radical. Recursive self-improvement (or RSI) isn’t just for creating some super intelligence AI. Any software system that is produced by a software factory has the potential to become recursively self-improving. To see why, we’ll have to dig into the details of what a software factory might look like. (Note: this entire post is written lovingly by hand by me personally with no AI, but the following visualization was created by Opus 5.5 at my direction) At the top of the factory you have inputs (e.g. from humans, production monitoring, and agents) and on the bottom you have outputs like a software artifact, a cloud service, messages and outputs to third parties, reports, documents and work that feed back into the factory, and the systems of the…

Paul Dix
· 5 min · Original

AI is the greatest gift to every self-starter

I thought of writing this post last month when I read that Duncan Sheik had died. He was the singer-songwriter with the hit single Barely Breathing, released in 1996. Now, you might be asking yourself “what does the death of a one-hit-wonder musician from the 90’s have to do with AI or self-starters”? Well, hit play on this and travel back in time while I connect it to me. ▶ Play “Barely Breathing” by Duncan Sheik on the site As I read Duncan Sheik’s NYT obituary, his hit song started playing in my head and I remembered this year and time in my life very clearly. I was one year out of high school working as a PC and printer technician in a small computer shop in Denver in a part of town known as the DTC, or Denver Tech Center. Believe it or not, it had actually taken a bit of time and effort to get this job. At the time I graduated high school in 1995 I couldn’t figure out how to pay for college but I knew I wanted to work in computers. So I got a job at Computer City (a big box retailer) on the sales floor just to get proximity to their tech department. They let employees borrow the tech books they had and I read through those in my off work hours to learn enough to get A+ Certified for PC repair. I parlayed that into a job in the Computer City tech department and then got enough experience to go off to this small computer shop in the DTC, which built and serviced computers for tech and telecom companies with fancy offices in the heart of Denver’s very nascent tech scene. While working in this small shop I learned from one of my coworkers of another certification that might enable me to land a job in one of those fancy offices: The Microsoft Certified Systems Engineer, or MCSE. It was a certification that consisted of 6 tests on the topics of Windows NT 4.0, Exchange…

Paul Dix
· 9 min · Original

The end of programming

Last week Bun 1.4 was released. This was the one that contains the rewrite of Bun from Zig into Rust, apparently containing more than 1 millions new lines of Rust code. And while this caused a bunch of drama in the programming community centered around the language switch, I think the most important thing about this release is how the rewrite was done and the scale of it. The details of this, along with my own experiences, and soon to arrive advances in AI lead me to believe that we’ve arrived at the end of programming as we know it. What I mean by this is that I think the act of writing code manually and having other humans review it to create useful, working software is headed for extinction. Or at the very least, it will be drowned out by the absolute deluge of useful, working software that will be created by agents, with humans reviewing only the end result, not the code itself. We’ll have more software than we’ve ever had, but most of the code for it won’t have been written or even read by humans. To be sure, there will also be a mountain of slop. Of buggy, useless, terrible, offensive software that conforms to no programmer’s sense of aesthetic or purpose and style. But there will also be well engineered, working software that solves real problems, yet hasn’t been reviewed in fine detail by human eyes. This explosion in software can already be seen in this graph from GitHub’s post about their August 17th outage: Since last year there’s a steep exponential climb in the amount of code being produced. My theory is that most of this is actually from side projects or projects internal to companies that are skunk works, or for individual users. Things that are viewed as non-critical. In most companies, there is still significant organizational friction to individual…

Paul Dix
· 6 min · Original

You might not have to read that code

There’s a lot of debate right now about if developers doing agentic programming need to review their code. Most sane and sober voices are loudly proclaiming that, yes, you need to read it. But, and go with me for a moment, do they really? Every programmer working today has shipped production software using a mountain of code they’ve never read or even understand. The operating system, the programming language, the web framework, the database, the message queue, the cache, the libraries, the dependencies… how much of it have you read? How much of that could you really give detailed explanations about how the individual parts of them work? I’ve been at this long enough that I’ve probably forgotten as much as I currently know. I’ve forgotten the individual specific details of code I myself wrote, by hand, like a computer science pesant. I’ve even had that experience when developing in a large code base, I’ve come across some specific bit of code and thought, that’s dumb, who did this? Only to find out after a git blame that it was me, I was the one that put that stupid line of code into the code base. And guess what? It passed code review. I think most projects and enterprise applicatinos in particular are still doing human code review like they were a year ago. We certainly are at InfluxDB. And every bug those enterprises (and us) have shipped has passed human code review. So maybe human code review isn’t as good as we like to think it is? Of course, the other argument for it is for knowledge sharing. Sure, knowledge sharing is important, but you actually don’t need line-by-line code review to achieve that. A short doc, or presentation with visualizations can give another programmer the details of how the system works, without the specific lines. Although there is the…

Paul Dix
· 7 min · Original

There's alpha in AI free writing

I’ve noticed lately, as I’m sure most of you have, that more and more of what I read every day is written by AI. It’s obviously in my agentic coding sessions, of which there are dozens in any given day. But it’s also in Github issues, pull requests, Twitter, LinkedIn, and even creeping into Slack. I’d wager that most of what I read in any given day is written by AI. Until AIs learn to write much better, and particularly in more concise, terse language, there’s an attention advantage given to anyone that puts their own thoughts and words together without AI doing the editing or writing. This post, and the sporadic, infrequent writing that I intend put up on this site, is an attempt to take advantage of something I think is a unique advantage at this peculiar moment in time: writing without the AI is more likely to get other people’s attention and fewer people are doing it than before AI. There’s also the added benefit that I think writing helps one think through a problem or organize their thoughts around a given topic. Tuning your language helps tune your thinking. My posts likely won’t be very long as I value concise language and thoughts. This is in high contrast with typical AI writing which is happy to drown you in flowery language, irrelevant details, or more specificity than is warranted for some given communique. This isn’t to say that I’m against AI writing. Most of the time these days I have AIs write issues for me in Github, write PR descriptions, commit messages. But if I intend to have a coworker read it, I’m trying more and more to distill down what was produced by the AI to something more bitesize and manageable. It used to be that I’d just read through and do light editing. But since I see more and more AI driven writing getting put in front of me, I…

Paul Dix
· 3 min · Original

Build the machine that builds the machine

(Note: this is a copy of a post I originally published on X on January 15, 2026, before this site existed. Unlike everything else I write here, I iterated with AI to finish this one. I still wrote it, but I did use AI help with editing and changes, so if it reads a bit different, that’s why. See There’s alpha in AI free writing for why the rest of the words on this site are written without AI assistance.) Coding agents can produce the first version quickly. The difference between a demo and a deployable change is verification, and the verification stack is what actually improves agent output through rapid iteration. Build that machinery, and you get speed and quality at the same time. There’s a manufacturing idea that goes something like: the real product is the factory. It’s the machine that builds the machine (i.e. end product). An agent with the right tools and verification loop can build many different parts of the product. Building the infrastructure and tooling to point many agents at many different features and problems is, for software, building the machine that builds the machine. They become the way to reduce cycle time, increase velocity, and deliver the final product faster than ever before. At InfluxData, that means investing heavily in test + validation infrastructure so agents can operate inside tight verification loops across objectives like: implement this feature fix this bug investigate this production issue improve performance in a specific subsystem The goal is to move review effort up the stack: from line-by-line scrutiny to verifying behavior, performance, and safety via repeatable checks. All of which should also be accessible by the agents doing the work. Of course, that’s not where we are right now. We’re very much in the category of doing…