They are paying for it, so I'm not clear on how you hide it. They'll figure it out, and you look disingenuous when they do.
If they’re working on a shared codebase together, the latter developer will end up cleaning up the mess left by the former and getting less recognition from management. In all likelihood, this developer will either leave due to resentment, be laid off for underperformance, or stop doing the maintenance work. In any case, there’s no longer anyone seeing to the long-term development velocity and the team’s productivity will slowly grind to a halt.
1) Slack in the system, meaning there is time without explicitly defined tasks that have to be done.
Basecamp does something like this where they take 1-2 weeks off scheduled work after a 6-week cycle to let their employees fix things up [0].
2) A good definition-of-done plus a technical culture focused on quality.
My current workplace has a culture of valuing correctness and quality over velocity, it has been a nice change of pace from my previous workplace where velocity was valued over everything else, leading to lower velocity as our code became worse over time.
0: https://3.basecamp-help.com/article/35-the-six-week-cycle
I'm talking about how the development team as a whole should relate to other parts of the business.