In my experience, the clankers can write great code when you give it a hole with the right shape in the bigger picture of code that looks how you like. I had the experience of setting a clanker loose on Wizard to go implement a Wasm proposal[1] that had reached stage 4, and it wrote the canonical V3 interpreter implementation, fast assembly interpreter implementation, and JIT support, as well as code validation and fitting the rest into the system, in just 40 minutes, complete with tests. The VM code was canonical. There wasn't a line I would have written otherwise. In the end it was only 144 lines. But it was the right 144 lines.

Clankers can do things right when they are given clear instructions and good context. They go bad when they are given agency and no oversight. What I have seen repeatedly is that even small amounts of correction to turn a refactoring this way or that way or make a better modularity decision, or to enforce a boundary that wasn't written down, helps a lot. Clankers don't know about your implicit information hiding going on. They don't know you've been working for years to get rid of a bad code smell that spread faster than you could stamp it out, or that you've been working on the same codebase for 10+ years and only now understand how you'd like to structure it.

Some people use the clanker to get something out of nothing. As engineers, we should be using them to engineer the heck out of things that we didn't have human effort available for. Things like refactoring, testing, cleaning up documentation, doing optimizations, simplifying, introducing proper interfaces, removing improper interfaces, etc.

[1] The wide-arithmetic proposal, which added 4 instructions with very well-specified behavior.