A computer program (and software in general) is "built from scratch" by writing code. Programmers are encouraged to include and use proven library routines within the code that they are writing, but software is basically"built" from the ground up, like a structure or a building.
However, software is NOT a building, and we should not have to logically "start from scratch", and build up new software functionality in a painstaking way, and include proven stuff (library code) sort of "as needed". Instead, why not start with a huge"do everything" piece of running code that has everything "already in there" running and proven, and then we program by logically "throwing away what we don't need". This is a bit like saying that when a sculptor creates a statue of a bear, the sculptor starts with a block of marble and then chips off everything on the block of marble that does not look like a bear. The bear you want (a program) is "in there" in the do-it-all hyper-program, proven and debugged. You (as the programmer) have to describe what "bear you want" to an AI mechanic and helper, who then helps you throw away stuff you don't need. But every line in the resulting code comes from the hyper-program engine, including glue and integration lines.
Obviously our existing libraries of link-able, "include-able" code today, are proven, running code, but with the context left out, and one still has to create code "from scratch" for the existing problem context. My (hazy) vision says that (if we but had the will, and an invented way) we could provide generic commercial contexts *in our libraries*, such that the programmer's thought process is changed drastically. What I am thinking of would be analogous to the construction work that happens when a house is extensively re-modeled, as opposed the the construction work that happens when a new house is built from scratch.
To do this correctly by my "vision of it", we probably need a whole new way of specifying and of "talking about in a precise way" the commercial problem contexts of software. How do we know that we need to do a sort here? How can we tell that this problem requires creation of a file (or a DB table) by combining (or merging) two other files (or tables), in a particular way, and then visiting each item (or row) in that resulting file/table, to do <blah>? We need a way to make "problem context details" become as "manipulate-able" as is "normal data". Or something to this effect. Can we abstract and codify the universe of programming problem contexts in such a way that the programmer can be always working at an even higher "level" in a meta-problem sense?
There is a level of meta-problem "context" that is unstated (or not specified in precise and reproducible ways), that needs to become the subject of "AI expertise" where now it is only the domain of the programmer/coders who have become familiar with the needs of a particular business or commercial (or government) context. And of course this "context" evolves over time...
Obviously (to me anyway) a visionary "new way" would involve working with an (AI-based) "expert" on the topography of this wonderful, "it does that already" huge structure of running code, in pre-defined contexts. The expert would be an AI "bot" who is an expert at not only the structure of this context-based, running-code, model library, but also is an expert at interacting with programmers to "find what is needed" within that universe of "running-code-in-context", and "narrowing it all down" to only what you need in this case. "Talking" with the AI-based impresario of the hyper-does-it-all program would involve much to do with extracting local application data and contexts from the selected pre-running hyper-does-it-all "context library", that has its own (somehow codified) context and data structures that enable it to run. Perhaps there would need to be a sort of psuedo-code specification of the algorithms and the problem contexts involved, that the AI-based "universal code mechanic" could use as a guide for helping the programmer extracting known good particular code from the universal, "it already does that" hyper-program.
ALSO (I believe) that this would "only work" (or perhaps "would work best") for
application-level code. System structures are so much dictated by the hardware
architectures involved, that "select and throw away" strategies would be not of
as much use, I think.