Your CFO is asking the question more and more often: we're spending serious money on AI, so why aren't the results showing up?
It's a fair question. And the answer is probably not what you'd expect from someone who builds AI tooling for a living.
The problem isn't the models. It isn't the tooling. It isn't the developers. The problem is a question that almost nobody is asking.
When an organization decides to use AI to accelerate software development, the conversation usually goes like this: What can we automate? Where can AI write code faster than a human?
That's the wrong question. Or at least, it's the second question. The first question is this:
Where does this project actually require human judgement — and where can decisions be verified and therefore automated?
These are not the same thing. And conflating them is why so many AI initiatives produce a lot of activity and very little value.
AI agents are extraordinarily good at executing well-specified tasks. Given a clear spec, a defined scope, and unambiguous success criteria, they can work faster and more reliably than any human team. But they are not good at knowing whether the spec is right. They cannot tell you if you're solving the right problem. They have no way to sense that the architecture you've described sounds clever but won't survive contact with your actual users.
That's human judgement. And it cannot be automated, verified, or scaled away.
Here's what happens when you skip that question. Teams use AI to ship faster. They produce more output — more features, more code, more documentation, more specs. The throughput metrics look great. But the output doesn't move the needle on what actually matters, because nobody stopped to ask whether it should be built at all, or built that way.
You end up with a truckload of things that are technically correct and strategically wrong.
The CFO sees the invoices from the AI tools. They don't see the rework, the pivots, the features that shipped and got quietly deprecated three months later. They just know the return doesn't match the investment.
This isn't a technology problem. It's a workflow problem. Specifically, it's the problem of human judgement not being systematically collected at the right moment — before the AI agents get to work.
When people talk about the market for AI development tools, they usually mean productivity. Ship faster. Write less boilerplate. Close more tickets.
That's a real market. But it's not the most important one.
The more important market is this: organizations that want AI to work on the right things. Not just efficiently, but effectively. Teams that understand that the bottleneck isn't code generation speed — it's decision quality upstream of code generation.
That's a different product. It sits earlier in the workflow, before the agents start running. It's about making sure the spec is sound, the architecture holds up under scrutiny, and the approach makes sense to the humans who understand the context that the AI cannot access.
The name isn't a metaphor. Ritual Dissent is a real facilitation technique — developed by Andrew Cameron and Sonja Blignaut, and used in organizational change work for decades.
Here's how a live session works. Someone presents a plan or proposal to a group. Once they've finished, they turn their chair around — literally, physically — so their back is to the room. The group then spends several minutes articulating everything that could go wrong, every assumption that might be flawed, every concern they have. The presenter listens but cannot respond, cannot defend, cannot explain. They just take notes.
When the group finishes, the presenter turns back around. They've just received unfiltered critique with no social pressure to soften it.
The ritual solves a problem that every engineering team knows but rarely names: group dynamics corrupt feedback. In a normal meeting, the most senior person speaks first and anchors the room. People hedge their concerns to avoid conflict. Criticism gets wrapped in so much diplomatic padding that it loses its signal. The person whose idea it is spends their energy defending instead of listening.
Remove those dynamics and you get something rare: honest, independent assessment from people who know the domain.
The catch is that running Ritual Dissent sessions in person requires coordination, availability, and a facilitator who knows what they're doing. It doesn't scale to async teams. And it produces no structured output that an AI agent can act on.
That's the gap I set out to close.
I work with Claude Code every day. I use it to write specs, design systems, draft architecture documents, build plans. It's fast and it's good. But I kept running into the same problem: I'd have Claude produce something well-reasoned and internally consistent, share it with colleagues, and discover that three people had three different concerns that none of us had thought to articulate — concerns that would have completely changed the approach if we'd surfaced them before the agents started running.
The cost of that discovery late in the process is high. The cost of discovering it before a single line of implementation code gets written is close to zero.
I needed a way to run Ritual Dissent asynchronously, at the speed of an AI-assisted workflow, and get output back in a form that Claude could act on directly. No scheduling, no facilitation overhead, no meeting. Just: here is what we're planning to build, tell me what's wrong with it.
Ritual Dissent is a feedback layer for AI-generated documents. You run /ritualdissent in Claude Code. It scans your project for Markdown and HTML files — specs, plans, architecture docs, anything text-based — uploads them to a shared reading session, and gives you a link.
You send that link to whoever needs to see it. They open it in a browser, read through the documents, and highlight any passage they want to comment on. They can leave a comment or propose a direct edit. No account required.
Critically, reviewers can't see each other's responses while they're writing. That's the dissent part — each person's feedback is independent, unanchored by what anyone else has said. You get real signal instead of consensus shaped by whoever spoke first.
When the feedback round closes, you run /ritualdissent feedback in Claude Code. Claude reads every response, synthesizes it into numbered action items, and walks you through each one. You decide what to act on. Accepted suggestions get applied directly to your files.
The whole loop — from sharing a spec to having your AI agent act on the human feedback — takes less time than a meeting.
The point isn't to slow down AI. The point is to direct it correctly.
An AI agent acting on a bad spec produces bad output very efficiently. An AI agent acting on a spec that has been through a proper human feedback round produces good output very efficiently. The difference in output quality is enormous. The cost of the feedback round is small.
Every engineering lead I've spoken to about this has had the same reaction: they know the problem. They've experienced the expensive pivot, the feature nobody wanted, the architecture that made sense on paper and fell apart in production. They just didn't have a lightweight way to systematically prevent it.
That's the bet behind Ritual Dissent: that human judgement, applied at the right moment, is the highest-leverage thing you can do to make AI work in practice. Not more powerful models. Not better prompts. Just: did the right humans look at this before the agents ran?
Ritual Dissent is free for your first session. Try it here.
Thoughts? Find me on Bluesky.