Computing devices, methods, media, and products for software development

Abstract

The present invention relates generally to computer systems based on specific computational models, and in particular to a computing device, method, medium and product for software development. A computing device includes a computing resource, an orchestration control module and an agent. The agent is respectively configured into a project planning role, a development role and a quality assurance role in a predetermined order under the control of the orchestration control agent. Among them, the execution evidence is passed between the project planning roles across rounds, the software artifacts are passed between the development roles across rounds, and the development documents are shared between the development roles and the quality assurance in a single round. The observable records marked as verified records in the current round are converted into retention constraints in the next round, and the observable records marked as gap records in the current round are converted into update targets and verification requirements in the next round. The execution evidence provided by the computing device according to the embodiment can trace the execution of each round in the software development process, and improve the performance of the developed software.

Description

Technical Field

[0001] This invention generally relates to computer systems based on specific computational models, and more specifically to computing devices, methods, media, and products for software development. Background Technology

[0002] Large language model-driven code writing agents can interact with the software environment through file editing, command lines, build, run, and test tools. The combination of the large language model and its runtime framework, role-oriented instructions, available tools, and runtime strategies can be referred to as the code writing agent framework-model configuration.

[0003] Software development from scratch starts with publicly available task specifications and requires the gradual creation of working software artifacts from empty workspaces, scaffolding projects, or existing repositories. It also involves addressing functional, interactive, resource, build, and runtime issues throughout continuous development. Compared to partial code generation or single-time defect fixes in existing repositories, this task requires maintaining the current implementation across iterations to validate conclusions.

[0004] A single development execution generates source code, configurations, assets, and project resources, as well as build results, test results, runtime logs, screenshots, replays, and asset inspection results. Only by linking these observations to verifiable claims and feeding them back into subsequent planning can later rounds schedule fixes, retention, and retesting based on the actual execution status.

[0005] Some existing solutions for function-level or program-level code generation for natural language programming tasks output code that meets test requirements. For example, AgentCoder takes natural language programming requirements as input, a programmer agent generates code, a test design agent generates tests, a test execution agent runs the tests and feeds back failure information to the programmer, and after a loop, outputs a program that passes the generated tests. Its processing chain is "generation—testing—feedback—correction," and the output is mainly code and test results (see Huang et al., "AgentCoder: Multi-Agent-Based Code Generation with Iterative Testing and Optimisation," 2023, https: / / arxiv.org / abs / 2312.13010). This solution does not describe the complete software project, the execution records archived by function claims, and subsequent retention constraints as independent cross-cycle states.

[0006] Some existing solutions target issues or tasks in existing code repositories for location, modification, and repair, typically outputting modifications to a given repository. For example, SWE-Agent explicitly uses existing code repositories and their issues as typical input (see Yang et al., "SWE-Agent: Agent-Computer Interfaces Enable Automated Software Engineering," 2024, https: / / proceedings.neurips.cc / paper_files / paper / 2024 / file / 5a7c947568c1b1328ccc5230172e1e7c-Paper-Conference.pdf). While OpenHands possesses more general software development capabilities, its publicly available repository-level tasks also typically provide task descriptions, existing code repositories, and tool interfaces (see Wang et al., "OpenHands: An Open Platform for AI Software Developers as Generalist Agents," 2025). The agent examines files, edits code, executes commands, and tests, outputting the modified repository and execution results.

[0007] Some schemes, such as AutoHarness (see Lou et al., "AutoHarness: Improving LLM Agents by Automatically Synthesizing a Code Harness", 2026, https: / / arxiv.org / abs / 2603.03329), Meta-Harness, and Self-Harness, deal with the scaffolding of the agent itself, improving the agent's capabilities by synthesizing, searching, or rewriting prompts, tools, and logical control.

[0008] The existing solutions described above have several limitations.

[0009] First, when only workspaces are transferred, cross-round status lacks readily available execution evidence for planning. While the next round can access project files, it cannot glean from the unified log which public requirements from the previous round are supported by build, test, run, or inspection results. The direct consequence is that subsequent planning requires re-inferring project status, test findings struggle to become reliably sourced update targets, and insufficient evidence is easily confused with functional failures.

[0010] Secondly, there is a lack of traceable links between test outputs and development decisions. If build logs, runtime paths, screenshots, or replays are not tied to specific functional claims, the basis for a quality conclusion cannot be clearly explained, nor can corresponding re-verification requirements be formed. The direct consequence is that the next round may involve repeatedly verifying irrelevant content, or only fixing superficial errors while omitting unmet requirements in the publicly disclosed task specifications.

[0011] Third, a hot start of a software artifact is not the same as an explicit retention constraint for verified functionality. Existing solutions can retain the code repository or workspace from the previous round and continue development from existing software artifacts. However, if verified functionality and the execution evidence supporting that functionality are not written into the next round of development documentation as retention constraints, development roles will still find it difficult to distinguish between behaviors that must be retained and general existing code. The direct consequence is that even with a hot start of a software artifact from the previous round, subsequent extensions or fixes may still cause a regression in verified behavior. Once a regression occurs, it is difficult to trace back to the evidence from previous rounds supporting that behavior along the next round of development constraints.

[0012] There is a need in this field to improve intelligent agent technology for software development in at least one of the above aspects. Summary of the Invention

[0013] This invention is provided to provide an improved intelligent agent for software development.

[0014] One aspect of the present invention provides a computing device for software development, comprising: computing resources; an orchestration control module for controlling operations between multiple rounds in the software development process and operations within each round; and an intelligent agent for invoking the computing resources to perform corresponding operations in each round, under the control of the orchestration control module, in a predetermined order as a project planning role, a development role, and a quality assurance role, wherein, in the current round, the intelligent agent is configured as the project planning role to perform the following steps: S1: Based on the task specifications associated with the software to be developed and the first execution evidence obtained up to the end of the previous round, determine the development document associated with the current round, the development document including retention constraints, update objectives, and verification requirements; the intelligent agent is configured as the development role to perform the following steps: S2: Based on the task specifications and the development document, modify the first software artifact obtained up to the previous round to form a second software artifact associated with the current round; the intelligent agent is configured as the quality assurance role to perform the following steps: The following steps are performed: S3: Calculate a set of verifiable claims associated with the current round based on the task specification and the development documentation, the set of verifiable claims including multiple verifiable claims; S4: For each verifiable claim, determine the observable record associated with the verifiable claim based on the second software artifact and the verifiable claim, and determine the support level determination state associated with the verifiable claim; S5: Mark the associated observable record as a verified record or a gap record based on the support level determination state; S6: Generate a second execution evidence associated with the current round based on each verifiable claim, the observable record associated with the verifiable claim, and the support level determination state associated with the verifiable claim, wherein the second software artifact and the second execution evidence are passed to the next round, the observable records marked as verified records in the second execution evidence are converted into retention constraints in the next round, and the observable records marked as gap records in the second execution evidence are converted into update targets and verification requirements in the next round.

[0015] In the computing device described above, S1 includes: S11: for each observable record marked as a verified record in the first execution evidence, extracting the verifiable claims and reference evidence associated with the observable record, and writing the extracted verifiable claims and reference evidence into the retention constraints of the development document.

[0016] As described in any of the preceding computing devices, S1 includes: S12: for each observable record marked as a gap record in the first execution evidence, extracting the verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates associated with the observable record; writing the extracted verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates into the update target of the development document; and writing the observables that need to be supplemented for the extracted verifiable claims into the verification requirements of the development document.

[0017] For any of the computing devices described above, the update targets of the development documentation include build or run-blocking items, evidence-supported defects, and unmet requirements.

[0018] As described in any of the above computing devices, the development documentation arranges the build or run-time blocking items, the evidence-supported defects, and the unmet requirements in descending order of priority, and S2 includes: S21: modifying the build or run-time blocking items, the evidence-supported defects, and the unmet requirements in sequence.

[0019] The computing device as described in any of the above, whose items are indicated by the retention constraints in the development documentation, remains available in the current round.

[0020] The observable records of any of the above computing devices include at least one of the following: exit status of build or test, standard output and error output, runtime log, status trace, screenshot, video, playback, and asset check.

[0021] As described in any of the preceding computing devices, S5 includes: S51: in response to determining that the referenced observable record is sufficient to observe the expected behavior, marking the observable record as a verified record; S52: in response to observing a failure or verification requirement not being met or a retention function regression from the referenced observable record, or determining that the referenced observable record is insufficient to observe the expected behavior, marking the observable record as a gap record.

[0022] As described in any of the above computing devices, the second software artifact is passed to the next round via a first channel for use by the development role, and the second execution evidence is passed to the next round via a second channel for use by the project planning role, wherein the first channel and the second channel are isolated from each other.

[0023] The computing device as described in any of the above claims, the agent is further configured to perform the following steps: S7: performing an initialization round, S7 including: S71: generating an initial development document based on the task specification; S72: forming a third software artifact associated with the initialization round based on the initial software artifact and the initial development document; and S73: determining third execution evidence associated with the initialization round based on observations of the first execution of the third software artifact.

[0024] The computing device as described in any of the above, the initial software artifact includes an empty workspace, scaffolding project, or existing warehouse.

[0025] The computing device as described in any of the above, the intelligent agent is further configured to perform the following steps: S8: in response to determining that the current round has reached a preset number of iteration rounds, outputting the second software artifact as the final software artifact.

[0026] Another aspect of the present invention provides a method for software development, comprising the following steps: an orchestration control module controls an agent to perform corresponding operations in a predetermined order as a project planning role, a development role, and a quality assurance role, wherein, in each of a plurality of rounds in the software development process, the method includes the following steps: S1: the agent, in the project planning role, determines a development document associated with the current round based on a task specification associated with the software to be developed and first execution evidence obtained up to the end of the previous round, the development document including update objectives, retention constraints, and verification requirements; S2: the agent, in the development role, modifies a first software artifact obtained up to the end of the previous round based on the task specification and the development document to form a second software artifact associated with the current round; S3: the agent, in the quality assurance role, calculates a set of verifiable claims associated with the current round based on the task specification and the development document, the set of verifiable claims including a plurality of verifiable claims. S4: For each verifiable claim, the agent, in the quality assurance role, determines the observable records associated with the verifiable claim based on the second software artifact and the verifiable claim, and determines the support level determination state associated with the verifiable claim; S5: The agent, in the quality assurance role, marks the associated observable records as verified records or gap records based on the support level determination state; and S6: The agent, in the quality assurance role, generates a second execution evidence associated with the current round based on the marked support level determination state, the verifiable claim associated with the support level determination state, and the support level determination state, wherein the second software artifact and the second execution evidence are passed to the next round, the observable records marked as verified records in the second execution evidence are converted into retention constraints in the next round, and the observable records marked as gap records in the second execution evidence are converted into update targets and verification requirements in the next round.

[0027] As described above, step S1 includes: S11: For each observable record marked as a verified record in the first execution evidence, extract the verifiable claims and cited evidence associated with the observable record, and write the extracted verifiable claims and cited evidence into the retention constraints of the development document; S12: For each observable record marked as a gap record in the first execution evidence, extract the verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates associated with the observable record, write the extracted verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates into the update target of the development document, and write the observable results that need to be supplemented for the extracted verifiable claims into the verification requirements of the development document.

[0028] As described in any of the above methods, the update targets of the development documentation include build or run-time blocking items, evidence-supported defects, and unmet requirements, and the development documentation arranges the build or run-time blocking items, evidence-supported defects, and unmet requirements in descending order of priority, and S2 includes: S21: modifying the build or run-time blocking items, the evidence-supported defects, and the unmet requirements in sequence.

[0029] As described in any of the above methods, the items indicated by the retention constraints in the development documentation remain available in the current round, and the observable records include at least one of the following: exit status of the build or test, standard output and error output, runtime logs, status traces, screenshots, videos, replays, and asset checks.

[0030] As described in any of the preceding methods, S5 includes: S51: in response to determining that the referenced observable is sufficient to observe the expected behavior, marking the observable as a verified record; S52: in response to observing a failure or verification requirement not being met or a retention function regression from the referenced observable, or determining that the referenced observable is insufficient to observe the expected behavior, marking the observable as a gap record.

[0031] As described in any of the above methods, the second software artifact is passed to the next round through the first channel for the development role to invoke, and the second execution evidence is passed to the next round through the second channel for the project planning role to invoke, wherein the first channel and the second channel are isolated from each other.

[0032] The method as described in any of the above further includes the following steps: S7: executing an initialization round, S7 including: S71: generating an initial development document based on the task specification; S72: forming a third software artifact associated with the initialization round based on the initial software artifact and the initial development document; and S73: determining third execution evidence associated with the initialization round based on observations of the first execution of the third software artifact; and S8: in response to determining that the current round has reached a preset number of iteration rounds, outputting the second software artifact as the final software artifact.

[0033] Another aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the preceding claims.

[0034] Another aspect of the present invention provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the above embodiments.

[0035] The computing device according to the embodiment provides execution evidence during the software development process that allows for traceability of each round of execution, facilitating gradual modification of the software code and improving the performance of the developed software. Attached Figure Description

[0036] Various embodiments of the present invention are described in conjunction with the accompanying drawings.

[0037] Figure 1 This is a block diagram of a computing device for software development according to some embodiments of the present invention.

[0038] Figure 2 This is a schematic diagram of the interaction and operation within a round of an intelligent agent and an orchestration control module of a computing device for software development, according to some embodiments of the present invention.

[0039] Figure 3 This is a schematic diagram illustrating the operation of an intelligent agent in a computing device for software development within a single round, according to some embodiments of the present invention.

[0040] Figure 4 This is a schematic diagram illustrating the updating and cross-round transfer of execution evidence and development documentation according to some embodiments of the present invention.

[0041] Figure 5 This is a block diagram illustrating the composition of development documentation according to some embodiments of the present invention.

[0042] Figure 6 This is a flowchart of a method for software development according to some embodiments of the present invention.

[0043] Figure 7 This is a flowchart of a first process associated with a method for software development according to some embodiments of the present invention.

[0044] Figure 8 This is a flowchart of a second process associated with a method for software development according to some embodiments of the present invention.

[0045] Figure 9 This is a flowchart of a third process associated with a method for software development according to some embodiments of the present invention.

[0046] Figure 10 This is a block diagram of a computer-readable storage medium according to some embodiments of the present invention.

[0047] Figure 11 This is a block diagram of a computer program product according to some embodiments of the present invention.

[0048] Figure 12 The embodiments of the present invention are shown to vary in iterative performance under different code-writing agent framework-model configurations.

[0049] Figure 13 The embodiments of the present invention are shown to compare the performance of the base method across various quality dimensions under different code-writing agent framework-model configurations.

[0050] Figure 14 According to embodiments of the present invention, key mechanism ablation results are obtained regarding final product quality and cumulative inference dosage. Detailed Implementation

[0051] In this application, the code-written intelligent agent framework-model configuration is fixed within a single complete run, and it may include the framework implementation, underlying model, role-oriented instructions, available tools, and runtime strategy. A fixed code-written intelligent agent framework-model configuration means that the above combination does not change between rounds within the same run. What changes in the code-written intelligent agent framework-model configuration are the software artifacts and round contexts, rather than automatically searching for or rewriting the fixed code-written intelligent agent framework-model configuration.

[0052] Symbols may be used in this application. S This refers to the publicly disclosed task specifications that are presented throughout all rounds. Task specifications may include product requirement documents or equivalent public requirements, as well as supporting public materials.

[0053] In this application, the following can be used i The index representing the round.

[0054] Symbols may be used in this application. A i Indicating in round i The code artifacts obtained from it. A i This can correspond to a workspace. As an example, A i This can be included in rounds i The source code, configurations, assets, and project resources that remain in the shared workspace after development is complete.

[0055] Symbols may be used in this application. D i Indicating in round i The development documentation used in the development and verification process.

[0056] Symbols may be used in this application. E i Indicating in round i The execution evidence used.

[0057] According to one aspect of the present invention, a computing device for software development is provided.

[0058] Figure 1This is a block diagram of a computing device 100 for software development according to some embodiments of the present invention.

[0059] In some embodiments, the computing device 100 may include computing resources 110, an agent 130, and an orchestration control module 150.

[0060] Computing resources 110 may include various hardware resources for computing, such as a central processing unit (CPU), a graphics processing unit (GPU), and various execution units (e.g., tensor processing unit, ray tracing unit, floating-point execution unit, integer execution unit, etc.).

[0061] Agent 130 can be a code-writing agent based on a large language model. Agent 130 can call upon computing resources 110 to perform code writing tasks.

[0062] The orchestration control module 150 can be used to control operations between multiple rounds in the software development process, as well as operations within each round. The following will combine... Figure 2 Further details are provided regarding the control of cross-round interactions and intra-round operations by the orchestration control module 150.

[0063] Figure 2 This is a schematic diagram of an intelligent agent 130 and an orchestration control module 150 of a computing device for software development, according to some embodiments of the present invention, interacting across rounds and operating within rounds.

[0064] In some embodiments, agent 130 may be configured to assume the roles of project planning 132, development 134, and quality assurance 136, respectively.

[0065] As an example, agent 130 can assume corresponding roles through role hints. Role hints can be formed by concatenating reusable markup language modules with runtime slots. Fixed modules define role boundaries, public information policies, and output contracts. Runtime slots can be used to populate public tasks, round indices, current software artifacts, development documentation, and execution records. Agent 130's three roles can call shared code to write agent framework-model configurations, but only receive inputs corresponding to their role responsibilities.

[0066] As an example, prompts for Project Planning Role 132 may include role instructions, publicly available task specifications, evidence of execution from the previous round, document skeletons, and output contracts.

[0067] As an example, prompts for development role 134 may include baseline task guidance, round encapsulation, warm-start block, and development documentation for the current round, and explicitly require that software development for the current round continue from software artifacts that already exist in the workspace (i.e., software artifacts obtained after the completion of the previous round).

[0068] As an example, prompts for Quality Assurance Role 136 may include test role instructions, phase instructions, development documentation for the current round, a list of public media, and output contracts.

[0069] In some embodiments, in the current round t, agent 130, under the control of orchestration control module 150, can perform corresponding operations in a predetermined order as project planning role 132, development role 134, and quality assurance role 136. That is, in round t, under the control of orchestration control module 150, agent 130 first operates as project planning role 132, then as development role 134, and finally as quality assurance role 136, thereby completing the operations in round t. Similarly, in round t+1, under the control of orchestration control module 150, agent 130 first operates as project planning role 132, then as development role 134, and finally as quality assurance role 136, thereby completing the operations in round t+1.

[0070] In some embodiments, the orchestration control module 150 is also used to control operations between multiple rounds. As an example, the orchestration control module 150 is used to control the transition from round t to round t+1.

[0071] Figure 2 The document also shows enforcement evidence E. i Software artifact A is transferred between project planning roles 1, 3, and 2 across rounds. i It is passed between development roles 1, 3, and 4 across rounds, and development document D is also included. i This is shared between Development Role 134 and Quality Assurance Role 136 within the same round, as indicated in the corresponding diagram. The following will combine... Figures 3-4 This section further describes the specific implementation methods for the transfer of execution evidence and software artifacts across rounds, as well as the sharing of development documentation within rounds.

[0072] Figure 3 This is a schematic diagram illustrating the operation of an intelligent agent in a computing device for software development within a single round, according to some embodiments of the present invention.

[0073] In some embodiments, the agent may be configured as a project planning role 132 to base its actions on the task specification S associated with the software to be developed and the first execution evidence E obtained up to the end of the previous round. t-1 To determine the development document D associated with the current round t.t In some embodiments, development document D t This may include retention constraints, update objectives, and validation requirements.

[0074] In some embodiments, the agent may be configured as a development role 134, based on task specification S and development document D. t To modify the first software artifact A obtained up to the previous round (i.e., round t-1). t-1 To form a second software artifact A associated with round t. t .

[0075] In some embodiments, the agent may be configured as a quality assurance role 136, based on task specifications S and development documents D. t Second software product A t Determine the second execution evidence E associated with round t t The following text will combine... Figure 3 Further description: The agent is configured as a quality assurance role 136 to determine the second execution evidence E. t The specific implementation method.

[0076] exist Figure 3 China and Israel Figure 2 Similar diagrams in the text more clearly illustrate the transfer of execution evidence across rounds between project planning roles 132 and the transfer of software artifacts across rounds between development decisions. Figure 3 The document also shows that in round t, the development documentation D... t It is shared between Development Role 134 and Quality Assurance Role 136.

[0077] Figure 4 This is a schematic diagram illustrating the updating and cross-round transfer of execution evidence and development documentation according to some embodiments of the present invention. Figure 4 The process shown in the figure can be Figure 3 The agent is configured as a quality assurance role 136 to generate second execution evidence E. t The specific implementation method.

[0078] In some embodiments, the agent may be configured as a quality assurance role, based on task specifications S and development documents D. t To calculate the set of verifiable claims c associated with round t. t Verifiable claim set c t It may include multiple verifiable claims.

[0079] In some embodiments, the agent can be configured as a quality assurance role to address each verifiable claim c t,j Based on the second software artifact A t And the verifiable claim c t,jDetermine the relationship with the verifiable claim c t,j Associated observable records r t,j And determine the level of support associated with the verifiable claim and determine the status s t,j .

[0080] In some embodiments, the agent may be configured as a quality assurance role to determine the state based on the level of support and mark the associated observable record as a verified record or a gap record.

[0081] In some embodiments, the agent may be configured as a quality assurance role to assess each verifiable claim. t,j , and the verifiable claim c t,j Associated observable records r t,j and the verifiable claim c t,j The associated support level determines the state s t,j To generate the second execution evidence E associated with the current round. t .

[0082] Second executable evidence E t This may include a first part 410 and a second part 420. The first part 410 may include observable records marked as verified records, and the second part 420 may include observable records marked as gap records. In the next round (i.e., round t+1), the first part 410 may be converted into the corresponding development document D. t+1 The retention constraints 430 and the second part 420 can be converted into the corresponding development document D. t+1 The update target 440 and verification requirement 450.

[0083] Some implementations employ execution evidence channels and evidence conditional planning, enabling the next round to distinguish verified functions and gaps by record, and to form retention constraints and update targets respectively. This allows verified functions to be maintained and gaps to be focused on in the next round, improving the efficiency and performance of software development.

[0084] Some implementations support the transfer of software artifacts across rounds, enabling the next round of software development to proceed incrementally based on the software artifacts obtained in the previous round, thereby improving the efficiency and performance of software development.

[0085] Some implementations use execution evidence obtained from the previous round to regenerate the development documentation for the current round, enabling the current round to adjust its goals and conduct verifications based on the actual execution results of the previous rounds, thus improving the performance of software development.

[0086] In some embodiments, in order to determine the development document associated with the current round, an agent may be configured as a project planning role to extract verifiable claims and reference evidence associated with each observable marked as a verified record in the first execution evidence, and write the extracted verifiable claims and reference evidence into the retention constraints of the development document.

[0087] In some embodiments, in order to determine the development document associated with the current round, an agent may be configured as a project planning role to extract, for each observable record marked as a gap record in the first execution evidence, verifiable claims, observed failures or insufficient evidence, user impact, and recommended updates associated with that observable record, write the extracted verifiable claims, observed failures or insufficient evidence, user impact, and recommended updates into the update target of the development document, and write any observables that need to be supplemented to the extracted verifiable claims into the verification requirements of the development document.

[0088] In some embodiments, observable recording (e.g., observable recording r) t,j This may include at least one of the following: exit status of the build or test, standard output and error output, runtime logs, status traces, screenshots, videos, replays, and asset checks.

[0089] In some embodiments, in order to mark an observable as a verified record or a gap record, an agent may be configured as a quality assurance role to mark the observable as a verified record in response to determining that the referenced observable is sufficient to observe the expected behavior.

[0090] In some embodiments, in order to mark an observable record as a verified record or a gap record, an agent may be configured as a quality assurance role to mark an observable record as a gap record in response to observing a failure or unmet verification requirement or retained function regression from the referenced observable record, or to determine that the expected behavior is insufficient to be observed from the referenced observable record.

[0091] In some embodiments, the second software artifact (e.g., Figure 3 The second software artifact A t ) can be passed to the next round through the first channel (e.g., Figure 3 In some embodiments, the second execution evidence (e.g., round t+1) is provided for the development role to invoke. Figure 3 Second enforcement evidence E t It can be passed to the next round through the second channel (e.g., Figure 3 The first channel (t+1) is used for project planning roles to invoke. In some embodiments, the first channel can be isolated from the second channel.

[0092] In some embodiments, the agent may also be configured to perform an initialization round. In some embodiments, the agent may be configured to generate initial development documentation based on a task specification. In some embodiments, the agent may be configured to form a third software artifact associated with the initialization round based on the initial software artifact and the initial development documentation. In some embodiments, the agent may be configured to determine third execution evidence associated with the initialization round based on observations of the first execution of the third software artifact.

[0093] In some embodiments, initializing software artifacts may include an empty workspace, scaffolding works, or an existing warehouse.

[0094] In some embodiments, the agent may also be configured to determine that the current round has reached a preset number of iteration rounds and output a second software artifact as the final software artifact.

[0095] Figure 5 This is a block diagram illustrating the composition of development documentation according to some embodiments of the present invention.

[0096] In some embodiments, the development documentation may include retention constraints and update objectives.

[0097] In some embodiments, the update target may include build or run blocking items, evidence-supported defects, and unmet requirements.

[0098] In some embodiments, the development documentation may prioritize items that prevent construction or motion, items with evidence support for defects, and items that do not meet requirements in descending order of priority.

[0099] In some embodiments, in order to form a second software artifact associated with the current round, an agent may be configured as a project planning role to sequentially modify build or run-blocking items, evidence-supported defects, and unmet requirements.

[0100] Some implementations modify the targets that need updating in the software artifacts obtained in previous rounds in the current round in descending order of priority, increasing the targeting, effectiveness and efficiency of the modifications in the current round.

[0101] In some embodiments, items indicated by the retention constraints in the development documentation may remain available in the current round.

[0102] Some implementations keep the items for which the constraint indications are retained available (i.e., not modified) in each round, thus preventing the verified behavior from regressing in subsequent rounds.

[0103] According to another aspect of the present invention, a method for software development is provided.

[0104] Figure 6This is a flowchart of a method for software development according to some embodiments of the present invention. The method can be... Figure 1 The invention is performed by the computing device 100, but the scope of the invention is not limited thereto.

[0105] In some embodiments, the method may include the step of: controlling an agent to perform corresponding operations in a predetermined order as a project planning role, a development role, and a quality assurance role, respectively, by an orchestration control module.

[0106] In some embodiments, each of the multiple rounds of the software development process (e.g., in round i) may include step S1: an agent, acting as a project planner, determines the development document associated with the current round based on the task specifications associated with the software to be developed and first execution evidence obtained up to the end of the previous round. The development document includes update objectives, retention constraints, and validation requirements. The following will combine... Figure 7 The specific implementation method of step S1 will be further described.

[0107] In some embodiments, each round may include step S2: an agent, acting as a development role, modifies the first software artifact obtained up to the previous round based on the task specifications and development documentation to form a second software artifact associated with the current round.

[0108] In some embodiments, each round may include step S3: an agent, acting as a quality assurance role, calculates a set of verifiable claims associated with the current round based on the task specifications and development documents. The set of verifiable claims includes multiple verifiable claims.

[0109] In some embodiments, each round may include step S4: an agent, in a quality assurance role, determines, for each verifiable claim, observable records associated with the verifiable claim based on the second software artifact and the verifiable claim, and determines the support level determination state associated with the verifiable claim.

[0110] In some embodiments, each round may include step S5: an agent, acting as a quality assurance role, determines the state based on the level of support and marks the associated observable record as a verified record or a gap record. The following will combine... Figure 8 The specific implementation method of step S5 will be further described.

[0111] In some embodiments, each round may include step S6: an agent, in a quality assurance role, generates second execution evidence associated with the current round based on a labeled support level determination state, a verifiable claim associated with the support level determination state, and the support level determination state.

[0112] In some embodiments, the second software artifact and the second execution evidence are passed to the next round. In some embodiments, observables marked as verified records in the second execution evidence are converted into retention constraints in the next round. In some embodiments, observables marked as gap records in the second execution evidence are converted into update targets and verification requirements in the next round.

[0113] After executing step S6, it can be determined whether the preset number of iteration rounds has been completed (i.e., whether the round index i is less than or equal to the preset number of iteration rounds T). If i ≤ T, the round index i can be incremented by 1, and the method can continue to the next iteration round.

[0114] In some embodiments, the update targets for the development documentation may include build or run blocking items, evidence-supported defect phases, and unmet requirements.

[0115] In some embodiments, the development documentation may prioritize build or run blocking items, evidence-supported defect phases, and unmet requirements in descending order of priority.

[0116] In some embodiments, step S2 may include step S21: modifying, in sequence, the build or run blocking items, the evidence-supported defect items, and the unmet requirements items.

[0117] In some embodiments, items indicated by retention constraints in the development documentation remain available in the current round.

[0118] In some embodiments, observable logs may include at least one of the following: exit status of a build or test, standard output and error output, runtime logs, status traces, screenshots, videos, playback, and asset checks.

[0119] In some embodiments, a second software artifact may be passed to the next round via a first channel for use by development roles. In some embodiments, a second execution artifact may be passed to the next round via a second channel for use by project planning roles. In some embodiments, the first and second channels may be isolated from each other.

[0120] In some embodiments, the method may include an optional step S7: performing an initialization round. This will be discussed in conjunction with... Figure 9 The specific implementation of step S7 will be further described.

[0121] In some embodiments, the method may include an optional step S8: in response to determining that the current round has reached a preset number of iteration rounds, outputting a second software artifact as the final software artifact.

[0122] Figure 7This is a flowchart of a first process associated with a method for software development according to some embodiments of the present invention. The first process may be... Figure 6 The specific implementation of step S1 in the method is described, but the scope of the present invention is not limited thereto.

[0123] In some embodiments, the first process may include step S11: for each observable record marked as a verified record in the first execution evidence, extracting the verifiable claims and reference evidence associated with the observable record, and writing the extracted verifiable claims and reference evidence into the retention constraints of the development document.

[0124] In some embodiments, the first process may include step S12: for each observable record marked as a gap record in the first enforcement evidence, extracting the verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates associated with the observable record; writing the extracted verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates into the update target of the development document; and writing the observables that need to be supplemented by the extracted verifiable claims into the verification requirements of the development document.

[0125] Figure 8 This is a flowchart of a second process associated with a method for software development according to some embodiments of the present invention. The second process may be... Figure 6 The specific implementation of step S5 in the method is described, but the scope of the present invention is not limited thereto.

[0126] In some embodiments, the second process may include step S51: in response to determining that the referenced observable is sufficient to observe the expected behavior, marking the observable as a verified record.

[0127] In some embodiments, the second process may include step S52: in response to observing a failure or unmet verification requirement or retained function regression from the referenced observable record, or determining that the expected behavior is insufficient to be observed from the referenced observable record, marking the observable record as a gap record.

[0128] Figure 9 This is a flowchart of a third process associated with a method for software development according to some embodiments of the present invention. This third process may be... Figure 6 The specific implementation of step S7 in the method is described, but the scope of the present invention is not limited thereto.

[0129] In some embodiments, the third process may include step S71: generating an initial development document based on the task specification.

[0130] In some embodiments, the third process may include step S72: forming a third software artifact associated with the initialization round based on the initial software artifact and the initial development documentation.

[0131] In some embodiments, the third process may include step S73: determining third execution evidence associated with the initialization round based on observations of the first execution of the third software artifact.

[0132] According to another aspect of the present invention, a computer-readable storage medium is provided.

[0133] Figure 10 This is a block diagram of a computer-readable storage medium 1000 according to some embodiments of the present invention.

[0134] In some embodiments, a computer program 1050 may be stored on the computer-readable storage medium 1000. When executed by a processor, the computer program can achieve the above-described combination. Figures 6-9 The methods and processes described.

[0135] According to another aspect of the present invention, a computer program product is provided.

[0136] Figure 11 This is a block diagram of a computer program product 1100 according to some embodiments of the present invention.

[0137] In some embodiments, computer program product 1100 may include computer program 1050. The computer program, when executed by a processor, can implement the above-described combination. Figures 6-9 The methods and processes described.

[0138] The software development process according to embodiments of the present invention is further described below with reference to specific examples of game software development. In this example, a system (e.g., a computing device) can receive natural language game requests and a fully functional game with observable results can be created by a coded intelligent agent. As an example, Godot can be used to implement and run the game project.

[0139] Take a platforming game as a specific example. In this game, players control a character to move and jump, and use actions such as wall jumps to cross platforms or obstacles. During the iterative development of this game, there may be observable issues such as wall jumps being implemented in the code but not clearly shown in replays or screenshots, or hard cuts or blank areas at the edges of levels.

[0140] Table 1 below lists the definitions and specific details of the relevant terms in this application for this example.

[0141]

[0142] The following is an excerpt from player.gd, from the complete software artifact A2 at the end of round 2, concerning wall jumping and camera boundaries: extends CharacterBody2D @export var move_speed := 260.0 @export var jump_speed := 520.0 @export var wall_jump_push := 320.0 @onready var camera: Camera2D = $Camera2D func _ready() -> void: # Limit the camera's field of view to avoid displaying blank areas outside the map. camera.limit_left = 0 camera.limit_top = 0 camera.limit_right = 3840 camera.limit_bottom = 2160 func _physics_process(delta: float) -> void: # Retain the horizontal movement and normal jump from the previous round. var direction := Input.get_axis("move_left", "move_right") velocity.x = direction move_speed if not is_on_floor(): velocity += get_gravity() delta if Input.is_action_just_pressed("jump"): if is_on_floor(): velocity.y = -jump_speed elif is_on_wall(): # Wall jump: Jump in the opposite direction of the wall and then jump upwards. var normal := get_wall_normal() velocity = Vector2(normal.x wall_jump_push, -jump_speed) move_and_slide() The relationship between the above code snippet and the current round object is as follows: horizontal movement and ground jump are existing functions from the previous round and need to be retained; the `is_on_wall()` branch represents the wall jump implementation; `camera.limit_` This indicates the boundaries between the map and the camera. However, the presence of this logic in the code only indicates that it has been written and implemented; it cannot prove that the actual running effect has met the requirements.

[0143] As an example, the update retention constraint for development document D2 in round 2 is: it must not disrupt the original horizontal movement, normal jump, main scene startup, and effective replay.

[0144] As an example, the update goal of development document D2 in round 2 could be: to improve wall jump and set map and camera boundaries so that the wall jump process and boundary effects can be observed.

[0145] As an example, the verification requirement for development document D2 in round 2 could be: start the game and record the continuous process of "wall-jump-away from the wall", and capture the ground... Figure 4 The perimeter screen is checked, and the original movement and normal jumps are re-examined.

[0146] As an example, the specific steps for the second round of development can be as follows.

[0147] Step 1: After the first round, A1 is a working game project. Test materials show that the main scene and some replays are usable, but the wall-jumping process is not clear enough in the replay, and the edges of the level also appear incomplete.

[0148] Step 2: The project planning role generates D2 based on this. This round first fills in the visible wall-jumping process, then adjusts the map and camera boundaries; retains horizontal movement, normal jumps, main scene startup, and effective replays; during acceptance, continuous wall-jumping replays, boundary screenshots, and regression checks must be reviewed again.

[0149] Step 3: Develop the character by directly modifying A1 to obtain A2, instead of creating a new game that is unrelated to the previous round.

[0150] Step 4: The quality assurance role initiates, operates, and observes A2 item by item according to D2, forming C2, and saves the corresponding r for each item. j Then give s j .

[0151] Step 5: These records are merged into E2. The third-round planning role reads E2, writes the verified functions into the retention requirements, and writes the gaps into the next round of repair and re-verification requirements.

[0152] Table 2 below lists the multiple verifiable claims c in this example in round 2. j and the corresponding observable record r j And the degree of support determines the state s i .

[0153]

[0154] Based on the information shown in Table 2, the evidence E2 for the second round of enforcement can be summarized as follows: c1 and c4 have existing materials to prove their validity and must be retained in the next round; c2 and c3 still have gaps, which should be repaired and re-provided in the next round.

[0155] The following presents some verification results of embodiments of the present invention.

[0156] Figure 12 The embodiments of the present invention are shown to vary in iterative performance under different code-writing agent framework-model configurations.

[0157] Figure 12 Three code-writing agent framework-model configurations are shown: Codex+GPT-5.5 (High), Pi+MiniMax-M3, and Opencode+DeepSeek-V4-Pro. The "Base Method" on the horizontal axis represents a single baseline, and iteration rounds 1-3 represent the execution of rounds 1 to 3 according to an embodiment of the invention. The vertical axis of the upper (a) section corresponds to the average total score of GameCraft-Bench, and the vertical axis of the lower (b) section corresponds to the average reward of FrontierSWE. The single baseline points for the three code-writing agent framework-model configurations are illustrated with corresponding legends at the "Base Method" on the horizontal axis. The results show that the method according to the embodiment achieves higher scores / rewards on both benchmarks across the three code-writing agent framework-model configurations compared to the base method, with increasing rounds.

[0158] Figure 13 The embodiments of the present invention are shown to compare the performance of the base method across various quality dimensions under different code-writing agent framework-model configurations.

[0159] Figure 13 The middle shows with Figure 12The same three code-writing agent framework-model configurations are presented in Parts (a), (b), and (c), respectively, showing the performance of the embodiments' techniques compared to the base method in four quality dimensions: "mechanism," "content," "functionality," and "art." The results show that, under all three code-writing agent framework-model configurations, the methods according to the embodiments outperform the base method in all four quality dimensions.

[0160] Figure 14 According to embodiments of the present invention, key mechanism ablation results are obtained regarding final product quality and cumulative inference dosage.

[0161] Figure 14 The left graph compares the average total score of the final artifacts, while the right graph compares the average cumulative number of lexical units consumed per task by the code-writing agent. The ablation mechanisms were removal of development documentation updates, removal of evidence feedback, and removal of warm starts. The results show that all three ablation versions scored lower than the technology of the complete embodiment. Furthermore, the results regarding the number of lexical units consumed also show that the highest number of lexical units were consumed after removing warm starts, further illustrating that the continuity of software artifacts not only affects quality but also the overhead of repeated implementations.

[0162] Various embodiments of the invention have been described with reference to the accompanying drawings, which are illustrative and not restrictive.

Claims

1. A computing device for software development, characterized in that, include: Computing resources; The orchestration control module is used to control the operations between multiple rounds in the software development process, as well as the operations within each round. The intelligent agent is used to invoke the computing resources to perform corresponding operations in each round, under the control of the orchestration control module, in a predetermined order, as a project planning role, a development role, and a quality assurance role, respectively. In the current round, The agent is configured as the project planning role to perform the following steps: S1: Based on the task specifications associated with the software to be developed and the first execution evidence obtained up to the end of the previous round, determine the development documents associated with the current round, the development documents including retention constraints, update objectives and verification requirements; The agent is configured as the development role to perform the following steps: S2: Based on the task specifications and the development documents, modify the first software artifact obtained up to the previous round to form a second software artifact associated with the current round; The agent is configured as the quality assurance role to perform the following steps: S3: Calculate a set of verifiable claims associated with the current round based on the task specifications and the development documentation, wherein the set of verifiable claims includes multiple verifiable claims; S4: For each verifiable claim, based on the second software artifact and the verifiable claim, determine the observable records associated with the verifiable claim, and determine the support level determination status associated with the verifiable claim; S5: Based on the level of support, determine the status and mark the associated observable records as verified records or gap records; S6: Based on each verifiable claim, the observables associated with that verifiable claim, and the level of support associated with that verifiable claim, determine the state and generate second execution evidence associated with the current round. In this process, the second software artifact and the second execution evidence are passed to the next round, and the observable records marked as verified records in the second execution evidence are converted into retention constraints in the next round, while the observable records marked as gap records in the second execution evidence are converted into update targets and verification requirements in the next round.

2. The computing device as described in claim 1, characterized in that, S1 includes: S11: For each observable record marked as a verified record in the first execution evidence, extract the verifiable claims and reference evidence associated with the observable record, and write the extracted verifiable claims and reference evidence into the retention constraints of the development document.

3. The computing device as described in claim 1, characterized in that, S1 includes: S12: For each observable record marked as a gap record in the first execution evidence, extract the verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates associated with the observable record, write the extracted verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates into the update target of the development document, and write the observable results that need to be supplemented for the extracted verifiable claims into the verification requirements of the development document.

4. The computing device as claimed in claim 1, characterized in that, The update targets in the development documentation include build or run blocking items, evidence-supported defects, and unmet requirements.

5. The computing device as described in claim 4, characterized in that, The development documentation lists the build or runtime blocking items, supported defects, and unmet requirements in descending order of priority. S2 includes: S21: Modify the construction or operation blocking item, the evidence-supported defect item, and the unmet requirement item in sequence.

6. The computing device as claimed in claim 1, characterized in that, The items indicated by the retention constraints in the development documentation remain available in the current round.

7. The computing device as claimed in claim 1, characterized in that, The observable logs include at least one of the following: exit status of the build or test, standard output and error output, runtime logs, status traces, screenshots, videos, replays, and asset checks.

8. The computing device as claimed in claim 1, characterized in that, S5 includes: S51: In response to determining that the referenced observable is sufficient to observe the expected behavior, mark the observable as a verified record; S52: In response to observing a failure or unmet validation requirement or retained function regression from the referenced observable record, or determining that the expected behavior is insufficient to be observed from the referenced observable record, the observable record is marked as a gap record.

9. The computing device as claimed in claim 1, characterized in that, The second software artifact is passed to the next round through the first channel for the development role to call, and the second execution evidence is passed to the next round through the second channel for the project planning role to call, wherein the first channel and the second channel are isolated from each other.

10. The computing device as claimed in claim 1, characterized in that, The agent is also configured to perform the following steps: S7: Execute the initialization round, wherein S7 includes: S71: Generate initial development documentation based on the task specifications; S72: Based on the initial software artifact and the initial development documentation, a third software artifact associated with the initialization round is formed; and S73: Based on observations of the first execution of the third software artifact, determine third execution evidence associated with the initialization round.

11. The computing device as claimed in claim 10, characterized in that, The initial software artifacts include empty workspaces, scaffolding projects, or existing warehouses.

12. The computing device as claimed in claim 1, characterized in that, The agent is also configured to perform the following steps: S8: In response to determining that the current round has reached a preset number of iteration rounds, output the second software artifact as the final software artifact.

13. A method for software development, characterized in that, Includes the following steps: The orchestration control module controls the intelligent agents to perform corresponding operations in a predetermined order, assuming the roles of project planning, development, and quality assurance. Each of the multiple rounds in the software development process includes the following steps: S1: The intelligent agent, in the role of project planning, determines the development document associated with the current round based on the task specifications associated with the software to be developed and the first execution evidence obtained up to the end of the previous round. The development document includes update objectives, retention constraints, and verification requirements. S2: The intelligent agent, in the development role, modifies the first software artifact obtained up to the previous round based on the task specifications and the development documents to form a second software artifact associated with the current round. S3: The agent, in the role of quality assurance, calculates a set of verifiable claims associated with the current round based on the task specifications and the development documents. The set of verifiable claims includes multiple verifiable claims. S4: The intelligent agent, in the quality assurance role, determines the observable records associated with the verifiable claim based on the second software artifact and the verifiable claim for each verifiable claim, and determines the support level determination state associated with the verifiable claim; S5: The agent, in accordance with its quality assurance role, determines the state based on the level of support and marks the associated observable record as a verified record or a gap record; and S6: The agent, in the quality assurance role, generates a second execution evidence associated with the current round based on the labeled support level determination state, the verifiable claims associated with the support level determination state, and the support level determination state. In this process, the second software artifact and the second execution evidence are passed to the next round, and the observable records marked as verified records in the second execution evidence are converted into retention constraints in the next round, while the observable records marked as gap records in the second execution evidence are converted into update targets and verification requirements in the next round.

14. The method as described in claim 13, characterized in that, S1 includes: S11: For each observable record marked as a verified record in the first execution evidence, extract the verifiable claims and reference evidence associated with the observable record, and write the extracted verifiable claims and reference evidence into the retention constraints of the development document; S12: For each observable record marked as a gap record in the first execution evidence, extract the verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates associated with the observable record, write the extracted verifiable claims, observed failures or insufficient evidence, user impact, and suggested updates into the update target of the development document, and write the observable results that need to be supplemented for the extracted verifiable claims into the verification requirements of the development document.

15. The method as described in claim 13, characterized in that, The update targets in the development documentation include build or run-blocking items, evidence-supported defects, and unmet requirements. The development documentation lists the build or runtime blocking items, supported defects, and unmet requirements in descending order of priority. S2 includes: S21: Modify the construction or operation blocking item, the evidence-supported defect item, and the unmet requirement item in sequence.

16. The method as described in claim 13, characterized in that, The items indicated by the retention constraints in the development documentation remain available in the current round, and The observable logs include at least one of the following: exit status of the build or test, standard output and error output, runtime logs, status traces, screenshots, videos, replays, and asset checks.

17. The method as described in claim 13, characterized in that, S5 includes: S51: In response to determining that the referenced observable is sufficient to observe the expected behavior, mark the observable as a verified record; S52: In response to observing a failure or unmet validation requirement or retained function regression from the referenced observable record, or determining that the expected behavior is insufficient to be observed from the referenced observable record, the observable record is marked as a gap record.

18. The method as described in claim 13, characterized in that, The second software artifact is passed to the next round through the first channel for the development role to call, and the second execution evidence is passed to the next round through the second channel for the project planning role to call, wherein the first channel and the second channel are isolated from each other.

19. The method as described in claim 13, characterized in that, It also includes the following steps: S7: Execute the initialization round, wherein S7 includes: S71: Generate initial development documentation based on the task specifications; S72: Based on the initial software artifact and the initial development documentation, a third software artifact associated with the initialization round is formed; and S73: Determine third execution evidence associated with the initialization round based on observations of the first execution of the third software artifact; and S8: In response to determining that the current round has reached a preset number of iteration rounds, output the second software artifact as the final software artifact.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 13 to 19.

21. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 13 to 19.

Images