And an application is far more than just the code.
Upfront design, and often figuring out what the customer/user is actually wanting to do.
Which is very often not what they verbally ask for.
Very true. One of my last major projects before retiring was writing schedule monitoring package for a major brokerage firm. All jobs had to be finished by schedules established by the FTC or there were major fines (some over $1,000,000). This meant all jobs in the job chain had to finish within parameters or the various final products would not be completed before penalties.
The original specifications stated to track and report on a screen every 30 seconds the status of all the jobs, over 12000 at the time. There were other specifications but this was the first I saw and asked my boss if they were serious. They were and the specifications had been approved all the way up to CFO and CTO levels. I was actually hired to be assigned the job so the new person would be the one fired when the job could not be completed on time.
I called for a meeting with the customers. I was told no. I pushed and did it anyway, the primary customers begrudgingly agreed. They asked at them how good their eyes were? They asked me what I meant. I said the requirements would result in 400 lines per second being scrolled on the screen (standard 25 lines) or about .07 seconds for a line from top to bottom. They said I was wrong. I pointed out the 12000 jobs being reported with full status information (when start, how long ran, job status on completion, completion time, ...) so 1 line per job. 12000 lines/30 seconds = 400 lines/second, 25 lines(screen)^-1/400 lines(second)^-1=1second/16screens. After they realized what they had asked for, I asked what they wished to accomplish and why. After about 30 minutes, I had a good idea of what was needed. I asked for another meeting in a week to present a fleshed out idea on what I thought would work, I just had to check information available to me to make sure, I could do what I was thinking.
I spent the week pouring over system files, the specific subsystem, ... and came up with a general program. I presented it to them. I indicated, it might have a few problems to be worked out but the program should work.
Basically I build a database of jobs, start times, and run times. I then only reported jobs starting late, running long, or terminating abnormally. There was one more major problem in that they wanted information displayed immediately. To do so, literally ate up all 4 processors of a large mainframe computer. The job was disallowed to run as it mean spending something like $30,000,000 for a complete system. The people complained and I asked if I could sleep the system and only run the information every 30 seconds. They agreed. No new system required, jobs reported that were late, long running, or aborted, and at most a few seconds lost (assuming the production control people glanced at the screen once or twice a minute. Customer happy.
An AI can not look at the various factors. An AI cannot determine what is actually needed from what is listed in a pie-in-the-sky specification. An AI cannot recognize human limitations. AI based programming is good for taking what has been and reusing. It is not good for creating whole new ways of looking at the problem so finding whole new solutions.
Finally I know few work in macro assembler and machine language anymore but do they even have AI's that code in those languages for efficiency?