Synopsis
Treat model output as an untrusted code review or draft. A useful coding prompt supplies the relevant code, observed failure, runtime environment, required behavior, and constraints that the change must preserve.
Review the resulting diff and run it in the intended environment. Generated tests do not establish correctness unless they exercise the required behavior and fail for the original defect.
Collect the evidence
Include only the material needed to reproduce or review the problem:
- The smallest relevant code sample
- The complete error message and stack trace
- The language, runtime, framework, and dependency versions
- The command used to run the program or test
- The expected and observed behavior
- Existing tests and compatibility requirements
Remove credentials, private keys, tokens, personal data, and proprietary material before sending code to a hosted service.
State the task
Use a precise verb and define the permitted scope.
Bad:
Fix this code.
Better:
Diagnose the failing Python 3.11 test below.
Identify the cause before proposing a change.
Modify only parse_record().
Preserve the public function signature and Python 3.11 compatibility.
Return a unified diff followed by the tests that cover the defect.
The revised prompt separates diagnosis, scope, compatibility, output format, and verification.
Make assumptions visible
Version and environment differences often determine whether a code example works. Require the response to list assumptions before selecting an application programming interface (API), command, or dependency.
The program runs on Node.js 20 with ECMAScript modules.
Do not add a dependency.
State any remaining runtime assumption before showing the patch.
An invented library method or unsupported version is easier to detect when the assumed interface is stated explicitly.
Request the smallest change
Large rewrites hide unrelated behavior changes. Constrain a repair to the smallest code region that explains the failure.
Reproduce the reported null-input failure from this function and test file.
Propose the smallest change that makes the new regression test pass.
Do not rename public symbols or reformat unrelated lines.
Ask for a diff when the surrounding file is already known. A complete replacement file is useful only when its boundaries and dependencies are clear.
Separate review from implementation
Use two passes for risky changes.
Request a diagnosis with evidence and no code changes. 2. Check the diagnosis against the source and documentation. 3. Request a minimal patch for the confirmed cause. 4. Review the diff for unrelated changes. 5. Run the relevant tests and static checks.
This sequence prevents a plausible patch from becoming evidence for its own diagnosis.
Generate useful tests
Name the behavior that each test must cover.
Add pytest tests for parse_record().
Cover a valid record, an empty input, a missing identifier, and malformed UTF-8.
Keep the existing fixtures.
Explain which test reproduces the reported defect.
Inspect the assertions, fixtures, and failure mode. A test that only executes a line or repeats the implementation does not provide meaningful protection.
Review security-sensitive code
Do not describe generated authentication, authorization, cryptography, input validation, or shell execution code as secure. Request a threat-focused review and verify every claim against primary documentation.
Review this login handler for authentication and session-management defects.
List findings with file locations and attack conditions.
Do not change the code.
Distinguish confirmed defects from questions that require deployment context.
Security review requires system context, dependency information, and independent testing.
Verification checklist
Before accepting a change, confirm that:
- The diagnosis explains the observed failure
- The diff stays within the requested scope
- Public interfaces and compatibility requirements remain intact
- New tests fail before the fix and pass afterward
- Existing tests and static checks still pass
- Dependencies and API calls exist in the stated versions
- Error handling covers the relevant boundary conditions
- Security-sensitive behavior received an independent review