This is an anecdotal answer, as I've been in your exact position. Sorry for the long read, but it gives you an idea on the situation you're in, how you can sometimes resolve it, and how it can sometimes be unresolveable.
As a consultant, I was hired by a company to fix their development processes. I quickly identified a problematic work culture with little to no developer guidance and a toxic undertone. The solution to this problem falls into two categories: Developers who mean well, and those who don't.
The short answer
Is there any way to deal with such problematic teams?
As long as the developers want to improve and are simply lacking guidance, then yes. If they actively don't want to improve, then no.
Developers who mean well
Initially, I assumed that it was innocent ignorance. The company put too much work on all developers and their bad practice (cutting corners, writing slapdash code, no testing, ...) could be a way to cope with the workload. Without guidance, junior developers will develop bad practices without realizing that there's a better way, and if the pressure is constantly too high, they have no time nor effort to dedicate towards investigating if they can improve their (bad) practices.
So what I did is dig into the actual work they did. I didn't just observe the task itself, but also the code they committed, how long it took them to commit the code, and I investigated bugfixes (after the fix was implemented) to backtrack where the bug occurred and how it could've been prevented from the get go.
Using that information, I started tailoring my feedback to developers. Instead of giving them a theoretical rule ("you should do [thing]"), I used their concrete experience ("If you had done [this], then [this later bug] wouldn't have occurred").
Every developer (except one, which I'll get to) immediately improved their practices, deadlines were being met more often and bug reports decreased significantly. This proved to me that the issue here wasn't one of work ethics, but rather a lack of guidance and overhead. Every developer has been hired by the company as a junior, and they had all learned their bad development practices at this company. Those who stuck around had become senior developers, who in turn trained the newly hired juniors, thus causing a recursive loop of bad practice.
If the developers are well intentioned, it's a matter of making them understand the benefits of better practice. This requires concrete examples and clearly noticeable improvements to quality of life (both of the code and the developer's day to day tasks), but once shown, developers will take to them.
But what if your developers are toxic or ill-intentioned? This is where we get to the one developer who didn't improve with guidance.
Developers who don't mean well
This developer's behavior was very problematic. No testing, writing code in a language (French) that half the staff doesn't speak, refusing to learn new technologies or approaches, claiming sole ownership over their code and actively reverting any commits that touched "their" code without their explicit permission, actively ridiculing anyone who pointed out an improvement to their code, debugging on the production database because taking a backup takes too much time, ... the list is endless.
However, this developer was rated the highest by the company. Not because of their practices, but because they were able to solo projects. The company didn't understand development practices, but it does understand money, and a developer who bangs out projects in half the time seems very profitable and should be rewarded, right?
What the company didn't realize is that these projects ran well past their deadline as we'd spend three times longer fixing bugs. Even though the company thought they were being faster, they didn't factor in bugfixes as the bug reports would only come streaming in after the software had its first release.
The problem was that this developer's code was so shoddy and unreadable that no one but them could work with it, and there were seven software packages that could only be supported by this one developer because anyone else immediately advocated a complete rewrite to avoid the bugfest that it was. This led to the company relying on this developer, which gave them a false sense of superiority and that they were doing the right thing.
When I provided guidance (under the assumption of them being a well intentioned developer), I was met with an absolute refusal to take any advice. They would ridicule any suggestion that their code could be improved, argue to no end about inane matters such as indentation, and would refuse to write any test as is "wastes time they should be spending on fixing bugs".
After weeks of not getting through, I decided to fix their code for them (which is not my job) and then discuss improvements with them afterwards in the hope that seeing the improvements would show them that it could be done. But they actively reverted my changes and screamed at me in public for touching their code.
At this point, I addressed the manager. The screaming was unacceptable, but even more importantly, I was at a point where I would not be able to improve this developer's performance unless "I physically forced their fingers on their keyboard to write different code" (hyperbolically), and forcing others to do things they don't want to do is obviously not acceptable.
The ball was in management's court, they needed to reprimand (or threaten to reprimand) this developer because they completely refused to even consider improving their work. That's a HR problem, not a technical one.
And the company never did. I left after another few months because I just did not want to deal with the toxicity anymore. I later found out that this developer had been actively blackmailing their employer, threatening to refuse to work on the seven projects that only they could maintain, which would cost the company more than they were spending on the developer's wage. And thus the company always gave in. This led to the other developers, who had actually significantly improved their development process, to give up as well, as they were being rated more poorly than this bad practice developer (and thus not given any raises or promotions). Last I heard, after a massive exodus of developers, the bad practice developer is now training all the new hires.
This is a bit of a downer ending, but when you're dealing with toxic or ill-intentioned developers, the only recourse is to get the company to correct the issue - either by correcting the developer or firing them. All you can do is assess the situatuion and provide concrete evidence that this developer is underperforming and actively refusing to cooperate with their colleagues.