Descriptions for Actions and other application elements must currently be written manually. As a result, they are frequently missing, incomplete or no longer aligned with the actual implementation.
When developers join a project or work with unfamiliar or legacy applications, they often need to inspect the complete flow, inputs, outputs, queries, dependencies and exception handling just to understand what an Action is responsible for.
Idea
Add a “Generate with AI” option next to the Description property of an application element.
For an Action, the platform could analyse:
Its inputs and outputs
The logic flow and decision branches
Entities and aggregates it accesses
Other Actions and integrations it invokes
Exceptions and error-handling behaviour
Relevant side effects, such as sending emails or updating data
It would then generate a concise, editable description explaining what the Action does.
For example:
Starts the password-reset process for the supplied email address. If a matching user exists, it generates the reset information and sends a password-reset email. To avoid exposing whether an account exists, the Action returns success even when no matching user is found.
The generated content should always be presented as a draft that the developer can review, edit and approve, rather than being saved automatically.
Possible evolution
The same capability could later be available for:
It could also identify when the implementation has changed significantly and suggest that the existing description may need to be regenerated.
Benefits
Improves application maintainability
Reduces the effort required to document existing applications
Helps new team members understand unfamiliar logic
Makes code reviews and handovers easier
Produces better context for future AI coding agents
Encourages documentation to remain close to the implementation
Important refinement
The generated description should capture not only what the flow mechanically does, but also, whenever it can be inferred:
its responsibility;
its business outcome;
important security or privacy behaviour;
externally visible side effects;
reasons behind non-obvious implementation choices.
I attached a screenshot to provide an example. A weak generated description would be:
Gets the user by email, resets the password and sends an email.
A useful description would explain:
- the deliberate fake-success path, because preventing user enumeration is the most relevant part of the implementation.
I also prototype a possible UI for this using AI.
