Choose Plan or Build mode

Ask Ahamo to investigate first, or let it make a change when the outcome is clear.

On this page

The mode menu in the prompt box controls whether Ahamo discusses a change or starts making it. It defaults to Build.

Choose Plan for an explanation, investigation, comparison, or proposed approach. Plan is especially useful before changing saved data, access rules, or several connected screens.

Choose Build for a specific change with a visible result. For a small text or styling correction on one visible element, you can also use supported visual editing.

Plan before changing the app

Plan is labeled Discuss before building. Use it when the outcome is clear but the safest approach is not, or when you need Ahamo to explain the current behavior first.

For example:

Review the booking confirmation flow. Explain where a visitor could become unsure whether the booking succeeded, and propose the smallest improvement. Do not change the app yet.

When a proposal is ready, Chat shows Plan ready — review the tasks above and Approve & build. Check that the proposal preserves the parts that already work and gives you an observable result. Choose Approve & build only when you want Ahamo to execute it.

You can instead send a follow-up in Plan mode. That clears the pending approval and lets you narrow or question the approach without undoing code, because the proposal itself did not change the app.

Build a defined result

Build is labeled Make changes directly. Use it when you can name what should change and what should remain. For example:

Update the confirmation screen to show the selected service, date, and time. Add a short note that the shop will confirm by email. Keep the booking form and visual style unchanged.

A Build prompt can cover several files, but keep it to one outcome you can test. After the round completes, try the affected journey in Build. Check desktop and mobile when layout changed, and check the selected Runtime environment when saved data or sign-in changed.

When a round goes wrong

Do not stack another broad request on a result you do not understand. If the app still works, switch to Plan and describe the exact mismatch. If the latest round broke or replaced useful behavior, use history and undo to return to the previous app state, then send a narrower Plan or Build request.

On this page