Earlier this year I blogged about My Claude Code Setup , describing my personal point of view on how I was using Claude Code at that point in time.
Seven months later, my workflow has changed enough to need a follow-up.
So here I want to walk through the main changes to my setup. Think of it as a diff against the previous post, which I’d recommend reading first if you haven’t already.
If your workloads run on Kubernetes, where should your security logs come from?
This post, part of the “Continuous Visibility into Ephemeral Cloud Environments” series, describes a design for a state of the art security logging platform for Kubernetes clusters. It completes the set started by the AWS and GCP posts, both of which promised “a follow-up post” on worker node and container logs. This is that post, a few years later than planned.
Earlier this week I read The AI-Native SDLC Playbook from Anthropic.
It should be mandated reading in Engineering orgs, and even more so for Security people, at every level of seniority.
Read the post. Take the time to think each concept through. I truly think we, as an industry, should have the courage to throw away the playbooks we’ve been working on for the past 20+ years and create new (and better) ones for the AI era.
If you followed the wave of supply-chain attacks from the first half of 2026, you’ve probably realised that continuously patching and upgrading your dependencies is no longer optional.
For me, Renovate handles the patching part well.
Most bumps are safe, but majors, 0.x jumps, dead dependencies, and quietly deprecated framework configs are hard to spot from a CI test.
Manually reviewing every PR with the same rigor also doesn’t scale, and is a waste of time, to be honest.
CloudSecList just shipped a redesigned landing page.
Claude Design did the mockups. Claude Code wrote most of the code for Jekyll. I did everything in between, which turned out to be most of the actual work.
