The article formulates the basic concepts related to the automated program repair. It also discusses the main ideas and approaches. This topic is very relevant, because modern programming technology does not allow to make large, complex systems free from errors. The occurring of these errors during program execution can lead to serious consequences. In addition, the number of errors in programs is greater than the developers can fix. The Article is the first part of the work devoted to the automated program repair and is mainly theoretical. Unfortunately, a program is a very inconvenient object for processing, and this creates fundamental difficulties for the implementation of automated repair. A number of the proposed approaches have no theoretical basis, and the practical results of their application are unsatisfactory. There is no effective universal algorithm to verify that a computable function has a given nontrivial property. In addition to algorithmic insolubility, the problem is the complexity of programs, both in the number of their constituent entities, and the number of relationships between them. For large programs, overdriven algorithms may not be acceptable because of the combinatorial explosion and, as a consequence, too much time. The program space is discrete. The concept of small changes is not defined for the program. Any change affects correctness and non-functional properties, such as runtime. The proximity of programs abstract syntax trees does not mean the proximity of program behavior (execution traces). This means that for each program, the proof of correctness will be as unique as the program itself. It must therefore be generated and maintained in parallel with the development and maintenance of the program. Programs have a dual nature. They not only serve as instructions for computers, but also record knowledge in certain subject areas. Therefore, in order to process and, in particular, transform and/or correct programs, it is necessary to have both programming and subject knowledge. Thus, with the deployed program, because of its complexity and the algorithmic insolubility of its inherent problems, nothing can be done from the outside — it remains only to perform, trusting it (or rather — its authors). Only the program itself knows its semantics and can take care of itself. The article attempts to highlight promising ideas and approaches, as well as directions for further research and development.