rban.devFull-stack engineer

The best internal tools remove repeated thinking, not just repeated clicks

Apr 27, 20266 min readBy Rahul Ban

I read the Model Context Protocol spec last week and what surprised me wasn't the protocol itself. It was how clearly it removes the "how do I connect this" question from every new AI feature I build. That's the difference between automation and actual cognitive compression.

Most tools we celebrate as productivity boosters just move work around. They turn three clicks into one, or five commands into a single script. That's useful, but it's not transformative. The real leverage comes when a tool eliminates an entire class of decisions you used to have to make repeatedly.

When I look at our own internal tooling, I measure it by a simple question: what "what if" questions does this make obsolete? If the answer is "none," I'm probably just building another script that future me will have to maintain.

The Real Problem

The GitHub Copilot plan changes from last month are a useful trigger here, not because of the pricing itself, but because they forced a conversation about value. What are we actually paying for? Clicks saved, or decisions removed?

I've seen teams build internal CLIs that require more YAML than a Kubernetes cluster and more mental gymnastics than a Rubik's cube. The config file has nested conditionals, environment-specific overrides, and tribal knowledge flags that only three people understand. That's not compression—that's just deferred complexity.

The real cost of tooling isn't the time it takes to run it. It's the mental cycles spent deciding whether to run it, how to configure it, and why it broke this time. Those cycles add up to a tax on every feature, every bug fix, every experiment.

Where Teams Usually Get It Wrong

The most common mistake is building tools for the demo, not for the daily grind. You ship something that works beautifully in a controlled environment, with perfect inputs and a clean state. Then real usage hits, and you're left with edge cases, error handling, and configuration drift.

Azure AI Foundry's documentation shows this pattern clearly. They standardize connection patterns, authentication flows, and error handling across dozens of services. The value isn't in any single feature—it's in the fact that you don't have to think about how to connect to each service anymore. The pattern is already decided.

But teams often do the opposite. They build a tool that solves today's problem perfectly, then layer on flags and configs for tomorrow's hypotheticals. Each flag seems reasonable in isolation. Together, they create a decision matrix that nobody fully understands.

I watched this happen with a deployment tool last year. It started with three environments: dev, staging, prod. Then someone added a "canary" flag. Then "region" overrides. Then "feature-specific" configs. Within six months, you needed a spreadsheet to figure out what combination of flags would actually deploy your code safely.

A Better Working Shape

The Model Context Protocol works because it standardizes one thing: how clients and servers exchange context. That's it. Everything else is implementation detail. When you adopt it, you remove the "should I use REST, WebSockets, or something custom?" question from every new integration.

This is what good tooling looks like. Narrow scope, strong opinions, clear boundaries. The GitHub releases page shows this in practice—incremental improvements that remove specific friction points without expanding the surface area of decisions.

I would rather have ten small tools that each eliminate one recurring question than one monolithic platform that claims to solve everything but actually just moves the questions around. The monolith always wins in the demo. The small tools win in the daily commit cycle.

The key is to resist the temptation to generalize too early. Build for the concrete case you have, not the abstract case you might have. If you need to generalize later, do it by removing code, not adding config. Each new configuration option is a tax on future developers, including future you.

What to Watch in Practice

When evaluating a new internal tool, I ask three questions:

First: what decision does this make obsolete? If the answer is "it depends," I keep walking. Good tools have a clear, single point of leverage.

Second: what happens when it breaks? Does it fail closed (safe but annoying) or fail open (dangerous but convenient)? I prefer the former, even if it means more manual work sometimes. Safety is a property of the system, not a feature of the tool.

Third: who maintains it? If the answer is "the team that built it," that's a red flag. Good internal tools have clear ownership that outlives the original builders. They become infrastructure, not pet projects.

The Azure AI Foundry docs emphasize this with their "responsible AI" checks. They don't just give you tools—they give you guardrails that remove the "should I run this?" question by making the safe path the default path.

In day-to-day work, this means fewer Slack threads asking "how do I do X?" and fewer bugs from people using tools in ways they weren't designed for. It means you can onboard new engineers faster because there are fewer hidden decision points.

The Part I Would Watch

The friction point I see most often is when tools start to accumulate "just one more flag" syndrome. That's usually where things get messy. You go from a tool that removes thinking to one that requires thinking about the tool itself.

I keep a simple heuristic: if I have to document a decision point in the tool's README, the tool has already failed. Good tools encode decisions in their structure, not their documentation.

The Model Context Protocol avoids this by having a minimal surface area. The spec is short enough to read in one sitting. The implementation choices are binary: you either follow the protocol or you don't. There's no "it depends" middle ground.

What I do not trust yet is any tool that promises to save you thinking time but requires a weekly meeting to discuss its configuration. That's not compression—that's just moving the meeting.

Closing Heuristics

When you're building or buying internal tools, measure them by what they remove, not what they add. A tool that saves you 10 clicks but adds 5 config options is a net loss. A tool that saves you 2 clicks but removes 3 recurring decisions is a net win.

I would rather ship less but ship tools that are boringly reliable. Boring tools are the ones that actually get used, because they don't require a mental cost-benefit analysis every time you touch them.

The best internal tools are like good API design: they make the right thing easy and the wrong thing impossible. They collapse decision spaces instead of expanding them. Everything else is just automation with extra steps.

If you're interested in this from a systems perspective, I wrote about how shipping less can be a systems decision, not just product restraint. The same logic applies here—sometimes the most productive thing you can do is remove a tool entirely, not improve it.

The goal isn't to build more tools. It's to build fewer tools that do more compression. Every decision you remove is a decision that can't be made wrong, and that's where the real leverage lives.

Resources Worth Reading