GPT-5 coding tips

Solving the hallucination loop when using early GPT-5 preview builds for Python

I spent four hours last Thursday fighting a recursive loop where the model kept suggesting the same deprecated library for a FastAPI project, only to apologize and suggest the same one again. If you are testing GPT-5's coding capabilities, the "smarter" reasoning often masks a dangerous tendency to over-confidently hallucinate versioning when it hits a wall. To stop this, you have to pivot from "asking for a fix" to "providing a constraint."

Why the standard "fix this error" prompt fails with GPT-5 #

Most of us are used to the Claude 3.5 or GPT-4o workflow: paste the error, get the fix, repeat. With GPT-5, I noticed that if the model gets a logic pattern wrong once, it develops a "cognitive bias" within that specific chat session. It tries to force the original (wrong) solution to work rather than admitting the architecture is flawed.

I hit this while building a custom middleware for a project using Python 3.12. I kept getting a TypeError: 'NoneType' object is not callable in a dependency injection layer.

The error message looked like this:TypeError: 'NoneType' object is not callable`` File "app/main.py", line 42, in __init__

Every time I asked GPT-5 to fix it, it suggested adding a null check. I added the check. The error moved three lines down. It suggested another null check. This went on for six iterations. The model wasn't actually "reasoning" through the dependency graph; it was just playing a game of "Whac-A-Mole" with the traceback.

The shift to "Constraint-Based" prompting #

The breakthrough happened when I stopped asking it to fix the code and started telling it what not to do. Instead of "Why am I getting this TypeError?", I switched to a strict constraint: "Analyze the dependency graph of app/main.py. Do not suggest null checks. Identify which provider is returning None instead of a class instance."

The response changed instantly. It stopped guessing and actually pointed out that my settings.py was failing to load an environment variable, leading to a None return in the FastAPI dependency.

Here is a comparison of how I've had to adjust my GPT-5 coding tips based on actual failures:

| Old Approach (GPT-4o) | New Approach (GPT-5) | Why it matters |

| :--- | :--- | :--- |

| "Fix this bug: [traceback]" | "Analyze the state of X before the crash. Do not suggest Y." | Prevents the "apology loop" where the AI repeats mistakes. |

| "Write a function to do X" | "Write a function for X. Use only libraries from this list: [list]." | Stops the model from inventing "plausible" but non-existent methods. |

| "Optimize this for speed" | "Optimize this. Target complexity: O(n log n). Show the Big O for each step." | Forces the model to prove its logic rather than just moving code around. |

Using external context to break the hallucination #

When GPT-5 gets stuck, the worst thing you can do is keep chatting in the same thread. The context window is huge, but the "attention" can get skewed by its own previous wrong answers.

I've found that dumping the current state of the codebase into a fresh prompt—stripped of the previous failed attempts—works best. I actually started browsing Resources within the PromptCube community to see how others were structuring their "context dumps."

The trick is to provide a "Source of Truth" block. I now use this format:Current File State: [Code]`` Known Environment: Python 3.12, FastAPI 0.110``Goal: Resolve TypeError at line 42`` Constraint: Do not use the Optional wrapper; solve the root cause in the provider.

When the AI over-engineers a simple script #

There is a specific frustration with GPT-5: it loves to build an enterprise-grade architecture for a 10-line script. I tried to write a simple script to rename files in a directory based on a CSV, and it gave me a class-based system with abstract base classes and a custom logging handler. It was a nightmare to maintain for something that should have been a for loop and a os.rename().

To kill the over-engineering, I use the "Junior Dev" constraint. Telling the model "Write this as if you are a junior developer who hates complexity" sounds weird, but it actually forces the model to prioritize readability and brevity over "impressive" architectural patterns.

Leveraging a community for prompt iteration #

The wild part is that the "perfect" prompt for GPT-5 changes every few weeks as the model is tweaked. I stopped trying to maintain a private library of prompts and started looking at Prompt Sharing to see what's working for other devs in real-time. If a specific phrasing (like "Think step-by-step in a hidden scratchpad") stops working for the community, I know I need to pivot my workflow.

If you are still stuck in a loop where GPT-5 is apologizing but not fixing, try these three steps:

1. Start a brand new chat.

2. Provide the code and the error, but explicitly forbid the last three "failed" solutions.

3. Ask it to explain the logic before writing any code.

The cost of these tokens is negligible compared to the three hours I lost to that FastAPI bug. Just be honest about your constraints and don't let the model's confidence fool you into thinking a "null check" is the answer to a structural flaw.

Next How Automatic Key Exchange Slashed TLS 1.3 HRRs from 52% to 3% →