In short
Make This Better bridges the gap between user bug reports and AI agents: the widget captures a screenshot, the DOM, and the console, and the agent retrieves this information via MCP as a task. It sounds like the automation of your dreams—but the devil is in the triage.
AI agents have learned to write code quickly, but they haven’t learned to understand exactly what went wrong for the user. The [Make This Better] project(https://makethisbetter.dev/) aims to bridge this gap: a widget on the website collects feedback by automatically capturing a screenshot, a DOM snapshot, and the console log, while AI triage structures the complaint into a ready-to-go task. Then your agent in Claude Code or Cursor retrieves it via MCP and starts fixing it.
Conceptually, this is interesting because it solves a real pain point. A user writes “export isn’t working”—and the developer has no context. The widget fills in the missing details: URL, errors, and page state. The AI triage system asks clarifying questions and breaks down the feedback into three components: context, the issue causing the problem, and the actual need. This is no longer a raw bug report, but a structured work item.
The workflow looks like this: you set up the CLI, connect to the MCP server, and install the Skill. In the agent, you run /makethisbetter pick, and it pulls in the original evidence—screenshot, DOM, console logs, and triage. The agent “collects” the feedback, patches the code, runs tests, and updates the status. On the public board, the user sees the progress: received → in progress → deployed.
Claude Code, Cursor, Windsurf, and Codex are supported. Setup is via npx skills add makethisbetter/skills and the MCP config. The free plan offers BYOK: you use your own API key, the provider charges you directly, and Make This Better doesn’t take a commission on AI tokens.
But there are three issues here that the landing page carefully sidesteps.
The first is the quality of triage. The entire process relies on the AI correctly identifying a “real need” from a vague complaint. If the triage is wrong, the agent will receive a task that leads in the wrong direction and will calmly commit a solution to a problem that didn’t exist. This isn’t just noise—it’s a confidently implemented error.
Second—who reviews the work. The agent took the feedback, wrote a patch, and the tests passed. But tests also pass on code that fixes the wrong thing. Without a human in the loop, the widget turns into a conveyor belt that generates PRs that look correct on the surface. A public status board creates the illusion of control for the user, but doesn’t guarantee control for the team.
Third—granularity. The widget catches specific bugs: export to Safari is broken, a confusing billing toggle. This is useful. But “seven users are asking for an email newsletter”—that’s no longer a bug, but a feature, and here, structuring through AI triage is no substitute for a product discussion. Automation works well at the lower level—specific UI glitches. At the prioritization level, it creates a dangerous illusion of objectivity: if the AI has grouped complaints into a single ticket, then that must be the next step.
Make This Better—an honest attempt to bridge a real gap. A widget with automatic context capture is useful in and of itself, even without an agent. Integration with MCP is a logical next step that saves on routine work. But selling it as “your agent ships the fix, you sleep” is marketing that hides the fact that it’s up to a human to decide which feedback the agent should act on and which it shouldn’t. Without this filter, you haven’t accelerated the cycle; you’ve simply moved the decision-making point back one step and made it less visible.