fidzu : django

At the end of January, I was building out the deployment and infrastructure components for the startup project, so figured it would be an appropriate time to document how I think about these concepts at high level, perhaps they will help others. Generally I think about these processes two ways. First, is to create an environment, such as a virtual machine, PaaS, or container with a code spaced hole in it for your application, then create a process that moves the code from source control into that code spaced hole environment. This represents the initial deployment at a high level. Second, I think of deployments as pipelines. With the rise of infrastructure as code over the past decade, traditional CI/CD pipelines have become cyclical: code is pushed, deployed to production, and the cycle repeats. Infrastructure code is similar to application code, but its cadence is much slower. While a typical application deployment aims for multiple pushes per day-or at least a few per week-Infrastructure as Code (IaC) is usually deployed far less frequently, often annually. Early in a project, or when creating environments for feature branches, infrastructure deployments may occur more often, but they remain cyclical: a code push triggers an action that updates the infrastructure.

Both application and infrastructure code require state management. Application code often involves database migrations, where the current state is known and migrations are applied directly. In contrast, infrastructure can drift over time, requiring tools to read the existing state and apply only the necessary changes. Managing this state is crucial; for example, you wouldn't redeploy an entire domain each time-some elements, like DNS records, must remain consistent to avoid breaking the system.

I like to think of IaC as building with Legos: components such as networking, load balancers, instances, databases, and caches are assembled into an application, which is then placed into an environment like staging or production. Some resources, like DNS records or mail settings, exist outside these environments to keep them in a global environment and reduce blast radius if something fails. This separation ensures that a failure in one environment doesn't affect an entire company. Finally, a bootstrap or management environment provides out‑of‑band control for emergency recovery, enforcing the principle of least privilege.

This high‑level view covers the initial deployment cycle; ongoing operation, monitoring, and maintenance are separate concerns. Ideally, I would like to see IaC repos that could be treated like a pipeline, allowing continuous deployment despite the need to read existing state rather than simply overwriting it, but then I am not an expert into the internals of these systems and have no desire to be an expert at this stage in my career. However the above concepts allows me to from zero to deployed with Pulumi code (having never used it before) in a matter of days rather than weeks.

18 Feb 2026 6:00am GMT

In the AI age the importance of readable APIs goes up, as this can mean the difference between not reading the code because it's too much, and easily reading it to verify it is correct because it's tiny. It's been pretty clear that one of the superpowers of AI development is that it happily deals with enormous amounts of boilerplate and workarounds in a way that would drive a human insane. But we need to be careful of this, and notice that this is what is happening.

High level APIs with steep learning curves (like iommi) are now just as easy to use as simpler APIs, since the cost of initial learning is moved from the human to the AI. Since we also invested heavily in great error messages and validating as much as possible up front, the feedback to the AI models is great. We've been banging the drum of "no silent fixes!" for a decade, and nothing kills human or AI productivity as silent failures.

This is the time to focus our attention as humans to making APIs that are succinct and clear. It was vital before, but it's growing in importance for every day.

16 Feb 2026 6:00am GMT

In the AI age the importance of readable APIs goes up, as this can mean the difference between not reading the code because it's too much, and easily reading it to verify it is correct because it's tiny. It's been pretty clear that one of the superpowers of AI development is that it happily deals with enormous amounts of boilerplate and workarounds in a way that would drive a human insane. But we need to be careful of this, and notice that this is what is happening.

High level APIs with steep learning curves (like iommi) are now just as easy to use as simpler APIs, since the cost of initial learning is moved from the human to the AI. Since we also invested heavily in great error messages and validating as much as possible up front, the feedback to the AI models is great. We've been banging the drum of "no silent fixes!" for a decade, and nothing kills human or AI productivity as silent failures.

This is the time to focus our attention as humans to making APIs that are succinct and clear. It was vital before, but it's growing in importance for every day.

16 Feb 2026 6:00am GMT