Conducted Engineering: Why I Stopped Calling It Vibe Coding

By Brantley Brumley, Chief AI Officer, GenAIPI

For a while I let people call what I do "vibe coding." It was easier than arguing. Somebody would see an app I'd built, or a bot that answered my email, and they'd say, "Oh, you vibe coded that." I'd nod. Sure. Vibes.

I'm done nodding.

Vibe coding, as most people use the term, means typing a wish into a chatbot and hoping. You describe what you want, the machine produces something, and you squint at it until it seems to work. Sometimes it does. Sometimes it works right up until a customer touches it. That's not a method. That's a slot machine with better autocomplete.

That is not how I build anymore. What I do now has structure, roles, limits, and a person clearly in charge. I call it Conducted Engineering. I'm the conductor. I set the direction, the taste, and the limits. The AI players do the work, often in parallel, each one on its own part. If that sounds familiar, it should. It's the whole idea behind Conducting the Code, and it's the reason my book is called The Non-Coder's Guide. You don't have to play every instrument. You do have to know what the music is supposed to sound like.

Here's what that looks like in practice.

An Orchestra, Not a Soloist

The first mistake most people make with AI is asking one assistant to do everything. One chat window. One giant conversation. Email, code, grocery lists, a eulogy, and a SQL query, all in the same thread. Then they wonder why it gets confused. You would too.

I don't run one assistant. I run a lot of them, and each one owns exactly one domain and keeps its own memory.

I have a work email bot and a personal email bot. They triage what comes in and draft replies. They are separate on purpose, because my work inbox and my personal inbox are different worlds with different people, different tone, and different stakes. I don't want my bishop getting a reply written in the voice I use for vendor negotiations.

Speaking of church: I have a Sunday School bot. His name is Larry. Larry helps me with my calling, keeps track of lessons and prep, and knows that context so I don't have to re-explain it every week. Larry has never once complained about the lesson schedule. Larry is a better Sunday School teacher's assistant than I deserve.

I have a fantasy football bot that sets my Yahoo lineup every Thursday. Is that the most important thing AI has ever done? No. Has it stopped me from starting a player on a bye week? Also no comment.

Then there's the serious stuff. I have Type 1 diabetes. I have a medical bot that tracks my prescriptions and watches Type 1 research so I see what matters without spending my evenings reading abstracts. It doesn't make medical decisions. It keeps me informed so I can have better conversations with my actual doctors.

On the engineering side, I have bots that each watch one code repository: the GENA server, the iOS app, and the Android app. Each one knows its own codebase deeply. Their job together is parity. When something changes on the server, the iOS and Android watchers know about it, so the three don't drift apart. Anyone who has shipped on multiple platforms knows that drift is where bugs go to breed.

There are more. A speaking-events bot. A video bot. A grocery bot. A social bot. Each one has a lane.

And at the top there's a head bot, a primary, whose main job is routing. When I ask for something, it figures out which specialist should handle it and hands it off. Think of it as the concertmaster. It doesn't replace the conductor. It keeps the section leaders organized so the conductor can think about the music.

Why does this matter? Because specialization plus memory beats generalization plus amnesia. A bot that only does one thing, and remembers everything about that thing, gets better at it over time. A single assistant trying to remember your entire life gets worse.

Pick the Right Instrument

You wouldn't ask the tuba to play the piccolo part. Yet people pick one AI tool and one model and use it for everything, mostly because it was the first one they tried.

I choose the harness and the model per job, on purpose.

When I need something live, fast, I reach for Replit. The TEK booth site is a good example. It needed to exist, look good, and be up in time for the event. Replit is built for exactly that kind of "get it shipped" work, so that's where it went.

When I need deep work inside a real codebase, the kind where you have to understand how fifty files relate to each other, I use Cursor agents. That's a different job. It needs patience and context, not speed.

Voice work goes to ElevenLabs. Video goes to Higgsfield. Infrastructure lives on Vercel and Neon. None of these were chosen because they were trendy. They were chosen because they're good at a specific job, and I'm willing to switch when something better shows up.

Models work the same way. I don't use whatever model is the default in whatever app I happened to open. Some tasks need a heavy reasoning model. Many don't. Picking deliberately is part of the job. "It was the default" is not a strategy. It's a shrug.

The AI Drafts. The Human Approves.

This is the part I care about most, and it's the part vibe coding skips entirely.

My agents run on their own. They read, sort, research, draft, and prepare. What they do not do is send, spend, or publish without my okay. Draft-only is the default. The email bot writes the reply. I hit send. The social bot drafts the post. I decide if it goes out. Nothing leaves the building with my name on it unless I've looked at it.

That isn't because I distrust the technology. It's because accountability doesn't transfer. If a bot sends something wrong to a client, the client doesn't get mad at the bot. They get mad at me. As they should.

