How To Build A Hands-Free Streaming Rig With Claude Code And CodeRabbit

The streaming rig was a distraction, and most viewers took the wrong lesson

I am going to stake a clear position: the impressive part of that hands free streaming demo was not the streaming, and it was not that an AI wrote the code. It was that a second AI reviewed every change and refused to let bad work through. Almost everyone who watched it fixated on the voice control and the scene switching, which is the least important thing in the whole build. The part that actually matters, the part that changes what a small business can afford to build, is the loop where one AI writes and another AI signs off. I am Madhuranjan Kumar, and I think the single AI writing code is old news. The reviewer is the breakthrough, and missing that is missing the entire point.

Here is the contrarian claim in one sentence. The reason small businesses have avoided custom software is not cost, it is trust, and an automatic reviewer removes the trust problem, which means the usual excuse for not building the tool you need no longer holds. That is a bigger deal than any streaming rig, and it deserves to be argued properly.

Letting one AI write your software unsupervised is genuinely reckless

Let me concede the thing the skeptics get right, because it is real. Handing a coding agent a task and shipping whatever it produces is a bad idea. Agents write plausible code that looks correct and quietly breaks under the second customer, the edge case, the busy Saturday. If the story were just an AI wrote a working app, I would be the one warning you off it, because unreviewed AI code is exactly the fragile demo that falls over the first time real load hits it.

That is precisely why the naive version of this deserves the skepticism it gets. A business owner who cannot read code has no way to know whether the thing they were handed is solid or a liability wearing a nice interface. The gap between looks like it works and actually works is where money and reputation go to die. So the objection is correct as far as it goes. The mistake is assuming the objection is the end of the story.

The reviewer is what turns a lucky demo into a real workflow

What flips the whole thing is putting a second AI in the path as a gate. In the demo, one agent wrote the code and a code review tool inspected every change before it could merge. That tool spins up a sandbox, summarizes what changed, and reports problems by severity. On the first pass it flagged one major and one minor issue, handed them straight back to the writing agent, and the writing agent fixed them on its own. The second pass came back clean. It reviewed the larger pull request too, and there it surfaced four actionable items and three smaller nitpicks, all fixed automatically. The session even polled the pull request every minute until the review was done, so the loop stayed hands off.

That rhythm, test, review, fix, test, review, fix, then merge once the tests pass, is the actual product. It is not a clever trick specific to streaming. It is a repeatable engineering discipline that happens to run without a human sitting in the chair. The reviewer catching each problem in the phase that created it, rather than three phases later when it is tangled into everything else, is what keeps the cost and the risk low. Take the reviewer out and you are back to the reckless version. Leave it in and you have something a non technical owner can actually trust.

Two documents do more work than any amount of prompting

The other underrated part is that the whole thing is governed by two plain text files written before any code exists. The build starts with a plan document that lists every feature in ordinary language: voice control, chat commands, device switching in the original demo. Then a rules file holds the project's standards: use a proper version control workflow, run the reviewer between phases, review the code at each step.

I would argue those two documents are why this is a workflow and not a one off lucky run. Because the intent and the rules are written down, the build stays consistent across sessions. You can pause for a week, come back, and the agent still follows the same standards, works phase by phase, and submits each phase for review. That is the difference between a repeatable system and a demo that only worked once because the stars aligned. Skeptics who dismiss AI coding as unreliable are usually describing the version with no plan and no rules, which is a fair description of a bad process, not a fair description of this one.

Why this dismantles the usual excuse for skipping custom software

Now to the heart of the argument. Most small businesses assume custom software means hiring engineers, crossing their fingers, and hoping nothing breaks in front of a customer. That assumption made avoiding custom software the rational choice for years, because the downside of a fragile build was worse than the upside of a convenient tool. The reviewed loop changes the math. It replaces the crossing your fingers part with an automatic gate that catches bugs before they ever reach you.

Once that is true, the old excuse stops working. A restaurant can commission a reservation and waitlist tool. A law firm can build an intake form that files cases correctly. An e-commerce store can wire its orders and support tickets together. In every case the owner writes down what they want, the agent builds it in reviewed phases, and a second agent guarantees the work is checked before it ships. You do not need to become technical, and you no longer need to accept a fragile result as the price of building something custom. That is why I keep saying the reviewer, not the writer, is the news.

A worked example: the auto repair shop that needs a tool it can trust

