From need to demo

Our tasks start with real users. The Product Owner (PO), the person accountable for the product, gathers feature demand and listens to what gets in people’s way. Before passing a change for delivery, the PO analyses how the area works and should work with a domain expert and help from brAIn.

The PO recognizes the need and hands over the task

This analysis creates a task in Jira, on a kanban board — a board showing work flow. The PO assigns it to the person with the most knowledge of the changed area. Knowledge of rules and dependencies still matters when agents write the code.

The PO accepts business tasks. An AI Engineer — the person delivering a change with agents — leads technical needs. In both cases, a human is accountable for what is made.

The AI Engineer leads the change with agents

The AI Engineer takes the task and delivers it with agents through needed screens, logic, and data. Once a larger change is ready enough to walk its scenario, we hold a Live Demo and collect feedback. A smaller task can move faster to QA and then UAT — testing and acceptance environments described in the next chapter.

Task size changes the scope of the demonstration, but a person should always see what AI did. This applies to independent One Man Army work and an AI Engineer in a team. I do not want to work with an agent on autopilot: its “done” message is not yet my check of the result.

How I run a Live Demo

I ask an agent to use Playwright to show the journey through the application. In Codex, I lead such a demonstration by voice. I see the behaviour and can stop exactly where something does not fit.

For example: “Stop, I have feedback here. Add it to the feedback log,” or “Fix this now.” Not every observation must interrupt the whole demonstration. We record some, correct some immediately, and return to the same place.

After the demo, a feedback list remains. The agent implements corrections properly and checks them. For small changes I do a quick review; for larger ones I ask for another demo focused on what we changed. I want to see the result before I consider the subject finished.

See the full demo flow and prompt in One Man Army.

When working in parallel, check where you meet

Split work into whole features, as far apart in the application as practical. Before starting the agents, check whether the tasks change the same form, rule or data. Where scopes overlap, agree who leads the shared part and in what order the other person will incorporate the result.

Each person needs a separate branch — a working version of the code — and an agent working directory. Separate workspaces protect you from editing each other's files, but you still need to check that the changes work together. After merging them, walk through a scenario covering both parts. The task card below contains a broader template for these agreements.

Supplement the demo with tests and independent review

Watching the behaviour and checking the code provide different information. After a major stage and at the end, submit the change for independent review with fresh context, requirements and test results. The review explanation and prompt are shared with One Man Army.

Findings from CodeRabbit or a second model need to be checked. The agent should point to the code and the consequence of the problem, then repeat the necessary tests after the fix. If a finding is wrong, explain why based on the code. The person required by your playbook still accepts the result.

What must remain with the task

Update the existing task and plan: what works, who viewed the result, which comments were addressed and what remains open. If the change affects the system description, update the relevant documentation too. The card helps collect this information without creating a second register.

Summarise delivery of task [link] using the permitted sources.
State the user's need, the analysis agreements, the task lead and the recipient.
Record what a person viewed in the demo, what feedback they gave, what was fixed
and what needs another demonstration. Give the version, test results and independent
review results, along with remaining issues and documentation status.
Use the attached card and existing plan; do not create a second register.
Do not add acceptance or results without confirmation. Show the summary
without writing to external services or deploying.

An accepted task moves into the release process. In the next chapter, I show how it passes through our shared environments and acceptance of the whole version.