AI coding assistants — Cursor, GitHub Copilot, Claude Code, Gemini Code Assist — have changed what code review looks like. Engineers are shipping code that was partially or fully generated by AI. As a tech lead, you need language for a new set of conversations: evaluating AI suggestions, explaining your decisions, and setting standards for your team.
This session gives you the exact English phrases for those conversations.
Why This Is Harder Than Regular Code Review Language
In traditional code review, you’re evaluating what a person chose to write. The conversation is about intent, trade-offs, and skill. With AI-generated code, a new dimension appears: the engineer may not fully understand what the AI wrote — they accepted a suggestion without reading it carefully, or the AI hallucinated a working-looking solution to a subtle problem.
As a tech lead, you need to:
- Ask questions that reveal whether the engineer understands AI-generated code
- Explain concerns about AI output without dismissing the tool entirely
- Set quality standards that account for AI’s specific failure modes
- Build team culture around responsible AI tool use
All of this requires specific English. Let’s build it.
Key Phrases to Say Out Loud
Read each phrase aloud. Pay attention to the IPA stress markers.
Asking about AI-generated code
“Walk me through your reasoning on this section.” /wɔːk miː θruː jɔːr ˈriː.zən.ɪŋ ɒn ðɪs ˈsek.ʃən/ Use when you suspect a block was AI-generated and you want to test comprehension.
“Was any of this AI-assisted? I want to understand what you reviewed.” /wɒz ˈen.i ɒv ðɪs eɪˈaɪ əˈsɪst.ɪd aɪ wɒnt tə ˌʌn.dəˈstænd wɒt juː rɪˈvjuːd/ Non-accusatory way to open the AI conversation. The phrase “what you reviewed” signals your standard: accept AI suggestions only after review.
“What alternatives did you consider before settling on this approach?” /wɒt ɔːlˈtɜːn.ə.tɪvz dɪd juː kənˈsɪd.ər bɪˈfɔːr ˈset.əl.ɪŋ ɒn ðɪs əˈproʊtʃ/ Good for flagging over-reliance on a first AI suggestion.
Flagging concerns with AI output
“This looks like it could be an AI hallucination — let’s verify the API signature against the actual docs.” /ðɪs lʊks laɪk ɪt kʊd biː ən eɪˈaɪ həˌluː.sɪˈneɪ.ʃən lets ˈver.ɪ.faɪ ðə eɪˈpiːˈaɪ ˈsɪɡ.nɪ.tʃər əˈɡenst ðə ˈæk.tʃuəl dɒks/ Specific and actionable — you’re naming the failure mode and the verification step.
“The logic is correct, but the error handling feels auto-generated. Can you tighten it up?” /ðə ˈlɒdʒ.ɪk ɪz kəˈrekt bʌt ðə ˈer.ər ˈhænd.əl.ɪŋ fiːlz ˈɔː.toʊ ˈdʒen.ər.eɪt.ɪd kæn juː ˈtaɪt.ən ɪt ʌp/ “Tighten it up” = make it more precise, less generic. Very common in English code review.
“I’m not comfortable merging AI-generated code we haven’t manually verified for this use case.” /aɪm nɒt ˈkʌm.fər.tə.bəl ˈmɜːrdʒ.ɪŋ eɪˈaɪ ˈdʒen.ər.eɪt.ɪd koʊd wiː hæv.ənt ˈmæn.juəl.i ˈver.ɪ.faɪd fər ðɪs juːs keɪs/ Clear standard-setting. “I’m not comfortable” is a professional way to block without being aggressive.
Setting team standards
“Going forward, let’s add a comment wherever AI tooling contributed significantly — just for traceability.” /ˈɡoʊɪŋ ˈfɔːr.wərd lets æd ə ˈkɒm.ənt wɛrˈev.ər eɪˈaɪ ˈtuːl.ɪŋ kənˈtrɪb.juːtɪd sɪɡˈnɪf.ɪ.kənt.li dʒʌst fər ˌtreɪ.sə.ˈbɪl.ɪ.ti/ “Going forward” = from now on. “Traceability” = ability to track where code came from.
“Great use of the AI suggestion here — and I can tell you understood it because your variable names are consistent with the rest of the codebase.” /ɡreɪt juːs ɒv ðə eɪˈaɪ səˈdʒes.tʃən hɪər ænd aɪ kæn tel juː ˈʌn.dəˌstʊd ɪt bɪˈkɒz jɔːr ˈver.i.ə.bəl neɪmz ər kənˈsɪst.ənt wɪð ðə rest ɒv ðə ˈkoʊd.beɪs/ Positive reinforcement. Name the specific evidence of good AI review — this teaches the standard.
Vocabulary: 7 Terms for AI Code Review Discussions
| Term | Pronunciation | What It Means in Code Review Context |
|---|---|---|
| hallucination | /həˌluː.sɪˈneɪ.ʃən/ | AI-generated code that looks correct but has subtle bugs or uses non-existent APIs |
| AI-assisted | /eɪˈaɪ əˈsɪst.ɪd/ | Code that was written with significant AI tool contribution |
| accept blindly | /əkˈsept ˈblaɪnd.li/ | Accepting an AI suggestion without reviewing or understanding it |
| verify | /ˈver.ɪ.faɪ/ | Manually check that the code does what it claims to do |
| traceability | /ˌtreɪ.sə.ˈbɪl.ɪ.ti/ | Being able to trace where code came from and why it was written that way |
| tighten up | /ˈtaɪt.ən ʌp/ | Make the code more precise, more correct, less generic |
| over-reliance | /ˌoʊ.vər rɪˈlaɪ.əns/ | Depending too heavily on AI output without applying engineering judgment |
Practice Now: Scenarios and Scripts
Scenario 1: PR with unreviewed AI-generated error handling
The engineer submitted a PR where all the try-catch blocks are generic — same error message for every exception, no specific handling. This is a classic pattern when developers accept AI suggestions for error handling without customizing.
Your PR comment (write this in English):
“The error handling here looks auto-generated — every catch block returns the same generic message regardless of exception type. For network errors, timeouts, and validation failures, we need differentiated handling so our monitoring can alert on the right things. Can you revisit this section and tighten it up? Happy to pair on it if helpful.”
Read this comment aloud. Notice: specific concern, specific reason, specific ask, offer to help. This is the structure of effective English code review feedback.
Scenario 2: Engineer asks “should we even use AI for this?”
Your team is debating whether to use an AI coding assistant for a security-sensitive payment processing module.
Your response:
“Good question to raise. My take: AI assistance is fine for the boilerplate and structure — things like setting up the request/response flow, error handling patterns, logging. But for anything touching cryptography, token validation, or PCI-relevant logic, I want a human writing and a human reviewing every line. The risk of an AI hallucination in that specific path is too high, and the blast radius of getting it wrong is significant. Let’s define the boundary in the ticket before we start.”
Key phrases to practice:
- “boilerplate and structure” /ˈboɪ.lər.pleɪt ænd ˈstrʌk.tʃər/
- “blast radius” /blæst ˈreɪ.di.əs/ — the scope of damage if something goes wrong
- “define the boundary” — set clear rules about what’s in/out of scope
Scenario 3: Team member defensive about AI use
A senior engineer is frustrated that you’re questioning their AI-generated code. They say: “This came from Cursor and I verified it. Why are we spending time on this?”
Your response (firm but non-confrontational):
“I appreciate that you verified it — that’s exactly what we need. My question is about what ‘verified’ means for this specific function. Did you test the edge case where the input array is empty? That’s where I’d expect AI-generated code to miss, and it matters here because downstream processes assume a non-empty result. Let’s walk through it together — it’ll take five minutes.”
Key phrases:
- “What ‘verified’ means for this specific…” — challenging a vague claim without accusing
- “That’s where I’d expect AI-generated code to miss” — normalizes AI limitations without criticism of the person
- “Let’s walk through it together” — collaborative, not interrogative
5-Minute Drill: Say This Out Loud
Read the following script as if you’re opening a team retrospective on AI code review practices. Set a timer for 5 minutes. Aim to say it naturally by the third read-through.
“I want to spend 10 minutes on our AI tool usage in code reviews. Overall, I think we’re using AI assistance well — I’ve seen some genuinely creative solutions come out of Cursor suggestions that I wouldn’t have thought of. But I’ve also noticed a pattern I want us to address: some PRs have error handling that looks auto-generated and wasn’t customized for our context. My ask going forward is: whenever you accept an AI suggestion for error handling or security-relevant logic, add a comment explaining what you verified and why you accepted it. This isn’t about slowing us down — it’s about making our reviews more useful and building a culture where we understand what we ship. Any questions before we look at the examples?”
Vocabulary from the drill:
- “genuinely creative” — /ˈdʒen.ju.ɪn.li kriˈeɪ.tɪv/ — truly original
- “auto-generated” — /ˈɔː.toʊ ˈdʒen.ər.eɪt.ɪd/ — produced by AI without customization
- “security-relevant” — /sɪˈkjɔːr.ɪ.ti ˈrel.ə.vənt/ — matters for security
- “what we ship” — what we release to production (common idiom in eng teams)
Why This Vocabulary Matters Now
The ability to evaluate AI-generated code and communicate your standards in English is increasingly a leadership differentiator. Teams that can have these conversations clearly will build better culture around AI tool use — and ship more reliable software. Teams that can’t have these conversations will either over-rely on AI or reactively ban it.
Neither extreme is right. Your job as tech lead is to define the standard and speak it clearly enough that your team can apply it without you in the room.
That’s what today’s language gives you.