Post by mdorman

Last March, I started working on the piece of software that is serving this post to you. It's called jaunder, which is a Scottish word roughly equivalent to "prattle" or "gabble". I stumbled across the word in 2012-2013, and it seemed appropriate for what I wanted to do, though that goal morphed somewhat in the intervening years.

As the first major deliverable in a substantial project that I've set myself, it's doing what I want it to do well: it's a lightweight, reasonably-capable blogging engine. You can author via its web interface, which is pretty good on mobile or a tablet, or you can use AtomPub. It has an Emacs interface that works with the AtomPub interface. You can author in Org-mode or Markdown (or straight-up HTML via AtomPub). At some point I should actually put together a site for it, but I probably won't do that until I'm further along—there are many more major deliverables. But this is, for all intents and purposes, v1.0.

But this isn't so much about the software itself, as the process.

To be very up-front: I've used coding agents—a variety of them—to build this. I would strongly reject the description of "vibe coded", though I will also admit that there are parts of the code that I looked at in review before it went in, but could not pretend to be familiar with. I am absolutely certain that a lot of it could be better. In this, though, coding agents are just like the majority of the human programmers that I ever dealt with professionally: stunningly mediocre.

They create structures that are overly complex, or fail to refactor when it would make adding something immeasurably simpler, or just don't think about how one part of the system is going to interact with another. In a way, the worst thing about their coding abilities (I'm eliding all the other things wrong with them) is that they can be so fucking prolific and ruin your life at code review time—but even in that, they're not unlike some programmers I've known whose approach to everything was always more code, even when the right answer was to strip down and simplify and really understand what's going on before you lard more code into the mix.

But that's not even what I'm grinding away at right now. You see, our testing footprint has always been heavy, as an LLM can churn out a metric shit-ton of tests without breaking a sweat. Combine that with a penchant for writing complex code and my desire for good test coverage, and you've got a recipe for a lot of testing that takes a lot of time to complete. And all this is being done in Rust which is not always the quickest language to compile.

So I've spent the last few days directing the creation of a tracing framework for our testing framework, so that we can do a test run and get a trace that tells us where all the time went. And I've been looking at dismantling some of the infrastructure that's been overbuilt, and using more off-the-shelf parts, so that it can all be more inspectable and understandable. I feel like this is essential before I start the drive to v2.0: I don't want the iteration speed to be dictated by a test suite that takes an hour to complete.

But that's got me thinking about Software Engineering in general, and I'm realizing that all of the engineers that I've worked with directly and for whom I feel some admiration have been those who have understood the deep value of deleting code. Figuring out what to get rid of is vital to the long-term health of a software project. And as I've been working on this, I've realized that this is something that LLMs are not good at, and I wonder if anything "generative" can ever really master that approach?

I guess we'll find out over time. But I know I often find myself having to fight hard to get things removed instead of replaced, or new things added.