The Only Person on Stage Who Makes No Sound

We built Made In Tandem around one stubborn idea and held onto it for fifteen years. Then AI showed up, and for a while I was certain it had made that idea worthless. Boy did I have it backwards.

Feature image for The Only Person on Stage Who Makes No Sound

For about a year there I thought we were cooked.

Not the company, but certainly the idea. We started in 2011, in a cheap office in Wicker Park under a different name. (DevMynd, if you’re keeping score.) My pitch at the time was almost embarrassingly simple. The person who understands your problem should be the person who builds your solution. Senior engineers doing the actual work, not a partner who sells you a vision or an architecture in a slide-deck. The people in the room when we figured it out are the people who will ship the best solution.

For most of the last fifteen years this model has worked really well. It is, to be sure, a slower way to grow. You can’t pad the team with cheap bodies and bill them out at a markup. You can’t grow rapidly without watering down the exact thing that makes you good. But slower growth does allow you to be good consistently and over the long-haul. It has been worth it. We’ve had our side quests from time to time as all companies do but our core mission has remained the same.

Here’s the thing that spooked me: the models got good, then they quietly got scary good. The tools can scaffold a working feature in 45 minutes, do the research on the back-end architecture, write the tests, draft the docs, and find an unrelated bug along the way. I found myself doing the math nobody at a software company wants to do. If the code is suddenly close to free (free as in beer, not as in freedom), then what exactly are the humans for?

The market answered in typical mad rush fashion. Every consultancy on earth has bolted “We build AI stuff” onto their homepage in the last year or so, and the pitch underneath was both loud and mediocre: the work is cheap now, “get’cha software here, software, one dollar!” For a few months I honestly wondered whether the thing we’d spent fifteen years building had a very short shelf life and the date on the carton was coming due.

I was very happily wrong but it took me a while to see why. It’s the part worth slowing down for.

Everyone calls AI a force multiplier and that’s fine as a marketing term but how does that actually translate to the real world? Well, what does a multiplier do? It multiplies whatever is already there.

Put these tools in the hands of a seasoned and thoughtful engineer and what comes out is close to magic. Two decades of pattern recognition, scar tissue from systems borked at 3am, the gut sense for which corner can be cut without destroying someone’s weekend - all of that now moving at the speed of AI-generated code. Put the same tools in the hands of someone who doesn’t have that judgment and you don’t get a genius in a datacenter. You get a toddler running loose in the house with grown-up scissors: a mess, produced faster, debated more confidently, shipped at a speed so unheard of nobody notices it’s all wrong until way too late. The model will be spectacularly wrong at scale and cheerily smile at you and tell you you’re pretty while doing it.

So the cheap-and-fast era doesn’t actually work and it doesn’t devalue knowing what you’re doing. In fact it widens the gap between these scenarios and makes judgment, taste, and experience more essential than ever. That gap used to mean a few weeks of cleanup before launch. Now it’s measured in how much damage you can automate before the spec is even settled.

AI didn’t make our one stubborn idea obsolete. In fact I think it proved it. The thing that made us weird made us right: smart engineers, in the room from problem to solution to delivery, are the difference between software that works and software that just runs.

This all left us with a naming problem, and to solve it I went back to my roots. Before the company I spent years at a keyboard (the black-n-white kind), studying classical piano seriously enough to think it might be my whole life. Turns out it wasn’t, but it wired something into how I think. My teacher from age six to eighteen, Mrs. Keller, said something once while I was prepping for a competition with a full orchestra behind me. “The conductor does everything they’re gonna do before the players ever show up,” she told me. “You just bring the melody.” She was right and it still took me thirty years and a small existential crisis to really feel it.

When we sat down to rebuild the firm around judgment, we needed a name for the person who carries it. The senior engineer-architect who owns the whole engagement: the architecture, the client relationship, the AI agents doing the grunt work, the human engineers doing the deep build, and the final call on whether any of it is actually fit to ship.

We almost called them Orchestrators, which tested fine, but the musician in me bristled.

Orchestration is what the machines already do. It’s a software word - Kubernetes orchestrates containers, Airflow orchestrates pipelines, and the agent frameworks orchestrate their own conversations and tool calls. Orchestration is coordination: route this thing over here, sequence that thing there, fan out, collect, report, repeat. Machines are spectacular at this and they get better when exercised.

Conducting is something else.

During the performance, a conductor never plays a note. They’re the only one on stage making no sound at all. From the seats it looks like the easiest job in the building: wave a stick like a lunatic, look anguished and austere, and go nuts when the timpani come in. But that iceberg goes deep. The performance you’re watching is the smallest part of the conductor’s job because most of it already happened over weeks of rehearsal.

