AI prompt generation system, source code generation system, and AI prompt generation method

Abstract

When using generative AI to refactor source code, it is important to appropriately determine which parts to refactor. [Solution] The AI ​​prompt generation system 1 manages basic constraint information 4D regarding metrics that the source code of the functions constituting the software module must satisfy. Then, based on the number of times the execution path is passed in the execution trace result 2D, which records the time-series execution order of the functions when the software module is executed, it creates a priority function list 13a of functions that should be refactored first. Then, it creates constraint information 14a indicating a method for dividing the source code to satisfy the basic constraint information 4D for the functions included in the priority function list 13a, and generates a prompt 15a for the AI ​​to generate the refactored source code based on the constraint information 14a.

Description

Technical Field

[0001] The present invention relates to a generative AI prompt generation system, a source code generation system, and a generative AI prompt generation method.

Background Art

[0002] In software development, there is a process called refactoring to improve source code without changing the behavior of the program. Refactoring has the merit of improving the maintainability of the source code and enhancing the development and maintenance efficiency of the program.

[0003] In such refactoring, it is necessary to appropriately determine the refactoring target. In this regard, for example, Patent Documents 1 and 2 disclose techniques for determining an application (microservice) to be refactored from a monolithic application based on the analysis result of the source code.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] Here, in recent years, generative AI (Artificial Intelligence) has been spreading. By using generative AI, many source code refactorings can be efficiently implemented with a small amount of man-hours.

[0006] However, the amount of effort required to test the refactored code increases significantly depending on the amount of source code refactored. In other words, refactoring a large amount of source code using generative AI will increase the effort required for program testing. Therefore, when refactoring source code using generative AI, it was necessary to appropriately determine the refactoring targets in order to suppress the effort required for program testing.

[0007] This invention has been made in consideration of the above circumstances, and aims to appropriately determine the target of refactoring when performing source code refactoring using a generation AI. [Means for solving the problem]

[0008] To achieve the above objective, the present invention, in one aspect, provides a generation AI prompt generation system for generating prompts to instruct a generation AI (Artificial Intelligence) to refactor a software module included in a project under development, wherein the generation AI prompt generation system comprises a processor and memory, and the processor manages constraint basic information including threshold values ​​for metrics of the source code that each component unit constituting the software module should satisfy, identifies common paths based on the number of times the execution path is traversed in the execution trace result which records the time-series execution order of the component units when the software module is executed, extracts a list of the component units included in the common path to create list information, measures the metrics of the component units included in the list information, creates a priority list of the component units for which refactoring will be performed preferentially based on the measured metrics and the constraint basic information, creates constraint information indicating a division method for dividing the source code of the component units included in the priority list so that the metrics of the source code of the component units satisfy the constraint basic information, and generates the prompt based on the constraint information. [Effects of the Invention]

[0009] According to the present invention, for example, when performing source code refactoring using a generation AI, it is possible to appropriately determine the target of refactoring. [Brief explanation of the drawing]

[0010] [Figure 1] A block diagram showing the configuration of a source code generation system including a generation AI prompt generation system according to Embodiment 1. [Figure 2] A figure showing the metrics measurement results according to Embodiment 1. [Figure 3] A diagram showing the execution trace results according to Embodiment 1. [Figure 4] A diagram showing the common path according to Embodiment 1. [Figure 5] A diagram showing a list of functions on the common path according to Embodiment 1. [Figure 6A] A diagram showing the test effort budget for Embodiment 1. [Figure 6B] A diagram showing the test man-hours related to Embodiment 1. [Figure 7] A diagram showing the basic constraint information related to Embodiment 1. [Figure 8] A diagram showing the priority function list according to Embodiment 1. [Figure 9] A diagram showing constraint information related to Embodiment 1. [Figure 10] A diagram showing a prompt template according to Embodiment 1. [Figure 11] A diagram showing the prompt according to Embodiment 1. [Figure 12] A flowchart illustrating the process for creating a priority function list according to Embodiment 1. [Figure 13] A flowchart illustrating the constraint information creation process according to Embodiment 1. [Figure 14] A flowchart illustrating the prompt creation process according to Embodiment 1. [Figure 15] A diagram showing a list of functions on the common path according to Embodiment 2. [Figure 16] A diagram illustrating computer hardware.

