After building up enough tests, you will feel a new confidence to rewrite some big chunk of code, or conduct shotgun surgery that touches almost every file. Go for it!
As you build more tests and run them several times a day, you will start to get a feel for what you know and don't know about the system. Even more so, when you've written enough expensive, long running tests about a particular part of the system, you will feel a strong desire to rewrite that module.
What are you waiting for? This is the point of building a runnable safety net of tests. Understanding the ins and outs of a module gives you the knowledge to attack it. You might rewrite it, better decouple its parts, or whatever else is needed to make it work better as well as better support tests.
While you may feel a strong desire to attack the code, there may be an equal and opposing feeling to resist making such changes. This is risk aversion, and we all have to deal with it. We want to avoid diving in head first to a situation that could have drastic consequences.
Assuming we have built an adequate safety net, it's time to engage the code and start cleaning it up. If we run the test suite frequently while making these changes, we can safely move through the changes we need to make. This will improve the quality of the code and possibly speed up the run time of the test suite.
Tip
While making changes, we don't have to go "all in"
Cashing in on our confidence means we move in and make changes to the code base, but it doesn't mean we go into areas of code where the tests are shallow and inadequate. There may be several areas we want to clean up, but we should only go after the parts we are most confident about. There will be future opportunities to get the other parts as we add more tests in the future.