As you said, the best would be for you to give it a try and see the benefits in practice (if any). Beyond that, I can add to two points you brought up: First,

As you said, the best would be for you to give it a try and see the benefits in practice (if any). Beyond that, I can add to two points you brought up: First, Playwright MCP is really not enough. For example, imagine you are building a project management software and you are working on a feature for transferring tasks between projects. Testing this feature requires at least a user who is admin and at least two projects. When it is time for Playwright to test this feature, you need to automate the account creation, then it has to set up two projects, add the task, etc, and it often gets stuck. When you are using Tidewave, you naturally do this setup as part of your development, which Tidewave has direct access to during tests. So it just interacts with the same page. Furthermore, if you see any bugs or places you could improve, you can't really tell Playwright or regular coding agent to fix them, you have to translate what you want. With Tidewave you just point and click and it works across browsers. I talk more about this in the announcement post: https://tidewave.ai/blog/tidewave-web-phoenix-rails https://tidewave.ai/blog/tidewave-web-phoenix-rails Other than that, I am really curious about the handoff between Tidewave and the editor that you mentioned. At some point, you will need the editor indeed, but how to best do this transaction? Should you be able to review and do tiny tweaks within Tidewave first? Regardless, moving the agent to the browser for web applications bring enough benefits to justify going one lever higher. :)