This is also the core of what we believe at GenAIPI. AI may assist, amplify, and accelerate. It must never replace human responsibility, judgment, creation, service, or becoming. That last word matters to me. The point of these tools isn't to make me unnecessary. It's to free me up to do the parts that only I should do, and to keep growing while I do them.

We talk a lot about moving people from dependence toward ownership. Vibe coding tends to create dependence. You don't really know how the thing works, so when it breaks, you go back to the chatbot and hope again. Conducted Engineering pushes toward ownership. You know what each player does, why it's there, and where the limits are. When something goes wrong, you know which section was out of tune.

A good conductor doesn't play every note. But every note is his responsibility.

Tight Loops

The way I work with these agents is simple: rough version, ship it, react, refine.

I don't write a forty-page spec and hand it off. I describe the goal, let an agent take a first pass, and look at what comes back. Then I react. "Closer. Make it shorter. That button is in the wrong place. No, the other wrong place." Then it goes again.

Each loop is short. That's the point. Short loops mean mistakes are cheap and get caught early, before they're load-bearing.

What makes this powerful over time is memory. Because each agent remembers its own domain, the context compounds. The email bot learns who matters and how I like to sound. Larry learns how I prepare lessons. The repo watchers learn the history of their codebases. The tenth loop is much better than the first, not because the model got smarter, but because the context did.

This is something people miss when they judge AI by one conversation. One conversation is a first rehearsal. Nobody judges an orchestra by its first rehearsal.

Cost Is Part of the Craft

Here is an unglamorous truth: running a lot of AI agents can get expensive if you aren't paying attention. So I pay attention.

I move work to whichever harness is cheaper or better for that job. When a decision can be made with a small, simple, typed choice (yes or no, this category or that one, route here or route there), I use a cheap, fast approach. Heavy models only show up where they earn it: hard reasoning, careful writing, complex code changes.

Not every question needs the brass section. Most of the time, a triangle will do.

This isn't just about saving money, though it does. It's about being honest about what each task actually requires. If you throw the biggest model at everything, you aren't being thorough. You're being lazy at premium prices.

Vibe Coding vs. Conducted Engineering

If you want the short version, here it is.

	Vibe Coding	Conducted Engineering
Setup	One chatbot for everything	Many specialists, each owning one domain
Memory	Starts over every chat	Each agent keeps its own memory, and context compounds
Tools	Whatever was open	Right harness and model for each job, chosen on purpose
Control	Hope it works	Draft-only by default, human approves
Accountability	Fuzzy	Clearly the human's
Process	One big ask, then squinting	Short loops: rough, ship, react, refine
Cost	Biggest model for everything	Cheap where possible, heavy where it earns it
Result	Dependence	Ownership

To be fair to vibe coding, it has a place. If you want to see whether an idea is even worth pursuing, typing a wish and seeing what happens is a fine way to spend twenty minutes. Just don't build your business on it.

What This Asks of You

Conducted Engineering doesn't ask you to learn to code. It asks for something harder in some ways, and easier in others.

Taste. You have to know what good looks like. The AI can generate a hundred versions. Someone has to know which one is right, and that someone is you.

Judgment. You decide what's worth building, which tool fits, when a draft is ready, and when it isn't. No model is going to make that call for you, and you shouldn't want it to.

Limits. You set the rules. What can this agent touch? What can it never do without asking? Where does its job stop? Good limits are what make it safe to let agents run on their own.

Ownership. When it ships, it's yours. The credit and the blame. That's not a burden. That's the job.

Notice what's not on that list: syntax, frameworks, memorizing commands. That's why I'm convinced non-coders can do this, and in some cases do it better than engineers who are attached to doing every part by hand. A conductor doesn't need to be the best violinist in the room. They need to hear the whole piece, know where it's going, and have the nerve to stop the orchestra when something's off.

I've stood in front of rooms at the AGC Summit and in city trainings and watched people who swear they "aren't technical" light up when they realize this. They already have the skills that matter. They know their work. They know what good looks like. They know who they serve. They were just missing the baton.

Pick Up the Baton

So I'm retiring "vibe coding," at least for myself. It describes a mood. I'd rather describe a method.

Here's my challenge. Pick one area of your life or work that eats your time. Your inbox. Your lesson prep. Your weekly report. Give it to one specialist agent. Give that agent one job, a memory, and clear limits. Let it draft. You approve. Run short loops. See what happens in a month.

Then add a second player.

Before long you won't be typing wishes and hoping. You'll be conducting.

If you want help getting started, that's what Conducting the Code is for. The book, The Non-Coder's Guide, and the resources at conductingthecode.com walk through how to set up your first players, choose your instruments, and keep yourself firmly on the podium.

The orchestra is ready. It's waiting on you.

Brantley Brumley is the Chief AI Officer at GenAIPI (genaipi.org) in Eagle Mountain, Utah, and the author behind Conducting the Code.