ChatGPT Canvas: how to review code when the AI edits inline alongside you

2026-05-01 · 5 min read · ZenCode

ChatGPT Canvas opens a split-pane workspace: conversation on the left, code in an editable document on the right. When you ask ChatGPT to change something, it does not respond with a new code block in the chat. It edits the document directly — the same document you are looking at — and highlights the changed sections inline. The result looks more like collaborative editing than AI-assisted generation.

That distinction matters for review. Standard ChatGPT code review involves reading a new code block that appears in the chat thread. Each response is a discrete artifact you evaluate before deciding whether to use it. Canvas is different: the code in the document is already the version you are working from. ChatGPT edits that version. The review question is not "should I use this code?" but "were these specific inline changes correct?" — and that question is harder to answer than it looks.

The three traps below are specific to the Canvas interface model. They do not apply to standard ChatGPT chat code blocks, and they are structurally different from the traps in other inline-editing tools like Cursor Composer.

The three ChatGPT Canvas review traps

1. Document-completion framing

When ChatGPT generates a code block in chat, the visual framing is provisional: it is a response, a proposal, something the model produced in answer to your question. The chat format signals that review and decision come next. You read it, decide whether it is right, then act.

Canvas changes this framing. The code lives in a polished document with syntax highlighting, proper indentation, and a persistent view that looks like a file you would open in an editor. When ChatGPT edits it, the document updates in place. There is no "new code block to evaluate" — there is just the document, which now reflects the latest changes. The visual signal is not "here is a proposal" but "the document has been updated."

Document framing carries a subtle completion signal. A finished document with correct formatting reads as ready to use in a way that a chat response does not. The polish of the presentation — consistent indentation, no raw markdown, a view that looks like a real file — triggers a "this is done" prior before review begins. That prior is not grounded in anything about the correctness of the code; it is a response to the presentation format.

The fix is a deliberate framing reset before reviewing a Canvas document. Treat the current state of the document as you would a freshly generated code block in chat: a candidate that requires independent evaluation, not a file that is ready because it looks like a file. This sounds obvious stated plainly, but the visual environment actively works against it, which is why stating it explicitly before each review session has real effect.

2. Edit-site locality

When ChatGPT edits a Canvas document, it highlights the changed sections. The highlighting is useful: it tells you exactly what changed so you do not have to diff the document yourself. But the highlight creates a natural review boundary at the change site, and that boundary rarely matches the actual propagation boundary of the change.

A function that is modified in place changes what callers receive. A variable that is renamed in a utility function changes every file that imports that utility. An error handler that is rewritten to throw instead of return changes every call site that checks the return value. Canvas highlights the location where the text changed; it does not highlight the locations where the behavioral effects of the change land.

This creates a specific failure mode: you review the highlighted section carefully, confirm the edit looks correct in isolation, and move on. The edit was syntactically correct at the change site. The function now does something different from what its callers expected, because you reviewed the site but not the propagation. Nothing in the Canvas interface tells you that propagation review is missing — the edit is highlighted, you read the highlight, the highlight looks right.

The fix is to treat each Canvas edit as having two review zones: the highlighted change site and the immediate propagation surface. Before closing a Canvas session, for each significant edit, answer one question: what does this change affect beyond the lines that are highlighted? For changes that affect callers, add a check that the callers still work correctly. For changes that affect shared state, trace the state. This propagation check does not need to be exhaustive for every edit, but it needs to happen for any edit where the highlighted change is not the entire effect.

3. Co-author peer framing

The design metaphor of Canvas is collaborative document editing — the model that made Google Docs valuable for writing. Two contributors, one document, changes happening in real time. ChatGPT is positioned visually as a co-author: it edits your document, you edit your document, the conversation channel handles coordination. The split-pane interface makes this feel natural.

The problem is that co-author review and AI-generated code review require different priors. When you review a colleague's change to a shared document, you start from an assumption of competence: they know the codebase, they understood the task, their change is probably right except for the small set of things they might have overlooked. You scan for obvious errors and trust the rest. This is an appropriate prior for a peer reviewer who has context and accountability.

It is not an appropriate prior for AI-generated code. The right prior for AI output is that the code is plausibly correct in ways that are visible at the surface and may be subtly wrong in ways that are not. The model has no understanding of your specific system's invariants, no history with your codebase, and no accountability for the consequences. It generates code that reads correctly and may behave incorrectly in ways that only appear at runtime, under specific conditions, or at integration with other components.

Canvas's co-author framing actively suppresses the correct prior by replacing it with a peer-review prior. You are not reviewing a colleague's diff. You are reviewing a generated artifact that happens to live in a document that looks like something a colleague would edit. The review standard needs to be the generated-artifact standard: question the behavioral assumptions behind each change, not just whether the change is syntactically plausible.

The fix is to run a specific question after each Canvas session before treating the document as complete: for each edit ChatGPT made, what was the behavioral assumption behind it? Was that assumption correct for your specific system? The visual presentation will not surface this question on its own. You have to bring it.

What Canvas is well-suited for

Canvas works well for tasks where the review challenge is low: generating boilerplate, writing utility functions with clear contracts, producing test scaffolding for logic you will implement yourself, or iterating on structure and organization where the logic is simple and the surface is visible. For these tasks, the document format is genuinely useful — you can see the full code in context, ask for targeted changes, and get inline updates without managing a long chat history of code blocks.

The review traps appear when Canvas is used for substantive logic changes, changes with non-local effects, or iterative refinement of complex code where each session adds to a growing document. In those cases, the document-completion framing, edit-site locality, and co-author prior all work against the review standard the complexity requires.

The practical distinction is: use Canvas for generation tasks where you are the one bringing the logic, and apply the three checks above (framing reset, propagation review, behavioral-assumption question) for any session where ChatGPT is modifying behavior rather than just generating structure.

For a base review checklist that applies across all AI coding tools, see how to review AI-generated code. For the standard ChatGPT chat code review model, see ChatGPT code review. For the parallel inline-editing model in Cursor, see Cursor Composer multi-file edits review. For another polished-output tool with similar document-completion signals, see v0 by Vercel generated UI code review.