What Adrian said.
This is exactly where Quality Focused resources come into play. People dedicated to identifying risk, gaps and measuring the quality of the application/feature/change.
Ideally most if not all of the regression is automated. Exploratory tests should be migrating into an automated suite very quickly.
In some of the better roles Ive had the process would go something like this:
Developers would be responsible for Unit Tests of a change they are making. Its required for PR review.
Developers and QA would work to add integration tests as a part of the development process. QA Engineers would do things like identify automated tests that should fail as a result of the change. Identify the scope of the suite of tests to be monitored during development process. And so forth
Because management had no desire to wait for all tests to be automated, often a change would head to production befire that was going to be accomplished. So exploratory tests were detailed and and stored in a test case management tool.
As the product iterated, QA or Dev resources could review both automated and manual suites that exist. Identify cases that dont. and have an understanding of tests relevant to the change. Some of those manual cases would be identified as ones to be automated during the work on the change (and would be something a QA engineer could begin immediately while the dev did the change work)
once the PR was about to be merged into the pipeline for production, there would be an expected pass rate for the automated tests and gaps filled by some (hopefully few) manual tests, UAT.