A chatbot can turn a natural-language request into proposed Python code. In a coding workflow, the useful question is not just whether it produces code, but whether that code solves the stated problem. Generated solutions can contain bugs, so understanding the task and checking the result remain essential. section 2.5 section 5.9.1
Give the assistant enough context to act, then inspect what it returns:
- Make existing code available when asking for a refactor. State the required behavior and options explicitly; a request to turn a program into a Unix wc-like command should name -l, -w, -c, and -L. section 11.5.1
- For a contained change, point to the previous version and specify the change, such as adding appropriate exception handling. section 14.4.1
- Run the result, compare it with the requirements, and refine the prompt or code when necessary. Trying the problem yourself first helps you write a better prompt and judge the answer. section 5.9.2 section 5.9.1
Refactor the code in the previous cell into a commandline program that works like the Unix wc utility, and supports the -l, -w, and -c options, and the -L option. Output should be similar to output of wc.
This refactoring prompt identifies the existing code, the target command-line behavior, every required option, and the desired output style. section 11.5.1
A plausible result with the wrong filter
A generated weather-file program copied headers and converted percentage fields, but its output contained only a header. It tested `if 'Cook' in row:`, which looks for an entire field equal to `Cook`; the needed test was `if 'Cook' in row[3]:`. Running the code exposed a mistake that its otherwise reasonable plan did not catch. section 21.6.2
Google Colaboratory offers code generation from a notebook cell; GitHub Copilot can work through a chat interface in VS Code. Tool choice is optional. Neither removes the need to supply relevant code, describe the goal clearly, and verify the output. section 5.9.2 section 2.5.3 section 11.5.1
