Generate Code With ChatGPT: Specify, Test, and Review

To have ChatGPT create code you can use, specify one small change, provide the relevant existing code, and define how the result should behave. Then run the checks and inspect the change before accepting it. fenbs keeps the requirements, agreed constraints, and next step available when development continues in another session.

How do you start with a change you can verify?

1. Choose a small outcome: one function, a focused interface change, or a narrow improvement to an existing feature.
2. Describe the inputs, outputs, important examples, and behavior for invalid or missing input.
3. Supply the language, relevant versions, surrounding code, and the project’s existing patterns.
4. State constraints such as no new dependencies, no changes outside named files, and no deployment without approval.
5. Request the implementation and relevant checks, then review the result against your original requirements.

A request to build an entire customer portal leaves too many decisions hidden. A request to add a filter to an existing list gives you a result you can inspect. Start with a size you understand, then expand only after the first change works.

What should a code-generation prompt include?

Describe the behavior before the implementation. Explain what existing code is for, where the new behavior belongs, and what must remain unchanged. Ask ChatGPT to raise missing requirements rather than selecting product behavior on your behalf.

OpenAI’s prompting guidance↗ (opens in a new tab) recommends giving the goal, useful context, desired output, and boundaries. For code, examples of valid and invalid input often clarify more than a long description. Include the existing test style if the change belongs in a project that already has tests.

Write a Python function named unique_labels.
Input: a list of strings.
Output: a new list with outer whitespace removed, empty labels
omitted, and exact duplicates removed while preserving order.
Case matters: Red and red are different labels.
Do not change the input list or add dependencies.

Example: [" Red ", "", "Red", "red"] -> ["Red", "red"]
Provide tests using the standard library unittest module.
Explain the approach and any unanswered requirements.
Do not add file access, networking, or command-line behavior.

This example deliberately defines how duplicates and capitalization work. Without those details, two reasonable implementations could disagree while both looking correct. The same principle applies to dates, currencies, permissions, and error messages in a larger application.

How much existing code should you share?

Start with the function or component being changed, its relevant callers, and a nearby example of the project’s conventions. Include the interface it must satisfy. When ChatGPT needs more context, ask which file or behavior would change its answer before sharing unrelated material.

Use sanitized examples, and share only code and data your organization allows. Replace credentials and personal details with placeholders. If removing a detail changes the behavior, explain the structure that matters without exposing the original value.

Keep settled requirements available in fenbs project context, while the actual source code stays in your repository. A short work record can explain why capitalization must remain significant without duplicating every file or asking a new assistant to infer the rule from the implementation.

How do you test behavior rather than the generated answer?

Choose expected results from the requirement, independently of the implementation. For unique labels, check a normal list, an empty list, repeated values, labels that become empty after trimming, and distinct capitalization. Also verify that the original list remains unchanged.

Python’s unittest documentation↗ (opens in a new tab) explains how test cases check expected responses to specific inputs and how a runner reports results. If you use another language, use the project’s existing test framework. A familiar testing setup is usually easier to review than a new one introduced for a small change.

Read the tests before trusting a passing result. Do their expected values match the request? Could a test pass while the function breaks an important case? Run the actual commands in the intended environment, and keep any checks that were not run visibly separate from the ones that passed.

Tell ChatGPT about realistic input size when it affects the design. A function tried on four labels has not been checked for a large import. Ask what assumptions the approach makes about memory and input shape, then decide whether additional checks matter for your use. Avoid adding complexity for an imaginary scale the project does not need.

What should you inspect before accepting the code?

Review the diff, the view that shows changed lines, and make sure every change supports the requested behavior. Look for added dependencies, altered interfaces, removed validation, hidden network calls, and modifications outside the intended files. Ask ChatGPT to explain anything you cannot follow.

For an existing feature, check nearby behavior that should stay the same. A new filter should not silently change the default sort order. A helper function should not require a new runtime version without an explicit decision. Clear constraints give you concrete reasons to accept or reject these changes.

OpenAI’s code review guidance↗ (opens in a new tab) emphasizes checking findings against the change, expected behavior, and tests. For broader assistant choices, see ChatGPT Codex and Claude versus ChatGPT for coding. A different assistant still needs the same requirements and review.

What if the generated change does not work?

Keep the failed result and reduce the problem to one observable difference. Provide the exact failing input, expected output, actual output, and error. Ask for an explanation and a focused correction instead of another complete rewrite, which can discard working behavior along with the defect.

The ChatGPT debugging workflow covers investigating a reproduced failure. ChatGPT for code work covers the broader development process. When the correction reveals a reusable mistake, save a lesson describing the cause and the check that would catch it next time.

How to do this with fenbs

1. Create a free account and add your software project. One person can start free, with no credit card.
2. Add a feature or enhancement task describing one code change, its examples, and the checks needed before acceptance.
3. Record the person’s continuing constraints in Decisions and rules, and keep open product choices separate from agreed requirements.
4. Connect a supported assistant using the integration guides. Ask it to read the context, implement the scoped change, and report the checks it actually ran.
5. Save progress with accepted work, test results, unanswered questions, and the next step. Add a lesson when a verified mistake suggests a useful prevention check.

fenbs maintains the work record; it does not replace your editor, source repository, or test runner. For a disposable snippet with no continuing project, a chat and a local check may be sufficient. Explore more everyday methods in the AI at work hub.