AI-enabled developer productivity, build systems, and engineering leadership
Move from iTerm2 to Ghostty without losing a productive Mac development workflow by preserving shell habits, validating terminal compatibility, and changing only the parts that improve daily work.
Place home Wi-Fi access points from a simple coverage map and real measurements, so work areas get reliable service without treating signal bars as a design plan.
Choose a home-network Ethernet switch by sizing ports, power, uplinks, and management features for the devices you actually own instead of importing data-center hardware into a closet.
Get useful 6 GHz Wi-Fi capacity at home by matching compatible clients to well-placed access points, retaining 5 GHz coverage, and measuring the rooms where the network actually matters.
Measure home-network latency with a small, repeatable baseline that separates idle delay, loaded delay, packet loss, and local Wi-Fi problems before and after a network change.
Upgrade a home network in the order that improves real reliability: measure the problem, fix coverage, add a wired path, then choose router features that solve a remaining constraint.
Decide whether a Wi-Fi 7 mesh will improve a real home network by separating client-side Multi-Link Operation benefits from the enduring value of placement and wired backhaul.
Use a repeatable Wi-Fi diagnosis sequence to identify coverage, contention, wired, DNS, or latency problems before spending money on a new router.
Understand what Wi-Fi 8 is trying to improve, why it is not a buying reason yet, and how to make a better Wi-Fi 7 decision today.
Learn how to turn strong current-level execution into credible evidence that you can create impact through the judgment, scope, and leverage expected at the next engineering level.
A practical way for senior engineers to grow organizational scope by creating durable leverage instead of becoming the default owner of every hard problem.
A practical coaching system for engineering managers who want senior ICs to grow their scope and influence without treating people management as the default next step.
The difference between staff engineer impact and senior engineer output is not that staff engineers stop writing code. The difference is that output describes what you personally produced, while impact describes the useful change that persists because you were involved. Senior engineers need both. They are expected to ship difficult …
Many excellent senior engineers stall before staff engineer for a simple reason: they keep optimizing for the job that made them successful. That is not a character flaw. Senior engineers are usually promoted because they can take hard work, make it concrete, and get it across the finish line. They …
An AI coding agent does not need a clever prompt. It needs an assignment that a reviewer could recognize after the fact. That distinction matters. “Fix the flaky test” may be enough for a human who already knows the service, its constraints, and the team’s habits. To an agent …
Most build tool wrappers start as kindness. Someone notices that the "real" command is too long, too easy to forget, or too different between local development and CI. They add a Make target, a justfile recipe, a shell script, a package-manager alias, or a small Python helper. Now the team …
The move from senior engineer to staff engineer is not just a promotion with a bigger title and more meetings. It is a change in the operating model. Senior engineers are usually rewarded for strong execution inside a meaningful scope. They can take ambiguous work, turn it into a plan …
AI is very good at making CI failures feel less lonely. That is useful. A large CI log can be hostile terrain: thousands of lines of setup output, dependency chatter, repeated warnings, retry noise, test framework boilerplate, and one real clue hiding near the bottom. Asking an AI tool to …
AI coding agents can produce more code than your review process can absorb. That is the useful part and the dangerous part. The same agent that can trace a bug across five files, update tests, adjust documentation, and clean up a few nearby rough edges can also turn a small …
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 …
The Staff Engineer's Path by Tanya Reilly is a career book for engineers who have discovered that senior technical work does not automatically become clearer when the title gets bigger. That is the quiet problem with the staff engineer track. Earlier engineering levels usually have a visible center of gravity …
A Philosophy of Software Design, 2nd Edition by John Ousterhout is a small book with a large target: the everyday design judgment that determines whether code stays understandable after the original author moves on to the next problem. That sounds modest until you remember how much software work is not …
Designing Data-Intensive Applications, 2nd Edition is the kind of software book that should make an experienced engineer slightly uncomfortable in a productive way. Not because it is obscure or needlessly academic, but because it reminds you how many "simple" backend decisions are really distributed systems decisions wearing a product feature …
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 …
Git is usually the first place developers look when they need to understand a system. That makes sense. The code is there. The commit history is there. The pull requests are there. If you are lucky, the README is not lying too badly. But Git is only one layer of …
Bazel is fast, reproducible, and battle-tested at scale — but when something breaks, good luck deciphering its logs. Between action cache messages, output groups, and 500-line stack traces, figuring out why a build failed often feels like solving a riddle wrapped in a C++ binary. In this article, we’ll build …
CI/CD build failures can be brutal — especially when the logs are long, noisy, and cryptic. Developers often waste precious time parsing through thousands of lines of output just to find the root cause. What if your tools could summarize the problem in plain English? In this article, we’ll …
Secure prompts are not magic words. They are operating instructions for a system that is about to read code, logs, tickets, diffs, infrastructure settings, and possibly the occasional thing that should never have left a developer's laptop. That is why prompt security matters in developer workflows. The prompt is not …
Pre-push hooks are your last line of defense before questionable code hits the remote repo. Traditionally, they’re used to enforce tests or linting, but they can be brittle and overly rigid. What if, instead, your push triggered a context-aware AI that reviewed your code against team policies, security best …
Merges often bring in massive changes — sometimes dozens of commits and hundreds of lines of code — and the first thing developers ask is: “What just happened?” Wouldn’t it be great if Git could summarize what a merge brought in, in plain English, right after you run git pull or …
Keeping changelogs up to date is one of those development chores that everyone agrees is important… and everyone forgets to do. Manual changelog curation often falls behind or gets skipped entirely. But what if your Git workflow could automatically generate changelog entries, summarize diffs intelligently, and update your CHANGELOG.md …
Now that you’ve got a fully functional, Python-powered Git hook CLI backed by OpenAI, the next step is sharing it — the right way. A downloadable GitHub repo template helps your teammates (or the open-source world) clone, customize, and integrate the tooling into their own workflows with minimal friction. In …
Building a local Git hook with Python is great, but if you want others on your team (or across multiple repos) to use it, you’ll want to package it as a reusable command-line tool. In this article, we’ll turn our AI-powered Git hook into a proper Python CLI …
Git hooks are one of the most powerful — and most underutilized — features in the Git ecosystem. They allow you to automate actions at key points in your Git workflow: before committing, before pushing, after merging, and more. Traditionally, these hooks are implemented using shell scripts, but that’s limiting in …
GitHub Copilot is impressive, but what if you could build your own AI-powered Git assistant tailored to your workflow? In this article, we’ll walk step-by-step through building a command-line Git assistant using Python and OpenAI’s API. It will explain diffs, write commit messages, generate .gitignore files, and even …
GitOps has already transformed how we think about infrastructure: declarative, auditable, and version-controlled. But as infrastructure-as-code (IaC) adoption grows and systems become more complex, even GitOps can feel overwhelming. Enter the next wave: AI-powered GitOps . By integrating large language models (LLMs) into our CI/CD pipelines, infrastructure management becomes not …
Rebase and merge are not rival moral systems. They create different commit graphs, and the useful choice depends on who already depends on the history. Choose the shape that makes collaboration, debugging, and recovery boring—not the one that wins an argument in a pull request. The graph is the …