In the first place, I'd recommend reviewing **why** that happened in the first place:

- Is this improvement just an implementation detail?
- Or does it involve a bigger change in terms of design/architecture?

It sounds to me like this suggestion is bigger than just an implementation detail. This could be a symptom of insufficient detail at the design documentation phase. It reminds me of [this video where Rahul explains the scope that a healthy code review should have](https://www.youtube.com/watch?v=rTvq8vS42zk). I pretty much agree with him when he says that architecture discussions should not take place in a code review, they should take place in the design phase instead, where these kind of higher level issues should be addressed. I'd reflect on that to see if there's a way the design phase could be improved to make sure these kind of situations don't happen again.

On the other hand, now that this has happened, I'd try to find a compromise. I'd try to come up with a plan to migrate from the original solution to the solution your coworker proposed. I'd then discuss with my coworker the plan and I'd merge the original solution for the current sprint (since the coworker thought the code was good enough), but ensuring that in the next sprint the better solution from my coworker would be implemented. This is assuming that you have some sort of hard deadline where the code **has** to be merged for the current sprint.

Hope that helped!