When we use generative AI to proofread our daily writing, whether technical reports, business proposals, or blog posts, it is easy to fall into the habit of simply copying and pasting AI-rewritten text without reflecting on what was changed or why. While that fixes the immediate draft, it rarely helps us grow as writers.
Developers who have worked with the Google Docs API will know the challenge of managing shifting startIndex and endIndex character offsets when inserting and removing content (and since DocumentApp doesn’t support Suggesting mode or comments, there is no avoiding the REST API here). If you’ve already explored the official WriteControl and suggestions guide, the guide simplifies this by only showing single-request examples, such as inserting a string at index: 1 with writeMode: "SUGGEST". Digging into Kanshi’s implementation reveals several practical patterns that aren’t covered in the official docs:
Applying Suggestions: You cannot propose a suggested edit and reply to it in the same batchUpdate call because the suggestion ID doesn’t exist until the edit is created. Kanshi solves this in two steps: first applying all suggested edits in reverse order (from the bottom of the document to the top) so character positions don’t shift, and then using the suggestion IDs returned in the response to attach the coaching notes (addCommentReply) in a second batchUpdate call.
Commenting on Tables & Images: Adding text suggestions immediately changes the character positions of everything further down the page. Before attaching review comments to charts or tables, the script fetches the document a second time to get their updated positions, and falls back to the surrounding paragraph if the API rejects anchoring a comment directly to an image.
Mapping Selections: The Docs REST API has no way to know what a user has highlighted on screen, while DocumentApp.getSelection() doesn’t return the startIndex and endIndex offsets the REST API requires. To let users review just a highlighted section, the script matches the selected DocumentApp elements (and any comments anchored to them) to their corresponding positions in the Docs API response.
Tracking Accepted or Edited: Because WriteMode.SUGGEST runs under the user’s own account and resolved suggestions disappear from the document body, the API doesn’t distinguish AI edits from human ones or track what the writer did with them. To work around this, the script saves each AI suggestion ID and its surrounding text in DocumentProperties, comparing them on later runs to see whether the suggestion was accepted as-is, edited further, or rejected.
Since publishing his original walkthrough, Kanshi has continued to iterate on the project, sharing a follow-up post, Beyond Passive AI Rewrites and Vibe Coding in Google Docs, along with several updates to the repository adding embedded code-block review, Google Drive rulebook grounding, and admin-friendly API key management. To explore the full walkthrough and the latest version of the code, check out the source post below and the tanaikech/DocuMentorAI repository on GitHub.
