Victory Ledger - March 2026
In March, I was really starting to cook. I figured out that a lot of the code I was working on was going to be useful to all of the future customers of Vulcan Forge. To make it available to them, I split the code into two scopes:
- Platform-level that any tenant or customer of Vulcanforge would be able to use
- Tenant-level that would be specific to actually implementing the Vulcan Forge application
This actually has a huge impact for what I'm calling the composition unit of code.In the past you would include maybe a module or a particular service or a library that would do a specific thing like maybe read a PDF or make a web request or something. They were very small pieces.
By switching to having a platform level construct for VulcanForge, we can make the composition unit much larger. So instead of a bunch of little pieces that you have to string together to make a web server, I can just ship a web server at the platform level that any VulcanForge customer can use right out of the box.
I can provide large pieces of code that implement entire functional units, like:
- web servers
- LLM calling infrastructure
- website single page application scaffolds
- Security and login systems
- Logging clients, event ETL daemons and event databases
- Entire worker systems including queues, worker managers and worker frameworks
All of this was built over time based on the foundation built in March.
Session Rigs
We also shipped the newest form of rig in March: session rigs.
All our previous rig types required us to develop a plan for what we were about to do and then implement it using billets. This is really good discipline to make sure that we know what the AI model is about to do, can track what it actually did, and make sure that they match so we can do things like curing the rig to ensure conformance.
However, if the work is open-ended and unclear, this process can be really high overhead. Especially if we're debugging something, and we're not sure exactly how many blockers we're going to find along the way, having to create rigs each and every time before we can make a change slows the process to a crawl.
This is where session rigs really shine. Instead of coming up with a plan beforehand, what we do is open a rig that locks the repo we want to work on.
We then figure out what to tell the model what to do, either based on debugging a problem or achieving a goal or whatever it might be. We can even use plans that we build along the way to get more specific. The model then implements the changes, logs what it actually did, and commits the changes along the way.
In this way we get a good record of what happened and why and a good commit history as well as preventing other rigs from working on these repos while we're working on them.
Of course this does open the opportunity for abuse where you could use session rigs to skip all of the Vulcan Forge workflow. But we're assuming that the users of Vulcan Forge are trying to achieve the best possible outcomes, not antagonistically thwart us in our workflow design.