Regression testing will certainly help here but it should be applied with a focus on the product risks. If you take some time to chat or pair with the developers to understand the scope of the changes it should be possible to identify the areas with the biggest risk of regressions.
When creating a regression suite choose the most reliable tests you have and skip any that might give questionable results (or clearly mark them as such), this keeps confidence in the results high and ensures developers take them seriously.
If you have the time and specs you can create at least some of tests ahead of development so they have a target (TDD) , this gives the benefits of CI right at their desk, however this isn't always possible with complex projects or less specified development styles. Also be very sure your test is accurate !
If you cant do TDD then at least try to deliver tests focused on the areas of riskiest areas change.
The earlier in development you can test meaningfully the cheaper it is to fix bugs you find.
. Continuous Integration is good way to keep code tested , it takes time and you need to write tests in a slightly more stable way than standalone ones. Generally you need s team of testers and possibly some DevOps to get the most out of CI.
So in summary
Cleanup, focus , test early