Say the owner of an auto repair shop wants a simple job tracking tool. Customers drop off a car, the shop logs the repair, and the system texts an update when the work moves from inspection to in progress to ready for pickup. First I would write the plan document listing exactly those features in plain language. Then I would write the rules file so every phase gets reviewed before it merges.

The writing agent builds phase one, the core job records and the status updates, then submits it for review. The reviewer flags anything risky, like a text message firing twice or a status that can skip a step, and the writing agent fixes it. Phase two adds the customer facing status page. Phase three adds a daily summary of which cars are in the bay. The owner never touches code. They just read the short plan at the start of each phase and confirm the finished tool works. Because the reviewer is catching mistakes the whole way, the shop ends up with a tool it can actually trust on a busy Saturday, not a fragile demo that falls over the first time two cars are logged at once.

The same discipline extends past internal tools. When the shop wants a booking page wired into its CRM and website stack, or a custom landing page built to convert the traffic from its Google Ads, the reviewed loop produces something dependable rather than something that half works. The reviewer is what makes it safe to point this at anything customer facing, which is where the real revenue lives.

The position, restated

So here is where I land. The people impressed by the streaming rig were impressed by the wrong thing, and the people dismissing AI coding as too risky are describing a process that does not include a reviewer. Both are looking at the surface. The durable idea is a build and review loop where the mistakes get caught automatically, in the phase that created them, before they ever reach a customer. That is what makes custom software a reasonable option for a business that could never justify a dev team, and it is why the excuse of it is too risky to build our own tools no longer holds up.

Start with the two documents, not the code. Spend an hour writing a plan that lists every feature in plain English, then a rules file that says build phase by phase, run a code review between phases, and fix the findings before merging. The discipline of review as a gate is what turns a fuzzy idea into a tested system you can run live, and none of it requires you to be an engineer, which is the entire point.

Anticipating the strongest objection to my own position

Let me take on the best counterargument, because a position is only worth stating if it survives the strongest pushback. A serious skeptic would say this: sure, a second AI catches some bugs, but who reviews the reviewer? If both agents share the same blind spots, the review is theater, and you have simply automated your way to false confidence. That is a fair and important challenge, and pretending it away would be dishonest.

Here is my answer. The reviewer does not need to be perfect to change the economics, it needs to be independent and consistent. In the demo the review tool ran in its own sandbox, evaluated the code fresh against severity criteria, and caught concrete issues on multiple passes, including on the larger pull request. It is not a rubber stamp, and because it applies the same standard every time, it catches the routine, expensive mistakes that slip past a tired human at the end of a long day. It will not catch a deep architectural flaw that neither agent understands, which is exactly why the human still owns the plan, the acceptance test, and the final sign off on anything customer facing. The claim was never that this removes the human. The claim is that it removes the fragile, unreviewed step that made custom software too risky for a small business to attempt. That narrower claim holds.

What this quietly does to the cost of building anything

The deeper consequence is about cost, and it is bigger than any single tool. When building custom software required a dev team and carried real risk of shipping something broken, the bar for building anything was high, so businesses only commissioned software when the payoff was large enough to justify the gamble. A huge number of small, useful, boring internal tools never got built, because they were not worth the risk and expense.

The reviewed loop drops that bar. When the writing is automated and the checking is automated, the cost and risk of building a small tool fall far enough that the boring, useful ones finally make sense. The reservation tracker, the intake form, the daily summary, the little utility that saves an hour a week. Those are exactly the tools that never justified a developer but absolutely justify an afternoon of a reviewed agent's time. That is the real shift hiding behind a streaming demo: not that AI can write code, but that checked, trustworthy code is now cheap enough to point at problems that were never worth solving before.

Once you accept that, the strategic question for a business changes shape. It stops being can we afford to build this and becomes what small frictions have we simply tolerated because building around them was never worth it. Most companies are full of those frictions, little manual chores that everyone accepts as just how it works. The reviewed loop makes a large share of them cheap to eliminate, one small tool at a time, and the businesses that start noticing and fixing them will quietly pull ahead of the ones still treating custom software as a luxury they cannot justify.

You can absolutely build this yourself, and I would start with one small internal tool this week just to feel the loop work. If you would rather hand me the feature list and have the whole reviewed build stood up so it works on the first try, that is exactly the kind of work I do for clients, and you can bring me in to handle it.