A code development method and a code development system

Abstract

This disclosure provides a code development method and system, relating to the field of computer technology, and particularly to the field of artificial intelligence technology. The specific implementation scheme includes: obtaining development requirement information and establishing code development tasks; executing the code development tasks, including: calling a first coding agent to generate execution planning information based on the development requirement information; calling a second coding agent to generate code based on the development requirement information and execution planning information, and submitting the code for review; in response to a review rejection, obtaining review feedback information for the code, calling the second coding agent to optimize the code based on the development requirement information, execution planning information, and review feedback information, and submitting the optimized code for review until the review result indicates approval. This disclosure automates code development, improves development efficiency, and possesses continuous code optimization capabilities, effectively improving code quality.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to code development methods and systems in the field of artificial intelligence technology. Background Technology

[0002] Code development, also known as software development or program development, aims to write code to accomplish predetermined functions. Currently, code development primarily relies on traditional manual coding methods. However, the rapid iteration pace, large-scale interactive pressures, and complex technology stacks inherent in the internet industry create a strong contradiction with the efficiency, cost, and quality bottlenecks of traditional manual coding. Therefore, there is an urgent need for automated code development technologies that can reduce labor costs and improve development efficiency. Summary of the Invention

[0003] This disclosure provides a code development method, system, electronic device, non-transitory computer-readable storage medium, and computer program product to improve development efficiency.

[0004] According to one aspect of this disclosure, a code development method is provided, the method comprising: Obtain development requirements information and create code development tasks; The code development task includes: invoking a first coding agent to generate execution plan information based on the development requirement information; invoking a second coding agent to generate code based on the development requirement information and the execution plan information, and submitting the code for review; in response to the review result indicating a rejection, obtaining review feedback information for the code, invoking the second coding agent to optimize the code based on the development requirement information, the execution plan information, and the review feedback information for the code, and submitting the optimized code for review until the review result is a pass.

[0005] According to another aspect of this disclosure, a code development system is provided, the code development system including a task management module, an executor module, a first coding agent, and a second coding agent; The task management module is configured to obtain development requirement information; The task management module is configured to create code development tasks based on the development requirements information; The executor module is configured to execute the code development task, which includes: invoking a first coding agent to generate execution plan information based on the development requirement information; invoking a second coding agent to generate code based on the development requirement information and the execution plan information, and submitting the code for review; in response to the review result indicating a rejection, obtaining review feedback information for the code, invoking the second coding agent to optimize the code based on the development requirement information, the execution plan information, and the review feedback information for the code, and submitting the optimized code for review, until the review result is a pass.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which enables the at least one processor to execute the above-described code development method.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to execute the above-described code development method.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described code development method.

[0009] As can be seen from the above technical solutions, this disclosure generates execution planning information by calling a first coding agent, generates code by calling a second coding agent, submits the code for review, and can automatically optimize the code based on the review feedback when the review is rejected, until the review is passed. This disclosure adopts an iterative end-to-end development process, realizing full automation from requirements understanding to code submission, which improves development efficiency compared to traditional development methods that rely on manual coding and providing code snippet-level suggestions.

[0010] In addition, this disclosure constructs a closed loop for code quality optimization driven by external review feedback. When the code review result is a rejection, the review feedback information is used as a new round of input for the second coding agent to optimize the code. This enables the automated code development process to have continuous code optimization capabilities, thereby effectively improving code quality.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure.

[0013] Figure 1 This is an exemplary system architecture diagram to which embodiments of this disclosure can be applied.

[0014] Figure 2 A schematic flowchart illustrating the code development method provided in this embodiment of the disclosure.

[0015] Figure 3 A flowchart illustrating the various stages of execution of the actuator module provided in the embodiments of this disclosure.

[0016] Figure 4 This is a schematic diagram of state transitions provided for an embodiment of this disclosure.

[0017] Figure 5 A schematic flowchart illustrating the execution of a scheduler instance provided in an embodiment of this disclosure.

[0018] Figure 6 This is a schematic diagram of a session management process provided in an embodiment of this disclosure.

[0019] Figure 7 A schematic block diagram of a code development system provided in an embodiment of this disclosure.

[0020] Figure 8 This is a block diagram of an electronic device used to implement the code development method of the embodiments of this disclosure. Detailed Implementation

[0021] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0022] Traditional code development mainly includes two approaches: One approach relies on developers manually writing code, supplemented by intelligent code completion from the integrated development environment (IDE). This method is obviously labor-intensive and inefficient.

[0023] Another approach is to use intelligent programming assistants to generate local code suggestions based on code context or comments. While this method reduces manual costs to some extent, it only focuses on specific parts of the development process, providing fragment-level suggestions. A significant amount of work still requires manual execution and cannot achieve automated code generation.

[0024] In view of this, this disclosure provides a completely new approach. To facilitate understanding of the embodiments of this disclosure, the system architecture on which this disclosure is based will first be described. Figure 1 Exemplary system architectures that can be applied to embodiments of this disclosure are shown, such as Figure 1 As shown, the system architecture may include: a user-side and a code development system (or software development system / program development system, etc.) set up on the server side.

[0025] The server side and the client side are the two main components of an application service. The server side uses a server as its primary hardware infrastructure and may include one or more software service modules. The server side and the client side form a collaborative front-end and back-end.

[0026] The client can be set on the terminal device. In this embodiment of the disclosure, the client can be a local application, a mini-program, or a web application running through a browser on the terminal device.

[0027] A server can be a single server, a server cluster consisting of multiple servers, or a cloud server. A cloud server, also known as a cloud computing server or cloud host, is a hosting product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Servers (VPS) services, such as high management difficulty and weak service scalability.

[0028] In this embodiment of the disclosure, the user client can submit development requirement information input by the user to the server-side code development system. The code development system automatically generates code based on the development requirement information using the method provided in this embodiment. In this embodiment, the code development system may involve access to remote storage space, rule databases, code repositories, etc., and may also involve invoking coding agents.

[0029] It should be understood that Figure 1 The number of client applications, code development systems, remote storage spaces, rule databases, code repositories, and coding agents shown is merely illustrative. Depending on implementation needs, any number of client applications, code development systems, remote storage spaces, rule databases, code repositories, and coding agents can be included.

[0030] Figure 2This is a schematic flowchart illustrating a code development method provided in an embodiment of this disclosure. The method can be developed by... Figure 1 The code development system in the system shown executes, such as Figure 2 As shown, the method may include the following steps: Step 201: Obtain development requirements information and create code development tasks.

[0031] Step 202: Execute code development tasks, which include: calling the first coding agent to generate execution plan information based on development requirements information; calling the second coding agent to generate code based on development requirements information and execution plan information, and submitting the code for review; responding to the review result indicating review rejection, obtaining review feedback information for the code, calling the second coding agent to optimize the code based on development requirements information, execution plan information, and review feedback information for the code, and submitting the optimized code for review until the review result is approval.

[0032] As can be seen, this disclosure generates execution planning information by calling a first coding agent, generates code by calling a second coding agent, submits the code for review, and can automatically optimize the code based on the review feedback when the review is rejected, until the review is passed. This disclosure adopts an iterative end-to-end development process, realizing full automation from requirements understanding to code submission, which improves development efficiency compared to traditional development methods that rely on manual coding and providing code snippet-level suggestions.

[0033] In addition, this disclosure constructs a closed loop for code quality optimization driven by external review feedback. When the code review result is a rejection, the review feedback information is used as a new round of input for the second coding agent to optimize the code. This enables the automated code development process to have continuous code optimization capabilities, thereby effectively improving code quality.

