A curated collection of articles exploring this topic in depth.
Intentional Engineering in the Age of AI
Reflecting on why building a personal blog as a production-grade system matters in an era where AI makes it easy to skip the thinking process.
Software development is undergoing a shift in how systems are constructed. Large Language Models (LLMs) have lowered the barrier to generating code. It is now possible to describe a blog to an AI and receive a repository, deployment script, and components in seconds. This approach moves from intent to implementation, often bypassing the stage of technical understanding.
This convenience is tempting for a personal blog. However, spending time on Terraform modules or OIDC trust boundaries remains valuable even when hosted platforms or generated templates are readily available.
The trap of convenience
Hosted platforms and AI-generated setups are built for the average case. They prioritise speed to publish over long-term ownership. When you use them, you are inheriting a set of implicit trust boundaries and architectural decisions you didn't make and might not fully understand.
For a simple blog, this might seem like a reasonable trade-off, but "simple" is often a deceptive label. Even a static site must address several specific production concerns to be resilient:
- Identity and Access: Managing how CI/CD runners authenticate with cloud providers.
- Delivery: Content caching, invalidation, and global distribution.
- Security: Verifying that storage is genuinely private rather than merely hidden.
- Reproducibility: The ability to recreate the entire stack from scratch if a provider becomes unavailable.
When we skip the design of these elements, we aren’t just saving time; we are accepting whatever ownership emerges. In this blog, that trade-off is intentional and low-risk, but the principle applies to any system.
Security is about intent, not scale
While "production-grade" engineering is often associated with high-scale systems, it is better understood as a mindset where every component exists for a reason and every boundary is explicit.
In this system, I’ve implemented:
- OIDC-based deployment: No long-lived AWS keys, even for a "small" site.
- Origin Access Control (OAC): S3 buckets that are genuinely private, with access granted only to CloudFront.
- Content Validation: A CI pipeline that treats Markdown files with the same rigour as application code.
These measures serve as guardrails that allow me to focus on writing, supported by a system I can trust.
Systems as long-lived artefacts
This blog is intended to be a long-lived artefact. If I look at the underlying code and configuration in three years, I should be able to understand the why as much as the how.
Declarative infrastructure (Terraform) acts as executable documentation. It tells the story of the architecture. Automated tests for content ensure that the site doesn't suffer from "silent rot" as dependencies evolve.
In an age of LLM-generated boilerplate, these deliberate choices are what make a system resilient. While LLMs are excellent at generating code quickly, they are yet to be proven in providing context or maintaining a coherent architectural vision over years.
Writing as thinking
Building this way is slow engineering. It forces me to confront trade-offs. It makes me a better practitioner because it requires an end-to-end understanding of the primitives I’m using.
This series will break down the specific decisions behind this blog, not as a tutorial on "how to use Tool X", but as a study in how I designed this small system with production-level discipline.
In the next post, we’ll look at the architectural constraints of a statically exported blog and why picking the framework was the last decision I made, not the first.