Adding a tool to the stack used to be slow. Someone read the docs, ran a proof of concept, argued for it in a meeting, and spent a sprint wiring it in. That friction was annoying, but it also made teams ask whether they needed the thing at all.

AI removed most of it. In an afternoon you can have a new deploy script, a log parser, a small internal CLI or a dashboard service, written for you and often working on the first try. Installing an off-the-shelf tool is faster too, since the AI writes the config and the glue.

I think the old advice about tool sprawl matters more now, not less. AI made tools cheap to build. It didn’t make them cheap to own, and owning is where the cost always was.

The cost of a tool

The license or hosting bill is the visible part. The rest is what the team now has to know: one more config format, CLI, auth setup, set of failure modes and upgrade path. Then the links between tools, which hold until a token expires or an upgrade changes an API, and then fail somewhere else, as a message that never arrives. Upgrades cascade through those links, so teams put them off and end up a few major versions behind on everything. And knowledge spreads thin: one person knows the infrastructure code, another the cluster, another the secrets setup, and when one of them leaves, part of the system becomes something nobody understands.

None of this changes when the tool was generated instead of installed. A script the AI wrote still has to be read, maintained, upgraded and debugged at 3 AM. It just comes without docs, a community or a changelog.

Scripts nobody read

The upside is real. A lot of shared tooling exists because writing your own used to be expensive. Now a project can carry a short script that does exactly what it needs, versioned with the code, readable by anyone who opens the repo, and deleted when it’s no longer useful. That can replace a platform service, a plugin or a framework the whole team had to learn for one feature.

The risk is that the same ease turns collecting into generating. Each project grows its own deploy script, its own wrapper around the cloud CLI, its own small dashboard. Nobody wrote them in the usual sense, so nobody fully read them. The person who asked for one moves on, and now there are five slightly different versions of the same idea and no owner for any of them.

The 2025 DORA report calls AI an amplifier: it “magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” Tooling works the same way. A team in the habit of asking “do we need this?” gets small, local scripts that replace heavier tools. A team without that habit gets more tools, faster.

Three habits

Prefer small and local. A script in the repo that does one job is easier to understand than a shared service with its own UI, and much easier to delete. AI makes this option cheap, so use it. Once three projects copy the same script, though, it has become a tool, and it needs an owner and one home.

Someone has read it. Every tool needs a person who can explain how it works and fix it when it breaks. That was always true. What’s new is how easy it is to skip: with generated code, someone has to have actually read it, not only run it and watched the tests pass. If nobody will, don’t add it.

Pick the boring one. Dan McKinley made the case in Choose Boring Technology: a team gets a few innovation tokens, and the known failure modes of an old tool are worth more than the features of a new one. Postgres is boring. Kubernetes and Prometheus are getting there. Boring means documented, widely understood, and well known to the AI you’re using, so it gets the config right more often too. A newer, clever tool has to be clearly better to justify being the one thing on the team nobody else can debug.

A forty-line script

Suppose deploys have started failing a few times a week and nobody can tell why.

The reflex is to add a tool: a deployment analytics product, or a service the AI writes over a weekend that pulls CI events into a database with a dashboard on top. Either one looks great in the demo. Six months later it’s one more system to keep running, the dashboard has drifted from the pipeline it watches, and when deploys fail again people go back to reading the CI logs.

The other answer starts with the logs you already have. Ask the AI for a short script, kept in the repo, that reads the last month of failed CI runs and groups them by error. Someone reads it, runs it, and finds that most failures come from one flaky test and one registry timeout. Fix those two, then keep the script for next time or delete it. No new system, nothing new to upgrade, and anyone on the team can read the forty lines it took.

The cost of saying no

Saying no has a cost. Boring tools have fewer features, and some new tools really are better. A small script won’t do everything a product does, and a team that turns down every new tool will miss some that matter. From the outside, it can also look like you’re not keeping up.

What you get is a system the whole team understands. New engineers can debug the whole thing sooner, incidents don’t wait for the one person who knows a tool, and upgrades stay small enough to actually do.

Takeaways

  • AI made tools cheap to build, not cheap to own. Learning, integrating, upgrading and debugging cost what they always did.
  • A script nobody has read is a tool nobody owns. Generated code counts.
  • Small scripts in the repo can now replace heavy shared tools. Use that, and delete what you no longer need.
  • Boring tools are understood by everyone, including the AI.

I’d rather have half the tools and twice the understanding. AI can help you get there, if you use it to remove tools as well as add them.