[0034] The following describes in detail each step of the above process and the effects that can be further produced, with reference to the embodiments. It should be noted that the terms "first," "second," etc., used in this disclosure do not have limitations on size, order, or quantity, and are only used to distinguish them by name. For example, "first executor instance" and "second executor instance" are only used to distinguish two executor instances by name. Similarly, "first subtask" and "second subtask" are only used to distinguish two subtasks at different stages of the same code development task by name.

[0035] First, the above step 201, namely "obtaining development requirement information and establishing code development tasks", will be described in detail with reference to the embodiments.

[0036] The code development process involved in this embodiment may include multiple stages, such as the task creation stage, initialization stage, planning stage, and code writing stage. This step is the first stage in the code development process, namely the task creation stage. After the user inputs development requirement information and triggers the task creation request for the code development task, the task creation stage begins. The task creation stage is the starting point of the code development task lifecycle, obtaining development requirement information from the task creation request and creating the task object of the code development task.

[0037] The user management module in the code development system is responsible for user authentication, access control, and key management. It supports user role definition (e.g., regular users, product line administrators, super administrators, etc.) and product line access control, and provides encrypted storage and secure access mechanisms. Users can access the code development system according to their predefined roles after being authenticated and authorized by the user management module.

[0038] The product line management module in the code development system is responsible for managing product line information, including the product line's name, description, owner, associated code repository, and corresponding requirement space. It supports operations such as creating, updating, deleting, and querying product lines.

[0039] The requirements management module in the code development system receives and manages development requirements. Development requirement information can include things like product line, requirement description, and technical attributes. The requirement description includes things like user scenarios, functional goals, acceptance criteria, and functional dependencies. Technical attributes can include things like target code repository, target branch, and deployment environment type, and the system transforms requirements into structured task objects.

[0040] When creating task objects, unstructured development requirements information can be transformed into structured task objects, providing a unified data input for subsequent processes. The created task objects not only contain development requirements information but also other metadata required for execution, such as the task ID, product line identifier, and owner information for the code development task.

[0041] After creating the task object, perform validation, such as validating necessary information: task identifier, task name, code repository address, owner information, workspace path, environment type, etc.

[0042] The following focuses on a detailed description of step 202, namely "execute code development task", with reference to the embodiments.

[0043] In this embodiment, the code development task can be executed by the executor module in the code development system. It mainly includes the following stages: Initialization phase: During the initialization phase, such as Figure 3 As shown, it may include: Step 301: Initialize the workspace based on the task information.

[0044] For example, create a dedicated, isolated workspace directory based on the workspace path and task identifier of the task object to avoid conflicts between the code or configuration of different tasks.

[0045] Step 302: In this workspace directory, clone the remote code repository and switch to the target branch. This step ensures that code development tasks are based on the correct code baseline.

[0046] Step 303: Prepare the coding environment.

[0047] This means that based on the dependency configuration files in the code repository, the necessary dependency packages for code development are installed, environment variables are configured, and environment availability is verified, thereby ensuring that developers can directly code or debug.

[0048] Planning and formulation stage: During the planning and formulation phase, such as Figure 3 As shown, it may include: Step 311: Invoke the first coded intelligent agent to generate execution plan information based on development requirements information.

[0049] The term "coding agent" as used in this disclosure refers to an intelligent coding agent built on a large language model, capable of understanding development requirements and generating execution rules or code. Its core function is to understand and execute coding-related processing logic.

[0050] The first coding agent can construct a first prompt, which includes at least development requirement information and may also include parameters such as working directory and permission mode. This first prompt can be quickly constructed by filling the development requirement information into a planning prompt template. The first coding agent then interacts with the large language model using a command-line interface to prompt the large language model to generate execution planning information based on the development requirement information.

[0051] In this disclosure, "execution planning information" refers to a scheme description document generated by the first coding agent based on development requirement information, outlining how to implement the requirement. It does not contain specific execution code, but rather a plan for code writing. For example, it can be a text document containing some or all of the following types of content: requirements analysis, technology selection recommendations, module design, implementation steps, potential risks, and dependency descriptions.

[0052] Step 312: Send the execution plan information to the user terminal.

[0053] In some cases, the execution plan information generated by the first coding agent may not meet the user's actual needs. To prevent subsequent code generation from deviating from the user's actual needs, the generated execution plan information can be sent to the user's client. The user's client displays the execution plan notification on the development interface. This notification may include the execution plan information, a confirmation component, and a rejection component. If the user (e.g., a developer) is satisfied with the execution plan information, they can trigger the confirmation component. In response to triggering the confirmation component, the user's client returns a confirmation message for the execution plan information to the server. If the user is not satisfied with the execution plan information, they can trigger the rejection component and further input at least one of the rejection reason and modification suggestions. In response to triggering the rejection component, the user's client obtains at least one of the rejection reason and modification suggestions input through the rejection component and returns at least one of the rejection reason and modification suggestions to the server.

[0054] Step 313: In response to the feedback result being a rejection, obtain at least one of the rejection reason and modification suggestions, call the first coded agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestions and the development requirement information, and proceed to step 312.

[0055] In this embodiment, the session content generated by calling the first coded agent is stored in a local session file, which is stored in correspondence with the task identifier of the code development task. This way, even if the code development task is interrupted, the previous dialogue content can be recovered promptly based on the session file to obtain the context and continue processing the code development task, avoiding duplication of work and context loss.

[0056] The above process cleverly incorporates human confirmation points into the automated code development process, forming a rapid feedback loop to ensure that subsequent code writing is carried out under user authorization and clear planning guidance, thereby enhancing the consistency between the final code output and the user's intent regarding development requirements. Once the user confirms the execution plan information, the process moves to the code writing stage.

[0057] Code writing phase: During the planning and formulation phase, such as Figure 3 As shown, it may include: Step 321: Invoke the second coding agent to generate code based on development requirements information and execution plan information, and submit the code for review.

[0058] It should be noted that the first coded agent and the second coded agent involved in the embodiments of this disclosure can be the same coded agent or different coded agents.

[0059] The second coding agent can construct a second prompt, which includes at least development requirements and confirmed execution plan information, and may also include parameters such as working directory and permission mode. This second prompt can be quickly constructed by filling the development requirements and execution plan information into a coding prompt template. The second coding agent then interacts with the large language model via a command-line interface using the constructed second prompt, prompting the large language model to generate code based on the development requirements and execution plan information.

[0060] Once the code is generated, the system automatically performs a "commit for review" operation. This is typically an automated version control (Git) workflow, which may include: 1) detecting code changes in the workspace relative to the initial clone state; 2) executing commands such as `git add` to stage valid code changes; 3) generating a commit message; 4) executing commands such as `git commit` to solidify the code version; 5) executing commands such as `git push` to push the commit message to the task branch of the remote repository; 6) calling the code review platform's API, creating a merge request or pull request based on the push to submit the code for review, and obtaining the URL of the review interface for developers to view, annotate, or process.

[0061] Step 322: Obtain the review result. If the review is rejected, proceed to step 323; if the review is approved, end the process.

[0062] Step 323: Obtain the review feedback information for the code, call the second coding agent to optimize the code based on the development requirements information, execution planning information and the review feedback information for the code, submit the optimized code for review, and proceed to step 322.

[0063] At this point, the second coding agent can construct a third prompt instruction, which includes at least development requirement information, execution planning information, and code review feedback information, and may also include parameters such as working directory and permission mode. The construction of the third prompt instruction can be quickly obtained by filling the development requirement information, execution planning information, and code review feedback information into the feedback prompt template.