Embodiments for Carrying Out the Invention

[0011] Hereinafter, embodiments of the present invention will be described based on the drawings.

[0012] [Embodiment 1] (Configuration of Source Code Generation System S According to Embodiment 1) FIG. 1 is a block diagram showing the configuration of a source code generation system S including a generation AI prompt generation system 1 according to Embodiment 1. The source code generation system S has a generation AI prompt generation system 1 and a source code generation unit 16.

[0013] The source code generation unit 16 is a generation AI (Artificial Intelligence), and based on the input prompt 15a, generates and outputs source code 6D that has undergone refactoring. The generation AI prompt generation system 1 re-acquires the source code 6D as source code 1D.

[0014] The source code generation unit 16 may be arranged in a remote server connected to the generation AI prompt generation system 1 via a network. Or the source code generation unit 16 may be arranged in a local server connected to the generation AI prompt generation system 1 or the generation AI prompt generation system 1.

[0015] The source code 6D output by the source code generation unit 16 is tested by the test execution device 2. Through the test execution of the test execution device 2, the actual test man-hours 7D are obtained. The actual test man-hours 7D are reflected in the test man-hours 3D2 of the test information 3D or are used as the basis for calculating the test man-hour budget 3D1.

[0016] The generation AI prompt generation system 1 has a metrics measurement unit 11, a function extraction unit 12, a priority function determination unit 13, a constraint information calculation unit 14, and a prompt generation unit 15.

[0017] The metrics measurement unit 11 takes source code 1D as input, measures the metrics (metric values) of each source code 1D of the program provided, for example as a function, and outputs the metrics measurement results 11a. A single project contains multiple software modules. Each software module contains multiple functions. In this embodiment, a function is an example of a constituent unit that makes up a software module and is the unit of source code creation. However, the constituent unit is not limited to a function.

[0018] Figure 2 shows the metric measurement results 11a according to Embodiment 1. The metrics measured include the number of lines, words, word types, and function references of the source code 1D, as shown in Figure 2. In the example in Figure 2, function A has 200 lines, 1000 words, 100 word types, and 20 function references.

[0019] Returning to the explanation of Figure 1, the function extraction unit 12 takes the execution trace result 2D, which records the chronological execution order of functions when the software module included in the project under development is executed, as input. The function extraction unit 12 then identifies the common path Path, which is the path with the most executions (for example, the path with the highest number of traversals) on the execution paths (representing the execution order of functions) executed in various use cases. The function extraction unit 12 then extracts the functions on the common path Path as functions with high refactoring priority. The function extraction unit 12 then outputs a list of functions 12a on the common path Path. The list of functions 12a on the common path Path is an example of "list information".

[0020] Figure 3 shows the execution trace result 2D according to Embodiment 1. Figure 4 shows the common path Path according to Embodiment 1. Figure 5 shows the function list 12a on the common path Path according to Embodiment 1. The execution trace result 2D is the chronological execution history of each function when a software module included in the project under development is executed. The common path Path, as shown in Figure 4, is a path that corresponds to the call relationship with the most calls among the hierarchical call relationships extracted by the analysis of the execution trace result 2D. In other words, the common path Path is a typical path that is traversed the most times among the execution paths of the execution trace result 2D executed in various use cases. The function list 12a on the common path Path is a list of functions that exist on the common path Path with a high number of executions.

[0021] Returning to the explanation of Figure 1, the priority function determination unit 13 takes test information 3D as input and determines the upper limit of the number of entries in the priority function list 13a. Test information 3D includes the test effort budget 3D1 that can be allocated to test effort and the estimated or actual test effort 3D2. In other words, the priority function determination unit 13 sets the number of priority functions to be refactored within the range of the test effort budget 3D1 or the test information 3D. That is, the upper limit of functions to be included in the priority function list 13a (priority list) is determined based on the budget for the effort required to perform program tests on the functions modified by refactoring.

