The interview asks the wrong follow-up.
You are reviewing an AI interview. It asks a technically reasonable question at the wrong moment. It sounds like a form instead of a conversation. You know the wording that would work better, but the instructions live somewhere you cannot edit.
This situation came up repeatedly in the product conversations behind Nibuno. The request was practical: let the business owner change a prompt without navigating the application’s code structure.
Find the prompt by product and purpose.
A product folder should contain the prompts that product uses. Open one and see its purpose, current instructions, live version, draft, previous versions, model, and tests. You should not need to know the source file or the endpoint to find the interview guide.
The owner can then identify which instructions caused the problem and choose examples to test a revision.
Keep technical constraints under engineering control.
The business team can work on tone, examples, follow-up logic, and scoring guidance. Engineering defines the required inputs, response structure, tools, and permissions. An edit that conflicts with those constraints needs attention before release.
Separate drafts from production. Saving an idea should not immediately change a customer interaction. The new version should earn approval through examples, compatibility checks, and a clear release decision.
Save reviewer feedback with the test case.
Save the original input, the old answer, the new answer, and the explanation for the reviewer’s decision. If the interview should retain a fact or filter something out, record that expectation explicitly.
Try the next version on the same development examples. Inspect where it improves and where it regresses. Use additional unseen cases before treating that improvement as evidence of broader reliability. Include difficult and unusual inputs before deciding the prompt is ready for production.
Review the same version and test results.
In Nibuno, the business owner would edit a draft, the reviewer would compare its answers, and the engineer would check its compatibility with the application. Their comments and decisions would stay attached to the same version.
We are accepting beta applications from teams with a prompt they want to improve. Tell us what it does, what is going wrong, and who reviews its answers.