[0064] Furthermore, in this embodiment, the executor module can enable different operation permissions for the coding agent at different stages to ensure system security. For example, during the planning stage, the first coding agent is restricted to read-only permissions and prohibited from performing file modification operations; during the code writing stage, file modification and execution permissions are granted to the second coding agent, allowing the second coding agent to modify existing files, generate code, and make tool calls.

[0065] In the field of code development, the reason why we can currently only use intelligent programming assistants to provide fragment-level suggestions is that, in code generation scenarios, traditional intelligent programming assistants, when utilizing large language models, provide development requirements information to the large language model through input prompts, and the large language model directly outputs code based on these requirements. However, in this approach, the large language model can only handle very simple development requirements, and it is difficult to achieve the desired results for relatively complex development requirements.

[0066] Through in-depth analysis, the inventors discovered that the root cause of the aforementioned problems lies in the fact that simply inputting all development requirements information into a large language model at once can easily lead to information overload or the neglect of critical details when the task complexity is high. Therefore, this disclosure decomposes the entire code generation capability involved in the code development task into multiple stages. Without sacrificing the powerful code generation capabilities of the coding agent, the code generation capability is decomposed into calls to the coding agent at each stage, thereby improving the controllability of the development process and the reliability of the results. To ensure that the entire process is automated, controllable, and reliable, in the embodiments of this disclosure, the executor module can adopt a multi-layer state machine model to execute the aforementioned code development task.

[0067] One possible implementation is that the executor module can acquire multi-layered state information configured for the code development task. This multi-layered state information can include information about multiple stages of code generation, the state information contained in each stage, and the transition rules between states. These multiple stages include at least the planning stage and the code writing stage, and may also include an initialization stage. In response to determining that the transition rules are met, the module executes the transition action corresponding to the current state of the current stage and then switches to the next state.

[0068] The "multi-level state information" referred to in this disclosure refers to state machine information used to define and manage code development tasks. It describes the task lifecycle through at least two levels (stages and states within stages), specifying the triggering conditions for transitions between stages, and the conditions and actions for transitioning from one state to the next within a stage. For example, it can be specifically a configuration file for a state machine, declaring which stages exist, under what conditions stage transitions occur, which states each stage contains, and under what conditions and after what actions transitions between states.

[0069] The "transition rule information" referred to in this disclosure is a logical description that connects one state to the next and specifies the triggering conditions and transition actions. It typically includes the triggering conditions, the action to be executed (which can be empty, meaning that if the triggering conditions are met, the next state can be entered without executing any action), and the target state. For example, a rule can be expressed as: when the task is in the "planning pending" state and "development requirement information has been obtained", then execute the action of "calling the first coded agent to generate the execution plan", and after completion, switch the state to "planning in progress".

[0070] The aforementioned multi-layered state information can be maintained by the task management module. The task management module provides a strict state transition verification mechanism to ensure that states can only transition according to predefined transition rules. Each state transition requires validity verification to prevent illegal state transitions. For example, during the initialization phase, the state can only transition from "Initialization" to "Initialization Completed" or "Initialization Failed," and cannot directly jump to other phases.

[0071] As one possible approach, the initialization phase can include the following states: pending initialization, initialization in progress, initialization successful, and initialization failed.

[0072] The rule-making phase can include the following states: planning pending, planning in progress, planning under confirmation, planning confirmed, and planning failure.

[0073] The code writing phase can include the following states: code to be written, code in progress, code under review, review passed, review rejected, and writing failed.

[0074] In addition to the above-mentioned stage division methods and state division methods within a stage, coarser or finer-grained stage division methods or coarser or finer-grained state division methods can also be used. This disclosure does not impose any more specific restrictions on these methods.

[0075] The executor module continuously and periodically monitors the current state of the code development task and queries the multi-level state information for transition rules applicable to the current state. When the trigger condition of a transition rule is met, the executor module executes the transition action defined by that rule. After successful execution, the current state of the code development task is switched to the target state defined in the rule, thus propelling the process to the next stage.

[0076] In this embodiment of the disclosure, at least the planning stage and the coding stage are driven by multi-layered state information. For the planning stage, the transformation actions performed include invoking a first coded agent to generate execution planning information based on development requirement information.

[0077] During the code writing phase, the conversion actions performed include calling the second coding agent to generate code based on development requirements information and the execution planning information, and submitting the code for review; and calling the second coding agent to optimize the code based on development requirements information, execution planning information and review feedback information on the code, and submitting the optimized code for review.

[0078] This mechanism enables proactive and orderly advancement of the development process, breaking down a complex end-to-end task into multiple stages including state transitions. Each state transition has clear triggering conditions, transition actions, and target states, making the entire process automatic, transparent, controllable, and traceable.

[0079] In addition, a multi-layered state information-based driver can be implemented in the initialization phase. The following example, using a driver that integrates multi-layered state information from task initialization to code writing, details the state transition process at each stage. A diagram illustrating the state transitions is shown below. Figure 4 As shown.

[0080] After creating the task object for the code development task, the initialization phase is triggered.

[0081] Upon entering the initialization phase, the system is initially in a pending initialization state. If the current state is the pending initialization state of the initialization phase, and if the initialization triggering conditions are met (e.g., receiving an event that triggers entry into initialization or the code repository being created successfully), the workspace of the code development task is initialized (i.e., a conversion action) based on the aforementioned conversion rule information, and the system switches to the initialization in progress state (i.e., the target state). In response to initialization completion, the system switches to the initialization successful state based on the conversion rule information, triggering entry into the planning and formulation phase (e.g., generating an event that triggers entry into the planning and formulation phase).

[0082] The state transition process described above in the initialization phase can automatically initialize the workspace for code development tasks, avoiding the manual costs associated with manual configuration, improving efficiency, and providing a stable, consistent, and isolated sandbox environment for subsequent phases. The entire initialization process is orderly, controllable, and traceable.

[0083] Upon entering the planning stage, the system is initially in a planning-pending state. If the executor module obtains that the current state is the planning-pending state of the planning stage and obtains development requirement information (i.e., triggering conditions), it calls the first coded intelligent agent to generate execution planning information (i.e., conversion actions) based on the development requirement information, and switches to the planning-in-progress state (i.e., the target state).

[0084] In response to the completion of execution planning information generation (i.e., triggering condition), the execution planning information is sent to the user terminal based on the conversion rule information (i.e., conversion action), switching to the planning confirmation state (i.e., target state). While the execution planning information generated by the first coding agent can be directly used for subsequent code generation, this embodiment provides a preferred method: the execution planning information generated by the first coding agent is first returned to the user terminal for confirmation or rejection, thereby avoiding deviations in subsequent coding work due to misunderstandings by the coding agent. The methods for returning the execution planning information to the user terminal may include, but are not limited to, user interface push notifications, email push notifications, instant messaging tool message push notifications, etc.

[0085] In response to the feedback confirmation of the execution planning information returned by the user (i.e., the triggering condition), based on the transformation rule information, the system switches to the planning confirmed state (i.e., the target state), triggering entry into the code writing stage (e.g., generating an event to trigger entry into code writing). The achievement of the planning confirmed state is a prerequisite for the initiation of the code writing stage, thereby triggering the transition between stages.

[0086] In response to the user's feedback result indicating rejection (i.e. triggering condition) regarding the execution planning information, based on the transformation rule information, the first coded agent is invoked to regenerate the execution planning information (i.e. transformation action) based on at least one of the rejection reasons and modification suggestions returned by the user regarding the execution planning information, as well as the development requirement information, and switches to the planning pending state (i.e. target state).

