The underlying skill from the previous lesson ā providing genuine project context instead of bare requests ā transfers directly to ChatGPT. This lesson covers what's actually the same, and the few practical differences worth knowing when your team or project uses ChatGPT specifically.
1The Same Underlying Skill, Genuinely Tool-Agnostic
Every principle established in the previous lesson ā providing genuine project context rather than bare, abstract requests; pasting actual existing code rather than describing it; iterating with specific feedback rather than seeking one perfect prompt ā applies to ChatGPT exactly as directly as it applies to Claude, because the underlying reason these principles work has nothing to do with either specific assistant's particular architecture. Any AI code-generation tool lacks inherent knowledge of your specific project's conventions unless you provide that information directly; this is a structural fact about how these tools work generally, not a quirk of one specific product.
This matters practically because it means the *skill* you're building throughout this section ā effective context provision, precise convention-stating, iterative review-and-refine workflows ā is a genuinely transferable professional capability, not narrow expertise in one specific tool's quirks that becomes obsolete the moment your team switches tools, or the moment a newer assistant becomes the team standard. Learning to communicate project context effectively to an AI assistant is closer to learning to write a clear, well-specified GitHub issue or a clear code review comment ā a durable communication skill, applicable regardless of which specific tool receives it.
This reframing is worth internalizing precisely because the AI tooling landscape changes rapidly ā the specific assistant your team uses today may not be the one it uses in two years, but the discipline of providing real context, stating conventions explicitly, and reviewing output critically remains valuable and directly applicable regardless of which specific tool sits on the other end of that discipline.
# The SAME principle applies to ChatGPT:
# Bare: "write a retry decorator"
# Context-rich: "write a @with_retry decorator matching our project's
# style -- here's our existing exception hierarchy, and we use
# exponential backoff with jitter per our retry_strategies module: [code]"Applies identically to Claude, ChatGPT, or any future AI coding assistant
2Custom GPTs: Configuring Context Once Instead of Repeating It
ChatGPT's Custom GPTs (and similarly, persistent project-level instructions in various AI coding tools) offer a genuine, practical convenience beyond the pure skill of context provision: configuring your project's standing conventions ā type hint requirements, your custom exception hierarchy's location and naming, standard timeout values, your team's preferred error-handling patterns ā *once*, as persistent instructions that automatically apply to every future conversation with that configured assistant, rather than needing to restate them at the start of every single new chat.
This doesn't change the underlying principle from the previous lesson at all ā it's still context provision, still closing the same gap between generic and genuinely-fitted output ā it just relocates *when* that context gets provided, from 'every conversation, manually, right now' to 'once, upfront, automatically applied going forward.' The practical benefit is consistency (you can't forget to mention a convention you've already configured persistently) and reduced repetitive effort across many separate conversations over time.
This is directly analogous to a pattern covered elsewhere in this curriculum: a project's pyproject.toml configuring ruff's rules once, applying consistently to every future lint run, rather than needing to specify the same rule set manually every single time you happen to run the linter. Persistent AI assistant configuration is the same underlying idea ā settle a standing decision once, let it apply automatically and consistently thereafter ā applied specifically to AI-assisted code generation instead of tooling configuration.
# A custom GPT's persistent instructions might include:
# "Always use type hints. Use our custom exceptions from
# myapp.exceptions, never generic ones. Follow PEP 8.
# Default timeout for HTTP calls: 5 seconds."
#
# Set ONCE -- applies to every future conversation with that GPT,
# instead of re-explaining conventions in every new chatSame context, provided once instead of repeated every conversation
3The Review Discipline Remains Identical, Regardless of Source
Whichever specific assistant generated a piece of code ā Claude, ChatGPT, or any other tool ā the review discipline before merging that code into a real codebase is identical, and this consistency is itself worth recognizing explicitly: does it match the project's actual type hint conventions? Does it use the project's own custom exceptions rather than generic ones? Does it follow established error-handling and logging patterns from earlier in this curriculum? And critically ā has it actually been *run and tested*, not merely read and assumed correct because it looks plausible and syntactically well-formed?
This last point deserves particular emphasis specifically because AI-generated code, from any assistant, can be extremely *plausible-looking* ā well-formatted, using correct syntax, following reasonable-seeming logic ā while still containing a genuine bug, an incorrect edge-case handling, or a subtle misunderstanding of the actual requirement. Plausibility is not correctness, and the professional discipline this curriculum's Testing section established (write tests, verify behavior, don't just trust that code compiling means it's correct) applies with full force to AI-generated code, arguably with *extra* vigilance precisely because fluent, confident-looking output can be more convincing at first glance than a human colleague's more hesitant, visibly-uncertain first draft.
The unifying principle across both this lesson and the previous one: the specific tool generating a first draft matters far less than the discipline applied both before generation (providing genuine context) and after it (reviewing and testing critically) ā that discipline is the actual professional skill, and it's what determines whether AI assistance genuinely accelerates good engineering or merely accelerates the production of plausible-looking code that hasn't actually been verified.
# Whichever assistant generated it, the review checklist is the SAME:
# - Does it match our type hint conventions?
# - Does it use OUR custom exceptions, not generic ones?
# - Does it follow our established error-handling patterns?
# - Have I actually tested it, not just read it and assumed it's correct?The same discipline, applied identically regardless of which tool generated the draft
4Step-by-Step Breakdown
The context-provision discipline that makes Claude's output fit your codebase works identically with ChatGPT ā the underlying skill is tool-agnostic, even when the specific tool isn't.
The core discipline from the Claude lesson transfers directly -- context beats bare requests, regardless of which specific assistant you're using.
Checkpoint: Does the "provide context, not bare requests" principle from the Claude lesson apply to ChatGPT too, or is it Claude-specific?
- āIt applies universally ā any AI assistant produces more genuinely-fitted code when given real project context, regardless of which specific tool it is
- āIt's specific to Claude's particular design and doesn't meaningfully transfer to other assistants
Custom GPTs (or persistent project-specific instructions) let you configure YOUR project's conventions ONCE, rather than repeating them in every single conversation.
Checkpoint: What genuine advantage does a Custom GPT with persistent instructions provide over repeating conventions in every conversation?
- āProject conventions are configured once and automatically apply to every future conversation, rather than needing to be re-explained each time
- āIt fundamentally produces higher-quality code than the same conventions provided manually each time
Regardless of assistant, the review discipline from the Claude lesson still applies identically -- verify generated code against your ACTUAL project conventions before merging.
Generation covers writing new code with AI assistance; Refactoring with AI is next, applying the same collaborative discipline to improving code that already exists.
Detect a Real Context-Rich Prompt. Finish is_context_rich_prompt(): the context-provision discipline is tool-agnostic.
Level Up š
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported (via server-side Python execution).
Fully supported (via server-side Python execution).
Fully supported (via server-side Python execution).
Fully supported (via server-side Python execution).
Best Practices
Configure persistent project conventions once (via Custom GPTs or equivalent) rather than repeating them in every conversation
This provides the same context-provision benefit with less repetitive effort and reduces the risk of forgetting to mention an important convention in any specific conversation.
Apply the identical review and testing discipline to AI-generated code regardless of which specific assistant produced it
Plausible-looking, well-formatted code is not the same as tested, correct code -- this holds true universally across every AI coding assistant, not just one specific tool.
Frequent Bugs
Trusting AI-generated code as correct because it looks plausible, well-formatted, and syntactically reasonable, without actually running or testing it before merging.
Apply the same testing discipline (write and run tests, verify actual behavior) to AI-generated code as to any other code, regardless of how confident or polished the generated output appears.
Real-World Examples
Configuring a Custom GPT for Consistent Project Conventions
A team wants every team member's AI-assisted code generation to consistently follow the same project conventions, without each person needing to remember and restate them individually every time.
# Custom GPT persistent instructions (configured once, by the team):
# "This is a FastAPI project using Python 3.12. Always include type hints.
# Use our custom exceptions from myapp.exceptions (never generic ones).
# All HTTP client calls need an explicit 5-second timeout.
# Follow the existing patterns in myapp/services/ for new service classes."
#
# Every team member's conversations with this GPT now automatically
# incorporate these conventions, with no need to restate them each time.