[0022] Figure 6A shows the test effort budget 3D1 according to Embodiment 1. The test effort budget 3D1 manages the effort budget (hours) for each project, the effort budget (hours) for each module included in each project, and the effort budget (hours) for each function included in each module.

[0023] Figure 6B is a diagram showing the test effort 3D2 according to Embodiment 1. The test effort 3D2 stores the estimated or actual test effort. The test effort 3D2 manages the effort (estimated or actual) (hours) for each project, the effort (estimated or actual) (hours) for each module included in each project, and the effort (estimated or actual) (hours) for each function included in each module.

[0024] Returning to the explanation of Figure 1, the priority function determination unit 13 takes the metrics measurement results 11a, the list of functions on the common path Path 12a, and the constraint basic information 4D as input, extracts the priority functions to be refactored, and outputs the priority function list 13a. The priority functions are those functions included in the list of functions on the common path Path 12a that have metrics that do not satisfy the thresholds defined in the constraint basic information 4D.

[0025] Figure 7 shows the constraint basic information 4D related to Embodiment 1. The constraint basic information 4D indicates the conditions that the measurement results of the function metrics (Figure 2) must satisfy. In the example in Figure 7, the threshold for the number of function rows is "1000", the threshold for the number of words is "3000", the threshold for the number of word types is "2000", and the threshold for the number of function references is "60". When any metric exceeds the threshold, the corresponding function is split so that the metrics fall below the threshold, as described later.

[0026] The thresholds for the number of lines, words, word types, and function references of each function may be any value less than the threshold. However, they are not limited to arbitrary values. That is, the thresholds for the number of lines, words, word types, and function references of each function may be a second value based on the ratio of functions defined to the size of the entire project or software module being developed. The thresholds for the number of lines, words, word types, and function references of each function may also be a third value based on statistical values ​​(mean, median, mode, etc.) based on the statistics of the number of lines, words, and word types of each function in other projects or software modules used as reference. The thresholds for the number of lines, words, and word types of each function may also be a fourth value based on a specific indicator representing the maintainability of the source code (e.g., MI (Maintainability Index)). The threshold for the number of function references of each function may also be a fifth value based on the test time for each function. The thresholds for the number of lines, words, word types, and function references of each function are determined based on at least one of the first through fifth values.

[0027] Furthermore, the thresholds for the number of lines, words, word types, and function references of each function may be calculated periodically or dynamically during refactoring by the processor of the AI ​​prompt generation system 1. That is, the processor of the AI ​​prompt generation system 1 determines the thresholds for the number of lines, words, word types, and function references of each function based on one or more of the following: the ratio of metrics of each component unit defined to the size of the entire project or software module, statistical values ​​based on the statistics of metrics of each component unit of other projects or software modules, specific indicators representing the maintainability of the source code, and the test time for each component unit.

[0028] Figure 8 shows the priority function list 13a according to Embodiment 1. The priority function list 13a lists the priority functions extracted from the function list 12a on the common path Path.

[0029] Returning to the explanation of Figure 1, the constraint information calculation unit 14 takes the metrics measurement results 11a, the priority function list 13a, and the constraint basic information 4D as input. The constraint information calculation unit 14 then divides the functions listed in the priority function list 13a in the metrics measurement results 11a so as to satisfy the constraint basic information 4D, and outputs the constraint information 14a.

[0030] Figure 9 shows the constraint information 14a according to Embodiment 1. The constraint information 14a is based on the metrics measurement result 11a (Figure 2). However, compared to the metrics measurement result 11a, the number of words in the constraint information 14a is "5000", which is above the threshold, so function B is divided into three functions: functions B-1, B-2, and B-3. As a result, the metrics of functions B-1, B-2, and B-3 are below the threshold. Also, compared to the metrics measurement result 11a, the number of function references in the constraint information 14a is "60", which is above the threshold, so function D is divided into two functions: functions D-1 and D-2. As a result, the metrics of functions D-1 and D-2 are below the threshold.