That’s where a conductor actually conducts - shaping how a hundred musicians think about a piece. What does this phrase mean? Is there a breath here? How loud is “loud” really? They run it back, yell and hash it out, build a shared reading of the thing until an interpretation lives inside the players themselves. On opening night the conductor’s vision is already loaded into a hundred pairs of hands. The baton is mostly a reminder of decisions everyone made together in an empty room.

Take the conductor away and a hundred world-class musicians play a very expensive sequence of correct notes with no point of view. And the better those musicians are, the more that silent, shaping role matters, not less. Hand a conductor a string section that can sight-read anything you put in front of it and the job stops being “can we hit the notes” and becomes “which reading, how fast, to what end.” The capability climbs straight up the stack, into taste and judgment, into the one job the machines can’t hold.

That’s the job now; we call them Conductors. Senior engineers who have the experience and intuition to guide a team (AI agents and human engineers together) to an outcome that’s more than the sum of the assembled parts.

This doesn’t just make the work faster; it makes the work better. For most of my career, judgment was rationed by physics. You could see the cleaner architecture, or a smarter abstraction that would settle an argument. Then you’d look at the deadlines and ship the first idea that made sense, because there were only so many hours. “Good enough” became a ceiling set by what you could afford to build, and now that ceiling has lifted.

The Conductor who used to get one swing at a design now gets five, and way more prototypes before we commit. More reviews, more gates, more “hold on, let’s validate that assumption before we pour concrete on it.” We can try many versions of a feature in the time the old way could only bring us one. The machine does the typing, and the human spends the reclaimed hours on the part that was always the hard point - deciding what’s worth typing at all and how to do it. Taste with the brakes off is a way different animal than taste stuck behind syntax and Google searches for “how do I do X in Y library.”

The same shift has played out in the room with our clients, and it’s running counter to what I had expected. The lazy version of an AI consultancy is obvious: collect the requirements, shovel them into a model, squint at the output, hand it back, invoice, repeat. We’ve never been that kind of company and we’re going in a different direction. The hours the machines give us back don’t vanish into margin; they go straight back across the table. More conversations, not fewer. More of the dumb-smart curiosity that surfaces the things nobody thought to put into the RFP. More time spent understanding the business and the people it serves, less time spent grinding out boilerplate. The grunt work isn’t just trivial now; in skilled hands it basically takes care of itself, which lets inquiry and insight grow to fill the space.

Which brings me to the thing underneath all of this, the belief that helped us walk out of this whole reckoning without a scratch:

We are people-first, and the deeper we go into these new AI tools, the more sure we are of it.

Software exists because people want things. Businesses run on human desire: somebody decided this market was worth chasing, this type of customer was worth keeping, this particular problem was worth a year of payroll and tears to solve. The model can write the code for any of that but it cannot want any of it. It has no skin, no stakes, no board meetings, no 3am worries about getting employees paid. It is the most capable instrument any of us has ever held, and it sits in dead silence until a human picks it up and decides what to play.

There’s a quieter reason to keep people in charge, too. With nothing on the line, a model has no particular reason to be honest with you. Ask it whether your plan is any good and it’ll tell you it’s brilliant, with the same easy confidence it used to tell you you were pretty. Someone with judgment and something to lose will tell you when you’re about to drive the whole thing off a cliff. Now that plausible, beautifully formatted nonsense is free and infinite, that kind of candor (what’s actually broken, what won’t survive first contact with production, what we’d flat refuse to build) has become the rarest and most valuable thing we sell.

The whole job of a Conductor is to hold a human intention, steady and clear, and carry it on purpose and in writing to a hundred tireless players who have none of their own. That’s the rehearsal, and it’s where the real work lives: the architecture, the specs, the examples, the gates, and the definition of “done” turned into evals and tests and security reviews, all of it set down before the system ever runs for real. By the time the thing goes live, the judgment is already baked in. Knowing when to put a human back in the loop is an integral part of the score too.

The site you’re reading this on is a new one. Fifteen years of work, rebuilt around the one idea that has survived everything we threw at it, including the tool I was sure would be the one to bury us.

The score is on the stand and the players are tuned up. We’re a small group of people who’ve been at this a long time, happiest on the hard, unglamorous problems that nobody else wants: the systems that won’t talk to each other, the data that’s nowhere near ready for the AI everyone keeps promising, and the spreadsheet that turned load-bearing years ago and now nobody dares touch.

Bring us the messy version. That’s where the real music starts.

-- JC Grubbs, Founder & Conductor

Need senior technical judgment, not another deck?

Bring us the system, workflow, data problem, or AI idea that keeps circling the drain. We will help you figure out what is worth building and how to get it into production.