A useful request gives our AI Engineer a clear outcome, enough evidence to locate the problem, and boundaries for any changes. You do not need to know the technical cause in advance. Describe what you can observe, what should happen instead, and which website or hosting service is affected.
IN THIS ARTICLE
01 Give the evidence that matters
- Include the relevant page or feature, the wording of an error with sensitive details removed, and when the problem started.
- Mention recent changes such as a plugin update, a new redirect, a PHP version change, or an edited file.
- Say whether the problem affects everyone or only a particular action.
- If you can reproduce it, provide a short sequence of steps.
02 Describe the outcome and approval boundary
For a NabWP issue, an effective request could be:
On my selected WordPress website, the enquiry form displays an error after I click Send. This began after yesterday's plugin updates. Please inspect the relevant logs and configuration, explain the likely cause, and propose the smallest fix. Ask before changing the live site, and test the form after any approved change.
For development work, describe the expected result and acceptance criteria. For example, explain the fields a form needs, what should happen after submission, and which existing pages must keep working. If a request involves a paid integration or an external service, identify it without pasting passwords or secret API keys.
03 Keep each request focused
Keep unrelated goals in separate requests so the Engineer can investigate and verify each outcome clearly. You can refine a request as evidence emerges. Asking for "make everything perfect" leaves too many decisions undefined, while a specific target helps the Engineer spend its available tools and AI allowance on work you can review.
04 Example: describe a change the Engineer can verify
A useful development request states exactly what the visitor should experience. For a small enquiry-form improvement, use a prompt like this after selecting the correct website.
On https://example.com/contact, add an optional Company field.
Keep Name, Email and Message working as they do now.
Include Company in the existing notification when it is supplied.
If it is empty, the form must still submit successfully.
Show me the affected files and proposed change before editing.
After approval, test both a filled and an empty Company field.Tell the Engineer about any form plugin or external delivery service already in use. Review the resulting form on a phone as well as a desktop.
Expected result: the field behaves correctly in both cases, existing submissions still work, and the notification contains the information you requested.
What makes an AI Engineer request testable?
- State the current behaviour, the desired behaviour and a repeatable example using a non-sensitive test input.
- Name the affected URL or resource and specify what must remain unchanged, such as live orders, the current design or mail routing.
- Ask for the proposed change, the recovery method and the check that will demonstrate success.
For a feature request, include the expected validation and failure behaviour, not only the appearance of the page. A contact form needs a destination, input checks and confirmation handling. Test details help the Engineer distinguish a working implementation from a change that only looks complete.