In a companion piece we made the case for building with a genius and shipping a machine — using an AI agent to develop, test and endlessly refine a fast, deterministic engine, so what lands on your phone is instant, private and incapable of hallucinating. Every word of it is true. This is the honest asterisk.
Because for all the loop's power, the biggest single leap in how accurately CricCuts tells a real cricket shot from a false alarm did not come out of the agent. It came from a person noticing something the numbers had been hiding in plain sight. And what makes it worth writing down is which half of the work turned out to be the hard, human half.
The false alarms that would not die
Picture a row of practice nets, several side by side, one phone on a tripod filming them all. You want the reel of your batter — but the net next door is also full of cricket. The crack of the bat two lanes over sounds almost identical to yours. And a plain motion detector, counting how much the picture moved, can't tell the difference between a delivery and a person strolling across the frame during a changeover.
So the app kept flagging moments that weren't your shots: the neighbour's cover drive, someone walking through, the shuffle between overs. Not many — but enough to nag. And every fix I reached for lived on the same axis. Was it louder or quieter? Did more of the frame move, or less? We tried richer motion features, we tried tracking the flow of pixels, we tried full body-pose estimation. Each one helped a little, then flattened out. The false alarms had learned to look exactly like the real thing on every scale we were measuring.
This is precisely the situation the agent is built for. I put the pipeline through review after review — with Claude, which had built and rebuilt this engine a hundred times over and held every signal in its head at once, and with Fable brought in for a cold, adversarial second read. Between them they proposed a small mountain of ideas: sharper thresholds, cleverer motion descriptors, better pose, ways to combine what we already had. Good ideas, tested in hours instead of weeks. And all of them, quietly, were more of the same question — how loud, how much, what shape. None of them changed the question.
Every signal we tried asked the same thing in a new accent: how much did this moment move, and how. The breakthrough was to stop asking that entirely.
The thing you only notice standing behind the camera
The reframe came while I was watching the footage — not the graphs, the footage — for the hundredth time. And it landed as something obvious that had been true the whole time: the camera never moves.
Ball after ball, the bowler runs up through the same strip of the picture. The batter settles and triggers in the same box. The follow-through sweeps the same arc. On a fixed camera, real cricket is astonishingly repetitive in space — the important things happen in the same places, over and over, all session long. And the false alarms? The person wandering through, the changeover, the stray ball from two nets down — those are novelties. They happen rarely, and they happen somewhere else.
So here was the hunch: what if the recording could teach us where its own cricket lives? Build a simple map of where movement gathers across the entire session — a heatmap where the squares that light up again and again are the real action. Then judge every candidate moment by one new question: does this look like it happened where cricket keeps happening here, or off in a corner the pattern says it shouldn't?
Why "where" beat "how much"
That one shift in the question did what a dozen cleverer-sounding signals couldn't. It could finally tell your shots from the next net's — because they simply live in different parts of the frame, and the map knows it. It cost almost nothing to compute, because the movement information was already being worked out for something else; we'd just been throwing this part of it away. And best of all it teaches itself: every recording builds its own map, so it adapts to wherever you happen to set the phone down, with no setup and nothing to configure.
None of that is magic, and I want to be careful not to oversell it — it's one signal among several, it has its own failure modes, and it took a lot of that same tireless agentic testing to prove it held up on real footage rather than just sounding clever. But the direction was right in a way nothing else had been. It was the reframe that unlocked the rest.
The idea no model suggested
Here's the part I keep turning over. This was, by a distance, the most important accuracy idea in the project. And no language model proposed it.
🤖 What the models were brilliant at
- Holding the whole tangled pipeline in mind at once
- Generating and testing dozens of variations, fast
- Building the measuring instruments — the scoreboards, the A/Bs
- Refactoring, hardening, never getting bored or tired
- Every idea adjacent to the ones we already had
🧠 What only the human brought
- Having actually stood behind that camera, for years
- A gut feeling that the boring, repetitive thing was the signal
- Changing the question, not just the answer
- Knowing what a false alarm feels like, not just scores like
- The one reframe none of the reviews reached for
This isn't a knock on the AI. Claude had rebuilt this engine more times than any human team ever could, and Fable read it cold and sharp. They were faster and more thorough than I will ever be. But they optimised within the frame of the problem as it was posed — better answers to the question on the table. The move that mattered was to change the question: to stop measuring the motion and start mapping the place. And that came from a very particular, very human thing — having watched a thousand of these clips and felt, in the gut, that the real cricket was the dull, repeating thing and the false alarms were the novelty.
Models are extraordinary at answering the question you give them. The rarer, harder work is realising you've been asking the wrong one.
The real shape of the partnership
So the honest version of "build with a genius, ship a machine" has a third character in it. The tireless genius in the workshop is the agent. The fast, private, hallucination-proof machine in your hand is the deterministic engine it helped forge. But the spark — the idea that bent the whole trajectory — came from a person who plays the game and had lived with the problem.
And here's the thing: AI didn't diminish that. It amplified it. A hunch I could never have tested in a month, the agent validated in an afternoon — building the harness, running it on real footage, scoring it honestly, and telling me, unsentimentally, whether my pretty theory actually held. Human intuition without that loop is just a hunch. The loop without the intuition is a very fast search of the wrong space. Together they're something neither is alone.
I think this is going to be the shape of a lot of good software for a while. Not the AI replacing the maker, and not the maker refusing the AI — but a person who knows their problem deeply, handing an agent the one insight that reframes it, and getting back in hours what used to take a season. The genius did extraordinary work in the workshop. The idea that made it matter walked in from the nets.
See what the partnership built
Intelligent, on-device cricket highlights — free, private, offline. Point it at your footage and watch it find the moments that matter.
Get the app → Build with a geniusRelated reading: build with a genius, ship a machine — the companion piece on agentic development — and how a phone watches cricket and cuts the highlights itself. More on the CricCuts blog.