Writing code in natural language: turn a request into a verifiable task

The most useful way to request code in natural language is to describe one behavior rather than ask for an entire application. Consider a reading-list form that rejects empty titles. If the request specifies which input is accepted and which message appears, reviewing generated code becomes easier. This approach does not claim that a model always writes correct code. It makes human review more concrete.

Narrow the request with an example

Instead of “improve the form,” describe the behavior: an empty title must not create a record, an understandable message appears beside the field, and other entered information remains intact. Add two examples. “Evening reading” is valid; a title containing only spaces is invalid. These examples expose a small detail that changes data behavior. Without the edge case, the tool may choose its own interpretation.

Inspect the language, framework and form conventions already used by the project. A new feature is not a reason to rewrite the whole system. Identify files to preserve, existing user changes and whether real services may be touched. These boundaries also keep the review understandable. It is easier to inspect one changed behavior than separate the effects of five architectural decisions made together.

Write acceptance criteria before code

A useful list answers three questions: what happens with normal input, what happens with invalid input, and what remains if the operation is interrupted? The example form saves a valid title, rejects an empty one and retains text after a network failure. Describe user behavior rather than making a particular function name the purpose of the test. Another correct implementation should be able to satisfy the same criteria.

If no server connection exists, say so. A success message in the browser does not prove that a record reached the database. Keep prototype behavior visibly labeled. Once the real service is connected, run a separate end-to-end check: create a record, confirm it through an independent read and clean up the identified test record through a defined recovery method. Do not use production data as a learning experiment.

Read the actual changes

Do not rely only on the generated explanation. Inspect changed files. Did the form request also modify dependencies, permissions or deployment settings? If a new network request appeared, investigate its destination and transmitted data. Do not approve an unexplained change simply because tests are green. Ask what it does, then compare that explanation with the code.

Split an oversized review into smaller steps, such as validation, error presentation and accessibility. Keep their relationships visible: if the field displays an error, does the server reject the same invalid input? Assume browser checks can be bypassed. A visual warning does not replace data integrity. The experiment on this page illustrates why trimming whitespace changes an acceptance rule; it does not execute or certify your project.

Report the checks you actually ran

Describe observed behavior: the empty title was rejected, the valid example was saved and input survived a network failure. Separately list any mobile-browser or real-service check you could not run. That report gives the next person a clear starting point. “Everything works” hides unexamined areas and makes later investigation harder.

Keep the smallest useful reproduction note: environment, input, expected result, observed result and correction. It helps identify the same regression in a later version. Add a recovery path as well: which file or record changed, where the previous version lives and what reverting should do. A test result and a recovery plan serve different purposes; both make the change reviewable.

Use a four-line review brief

Before the next task, write four lines: behavior to change, behavior to preserve, sample input and evidence of success. If adding title validation must preserve the ordering of existing records, state that explicitly. It then becomes clear that changing list order is outside the task. You need not predict every detail; choose the ambiguity that could materially change the result.

Afterward, add the observed result. If a check could not run, record why and which behavior remains uncertain. Do not mark “probably correct” as passed. Another person can resume from these notes faster than from a long conversation. This habit turns a natural-language request into a concrete development task with boundaries and evidence.

Source

• GitHub: responsible use and limitations of code suggestions

The form is an explanatory example, not a measured productivity or success claim.