[0031] Figure 9 shows an example of splitting function B into three functions and function D into two functions, but the number of splits and the splitting method are not limited to those shown in Figure 9. There is no priority order for the metrics used to determine the threshold for splitting a function. Therefore, if a function is split so that a certain metric falls below the threshold, and other metrics still exceed the threshold, the split function will be further split so that the other metrics also fall below the threshold. In other words, the series of processes of determining the common path, extracting the function list 12a on the common path, measuring the function metrics, creating the priority function list 13a, creating constraint information 14a, and generating the prompt 15a are repeated for all metrics included in the constraint basic information 4D until the constraint basic information 4D is satisfied.

[0032] Returning to the explanation of Figure 1, the prompt generation unit 15 takes the constraint information 14a and the prompt template 5D as input, substitutes the function decomposition method shown in the constraint information 14a into the prompt template 5D, and generates a prompt 15a to cause the generation AI to create the source code of the decomposed function.

[0033] Figure 10 shows a prompt template 5D according to Embodiment 1. Prompt template 5D has an instruction part 4D1 and a condition part 4D2. Instruction part 4D1 contains an instruction to create source code for a refactored function, where the function to be refactored (in this embodiment, splitting a function) and the refactored function are represented by variables, such as "#Instruction Create source code for function Xi (i=1,2,···) based on function X and #condition."

[0034] Condition part 4D2 contains a function splitting instruction that expresses the function to be refactored (function splitting in this embodiment) and the refactored function as variables, such as "#Condition Split function X according to the value of function Xi (i=1,2,···) in constraint information 14a".

[0035] Figure 11 shows a prompt 15a according to Embodiment 1. In the prompt 15a shown in Figure 11, function B is substituted for function X in the prompt template 5D shown in Figure 10, and functions B-1, B-2, and B-3 are substituted for functions X-1, X-2, and X-3. The prompt 15a shown in Figure 11 is a prompt that splits function B into functions B-1, B-2, and B-3 and creates their source code, but prompts that split function D into functions D-1 and D-2 and create their source code are created in the same way.

[0036] (Process for creating a priority function list related to Embodiment 1) Figure 12 is a flowchart showing the process for creating a priority function list according to Embodiment 1. The priority function list creation process is executed in response to instructions from the user of the AI ​​prompt generation system 1.

[0037] First, in step S11, the priority function determination unit 13 determines the upper limit of the number of entries in the priority function list 13a from the test effort budget 3D1. In other words, the number of priority functions to be refactored is limited to the range of the test information 3D.

[0038] Next, in step S12, the function extraction unit 12 refers to the execution trace result 2D, lists the functions on the common path Path, and creates a list of functions on the common path Path 12a.

[0039] Next, in step S13, the priority function determination unit 13 selects one function from the list of priority functions 13a and obtains the metrics of the selected function from the metrics measurement results 11a. Next, in step S14, the priority function determination unit 13 compares the metrics measurement results 11a with the constraint basic information 4D and determines whether the metrics of the target function are above a threshold. If the metrics of the target function are above a threshold (step S14 YES), the priority function determination unit 13 moves to step S15, and if they are below a threshold (step S14 NO), it moves to step S17.

[0040] In step S14, if the metric is above the threshold, the function is determined to be subject to refactoring, and if the metric is below the threshold, the function is determined not to be subject to refactoring. However, this is not the only way; the function may also be determined to be subject to refactoring if the metric exceeds the threshold, and not to be subject to refactoring if the metric is below the threshold.