[0087] The above process automates the planning generation, feedback, confirmation, rejection, and replanning workflow through state transitions. Human feedback points are cleverly embedded within this automation, forming a rapid feedback loop to ensure that subsequent code writing is conducted under user-authorized and explicitly planned guidance, enhancing the consistency between the final code output and the user's intent regarding development requirements. Furthermore, the entire planning process is orderly, controllable, and traceable. It also empowers the code development system with the ability to iterate and improve based on user feedback, thereby enabling early detection and correction of planning deviations and avoiding resource waste and time loss caused by writing code in the wrong direction.

[0088] Upon entering the code writing phase, the system initially enters a code-ready state. If the executor module obtains the current state as the code-ready state and acquires development requirement information and execution plan information (i.e., triggering conditions), it calls the second coding agent to generate code based on the development requirement information and execution plan information (i.e., the conversion action) and switches to the code-writing state (i.e., the target state) based on the state transition rules.

[0089] By transitioning from the code-to-write state to the code-writing-in-progress state, the confirmed execution plan information can be accurately transformed into specific, executable code. This ensures that the code generation process is initiated under correct guidance, improving the accuracy of the generated code and its consistency with the execution plan information.

[0090] After the code is generated, the code development system performs version control, updates the session file, and commits the generated code to the code repository.

[0091] To introduce a code quality assurance mechanism, this embodiment of the disclosure can further add an automated code submission and review process after code generation. Specifically, in response to the completion of code generation (i.e., the triggering condition), based on the conversion rule information, the code is submitted for review (i.e., the conversion action), and the system switches to the code review state (i.e., the target state); in response to the obtained review result indicating that the review has passed (i.e., the triggering condition), based on the conversion rule information, the system switches to the review passed state (i.e., the target state).

[0092] This involves submitting code to a code review system for automated review based on pre-configured rules, or submitting the code to reviewers for evaluation. During code review, the system can examine whether the code conforms to syntax rules, architectural design rules, framework development rules, performance and resource usage rules, security rules, and more.

[0093] Considering that code review results may indicate rejection, in order to form a complete quality improvement closed loop, this disclosure further provides a path for handling review rejections and iterative optimization. After switching to the code review state, the method further includes: in response to the obtained review result indicating review rejection (i.e., triggering condition), switching to the review rejection state (i.e., target state) based on conversion rule information. In response to obtaining review feedback information for the code (i.e., triggering condition), based on the conversion rule information, invoking a second coding agent to optimize the code based on development requirement information, execution planning information, and review feedback information for the code (i.e., conversion action), switching to the code writing state (i.e., target state). Subsequently, a review of the optimized code will be triggered again.

[0094] By automating the code review process through transitions between the writing, review, and approval stages, the system ensures that the code meets basic requirements, enhancing its credibility and compliance. Furthermore, it establishes a feedback-driven optimization loop. This allows the code development system to understand and absorb the results of code reviews, optimizing accordingly. This improves the system's ability to handle complex code development tasks and meet quality standards, while also enabling the automated coding process to continuously learn and improve. The code generation and review processes are also orderly, controllable, and traceable.

[0095] During the execution of actions in each of the above stages, if an error occurs, the executor module will update the task status to the corresponding failure status, record a detailed error log, terminate the code development task processing flow, stop session management for that code development task, and release related resources. For example, if initialization fails, the status will be updated from "Initializing" to "Initialization Failed." Similarly, if generating an execution plan fails, the status will be updated from "Planning" to "Planning Failed." And if generating code fails, the status will be updated from "Code Writing" to "Code Writing Failed."

[0096] As can be seen from the above method embodiments, this disclosure decomposes the entire code development task into two levels: stages and states within each stage. This makes the complex development process easier to understand and manage, clarifies the responsibilities of each stage, and encapsulates state details within each stage, reducing the complexity of system design. Furthermore, modifications or expansions to states within a stage do not affect other stages, facilitating local optimization of the process and improving flexibility and maintainability.

[0097] In this embodiment, the multi-layered state information configured for code development tasks can be maintained by the task management module of the code development system. The task management module is responsible for the entire lifecycle management of tasks, from task creation, initialization, code generation, review to final completion or failure. The task management module defines a strict state transition mechanism to ensure that inter-stage transitions and intra-stage state transitions must be performed according to predefined rules (i.e., multi-layered state information), requiring legality verification.

[0098] Besides using the state transition flow corresponding to the aforementioned multi-layer state information (i.e., multi-layer state machine model) to orchestrate and implement the entire development process, other methods can also be used. For example, a fixed workflow engine can be used to execute specific tasks for each stage of the code development process through configurable plugins. Although this method can also define and manage the development process and support a certain degree of process customization, it is less flexible and has poorer intelligent decision-making capabilities and maintainability compared to the multi-layer state machine model-driven approach. Therefore, the implementation method of multi-layer state machine model-driven approach provided in the above embodiments of this disclosure is preferred.

[0099] To improve system observability and task traceability, and facilitate problem diagnosis and progress monitoring, this embodiment of the disclosure also adds an auxiliary function of a task management module. The method further includes: recording task data for code development tasks, whereby the task data includes execution status information for multiple stages and key event information. Key event information may include the occurrence time, description, and execution result data of the key event. Key events may include events such as initialization events (i.e., events that perform initialization), planning events (i.e., events that generate execution plans), planning confirmation events (i.e., events that confirm execution plans), and code writing events (i.e., events that generate code). The execution result data of the key event may be the execution result data of the corresponding transformation action. The execution result data may include messages indicating successful or failed execution, and may also include information such as generated execution plans, code, and code review results. If the key event involves a call to a coding agent, the corresponding execution result data may also include at least one of the coding agent's thought process and decision-making basis. In response to a task query request from the user, the method returns execution information for the code development task, such as the current stage information, current status information, and key event information for the executed stages.

[0100] During the aforementioned state transition process, recording task data for code development provides users and operations personnel with comprehensive tracking capabilities, making task progress, time consumption, and key event information readily available. This not only enhances the transparency and traceability of the automated coding process but also provides data support for system monitoring, debugging, and performance optimization.

[0101] In this embodiment of the disclosure, the executor module can be in the form of a distributed cluster, that is, the executor module can include multiple executor instances, and the state transitions of each stage can be executed by the same executor instance or by different executor instances.

[0102] The term "executor instance" as used in this disclosure refers to any process, container, or computing module capable of hosting and running the execution logic of a code development task.

[0103] The allocation of subtasks and the scheduling of executor instances can be performed by the scheduler module in the code development system. The scheduler module can also include multiple scheduler instances. In other words, not only do the executor instances adopt a distributed cluster approach, but the scheduler instances also adopt a distributed cluster approach.

[0104] The “scheduler instance” referred to in this disclosure is an independent running process, container or computing module of the scheduler program, which can independently complete task acquisition, scheduling decisions and task allocation. Multiple scheduler instances form a scheduler cluster.

[0105] As one of the preferred embodiments, such as Figure 5 As shown, a scheduler instance can execute the following steps in parallel: Step 510: Obtain the target event from at least one type of event queue using a distributed lock mechanism.

[0106] In a distributed scheduler cluster, multiple scheduler instances compete to acquire events in the event queue. The core function of a distributed lock is to ensure that the same event can only be acquired by one of the multiple scheduler instances at the same time, thereby avoiding scheduling conflicts or duplicate scheduling.

[0107] One possible approach is for a scheduler instance to request a queue-level lock on the target queue containing the target event, retrieve the target event from the queue, and then release the queue-level lock. While the queue is locked, no other scheduler instance can access the event queue except for the one that requested the queue-level lock.

