01 / Describe the problem
Name the user and the task they need to finish. Explain how they handle it today and what the application should make easier.
LEARN · APPLICATION DEVELOPMENT
Turn an application idea into a first release you can verify.
Start with one user, one problem, and one complete workflow. Define the result before asking an agent to build it, then carry the same acceptance criteria through review and deployment.
Keep the first release bounded.
02 / Define a working example
Supply sample records, roles, and the expected result. Make the smallest complete workflow clear enough to demonstrate.
03 / Review the delivered behavior
Inspect the change, run the relevant checks, and verify the published application against the original example.
Write a brief the agent can act on.
“Build a dashboard” leaves the agent to invent its users, metrics, and data. A more useful brief names the decision: an operations user needs to see which products are at or below a reorder threshold, using sample inventory records.
Add the fields, the threshold rule, who may view the result, and what should happen when a record is missing or stale. The agent can then propose a bounded implementation and identify decisions that still need your input.
| Part of the brief | Example |
|---|---|
| User and task | An operations user checks which products need replenishment. |
| Input | Sample products with available units and a reorder threshold. |
| Acceptance | Products at or below the threshold are flagged, including the equality case. |
| Later work | Connect the inventory system after the sample workflow is reviewed. |
Build a complete path before adding more features.
Ask the agent to plan the data shape, access rules, application behavior, and interface together. A useful first increment lets the user complete the task from start to finish, with enough error handling to understand a failed request.
Use sample data while the workflow is taking shape. Review a real integration separately, including source credentials, allowed records, update frequency, and what users should see if the source becomes unavailable.
Review the code and the evidence.
Check the diff against the brief. Tests should exercise the important behavior, including permissions and boundary cases. A successful build establishes that the application can be assembled; it does not by itself establish that the user’s workflow is correct.
Record what ran and what remains uncertain. If the change affects existing behavior, include a check that it still works. Keep the application’s normal review and merge requirements in place.
Verify the deployed first release.
For Redgold managed pipeline applications, the reviewable artifacts include data types, a route and pipeline manifest, transforms, and expected behavior. During preview, Redgold coordinates application creation, datasets, and managed deployment.
After publication, open the deployed application and repeat the agreed workflow. Confirm the intended revision, the visible result, and the access rules. Keep a record of that verification so the next task starts from a known release.