I’m a bit confused by this honestly on a couple levels.
First, many of the record-and-playback tools I’ve seen are little more than snake oil and a recipe for shallow testing and a maintenance nightmare. They tend to attract managers who have purchase authority but little knowledge of good testing, so I’m surprised to hear a developer has fallen for the marketing hype. I believe @katepaulk wrote a very good post on the limitations of such tools that might be helpful—I think it may have been on sqa.stackexchange.com but not 100% sure.
Second, I’m assuming that this developer is not your manager? If that’s the case, I wouldn’t let them push you around on what tools or approaches you use for your work, and perhaps your manager can be an ally in defending your autonomy if he won’t back down from trying to control that. I suspect he wouldn’t take kindly to you telling him what tools or languages he should use for development and maybe that’s even a helpful example to bring up if he continues to insist on your using his favorite tech.
Finally, as more general advice I would recommend prioritizing learning to advocate for the value of good testing over learning the tool the developer is trying to dictate. Michael Bolton’s blog (developsense.com) and conference presentations available online (just make sure to include “testing” in your search to avoid just getting the singer!) are some great resources for that. I imagine that if you put together your own test plan and demonstrate how it provides deeper testing for problems that threaten the value and ontime delivery of the product than the developer’s shallow record-and-playback approach, and are able to articulate that depth and skill required for good testing to the developer and to management, he would be hard pressed to keep trying to control how the testing is done.
As one final thought, if he’s dead-set on record-and-playback, perhaps you can make a wager with him that you’ll record the scripts and he can do the work to fix them if (by “if” I mean “when”) they break .