[0108] For example, before attempting to retrieve a target event from an event queue, a scheduler instance first requests a lock from a distributed lock service, identified by the queue's name. Only a scheduler instance that successfully acquires the lock can retrieve an event from the queue, and immediately release the lock after the operation is complete. This approach uses the entire queue as the lock granularity, is simple to implement, and can quickly process events in the queue with minimal lock contention overhead.

[0109] As an alternative approach, a scheduler instance can acquire an event-level lock for a target event, retrieve the target event from its target queue, and then release the event-level lock. While the event is locked, no other scheduler instance can access it except for the one that acquired the lock.

[0110] For example, a scheduler instance first determines the identifier of the target event, and then uses that identifier as the key to request a distributed lock. Only a scheduler instance that successfully acquires the lock can retrieve the target event from the event queue, and immediately release the lock after the operation is complete. This approach uses a single event as the lock granularity, resulting in higher precision, and allows multiple scheduler instances to process different events in the same queue simultaneously, further improving system throughput.

[0111] Step 520: Determine the subtasks of the code development task corresponding to the target event.

[0112] In this disclosure, the term "target event" refers to a single event message retrieved from the event queue and currently awaiting processing. It typically carries information necessary to trigger subsequent processing. The code development system can maintain multiple types of event queues to categorize and store different types of events. For example, four event queues could be used to store events such as new code development tasks, events confirming execution plans returned by the client, events rejecting execution plans returned by the client, and events indicating rejection returned by the code review system.

[0113] In some scenarios, the target event is a new task event for code development tasks. In this case, the subtasks of the code development task corresponding to the target event determined by the scheduler instance include: calling the first coding agent to generate execution plan information based on development requirement information, and sending the execution plan information to the user terminal.

[0114] In other scenarios, the target event is the event in which the user returns confirmation of the execution plan information. In this case, the sub-tasks of the code development task corresponding to the target event determined by the scheduler instance include: calling the second coding agent to generate code based on the development requirements information and the confirmed execution plan information, and submitting the code for review.

[0115] In some other scenarios, the target event is the event in which the user returns a rejection of the execution plan information. In this case, the subtasks of the code development task corresponding to the target event determined by the scheduler instance include: obtaining at least one of the rejection reason and modification suggestion, calling the first coding agent to regenerate the execution plan information based on at least one of the rejection reason and modification suggestion and the development requirement information, and sending the execution plan information to the user.

[0116] In some other scenarios, the target event is an event indicating rejection in the code review result. In this case, the sub-tasks of the code development task corresponding to the target event determined by the scheduler instance include: obtaining review feedback information for the code, calling the second coding agent to optimize the code based on the development requirements information, execution planning information and review feedback information for the code, and submitting the optimized code for review.

[0117] Step 530: Select an executor instance from multiple executor instances, and assign the subtask corresponding to the target event to the selected executor instance, so that the executor instance can execute the assigned subtask.

[0118] This approach can effectively improve the throughput of the code development system, thereby improving its efficiency. Furthermore, the redundant design of multiple executor instances and multiple scheduler instances effectively improves the reliability of the code development system.

[0119] In this embodiment of the disclosure, the scheduler instance can distribute subtasks to appropriate executor instances based on the real-time load status of the executor instance cluster, so as to achieve load balancing and efficient resource utilization.

[0120] One possible approach is to maintain an executor resource pool containing idle executor instances. The scheduler instance can retrieve an idle executor instance from the pool and assign a subtask of the code development task corresponding to the target event to that idle executor instance; after executing the assigned subtask, the executor instance returns to the executor resource pool.

[0121] An executor resource pool is a logical management concept used to maintain a list of currently idle executor instances (those that have not been assigned subtasks or have low resource consumption). After an executor instance finishes executing its assigned subtask, it returns to the executor resource pool, awaiting its next allocation. This approach reuses executor resources through pooling technology, avoiding the overhead of frequently creating and destroying executor instances for each task. By adopting this executor resource pooling management method, rapid matching and efficient reuse of executor instances can be achieved, reducing the complexity of task allocation.

[0122] Besides using an executor resource pool, other methods can be used to select executor instances based on load conditions. For example, based on the load condition of the executor instance, the executor instance with the fewest currently processing subtasks can be selected; or, the executor with the lowest CPU utilization, memory usage, or overall load can be selected.

[0123] Additionally, when selecting executor instances, the status of the executor instances is determined, and only those in a live state are selected. The scheduler instance can detect the status of executor instances through a periodic heartbeat mechanism, that is, to detect whether the executor instance is alive or invalid. Typically, when an executor instance fails, it is removed from the executor resource pool, and the resources it occupied are cleaned up and reclaimed, such as local session files.

[0124] In this embodiment of the disclosure, the failure of the executor instance is not limited to the executor instance crashing or stopping, but can also be due to excessive load, insufficient resources, etc.

[0125] Furthermore, if an executor instance is detected to be in a failed state due to not completing its assigned subtask, the assigned subtask is marked as failed, or the assigned subtask is reassigned. During reassignment, the subtask can be repackaged into an event and placed back into the event queue, awaiting reassignment by the scheduler instance.

[0126] In this way, the scheduler instance can proactively discover failed executor instances and mark the unfinished subtasks of the failed executor instances as failed or reassign them, preventing subtasks from being suspended indefinitely due to unexpected executor instance crashes, and further improving the robustness and reliability of the auto-coding system.

[0127] One possible approach is for each executor instance, upon startup, to send heartbeat information to a shared registry at fixed time intervals (e.g., once per second). This heartbeat information includes at least the instance ID and the latest timestamp. The scheduler instance uses the heartbeat information stored in the registry to determine whether the executor instances are alive. For example, if the difference between the latest timestamp of an executor instance and the current time exceeds a preset threshold (e.g., 30 seconds), the executor instance is considered to be in a failed state.

[0128] To ensure the consistency of the task context during fault recovery and task retries, embodiments of this disclosure also introduce a task identifier and allocation information management mechanism. Specifically, it includes recording the subtask allocation information of the executor instance. This subtask allocation information includes the task identifier of the code development task corresponding to the allocated subtask, and may also include information such as the executor instance identifier, allocation time, and subtask status. If an executor instance is detected to be in a failed state, the subtask allocation information of the failed executor instance is cleared.

[0129] Subtask allocation information can maintain the mapping relationship between subtasks and executor instances of a development task, thereby facilitating the acquisition of global allocation information for code development tasks. Furthermore, it can promptly clear the corresponding subtask allocation information after an executor instance becomes invalid, making the subtask allocation status of code development tasks more accurate.

[0130] In this embodiment of the disclosure, when the scheduler instance selects an executor instance from multiple executor instances and assigns the subtask corresponding to the target event (hereinafter referred to as the current subtask to be assigned) to the selected executor instance (i.e., performs step 530 above), the specific steps may be as follows: Step 531: Determine if the current subtask has a preceding subtask belonging to the same code development task. If yes, proceed to step 532; otherwise, proceed to step 534.

[0131] Step 532: Determine whether the first executor instance of the preceding subtask is alive. If yes, proceed to step 533; otherwise, proceed to step 534.

[0132] In this embodiment of the disclosure, the target event may carry a task identifier of the code development task; when allocating the subtask of the code development task corresponding to the target event, the subtask allocation information of each executor instance may be queried first based on the task identifier carried by the target event to determine whether there is an executor instance that has been allocated the subtask corresponding to the task identifier and is in a live state. In this embodiment of the disclosure, the executor instance is referred to as the first executor instance.

