Focus on concert hall, instead of the podium
Everyone wants beautiful music. And a lot of software developers have started fancying themselves as the conductor. We see ourselves the one directing the AI agents orchestra, staying in control at the podium. It's become the default metaphor for AI-era work. Whether it's prompting or agent loops, it's engineers holding the baton, but should they be?
TL;DR: The "AI Conductor" framing quietly re-installs the old gatekeeper pattern developers spent a decade trying to escape. This post argues the better model is to focus on concert hall, the structure that helps ANYONE sound good. Platform engineering and DevOps have already proved this works. Now it's developers' turn.
A conductor is still a gatekeeper
"AI won't take your job, but someone using AI will." — economist Richard Baldwin, World Economic Forum, 2023
For some reason, I always assumed that "someone" would be another developer, or someone with adjacent skills to the person being replaced. I don't think that anymore.
Developers have spent years as the multiplicative gatekeeper for the business. The ones who turn an idea into a technical implementation, that has huge impact on the business. I hadn't really stopped to consider that the gatekeeping itself is our biggest opportunity if we embrace our new role, and our biggest risk if we don't.
"Excel is your biggest competitor."
Why? Because it's a tool people with the problem know how to use to solve the problem themselves. No gatekeeping. Now, they have AI. AI can generate solutions for them, from websites to CRUD apps to iOS apps and beyond. All without you in the way.
"AI Conductor" could sound like evolution for software development. But, we should be passing the baton, not holding onto it. Positioning engineers as the one standing between the idea and the outcome is still the bottleneck, just wearing a nicer metaphor.
It's also not new
Our sysadmin friends already went through this. From platformengineering.org's history of the field:
In the late 90s and early 2000s, most setups had a single gatekeeper (and point of failure): the SysAdmin. If developers wanted to get anything done to run their applications, they had to go through them. In practice, this translated to the well-known "throw it over the fence" workflow — which led to poor experiences on both sides of the fence.
Sound familiar? Except now it's developers, instead of SysAdmins. How many sysadmins do you know who are still hand-installing OSs onto freshly unpacked servers on premise?
Yeah, me too. Whereas a skilled DevOps engineer can provide serious leverage where before there was a bottleneck, running tens, hundreds, thousands, or more servers, CI/CD pipelines, monitoring, and more! The best ones do it without breaking a sweat, while making it easy for developers to do the same, safely.
Build the hall, forget about the podium
That's the metaphor I'm swapping in: the concert hall, not the conductor.
A hall's acoustics, structure, setup are what help the performers sound good, and the orchestra sound AMAZING. But you don't see the architect standing on stage taking a bow. People rarely think about the engineering that makes a great (or small) hall work. That's the point. It can be invisible, and yet a critical component for lifting the performance to greatness.
Platform engineering already lives this distinction, and it gives us the playbook:
- Paved roads / golden paths — automated, secure default paths that let people move fast without becoming infrastructure experts.
- Governance built into the path itself — not enforced as a gate at the end, where it just slows everyone down and gets worked around anyway.
- Built for your scale and constraints — not every solution needs auto scaling, geo caching, or can afford a runaway AWS bill. Constraints can be freeing.
Developers should think like platform teams, building the development engine for product, design, support, CEOs, and founders. AI (not engineers) is the development team for a lot of these people now. Our job isn't to conduct their orchestra for them. It's to build the hall so well that they don't need us to.
*(yeah ok, I know nothing about concert halls and acoustics, but you get the idea)
Qualitative controls and avoiding slop
Platform and DevOps engineering's guardrails have traditionally been deterministic: Terraform plans, policy-as-code, static checks that either pass or fail, with a human expert reviewing on top.
We extend that same discipline to AI agents, like we did for developers before them, by building deterministic guardrails for probabilistic systems. But it's hard to statically verify that an LLM did what you wanted. The code can be linted, tested, and still do the wrong thing.
That's the engineering challenge, and it's not solved yet. Deterministic-grade guardrails for agentic AI exist today, just as scaled human teams needed them before, I consider them to mandatory for AI development. They are necessary but not sufficient. We have early patterns (ADRs, linting, type checking, automatic code reviews, sampling audits, scoped permissions, human-in-the-loop checkpoints) but not a fully finished paved road yet.
Even still, a good harness goes a LONG way.
I've said it before
and
I just hadn't realized at the time that the team and guardrails I was talking about building were for others, not ourselves.
So, stop asking "how do I get better at directing the AI" and start asking "what would make this safe and easy for someone who isn't me." That second question is the one that builds the hall.
Pick one workflow this week where a non-developer on your team wants to use AI, and instead of doing it for them, build the paved road that lets them do it themselves.