[0041] In step S15, the priority function determination unit 13 adds the functions whose metrics are above the threshold in step S14 to the priority function list 13a. Next, in step S16, the priority function determination unit 13 determines whether the number of functions registered in the priority function list 13a has reached the upper limit of the number of entries determined in step S11. If the number of functions registered in the priority function list 13a has reached the upper limit of the number of entries (step S16 YES), the priority function determination unit 13 terminates the priority function list creation process. On the other hand, if the number of functions registered in the priority function list 13a has not reached the upper limit of the number of entries (step S16 NO), the priority function determination unit 13 moves the process to step S17.

[0042] In step S17, the priority function determination unit 13 determines whether the termination condition for the priority function list creation process is met. The termination condition for the priority function list creation process is, for example, that the processes in steps S13 to S15 have been executed for all functions listed in the function list 12a on the common path Path in step S12. The priority function determination unit 13 terminates the priority function list creation process if the termination condition for the priority function list creation process is met (step S17 YES). On the other hand, if the termination condition for the priority function list creation process is not met (step S17 NO), the priority function determination unit 13 moves the process to step S13. In step S13, to which the process has been moved from step S17, the priority function determination unit 13 selects one unselected function from among the functions listed in the function list 12a on the common path Path and obtains metrics.

[0043] (Constraint information creation process related to Embodiment 1) Figure 13 is a flowchart showing the constraint information creation process according to Embodiment 1. The constraint information creation process according to Embodiment 1 is executed after the completion of the priority function list creation process (Figure 12).

[0044] First, in step S21, the constraint information calculation unit 14 creates the base for constraint information 14a based on the metric measurement results 11a. Next, in step S22, the constraint information calculation unit 14 reads one function from the priority function list 13a. Then, in step S23, it sets the metric division value for the function read in step S22 and updates the constraint information 14a with the divided function. The metric division value is determined so as to satisfy the threshold for each metric defined in the constraint basic information 4D.

[0045] Next, in step S24, the constraint information calculation unit 14 determines whether there are any unprocessed functions in the priority function list 13a that have not been executed in step S22. If there are unprocessed functions (step S24 YES), the constraint information calculation unit 14 returns to step S22. On the other hand, if all functions in the priority function list 13a have been processed (step S24 NO), the constraint information creation process is terminated.

[0046] (Prompt creation process according to Embodiment 1) Figure 14 is a flowchart showing the prompt creation process according to Embodiment 1. The prompt creation process according to Embodiment 1 is executed after the completion of the constraint information creation process (Figure 13).

[0047] First, in step S31, the prompt generation unit 15 generates a description for splitting the target function, for example, as shown in Figure 11, from the constraint information 14a and the prompt template 5D. Next, in step S32, the prompt generation unit 15 determines whether there are any unprocessed functions to be split that have not been executed in step S31, based on the constraint information 14a. If there are unprocessed functions to be split (step S32 YES), the prompt generation unit 15 returns to step S31. On the other hand, if all the functions to be split in the constraint information 14a have been processed (step S32 NO), the prompt generation unit 15 terminates the prompt creation process.

[0048] (Effects of Embodiment 1) In the above-described embodiment 1, a priority function list of functions to be refactored is created based on a list of constituent units included in a common path, which is determined by the number of times the execution path is traversed in the execution trace result that records the time-series execution order of functions. Therefore, according to embodiment 1, since the functions to be refactored are determined on an execution path basis, refactoring can be carried out effectively while suppressing the effort required for program testing after refactoring.

[0049] Furthermore, in Embodiment 1 described above, the threshold for the constraint basic information is determined based on one or more of the following: the ratio of the metrics of each function defined to the size of the entire project or software module; statistical values ​​based on the statistics of the metrics of each function in other projects or other software modules; a specific indicator representing the maintainability of the source code; and the test time for each component unit. Therefore, according to Embodiment 1, since the functions are divided through refactoring to satisfy these thresholds, a certain level of performance can be ensured for the divided functions.

[0050] Furthermore, in the above-described embodiment 1, the upper limit of functions to be included in the priority function list is determined based on the budget for the effort required to perform program tests on the functions modified by refactoring. Therefore, the burden of program testing after refactoring can be reduced from a budgetary standpoint.

