Asking an AI assistant to 'write a function that does X' gets you code that compiles and runs ā and often doesn't fit your codebase's conventions, error handling, or type discipline at all. This lesson covers the specific context that turns a generic first draft into code you'd actually merge.
1Generic Requests Produce Generic (Not Wrong, Just Unfitted) Code
A bare request like 'write a function to fetch user data from an API' is entirely reasonable, well-formed, and will genuinely produce working Python code ā but that code is necessarily generic, because Claude has no information about your specific project's conventions to draw on. It doesn't know whether your team uses type hints on every function (as this curriculum has emphasized throughout the Type Hints and Modern Python Best Practices lessons), what your project's error-handling philosophy is (custom exceptions, from the Advanced Error Handling section, versus generic ones), what timeout convention your team has standardized on (from the requests lesson), or that you already have an ApiClient class this new method should actually be a method *on*, not a free-standing function duplicating its configuration.
This isn't a limitation specific to Claude, or to AI code generation generally ā it's the same fundamental problem any new team member faces on their first day: without context about a codebase's actual, specific conventions, any code they write (human or AI) will tend toward generic, plausible defaults rather than genuinely fitting the existing system. The difference is that a human new hire eventually absorbs those conventions through code review, pairing, and time; an AI assistant starts fresh in every new conversation, with no memory of your codebase's specifics unless you provide it directly, every time.
The practical implication: the quality gap between 'code that runs' and 'code you'd actually want to merge' is almost entirely a function of how much relevant context you provide, not a fundamental limitation of what the assistant is capable of producing when given that context.
# Prompt: "Write a function to fetch user data from an API"
# Generic result, with NO knowledge of your project's actual conventions:
def fetch_user(user_id):
response = requests.get(f"https://api.example.com/users/{user_id}")
return response.json()
# No type hints, no timeout, no error handling, no idea what YOUR project needsGeneric, working code ā no awareness of YOUR project's specific conventions
2Providing the Right Context: Existing Code, Conventions, and Constraints
The single highest-leverage thing you can provide is genuinely relevant *existing code* ā pasting the actual ApiClient class this new method should join, rather than describing it abstractly, lets Claude directly observe your project's real conventions (does it use self.session? What's the actual timeout value already established elsewhere in the class? What exception naming pattern is already in use?) and match them precisely, rather than guessing at plausible-sounding defaults that might not actually align.
Explicitly stating conventions that might not be obvious purely from a code excerpt ā 'we use a UserNotFoundError custom exception for 404s, not a generic one' ā closes gaps that even good context from pasted code might leave ambiguous, particularly for conventions that are more about team philosophy (from the Custom Exceptions and Exception Hierarchy lessons) than something directly visible in a single class's existing code.
This mirrors, quite directly, the same discipline covered throughout this curriculum's Object-Oriented Design and error-handling sections: precise interfaces and explicit contracts produce more reliable, predictable results than vague, implicit ones ā communicating with an AI assistant about your codebase benefits from exactly the same precision and explicitness that makes a well-designed function signature or a well-documented custom exception valuable for human collaborators too.
# Better prompt: "Write a get_user method for this existing ApiClient class,
# using our project's conventions: type hints, a UserNotFoundError for 404s,
# and our standard 5-second timeout. Here's the existing class: [paste ApiClient]"
def get_user(self, user_id: int) -> dict:
response = self.session.get(f"/users/{user_id}", timeout=5)
if response.status_code == 404:
raise UserNotFoundError(f"No user: {user_id}")
response.raise_for_status()
return response.json()Generated code that genuinely fits, not just code that compiles
3Iterative Refinement Beats One Perfect Prompt
A natural instinct is trying to craft one comprehensive, exhaustive initial prompt that anticipates every possible requirement ā but this is generally less effective, and more effortful, than an *iterative* approach: get an initial result with reasonably good context, actually review what came back, and then give specific, concrete follow-up feedback based on what you're genuinely looking at ('this looks good, but add the @with_retry decorator our other external calls use too').
This works better for a straightforward reason: it's genuinely difficult to anticipate every relevant requirement perfectly in advance, especially requirements that only become obviously relevant once you see a specific concrete result and notice what's missing from it. Reviewing an actual, specific output and reacting to it precisely is cognitively easier ā and produces more targeted, effective feedback ā than trying to specify every constraint exhaustively before seeing anything concrete at all.
This iterative pattern also directly mirrors the code review process this curriculum's professional-engineering sections have emphasized throughout ā review, specific feedback, revision, re-review ā applied to an AI-generated first draft instead of a human colleague's pull request. Treating AI-generated code exactly the way you'd treat any other first draft submitted for review, rather than as a finished, ready-to-merge artifact, is precisely the professional discipline that makes AI-assisted code generation genuinely productive rather than merely fast.
# Round 1: "Write get_user() following our ApiClient conventions"
# Review the result, then:
# Round 2: "This looks good, but our retry_strategies module has a
# @with_retry decorator we use on all external calls -- add that here too"
# Iterating with SPECIFIC feedback beats one massive initial promptMore precise and effective than one exhaustive initial prompt
4Step-by-Step Breakdown
The exact same request to Claude produces meaningfully different code depending on what context you provide alongside it ā and most of that difference is entirely within your control.
A bare request produces GENERIC code -- no type hints, no error handling matching your codebase's actual conventions, no awareness of what you already have.
Providing your project's ACTUAL conventions (type hints, error handling style, existing client class) produces code that genuinely fits, not just code that runs.
Checkpoint: Why does providing an existing class (like ApiClient) as context produce meaningfully better generated code than a bare request?
- āThe AI can match your project's actual, specific conventions (type hints, error handling, timeout values) instead of guessing at generic defaults
- āIt makes the AI generate a response measurably faster
Iterative refinement -- reviewing generated code and asking for SPECIFIC changes -- consistently beats trying to get a perfect result from one giant, all-encompassing prompt.
Checkpoint: Why does iterative refinement (small, specific follow-up requests) tend to work better than one giant, all-encompassing initial prompt?
- āReviewing an actual result and giving specific, concrete feedback is easier and more precise than anticipating every requirement perfectly in advance
- āIt always produces a result in less total time than a single comprehensive prompt
Generating fits Claude specifically; the ChatGPT lesson next covers the same underlying skill, contrasted against a different assistant's specific behavior patterns.
Score Real Generated Code Quality. Finish generated_code_quality_score(): a bare request tends to produce code missing these three things.
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
Paste actual, relevant existing code as context rather than describing your project abstractly
Real existing code lets the assistant directly observe and match your specific conventions (naming, error handling, structure) rather than guessing at generic defaults that might not align.
Treat AI-generated code as a first draft requiring review, exactly like a human colleague's pull request
Iterative, specific feedback on an actual result is more effective than trying to craft one perfect, exhaustive initial prompt, and matches the professional code review discipline this curriculum emphasizes generally.
Frequent Bugs
Accepting AI-generated code without reviewing whether it matches the project's actual conventions (type hints, error handling, existing class structure), merging generic code that technically works but doesn't fit the codebase's established patterns.
Always review AI-generated code against your project's actual conventions before merging, and provide relevant existing code as context upfront to reduce the gap in the first place.
Real-World Examples
Generating a New Method That Matches an Existing Client Class
A developer needs to add a new method to an existing, established ApiClient class and wants the generated code to match that class's specific existing conventions exactly.
# Effective prompt structure:
# 1. Paste the existing ApiClient class in full
# 2. State the specific new method needed: "add a delete_user(user_id) method"
# 3. State any conventions not obvious from the pasted code:
# "follow the same UserNotFoundError pattern as get_user for 404s"
# Result: code matching the class's real, existing patterns directly