
Your newest sysadmin is an LLM
Luke Hefson
Recently, we wrote that Homebrew had stopped being an engineering-team problem. AI-assisted development had turned analysts, ops, and product managers into people who run brew install. That was based on our observations of the industry, and we stand by it, but in these rapidly evolving times, something else has changed: increasingly, the person running the command isn’t really a person anymore.
AI coding tools in 2026 don’t just generate code, they set up the machine to run it too. When Claude Code, Cursor, or Copilot needs Python, Redis, ffmpeg, or some random CLI utility to make a project work, it usually doesn’t send you to a download page. It just writes the command. More and more often, it now just runs the command too.
On macOS, that command is almost always brew install. The LLM has quietly become a kind of sysadmin for your fleet. Nobody planned for that, but here we are!
How this plays out for users
Someone in your fleet asks an AI assistant to build something small: a prototype, internal tool, script, dashboard, etc. The assistant writes the code, then realizes it needs software on the local machine to make the whole thing function.
Then, it starts emitting install commands.
If Homebrew isn’t installed on the device yet, it will give you the Homebrew install script. Then come the brew install lines, one after another. You copy-paste them or just hit ‘accept’, because that’s the fastest way to keep moving and productive. A lot of people don’t stop to inspect what they’re installing. The model already did the “thinking” part.
What each install drags in
Homebrew packages pull in dependencies, and those dependencies pull in more dependencies. Kris mapped the ecosystem and it gets deep fast. A single brew install node brings along 58 additional packages. He described this as a package's blast radius, which feels accurate once you start tracing the graph and realise a simple install can drag in tooling and licenses nobody on the team has even heard of.

Now throw an AI assistant into the mix.
An LLM trying to get a project working often doesn’t optimize for elegance or restraint. It optimizes for the path of least resistance to get the project running. If the first approach fails, it’ll grab another package. Then another one. Sometimes three competing approaches end up installed because the model iterated its way through the problem in real time.
So the question probably isn’t just whether AI increases the number of packages being installed. It probably does. The bigger question is whether AI massively expands the surface area underneath every install, especially in environments where nobody is reviewing these decisions closely because the whole workflow depends on speed.
You’re managing machines nobody fully configured
MDMs were built for a different world. They’re good at deploying managed apps, pushing configuration profiles, enforcing device settings. They were not really designed for a coding assistant pulling open source infrastructure onto a company laptop because a prototype needed to parse PDFs or transcode audio.
Taking Homebrew away entirely isn’t realistic either. In a lot of companies it would immediately break the exact AI-assisted workflows that are helping teams ship so much faster.
Workbrew sits alongside your existing MDM and handles the layer traditional tooling can’t really see:
- Observability — inventory every package and transitive dependency across the fleet, including the stuff installed indirectly through AI-assisted workflows.
- Control — manage updates, approvals, and team-level restrictions centrally without locking developers out of Homebrew entirely.
- Private taps — distribute internal tooling and binaries through the same workflow developers and AI tools already expect.
If you’re curious what your AI tools are actually pulling onto company laptops, get started with Workbrew, connect your MDM and take a look at the dependency graph you’re already running.