Write and Test AI Prompts
Published · Updated
Writing AI prompts starts with a clear outcome, relevant context, boundaries and a way to check success. Give small examples, request specific revisions and distinguish your instructions from material supplied for analysis.
Define the outcome and the first scope
Begin with the work you want completed, the intended user and the result that user needs. “Build an excellent app” leaves important decisions open. A more useful request is: “Create a maintenance request form for tenants, show required fields, save the request and provide a way to check its status.” The request now describes observable behavior, so you can identify missing requirements before accepting an attractive but incomplete screen.
Define the first version. Name the essential screens, the information entering and leaving the process, and whether you want a plan, a draft or an implementation. For an existing project, describe the current screen and the behavior you want changed. Separate visual changes from changes to stored information when combining them would make review confusing. A smaller scope lets you assess each result before another decision depends on it.
Write a concrete acceptance check for each objective. A maintenance form might need a warning for a missing description, preserved input after correction and a saved record that can be found after submission. You can present this brief to Infera Agent while checking the implementation options available in your account. A request does not establish that a particular feature exists; ask which requirements need additional setup or separate work before relying on them.
- Name the user, task and outcome.
- Set a scope you can inspect.
- Give observable acceptance checks.
Add useful context and representative examples
Include details that change the decision: interface language, audience, fields, output format and relationships between screens. Avoid pasting the entire project history when the problem concerns one error message. Use the names visible in the project to reduce confusion between similar elements. If information is missing, request a short list of assumptions and the question that prevents accurate completion. An explicit unknown is easier to resolve than an unnoticed assumption.
Provide an ordinary example and an exception. For maintenance requests, the ordinary case could include a short description and a unit reference; the exception might contain a long description or a missing field. State the expected result for both. When requesting a table, specify columns, ordering and how unavailable values should appear. When requesting prose, define the reader, length, tone and facts that must not be invented. Check that the examples themselves match your intended process.
Explain how a reference file or image should influence the result: structure, text, data or visual treatment. A vague reference cannot replace the actual requirement. Use clearly marked sample information when it is enough to demonstrate the task. Distinguish known facts from suggestions and provisional values. Keep the central brief in a separate document so you can update it and reuse it without carrying outdated details into a different project or importing conflicting decisions from earlier conversations.
- Include context that changes decisions.
- State expected results for examples.
- Define output format and unknowns.
Check results and revise the actual problem
Compare the result with the acceptance checks instead of relying on a first impression. Open the relevant screen, enter the examples and inspect the resulting record or file when the task involves implementation. For writing, review factual accuracy, language, coverage and repetition. Save the request, version and observed result. This turns the next round into a correction of a known issue rather than another broad instruction to make everything better.
Write feedback in three parts: what happened, what should happen and how to reproduce the difference. For example: “Submitting an empty description shows success; it should display a field warning and create no request; repeat the submission and inspect the records.” Ask for the change and its verification. If the problem involves stored information, changing only the message is insufficient. A convincing interface can still leave the underlying behavior inconsistent with the intended requirement.
When comparing prompt wording, change one factor at a time and use the same test cases. Compare added context, an example or a stricter output format without simultaneously replacing the task. Record successful and incomplete cases; one good answer does not establish consistent performance. Save a useful prompt with its purpose and revision date. Update names, fields and acceptance checks when the project changes, then repeat the checks before adopting the old request for a new version.
- Inspect outputs against acceptance checks.
- Describe actual and expected behavior.
- Keep prompt versions and test results.
Separate external material from instructions
Files and websites can contain instructions that try to redirect the task, a prompt injection risk. Present references as material to analyze. Textual separation improves clarity but does not guarantee protection. Enforce authorization and tool restrictions outside the model, with only the access needed for the task.
Review unexpected changes after external content is processed. Keep secrets out of prompts and require human review for sensitive operations. Risk reference: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ . Coding review reference: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html . These measures reduce risk; they do not certify an application as secure.
- Treat references as data.
- Enforce action controls outside the model.
Questions
Are longer prompts better?
Only when the extra detail helps the task. Remove repetition and compare alternatives with the same examples and acceptance checks before choosing a version.
How do I request a useful correction?
State actual behavior, expected behavior and reproduction steps. Include a representative example and request an explanation of the change and how it was checked.
Must the wording sound formal?
No. Clear language and consistent names matter more. Use terms you understand and request an outcome you can inspect without interpreting vague praise.
When can I reuse a prompt?
After saving a version that meets your checks on the tested cases. Update its context and expectations for the new project, then verify the result again.