Prompting GPT & Migrating from Claude

1 · Prompting GPT well essential

Most good prompting is vendor-neutral, and that's the reassuring news. The habits that make Claude reliable make GPT reliable: give it a clear role and task, put stable rules in the system channel (instructions), show a few examples of the input→output you want, and ask for structure when a program will read the result. None of that changes when you switch the logo on the API. If your prompts are well-built, they port.

The GPT-specific adjustments are mostly about where text goes and which model you're on. Put rules in instructions, not stuffed into the user turn (ox2); keep the stable prefix first so caching fires (oap2); and prefer the schema-constrained responses.parse over asking for JSON in prose. These are the same instincts the course teaches throughout, applied to the OpenAI surface.

The common mistake is porting prompts that lean on Anthropic-specific scaffolding — heavy XML-tag structuring that Claude loves, or prompt tricks tuned to one model's quirks — and assuming they're optimal on GPT. They usually still work, but the right move after a migration is to re-run your evals and let measurement, not folklore, tell you what to adjust.

2 · Reasoning models change the old advice essential

One classic prompting trick is now often redundant: "let's think step by step." On older models, that chain-of-thought nudge measurably improved hard-problem accuracy. On modern reasoning models — which do hidden reasoning internally, dialed by reasoning={"effort": …} — telling them to think step by step is usually unnecessary and sometimes counterproductive; the reasoning is happening whether you ask or not. The modern lever is the effort dial, not the magic phrase.

So the updated habit: for a reasoning model, raise effort for hard tasks rather than appending reasoning incantations, and keep prompts clean and direct. Save explicit "show your work" instructions for when you actually want the reasoning surfaced in the output, not as a performance crutch.

3 · The Claude → OpenAI migration map advanced

If you have a working Claude codebase, migration is mostly mechanical — a handful of renames, not a rewrite. The concepts line up one-to-one; the SDK surface differs. Here's the field-by-field map.

before_claude.pyfrom anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
    model="claude-opus-4-8", max_tokens=512,
    system="You are terse.",
    messages=[{"role":"user","content":"Define idempotency."}],
)
text = next(b.text for b in resp.content if b.type=="text")

after_openai.pyfrom openai import OpenAI
client = OpenAI()
resp = client.responses.create(
    model="gpt-5.5", max_output_tokens=512,
    instructions="You are terse.",
    input="Define idempotency.",
)
text = resp.output_text

4 · Planning a migration professional

A migration isn't done when the code compiles — it's done when the evals pass. The plan: (1) swap the client + call surface using the map; (2) move system→instructions and restructure tool loops; (3) re-point the model id to a config value; and critically (4) re-run your eval suite (Ch 5) against the OpenAI version. Different model, different behavior — a prompt tuned on Claude may need adjustment on GPT, and only your evals will tell you where. Migrate behind a flag so you can run both and compare before cutting over.

5 · Tech-lead — vendor flexibility as architecture tech-lead

The strategic lesson of this whole track: treat the vendor as a boundary, not an assumption. Keep the model id and client construction in config (oap6), keep tool functions plain, keep prompts in a registry, and maintain an eval suite that runs against whichever vendor you point at. Do that and switching from Claude to OpenAI (or running both, routing by task) becomes a configuration and eval exercise — not a rewrite. In a market where the best model changes every few months, that flexibility is itself a design goal.

Knowledge check check yourself