Bunch of comments online also reflect how there's a lot of "butthurt" developers shutting things down with a closed mind - focusing only on the negatives, and not letting the positives go through.
I sound a bit philosophical but I hope I'm getting my point across.
I mean, do we really want our code base to not follow a coding standard? Or are network code not to consider failure or transactional issues? I feel like all of these traits are hallmarks of good senior engineers. Really good ones learn to let go a little but no senior is going to watch a dev automated or otherwise, circumvent six layers of architecture by blasting in a static accessor or smth.
Craftsmanship, control issues and perfectionism, tend to exist for readability, to limit entropy and scope, so one can be more certain of the consequences of a chunk of code. So to consider them a problem is a weird take to me.
This conversation is useless without knowing the author's skillset and use-case.
sounds like you can't code for shit. guidelines, standards, and formatting have developed for a reason. the reason is: less bugs and maintainability. you sound like the average cocky junior to me.
2. When you are in a new area, but you don't want to dive deep and just want something quick and it is not core of the app/service.
But, if you are experienced, you can see how AI can mess things up pretty quickly, hence for me it has been best used to 'fill in clear and well defined functionality' at peacemeal. Basically it is best for small bites, then large chunks.