AI induced errors in your code

I've noticed that, sometimes the AI will choose unexpected libraries, and there is the temptation to just accept it and see where it goes with the code! Some orgs have mechanisms that would avoid that from being introduced into code. Example is financial orgs, they won't allow any library or API or middleware to be used without an 'on-boarding' process, which can easily drag out for months on end (and six months to a year is not unknown), because it needs approval from multiple departments and they will have a documented process to do that so that things are not ignored. As a result, there's massive incentive to try to use libraries/APIs etc that are already in use elsewhere in the org, simply to get the code released quicker.

Another now popular thing is to modularize the code substantially, and then each portion has it's own enforced rules (for instance, which destinations the portion is allowed to communicate to, and over which ports etc), in other words there's a virtual firewall in-between almost every tiny portion of code, and anomalies are then easily noticed. This doesn't apply all that much to embedded apps unfortunately, although, the Microsoft SDK for a microcontroller (Azure Sphere, it was for some MediaTek chip) which was released around 2019 did contain separate areas for code to execute in, and a sort of rules that could be configured and enforced, for what communication was allowed between those two areas, i.e. a super-tiny firewall (but I don't remember much about it).

I've noticed that, sometimes the AI will choose unexpected libraries, and there is the temptation to just accept it and see where it goes with the code! Some orgs have mechanisms that would avoid that from being introduced into code. Example is financial orgs, they won't allow any library or API or middleware to be used without an 'on-boarding' process, which can easily drag out for months on end (and six months to a year is not unknown), because it needs approval from multiple departments and they will have a documented process to do that so that things are not ignored. As a result, there's massive incentive to try to use libraries/APIs etc that are already in use elsewhere in the org, simply to get the code released quicker.

Another now popular thing is to modularize the code substantially, and then each portion has it's own enforced rules (for instance, which destinations the portion is allowed to communicate to, and over which ports etc), in other words there's a virtual firewall in-between almost every tiny portion of code, and anomalies are then easily noticed. This doesn't apply all that much to embedded apps unfortunately, although, the Microsoft SDK for a microcontroller (Azure Sphere, it was for some MediaTek chip) which was released around 2019 did contain separate areas for code to execute in, and a sort of rules that could be configured and enforced, for what communication was allowed between those two areas, i.e. a super-tiny firewall (but I don't remember much about it).

shabaz said:

Some orgs have mechanisms that would avoid that from being introduced into code.

Mine does. Our engine is vetted on a fenced set of information. And we have a process to introduce new knowledge.

It 'll come at a cost - we miss a whole lot of training that's available in public. 
On the other hand, we avoid to get unfriendly code in. And it avoids that our trade secrets leak out to the public.

This makes perfect sense, but is ironic.  (Some) People are using AI to write their code.  But if you want safe, secure, reliable code, you have to check everything before it goes into production.  Is there a time savings?  Maybe.  Maybe not.  But if you don’t want safe reliable code, of course, there is a time savings.