How to Use Inline AI Edit in Cursor (Cmd/Ctrl+K)

Cmd+K (Ctrl+K on Windows/Linux) opens Cursor's inline AI editing prompt, letting you describe a desired code change in natural language and have it applied directly at your cursor position or over a current selection — the signature feature distinguishing Cursor from the VS Code foundation it's built on. **Editing existing code**: selecting a block of code before pressing Cmd/Ctrl+K scopes the AI's edit specifically to that selection, useful for requests like 'convert this to use async/await' or 'add null checking here' — the AI proposes a diff-style change for that exact scoped region rather than affecting unrelated parts of the file. **Generating new code**: triggering the same shortcut on an empty line, or in an empty new file, instead prompts the AI to generate fresh code straight from your description — effectively a natural-language authoring tool rather than a modification of anything already written. **Reviewing before committing**: proposed AI edits are typically shown as a reviewable diff rather than being silently applied, giving you the chance to read exactly what's about to change before accepting it — an important habit to maintain regardless of how confident the AI's suggestion looks, since AI-generated code isn't guaranteed correct and deserves the same scrutiny as code from any other source. **Iterating on a proposed edit**: if the initial AI response isn't quite right, you can typically continue the inline conversation with follow-up instructions ('make it handle the empty-array case too') rather than needing to reject and restart from scratch, refining the proposed edit iteratively within the same inline session. **Scoping matters more than it seems**: a common mistake is selecting either too little or too much code before invoking Cmd/Ctrl+K. Selecting too little can leave the AI guessing at surrounding context it can't see; selecting too much can cause it to propose changes to code you didn't actually want touched. Selecting exactly the logical unit you want changed — a full function rather than a couple of lines inside it, for instance — tends to produce the most reliably scoped results. **When to escalate instead**: if a request keeps needing several rounds of inline follow-up because it genuinely spans multiple files or requires broader discussion of approach, that's usually a sign the task has outgrown inline edit's scope and would be handled more effectively in the Chat panel or Agent mode instead, rather than continuing to force it through a single-location tool. **Related shortcuts**: Tab to accept a resulting suggestion once it's proposed, Esc to reject it, Ctrl/Cmd+Enter to accept a larger multi-file version of a proposed change, and Cmd/Ctrl+L to escalate to the fuller Chat panel if the request turns out to need more back-and-forth discussion than the inline format comfortably supports. **Working with an unfamiliar codebase**: inline edit is also useful purely as a comprehension tool even when you don't want an edit applied at all — asking it to explain what a selected block does, without accepting any proposed change, is a low-friction way to get oriented in code you didn't write, faster than context-switching to the fuller Chat panel for a single quick question. **A note on prompt specificity**: vague prompts like 'improve this' tend to produce vague, sometimes unhelpfully broad edits, while prompts that name the specific outcome ('extract this into a separate function called validateInput and add a guard clause for null') tend to produce tighter, more predictable diffs. Treating the inline prompt more like a precise instruction to a capable but literal-minded collaborator, rather than a vague wish, consistently produces better first-pass results and fewer follow-up rounds.