The issues we have with any code development; whether through on-site employees, offsite employees, contract shops, or integrated contractors, would also apply to AI.

Those of us that have been doing it a while, know that the single biggest issue in any commercial code project is bad input to the process; otherwise known as Requirements. No one knows what they want, or, even worse, they know what they want, and what they want, sucks.

Steve McConnell wrote about how projects mess up, and how much the damage can propagate throughout a project lifecycle; with bad requirements being the nightmare scenario. This was about a quarter century ago. It is not new (https://stevemcconnell.com/articles/software-quality-at-top-...).

The best requirements for a software project is code. Even an AI will need extremely high-quality, detailed, and well-considered requirements that are likely to require their own language (so AI requirement-generation will look a heck of a lot like "coding").

What AI gives us, is (maybe) speed between requirements and executable, so, theoretically, we could have a really high-power, effective iterative process, where bad input results in bad output, and we see that quickly, then refine the input; much like we already do with code, and run the build again, to see how that results in executable.

I learned development back in the "big iron" days, where CPU time was the most expensive part of the process, and we were required to debug our code in the design phase. If we borked during our slice, we were penalized.

Nowadays, I tend to just write some junky "strawman" code, fire up the debugger, and step through until it breaks.

Working with separate contractors, whether domestic or offshore, needs really good requirements, and some kind of fast feedback and a flexible, iterative lifecycle process; which is frog-fur rare.

If we don't have a fast feedback cycle, then we can't iterate effectively. In-office staff helps to make feedback fast, but it's quite possible to have fast feedback in a distributed environment (I used to work for a Japanese corporation, so I can tell you about "feedback lag"). It's just that we then need some kind of process to afford and regulate that feedback loop.

I think that the process of software development is fundamentally broken, and that the industry is still thrashing around, trying out all sorts of "silver bullets" (See Brooks, Fred).

I also believe that overbuilt process is an enormous issue. I call it "Concrete Galoshes" (https://medium.com/chrismarshallny/concrete-galoshes-a5798a5...), and it affects new-fangled, agile shops, as much as it does old-fashioned waterfalliers.

Unfortunately, if we want to reduce "tribal knowledge," and treat our engineers like interchangeable LEGO blocks, then we need a pretty heavy process. It's still a heavy process, even if we call it "agile."

"Tribal knowledge" is a bad term in the software development industry, but it is the most effective way to have a light-touch process.

It also requires treating engineers well (not just paying them well), so they stay around. I'm not sure that foozball tables and on-site beer are doing the trick, as the average stay at a corporation seems to be less than 2 years.

I do not have the answer. If I did, I would own a private jet for every day of the week. I have my own personal process that works quite well for me, but I don't think it scales particularly well to others.