[0133] Step 533: Assign the current subtask to the first executor instance, end the subtask assignment process corresponding to the current target event, and proceed to obtain a new target event.

[0134] Step 534: Based on the load status of multiple executor instances, select the second executor instance from the multiple executor instances, assign the current subtask to the second executor instance, and have the second executor instance execute the current subtask. This ends the subtask assignment process corresponding to the current target event, and you can proceed to obtain a new target event.

[0135] This implementation method ensures that different subtasks of the same code development task are assigned to the same executor instance for execution as much as possible. In this way, the executor instance can directly process based on the context of the preceding subtask, thereby improving the coherence and efficiency of task execution.

[0136] During the execution of some subtasks, calls to coded agents (including the first coded agent and the second coded agent) are involved. When the executor instance calls and interacts with the coded agents, a session file is generated, which is stored locally.

[0137] In this embodiment, the session file may include, but is not limited to, globally unique identifiers (typically uniquely corresponding to code development tasks), user-provided raw input (e.g., user-inputted development requirements, user feedback on execution planning information, user feedback on code review results, etc.), the coding agent's thought records, and the coding agent's output content, among other contextual content. The session file corresponds to the code development task; for example, the task identifier of the code development task is maintained and stored in correspondence with the identifier in the session file. Subtasks at each stage of the code development task share the same task identifier, thereby distinguishing the code development task to which they belong.

[0138] In this embodiment of the disclosure, a session persistence and synchronization mechanism is further provided. The session management module in the code development system can detect the local session file corresponding to the code development task. In response to detecting a change in the local session file, the modified local session file is synchronized to a remote storage space, such as a cloud server.

[0139] Figure 6 A session management process for a session management module provided in this embodiment of the disclosure, such as... Figure 6 As shown, the following steps may be included: Step 601: Start the session listener for the code development task.

[0140] Step 602: Periodically check whether the local session file has changed using a session listener.

[0141] Session listeners can be bound to the code development task identifier. The interval for periodic checks can be flexibly configured, for example, set to 30 seconds, 1 minute, or shorter or longer time intervals to capture changes in session content.

[0142] One possible approach is for the session listener to periodically check the most recent modification timestamp of the session file and determine whether the local session file has been changed by comparing the modification timestamp with the timestamp of the last time the session file was synchronized to the remote storage space.

[0143] Step 603: In response to the detection of a change in the local session file, parse the session content from the local session file and synchronize the session content to the remote storage space to store the session file corresponding to the code development task in the remote storage space.

[0144] The aforementioned synchronization operations may include reading the modified session file and uploading it to a specified path in a remote storage space (e.g., cloud storage) via a network protocol. For example, this involves creating an export directory structure, loading a session parser, reading the session file, parsing the session content (e.g., session files are typically in JSONL format), organizing and converting the session content according to a predefined format (e.g., loading an HTML module, organizing the structure of the dialogue content, and applying style templates), thereby generating a viewable document (e.g., converted to HTML format) and uploading it to the specified path in the remote storage space. This path is associated with the task identifier of the code development task for storage, ensuring that the session content of each code development task can be accurately stored and retrieved, and guaranteeing the security and accessibility of the session content.

[0145] Synchronization can take the form of, but is not limited to, full synchronization and incremental synchronization. Full synchronization refers to uploading the entire session file every time a change is detected in the local session file. Incremental synchronization refers to appending only the newly added lines or data blocks from the local session file to the session file in the remote storage space.

[0146] Step 604: Determine if the upload was successful. If the upload was successful, proceed to step 605; otherwise, proceed to step 606.

[0147] Step 605: Update the timestamp of the session file synchronized to the remote storage space, and proceed to step 602.

[0148] Step 606: Record the upload failure information and proceed to step 602.

[0149] Based on the aforementioned session persistence and synchronization mechanism, when the second executor instance executes the current subtask, it can retrieve the session file corresponding to the code development task from the remote storage space to execute the current subtask.

[0150] The second executor instance can retrieve the session file from remote storage in several ways. For example, when the scheduler instance assigns the current subtask, it passes the task identifier to the second executor instance. When the second executor instance executes the current subtask, it actively retrieves the session file corresponding to that task identifier from remote storage based on the task identifier (which is shared by all subtasks within the code development task). Another example is that when the scheduler instance assigns the current subtask, it determines the storage path of the session file in remote storage based on the task identifier and sends this storage path as a parameter to the second executor instance. When the second executor instance executes the current subtask, it retrieves the session file from remote storage based on the storage path.

[0151] This disclosure ensures the continuity and recoverability of the task execution process by detecting changes to the local session file and synchronizing it to the remote storage space, and by retrieving the session file from the remote storage space when executing subsequent subtasks of a code development task. Even if different subtasks of the same code development task are assigned to different executor instances, the subtasks can continue to be executed based on a unified session context, thus improving the robustness and fault tolerance of the system.

[0152] To further improve the manageability and queryability of session files, in this embodiment of the disclosure, the session management module can respond to a session file query request for a code development task. If a local session file corresponding to the code development task exists, the module queries the local session file and returns the query result; otherwise, it queries the session file corresponding to the code development task in the remote storage space and returns the query result.

[0153] By adding the aforementioned session query and management functions, the entire automated code development process becomes more transparent and easier to trace, thereby enhancing the system's credibility and maintainability.

[0154] Since the second coding agent uses rule information (or specification information) during code generation and / or optimization in the code writing phase, the rule management module in the code development system can further handle the storage, maintenance, version control, and access control of rule files. It also supports product-line specific rule configurations and integration mechanisms with basic rules. For example, users can create or modify rule information through the rule management interface; this rule information serves as the basis for code generation and / or code review during the code writing phase.

[0155] The rule information may include, but is not limited to, format rules, syntax rules, business logic rules, security rules, performance and resource rules, and compatibility rules.

[0156] Figure 7 A schematic block diagram of the code development system provided in this disclosure embodiment, such as Figure 7 As shown, the code development system 700 may include: a requirements management module 701, an executor module 702, an agent module 703, and a task management module 704. It may also include a timeline management module 705, a scheduler module 706, a session management module 707, a user management module 708, a product line management module 709, a rule management module 710, and a version control module 711. The agent module 703 may include a first coding agent and a second coding agent.

[0157] Among them, the requirements management module 701 is configured to obtain development requirements information.

[0158] Task management module 704 is configured to create code development tasks based on development requirements information.

[0159] The executor module 702 is configured to execute code development tasks, which include: calling a first coding agent to generate execution planning information based on development requirements information; calling a second coding agent to generate code based on the development requirements information and execution planning information, and submitting the code for review; responding to the review result indicating rejection, obtaining review feedback information for the code, calling the second coding agent to optimize the code based on the development requirements information, execution planning information, and review feedback information for the code, and submitting the optimized code for review, until the review result is approval.

[0160] Furthermore, the executor module 702 is also configured to send execution planning information to the user terminal, and in response to the user terminal's feedback result indicating confirmation regarding the execution planning information, to invoke a second coding agent to generate code based on the development requirement information and the execution planning information; and in response to the feedback result indicating rejection, to invoke a first coding agent to regenerate the execution planning information corresponding to the development requirements based on at least one of the rejection reason and modification suggestion returned by the user terminal regarding the execution planning information, as well as the development requirement information.

[0161] As one possible approach, the task management module 704 is configured to maintain multi-layered state information configured for code development tasks. The multi-layered state information includes information on multiple stages of code generation, state information contained in each stage, and transition rules between states. Among these multiple stages, at least the planning stage and the code writing stage are included.

