slaptijack

Build failures become expensive when they stop being reproducible.

The first failure is usually just a problem. The third person saying "it only happens in CI" is when the problem starts turning into folklore. Someone reruns the job. Someone else clears a cache. A third person changes an unrelated file …

CI output is part of your developer experience.

That sounds obvious until you look at the average failed build. A pull request goes red, the developer opens the CI job, and the first thing they see is a scrollback landfill: dependency installation noise, folded shell wrappers, progress bars, warnings from …

AI coding agents are very good at refactors until they are not.

That is the uncomfortable part. The same agent that can rename a helper across a repository, split a giant function, update tests, and clean up repetitive call sites can also make one tiny semantic change that hides inside …

Remote cache misses are where build-system optimism goes to get humbled.

The sales pitch for remote caching is simple: someone already built the thing, so you should not have to build it again. In a healthy Bazel setup, that can be beautiful. CI writes reusable outputs. Developers pull the same …

Local CI commands should be boring.

That sounds like faint praise, but boring is exactly what you want from the command that tells a human developer, a coding agent, or a pull request bot whether the repository is healthy enough to trust.

The problem is that many repositories make this …

AI-written tests are dangerous in exactly the way good-looking tests are always dangerous: they can make you feel safer without actually reducing much risk.

That is not an argument against using AI coding agents to write tests. I use them for test scaffolding, edge-case enumeration, fixture cleanup, and regression coverage …

Remote build caching is worth it when the cache saves more engineering time than it costs in build discipline, infrastructure, debugging, and trust.

That sounds obvious, but it is the part teams skip. They see long CI times, slow local builds, and a build system with the word "remote" in …

AI-generated pull requests are not a new category of code. They are pull requests.

That sounds obvious, but it is the first thing teams forget when the novelty arrives. A pull request created with an AI coding agent still changes production systems, test behavior, user workflows, security posture, operational load …

Build tools are one of those engineering choices that look small until they are not small anymore.

At first, you just need a way to run tests. Then you add code generation. Then there is a Docker image. Then CI needs the same steps as laptops. Then one team needs …

AI coding agents are useful in the same way junior engineers, build scripts, and sharp shell aliases are useful: they can remove friction, accelerate boring work, and occasionally surprise you with a clever path through a problem. They are not a replacement for engineering judgment.

That distinction matters.

The strongest …

Bazel's old WORKSPACE model had a long run. It was powerful, familiar, and occasionally the place where every build-system shortcut in the company went to hide. But the center of gravity has moved. Bazel 8 disabled WORKSPACE by default, Bazel 9 removed support, and the modern dependency story is MODULE …

Bazel 9.1.0 is not the kind of release that should make an engineering team drop everything and schedule a build-system migration party. It is a minor LTS release in the Bazel 9 line, published on April 20, 2026, and most of the changes are incremental. That is good …

Bazel 8.0.0 was not just another build-tool release. It was the release where Bazel stopped politely suggesting that teams should modernize their dependency management and started making the new world harder to ignore.

The headline changes were Bzlmod becoming the default, WORKSPACE being disabled by default, and more …

Natural language developer queries sound like a toy until you watch someone spend ten minutes answering a question the platform already knows:

• "Who owns the checkout service?"
• "Where is the Terraform for staging Redis?"
• "What changed before the payments incident?"
• "Which services still point at the old Kafka cluster?"
• "Where …

Backstage is already where many platform teams want developers to go for service ownership, docs, APIs, runbooks, and operational metadata. The problem is that developers do not always want to navigate a portal. Sometimes they just want to ask a question:

• "Who owns checkout-service?"
• "Where is the runbook for restarting …