Bootstrap, an engineering exercise (part 3)
4 min read
This last part in the series of posts on my bootstrap project talks about making the project boring. In this case, boring is a very, very good thing.
Boring
The most important thing about this project was that it needed to be boring. Elegant over efficient and consistent over creative. It needed to be reliable.
Building boring meant lots of testing, lots of linting, lots of standards compliance verification. Each and every change required going through a battery of unit tests so that new changes were demonstrably safe with old code. If this project was to be documentation-first, then it would be testing-second. Each change was built by establishing tests first – tests designed to fail – that would only pass once the code was changed successfully.
After unit tests were built and verified, end-to-end testing needed to be included. To mimic a fresh, minimal environment as best possible, I used containerized end-to-end tests that started with only the slimmest of base functionality. It wasn’t sufficient to show that individual slices of logic worked as expected; the whole tool from start to finish needed to be verified.
The tool used elevated privileges to do what it needed to do. That is, it needed administrative, root access. Because of this, everything the project did needed to be beyond reproach, maximally safe, consistent, and safe. When someone would download the project, I wanted them to be assured that what was being done on their system was safe. Running my script as root gave me complete and total access to their system to install whatever I wanted. Therefore, I was being trusted to responsibly interact with their system using my code as a proxy. Every step, every reason, every decision needed to be safe and transparent. Builds needed to be transparent. Code needed to be transparent.
Builds needed to be repeatable and verifiable. Each release included a cryptographic hash and an attestation. Each dependency, each tool, each step needed to be open to review.
In asking potential users to trust me, I assumed the responsibility to make the experience as reliable as possible. I assumed the responsibility of making this project as safe as possible and as boring as possible.
One area where I didn’t anticipate the bootstrap tool helping was with the building of container images. Typically, I’ll include a RUN apt-get install to install the packages used by the image. While that works, it also makes it more difficult to audit what’s being installed. Some tools like Trivy can raise objections that packages’ versions aren’t pinned, so this results in lines like this:
RUN apt-get install something=1.2.3 something-else=4.5 a-thirdthing=7.8.9-p0Parsing that can be challenging for a general tool. Instead, consider this:
# This package does something
something = 1.2.3
# The foobar application requires at least version 4.5 of something-else
something-else >= 4.5
a-thirdthing = 7.8.9-p0The package manifest is general, accessible, and auditable.
The Results
Overall, I consider the project to be a success; it produced exactly the results I had hoped to achieve. I was able to use the bootstrap tool on a variety of different systems, all without major issue. Some systems highlighted where the system could use improvement (e.g., a large manifest of packages should show progress to assure the user that it’s working properly).
No systems were rendered inoperable. Nothing broke.
I did not write a single line of code. I wrote a single document explaining why I built the tool, but otherwise the entire project was drafted by an LLM.
If you’re interested – and I hope you are – you’re welcome to explore the repository as it’s accessible publicly on GitHub:
https://github.com/wesley-dean/bootstrap.git
The deliverable has a stable URL where the latest or individual releases can be directly referenced:
https://github.com/wesley-dean/bootstrap/releases/latest/download/bootstrap.bash
If I had to wrap this whole experiment up, I would say that I’m very pleased with the outcome. I now have a tool that I can use reliably across many different contexts. I would do this project again and I would use this exact same approach.
The experiment didn’t convince me that AI replaces engineering. It convinced me that disciplined engineering makes AI-generated code practical. The value wasn’t that an LLM wrote the code; the value was that every decision, assumption, interface, and test constrained what that code was allowed to become.
Would recommend.