Reliability engineering often starts with tooling, but the durable work starts earlier: naming what actually fails.
That sounds smaller than it is. Names are the unit that lets an organization learn from production. Without them, incidents remain stories: this deploy, that overload, this dependency outage, that missing alert. The stories may be accurate, but they are hard to compare. They depend on who was in the room, who wrote the postmortem, and which details were memorable under stress.
I have written before about reef-pi as a public engineering artifact: modules, documentation, community, hardware. That post surveyed the shape of the project. This one is about a single line inside it.
The difference between a project and a platform is not size, and it is not popularity. It is whether there is a boundary somewhere in the system that the maintainers agree not to cross, and whether that agreement survives contact with real hardware.
The first time I cared deeply about infrastructure as code, the argument was not really about Chef.
Chef was the tool in front of us. It gave us cookbooks, recipes, resources, and a DSL for describing how machines should be configured. But the deeper argument was that operational knowledge should not live only in tickets, shell history, wiki pages, and the heads of a few senior engineers.
If a server needed a package, file, daemon, permission, or dependency, that intent belonged in code. If a change could break production, it deserved version control, review, testing, and a release path. If an operator repeated the same judgment, the system should eventually learn it as an artifact.
The more I use coding agents and LLMs for real work, the less I think of prompts as throwaway text.
A useful prompt is not just a question. It is a small interface. It carries assumptions, constraints, examples, preferences, and failure modes. A project instruction file is even more explicit: it tells an agent how to navigate a codebase, what quality bar to hold, which tools to prefer, and which boundaries not to cross. A context pack does the same thing for a domain. It packages durable facts, active goals, source notes, open questions, stale claims, and sensitive exclusions so an agent can reason from the right starting point.
This website is my public professional and project archive. It collects writing, talks, papers, open source work, and selected project notes that are safe to publish outside my private knowledge base.
The site is intentionally simple. The content is the main surface: public engineering themes, open source projects, reliability and operations writing, and posts that connect software systems thinking with physical computing projects such as reef-pi.
The current refresh uses a public-only publishing pack generated from my personal LLM wiki. That pack filters for public wiki pages and public source manifests, then produces source-backed context for website updates. Non-public wiki material stays out of the website workflow.
Looking back across my public talks and writing, the same idea keeps returning in different forms: operational work should become software.
In the early 2010s, that meant Chef, infrastructure as code, and testing cookbooks. At PagerDuty, it meant CI/CD for infrastructure, TDD in operations, and service discovery with Consul. At Uber scale, it meant production engineering, capacity management, incident taxonomy, and ML-assisted operational decisions.
reef-pi started as an open source Raspberry Pi reef tank controller. The public record now shows something larger: a hobby controller that grew into a small ecosystem of software, documentation, community support, and compatible hardware.
That arc is interesting to me because reef-pi is not only about aquarium automation. It is a compact example of how public engineering systems mature when they need to survive real users, real hardware, and long-lived maintenance.