The time-to-think principle instructs a language model to review its proposed result for completeness, correctness, or risk mitigation before returning the final output. It turns checking into an explicit prompt requirement rather than an assumed capability. section 4.4.5 section 6.1.1
Use the principle to make a requested check concrete:
- State the required result and the condition to verify, such as checking that exactly five JSON objects were created. section 6.1.1
- For code changes, ask the model to mitigate identified risks and check that each risk has been addressed before outputting the refactoring. section 4.4.5
- Treat the check as assistance rather than proof: generated data can still contain unsuitable URLs or inconsistent relationships, and code should be tested and reviewed. section 4.4.5 section 6.1.1
Checking generated test data
A direct prompt is: “You are a JSON data generator. Generate 5 JSON objects in an array and check that 5 JSON objects have been created before outputting the results.” Delimiters separately specify fields, types, and permitted values. The returned data may satisfy the count while still requiring review for issues such as placeholder image URLs or implausible beds-to-room-type relationships. section 6.1.1
Checking a refactoring
After receiving risk analysis for a Java Timesheet class, ask: “Refactor the code to mitigate the risks suggested. Check to see that each risk has been mitigated before outputting the solution.” Copy the result into the project, run the checks, and repeat the original analysis; new risks may still emerge, such as case sensitivity or missing duration validation. section 4.4.5
