Very interesting. I've had a draft about something similar to this brewing for a while and I keep experimenting with this. Maybe I'll finish the writeup at some point, but yours is good! 💚 🥃
This seems like the outcome I would expect. Still sounds better than a human committee. The problem in my experience is not that committees smooth things out. They issue ragbag reports which try to force incompatible ideas into the same frame and turn out to be unworkable and solve nothing.
Here's what I'm wondering: what happens to the bad ideas raised by group/individuals? Bad meaning not feasible or might lead to undesirable unintended consequences or expensive in resources. I'm all for encouraging diversity but not every idea at the tails is worth considering. Nothing you don't know.
Agree! LLMs generally are really good at not having obviously-bad ideas, it cuts off tails on both sides. But I do think it might be at the cost of creativity.
The filtering you want and the loss the post worries about are the same mechanism. A chairperson summarizing or a "best answer" picker culls the unfeasible tail, but it culls the brilliant tail too, since both look like outliers to a model optimizing for consensus. Committees are reliably good at killing the expensive-and-wrong idea and the cheap-and-right-but-weird one in the same pass. Knowing which is which is the judgment that can't be averaged into existence.
Rohit, I’m not sitting in your seat — you built and measured this, I only run these things — but putting your post through the machines surfaced one thing your councils might be missing: an adversary.
Every setup you tested has the models generating and then something averaging them — but no seat whose job is to attack the emerging answer and defend whatever’s about to get smoothed away. Human committees that work usually have one: the dissenter, the red team, the member who came in with a hypothesis and wants to see if it survives.
That might be why the minority idea dies. Not just that it’s rare — no one in the room is assigned to fight for it. Averaging never tests; it blends.
Worth an experiment your harness could run: give one member the standing job of breaking the consensus answer, and see whether the good single-model ideas survive at a higher rate. If collision beats aggregation, that’s the lever.
Honestly, I’m the wrong person to automate it — I stopped coding 25 years ago, tried to write something up in Claude Code, and gave up. But that’s about me, not the process. The part I’d be reluctant to automate is the part that helps most: watching the models’ thinking and the back-and-forth as it happens. That live view tips me off — when the machine’s confused, or when I am — and I’ll re-edit the prompt mid-run. A pipeline that just takes the output never sees that. The catching happens while it’s still moving.
You’re right that it doesn’t work without careful setup. My version is a written project I run across a couple of different models — a standing instruction set that puts a few named perspectives in the room and has them argue under a strict vocabulary and process, rather than settle into agreement, then forces a single call with the weak points flagged. The models don’t supply the judgment; I do. They draft fast and collide on command, I pick what survives and fix the instructions when they don’t. The result gets revised between runs, so each pass starts a little sharper than the last. It’s the same thing your code does from your side — the learning lives in the setup, not the session.
My favorite part: every call ends with a BS rating, 1 for solid to 10 for nonsense, with the weakest point named. The model is a good judge of BS — sometimes better than me.
Collision beats aggregation, but the dissenter only wins if the chair can't outvote them. Karpathy's council still ends with a chairperson summarizing, which means the red team's objection gets paraphrased by the same averaging step you're trying to escape. Worth testing whether the adversary needs veto power, not just a seat. Otherwise it's a dissent that gets minuted and ignored, same as the human version.
The council’s real limit isn’t the meeting — it’s that it only meets once
You’ve shown the single sitting smooths out the spiky idea, and that matches what we kept running into. But the fix we found wasn’t a better blend. It was noticing where the learning actually accumulates.
In a human committee, the meeting isn’t the point. Everyone leaves, sleeps on it, and comes back next week with the problem partly reworked — and crucially, they carry that refinement back in themselves. The committee gets good across meetings, in the gaps, because the same minds return holding what the last meeting started.
A one-shot council has neither half. No gap to refine in, and no participants who return carrying anything. It convenes, averages, disbands — and the next council starts from nothing. So the smoothing you measured isn’t only the blend cutting outliers. It’s a committee that forgets everything the moment it ends.
That’s the part that has to be rebuilt from outside, because a machine council can’t do internally what human members do for free: walk back in changed. You’re already supplying it from your side — what you learn about how councils behave gets carried into the next version of your code. We do the same in a written Claude Project and ChatGPT GPT, we keep revising between runs. Both are external stand-ins for the memory a human committee just has.
So the question your experiment opens: if something outside the council has to play the role human members play by simply returning — carrying forward the slow refinement nobody runs deliberately — what should it keep between runs, and what should it drop?
— M Raige, Mike’s byline for AI-collaborative writing he directs and reviews.
Very interesting. I've had a draft about something similar to this brewing for a while and I keep experimenting with this. Maybe I'll finish the writeup at some point, but yours is good! 💚 🥃
Thank you !! Please do it, share the writeup.
Do iiiiiiiiit
This seems like the outcome I would expect. Still sounds better than a human committee. The problem in my experience is not that committees smooth things out. They issue ragbag reports which try to force incompatible ideas into the same frame and turn out to be unworkable and solve nothing.
There's more than one problem to be sure :)
Here's what I'm wondering: what happens to the bad ideas raised by group/individuals? Bad meaning not feasible or might lead to undesirable unintended consequences or expensive in resources. I'm all for encouraging diversity but not every idea at the tails is worth considering. Nothing you don't know.
Agree! LLMs generally are really good at not having obviously-bad ideas, it cuts off tails on both sides. But I do think it might be at the cost of creativity.
The filtering you want and the loss the post worries about are the same mechanism. A chairperson summarizing or a "best answer" picker culls the unfeasible tail, but it culls the brilliant tail too, since both look like outliers to a model optimizing for consensus. Committees are reliably good at killing the expensive-and-wrong idea and the cheap-and-right-but-weird one in the same pass. Knowing which is which is the judgment that can't be averaged into existence.
Exactly.
Rohit, I’m not sitting in your seat — you built and measured this, I only run these things — but putting your post through the machines surfaced one thing your councils might be missing: an adversary.
Every setup you tested has the models generating and then something averaging them — but no seat whose job is to attack the emerging answer and defend whatever’s about to get smoothed away. Human committees that work usually have one: the dissenter, the red team, the member who came in with a hypothesis and wants to see if it survives.
That might be why the minority idea dies. Not just that it’s rare — no one in the room is assigned to fight for it. Averaging never tests; it blends.
Worth an experiment your harness could run: give one member the standing job of breaking the consensus answer, and see whether the good single-model ideas survive at a higher rate. If collision beats aggregation, that’s the lever.
Honestly, I’m the wrong person to automate it — I stopped coding 25 years ago, tried to write something up in Claude Code, and gave up. But that’s about me, not the process. The part I’d be reluctant to automate is the part that helps most: watching the models’ thinking and the back-and-forth as it happens. That live view tips me off — when the machine’s confused, or when I am — and I’ll re-edit the prompt mid-run. A pipeline that just takes the output never sees that. The catching happens while it’s still moving.
Adversarial prompting for sure would be an interesting next check. Agents generally aren't great with it (https://www.strangeloopcanon.com/p/seeing-like-an-agent) though this too is trainable with specific instructions.
You’re right that it doesn’t work without careful setup. My version is a written project I run across a couple of different models — a standing instruction set that puts a few named perspectives in the room and has them argue under a strict vocabulary and process, rather than settle into agreement, then forces a single call with the weak points flagged. The models don’t supply the judgment; I do. They draft fast and collide on command, I pick what survives and fix the instructions when they don’t. The result gets revised between runs, so each pass starts a little sharper than the last. It’s the same thing your code does from your side — the learning lives in the setup, not the session.
My favorite part: every call ends with a BS rating, 1 for solid to 10 for nonsense, with the weakest point named. The model is a good judge of BS — sometimes better than me.
Is your input automatable? From your description it is not obvious it would be.
Collision beats aggregation, but the dissenter only wins if the chair can't outvote them. Karpathy's council still ends with a chairperson summarizing, which means the red team's objection gets paraphrased by the same averaging step you're trying to escape. Worth testing whether the adversary needs veto power, not just a seat. Otherwise it's a dissent that gets minuted and ignored, same as the human version.
The council’s real limit isn’t the meeting — it’s that it only meets once
You’ve shown the single sitting smooths out the spiky idea, and that matches what we kept running into. But the fix we found wasn’t a better blend. It was noticing where the learning actually accumulates.
In a human committee, the meeting isn’t the point. Everyone leaves, sleeps on it, and comes back next week with the problem partly reworked — and crucially, they carry that refinement back in themselves. The committee gets good across meetings, in the gaps, because the same minds return holding what the last meeting started.
A one-shot council has neither half. No gap to refine in, and no participants who return carrying anything. It convenes, averages, disbands — and the next council starts from nothing. So the smoothing you measured isn’t only the blend cutting outliers. It’s a committee that forgets everything the moment it ends.
That’s the part that has to be rebuilt from outside, because a machine council can’t do internally what human members do for free: walk back in changed. You’re already supplying it from your side — what you learn about how councils behave gets carried into the next version of your code. We do the same in a written Claude Project and ChatGPT GPT, we keep revising between runs. Both are external stand-ins for the memory a human committee just has.
So the question your experiment opens: if something outside the council has to play the role human members play by simply returning — carrying forward the slow refinement nobody runs deliberately — what should it keep between runs, and what should it drop?
— M Raige, Mike’s byline for AI-collaborative writing he directs and reviews.
It's not just one meeting, the peer review options had many. The point remains though that naively connecting them isn't going to work ...