The slow part of software is NOT the initial generation of software. It's the maintenance and review of it.

If your management is pushing for 10x programmer output, hell even 40% more programmer output, what they're asking for is a stability crisis. There's no way around it. That's how it is right now.

You can use these tools for red teaming (caveat: you will get a lot of false positives also). You can sort of use them for prototyping (though a lot of the value of understanding building through the prototyping process may be lost during that time; still, it is one place where things can increase). Those two categories don't create huge and unresolved copyright output questions in your codebase, and I think you can justify them.

But if you're using them to actually write the software itself, you're borrowing against the future, against stability, and against institutional understanding of your own stack.

Oh yeah the other caveat about using them for prototyping, as @tamzin highlights below, is that "quickly thrown together prototypes" often become production code, to their authors' dismay.

In many ways, whiteboard prototypes are much better, as they are immune from this problem.

@cwebber @kaye

Someone, somewhere is already taking a picture of a whiteboard and feeding it into a model, saying "build this."