It's called a compiler.
I specifically referring to English though, not computer language.
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.
The books that are published feel like they're targeting entry developers and it's a lot of stuff you'd learn on the job. It feels like we're over-promoting way too quickly and demanding delivery over experience or quality.
Interviews: You have developers that refused to learn this skill and they just skim a few leetcode problems and expect the interviewee to solve it in 15 minutes.
Best practices: What happened to developing standards and demanding/expecting tests (and their appropriate categories unit, integeration, smoke, feature/functional, etc)
Though things could get fun if AI can enable more flexible declarative programming.
Have you read laws? That is the style of language that tries to make a "precise and clear enough description" in English, but it does not go far enough, it's still not sufficiently precise to be applied directly, you would have to use something like 'super-legalese' for that.
So even if you had a system that could accept English, nobody would want to use that because it's difficult to express precise and clear enough descriptions in English, and easier to do so in Python or some other programming language; and in any case, the difficult part of programming is thinking up the precise and clear enough descriptions.
This comes up in writing specifications for outsourced programmers. Writing a specification in English that's clear and actually precise enough takes more work than just writing the code directly - since you have to do all the hard part anyway, and then have to express it in a language that's poorly suited to do so. And a reasonable specification is very much not precise enough to be executed, it relies on the programmer putting in a lot of the details based on their domain understanding and common sense, leading to very different implementations as that domain understanding and common sense varies.
Yes but in the future this can be solved by the smarter AI.
Essentially that what a lot of developer do, they turn other people idea or english description into working code.
You give the AI instruction and explanation in English, preferably as clear and as detailed as possible and you get back code.
Essentially its very similar workflow when working with offshore developer, in the future you could in theory replace the offshore dev with AI, except with much less latency.