[0162] The actuator module 702 is specifically configured to acquire multi-level state information; in response to determining that the transition rule information is satisfied, it executes the transition action corresponding to the current state of the current stage and then switches to the next state.

[0163] Specifically, when the current stage is the planning stage, the conversion actions include: calling the first coding agent to generate execution planning information corresponding to the development requirements information based on the development requirements information; when the current stage is the code writing stage, the conversion actions include: calling the second coding agent to generate code based on the development requirements information and execution planning information, and submitting the code for review; and calling the second coding agent to optimize the code based on the development requirements information, execution planning information, and review feedback information on the code, and submitting the optimized code for review.

[0164] As one possible implementation method, the executor module 702 can be specifically configured as follows: if the current state is the planning stage (planning pending state) and development requirement information is obtained, based on the conversion rule information, the first coding agent is invoked to generate execution planning information based on the development requirement information, and the state is switched to planning; in response to the completion of execution planning information generation, the execution planning information is sent to the user terminal based on the conversion rule information, and the state is switched to planning confirmation; in response to the user terminal returning a confirmation result for the execution planning information, the state is switched to planning confirmed based on the conversion rule information, triggering entry into the code writing stage; in response to the user terminal returning a rejection result for the execution planning information, the first coding agent is invoked based on the conversion rule information and at least one of the rejection reason and modification suggestion returned by the user terminal for the execution planning information, as well as the development requirement information, to regenerate the execution planning information, and the state is switched to planning pending state.

[0165] As another possible implementation, the executor module 702 can be specifically configured as follows: if the current state is the code-writing stage (code-pending state), and development requirement information and execution planning information are obtained, based on the conversion rule information, the second coding agent is invoked to generate code based on the development requirement information and execution planning information, and the state switches to the code-writing state; in response to the completion of code generation, based on the conversion rule information, the code is submitted for review, and the state switches to the code review state; in response to the obtained review result indicating that the review has passed, the state switches to the review-passed state based on the conversion rule information; in response to the obtained review result indicating that the review has been rejected, the state switches to the review-rejected state based on the state transition rule information; in response to the obtained review feedback information for the code, based on the state transition rule information, the second coding agent is invoked to optimize the code based on the development requirement information, execution planning information, and review feedback information for the code, and the state switches to the code-writing state.

[0166] Furthermore, the timeline management module 705 is configured to record task data for code development tasks. The task data includes execution status information for multiple stages and key event information. The key event information includes the occurrence time, description information, and execution result data of the key events. In response to a task query request from the user, it returns the execution information of the code development task. The execution information includes the current stage information, the current status information, and key event information of the executed stages.

[0167] Furthermore, the scheduler module 706 includes multiple scheduler instances, and the executor module 702 includes multiple executor instances.

[0168] The scheduler instance is configured to execute in parallel: it retrieves the target event from an event queue of at least one type through a distributed lock mechanism; it determines the subtask of the code development task corresponding to the target event; it selects an executor instance from multiple executor instances and assigns the subtask of the code development task corresponding to the target event to the selected executor instance.

[0169] The subtasks are as follows: 1) Invoking the first coding agent to generate execution plan information based on development requirements information; 2) Invoking the second coding agent to generate code based on development requirements information and confirmed execution plan information, and submitting the code for review; 3) Obtaining review feedback information on the code, invoking the second coding agent to optimize the code based on development requirements information, execution plan information and review feedback information on the code, and submitting the optimized code for review.

[0170] Furthermore, the scheduler instance is also configured to: detect the status of the executor instance of the assigned subtask through a heartbeat mechanism; if it is detected that the executor instance has not completed the assigned subtask and is in a failed state, then mark the assigned subtask as a failed state, or reassign the assigned subtask.

[0171] As one possible implementation, when assigning a subtask to a selected executor instance, the scheduler instance is specifically configured as follows: if the current subtask does not have a preceding subtask belonging to the same code development task, or if the first executor instance executing the preceding subtask is in a failed state, then based on the load status of multiple executor instances, a second executor instance is selected from multiple executor instances, and the current subtask is assigned to the second executor instance. If the first executor instance executing the preceding subtask is alive, the current subtask is assigned to the first executor instance.

[0172] Furthermore, the session management module 707 is configured to detect the local session file corresponding to the code development task, the session file including the session content generated by the first executor instance executing the preceding subtask; in response to detecting a change in the local session file, the modified local session file is synchronized to the remote storage space.

[0173] The scheduler instance is also configured to pass the task identifier of the code development task to the second executor instance when assigning the current subtask to the second executor instance.

[0174] The second executor instance is configured to retrieve the session file corresponding to the code development task from remote storage to execute the assigned current subtask.

[0175] The session management module 707 is also configured to respond to a received session file query request for a code development task. If a local session file corresponding to the code development task exists, the local session file is queried and the query result is returned. Otherwise, the session file of the code development task in the remote storage space is queried and the query result is returned.

[0176] Furthermore, the user management module 708 is configured to handle user authentication, access control, and key management. It supports user role definition (e.g., regular users, product line administrators, super administrators, etc.) and product line access control, and provides encrypted storage and secure access mechanisms. Users can access the code development system according to their predetermined roles after being authenticated and authorized by the user management module.

[0177] Furthermore, the product line management module 709 is configured to manage product line information, including the product line's name, description, owner, associated code repository, and corresponding demand space. It supports operations such as creating, updating, deleting, and querying product lines.

[0178] Furthermore, the rule management module 710 is configured to be responsible for the storage, maintenance, version control, and access control of rule files. It also supports product-line specific rule configurations and integration mechanisms with basic rules. For example, users can create or modify rule information through the rule management interface; this rule information is used as a basis for generating code during the code writing phase and / or for code review.

[0179] Version control module 711 is configured to perform version control of the code when the executor module 702 generates code, and to submit the code to the review system, etc.

[0180] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0181] It should be noted that the large language model used by the coded intelligent agent involved in this embodiment is not a model for a specific user and cannot reflect the personal information of a specific user.

[0182] This disclosure also provides an electronic device, including: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which enables the at least one processor to perform the code development method described in any of the foregoing method embodiments.

[0183] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to execute the code development method described in any of the foregoing method embodiments.

[0184] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the code development method described in any of the foregoing method embodiments.

[0185] Figure 8A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0186] like Figure 8 As shown, device 800 includes a computing module 801, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 802 or a computer program loaded from storage module 808 into random access memory (RAM) 803. RAM 803 may also store various programs and data required for the operation of device 800. The computing module 801, ROM 802, and RAM 803 are interconnected via bus 804. Input / output (I / O) interface 805 is also connected to bus 804.

[0187] Multiple components in device 800 are connected to I / O interface 805, including: input module 806, such as keyboard, mouse, etc.; output module 807, such as various types of displays, speakers, etc.; storage module 808, such as disk, optical disk, etc.; and communication module 809, such as network card, modem, wireless transceiver, etc. Communication module 809 allows device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0188] The computing module 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing module 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing modules running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing module 801 performs the various methods and processes described above, such as code development methods. For example, in some embodiments, code development may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage module 808. In some embodiments, part or all of the computer program may be loaded and / or installed on device 800 via ROM 802 and / or communication module 809. When the computer program is loaded into RAM 803 and executed by the computing module 801, one or more steps of the code development methods described above may be performed. Alternatively, in other embodiments, the computing module 801 may be configured to perform code development methods by any other suitable means (e.g., by means of firmware).

