Getting constantly dragged back to fix last week's bugs sounds like a chapter from Dante's Inferno. I'd rather discover them while the code is fresh in my mind.
Without tests, how do I know when I'm done?
Initially separate QA teams that would write tests, a subset of which might do manual testing in the UI.
The feedback loop for this was brutal as you suggest and caused a lot of problems, with delayed breaks that become hard to fix and debug. It's also hard for QA to often know what the code is doing or interact closely with the dev teams. You can try to get them to be as close as possible, but it doesn't work super well.
Now devs are responsible for writing tests and teams think about potential failures when designing things/discussing the plan with their team. They were supposed to consider these things before too, but the incentives weren't aligned - now they are. We have infrastructure teams to make automated testing as easy as possible and spin up a test environment where you can see your change, etc.
I think this model is better, testing well is hard and reasoning about failures and how things can go wrong is an important skill to develop. Offloading this to a different team feels like a variant of the dev that 'just writes features' and doesn't consider actual deployment.
This is often made doubly worse by companies that have QA teams often treating them as second class citizens both in status and in pay. I think it's better to have it be part of the job of the person writing the feature also write the tests, it doesn't help that writing tests is something few people know how to do coming out of school.
I haven't done this in probably 7 years, though. Mostly because I haven't cultivated this kind of working relationship with my coworkers.
Write the tests.
Write the code.
I'm taking about API and system level tests. Unit tests vary in scope between 'test a function' and 'test a unit interface'. Former should be done by the dev during development. Latter should be done by someone else. It's a grey area between those extremes.
I'm coming from a systems programming and embedded background so I have no idea if a web dev or someone else should follow my advice, but I suspect so.