Analyzing StackOverflow data (2008–2026) reveals a massive activity decline post-ChatGPT. Using Google Apps Script as a case study, this report quantifies the migration from human support to AI. We explore how the platform is pivoting from a help desk to a critical verification layer for AI-generated code to prevent model collapse.
It’s that time of year again. Kanshi Tanaike has just released his seventh annual report on the state of the google-apps-script tag on Stack Overflow. The numbers show a massive drop in platform activity since late 2022, which Tanaike identifies as a “structural shift” from human support to Generative AI.
But if you’re like me, you’re probably wondering whether the community is actually shrinking or if we are just working differently.
It’s Not Just Automation; It’s “Vibe Coding”
Tanaike’s data points to a decline in question volume, suggesting that AI has taken over the routine heavy lifting. While that is part of the story, I believe there is a more nuanced explanation for those of us in the Apps Script world.
Rather than task automation I think it’s more about “vibe coding”. We are all using LLMs to prototype, troubleshoot, and get through that initial hurdle of “how do I even start this?”. AI is absorbing the iterative problem-solving that used to happen in public threads, effectively acting as a filter for the simpler questions that used to dominate the tag.
The Shift to a “Verification Layer”
One of the most interesting parts of the report is Tanaike’s argument that Stack Overflow is transitioning from a high-volume help desk to a high-quality Verification Layer.
As the web gets flooded with AI snippets, the value of the “ground truth” on Stack Overflow actually goes up. Tanaike noticed that while scripting languages saw a sharp drop in activity, enterprise-heavy languages like PHP and Swift held steady. To me, that is a clear sign of where AI still struggles. It can write a function, but it cannot always understand the deep architectural context of a complex legacy system. That remains a human-only job.
Maturation, Not Decline
AI is great at the first 80%. It handles the syntax and the boilerplate, but the remaining 20%, the part that actually makes a solution robust and secure, is where we come in. You can read more and make your own conclusions in Kanshi Tanaike’s post.
The “USB-C for AI” has officially arrived at Google.
If you have been following the rapid rise of Anthropic’s Model Context Protocol (MCP), you know it promises a standardised way for AI models to connect to data and tools. Until now, connecting an LLM to your Google Drive or BigQuery data meant building custom connectors or relying on fragmented community solutions.
Here is an overview of the different approaches emerging for MCP tools and what the future looks like for Workspace developers.
The Official Path: Managed MCP Servers
Google’s announcement represents a massive shift in how they view AI agents. Rather than asking developers to wrap every granular API endpoint (like compute.instances.insert) into a tool, Google is releasing Managed MCP Servers.
Think of these as “Client Libraries for Agents.” Just as Google provides SDKs for Python or Node.js to handle the heavy lifting of authentication and typing, these managed servers provide a simplified, reasoned interface for agents.
The announcement lists a massive rollout over the “next few months” covering everything from Cloud Run and Storage to the Android Management API. The goal described is to make MCP the standard way agents connect to the entire Google ecosystem. To start with Google announced MCPs for:
Google Maps: instead of just raw data, the agent gets “Grounding Lite” to accurately answer location queries without hallucinating.
BigQuery: The agent can interpret schemas and execute queries in place, meaning massive datasets don’t need to be moved into the context window.
Google Kubernetes Engine (GKE): Agents can diagnose issues and optimize costs without needing to string together brittle CLI commands.
The Community Path: Privacy-First and Scriptable
While managed servers are excellent for scale and standardisation, there are some other notable approaches using local execution.
1. The Gemini CLI Workspace Extension As detailed in a recent tutorial by Romin Irani, the official google-workspace extension for the Gemini CLI takes a privacy-first approach. Instead of running in the cloud, the MCP server runs locally on your machine.
It uses your own local OAuth token, meaning your data flow is strictly Google Cloud <-> User's Local Machine <-> Gemini CLI. This is ideal for tasks like searching Drive, checking your Calendar, or drafting Gmail replies where you want to ensure no third-party intermediary is processing your data.
2. The Power of Apps Script (gas-fakes) For true customisability, Kanshi Tanaike has been pushing Google Apps Script. A recent proof-of-concept using gas-fakes CLI demonstrates how to build MCP toolsdirectly using Apps Script.
This is a big step for Apps Script developers. It allows you to write standard GAS code (e.g., DriveApp.getFilesByName()) and expose it as a tool to an MCP client like Gemini CLI or Google Antigravity. Because it uses the gas-fakes sandbox, you can execute these scripts locally, bridging the gap between your local AI agent and your cloud-based Workspace automation.
The Future: A Universal MCP Strategy?
We are likely moving toward a world where every Google product launch includes three things: API documentation, Client SDKs, and an Official MCP Server Endpoint.
For developers, the choice will come down to granularity and control:
Use Managed Servers when you need reliable, standard access to robust services like BigQuery or Maps with zero infrastructure overhead.
Use Community/Local Tools (like the Workspace extension or gas-fakes) when you need rapid prototyping, deep customization, or strict data privacy on your local machine.
The “Agentic” future is here, and whether you are using Google’s managed infrastructure or writing your own tools, the ecosystem is ready for you to build.
gas-fakes includes a sandbox feature in an emulation of Apps Script on Node that allows you to control file access and manage test artifacts
The rise of generative AI tools like the Gemini CLI has unlocked incredible potential for automating Google Workspace, allowing developers to generate Google Apps Script code from simple, natural language prompts. However, this power comes with a significant security challenge: how can you safely execute code generated by an AI without granting it broad, potentially risky permissions to your Google Drive?
In a brilliant example of community collaboration, two distinguished developers, Bruce Mcpherson and Kanshi Tanaike, have provided a powerful solution to this very problem. Their combined work showcases an elegant architecture for creating a secure “Fake-Sandbox,” allowing developers to test and run AI-generated code with confidence.
The Problem: The All-or-Nothing Permission Model
At the heart of the issue is that Google Apps Script’s core services often require sweeping permissions. For example, a script designed to organise files often needs the https://www.googleapis.com/auth/drive scope, which grants it sweeping access to all of a user’s files and folders in Google Drive. This presents a clear risk when running code from a source you don’t fully control, as an unintended command could have far-reaching consequences.
Bruce Mcpherson’s Foundation: gas-fakes
The technical cornerstone of the solution is gas-fakes, a powerful Node.js library created by Bruce Mcpherson. This library ingeniously emulates a Google Apps Script environment locally. It works by translating familiar Apps Script calls (like SpreadsheetApp.create()) into their equivalent, direct Google API requests. The library already provides extensive support for the most-used services, including SpreadsheetApp, DocumentApp, DriveApp, and SlidesApp, along with their advanced service counterparts.
This abstraction is the key. By funnelling actions through the underlying APIs, gas-fakes makes it possible to work with more granular, file-specific permissions—a level of control not available with the standard Apps Script services.
Kanshi Tanaike’s Vision: The “Fake-Sandbox”
Seeing the potential of this library, Google Workspace Developer Kanshi Tanaike authored a detailed feasibility study proposing its use as a “Fake-Sandbox.” Tanaike demonstrated how gas-fakes could be integrated directly into the Gemini CLI workflow.
His approach is both simple and effective:
Generate Code: A user provides a prompt to the Gemini CLI (e.g., “Create a new Google Sheet and add the value ‘Hello, World’ to cell A1”).
Execute Locally: The generated Apps Script code is then executed locally on Node.js.
Translate and Secure: The gas-fakes library intercepts the Apps Script commands, translates them into permission-controlled Google API calls, and executes them securely.
Crucially, any files created during this process are contained within the sandbox session. At the end of the run, a simple command (ScriptApp.__behavior.trash()) automatically cleans up by moving all created files to the Google Drive trash, leaving the user’s Drive pristine.
Taking it Further: Granular Controls
Building on this concept, the gas-fakes library now includes even more sophisticated sandbox controls, as detailed in a follow-up post. Developers can now implement:
Whitelists to grant read-only or write access to specific, pre-existing files.
Per-Service Rules to disable entire services (like DocumentApp) or restrict a service to a specific list of approved methods.
Ultimately, this work provides a vital safety net for innovation. It gives developers the confidence to experiment with AI-generated code, knowing that their core data is protected by a robust and highly configurable sandbox. This practical solution removes a major barrier to entry, establishing a clear blueprint for safely embracing the next wave of Google Workspace automation.
To dive deeper into this solution check out the source links below:
This article explores the integration of the Gemini Command-Line Interface (CLI) with Google Sheets using the Model Context Protocol (MCP). It demonstrates how to leverage the open-source projects MCPApp and ToolsForMCPServer to create a bridge between the Gemini CLI and Google Workspace. This enables users to perform powerful data automation tasks, such as creating, reading, and modifying tables in Google Sheets directly from the command line, using natural language prompts. The article provides practical examples and sample prompts to illustrate the seamless workflow and potential for building sophisticated, AI-powered applications within the Google Cloud ecosystem.
For developers who work in the command line, the introduction of Google’s Gemini Command-Line Interface (CLI) has opened up new ways to interact with AI. The open-source tool allows you to bring the power of Gemini models directly into your terminal, making it a useful companion for coding assistance, content generation, and task automation. While the CLI can interact with your local file system and the internet, its standard capabilities don’t provide a direct path to your personal data within Google Workspace.
But what if you could extend it? What if you could create a secure connection, allowing the Gemini CLI to interact with your own files in Drive, events in Calendar, or emails in Gmail?
Over the past month, Google Workspace Developer Expert Kanshi Tanaike has published an insightful series of blog posts that provides a practical blueprint for achieving just that. In this series, he demonstrates how to use the flexibility of Google Apps Script to create a powerful, personalised bridge between the Gemini CLI and the entire suite of Google Workspace services.
At the centre of Kanshi’s solution is a simple and effective architecture. He shows readers how to build a Model Context Protocol (MCP) server using a Google Apps Script project deployed as a Web App. This server acts as the secure intermediary between the Gemini CLI and your Google account.
The key advantage of this approach lies in its security and simplicity. By using Apps Script, the complex and critical OAuth2 authorisation is handled natively within the Google ecosystem. This means developers can create a robust tool without the overhead of managing credentials or setting up separate cloud infrastructure.
Throughout the series, Kanshi doesn’t just provide the theory; he delivers the tools to make it happen. He has developed and shared two key open-source Apps Script libraries, MCPApp and ToolsForMCPServer, which significantly simplify the process. These libraries provide a ready-to-use framework and a rich set of functions for interacting with Workspace services.
The result is a system capable of executing complex, multi-step automations from a single, natural-language prompt. The examples in his posts speak for themselves:
Automated Data Entry: Fetching a multi-day weather forecast and populating it directly into a Google Sheet.
Content Creation: Uploading a local PDF to Drive, generating a summary, creating a new Google Slides presentation from that summary, and emailing it to a colleague.
Interactive Tasks: Generating a custom survey in Google Forms and sending out the link via Gmail.
This extensibility is what sets the approach apart. While a standard tool like the Gemini App (gemini.google.com) provides a familiar conversational interface, it offers a fixed set of features. This CLI-based method allows developers to keep that same intuitive, conversational style of interaction but makes it completely extensible. With the CLI and a custom MCP server, developers are no longer limited—they can build bespoke tools to solve their specific challenges.
For example, a common request from Workspace users is the ability to generate an entire presentation from source material. Using this framework, a developer could easily build a custom tool to do just that, triggered by a single command.
This series is a great example of the innovation happening within the Google Workspace developer community. While this command-line approach is naturally suited for developers and power users comfortable with scripting, it offers a level of control and automation that is difficult to achieve through graphical interfaces. It provides a clear, powerful, and extensible pattern for anyone in this group looking to explore their own sophisticated AI-powered automations.
We highly recommend diving into the series to see what’s possible. You can start with the most recent post, which links back to the previous articles in the series:
Exploring Agent2Agent (A2A) protocol implementation in Google Apps Script seamlessly allows AI agents to access Google Workspace data and functions. This could enable complex workflows and automation, overcoming platform silos for integrated AI applications.
The buzz around AI and collaborative agent systems is growing, and with it, the need for standardized communication. The recently introduced Agent2Agent (A2A) protocol aims to enable exactly that – allowing different AI agents, regardless of their underlying framework, to discover each other’s capabilities and work together. But how can the Google Workspace developer community tap into this exciting new frontier?
Enter prolific Apps Script contributor Kanshi Tanaike, who has once again provided a valuable resource for the community. Kanshi has published a detailed guide and a Google Apps Script library demonstrating how to build an Agent2Agent (A2A) server using Google Apps Script.
Why is this significant?
Kanshi’s work explores the feasibility of implementing a core A2A server component directly within the Google Workspace ecosystem. As Kanshi notes, “Such an implementation could seamlessly allow AI agents to securely access and utilize data and functionalities across Google services like Docs, Sheets, and Gmail via a standardized protocol.”. This opens up possibilities for:
Integrating AI agents with your Google Workspace data: Imagine AI agents that can directly interact with your Sheets, Docs, Drive files, or Gmail.
Building sophisticated AI-powered workflows: Automate complex tasks that span across different services, orchestrated by communicating AI agents.
Kanshi’s guide walks through the setup and implementing functions that allow AI agents to interact with Google Workspace services like Drive or external APIs via UrlFetchApp. This work significantly lowers the barrier to entry for Google Workspace developers looking to experiment with and implement A2A-compatible agents and as such I highly encourage you to check out the linked source post for the complete guide, code, and library details.
This is a sample Google Apps Script designed to replace all instances of specific text within a Google Slides presentation, while simultaneously applying a desired text style. The built-in Presentation.replaceAllText() method within the Google Slides service is limited; it efficiently replaces text strings but lacks the functionality to modify text formatting during the replacement process. This limitation poses a challenge when aiming for styled text replacements. This report presents a detailed script solution that overcomes this constraint.
Have you ever needed to replace text across your Google Slides presentation but also wanted to apply specific formatting to the new text at the same time? The standard replaceAllText() method in Apps Script is handy for bulk text replacement, but it falls short when you need to control the styling – like font, size, or colour – during the replacement process.
Community contributor Kanshi Tanaike has developed a clever solution to overcome this limitation. Tanaike has shared a Google Apps Script function that not only finds and replaces text throughout all elements in your slides (including shapes, tables, and grouped objects) but also applies your desired text styles simultaneously.
The script works by iterating through the elements on each slide. When it finds the text you want to replace, it uses TextRange methods to perform the replacement and apply the specified formatting attributes, such as font family, size, colour, bold, italics, underline, and more.
This approach provides significantly more control than the built-in method, allowing you to ensure that automatically replaced text matches the exact styling you need for visually consistent and polished presentations. Tanaike’s post includes the full script, configuration details for specifying the text and styles, and sample slides showing the results.
Gemini API now generates images via Flash Experimental and Imagen 3. This report introduces image evolution within conversations using Gemini API with Google Apps Script.
The Gemini API recently gained the ability to generate images. Taking this a step further, Kanshi Tanaike has explored how to create evolving images within a conversation using Google Apps Script.
Often, you might want to generate an image and then iteratively add or modify elements in subsequent steps. Kanshi’s approach cleverly uses the chat functionality of the Gemini API (gemini-2.0-flash-exp model). By sending prompts sequentially within a chat, the API uses the conversation history, allowing each new image to build upon the previous one. This enables the generation of images that evolve step-by-step based on your prompts, as demonstrated in the original post with examples like drawing successive items on a whiteboard.
This technique is particularly useful because, as noted in the post, using chat history provides better results for this kind of sequential image generation compared to generating images from isolated prompts.
Kanshi Tanaike’s original post includes a detailed explanation, setup instructions (including API key usage and library installation ), and complete sample code snippets that you can adapt for your own Google Workspace projects.
The data reveals a notable decrease in Stack Overflow activity related to Google Apps Script from 2023 to 2024. There’s a reduction in total questions, questioners, answerers, and tags used. Interestingly, the ratios of answered and solved questions have increased. This suggests that while there’s less activity, a higher proportion of questions are getting resolved. A key factor influencing these trends is likely the rise of generative AI.
The latest report on the google-apps-script tag on Stack Overflow, published by Kanshi Tanaike, paints a fascinating picture: Google Apps Script is a maturing platform, but it’s also undeniably at a critical juncture. As Tanaike notes, “the rise of generative AI” is reshaping the developer landscape, and this is clearly reflected in the data.
The declining volume of basic Google Apps Script questions on Stack Overflow is arguably not a sign of the platform’s decline, but rather a signal of a significant evolution. This shift demands our attention and a willingness to explore the new opportunities and challenges it presents. This means actively seeking out new opportunities, adapting our skillsets, and rethinking traditional approaches to Google Apps Script development.
I believe the future of Apps Script rests on the skills of its developers and the strength of its community. Fostering a community capable of tackling complex integrations, building sophisticated automation within Google Workspace, and leveraging AI to enhance Apps Script’s capabilities is paramount. Supporting both current and new Apps Script developers, enabling them to unlock the platform’s full potential, is a key part of this future. The core value proposition, Apps Script’s unparalleled integration with the Google ecosystem, remains strong.
The real challenge, and the opportunity, lies in how the Google Apps Script community adapts, supporting knowledge sharing that goes beyond basic Q&A and cultivating a culture of deep understanding, critical thinking, and collaborative problem-solving. For us at AppsScriptPulse, this means continuing to share not just code snippets, but also design patterns, architectural best practices, and strategies for effectively integrating and evaluating AI-generated code.
Google Apps Script automates tasks like managing protections in Google Spreadsheets. These protections control user access to specific cells. While scripts exist for this purpose, users still encounter challenges, prompting this report. The report aims to introduce techniques for managing protections using sample scripts, helping users understand and implement this functionality.
Google Sheets aficionados are likely no strangers to the “Protect sheet” and “Protect range” options tucked away in the menus. These features offer a basic level of control over who can edit what within your spreadsheet. But what if you need more dynamic, automated control over these protections? That’s where the power of Google Apps Script and the Sheets API comes into play.
This post from Kanshi Tanaike provides a deep dive into how you can programmatically manage protections in your Google Sheets. While the traditional menu options are great for static scenarios, using Google Apps Script allows you to create more flexible and powerful protection workflows.
Why Go Script?
Dynamic Protections: Instead of manually adjusting protections, you can use scripts to change them based on specific conditions or events within your spreadsheet.
Automation: Integrate protection changes into larger automation workflows, streamlining processes and reducing manual intervention.
Granular Control: Achieve a level of control over cell-level permissions that goes beyond the standard menu options.
Some possible use cases for developers could include:
Approvals Automation: Imagine a scenario where certain parts of a spreadsheet need to be locked down once a manager approves them. With this solution, you could create a script that automatically protects those ranges upon approval.
Time-Limited Editing: Need to open up a section of a spreadsheet for editing only during a specific window of time? You could use Google Apps Script to handle this, automatically protecting
The scripts provided by Kanshi Tanaike offer a starting point for exploring these possibilities.
Google Apps Script offers Document service for basic document tasks and Google Docs API for advanced control, requiring more technical expertise. This report bridges the gap with sample scripts to unlock the API’s potential.
Kanshi Tanaike’s latest blog post, “Unlocking Power: Leverage the Google Docs API Beyond Apps Script’s Document Service,” is a great read for Google Workspace developers. It offers a goldmine of code snippets that will supercharge your Google Docs projects. Tanaike highlights the advantages of using the Google Docs API for more advanced features and flexibility compared to the standard Apps Script DocumentApp Service. Even though the API requires a bit more technical know-how, Tanaike provides clear, practical examples to get you started.
Some of the sample snippets include:
Changing page orientation (portrait to landscape and vice versa)
Kanshi Tanaike’s post serves as a valuable resource for developers looking to expand their Google Docs capabilities. Hopefully with these sample scripts, you can start unlocking new levels of automation and customization in your Google Doc projects.
To delve deeper into the world of Google Docs API, follow the source link post.