[0051] Furthermore, in the above-described embodiment 1, the series of processes of determining the common path, extracting a list of functions on the common path, measuring function metrics, creating a preferred function list, creating constraint information, and obtaining prompt generation are repeated until the basic constraint information is satisfied for all metrics. Therefore, even if the basic constraint information is not satisfied for multiple metrics, the sequential processing ensures that the basic constraint information is satisfied for all metrics.

[0052] Furthermore, in the above-described embodiment 1, the source code generation unit 16 can consistently execute everything from prompt generation to source code refactoring.

[0053] [Embodiment 2] In Embodiment 1, when extracting common paths, the path with the highest number of passthroughs is selected. However, this is not the only option; in Embodiment 2, the number of passthroughs is recorded, and a priority function list 13a is created based on the top N paths (where N is a natural number greater than or equal to 2) or paths whose passthrough count exceeds a threshold.

[0054] In the following description of Embodiment 2, we will focus on the differences from Embodiment 1 and omit redundant explanations.

[0055] The AI ​​prompt generation system 1 according to Embodiment 2 has a function list 12aB on the common path Path instead of the function list 12a on the common path Path according to Embodiment 1.

[0056] (List of functions on the common path Path according to Embodiment 2 12aB) Figure 15 shows a list of functions 12aB on the common path Path according to Embodiment 2. The list of functions 12aB on the common path Path manages combinations of functions, including their execution order in the execution trace results 2D of the software modules included in the project under development, as "function names," and records the number of times each combination is traversed.

[0057] In the above-described embodiment 2, among the execution paths, multiple execution paths with the highest number of passes, or execution paths with a number of passes equal to or greater than a threshold, are determined as common paths. Therefore, as much function refactoring as possible can be carried out within the constraints of testing effort and budget.

[0058] (Hardware configuration of Computer 1000) Figure 16 shows an example of the hardware configuration of computer 1000. Computer 1000 implements the respective parts of the AI ​​prompt generation system 1 and the source code generation system S by executing a predetermined program.

[0059] The computer 1000 comprises a processor 1001 including a CPU, a main memory 1002, an auxiliary memory 1003, a network interface 1004, an input device 1005, and an output device 1006, all interconnected via an internal communication line 1007 such as a bus.

[0060] The processor 1001 controls the operation of the entire computer 1000. The main memory 1002 is composed of, for example, volatile semiconductor memory and is used as the work memory of the processor 1001. The auxiliary storage device 1003 is composed of a large-capacity non-volatile storage device such as a hard disk drive, SSD (Solid State Drive), or flash memory and is used to retain various programs and data for a certain period of time.

[0061] The executable program 1003a stored in the auxiliary storage device 1003 is loaded into the main memory device 1002 when the computer 1000 starts up or when needed, and is executed by the processor 1001.

[0062] The executable program 1003a may be recorded on a non-temporary recording medium, read from the non-temporary recording medium by a media reader, and loaded into the main memory 1002. Alternatively, the executable program 1003a may be obtained from an external computer via a network and loaded into the main memory 1002.

[0063] The auxiliary storage device 1003 stores various executable programs 1003a.

[0064] The network interface 1004 is an interface device for connecting computer 1000 to various networks within the system or for communicating with other computers. The network interface 1004 consists of, for example, a NIC (Network Interface Card) such as a wired LAN (Local Area Network) or a wireless LAN.

[0065] The input device 1005 consists of a keyboard, a pointing device such as a mouse, and is used by the user to input various instructions and information into the computer 1000. The output device 1006 consists of a display device such as a liquid crystal display or an organic EL (Electro-Luminescence) display, or an audio output device such as a speaker, and is used to present necessary information to the user when needed.

