You’ve lived this nightmare. A user sends you a screen recording. It’s 47 seconds of them clicking around. No narration. No context. No explanation of what they expected to happen. Just a cursor wandering across the screen like a lost tourist, and then — silence. You watch it three times, squinting, trying to reverse-engineer what they thought was supposed to occur.
Then begins the back-and-forth. “What did you expect to see?” “Were you logged in?” “Is this production or staging?” Five messages deep, and you still don’t know if you’re fixing a bug or explaining how the feature works.
The bug was never in the screen recording. The bug was in the gap between what happened and what the user expected — and nobody captured that.
This is the problem Tentomushi, a side project from FiredAPP Development, is trying to solve. The pitch is straightforward: a user records their screen or uploads a screenshot, and AI drafts a structured bug report — title, description, steps to reproduce, the works. It’s the kind of tool that makes you nod and think, “Finally, someone’s automating the tedious part.”
But here’s where it gets interesting. The top comment on their launch wasn’t about the AI. It wasn’t about the automation. It was a quiet, surgical observation that cut straight to the heart of the problem:
Users submit recordings showing what happened, but never what they expected to happen.
Read that again. Because that commenter just identified the single biggest failure point in every bug reporting tool ever built — and most of you have been staring at it for years without seeing it.
Here’s the uncomfortable truth: AI can watch a screen recording and transcribe every click, every hover, every error message. It can generate a pristine Jira ticket with repro steps so clean they look like they were written by a senior QA engineer. But none of that matters if the report is missing the one piece of information that turns a vague complaint into an actionable diagnosis.
Expected behavior is the missing ingredient in 90% of bug reports, and no amount of AI automation can conjure it from a screen recording alone.
Think about it. When a user says “the button doesn’t work,” what they actually mean is one of a dozen things: the button is grayed out when it shouldn’t be, clicking it throws a 500 error, it navigates to the wrong page, it doesn’t trigger the expected animation, it works but the loading state never resolves. Each of those is a completely different bug with a completely different fix. The screen recording shows the symptom. The expectation reveals the disease.
The real breakthrough of a tool like Tentomushi isn’t the AI that structures the report. It’s the opportunity to insert a prompt — a single field, a single question — that forces the user to articulate what they thought was going to happen before the AI generates anything. That moment of friction, that brief pause where the user has to think about their own expectations, is worth more than any machine learning model in the stack.
The magic isn’t in the AI that writes the report. It’s in the question that makes the human think before the AI writes it.
I’ve seen this pattern play out across the entire DevOps landscape. Teams invest in sophisticated monitoring, automated alerting, AI-powered triage — and then wonder why their mean time to resolution hasn’t improved. They’ve optimized everything except the moment where human intent gets translated into machine-readable signal. They’ve built a Ferrari engine and bolted it to a wagon with square wheels.
The same principle applies here. If your bug reporting workflow captures what happened but not what was supposed to happen, you’re not reducing friction — you’re just automating the confusion. The AI will generate a beautifully structured report that’s missing its most critical field, and the developer on the other end will still send the same clarifying message: “What did you expect to see?”
So here’s the takeaway for anyone building tools in this space — and for anyone evaluating them. Don’t fall in love with the AI. Fall in love with the workflow design that surrounds it. The best tools won’t be the ones with the smartest models. They’ll be the ones that understand a fundamental truth about debugging: the most valuable information comes not from observing the system, but from understanding the human’s mental model of the system.
A screen recording shows you the failure. An expectation shows you the bug. And until your tool captures both, you’re just watching replays of the same accident and wondering why you can’t prevent the next one.
FAQ
Q: Isn't forcing users to write expected behavior just adding friction back into the process?
A: Yes, and that's the point. The friction you remove should be the tedious kind (formatting, categorizing, writing repro steps), not the diagnostic kind. A one-line prompt asking 'What did you expect?' is three seconds of friction that saves three hours of back-and-forth.
Q: How should teams implement this if they're already using a tool like Tentomushi?
A: Add a required field before the AI generates the report. Ask: 'In one sentence, what did you expect to happen?' Feed that answer into the AI's context. The structured output will be dramatically more useful because the AI now has the intent, not just the observation.
Q: Is AI even necessary here, or is this just a UX problem?
A: It's both. The UX problem (capturing expectations) is the hard part that determines whether the tool is useful. The AI is the easy part — it's just structured generation. Teams that lead with 'we have AI' are solving the wrong problem first. Lead with the workflow, then let AI amplify it.