Police it, and give it explicit instructions.
Then after it's done its work prompt it with something like "You're the staff engineer or team lead on this project, and I want you to go over your own git diff like it's a contribution from a junior team member. Think critically and apply judgement based on the architecture of the project describes @HERE.md and @THERE.md."
You use it to make your job easier. If it doesn't make your job easier, you don't use it.
Anybody trying to sell you on a bill of goods that this is somehow "automating away engineers" and "replacing expensive software developers" is either stupid or lying (or both).
I find it incredibly useful, but it's garbage-in, garbage-out just like anything else with computers. If your code base is well commented and documented and laid out in a consistent pattern, it will tend to follow that pattern, especially if it follows standards. And it does better in languages (like Rust) that have strict type systems and coding standards.
Even better if you have rigorous tests for it to check its own work against.
This is still early days with LLMs and coding assistants. You do have to hold them in the right way sometimes. If you're not willing to do that, or think that provides less value than doing it another way... great, good for you, do it the way you think is best for you.
I've been a coding assistant skeptic for a long time. I just started playing with Claude Code a month or so ago. I was frustrated for a bit until I learned how to hold it the right way. It is a long, long way from being a substitute for a real human programmer, but it's helpful to me. I certainly prefer it to pair programming with a human (I hate pair programming), so this provides value.
If you don't care to figure out for yourself if it can provide you value, that's your choice. But this technology is going to get better, and you might later find yourself wishing you'd looked into it earlier. Just like any new tool that starts out rough but eventually turns out to be very useful.
> Better off training someone off the street to be a software engineer.
And that person is going to quit and you have to start all over again. They also cost at least 100x the price.
Because right now AI companies are losing their asses - it costs significantly more than what they are charging.
Honestly, it feels like DevOps had a kid with Product.
You've just described a match made in hell. DevOps - let's overcomplicate things (I'm looking at you K8s) and Product - they create pretty screenshots and flows but not actually think about the product as a system (or set of systems.)
