Matthew Berman’s ChatGPT Coding Workflow: Build, Test, and Iterate

ChatGPT has changed how I build software, and I expect developers who learn to use AI to become more productive. My prediction that those who do not will lose their jobs is a personal forecast, not an established outcome. I also describe a tenfold productivity improvement from my own experience; this walkthrough does not measure or establish a general productivity multiplier.

I think of the developer as a conductor: describe the work, guide the model, and examine what it produces. A basic understanding of programming and the structure of a project helps. I suggest starting with Python and learning as you go, including asking ChatGPT where files belong, while recognizing that the generated code still needs to be understood and checked.

For this April 2023 demonstration I use GPT-4 in ChatGPT to help write code, while targeting GPT-3.5 Turbo for the application itself. I discuss the message and context limits available to me at the time, including a 25-message-per-three-hour cap and different token limits. Those figures and model availability were specific to that period and are not current specifications.

As a codebase grows, providing all its context in a prompt becomes harder. Clear file and method names can help convey intent, and a concise description can summarize surrounding code. These aids do not guarantee the model knows what omitted files actually do: when a response depends on details, supply the relevant context.

The example is a Python command-line interface for asking questions through the OpenAI API. The interface runs on my computer, but the model is called remotely through the API. Before writing files, I ask ChatGPT for a high-level plan, the file structure, and a code outline, specifying GPT-3.5 Turbo and Python.

ChatGPT suggests using the OpenAI package. In VS Code, I create a project folder, install the dependency, and add `chatgpt.py`, `requirements.txt`, and a `.env` file. The requirements file records dependencies; the environment file holds the API key. The commands and SDK patterns in the video belong to the 2023 versions, so consult current documentation before copying them.

I create a secret API key and place it in the environment file. I say in the video that I will rotate the displayed key before publication. In general, keep keys out of source control, screenshots, and prompts; if a key is exposed, revoke or rotate it. I then copy the generated code skeleton into the Python file and choose the Python interpreter where my dependencies are installed.

ChatGPT provides a function to call the API, but I notice that the first suggestion uses an older model rather than the GPT-3.5 Turbo I requested. Asking it to switch models produces a second suggestion that still follows the older API pattern. This is an example of why a plausible answer must be inspected rather than accepted automatically.

I copy the relevant example from the GPT-3.5 Turbo API documentation into the conversation and ask for the correct usage. The revised version uses the chat-completion pattern in use at the time. I replace the method and update the main function so the application maintains conversation history. API interfaces evolve, so this historical code should not be assumed to work unchanged today.

The script loads the environment file and API key, initializes the client, and starts a command-line loop. I run it in VS Code and request a ten-word poem about AI; the answer has fewer than ten words, but confirms that the interface responds. I then ask for Python code to count to 100, and it returns a loop using `range(1, 101)`.

Generated code can be wrong, so read it and run tests. The assistant may also follow a flawed suggestion too readily. If you want an alternative instead of blind compliance, explicitly ask it to discuss your proposed approach and suggest a better method. That conversation can help, but you remain responsible for deciding whether its advice is sound.

The assistant can use earlier messages as context, so I do not repeat the entire project on every turn. But context is limited and retention is not guaranteed. When answers repeat incorrect suggestions or no longer fit the code, provide the relevant files and details again instead of assuming the assistant still has everything.

To demonstrate debugging, I deliberately change the model name to an invalid GPT-3.0 Turbo name and rerun the script. The application produces a traceback. I copy the error output into ChatGPT and ask for help; it identifies the model name and suggests GPT-3.5 Turbo. When sharing logs in practice, remove API keys and other sensitive information first.

The debugging loop is straightforward: create code, test it, provide the error and relevant context, apply a proposed fix, and test again. I change the model name back and rerun the poem request. A useful error message can point directly to a problem, but an AI-generated diagnosis still needs verification.

Next I ask ChatGPT what features might extend the application. It suggests options including saving conversation history, multiple users, rich media, personalization, simulated typing, translation, voice, and external APIs. I choose simulated typing and ask for an implementation.

The first suggestion uses `time.sleep` to delay the chatbot response. I add the proposed imports and methods, replace the main function, and run it. It shows a typing message before displaying the response, but that is not quite what I meant: I wanted the text itself to appear progressively.

I clarify that I want to simulate someone typing the response. ChatGPT proposes displaying the response one character at a time with a delay. I add the new typing and display functions, update the main loop, and test again. This time the characters appear progressively; it is a visual simulation, not the same as streaming the model’s response in chunks.

As a project becomes larger, choose the parts of the code that are necessary to explain the current task and provide them when needed. With practice, you learn where the assistant loses context and where its suggestions need more scrutiny. I also look forward to GitHub Copilot X, which I hope will make working with project context easier; that expectation reflects the time of this recording.