Scaling and Ceilings

Lately I've been involved in the very difficult task of figuring out what "Agentic Software Development Bottlenecks" actually means (Muh Code Review Too Slow anyone?) and have necessarily been absent from authorship while I put my whole being into moving our processes to a new age. It's probably worth briefly outlining what this actually means: The Bottleneck Of Scale!

The Bottleneck of Scale

I'm an avid Factorio fan. Diehard, actually, one of the greatest games of all time. What you realize while playing is that "scale" is really just a fancy term for process. You can mine all of your iron with burner miners, but you don't want to because that's boring! So you enhance your production lines with scalable tooling and infrastructure, you learn patterns of building that leads you towards reusable systems, and you design factories that get out of your way. It's Very Fun, and it's what I've found my profession to ultimately be: scaling systems so the systems get out of our way.

What's become apparent in recent months is that our software output has been stoppered by our verification process. We only have a few people who's responsibilities vary and who's priorities are unstable, so verifying the "Quality" of a given project can take a good while. The problem we had was that our deployment process has a few different environments we deploy into, and originally we used isolated branches for this. Huge problem with that is once your code velocity increases, suddenly even unrelated changes collide with each other on non-main branches, causing deployment "brown-outs" (endless merge conflicts). So I spent a few weeks and many hours building out our team's feature branch system and deciding on a more-robust CI/CD strategy for agentic deployment (push straight to main haha).

I joke a bit but I truly think "straight to main" is correct these days. Time to Deployment being hours as opposed to days means agents aren't colliding on shared utilities, problems are solved immediately, and long-lived feature branches don't require hours of a senior developer's life to parse the git merge conflicts. This is how I do stuff at home because my scale is small, but at work? How can I be confident "straight to main" is correct?

You see, that's the time sink. I spent weeks combing our new test suites, correcting issues, designing merge queues and pipeline yamls to make sure our pipelines are fast, cost-efficient, and correct! It was particularly important I did this now as opposed to later because we are currently in a very opportune moment at MenuMetric to restructure our deployment infrastructure for reasons I'm not at liberty to declare here. However, It's given me great insight into the future, and in particular scaling our infrastructure in such a way that it gets out of our way so we can solve problems faster, more correctly, with fewer hours spent hemming and hawing over if it actually works, because we now have a deployment procedure that guarantees past performance for the current deployment.

I'm a few days away from declaring myself the Devops Tzar of MenuMetric, another one of my many titles I have taken up. Anyways Laravel's Pennant is pretty slick and Merge Queues are awesome, I think I'm going to be taking a lot of these lessons from work and applying them to this site, which has been dormant for a while. Lot's of stuff to do, I need to make some GPU Steam soon.

Slice of Life

I've finally got a site redesign prepped for here, and I've also been on the Dependable C bandwagon lately, so expect to see some C projects. At some point I swear I promised a native reader for this website specifically. I have been building my own ncurses library from scratch; TUIs have always fascinated me, so that's what I've been up to lately.