A few days ago I announced my talk at Devopsdays Prague. This is the story behind one of its slides.
Before there was an audit, a sandbox or a talk, there was one small script. In May 2025 I needed to know which of more than a hundred feature flags were still referenced anywhere in an organisation's code. Not in one repository. In all of them.
On Monday 5 October I am speaking at DevOpsDays Prague. The talk is called When Your Safety Net Becomes a Trap: Cleaning Up Feature Flag Debt.
Feature flags are one of the most useful tools in a modern DevOps toolkit — progressive rollouts, A/B tests, safer deployments. They also accumulate quietly, until a codebase is a maze of stale conditionals nobody dares delete.
Codex is most useful when it can connect—to your repo, your tools, and your deployment pipeline. This post is a quick guide to wiring those connections so Codex can move from “nice assistant” to “useful teammate.”
This blog post was created with decisive help of Codex, and Codex can be connected to an existing repository — creating a new one is not obligatory.
If you are using MkDocs inside GitHub Codespaces, you may notice that the usual:
mkdocs serve
does not rebuild your site when Markdown files change. The internal watcher seems broken in Codespaces, and no amount of --dirtyreload or watchdog tricks reliably triggers a rebuild.
Here’s a simple, working workaround I use:
Create a Makefile in the root of your repo: