Document view in an application development environment for exectuable generation

Abstract

A method and system for executable generation via an application development environment are provided. The method may include obtaining a textual description of a code module forming part of a codebase. The textual description may be a description of functionality of the code module. The method may include outputting the textual description to a document view displayed via a graphical user interface. The textual description may be editable via the document view. The method may include receiving a textual description edit to edit the textual description of the code module. The code module may be updated based on the textual description edit. The method may include receiving a code module edit and updating the textual description based on the code module edit. The updated textual description may be output to the document view. The document view may be updated in response to updates to the code module and vice versa.

Description

[0001] DOCUMENT VIEW IN AN APPLICATION DEVELOPMENT ENVIRONMENT FOR EXECTUABLE GENERATION

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority from United States provisional patent application number 63 / 634,740 filed on 16 April 2024, which is incorporated by reference herein.

[0004] FIELD

[0005] This disclosure relates generally to arrangements for software development and / or software engineering, including an application development environment for software design and / or the creation or generation of source code and / or executable code. More particularly, although not exclusively, this disclosure relates to an application development environment providing a document view and systems and methods relating thereto.

[0006] BACKGROUND

[0007] Development of application software can entail collaboration between a large number of participants, each having different skillsets and different levels of technical understanding. It is felt that currently available application development environments do not sufficiently support or foster collaboration, in particular across participants with different skillsets and different technical understanding. For example, there may be a disconnect between business analysts driving product requirements on the one hand and software developers building the application software in line with these requirements on the other hand. It is therefore felt that there is scope for improvement.

[0008] The preceding discussion of the background is intended only to facilitate an understanding of the present disclosure. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application.

[0009] SUMMARY

[0010] In accordance with an aspect of the present disclosure there is provided a computer-implemented method for executable generation comprising; obtaining a textual description of a code module of a plurality of code modules providing a codebase; outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

[0011] The document view may provide a “what you see is what you get” view of a document. The method may include receiving input of an edit. The edit may be the textual description edit or the code module edit. The method may include receiving input of the textual description edit or receiving input of the code module edit from a human user or an agent module.

[0012] The user interface may provide a chat window via which a human user can interact with other human users and with an agent module associated with the code module. The method may include receiving input of the textual description or the code module edit from the agent module in response to an interaction via the chat window.

[0013] The code module may be represented by a functional element instance created from a functional element template. The code module may be uniquely associated with an agent module created for the functional element instance and configured to update the code module by updating the associated functional element instance. The functional element instance may be in the form of a schema validation-based file configured for generating and updating the code module.

[0014] Obtaining the textual description of the code module may include the agent module generating the textual description of the code module based on the functional element instance. Generating the textual description of the code module based on the functional element instance may include using a language model.

[0015] Updating the code module based on the textual description edit may include the agent module generating an updated code module from the edited textual description thereof using the functional element instance. Generating the updated code module from the edited textual description thereof may include using a language model.

[0016] Generating the updated code module from the edited textual description thereof may include compiling a prompt including one or more of: the edited textual description; the functional element instance; and information derived from the functional element instance. Generating the updated code module from the edited textual description thereof may include inputting the prompt into the language model. Generating the updated code module from the edited textual description thereof may include receiving an updated functional element instance from the language model Generating the updated code module from the edited textual description thereof may include generating the updated code module from the updated functional element instance.

[0017] Information derived from the functional element instance may include: information relating to the type of functional element instance; and, configuration of the functional element instance. The configuration of the functional element instance may include validated data points.

[0018] The code module may be a block of code. Updating the code module based on the code module edit may include updating the block of code based on the edit. The codebase may be provided for compiling into an executable.

[0019] The code module and textual description thereof may be associated with a context of development. Receiving input of the textual description edit or the code module edit is while the associated context of development is active. The context of development may be defined by a section of the document view in which the textual description is output. The context of development may be activated by selecting or interacting with the section of the document view.

[0020] The method may include validating input of the textual description edit, including using a change intercepting workflow. Validating input of the textual description edit may include initiating the change intercepting workflow in response to detecting one or more predefined conditions associated with the textual description edit.

[0021] The one or more predefined conditions may include: editing a project name, description or purpose; editing a role name, description, purpose or restriction; adding or removing an interaction; and, editing an action name.

[0022] In accordance with a further aspect of the present disclosure there is provided a system for executable generation comprising a non-transitory computer-readable storage medium, and one or more processors coupled to the non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium comprises program instructions that, when executed on the one or more processors, cause the system to perform operations comprising: obtaining a textual description of a code module of a plurality of code modules providing a codebase; outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

[0023] In accordance with a further aspect of the present disclosure there is provided a system for executable generation including a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the system comprising: a textual description obtaining component for obtaining a textual description of a code module of a plurality of code modules providing a codebase; a textual description outputting component for outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; a code module updating component for, in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, a textual description updating component for, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

[0024] In accordance with a further aspect of the present disclosure there is provided a computer program product for executable generation comprising a computer-readable medium having stored computer-readable program code for performing the steps of: obtaining a textual description of a code module of a plurality of code modules providing a codebase; outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

[0025] Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

[0026] Embodiments will now be described, by way of example only, with reference to the accompanying drawings.

[0027] BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In the drawings:

[0029] Figure 1 is a schematic diagram which illustrates an example application development environment according to aspects of the present disclosure;

[0030] Figure 2A is a schematic diagram which illustrates example networks of functional element instances and associated agent modules according to aspects of the present disclosure;

[0031] Figure 2B is a schematic diagram which illustrates an example treelike construct of functional element instances in accordance with aspects of the present disclosure;

[0032] Figure 3 is a schematic diagram which illustrates an example computing system on which the application development environment of Figure 1 may be hosted;

[0033] Figure 4 is a flow diagram which illustrates an example method executed within an application development environment according to aspects of the present disclosure;

[0034] Figure 5A is a flow diagram which illustrates an example method for updating a code module of a codebase and / or a corresponding textual description according to aspects of the present disclosure; Figure 5B is a flow diagram which illustrates an example chat management method according to aspects of the present disclosure;

[0035] Figure 5C is a flow diagram which illustrates an example method for validating input of an edit according to aspects of the present disclosure;

[0036] Figure 6A is a schematic diagram which illustrates an association between an agent module, a code module and a textual description of the code module within a given context of development according to aspects of the present disclosure;

[0037] Figure 6B is an example screen shot of a graphical user interface according to aspects of the present disclosure;

[0038] Figure 7 is a flow diagram which illustrates a method of converting a first type of content into a second type of content according to aspects of the present disclosure;

[0039] Figure 8 is a flow diagram which illustrates an example method performed by an agent module associated with a functional element instance in accordance with aspects of the present disclosure;

[0040] Figure 9 is a block diagram which illustrates example components which may be provided by a computing system for executable generation in accordance with aspects of the present disclosure; and,

[0041] Figure 10 illustrates an example of a computing device in which various aspects of the disclosure may be implemented.

[0042] DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

[0043] An application development environment for executable generation is described. The application development environment provides a document model or document-based development interface via a document view. The document view outputs a document that describes the application software under development. The document may be a 'living document' where changes can be made to the document which in turn changes or updates a codebase providing the application software, or vice versa. Multiple views of the document may be possible via respective user terminals, such that different participants can collaborate in the document to build and update the codebase. An inline chat functionality via a chat window may be provided via which participants can chat contextually in the document. The chat may be archived once resolved to become part of the record. In some examples, the chat may include text, audio and / or video chats embedded within the chat window. Participants can use the chat window to suggest changes to the document and / or the underlying codebase, which changes may be implemented by an agent module associated with the context in which the participants are chatting. In some cases, as participants move from one section of the document to another, the context of development changes and in turn the relevant agent module called to implement changes or otherwise assist with development (e.g. by responding to queries) changes. In this manner, moving to different sections of the document changes the context (e.g. from space to role to action, etc.) and hence so too does the agent module that handles the participant requests and / or changes. The chat may be workflowbased in that the various participants work towards an end (such as an agreeable change or edit that meets any relevant validation criteria), at which point the changes or edits can be promulgated to the codebase (via connected agent modules) and the chat can be archived. Some types of changes may require validation and subsequent revision via the chat when, for example, implementation of the change is detected to have the potential to cause an unintended knock-on effect to the codebase.

[0044] Figure 1 is a schematic diagram which illustrates an example application development environment (100) according to aspects of the present disclosure. The application development environment (100) provides a graphical user interface (10) via which an end-user can build a codebase (12) via either of: a low-code view (14) or a document view (16). The document view may provide a document editor, such as a cloud-based “what you see is what you get” document editor which permits an end-user to edit and manipulate the look and content of a document directly. The codebase may be a collection of modules (109.1 -109.5) of source code (“code modules”) which provides a particular software system, application, or software component (hereinafter “application software”). The application development environment may further provide a chat window (18) via which participants - including human end-users and / or various agent modules (1 10.1 , 110.5) included in an agent network (19) provided by the application development environment - may chat with each other.

[0045] The application development environment may be provided by an application development platform (101 ) which is accessible to a plurality of participants including human end-users via their respective user terminals (20) and optionally various machine learning-based agent participants (such as the one or more agent modules described herein). The development platform may be accessible to the user terminals via a communication network (22), such as the internet.

[0046] The development platform may be provided by a computing device or computing devices and may include or have access to one or more processors (24) for executing the functions of components described below, which may be provided by hardware or by software units executing on the development platform. The software units may be stored in a memory (26) and instructions may be provided to the one or more processors to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and / or process data on behalf of the development platform may be provided remotely.

[0047] The application development environment includes a template library (102) of functional element templates (104, 106) from each of which one or more functional element instances can be created. Creation of a functional element instance may entail one or more of: creation of a visual representation thereof in the low-code view (14); creation of an end-user (human) readable textual description thereof in a document view (16); creation in the codebase (12) of a code module (e.g., 109.1 ) corresponding to the functional element instance; and, initiation or spawning in the agent network (19) of an agent module (1 10.1 ) linked to the functional element instance. In some examples, the library (102) includes agent module templates (161 ) from which instances of agent modules can be created. There may for example be an agent module template for each type of functional element instance template.

[0048] The term “textual description” of the code module as used herein should be interpreted to include a plain language (or prose) description of the code module. In other words, the textual description may be in a form of written language that follows the natural flow of speech, a language's ordinary grammatical structures, or typical writing conventions, formatting and the like. The description may be a description of the functionality of the code module. For example, the description may state the purpose that the code module is designed or expected to fulfill. For example, the description may include details relating to the purpose, configuration, attributes, characteristics, dependencies of the code module, and the like. The textual description of the code module should be distinguished from the code module itself, and from the functional element instance associated therewith. The code module may be actual code (e.g. source code) compliant with relevant syntactical constraints of the programming language in which it is written (such as Python, C++, Rust, or the like). Likewise, the functional element instance may be in the form of a schema validation-based file representing structured data (such as JSON, XML, BPML or the like).

[0049] The library of functional element templates may be dynamic with new functional element templates being added and retired functional element templates being removed over time. The functional element templates may be grouped into different types of functional element templates (e.g. including “spaces”, “steps”, “roles”, “interactions” “flows” and “agents”). It follows that a functional element instance created from a functional element template will be of the same type as that of the template from which it is created. Although the illustrated example shows only a first group (104) and a second group (106) of functional element template types, a practical implementation may have a plurality of such groups. Each group of functional element type may include one or more functional element templates (e.g. there may be a plurality of functional element templates within a functional element type). There may for example be functional element templates for each of “spaces”, “steps”, “roles”, “interactions” “flows” and “agents”.

[0050] In an example application development environment, spaces may provide a container mechanism that allows one to create servers, services and / or microservices. Spaces may represent a functional unit of an organization or a collection of system-specific components. Each space is the boundary of the infrastructure where all other components are housed. Interactions (actions or reactions) connect or point to process flows. Actions are grouped by roles and are used to trigger process flows. Interactions could be considered analogous to application programming interface (API) endpoints. Participants (including end-users and / or agent modules), other spaces, or external systems may connect to roles as agents. Many agents can connect to the same role and agents can be connected to multiple roles. Roles may limit rights to specific agents that take on that role. A role is what an agent authenticates against. Roles are used to manage authentication and permissions. Flows are process flows which contain steps. A flow may be a workflow which is triggered by an action and contains the logic of how steps are connected. Steps are the building blocks of flows and may be termed building block functions. A step may define a block or snippet of functional code that is run when that part of a flow is reached. A step may take inputs from previous steps in a flow and will often result in an output being returned.

[0051] A functional element template may be provided by a schema-based validation file, which may for example be in the form of a small discrete file that has scaffolding (definitions) or shells defined in a text-based data interchange format for representing structured data based on syntax. The scaffolding tells the compiler how to operate, the version information, etc. For example, the scaffolding may be provided as JavaScript™ Object Notation (JSON™). JSON is a standard textbased format for representing structured data based on JavaScript object syntax commonly used for transmitting data in web applications. In another example, the scaffolding may be provided in Extensible Markup Language (XML), Business Process Modelling Language (BPML - an XML- based language for business process modelling), YAML (a human-readable data-serialization language) or the like. The functional element templates may provide visual building tools associated with each of spaces, roles, agents, interactions, flows and steps. A functional element instance created from a functional element template may be configured for configuration and interconnection via the low-code view. Visual representations of configured functional element instances may be based on or provided by the visual building tools. A configured functional element instance may be in the form of a schema validation-based file including configuration parameters, details, data points or the like that govern the particular operation of that instance of the functional element template. The visual building tools may be manipulated by one or more of the plurality of participants via the user interface for configuration and interconnection of representations of building-block functions in order to generate application software.

[0052] The low-code view may include functionality for connecting an action and / or reaction to a flow graph and in turn assigning one or more roles and / or agents to a flow graph. Each flow graph may be built up with a number of steps, each of which is based on a step macro.

[0053] A step macro may be made up of one or more files, each of which includes one or more functions. In some cases, a step macro may also refer to other files (that are not a part of the step macro) during compilation. Each step macro may be configured for configuration and interconnection via the low-code view to generate source code and / or executable code. Step macros may be configured and interconnected in the user interface to build a flow graph. The flow graph may be a visual flow that is drawn in the low-code view and displays how various steps in the flow reference each other. Each step in a flow may be an instance of a type of step macro that can be interconnected with other steps (being instances of the same or other types of step macros) and configured via the user interface. Each step may be associated with a block of executable code which may form a part of the codebase (e.g., being a particular computer program or application software that is being developed), which may include executable code of multiple steps in a flow. The flow graph may be a schematic representation of source code (e.g., in: Python, Rust, Elixir or the like) and / or executable code that is generated through configuration and interconnection of step macros.

[0054] Each flow graph may be a definition of the following components: visual instructions on how the low-code view should display them; the control flow with order of steps with each step defining what to call next (such as a branches field, an inner routing field and a settings field, etc.); and the code modules to execute before proceeding (such as the code modules to execute in combination with the configuration values before proceeding). The visual instructions and the control flow may be combined and leveraged to allow for the visual modelling and defining of the logic of the code around the modules that are actually executed. The development environment described herein may be configured to derive a visual representation of code, the flow graph, from the code itself.

[0055] The graphical user interface (10) may be displayed to the participants via their respective user terminals, which may be in the form of a computing device. The low-code view of the graphical user interface may define a bounded context in the form of a space in which roles and actions, and ultimately the codebase, relating to a functional unit within an organization, for example, can be described. The bounded context may be represented graphically in the low-code view as a circle or other shape to which and in which actions or roles may be added and configured. The user interface may include functionality for managing actions and roles. The user interface may include functionality for managing actions against a role, setting permissions for a role, assigning agents to one or more roles and the like. Managing actions against roles may allow for control as to which agents (being users or systems) can call which actions (based on the role to which they are assigned).

[0056] The application development environment may include a chat engine (118) which provides a chat function for chat between the participants accessing the development environment. The chat engine may support multimodal chat by way of which participants can exchange any one or more of text, audio, images, videos and the like. The chat engine and chat window may support text, audio, video and / or virtual environment-based chat (such as through avatars in the metaverse). The chat engine allows participants to chat with one another while viewing the user interface displayed via their respective user terminals. The user interface may be in the form of a shared screen or may include a shared area or zone which is visible to all participants in the chat. In this manner, manipulation, for example, of a graphical element within the user interface by one participant may be simultaneously visible to the other participants. In some examples, chats are bound to a context of development, and as a participant moves through different contexts of development (e.g. by moving through different sections of a document view), the chat engine may call and output, via the chat window, different chat histories associated with the different contexts of development. The chat engine may also be configured to archive a chat history once it has been marked resolved and once any change being discussed therein has been made and promulgated through to the codebase.

[0057] The application development environment may include a document engine (1 19) which provides the document view (16) via the graphical user interface (10). The document engine may compile a document from textual descriptions of code modules generated in accordance with aspects of the present disclosure. The document engine may be configured to interact with the agent modules of the agent network to update different sections of the document based on updated textual descriptions of the corresponding code modules. Although the term “sections” in the context of the document implies different sections of the same document, in some examples each of the different sections is in the form of a discrete document and the collection of discrete documents together make up documentation describing the codebase and hence the application under development.

[0058] The development environment may include an agent spawning component (133) and an agent management component (135). The agent spawning component may be configured to spawn agent modules, which may include creating an instance of an agent module from an agent module template. Each instance of an agent module may be bounded by or linked to a particular context. For example, an agent module that is spawned for a functional element instance may be bounded by or linked to the context of that functional element instance. The agent spawning component may make use of agent module templates for the purpose of spawning new instances.

[0059] The agent management component may be configured to manage the plurality of spawned (i.e., living) agent modules, for example by switching different agent modules between active and passive modes of operation (or otherwise calling or flagging or initializing an agent module) based on a changing context within the development environment. Managing the agent modules may include managing permissions of the respective agent modules, for example by changing permissions relating to output of information to the user interface (via one or more of: the low- code view, the document view or the chat window). The permissions may for example be toggled between enabled (in which case information can be output via the user interface) and disabled (in which case information cannot be output via the user interface). In some cases, managing the agent modules may include managing the manner in which information is communicated, for example either via the user interface or through a communications system that alerts participants or other agent modules to the outputs for consideration and / or action by a participant or agent module.

[0060] An agent module operating in an active mode of operation may have permission to output information to the user interface. An agent module operating in a passive mode of operation, on the other hand, may not have permission to output information to the user interface, and may instead store such information and trigger a notification or message via a communications component which prompts the participants to review the information and optionally change context to the context of the functional element instance with which the relevant agent module is associated.

[0061] For example, the agent spawning component may spawn an agent module for each functional element instance created in the development environment. While participants are working on a particular functional element instance, the agent module spawned for that functional element instance may operate in an active mode in which information can be output to and rendered visually via the user interface for participants to interact with. In other words, while active in the active mode of operation, the agent module may actively contribute to the development process. While this occurs, other agent modules spawned for other functional element instances may operate in a passive mode. In this mode, they may continue to receive and process messages to output information. However, in the passive mode of operation, such information may be stored and / or communicated to participants and / or other agent modules for review and / or consideration before causing an update to the codebase.

[0062] In response to participants moving to work on another functional element instance (for example by selecting, clicking on or discussing in chat a particular functional element instance or textual description of a code module associated therewith), and thus changing the context, the agent management component may be configured to switch the agent module spawned for the functional element instance which is now the focus to the active mode and to switch the previously active agent module to the passive mode.

[0063] Referring now to Figure 2A, when a functional element instance is created (e.g. 108.1 ) from a functional element template, it can be associated with (or linked to) one or more other functional element instances (e.g. 108.2-108.5) in the workspace. The association of the functional element instance (108.1 ) to the one or more other functional element instances (108.2-108.5) may be either that of: child; or parent. In this manner, the functional element instances may be arranged in a hierarchy. In one example, hierarchy may be determined at least in part by the type of functional element template, for example starting with a space, then one or more roles, then one or more interactions, then one or more flows and then one or more steps, etc. For each functional element instance that is created, an agent module (e.g. 110.1 ) is created or spawned for that functional element instance. In this manner, an agent network (19) of agent modules (1 10.1 - 1 10.5) is built up over time. The network of agent modules may mimic the hierarchy, structure, or dependencies of the functional element instances.

[0064] Each functional element instance (108.1 -108.5) may be associated with an address which uniquely identifies it. Similarly, each of the one or more agent modules (110.1 -110.5) are also associated with an address unique to that agent module. In this manner, a functional element instance may be associated with one or more other functional element instances by way of addresses such that the functional element instance either addresses or is addressable by the one or more other functional element instances. Similarly, an agent module may be associated with one or more other agent modules by way of addresses such that the agent modules either addresses or is addressable by the one or more other agent modules.

[0065] Each functional element instance (108.1 -108.5) represents a code module (109.1 -109.5), being a block of code (such as source code) forming part of the codebase (12) being developed in the application development environment for compiling into executable code. As described above, the functional element instances are configurable thereby to configure the underlying source code which they represent. Configuration may be validated using schema validation and a schema associated with the functional element instance or template from which the functional element instance is created. Furthermore, graphical representations of each of the functional element instances may be rendered and output to the low-code view (14) and / or document view (16). In this manner a graphical representation of the instance of the functional element can be output via a graphical user interface in which the association between the instance of the functional element and the other instances of the functional element or the instances of other functional elements is rendered graphically.

[0066] Configuration of the functional element instances can be via the graphical representations thereof: for example, in the low-code view, by dragging them around, connecting them to other functional element instances, inputting configuration into fields, etc.; and, in the document view, by editing descriptions thereof, headings thereof, and the like. In some cases, configuration of the functional element instances may be via an agent module, via speech-to-text conversion, or the like.

[0067] As mentioned, in some examples, the functional element templates and associated instances may be of a type selected from space, role, interaction, flow and step. Referring now to Figure 2B, in use of the development environment to build a given codebase, as development progresses, the codebase can be defined as a treelike construct, where the tree can have a plurality of spaces (160B-160H), which in turn, contain roles (162B-162C), which in turn contain interactions (164), which in turn contain flows (166), which in turn contain steps (168). It should be appreciated that although limited numbers of spaces, roles, interactions, flows and steps are illustrated in Figure 2B, a practical application of the development environment described herein may support a plurality of each of these, with each of the plurality of spaces having a plurality of roles, each of the plurality of roles having a plurality of interactions, and so on. As these different types of functional element templates are deployed, an instance of an associated agent module may be spawned for that functional element instance in that context. In this manner, an agent module is spawned for each functional element instance that is created. Further, each agent module may be bounded by the context in which it is created. By switching between contexts, the different agent modules may be activated or brought into a foreground mode of operation depending on the context to which the agent module is bound.

[0068] In this manner, as participants collaborate down the line, they can navigate to different parts (nodes) of the tree, and in so doing they change the context of where they collaborate. This navigation can be via the low-code view or the document view. Each node of the tree is linked to a functional element instance and associated agent module and may for example be in the form of a space, role, interaction, flow, or step. So, wherever a participant (or a meeting of participants) moves to a node, there will be a 'local' agent module associated therewith which is configured to assist in the building or altering of that functional element instance, and in turn the code module and graphical representation thereof. As participants move through different contexts, the agent modules continue to live in perpetuity while they observe activity and provide direct feedback about that node through chat, by messaging or the like.

[0069] It should be appreciated that different groups of participants may collaborate on different nodes of the application software at any given time. For example, there might be a group of participants in a virtual meeting room working on a space (e.g., 160A) and another group of participants in another virtual meeting room working on another space (e.g., 160B). Further, participants can use the document view to select a particular context and in turn the associated agent module. This may for example be by placing a cursor in the section of the document that describes the relevant functional element instance.

[0070] In a large project there could be thousands of these agent modules available at all times. Thus, while at the beginning of a project there may be one agent module for each of the functional element instances of the development environment at the top layer, as development progresses, further agent modules may be spawned, one additional agent module for each node in the tree, which will be long-lived and available when needed.

[0071] Changing context within the development environment may be via the user interface. This may be through clicking in a different area of the user interface (e.g., by clicking on a visual representation of a role or a step, etc.), based on certain keywords or key phrases in the chat (e.g., “Hey Trixta, let’s discuss roles” to activate an agent module for roles), placing a cursor in or otherwise navigating to a particular section of a document in the document view, or the like. In some cases, the one or more agent modules can be toggled between active and passive modes of operation based changing contexts. Changing contexts changes the agent module responsible for implementing changes.

[0072] Referring now to Figure 3, the development environment may execute on a computing system, such as cloud or on-premises computing infrastructure (200). The computing infrastructure may be made up of one or more nodes (202, 204, 206), each of which is provided by a computing device. In some examples, the computing infrastructure is decentralized. Each functional element instance (e.g. 108.1 , 108.2) may be embodied by a process (210, 212). In some examples, each process may be replicated across the one or more nodes such that a plurality of each of the processes (210.1 , 210.2, 210.3, 212.1 , 212.2, 212.3) execute across the plurality of nodes. Each of the processes may be analogous to an actor implemented by a function in a multi-actor model. Each process is addressable by and can address the other processes with which it is associated for sending and receiving messages. Each of the processes may be configured to communicate with each other by sending and receiving messages.

[0073] The messages may be received in a mailbox and stored in the order in which they are received. The messages may be stored until a receiving process takes them out to be read. In this manner, the processes implement asynchronous message passing. The processes described herein may be configured to share no state with each other. An estimated minimal overhead for each process is about 300 words, which means that many processes can be created without degrading performance. As the processes communicate using message passing instead of shared variables, any need for explicit locks may be obviated. In some examples, inter-process communication may work via a shared-nothing asynchronous message passing system. This may entail every process having a mailbox to define a queue of messages that have been sent by other processes and not yet consumed. A process may use a receive primitive to retrieve messages that match desired patterns. A message-handling routine may test messages in turn against each pattern, until one of them matches. When the message is consumed and removed from the mailbox the process resumes execution. A message may comprise any structure, including for example primitives (such as integers, floats, characters, atoms), tuples, lists, functions and the like.

[0074] Each functional element instance (108.1 , 108.2) may be allocated a portion of memory (216) dedicated to the underlying process and which represents a state machine (214.1 , 214.2) for the functional element instance. The memory (216) in which the portion of memory may be allocated may be provided by a distributed database management system (218) accessible by the one or more nodes. The state machine for a functional element instance may be updated in response to receiving a message from another process. The update may be based on the content of the message. The updated state machine is accessible to the one or more nodes executing the process. The state machine may store contextual information usable by an associated agent module in processing messages to obtain actions. It follows that for each functional element instance (108.1 ) that is associated with one or more other functional element instances (108.2), the underlying process (210) of that functional element is associated with one or more other processes (212) based on the association between the functional element instances such that messages can be exchanged between the process and the other processes.

[0075] Each functional element instance is associated with an agent module (110.1 -1 10.5). As mentioned, the application development environment is configured to create an agent module (e.g. 110.1 ) associated with a functional element instance (e.g. 108.1 ) when the functional element instance is created from its corresponding functional element template. In this manner, each functional element instance has its own agent module. Each agent module is unique to the functional element instance for which it is created and persists for as long as the functional element instance persists. Each agent module may itself be a process which may execute on the one or more nodes.

[0076] Agent modules may have access to one or more language models (232, 234). The language models may be large language models (LLMs). The language models may be provided by a model platform (230) and may for example be accessible via API or other interfaces. In some cases, bespoke language models are provided for agent modules of specific functional element types. In some examples, certain types of agent module have access to certain types of language models. For example, agent modules associated with higher level functional element instances may have access to more powerful, general purpose language models. Agent modules associated with lower-level functional element instances may have access to smaller, less powerful and in some cases more specific language models. In some scenarios, the smaller and less powerful language models may consume fewer computational resources and provide faster output to the agent modules. The agent modules may select a language model based on the context, such as the functional element instance that the agent module is associated with. The language models may be configured to generate outputs in a schema validation-based format representing structured data.

[0077] The agent modules described herein may serve various functions, including performing one or more actions. For example, they may aid the development team during the creation and refinement of the application by offering intelligent suggestions, thereby increasing efficiency and reducing potential errors. Secondly, post-development, they may interact with operational users (e.g. post-development users of the resulting application software), helping them navigate and make the most of the application’s functionalities. For instance, agent modules can take input from users, guide them through complex workflows, or provide them with relevant information as needed. Importantly, these agent modules are not transient or session-based; they are long-living modules that exist for as long as the application itself. This constant presence of agent modules may help provide a persistent level of support and guidance for users and builders alike.

[0078] The application development environment described herein may be distributed, fault-tolerant, real-time, highly available and configured for live updates to a block code which can be propagated through other blocks of code automatically with little to no human intervention.

[0079] Figure 4 is a flow diagram which illustrates an example method according to aspects of the present disclosure. The method may be conducted by one or more computing devices. The method may be conducted by an application development platform providing an application development environment, such as that described above with reference to Figures 1 to 3.

[0080] The method may include creating or initializing (402) a functional element instance from a functional element template and associating (404) the functional element instance with one or more other functional element instances in the development environment. The association may define a dependency between the newly created functional element instance and at least one of the one or more other functional element instances. The functional element instance may provide a schema for generating and updating the code module. Creating the functional element instance may be in response to receiving instruction to create the functional element instance from a participant, such as human end-user or an agent module.

[0081] Creating the functional element instance may include generating (406) a code module in the codebase. In some examples, the code module may be a space type functional element instance. Creating the functional element instance may include generating and outputting a graphical representation of the functional element instance to a low-code view displayed via a graphical user interface. The code module may thus be represented by a functional element instance created from a functional element template.

[0082] The method may include, in response to creating the functional element instance, creating or initializing (408) an agent module associated with the functional element instance. The agent module may be created instantly in response to (e.g., immediately after) creation of the functional element instance. The code module may therefore be uniquely associated with an agent module spawned for the functional element instance and configured to update the code module by updating the associated functional element instance.

[0083] The method may include obtaining (410) a textual description of the code module and outputting (412) the textual description of the code module to a document view displayed via a graphical user interface. The textual description of the code module may be viewable and editable via the document view. The textual description of the code module may be a description (such as a plain language description) of functionality of the code module. The document view may provide a “what you see is what you get” view of the document.

[0084] In some examples, and described in greater detail with reference to Figure 7, obtaining the textual description of the code module may include the agent module converting the code module to the textual description thereof using the schema provided by the functional element instance. Converting the code module to the textual description thereof may include using a language model. The agent module called to convert the code module may be the agent module inferred from the context in which the input is received (e.g. from the section of the document into which the input is inserted, in which a cursor locates, or the like).

[0085] In other examples, obtaining the textual description of the code module includes using information obtained or derived from (generally, information relating to) the functional element instance. This may include using logic or rules built into the application development platform in terms of which information relating to the functional element instance (such as the type of functional element instance, configuration thereof, and the like) is converted into a textual description of the code module. In some examples, each of the different functional element templates from which functional element instances are created contain rules for generating textual descriptions thereof, including for example template language that can be updated based on specific configuration of the functional element instance. In this sense, in some examples, generation of the textual description may be a static process based on rules and / or information contained within the function element instance or the template from which the functional element instance is created.

[0086] For example, a space (being a functional element instance) may be generated, and within which one or more code modules are contained. The code modules may comprise source code. One or more roles within the space may exist for defining permissions of one or more participants and in some cases one or more other spaces. In some examples, the permissions may be configured for agent modules to obtain sections of the source code, and for the same or other agent modules to make changes to the source code. Each role may include an interaction, which may provide connections between flows (such as workflows carrying out a set of steps). The interaction may include a flow, which further includes a step. The flow may be a workflow triggered by an action to obtain source code. The step may be a defined function configured to extract a portion of source code from the code module when requested by an agent module. In some examples, the step may be API endpoints, such that the database with the source code includes an API endpoint from which the source code may be obtained by an agent module.

[0087] Steps (402) to (412) may repeat each time a functional element instance is created such that, over time, a visual representation of the codebase is built up and output via one or both of the low-code view and the document view.

[0088] Users can collaborate on the application development via their respective terminals. For example, users can view the document view to review and make changes to the codebase. Further, users can view the low-code view to review and make changes to the codebase. To this end, the application development environment may implement a codebase management method. An example codebase management method is illustrated in Figure 5A.

[0089] The method may include tracking (502) a context of development. The context of development may be a context in which development is currently being undertaken. The context may, for example, link to one or both of: a particular code module; and, a particular functional element instance. The context of development may define a code module or functional element instance on which or in which development is currently taking or is to take place. Tracking the context of development may include tracking a location of a cursor, pointer or other user input element in the document view or in the low-code view. In some examples, tracking the context of development may include monitoring a chat between participants and determining the context of development from keywords present in the chat. In the document view, for example, different sections of the document may be associated with different functional element instances and hence with different contexts of development. The context may be tracked by tracking where in the document view (e.g., in which section) the participants are collaborating. Tracking the context may include flagging, activating or calling an agent module associated with the current context of development.

[0090] The method may include receiving (504) input of an edit. In some cases, the edit may be a textual description edit. The textual description edit may be input to the textual description of the code module. In other cases, the edit may be a code module edit. The code module edit may be input to the code module (e.g. by changing the code directly).

[0091] The input of the edit may be received from a participant, including a human user or the agent module. For example, the edit may be made directly to the textual description or the code module. In other cases, input of the edit may be received from the agent module in response to an interaction via the chat window (e.g. in response to a participant requesting the edit via the chat window). Input of the edit (whether to the code module or textual description thereof) may be by the agent module in response to the chat.

[0092] The input of the edit may be received in a particular context of development. For example, the edit may be input into a particular section of the document view, thus defining the context of development. In some examples, the input of the edit is in the form of a change requested via the chat window. In other examples, the input of the edit is in the form of a change requested by another agent module, for example by way of an agent module to agent module message. The input of the edit may be input of a requested edit and may be subject to validation.

[0093] Referring briefly to Figure 5B, for example, one or more participants may initiate a chat in the chat window (18). The chat may be bound to the context of development, for example based on the section of the document view in which the participants are active. The chat may be in the form of a thread and a participant may input an edit into the thread by “replying in thread” (540). The method may check (542) whether an existing thread or discussion exists for the context. When (544) there is an existing thread or discussion, the method includes loading (546) the thread. Otherwise, when (548) there is no existing thread or discussion, the method includes creating (550) a new thread for the context of development. Thereafter, participants can work (552) towards a resolution or conclusion by exchanging messages in the thread. This can for example include an exchange between one or more human participants (554, 556) and / or the agent module (110.1 ) active within the context of development. For example, a participant can ask the agent module to “make the textual description of the code module better”; “change the name of a role”; or the like. As described in greater detail below with reference to Figure 7, the agent module, receiving the chat message, can call a language model, input a prompt including the textual description and the user message, and return an updated textual description from the language model for review by the human user. This may repeat (558) until one or more or all of the participants are satisfied. Once satisfied, and subject to any necessary validations, the necessary updates can be made, and the thread can be marked (560) as resolved or concluded and then archived (562).

[0094] Returning now to Figure 5A, the method may include validating (506) input of the edit to the textual description of the code module. Validating the input may include using a change intercepting workflow. Validating input of the edit to the textual description of the code module may include initiating the change intercepting workflow in response to detecting one or more predefined conditions associated with the edit. The one or more predefined conditions may include: editing a project name, description or purpose; editing a role name description purpose or restriction; adding or removing an interaction; editing an action name; and the like. Referring to Figure 5C, for example, when a change is requested (564) via either chat (566), such as described above with reference to Figure 5B, or via editing (568) the textual description in the document view directly, the method may include determining (570) whether the change has an associated workflow. When (572) the change is determined to have a workflow, the method may include replying (574) in the chat with details regarding the change and possible impact on the codebase or other code modules thereof. This may for example include outputting a message in the chat to the effect of “the requested change will have X impact, are you sure you want to proceed” or the like. Thereafter, participants can conclude or resolve (576) any impact, including refining or modifying the requested change, via the chat and, once resolved, the change (being the requested or modified change, as the case may be) can be executed (578). When (580) the requested change has no associated workflow, the change can be executed (578) without further discussion in the thread.

[0095] In some examples, one or more of the following changes have an associated workflow:

[0096] - editing project name: where, for example, a project owner might need to approve, because interoperability might be broken if the name is used for domains, etc.;

[0097] - editing project description / purpose: which may trigger an analysis of the space to check alignment and recommend new roles / interactions accordingly;

[0098] - editing a role name: which might trigger an analysis of the interactions and description for alignment, and which might recommend new interactions. Further, references in flows, etc., may need to be updated and consuming services may need to be notified;

[0099] - editing a role description / purpose: which might trigger an analysis of the interactions and description for alignment, and which might recommend new interactions;

[0100] - editing a role restriction: wherein a role owner might need to approve, and an analysis of consuming services may be required; adding a new interaction: which might require analysis of alignment with name or role / description, and which may need to be updated accordingly; removing an interaction: which may require an analysis of alignment with name or role / description, and which may need to be updated accordingly. Further, such a change could break references, which would need to be highlighted and worked through;

[0101] - editing an action name: which may require references in flows, etc., to be updated, consuming services may need to be notified; and the role purpose or description may need to be altered.

[0102] As mentioned, in some examples, one or more of the code module, functional element instance, agent module and textual description of the code module are associated with a context within the codebase. Receiving input of the edit may be while the context is flagged, active or called. In other words, the input may be received in the context of the code module. In some examples, the context of the textual description of the code module may be defined or bounded by a section of the document view in which the textual description is output. In other words, different sections of the document may point to or be associated with different contexts, and thus with different functional element instances, agent modules, code modules and the like. A given context may be inferred (and an associated agent module activated) by selecting, hovering over, viewing, etc. the section of the document view. In other words, context may be changed by moving through different sections of the document.

[0103] The method may include updating (508) the code module based on the edit. The code module may be a block of code and updating the code module based on the edit may include updating the block of code based on the edit. Updating the code module may be in response to one or both of: receiving the input of the edit; and successful validation of the input of the edit. Updating the code module based on the update to the textual description thereof may include converting the edited textual description of the code module to update the code module using the schema. Converting the textual description of the code module to the code module may include using a language model.

[0104] In some cases, an update to a code module and associated functional element instance may impact on other code modules and their associated functional element instances. The method may include propagating (510) the update to the codebase. This may be by way of messages sent from the agent module and addressed to agent modules of linked / associated (e.g., parent / child) functional element instances for the respective agent modules to evaluate and execute as required. Propagating the update may include broadcasting a message containing details of the update to one or more other agent modules.

[0105] Propagating the updates to the codebase may in turn require updates to the visual representations thereof provided by the low-code view and / or the document view. The method may thus include, at each of a plurality of agent modules, in response to detecting (512) a change to a functional element instance and / or code module with which the agent module is associated, updating (514) the textual description of the code module based on the update and outputting (516) the updated textual description of the code module to the document view.

[0106] Converting a code module to a textual description thereof, and vice versa, (including converting updates or changes to the code module, or vice versa) may be performed by an agent module associated therewith. Referring now to Figures 6A and 6B, a given code module (e.g., 109.1 ) is associated with an agent module (110.1 ) in the agent network (19) and with a textual description (602) thereof which is provided in a particular section (604) of the document view (16). The section (604) of the document view defines the context of development and in turn the agent module (110.1 ) that is called or activated or used to process and convert edits. Moving to another section (e.g. 606) of the document view changes the context of development and in turn calls or activates the agent module (1 10.2) associated therewith. Changes to the textual description (608) of the corresponding code module (109.2) contained within the section will be handled by the associated agent module. By linking each agent module to a context of development and providing that agent module with information relating to its context of development, performance of the agent modules may be improved by narrowing down the scope of work that a given agent module is expected to perform.

[0107] Each agent module thus performs a method of converting content from a first type to a second type. The first type of content may be one of: a textual description of the code module (including, in some cases, an edited textual description of the code module); or, the code module (including, in some cases, an updated or edited code module). The second type of content may be the other of: the code module (or updated code module); or, the textual description (or updated textual description) thereof.

[0108] Referring to Figure 7, the method may include receiving (702) content of a first type; inputting (704) the content into a language model; receiving (706) content of a second type from the language model; and, outputting (708) content of the second type. In some cases, the content of the first type is received together with metadata including one or more of: the context of development; a chat message; chat history (e.g. including a string of chat messages); an agent module message; information derived from functional element instance associated with the content; and the like. In some examples, inputting the content includes compiling a prompt based on or including the content of the first type and any associated metadata. In some examples, compiling the prompt includes using predefined prompt language associated with the context of development and / or agent module. The language model may be specific to the agent module. In other words, the language model may be configured for the type of functional element instance or the functional element template from which the functional element instance is created.

[0109] In some examples, the language model receives or outputs, as the case may be, a functional element instance or information relating to or derived from the functional element instance from which the code module can be generated. In other words, the language model may receive the functional element instance or associated information and use it to generate a textual description of the code module. Or, the language model receives the textual description of the code module and generates the functional element instance or information relating to the functional element instance. The functional element may be a configured functional element instance. The information relating to or derived from the functional element instance may include: information relating to the type of functional element instance; and, configuration of the functional element instance. The configuration of the functional element instance may include validated data points. The functional element instance or associated information can in turn be used to generate the code module. The functional element instance may be in the form of or provided by a schema validation-based file representing structured data. The schema validation-based file may for example define fields and associated validation rules for configuration of the file and in turn of the code module.

[0110] Input into the fields may be validated based on validation rules of the functional element instance and configuration values (such as JSON configuration values) may be generated based on validated data points. The configuration values may in turn be converted into configuration code based on the validated data points. The configuration code can be converted into the code module based on components of a step macro forming part of the functional element instance, which are described in greater detail in the Applicant’s U.S. Patent No. 11 ,561 ,772 B2, the entire content of which is incorporated by reference herein for all purposes. For example, validated data points may be data points populated into fields of the functional element instance and validated using validation rules of a step configuration generator. The step configuration generator may be provided by the step macro and may be configured to generate a step configuration file. The step configuration file may be provided to an execution code generator for input into a metaprogramming component configured to interpret the data points of the step configuration file and to generate and output a compiled step file. The execution code generator may be configured to generate executable code in the form of the compiled step file configured for storage in memory and execution by a processor of a computing system. A step configuration requirements component may generate configuration values based on the validated data points.

[0111] Figure 8 is a flow diagram which illustrates an example method performed by an agent module (e.g. 1 10.1 ) associated with a functional element instance (108.1 ) described herein.

[0112] The method may include receiving (802) a message, for example from a queue of messages. In some cases, the message may be received from another functional element instance (e.g. 108.3) which is a parent of the functional element instance (108.1 ) with which the agent module is associated. In some cases, the message is received from a mailbox of a process which embodies the functional element. In some cases, the message is received from a participant via a chat window or from a document engine in response to an edit to a section of a document. The method may include obtaining (803) an action from the message. Obtaining the action may include probabilistically determining the action based on message content and optionally other context (such as a state of the agent module and / or the functional element instance). The action may be one of a set of actions which the agent module is configured to perform. The action may for example be one of the following types of actions: a query action; a change action; or, a delegation action. A delegation action may include an address (or information which can be used to determine an address) of another functional element instance to which the message is to be rerouted. A query action may be a request to return information about (such as a status of) the functional element instance. A change action may be an instruction to change configuration of the functional element instance. For example, the change action may effect a change to configuration of the functional element instance with which the agent module is associated.

[0113] Obtaining the action may include processing (804) the message to determine whether a language model (232) is required to extract an action from the message. Processing the message may include retrieving (806) a state associated with the agent module and / or the functional element instance. The state may be retrieved from a state machine (214.1 ) associated with the functional element instance with which the agent module is associated. Processing the message may include passing the message (and state) through a flow associated with the functional element instance. The flow may be a base flow and may be retrieved from the library and may be in the form of a set of instructions to be performed on the message to interpret it. For example, the base flow may be stored in the library in association with the group of functional elements of which the functional element instance is a part. In some examples, the flow includes a schema and associated schema validation rules for performing schema validation on the message to determine the action. The flow may for example include, at a first stage, determining whether the action can be obtained from the message and executed without further processing. The flow may include, at a second stage, determining whether the message can be delegated to another functional element instance.

[0114] In some examples, processing the message to determine whether a language model is required includes performing a schema validation on the message. Performing the schema validation may for example include using a schema associated with the functional element instance and which includes one or more fields from which the action can be extracted. In some examples, processing the message to determine whether the language model is required determines that the language model is required when the schema validation fails. Otherwise, when the schema validation is successful, the action may be extracted from the message based on the schema.

[0115] Schema validation may for example be used to determine whether the action can be obtained from the message and executed without further processing by validating an action entry in an action field of a message that conforms to the schema validation. The action entry may for example be in the form data elements describing an action contained within the action field of the message. When the action entry is validated using the schema validation, then the action can be performed without further processing. Further, schema validation may be used to determine whether the message can be delegated to another functional element instance. This may for example include using the state to determine whether the message is relevant to the functional element instance in question or if it should be delegated to another functional element instance. For example, a mismatch between the state of the functional element instance and data elements contained withing a state or related field of the message may indicate that delegation is required, and the message may be forwarded appropriately.

[0116] The processing steps may be provided to prevent unnecessary calls to the language model. This may improve speed (e.g. because unpredictable delays associated with calling the language model can be avoided) and can also reduce costs associated with calling the language model.

[0117] Obtaining the action may include, in response to determining that the language model is not required (808), extracting (810) the action from the message. Otherwise, obtaining the action may include, in response to determining that the language model is required (812), inputting (814) the message into the language model (232) and receiving (816) the action from the language model. Inputting the message may include inputting the message and other context into the language model (e.g. relating to the state of the functional element instance, obtained from the state machine).

[0118] The language model may be configured to determine the action from the message (and any other context). For example, the language model may be configured to determine the action from the message based on one-shot or few-shot learning. The one-shot or few-shot learning may include prompt language specific to one or more of: the state associated with the agent module; the functional element instance; and the functional element-type. Inputting the message may thus include compiling a prompt for the language model which includes or is based on: the message; any other context; and, prompt template language created for the functional element instance or the functional element type. In some examples, the language model is fine-tuned for the type of functional element with which the agent module is associated, such that agent modules of different types of functional elements have access to different language models (232, 234). In some cases, different types of models are available to the agent module and the method includes, in response to determining that the language model is required, determining a type of language model required. For example, different models of different sizes, computational efficiency, latency and the like may be available, and the method may determine a model from those available based on one or more of: the message, the state and other factors. In some examples, the language model may be called based on an assignment of the agent module to the language model. In some examples, agent modules are associated based on a tree-like dependency and lower level (e.g. leaf-type) agent modules may have access to smaller language models while higher level (e.g. root-type) agent modules may have access to larger language models. The smaller language models may be special purpose language models trained based on the agent module or the functional element template with which the agent module is associated. In some examples, the method includes selecting a language model from a set of available language models. The selection may be based on one or more of: cost; availability; assignment; and, latency.

[0119] As mentioned, obtaining the action may use contextual information relating to a state of the functional element instance. Agent modules of different functional element types might not need to know as much as others in this respect. However, the 'local' context will be useful in boosting the overall intelligence of each agent when performing its tasks. At least some of this contextual information may arrive along with a message and may be stored to be used later (e.g. to be retrieved from the state machine). The local context may for example include a type of breadcrumb data linking it to the primary effects it is involved with and optionally metadata to assist based on the step type. Such information may assist when there is ambiguity or conflicting constraints, an agent module of a functional element instance may detect this and seek to address the functional element instance that represents the associated primary effects to gain clarity / understanding. If at this point the constraints still conflict, a human or alternate system could intervene and possibly rework the requirements (or improve the steps) to relieve the conflict which may only become apparent during composition.

[0120] The method may include executing (818) the action. As mentioned, in some cases the action may be a delegation action. When the action is a delegation action, executing the action includes rerouting the message to the relevant functional element instance based on the address determined with the action. In this manner, actions may be promulgated down an arrangement of functional element instances until the appropriate functional element instance is identified. In some cases, the message may be an update message generated by another functional element instance in response to a change made to the other functional element instance. In such a case the agent module may extract and execute a change action from the message (e.g. to bring the functional element with which it is associated up to date with the other functional element instance with which it is associated). Further, as mentioned, the application development environment may provide a graphical user interface in which a visual representation of the functional element instances is output. When the action is a change action, executing the action may include changing configuration of the functional element instance and updating the visual representation of the functional element instance accordingly. Updating the visual representation of the functional element may be in real-time, i.e., immediately (within milliseconds) in response to the change. In some cases, executing the action may include prompting for user input, for example for user approval of the action to be executed or other input that might be required for the action to be performed.

[0121] By providing discrete agent modules for each functional element instance, and by providing each agent module with access to a state machine of the functional element instance from which contextual information representing the state of the functional element instance, the scope of actions that each agent module is required to perform can be narrowed down significantly. This can simplify calls to the language models, reducing cost and time associated with such calls. Further, because changes to configuration of functional element instances are validated using a schema validation associated with the functional element instance, changes determined to be made by the agent modules are easily moderated. Furthermore, the topology provided by the hierarchy of functional element instances allows for messages to be easily routed to and actioned by the appropriate agent module. The systems and methods described herein may therefore provide a low-code application development environment in which agent modules enhanced by large language models are able to assist with application development, reducing requirements on human intervention and involvement.

[0122] Various components may be provided for implementing the methods described above with reference to Figures 4, 5, 7 and 8. Figure 9 is a block diagram which illustrates exemplary components which may be provided by a computing system (900) for executable generation. The computing system may provide an application development platform which provides an application development environment.

[0123] The computing system (900) may include a textual description obtaining component (902) arranged to obtain a textual description of a code module of a plurality of code modules. The plurality of code modules may provide a codebase. The textual description obtaining component (902) may be arranged to input the code modules, or contents thereof, into the language model and to receive an output of the language model to obtain the textual description.

[0124] The computing system (900) may include a textual description outputting component (904) arranged to output the textual description of the code module to a document view. The document view may be displayed via a graphical user interface. The textual description of the code module may be viewable and editable via the document view. The textual description of the code module may be a description of functionality of the code module. The textual description outputting component (904) may be arranged to format the textual description to a format required by the graphical user interface.

[0125] The computing system (900) may include a code module updating component (906) arranged to update the code module based on the textual description edit. The code module updating component (906) may be arranged to receive input of the textual description edit. The code module updating component (906) may be arranged to update the code module in response to receiving input of the textual description edit to edit the textual description of the code module. The code module updating component (906) may be arranged to receive the input via the document view.

[0126] The computing system (900) may include a textual description updating component (908) arranged to update the textual description of the code module based on the code module edit. The textual description updating component (908) may be arranged to determine an update of the textual description of the code module. The textual description updating component (908) may be arranged to output an updated textual description of the code module to the document view. The textual description updating component (908) may be arranged to update the textual description and output the updated textual description in response to receiving a code module edit to edit the code module. The textual description updating component (908) may be arranged to update the document view in response to updates to the code module and vice versa.

[0127] The computing system (900) may include a prompt compiling component (910) arranged to compile a prompt from one or more prompt inputs. The prompt inputs may include any one or more of: the edited textual description; the functional element instance; and information derived from the functional element instance. The prompt compiling component (910) may be arranged to format a code module into a prompt input.

[0128] The computing system (900) may include a prompt inputting component (912) arranged to input a prompt into a language model.

[0129] The computing system (900) may include an updated functional element instance receiving component (914) arranged to receive an updated functional element from the language model. The updated functional element instance receiving component (914) may be arranged to modify an output from the language model into a format for the functional element instance.

[0130] The computing system (900) may include an updated code module generating component (916) arranged to generate an updated code module. The updated code module generating component (916) may be arranged to generate the updated code module by applying a set of changes to a previous code module.

[0131] Figure 10 illustrates an example of a computing device (1000) in which various aspects of the disclosure may be implemented. The computing device (1000) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different embodiments of the computing device may dictate the inclusion or exclusion of various components or subsystems described below.

[0132] The computing device (1000) may be configured for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any number of subsystems or components of the computing device (1000) to facilitate the functions described herein. The computing device (1000) may include subsystems or components interconnected via a communication infrastructure (1005) (for example, a communications bus, a network, etc.). The computing device (1000) may include one or more processors (1010) and at least one memory component in the form of computer-readable media. The one or more processors (1010) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (1000) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and / or process data on behalf of remote devices.

[0133] The memory components may include system memory (1015), which may include read only memory (ROM) and random access memory (RAM). A basic input / output system (BIOS) may be stored in ROM. System software may be stored in the system memory (1015) including operating system software. The memory components may also include secondary memory (1020). The secondary memory (1020) may include a fixed disk (1021 ), such as a hard disk drive, and, optionally, one or more storage interfaces (1022) for interfacing with storage components (1023), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.

[0134] The computing device (1000) may include an external communications interface (1030) for operation of the computing device (1000) in a networked environment enabling transfer of data between multiple computing devices (1000) and / or the Internet. Data transferred via the external communications interface (1030) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (1030) may enable communication of data between the computing device (1000) and other computing devices including servers and external storage facilities. Web services may be accessible by and / or from the computing device (1000) via the communications interface (1030).

[0135] The external communications interface (1030) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuitry.

[0136] The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (1010). A computer program product may be provided by a non-transient or non-transitory computer- readable medium, or may be provided via a signal or other transient or transitory means via the communications interface (1030).

[0137] Interconnection via the communication infrastructure (1005) allows the one or more processors (1010) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input / output (I / O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (1000) either directly or via an I / O controller (1035). One or more displays (1045) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (1000) via a display or video adapter (1040).

[0138] The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

[0139] Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. Components or devices configured or arranged to perform described functions or operations may be so arranged or configured through computer-implemented instructions which implement or carry out the described functions, algorithms, or methods. The computer- implemented instructions may be provided by hardware or software units. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient or non- transitory computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a harddrive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

[0140] Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

[0141] Some portions of this description describe the embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations, such as accompanying flow diagrams, are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof.

[0142] The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the present disclosure be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments herein is intended to be illustrative, but not limiting, of the scope set forth in any accompanying claims.

[0143] Finally, throughout the specification and any accompanying claims, unless the context requires otherwise, the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Claims

CLAIMS:

1. A computer-implemented method for executable generation comprising: obtaining a textual description of a code module of a plurality of code modules providing a codebase; outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

2. The method as claimed in claim 1 , wherein the document view provides a “what you see is what you get” view of a document including the textual description of the code module.

3. The method as claimed in claim 1 , including receiving input of the textual description edit or receiving input of the code module edit from a human user or an agent module.

4. The method as claimed in claim 1 , wherein the user interface provides a chat window via which a human user can interact with other human users and with an agent module associated with the code module, wherein the method includes receiving input of the textual description edit or the code module edit from the agent module in response to an interaction via the chat window.

5. The method as claimed in claim 1 , wherein the code module is represented by a functional element instance created from a functional element template and wherein the code module is uniquely associated with an agent module created for the functional element instance and configured to update the code module by updating the associated functional element instance.

6. The method as claimed in claim 5, wherein the functional element instance is in the form of a schema validation-based file configured for generating and updating the code module.

7. The method as claimed in claim 6, wherein obtaining the textual description of the codemodule includes the agent module generating the textual description of the code module based on the functional element instance.

8. The method as claimed in claim 7, wherein generating the textual description of the code module based on the functional element instance includes using a language model.

9. The method as claimed in claim 5, wherein updating the code module based on the textual description edit includes the agent module generating an updated code module from the edited textual description thereof using the functional element instance.

10. The method as claimed in claim 9, wherein generating the updated code module from the edited textual description thereof includes using a language model.

11. The method as claimed in claim 10, wherein generating the updated code module from the edited textual description thereof includes: compiling a prompt including one or more of: the edited textual description; the functional element instance; and information derived from the functional element instance; inputting the prompt into the language model; receiving an updated functional element instance from the language model; and, generating the updated code module from the updated functional element instance.

12. The method as claimed in claim 11 , wherein the information derived from the functional element instance includes: information relating to the type of functional element instance; and, configuration of the functional element instance, wherein the configuration of the functional element instance includes validated data points.

13. The method as claimed in claim 1 , wherein the code module is a block of code and wherein updating the code module based on the code module edit includes updating the block of code based on the edit.

14. The method as claimed in claim 1 , wherein the code module and textual description thereof are associated with a context of development and wherein receiving input of the textual description edit or the code module edit is while the associated context of development is active.

15. The method as claimed in claim 14, wherein the context of development is defined by a section of the document view in which the textual description is output.

16. The method as claimed in claim 15, wherein the context of development is activated by selecting or interacting with the section of the document view.

17. The method as claimed in claim 1 , including validating input of the textual description edit, including using a change intercepting workflow.

18. The method as claimed in claim 17, wherein validating input of the textual description edit includes initiating the change intercepting workflow in response to detecting one or more predefined conditions associated with the textual description edit.

19. The method as claimed in claim 18, wherein the one or more predefined conditions include: editing a project name, description or purpose; editing a role name, description, purpose or restriction; adding or removing an interaction; and, editing an action name.

20. The method as claimed in claim 1 , wherein the codebase is provided for compiling into an executable.

21. A system for executable generation comprising: a non-transitory computer-readable storage medium; and one or more processors coupled to the non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium comprises program instructions that, when executed on the one or more processors, cause the system to perform operations comprising: obtaining a textual description of a code module of a plurality of code modules providing a codebase; outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

22. A system for executable generation including a memory for storing computer-readableprogram code and a processor for executing the computer-readable program code, the system comprising: a textual description obtaining component for obtaining a textual description of a code module of a plurality of code modules providing a codebase; a textual description outputting component for outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; a code module updating component for, in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, a textual description updating component for, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

23. A computer program product for executable generation comprising a computer-readable medium having stored computer-readable program code for performing the steps of: obtaining a textual description of a code module of a plurality of code modules providing a codebase; outputting the textual description of the code module to a document view displayed via a graphical user interface, wherein the textual description of the code module is viewable and editable via the document view, and wherein the textual description of the code module is a description of functionality of the code module; in response to receiving input of a textual description edit to edit the textual description of the code module via the document view, updating the code module based on the textual description edit; and, in response to receiving a code module edit to edit the code module, updating the textual description of the code module based on the code module edit and outputting the updated textual description of the code module to the document view, such that the document view updates in response to updates to the code module and vice versa.

Images