After this lesson, you will be able to: Write prompts that produce useful code from Claude, Cursor, or Copilot on the first try (not the fifth); verify AI output before trusting it; and recognize the cases where you should NOT use the AI's suggestion.
Prompt engineering for coding isn't the same as prompt engineering for writing. The wins come from giving the AI the right context (the file, the function signature, the constraint), not from clever phrasing tricks. This lesson takes you from 'AI gave me code that doesn't compile' to consistent, useful output. You'll also learn how to verify what it produced and when to throw the suggestion away.
A prompt with the relevant code attached produces output 10x better than the same prompt without. If you're asking Claude to add a function to a file, paste the file. If you're asking why a test fails, paste the test AND the error AND the function under test. If you're asking for a refactor, name the constraint you care about (performance, readability, type safety). Most 'bad AI output' is actually a context-starved prompt. Fix the context first; the model's smarter than you think when it can see what you can see.
Both ask for the same thing. The second produces working, idiomatic code; the first produces a generic guess.
// BAD prompt// "Write a function to fetch users from the API."//// You get: a generic fetch with no error handling, against an invented URL,// in a style that won't match your codebase.// GOOD prompt// Paste the relevant file/function first, then ask://// Here's my current api.ts://// export async function getPosts() {// const response = await fetch(`${BASE_URL}/posts`);// if (!response.ok) throw new Error(`HTTP ${response.status}`);// return response.json() as Promise<Post[]>;// }//// Add a getUsers() function in the same style, hitting /users,// returning User[]. Use the same error-handling pattern.//// You get: code that matches your conventions, valid types, working URL.
These are not tricks; they're requests that match what the model can actually do well. **(1) Show the shape.** Give an example of the input and the expected output. AI is excellent at pattern-matching from concrete examples. **(2) Name the constraint.** 'No external dependencies,' 'must work with strict TypeScript,' 'avoid mutation', constraints rule out the half of the answer space that wouldn't fit your codebase. **(3) Give it a role and audience.** 'Explain this regex to a developer who's never seen lookahead' yields a tighter answer than 'explain this regex.' **(4) Ask for the WHY, not just the WHAT.** 'Why might this query be slow' beats 'optimize this query', you get reasoning you can verify. **(5) Iterate, don't restart.** When output is 80% right, point at the wrong 20% specifically ('the loop is fine but the early return on line 5 misses the edge case where the array is empty'). Don't start the conversation over.
Every line the AI gives you is a hypothesis you have to test. The most common failure modes, not random ones, predictable ones: **Hallucinated APIs and packages.** Functions that look real but don't exist. Methods on objects that the library doesn't actually have. Always check the import path actually exists, and the method actually exists on the object. **Slightly-wrong logic.** Off-by-one errors, swapped arguments, conditions that should be `<` but are `<=`. The code COMPILES; it just produces the wrong answer. Always run it on a known input and check the output. **Outdated patterns.** AI training has a cutoff; the framework you're using may have moved on. If you see class components, `componentDidMount`, `getInitialProps`, `getServerSideProps` for a new Next.js project, those are stale. **Security gaps.** SQL string concatenation, raw HTML rendering of user input, missing auth checks. AI doesn't know your threat model. Review every endpoint and every user-input touchpoint as if a junior wrote it.
Apply these to every chunk of AI-generated code before you commit it.
// (1) Does it COMPILE?// Save the file, watch your editor for red squiggles, run `tsc --noEmit`.// The fastest filter for hallucinated APIs and bad types.// (2) Does it RUN on a known input?// Try the obvious case (happy path) AND one edge case (empty array, null, max value).// If you can't predict the output, you can't verify it.// (3) Does it match your codebase's CONVENTIONS?// Same error-handling style as the file above?// Same naming conventions? Same import path style?// AI defaults to generic; your codebase is specific.
Reaching for AI is a habit; rejecting AI output is a skill. Five times you should ignore the suggestion and write it yourself: **(1) You don't understand what it produced.** Shipping code you can't explain is shipping a bug you can't debug. Either understand it before merging or write it yourself. **(2) The code touches authentication, payments, or PII.** Stakes too high; the cost of a subtle AI error is real customer harm. Write these by hand and have a human review. **(3) The model is on its third revision and still wrong.** It's not getting closer; it's drifting. Step back, re-state the problem, or just write it. **(4) The suggestion conflicts with your codebase's architecture.** AI doesn't know your team picked Repository pattern over Active Record, or chose Server Components over Client. If the suggestion fights your patterns, your patterns win. **(5) You're rushing.** AI under deadline pressure produces code reviewers will catch in PR. Slow down; write the simpler version yourself; ship cleaner.
The starter has a vague prompt that would produce generic AI output. Rewrite it into a prompt that includes: (a) the existing function/code as context, (b) at least one explicit constraint, (c) a clear description of the expected behavior. Required patterns check for code-block formatting, a constraint keyword, and a concrete behavior statement.
Pick the best explanation.
Sign in and purchase access to unlock this lesson.