[0189] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-codeable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex codeable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include: implementations in one or more computer programs that can be executed and / or interpreted on a codeable system including at least one codeable processor, which may be a dedicated or general-purpose codeable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0190] The program code used to implement the methods of this disclosure may be written in any combination of one or more coding languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other coded data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0191] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable and codeable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0192] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0193] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0194] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0195] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0196] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A code development method, characterized in that, The method includes: Obtain development requirements information and create code development tasks; The code development task includes: invoking a first coding agent to generate execution plan information based on the development requirement information; invoking a second coding agent to generate code based on the development requirement information and the execution plan information, and submitting the code for review; in response to the review result indicating a rejection, obtaining review feedback information for the code, invoking the second coding agent to optimize the code based on the development requirement information, the execution plan information, and the review feedback information for the code, and submitting the optimized code for review until the review result is a pass.

2. The method according to claim 1, wherein, Before invoking the second coded agent to generate code based on the development requirements information and the execution plan information, the method further includes: Send the execution plan information to the user terminal; In response to the feedback result confirmation returned by the user terminal regarding the execution planning information, the step of invoking the second coding agent to generate code based on the development requirement information and the execution planning information is executed; In response to the feedback result indicating rejection, the system obtains at least one of the rejection reasons and modification suggestions returned by the user terminal for the execution planning information, and calls the first coding agent to regenerate the execution planning information based on at least one of the rejection reasons and modification suggestions and the development requirement information.

3. The method according to claim 1, wherein, The execution of the code development task includes: Obtain multi-level state information configured for the code development task. The multi-level state information includes information on multiple stages of code generation, state information contained in each stage, and transition rules between states. The multiple stages include at least a planning stage and a code writing stage. In response to determining that the transformation rule information is satisfied, after performing the transformation action corresponding to the current state of the current stage, switch to the next state; Wherein, when the current stage is the planning stage, the conversion action includes: invoking the first coded intelligent agent to generate execution planning information based on the development requirement information; When the current stage is the code writing stage, the conversion action includes: invoking the second coding agent to generate code based on the development requirements information and the execution plan information, and submitting the code for review; and invoking the second coding agent to optimize the code based on the development requirements information, the execution plan information, and the review feedback information on the code, and submitting the optimized code for review.

4. The method according to claim 3, wherein, The step of responding to determining that the transformation rule information is satisfied, executing the transformation action corresponding to the current state of the current stage, and then switching to the next state includes: If the current state is the planning stage and the development requirement information is obtained, based on the conversion rule information, the first coding agent is invoked to generate the execution planning information based on the development requirement information, and the state is switched to the planning stage. In response to the completion of the execution plan information generation, the execution plan information is sent to the user terminal based on the conversion rule information, and the status is switched to "planning confirmation". In response to the feedback result confirmation of the execution plan information returned by the user terminal, based on the conversion rule information, the system switches to the plan confirmation state and triggers the entry into the code writing stage.

5. The method according to claim 4, characterized in that, After switching to the planning determination state, the step of responding to the determination that the transformation rule information is satisfied, executing the transformation action corresponding to the current state of the current stage, and then switching to the next state further includes: In response to the user terminal's feedback result indicating rejection of the execution planning information, based on the conversion rule information, the first coding agent is invoked to regenerate the execution planning information based on at least one of the rejection reasons and modification suggestions returned by the user terminal regarding the execution planning information, as well as the development requirement information, and switches to the planning pending state.

6. The method according to claim 3, wherein, The step of responding to determining that the transformation rule information is satisfied, executing the transformation action corresponding to the current state of the current stage, and then switching to the next state includes: If the current state is the code-writing stage and the development requirements information and execution plan information are obtained, the second coding agent is invoked to generate code based on the development requirements information and execution plan information, and the code-writing state is switched to the current state. In response to the completion of code generation, based on the conversion rule information, the code is submitted for review and switched to the code review state; In response to the obtained review result indicating review rejection, the system switches to the review rejection state based on the conversion rule information; In response to receiving review feedback information for the code, based on the conversion rule information, the second coding agent is invoked to optimize the code based on the development requirements information, the execution plan information, and the review feedback information, and then the code is switched to the code writing state.

7. The method according to any one of claims 3 to 6, further comprising: Record the task data of the code development task, the task data including the execution status information of the multiple stages and key event information, the key event information including the occurrence time, description information and execution result data of the key event; In response to a task query request from the user, the execution information of the code development task is returned, including the current stage information, the current status information, and key event information of the executed stage.

8. The method according to claim 1, wherein, The execution of the code development task also includes: The scheduler instance uses a distributed lock mechanism to obtain a target event from at least one type of event queue; determines the subtask of the code development task corresponding to the target event; selects an executor instance from the plurality of executor instances, and assigns the subtask corresponding to the target event to the selected executor instance, and executes the assigned subtask through the executor instance; The code development task includes multiple sub-tasks, which include: invoking a first coding agent to generate execution plan information based on development requirements information; or, invoking a second coding agent to generate code based on development requirements information and the confirmed execution plan information, and submitting the code for review; or, obtaining review feedback information on the code, invoking a second coding agent to optimize the code based on development requirements information, execution plan information, and the review feedback information, and submitting the optimized code for review.

9. The method according to claim 8, wherein, The method further includes: The scheduler instance uses a heartbeat mechanism to detect the status of the executor instance of the assigned subtask; If an executor instance is detected to be in an inactive state because it has not completed the assigned subtask, the assigned subtask is marked as failed, or the assigned subtask is reassigned.

10. The method according to claim 8, wherein, The step of selecting an executor instance from the plurality of executor instances and assigning the subtask corresponding to the target event to the selected executor instance includes: If the subtask corresponding to the target event does not have a preceding subtask belonging to the same code development task, or if the first executor instance executing the preceding subtask is in a failed state, then based on the load status of the multiple executor instances, a second executor instance is selected from the multiple executor instances, and the subtask corresponding to the target event is assigned to the second executor instance, which then executes the subtask corresponding to the target event. If the first executor instance executing the preceding subtask is alive, the subtask corresponding to the target event is assigned to the first executor instance.

11. The method of claim 10, further comprising: Detect the local session file corresponding to the code development task, the session file including the session content generated by the first executor instance executing the preceding subtask; In response to detecting a change in the local session file, the changed local session file is synchronized to the remote storage space; The execution of the subtask corresponding to the target event by the second executor instance includes: the second executor instance obtaining the session file corresponding to the code development task from the remote storage space to execute the subtask corresponding to the target event.

12. The method according to claim 1, further comprising: The local session file corresponding to the code development task is detected, and the session file includes the session content generated during the process of calling the first coding agent and / or calling the second coding agent; In response to detecting a change in the local session file, the changed local session file is synchronized to the remote storage space; In response to receiving a session file query request for the code development task, if a local session file corresponding to the code development task exists, the local session file is queried and the query result is returned; otherwise, the session file of the code development task in the remote storage space is queried and the query result is returned.

13. A code development system, characterized in that, The code development system includes a requirements management module, a task management module, an executor module, a first coding agent, and a second coding agent; The requirement management module is configured to obtain development requirement information; The task management module is configured to create code development tasks based on the development requirements information; The executor module is configured to execute the code development task, which includes: invoking a first coding agent to generate execution plan information based on the development requirement information; invoking a second coding agent to generate code based on the development requirement information and the execution plan information, and submitting the code for review; in response to the review result indicating a rejection, obtaining review feedback information for the code, invoking the second coding agent to optimize the code based on the development requirement information, the execution plan information, and the review feedback information for the code, and submitting the optimized code for review, until the review result is a pass.

14. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-12.

15. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-12.

16. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-12.

Images