Designing for an accelerating AI evolution
I worked on several Gemini Code Assist (GCA) projects. This journey was about continuously redesigning the fundamental relationship between developers and AI. Tools and Agent Mode were one of the top highlights that transformed GCA into a truly powerful, autonomous partner.
Problem to solve: How to connect external context to GCA?
Developers spend significant time switching between their code and external tools (GitHub, Jira) where crucial project information resides. Our challenge was to let developers connect all their external context to GCA to improve their productivity throughout the entire development lifecycle.
This was a critical differentiator for GCA's enterprise adoption, as a secure and context-aware coding assistant is important for large organizations.
The first attempt: GCA native tools
The initial technical strategy was to leverage Developer Connect, a Google Cloud service I was the design lead for, as the secure backend for individual user authorization. I then joined the GCA Tools team for this integration, responsible for translating a complex authorization model into a simple, trustworthy user experience.
Over 2 months, I designed the end-to-end tools management flow for both organizational admins and individual developers across the free and paid GCA tiers, partnering closely with PMs and engineers on both the GCA team and the Developer Connect team to ensure the design was technically feasible.
Ideal design for the free tier agents and tools management console
A free tier user’s journey usually starts in their IDE (where they code). The design provides them easy access to the agents and tools management console. If they call a tool in their prompt before connecting it, GCA will provide a link to the console in the response too.
Due to Developer Connect’s technical setup, a tool has to be first enabled in the console (usually by an admin), and then connected to their tool account (by individual developer). However, a free tier user will carry out both admin and developer steps, so the ideal design above attempted to streamline the process without extra clicks and keep users informed on the state of their tools.
The ideal design hides all other Developer Connect specific configuration from users and uses smart defaults behind the scene, because GCA users shouldn’t be confused by a Google Cloud service they don’t know about.
Tight timeline pushing ideal to MVP
Given engineers didn’t have much time to complete everything in the ideal design, I iterated and arrived at the MVP version, but ensured that users are informed on each step what they’re doing and why. Below is a setup flow of an admin on a paid tier.
User flow of an admin on a paid tier enabling a tool
The most important design element of this launch is the consistency between free tier and paid tier for good user experience as well as optimizing engineering efficiency and ease of maintenance.
In this MVP version, each tool card itself on the landing page is clickable, instead of showing a different button based on the tool’s state.
In the tool details panel, we didn’t have rich metadata per tool before launch, and making smart defaults of Developer Connect configuration was cut out of scope, the MVP version is a simplified version with a short configuration form. The full configuration is available to admins behind a button.
Pivoting to a more scalable solution
At the time, the plan to scale was creating a marketplace for community contribution where providers could submit their tools. This way removed the need for our team to manually create and manage an integration for each tool. However, this native integration model still had a scalability challenge.
Changing direction: Ride the wave of MCP
Not too long after the launch of GCA tools, the industry and the developer community started to rapidly adopt “Model Context Protocol” (MCP) for its flexibility. It solved the same problem using an AI-assistant-agnostic approach.
“Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.”
Simultaneously, the industry was shifting from traditional AI chat (Q&A) to an agentic framework — where an AI agent plans and executes on the user's behalf (e.g., creating a pull request, modifying code).
Our team started to look into integrating MCP into the next generation of GCA, the new “Agent Mode”. I transitioned to this project to work with 2 other designers. It had a tight deadline in 2 months due to competitor urgency.
Initial concept of an inline visual MCP management
I did a competitive analysis on other AI coding assistants’ MCP UX which informed many requirements later.
From my analysis, a differentiator for GCA could be a user-friendly way of managing MCP, since most competitors only offered a basic json file. I explored a no-code MCP management experience inside the IDE to consolidate all the scattered settings in one place.
This way, users can easily see MCP servers’ status and adjust their trust level for each server or tool.
However, this required high engineering effort and shipping the core agentic chat experience was the top priority, so I paused on this effort and shifted focus to designing post-MCP-installation UX.
Shifting design focus to displaying MCP calls in the agent’s response
While in the previous native solution, developers had to explicitly @ mention a tool in their prompt to invoke it, they don’t have to do so with MCP in the Agent Mode. The agent will pick the best one based on the user’s prompt.
Agent Mode uses both external MCP tools installed locally by the user and built-in tools to support basic common operations (e.g., file reading and writing, shell commands).
One critical design goal on how we display a selected MCP / tool in the chat response is ensuring a consistent, unified user experience regardless of the tool's source.
Design iterations: Integrating with the agent’s thinking process
Mock of an agent self-correcting itself
One thing that makes the Agent Mode different from the traditional chat experience is that the agent not only knows to think, but also to observe the result and act accordingly. This gives it the ability to self-correct without a user prompt. The technical term is called the “ReAct loop”.
The main focus in the next few iterations was to integrate MCP / tool call displays into the agent’s thought process, and add more user controls.
Design principles: Trust & User control.
Let users “trust” a tool by always allowing it to run, especially those common operations, so they don’t need to sit there and wait to click the Run button.
Included a warning message because all MCP tools are installed by users onto their machines directly.
Differentiated a tool call display and a thinking indicator, and let users expand to see details while keeping the response stream easy to follow.
Let users stop the agent since we noticed it could go into an infinite loop sometimes.
Iterating on visuals
While the agent knows to pick the best MCP / tool without the user specifying one, it can still be wrong sometimes, especially when the user has too many MCP installed and some have overlapping functionalities.
I then explored the idea of representing a MCP server via the familiar @ format and introducing / (slash commands) to surface a specific tool from a server.
Given the agent’s response is already a big wall of text, I explored with my design partners about adding icons to show status on the tool card and reducing visual clutter.
Final design: integrating with an agent’s multi-step plan
One last piece to make the agent really powerful is that AI creates a plan of a sequence of steps first before taking any action.
I designed the chat response and interaction patterns to clearly visualize agent’s step-by-step execution. This allowed users to easily follow the AI’s progress, understand its next action and the entire process.
With the step cards coming to play, I worked with my design partners and engineers to further simplify the visual of the tool card to avoid repetition of icons.
A researcher then conducted a user study to validate the design. We received positive feedback about the clarity of the agent’s process.
Explorations on an MCP indicator
Options of an MCP indicator. Click to see in full screen.
From my competitive analysis, I learned that it’s helpful for users to quickly see their MCP status before prompting the agent. I then explored options of showing an indicator near the prompt input.
The hypothesis is that users don’t often interact with individual servers. As long as it’s discoverable for them to troubleshoot, this indicator doesn’t have to be too prominent.
I reviewed with other designers to analyze all the options, and landed on the consolidated settings icon (option 6) which also gave us a place to house upcoming features without crowding the limited space.
Though the visual MCP management experience, the @, slash commands, planning, and the persistent indicator weren’t part of the MVP that shipped, it laid a solid ground for the team to work towards the next milestone.
At the time of writing, my team is polishing the Agent Mode experience with the goal of bringing it to General Availability by the end of 2025.
Switching focus to Gemini CLI
For the longest time, a chat GUI had been the dominant surface where developers interacted with AI in natural language. Most recently, AI coding tools were actually shifting to a surprising place: The terminal. See this TechCrunch article.
Gemini CLI was a super accelerator and powerful engine to the Agent Mode project. As a designer, I had to make sure developers had consistent and integrated experience between GCA and Gemini CLI, instead of two disconnected products.
Below is a mock I created to prompt Gemini CLI users to install an extension to bridge their code editor and the CLI, so they can get better responses from the agent.
Looking back and ahead
My 1.5-year journey on Gemini Code Assist put me at the forefront of the AI coding assistant revolution, where user priorities have evolved at a fast pace. This journey was about continuously redesigning the fundamental relationship between developers and AI.
I witnessed the developer priority shift from model quality to context and control in three stages:
-
Initial focus was simply on response quality — does the AI give correct answers?
-
As models matured, the focus shifted to how well AI understood the user's world. The challenge was how to give AI the right information. Developers wanted AI to have secure access to their enterprise codebases and external tools (e.g., GitHub). UX was critical in enabling controls and reliable context access.
-
The current stage — AI transitions from assistant to executor. Developers give it a direction and the outcome they desire, and let AI plan and take actions across the development lifecycle, like modifying code and acting on external tools, on the user's behalf.
This project perfectly showcased how fast AI product development could evolve in just 6 months. To be a leader in the space, speed is definitely a key. I wouldn’t have imagined in such a short time, users would go from not trusting AI’s code suggestions to embrace the autonomous AI agent to act throughout their development lifecycle!
It’s a fruitful and humble learning experience of designing in a fast-paced environment and keeping up with the latest technology! It’ll be faster from now on, definitely not slower!