[0066] It should be noted that the present invention is not limited to the embodiments described above, and includes a variety of embodiments. For example, the embodiments described above are described in detail for the purpose of clearly illustrating the present invention, and are not necessarily limited to those having all the configurations described. Furthermore, it is possible to replace some of the configurations of one embodiment with the configurations of another embodiment, or to add the configurations of another embodiment to the configuration of one embodiment. In other words, it is possible to delete or add / substitute the configurations of each embodiment with other configurations. [Explanation of symbols]

[0067] S: Source code generation system, 1: Generation AI prompt generation system, 1D: Source code, 2D: Execution trace results, 3D1: Test effort budget, 4D: Constraint basic information, 6D: Source code, 11a: Metric measurement results, 12a, 12aB: List of functions on the common path, 13a: Preferred function list, 14a: Constraint information, 15a: Prompt, 1000: Computer, 1001: Processor, 1002: Main memory, Path: Common path

Claims

1. A generative AI prompt generation system that generates prompts to instruct a generative AI (Artificial Intelligence) to refactor software modules included in a project under development, The AI ​​prompt generation system has a processor and memory, The aforementioned processor, The software module manages basic constraint information, including threshold values ​​for the metrics that the source code of each constituent unit must satisfy. When the aforementioned software module is executed, a common path is identified based on the number of times the execution path is traversed in the execution trace result, which records the time-series execution order of the constituent units. Extract a list of the constituent units included in the common path and create list information. The metrics of the constituent units included in the aforementioned list information are measured, Based on the measured metrics and the constraint basic information, a priority list of the component units for which the refactoring will be performed first is created. For the component units included in the priority list, constraint information is created that indicates a method for dividing the source code such that the metrics of the source code of the component unit satisfy the constraint basic information. The prompt is generated based on the constraint information. A generation AI prompt generation system characterized by the following:

2. A generation AI prompt generation system according to claim 1, The aforementioned processor, The threshold is determined based on one or more of the following: the ratio of the metrics of each component unit defined relative to the overall size of the project or the software module; statistical values ​​based on the metrics statistics of each component unit of other projects or other software modules; a specific indicator representing the maintainability of the source code; and the test time for each component unit. A generation AI prompt generation system characterized by the following:

3. A generation AI prompt generation system according to claim 1, The aforementioned processor, The upper limit of the components to be included in the priority list is determined based on the budget for the effort required to perform program tests on the components modified by the refactoring. A generation AI prompt generation system characterized by the following:

4. A generation AI prompt generation system according to claim 1, The aforementioned processor, The series of processes—determining the common path, extracting the list of constituent units, measuring metrics for the constituent units, creating the priority list, creating the constraint information, and generating prompts—is repeated for all metrics until the basic constraint information is satisfied. A generation AI prompt generation system characterized by the following:

5. A generation AI prompt generation system according to claim 1, The aforementioned processor, Among the execution paths, the multiple execution paths with the highest number of passes, or the execution paths whose number of passes is equal to or greater than the threshold, are determined to be the common path. A generation AI prompt generation system characterized by the following:

6. The generation AI prompt generation system according to claim 1, The generating AI generates and outputs source code that has undergone the refactoring based on the prompt, and A source code generation system characterized by having the following features.

7. A method for generating an AI prompt, which is executed by a generation AI prompt generation system, for generating prompts to instruct a generation AI (Artificial Intelligence) to refactor software modules included in a project under development, The AI ​​prompt generation system has a processor and memory, The aforementioned processor, The software module manages basic constraint information, including threshold values ​​for the metrics that the source code of each constituent unit must satisfy. When the aforementioned software module is executed, a common path is identified based on the number of times the execution path is traversed in the execution trace result, which records the time-series execution order of the constituent units. Extract a list of the constituent units included in the common path and create list information. The metrics of the constituent units included in the aforementioned list information are measured, Based on the measured metrics and the constraint basic information, a priority list of the component units for which the refactoring will be performed first is created. For the component units included in the priority list, constraint information is created that indicates a method for dividing the source code such that the metrics of the source code of the component unit satisfy the constraint basic information. The prompt is generated based on the constraint information. A method for generating AI prompts, characterized by having each of the following processes.

Images