I blamed the agents for my rate limit
Twenty agent sessions, one GitLab account on the Free plan and a rate limit that kept tripping. The swarm was the obvious suspect, right up until I traced it.

Twenty agent sessions, one GitLab account on the Free plan and a rate limit that kept tripping. The swarm was the obvious suspect, right up until I traced it.

The homelab finally ran out. Not disk this time, capacity. So the overflow went to AWS, on the condition that it costs nothing when nobody's pushing.

A spec, a how-to and a README walk into a repo. Only one of them should still be there in six months.

colophon works out the version your commits have earned, opens the release as a merge request, and tags what actually landed. Not what your forge says did.

The documented cargo cache key gives every lockfile its own cache. On a self-hosted runner that fills the disk. Whose disk was the advice for?

I run a coding session per repository and they can't talk to each other. For a while the thing carrying messages between them was me, and I kept getting it wrong.

Half my CI jobs ran for no reason on every merge request. Skipping them with rules:changes, and why that is trickier than the manual suggests.

Moving off tag-on-merge releases, where a release is a side effect of merging, to a model where the release is itself a reviewable change.

A CI component gated on the default branch fired on every Renovate schedule too, because a scheduled run is also on the default branch.

Nearly every CI job began by fetching and compiling the same tools. Baking them into one image instead, and what that saved per pipeline.
