DEV Community: Heysho

Build with Gemini Event Review: Developing AI Agents with ADK and Agents CLI

Heysho — Sun, 06 Sep 2026 10:14:11 +0000

I recently attended Build with Gemini Tokyo, a two-day event hosted by Google.

https://cloudonair.withgoogle.com/events/build-with-gemini26q3

The event was a hands-on workshop focused on building AI agents using tools such as Antigravity, ADK (Agent Development Kit), and Agents CLI.

Rather than simply learning about these tools through lectures, we went through the full development workflow ourselves—from creating an agent locally to deploying it on Google Cloud.

One of the main reasons I decided to attend was that I wanted to change the way I approach AI-assisted development.

Over the past six months to a year, I’ve increasingly relied on AI to build web applications and conduct data analysis. The tools I use most often are Antigravity and Codex.

At the same time, however, my development process had become somewhat repetitive.

I would typically start by defining the requirements, break them down into a detailed implementation plan, and then have AI write the code based on that plan. This is fairly close to what is often referred to as spec-driven development.

More specifically, I would create an implementation plan in Antigravity, have a more capable model review and refine it, and then pass the finalized plan to another model for implementation.

I had become very comfortable with this workflow, and before I knew it, I had been developing in essentially the same way for the better part of a year.

There is nothing inherently wrong with this approach—it works well for building software. But recently, I had started to feel that my process was becoming a little too predictable, and I wanted to experiment with a different way of working with AI.

That was when I came across Build with Gemini, an event focused on building applications by combining Google Cloud with AI agents.

In this article, I’ll share what we actually did at the event, my impressions of working with ADK and Agents CLI, and what the experience made me realize about my own development style.

Tools I Learned in This Workshop

In this workshop, we mainly used three tools: Antigravity, ADK, and Agents CLI.

Antigravity

Antigravity is a development environment designed for building software with AI assistance. I normally use Antigravity IDE, but during this workshop, we worked in an Antigravity 2.0 environment prepared specifically for the hands-on sessions.

ADK (Agent Development Kit)

ADK is a framework for building AI agents. It allows you to define how an agent behaves and which tools it can use, while supporting the broader development workflow, including building, testing, and running the agent.

Agents CLI

My understanding is that Agents CLI provides Skills designed to support agent development. These Skills make it easier to delegate not only ADK-based implementation, but also tasks such as testing and deploying agents to Google Cloud.

Benefits of Using These Tools Together

What stood out to me after using them was how much of the development process could be delegated to AI by combining Antigravity, ADK, and Agents CLI.

You could start with a simple natural-language instruction such as:

“I want to build an agent like this.”

From there, AI could handle a large part of the workflow, from implementation and testing to deployment on Google Cloud.

This felt quite different from the way I had been developing before, where I would first define detailed specifications and then ask AI to implement each part step by step.

With these tools, it felt possible to delegate work to AI in much larger chunks.

That was one of my biggest takeaways from the workshop.

Realizing the Difference in Development Styles Through Pair Programming

After the workshops on Day 1 and Day 2, we had a final session where participants paired up and built an agent together.

I paired up with the person sitting next to me, and we decided to build an agent that visualized token usage.

In enterprise projects, teams often use cloud environments or enterprise accounts where AI models are billed based on usage. In those situations, there may be a need to track and visualize how many tokens are being consumed.

The Person Next to Me Deployed in 10–20 Minutes

What surprised me most once we started was how quickly my partner moved.

Within about 10 to 20 minutes, they had already reached the point of deploying the application to Google Cloud.

I, on the other hand, struggled quite a bit and only managed to deploy mine near the end of the session, about an hour and a half later.

We were building fairly similar applications, so why was there such a big difference?

When I asked about their approach afterward, the answer was surprisingly simple.

They gave Agents CLI a rough instruction such as:

“I want to build an app like this.”

Then they focused first on getting something working.

They deployed it as quickly as possible, and only afterward did they gradually refine the application to bring it closer to what they had originally imagined.

I Spent Too Much Time Finalizing the Specifications Up Front

I, on the other hand, had brought my usual development style directly into the workshop.

I first worked with Codex to define the specifications in detail, created requirements and planning files, and then tried to implement everything according to that plan.

Looking back, I think this significantly reduced the benefits of using Agents CLI.

Agents CLI already comes with Skills that support implementation, testing, deployment to Google Cloud, and other parts of the development process.

Even so, I was using another model to recreate much of that implementation process from scratch.

In other words, even though a workflow had already been designed for this environment, I ended up building a separate workflow of my own.

I Was Using Agents CLI Without Really Taking Advantage of It

After the workshop, I also spoke with one of the engineers who had been supporting us.

They explained that there is nothing wrong with taking a spec-driven approach or using Codex to review the plan. However, if you do that, it is better to also provide Codex with the relevant Agents CLI Skills and the latest information about the environment.

Otherwise, another model may create a plan based on outdated assumptions, and that plan may not align well with the mechanisms and workflows already built into Agents CLI.

In my case, I was technically using Agents CLI, but I was not developing in a way that fully took advantage of what it was designed to do.

Next Time, I Want to Deploy First

If I work in a similar environment again, I want to change my approach.

First, I would set up ADK and Agents CLI.

Then I would give them a simple instruction such as:

“I want to build something like this.”

From there, I would focus on getting a working version deployed to Google Cloud as quickly as possible.

Once that was done, I would add features, improve the UI, and gradually bring the application closer to the final version I had in mind.

What I realized through this workshop is that development does not always have to begin with defining everything in detail.

The approach of getting something working first and improving it afterward can also be extremely effective.

Benefits of ADK and Agents CLI

I continued experimenting with ADK and Agents CLI the day after the event, and it reinforced just how useful they can be.

They Can Handle Large Chunks of Implementation

What surprised me most was how much of the implementation they could handle in a single run.

Once I gave them an instruction, they could continue working for quite a while, and by the time I checked again, a substantial amount of code had already been written.

The results were also more reliable than I had expected.

Of course, some corrections were still necessary, but my impression was that they could move a project forward fairly autonomously without requiring detailed instructions for every individual step.

They Can Also Handle Google Cloud Tasks

Another major advantage is the range of tasks they can handle.

Natural-language instructions can be used not only for application development, but also for Google Cloud integration and deployment.

For example, they can help deploy applications to agent runtimes or Cloud Run, as well as set up services such as Firestore.

Previously, whenever I needed to configure something in Google Cloud, I would open the console, find the relevant service, and work through the settings myself.

Since I started using ADK and Agents CLI, however, I have had far fewer reasons to interact directly with the Google Cloud console once the initial environment is in place.

Google Cloud Feels Much Less Intimidating Now

I had always found Google Cloud somewhat intimidating because of the sheer number of services and the complexity of the interface.

But by combining Antigravity, ADK, and Agents CLI, I can now move development forward without having to understand every detail of Google Cloud upfront.

After experimenting with this setup, I felt much more confident about using Google Cloud more actively in future projects.

For me, the biggest takeaway was not just that ADK and Agents CLI are useful development tools, but that they significantly lowered the barrier to using Google Cloud.

About the Workshop Experience and Environment

The Build with Gemini event itself was also very well organized. If I get the chance, I would definitely like to participate again.

A Workshop Designed So No One Gets Left Behind

The workshop began with a lecture, followed by a hands-on session where participants worked along while watching the instructor’s screen.

What stood out to me was how carefully paced the workshop was.

Rather than rushing ahead, the instructors regularly checked whether everyone had reached the same point before moving on. The workshop felt designed to minimize the chances of participants falling behind midway through.

There were also support staff in the room, so whenever I got stuck, I could ask questions right away. That made it much easier to work through the exercises with confidence.

The Venue Was Also Very Comfortable

The venue was a modern facility in Takanawa Gateway, and snacks and drinks were provided as well.

Even though it was a long workshop, the environment was very comfortable throughout the day.

We even received some giveaways, so I was genuinely grateful to be able to experience such a substantial program for free.

Overall, I was very satisfied not only with the technical content, but also with the organization and support throughout the event. If there is a similar opportunity in the future, I would definitely like to join again.

What I Want to Do Next

Now that I have had the chance to learn ADK, Antigravity, and Agents CLI, I want to start using them to build AI agents in real projects.

Building a Mental Health AI Agent

In fact, I have already started developing a web application designed to support mental well-being.

The idea is to create an AI agent that listens to users, helps them organize their thoughts in a way similar to counseling or coaching, and supports them in deciding what to do next.

It is still under development, but I already have a basic prototype in place.

Next: The Zenn × Google Cloud Hackathon

My next goal is to participate in a more serious hackathon organized by Zenn and Google Cloud.

I want to continue improving the AI agent I am currently building and submit it there.

At Build with Gemini, there were some areas where I was not able to take full advantage of Agents CLI. Based on that experience, next time I plan to try a different approach: build something that works and deploy it as quickly as possible first, then improve it afterward.

Moving Beyond Local Development to Something Others Can Use

Until now, I have often run AI agents locally through the CLI.

But if you want other people to actually use an agent as a product, it obviously needs to run in the cloud.

There have been several times in the past when I thought, “It works locally, but how do I actually turn this into a web application that other people can access?”

By going through the full deployment process to Google Cloud during this workshop, I feel that the barrier to doing that has become much lower.

Going forward, I want to make use not only of ADK and Agents CLI, but also Google Cloud services such as agent runtimes and Cloud Run, and challenge myself to build AI products that are not just for my own use, but that other people can actually use as well.

About the Workshop Experience and Environment

The Build with Gemini event itself was also very well organized. If I have the opportunity, I would definitely like to participate again.

A Workshop Designed So No One Gets Left Behind

The workshop began with a lecture, followed by a hands-on session where participants worked along while watching the instructor’s screen.

What stood out to me was how carefully the sessions were paced.

Rather than moving ahead too quickly, the instructors regularly checked that everyone had reached the same point before continuing. The workshop felt thoughtfully designed to make it difficult for participants to fall behind.

There were also support staff throughout the room, so whenever I got stuck, I could ask questions right away. That made it much easier to work through the exercises with confidence.

The Venue Was Also Very Comfortable

The event was held at a modern venue in Takanawa Gateway, with snacks and drinks provided throughout the day.

Even though the workshop lasted for several hours, the environment remained comfortable and easy to focus in.

We also received some giveaways, which made me even more appreciative of being able to take part in such a substantial program at no cost.

Overall, I was very satisfied not only with the technical content, but also with the organization and support throughout the event. If a similar opportunity comes up in the future, I would definitely like to participate again.

What I Want to Do Next

Now that I have had the chance to learn ADK, Antigravity, and Agents CLI, I want to start applying them to real AI agent projects.

Building a Mental Health AI Agent

In fact, I have already started developing a web application designed to support mental well-being.

The idea is to create an AI agent that listens to users, helps them organize their thoughts in a way similar to counseling or coaching, and supports them in deciding what to do next.

It is still under development, but I already have a basic prototype in place.

Next: The Zenn × Google Cloud Hackathon

My next goal is to participate in a larger hackathon organized by Zenn and Google Cloud.

I plan to continue improving the AI agent I am currently building and submit it to the hackathon.

At Build with Gemini, there were some areas where I was not able to take full advantage of Agents CLI. Based on that experience, I want to approach the next project differently: get something working and deployed as quickly as possible, then improve it from there.

Moving Beyond Local Development to Something Others Can Use

Until now, I have often run AI agents locally through the CLI.

But if you want other people to use an agent as a real product, it needs to be accessible beyond your local environment.

In the past, I often found myself thinking, “It works locally, but how do I turn this into a web application that other people can actually use?”

By going through the full deployment process to Google Cloud during this workshop, that step now feels much less intimidating.

Going forward, I want to make use not only of ADK and Agents CLI, but also of Google Cloud services such as agent runtimes and Cloud Run. Ultimately, I want to challenge myself to build AI products that are not just useful to me, but that other people can actually access and use as well.

Reflections on the “Gemini AI Hackathon @ Google Japan in Tokyo”

Heysho — Wed, 02 Sep 2026 08:54:37 +0000

Starting this month, I’ll be participating in the 5th Agentic AI Hackathon with Google Cloud.

The program kicks off with “Build with Gemini Tokyo” on September 3 and 4, where participants will build AI projects using Google Cloud and Gemini.

Since I’m taking part, I want to approach the development process more effectively this time than I did at my previous hackathon.

Before it begins, I thought it would be useful to reflect on the Gemini AI Hackathon @ Google Japan Hackathon Tokyo, which I attended in June 2026.

The previous event was a one-day hackathon organized by AI Builders and Google Japan. With only about five hours of actual development time, participants had to build an AI project, deploy it to the cloud, and present a working demo at the end.

I attempted to build an app using health data from my Apple Watch, but I wasn’t able to complete it before the event ended.

The immediate cause was that six months of health data exceeded 1 GB, making it difficult to import into the app successfully.

Looking back, however, the real problem wasn’t simply that I had “1 GB of data.”

Despite having only around four hours to build the project, I started with the full production dataset instead of first creating the smallest possible version that could work from end to end.

I also failed to plan my time properly. I focused mainly on implementation without setting aside enough time for deployment, the demo, and the final presentation.

To avoid making the same mistakes this time, I want to reflect on what stood out to me at the previous hackathon and organize the lessons I plan to apply to my next one.

The Line Outside the Google Office

When I arrived at the Google office that day, the first thing that surprised me was the long line outside the entrance. I had heard that there would be a lot of participants, but once I joined the queue, I realized the event was much larger than the small study-group-style gathering I had imagined.

I do not know the exact number of attendees, but my impression was that there were more than 300 people at the venue.

What also stood out was how international the crowd felt. Based purely on what I observed, there seemed to be many participants from a wide range of backgrounds, with people from overseas appearing to make up a significant portion of the audience.

I had expected the event to be mostly local, so the diversity of the participants was one of the first things that caught my attention.

This is only my personal impression from being at the venue and is not based on confirmed information about participants’ nationalities or backgrounds.

Most Participants Were Building Alone

Before attending, I had always imagined a hackathon as an event where several people formed a team, divided up the work, and built a single product together. But once the development session began and I looked around the venue, I noticed that many participants were actually working on their own.

I did not count everyone, so this is only a rough estimate, but it seemed that around 70–80% of participants were coding individually. Even among those working in teams, most appeared to be in small groups of two or so.

During the opening briefing, the organizers introduced Google Cloud and several related products, as well as tools that allowed participants to write code from the CLI with AI assistance.

With AI coding tools, it is becoming much easier for a single person to turn an idea into something that actually works. You no longer need a large team just to get a prototype off the ground.

Looking around the venue, I felt that the rapid improvement of these tools may be encouraging more people to think, “I’ll try building it myself first.”

Five Hours for Development, Deployment, a Video, and Slides

As I remember it, the event began with about one or two hours of introductions and explanations, followed by roughly five hours to build a product.

That development window had to cover much more than just coding. Participants also needed to deploy their projects to the cloud, record a demo video, and prepare presentation slides.

If the goal had simply been to build an app, five hours might have felt manageable. But getting something working, deploying it, preparing a demo, recording a video, and putting together slides for the final presentation made the schedule feel extremely tight.

Once I started working, the time seemed to disappear almost immediately.

Participants were also given Google Cloud credits as part of the event. As I recall, the amount was somewhere between ¥10,000 and ¥20,000, although I was unable to confirm the exact value or the conditions for using them.

At the time, I was already subscribed to Google AI Pro, so I decided not to use the credits immediately and thought I would save them for later. In the end, however, I never used them.

My Failed Project

At the time, I was interested in health and fitness, so I decided to build an app using health data collected from my Apple Watch. The idea was to visualize the data and generate personalized suggestions based on each user’s health information.

However, during development, I realized that my own health data had already exceeded 1 GB, even though I had only been using an Apple Watch for about six months. This was not just a case of the dataset being “larger than expected.” For a hackathon with only a few hours of development time, it was simply too large to work with efficiently from the start.

In practice, I was unable to upload the data successfully to the app I had deployed on Google Cloud, and I ended up spending a significant amount of time troubleshooting the issue. I could not determine during the event exactly which service or limitation was causing the problem, so I cannot say that any particular technical constraint was responsible.

In the end, I ran out of time before I could complete the product.

Looking back, I should have started with a small sample dataset and first confirmed that the entire workflow—from uploading the data to processing and displaying it—worked end to end. I also should have had a fallback plan, such as splitting the dataset or switching to a smaller version for the demo if the full dataset proved too large.

The biggest problem was not that AI coding tools failed to generate the code I needed. It was that I introduced a large, production-like dataset before confirming that the basic workflow worked.

With only a few hours available, checking the size and format of the data should have been part of my preparation before the hackathon even began.

Impressive Demos—and Presentations That Ran Out of Time

At the end of the event, I had the chance to watch demos from some of the prize-winning participants. Their UIs were polished enough that it was hard to believe they had been built in just five hours, and the projects had already been deployed to the cloud. Some were even multimodal apps with features such as voice input, rather than simple prototypes that only displayed information on a screen.

While I had spent much of my time struggling with a 1 GB dataset, other participants had managed to take their projects this far within the same limited timeframe. Seeing that was both impressive and motivating.

Watching the winning demos, I got the sense that there was very little hesitation between coming up with an idea and turning it into something that worked. Of course, I did not see their actual development process, but I suspect they had decided early on what they wanted to build—and, just as importantly, how far they needed to take it.

At the same time, some presentations seemed less polished than the products themselves. The apps worked, but a few presenters appeared unsure about what to explain first or how to structure the demo. It made me realize that if you spend every available minute on implementation, you leave yourself almost no time to rehearse the presentation.

There were, of course, also some excellent presenters. Within a few moments, it was clear what they had built, why it mattered, and what they wanted the audience to pay attention to. I learned a lot simply from watching how they structured their demos.

I also noticed that many of the presentation slides had a similar visual style. I wondered whether participants were using a common Google Cloud template or generating their slides with AI, although I did not confirm this, so that is purely speculation.

What stayed with me most was this: as implementation becomes faster, the differences in everything surrounding the implementation become more visible.

How narrowly did you define the scope? How well did you prepare your data? When did you decide to stop coding and start preparing the demo and presentation?

I think this stood out to me because I saw all three things in the same room: highly polished winning projects, presentations that appeared to have run out of preparation time, and my own project that never made it to the finish line.

The experience made me realize that in a short hackathon, coding speed alone is not enough. Scoping, preparation, time management, and presentation are all part of building the final product.

Conclusion: What I Learned from the Hackathon

At this hackathon, I was not able to finish and submit a completed product.

Looking back, the main problem was not a lack of AI coding skills. It was that I failed to narrow the scope, decide how far I needed to take the project within the limited time, and validate the workflow before introducing a large, production-like dataset.

At the same time, I saw many participants working alone and still managing to complete their cloud deployment, demo video, and presentation within just a few hours. With AI-assisted development, individuals can now turn ideas into working products much faster than before. Experiencing that firsthand was one of the biggest takeaways for me.

But I also realized that as implementation becomes faster, the skills surrounding implementation become even more important: deciding what to build, preparing the data, managing time, knowing when to stop coding, and communicating the result clearly at the end.

Next time, I want to approach the process differently. I will first test the entire workflow end to end with a small sample dataset. I will decide in advance when to stop implementation, and I will treat the demo and presentation as part of the product itself rather than something to prepare at the very end.

Because I failed to finish this time, I now have a much clearer idea of what I need to change.

At the next hackathon, I want to apply these lessons directly and make sure I take the project all the way from idea to working demo.

I Analyzed 1,000 Keywords with Python to See How AI Overviews Relate to Google Rankings

Heysho — Sat, 29 Aug 2026 01:55:52 +0000

Recently, I conducted a research project on the relationship between Google AI Overviews and organic search rankings, and published the findings on my website:

https://heysho.com/en/geo/research-aio-organic-ranking.html

Rather than going into detail about the findings themselves, in this article I’d like to share some of the behind-the-scenes aspects of the research that I couldn’t fully cover in the original report, including:

Why I decided to conduct this research
How I analyzed around 1,000 search queries
What I found challenging during the implementation
What I learned from actually looking at the data

I’ll also share some of the challenges, discoveries, and interesting lessons I encountered throughout the research process.

1. Do Google Rankings Still Matter in the AI Overview Era?

Over the past six months or so, I’ve been spending a lot of time researching GEO and AI search. I’ve created my own reports and looked closely at how brands appear in actual AI-generated answers.

One question kept coming up:

“How much does a brand’s Google ranking affect its chances of appearing in AI-generated answers?”

As I looked at different brands, I started noticing some interesting patterns.

Some brands don’t seem particularly focused on SEO, yet they are frequently recommended by ChatGPT and other AI search platforms.

On the other hand, some companies perform very well in Google Search, but their brand names don’t appear nearly as often in AI-generated answers.

That made me wonder:

How much do traditional SEO rankings really influence visibility in AI search?

There was also a more practical question I wanted to answer: What ranking position should we actually aim for?

When working on SEO for a large website, you might track KPIs such as:

The number of non-branded keywords ranking in the Top 10
The number of keywords ranking in the Top 5

But once AI search enters the picture, it becomes less clear which ranking thresholds actually matter.

Should we aim for the Top 3?
Is the Top 5 enough?
Does ranking in the Top 10 still make a meaningful difference?
Or can a position around 15th still have some impact?

The answer could affect how we prioritize SEO initiatives.

That’s what motivated me to collect the data myself and compare Google organic rankings with visibility in AI Overviews.

2. How I Analyzed 1,000 Keywords

In the end, I analyzed around 1,000 keywords, but I didn’t start by simply putting together a list of 1,000 queries.

First, I used Semrush to collect a large set of product-category keywords. The initial dataset contained nearly 100,000 keywords.

After removing obviously irrelevant terms, I narrowed the list down to around 50,000.

Classifying that many keywords manually would have taken a huge amount of time, so I used Python, LangChain, and LLM APIs to help automate the process.

For this study, I then narrowed the scope further to queries in the format “product category + recommended.”

For example:

“T-shirt recommended”
“hair dryer recommended”
“tent recommended”

The reason I chose this query format was simple: it makes it easier to analyze whether specific brands appear in AI Overview responses.

If someone searches only for “T-shirt,” the intent is relatively broad and ambiguous.

With a query like “recommended T-shirts,” however, the response is much more likely to include specific product or brand recommendations.

I created keyword pools across five categories—beauty, consumer electronics, apparel, furniture, and outdoor—and eventually narrowed the dataset down to around 15,000 candidate keywords.

From there, I selected the top 200 keywords in each category by search volume, giving me roughly 1,000 queries in total.

I didn’t jump straight to 1,000 queries, though.

I started small, testing with 20, then 50, and finally 100 queries.

By the time I had analyzed around 100 queries, the overall pattern was already becoming fairly clear. That suggested I probably didn’t need to analyze tens of thousands of keywords to see the broader trend.

So for the final study, I scaled the analysis up to around 1,000 queries.

3. What Did I Collect with Python + SearchApi?

I used SearchApi to retrieve Google search results.

Each request returns a JSON response containing a wide range of SERP data, including:

Organic search results
AI Overviews
References and citations within AI Overviews
Ads
Shopping results

Technically, it’s possible to build your own Google Search scraping pipeline, and I’ve written similar scripts myself in the past.

But once you need to collect hundreds or thousands of SERPs reliably, managing the entire process yourself can become quite a lot of work.

Being able to retrieve all of this data quickly through an API made the research process much easier.

I think this kind of service is particularly useful for SEO agencies that need to collect SERP data at scale across multiple clients, as well as for teams working on large websites or global SEO projects.

For individual use, however, there is still a trade-off between convenience and monthly cost. That was my impression after using it for this project.

For this research, I mainly extracted Google organic rankings along with the AI Overview response text and citations, then linked the two datasets together for analysis.

4. The Biggest Challenge: Brand Name Variations

One thing that turned out to be surprisingly difficult during the implementation was identifying brand names accurately.

Brand names can appear in many different forms in AI-generated answers.

For example, the same brand might appear as:

Its English name
Its name written in katakana
The full legal company name
Just the brand name
An abbreviation
A version with or without spaces

If you rely only on exact string matching, the same brand can easily be treated as multiple different brands.

To address this, I created a brand-name dictionary and added a normalization process so that different variations could be mapped back to the same brand.

Even then, it was difficult to automate the process completely, so I also manually reviewed some of the results.

This made me realize that brand-name variation is an important issue when using GEO / AI search tracking tools for Japanese queries.

If you’re using a GEO tool developed outside Japan, it may be worth checking how well it recognizes an English brand name, its katakana version, and the Japanese legal entity name as the same brand.

A dashboard may show clean-looking numbers, but if the underlying brand matching is inaccurate, the reported mention rate can change significantly.

It’s not the most glamorous part of the process, but it ended up being one of the most important lessons from this research.

5. How Often Do AI Overviews Actually Appear?

Of the roughly 1,000 queries I analyzed, AI Overviews appeared for around 70% of them.

Personally, I found that surprisingly high.

Of course, this was probably influenced by the fact that the study focused heavily on “product category + recommended” queries.

For example, Google may show very different AI Overview results for a search like “bicycle” or “T-shirt” compared with “recommended bicycles” or “recommended T-shirts.”

So if your goal is to measure how often your brand is recommended in AI search, it may be more useful to track queries that are likely to trigger brand recommendations rather than relying only on generic category terms.

For example:

“recommended [product category]”
“popular [product category]”
“recommended [product category] brands”
“[product category] rankings”

Designing queries around recommendation intent makes it much easier to measure how often your brand appears in AI-generated answers.

6. If You Rank #1 on Google, Are You More Likely to Appear in AI Overviews?

This was the question I was most interested in answering.

If a brand ranks #1 on Google, is it also more likely to appear in AI Overviews?

The results were quite interesting.

Among companies and brands ranking #1 in Google Search:

The AI Overview citation rate was around 52%.
The brand mention rate was around 20%.

The citation rate was higher than I expected. In other words, pages ranking #1 in organic search were also cited as a source in AI Overviews in roughly half of the cases.

The brand mention rate, however, was much lower at around 20%.

Before running the study, I had assumed that if a brand ranked #1 on Google, its name would also appear in AI Overviews fairly often.

In reality, that happened only about one in five times.

That gap between citation rate and brand mention rate was one of the findings that stood out to me the most.

7. The Gap Between the Top 5 and Lower Rankings

When I grouped the rankings into buckets, another interesting pattern emerged.

The brand mention rates were:

Positions 1–5: around 13%
Positions 6–10: around 6%
Positions 11–15: around 3%

The citation rates were:

Positions 1–5: around 38%
Positions 6–10: around 11%
Positions 11–15: around 3%

What stood out to me most was the gap between the Top 5 and lower-ranking positions.

The difference was especially noticeable for citations. The citation rate was around 38% for positions 1–5, but dropped to roughly 11% for positions 6–10.

Of course, based on this dataset alone, I can’t say that ranking in the Top 5 will cause a brand to appear in AI Overviews.

Still, the results suggest that, when AI Overview visibility is taken into account, reaching the Top 5 may be significantly more valuable than simply thinking, “As long as we’re in the Top 10, that’s good enough for SEO.”

One of the questions that originally motivated this research was: Should our SEO KPI be Top 3, Top 5, or Top 10?

So for me, this was one of the most useful findings from the study.

8. AI Overviews Seem to Rely Heavily on Pages That Rank Highly in Google Search

Looking at the citation rates, I found a fairly strong relationship between Google organic rankings and AI Overview citations, at least within the dataset I analyzed.

AI search and SEO are sometimes discussed as if they are completely separate disciplines. But when it comes to Google AI Overviews, I’m starting to think we may not need to treat them as entirely separate.

AI Overviews draw on information from across the web when generating answers.

In that sense, it seems reasonable that pages already performing well in Google Search may also be more likely to be used as sources in AI-generated answers.

There is an important caveat, though: what I observed here is correlation, not causation.

This study does not prove that improving a page’s organic ranking will directly increase its likelihood of being cited in an AI Overview.

It is also possible that both organic rankings and AI Overview citations are influenced by some of the same underlying factors, such as:

Providing comprehensive and useful information
Being highly relevant to the topic
Being well established and recognized across the web

So the takeaway is not:

“Improve your rankings, and your citation rate will automatically increase.”

Rather, the results suggest that organic search visibility and AI Overview citations are closely related and may, at least in part, be influenced by the same underlying signals.

9. So If You Rank #1 in SEO, Is Your GEO Work Done?

This is where it becomes important to separate citations from brand mentions.

When companies invest in GEO, I think what they ultimately want to increase is not just citations, but brand mentions.

For example, imagine a user asks an AI:

“What are some recommended T-shirt brands?”

From a company’s perspective, what matters more is probably not whether the AI says, “I used this page as a source,” but whether the brand itself is recommended in the answer.

And in this study, even brands ranking #1 in Google Search had a brand mention rate of only around 20%.

So ranking highly in organic search alone does not appear to be enough.

What else might matter?

From this point on, I’m going beyond what this dataset can prove, so the following is my own hypothesis.

When AI systems answer questions about brands, they are likely drawing on information from across the web, not just from a brand’s own website.

If that is the case, the important question may not simply be:

“Does our own website rank highly?”

but also:

“Is our brand being recommended across many different places on the web?”

For an e-commerce brand, that could include:

Comparison and review sites
Media articles
YouTube
Social media
Influencers
Affiliate websites
Marketplaces such as Amazon and Rakuten
User reviews

For example, if a brand is consistently recommended on comparison or review sites that also rank well in Google Search, such as Kakaku.com or mybest, that could potentially help AI systems recognize and recommend the brand as well.

My current hypothesis is that the brands that perform well in AI search will not simply be the ones with strong SEO.

Instead, they may be the brands with strong visibility across the web as a whole: ranking well in search, being discussed on social media, appearing in YouTube videos, being featured on comparison sites, and accumulating a large number of reviews.

In other words, broader digital visibility may ultimately put brands in a stronger position in AI search.

This is one of the areas I’d like to investigate next.

10. Final Thoughts on This Research

For this research, I combined a range of tools, including Semrush, Python, LangChain, LLM APIs, and SearchApi.

I also used Google Antigravity and Codex to support the coding process.

For tasks such as classifying large numbers of keywords, where I didn’t necessarily need the most powerful models, I used lightweight LLM APIs to keep processing costs down.

One thing this project really made me realize is that it has become possible for an individual to conduct research at a surprisingly large scale.

A few years ago, doing all of the following would probably have required a huge amount of time and effort:

Collecting 100,000 keywords
Classifying 50,000 of them
Retrieving 1,000 Google search results
Analyzing AI Overview responses
Normalizing brand names
Aggregating and analyzing the results

Today, by combining Python, APIs, and AI coding tools, one person can handle a surprisingly large portion of that workflow.

There is still a lot we don’t know about GEO and AI search.

So rather than only reading other people’s research, I’d like to keep taking the following approach:

“If something makes me curious, collect the data and test it myself.”

That’s the mindset I want to keep as this field continues to evolve.

11. Summary: Google Rankings Still Seem to Matter a Lot in the AI Overview Era

If I had to summarize the three most important takeaways from this research, they would be:

1. Google rankings and AI Overview visibility appear to be closely related

The relationship was particularly clear for citations: the higher a page ranked in Google Search, the more likely it was to be cited in an AI Overview.

2. The Top 5 seems especially important

There was a clear gap in both brand mention rates and citation rates between positions 1–5 and positions 6–10.

So when setting SEO KPIs with AI search in mind, aiming for the Top 5 may be more meaningful than simply reaching the first page of Google.

3. But even at #1, the brand mention rate was only around 20%

This suggests that GEO probably cannot be solved through SEO alone.

If you want AI systems to actually recommend your brand, it may be necessary to build a presence beyond your own website and create an environment where your brand is recognized, discussed, and recommended across different parts of the web.

Going forward, I’d like to conduct similar research not only on AI Overviews, but also on Google AI Mode, ChatGPT, Gemini, and other AI search platforms.

I’m also interested in exploring how visibility on YouTube, social media, review sites, and other platforms relates to brand mentions in AI-generated answers.

If you’re interested in the full methodology, charts, and data behind this study, I’ve published a more detailed version of the research on my website, heysho.com:

https://heysho.com/en/geo/research-aio-organic-ranking.html

About the Author(Heysho)

I currently work in SEO and GEO / AI search.

I’ve been using Python for around three to four years, and I also spent about five years working as a frontend engineer. I enjoy using programming for marketing analysis, research, and automation.

There is still a lot to learn about GEO and AI search, so I plan to keep exploring the field by collecting real data and testing things for myself.

If I come across any interesting findings, I’ll share them again.

Building AI Rap Generation Tool with Gemini API / LangChain / Cloud Run

Heysho — Thu, 27 Aug 2026 08:34:43 +0000

I recently developed Rap Dojo, a web service that uses AI to generate rap lyrics. In this article, I’ll share how the project came about, how I built it, and what I learned from launching and running it.

https://rapdojo.com/

1. Why I Built Rap Dojo

My original motivation was simple: I wanted to build a working product using an LLM API.

Around that time, Google and Zenn were hosting a Gemini-related hackathon, and I thought, “If I’m going to build something, why not make something interesting with Gemini?”

That idea led me to start developing Rap Dojo.

The concept was an AI rap generator that would make it easy for anyone to create a rap.

Of course, you can already ask a conversational AI such as ChatGPT or Gemini to “write me a rap,” and it will generate one for you.

But when you actually use a chat interface, that freedom can sometimes be overwhelming. People may wonder:

“What should I type?”
“How should I prompt it to create an interesting rap?”

With Rap Dojo, I wanted to create an experience simple enough that users could generate a rap by entering just a few words, without having to think about complicated prompts.

For example, you might enter your name, something you like, or something that happened recently, and the AI will turn those ideas into a rap.

I thought that if the experience were simple enough, even people who rarely use generative AI might feel comfortable playing around with it. It could make AI-generated content feel a little more accessible and integrated into everyday life.

That became the starting point for Rap Dojo.

2. System Architecture

I intentionally kept Rap Dojo’s architecture as simple as possible.

At a high level, it consists of:

Frontend: HTML / CSS / JavaScript
Backend: Python / LangChain
LLM: Gemini API
Infrastructure: Google Cloud Run

The frontend calls the backend API through JavaScript. The backend then uses Gemini to generate a rap based on the user’s input and returns the result to the frontend.

The Frontend Uses HTML / CSS / JavaScript

For the frontend, I decided not to use a framework such as React or a CMS. It is built primarily with HTML and CSS, with some JavaScript.

One reason I chose this approach is the rapid progress of AI coding tools.

Today, tools such as Claude Code and Antigravity make it possible to build and modify websites efficiently using natural-language instructions.

For a relatively small web service like this, I therefore felt that introducing a CMS or a large JavaScript framework was unnecessary.

I’m also comfortable working directly with HTML and CSS, so editing the code myself does not create much overhead.

Keeping the architecture simple provides several benefits:

It is easier to understand how everything works.
It is easier to modify with AI coding tools.
There are fewer dependencies.
Maintenance is simpler.

For small websites and indie projects, I’ve come to believe that avoiding unnecessary technical complexity can be just as important as choosing the right technology.

The Backend Runs on Google Cloud Run

I use Google Cloud Run for the backend.

Rap Dojo does not receive a large volume of traffic continuously, so I did not want to run a server 24/7.

Instead, I chose Cloud Run because its serverless model allows the backend to run only when needed.

Conceptually, the flow looks like this:

User input
↓
Frontend (JavaScript)
↓
Cloud Run API
↓
Python / LangChain
↓
Gemini API
↓
Rap generation
↓
Result returned to frontend

Once the user input is received, the backend performs the generation process and returns the output to the frontend through the API.

Almost No Infrastructure Cost for an Indie Project

One of the biggest benefits of this architecture is its low operating cost.

Gemini API usage naturally incurs costs depending on usage, but at Rap Dojo’s current traffic level, the Google Cloud infrastructure costs are extremely low.

The exact amount varies by month, but infrastructure costs generally stay below a few hundred yen per month.

In the past, launching a web service with a backend meant thinking about servers, hosting, maintenance, and other infrastructure concerns.

Today, by combining a serverless environment such as Cloud Run with a generative AI API, even an individual developer can launch a web application that accepts user input and processes it dynamically at very low cost.

Building Rap Dojo reminded me just how much the barrier to launching this kind of product has fallen.

3. Why I Chose Gemini

I use Gemini as the LLM behind Rap Dojo.

The biggest reason is its strong balance between cost and quality.

In particular, Gemini’s Flash models offer relatively low API costs while still providing more than enough quality for text-generation use cases like this one.

Every time a user generates a rap, the application makes an LLM API call. As usage grows, those costs accumulate.

That means indie developers need to think not only about model performance, but also about the cost of each generation.

From that perspective, I’ve found the Gemini Flash family very practical for personal projects.

Another reason I often use Gemini is that Google Cloud credits are relatively accessible through developer programs and events.

Google regularly organizes developer events and hackathons, and participation sometimes comes with Google Cloud credits.

Although these credits typically expire, some events provide credits worth around ¥10,000–¥20,000, which can be very useful for indie development.

Making good use of those credits is another reason the Gemini API has become my main choice for personal projects involving LLMs.

Rap Dojo currently uses different models depending on the task:

Gemini 3.7 Flash
Gemini 3.5 Flash-Lite

Rather than using the most powerful model for every task, I use lighter models where appropriate. This helps keep costs down while maintaining the generation quality I need.

For indie development, I’ve learned that model selection should not simply be about choosing the “best-performing” model. It is equally important to consider how cheaply you can operate while still meeting the required quality level.

4. Why I Use LangChain

In Rap Dojo, the rap-generation process is implemented as a two-stage pipeline.

At a high level, it works like this:

User input
↓
1. Generate the rap
↓
2. Format the output
↓
Display to user

The main reason I use LangChain is that I wanted a convenient way to connect multiple LLM operations sequentially.

Stage 1: Generate the Rap as Freely as Possible

The first step is to generate the rap itself.

At this stage, rather than controlling the output format too strictly, I give the LLM more freedom and prioritize creativity and entertainment value.

With rap lyrics, overly strict formatting requirements can make the output more consistent, but they can also make the writing feel repetitive or less expressive.

So in the first stage, I prioritize the quality of the content itself.

Stage 2: Format the Output for Display

The generated rap is then passed to a second process that adjusts it into a format that works well on the website.

For example, this stage can:

Remove unnecessary symbols.
Shorten the output if it is too long.
Standardize formatting and notation.

This step does not require particularly advanced creative ability, so I can use a lighter and cheaper model such as Gemini 3.5 Flash-Lite.

In other words:

Rap generation: prioritize quality and creativity.
Formatting: prioritize cost and processing efficiency.

Each model has a different role.

Separating Generation from Formatting

Initially, I considered handling everything within a single prompt:

“Write a rap and output it in this exact format.”

But after experimenting with the application, I found that separating content generation from output formatting made the system easier to manage.

Instead of asking a single model to do everything, I split the process into:

Generate
↓
Review / format

This also allows me to choose a model that is appropriate for each task.

Even though Rap Dojo has a relatively simple architecture, I still needed a convenient way to manage multiple LLM operations as a pipeline. That is the main reason I decided to use LangChain.

5. Deploying to Google Cloud

I use Google Cloud Run to deploy the backend.

There are several ways to deploy a Python-based web application, so during the early stages of development I considered a number of options, including:

Streamlit Cloud
Hugging Face
Building a Python environment on a traditional hosting server
Creating a Python runtime environment on Google Cloud

For this particular use case, however, I found Cloud Run to be the easiest option while also keeping costs low.

Easy to Combine with a Custom-Domain Website

With Rap Dojo, I did not want to publish only an AI demo. I wanted to integrate the rap-generation feature into a proper website running on the custom domain rapdojo.com.

Services such as Streamlit Cloud and Hugging Face are extremely useful for publishing AI application prototypes.

For the architecture I had in mind, however, it was easier to have an existing custom-domain website call a Python backend through an API.

With Cloud Run, the architecture can be cleanly separated like this:

rapdojo.com
HTML / CSS / JavaScript
        ↓
   Cloud Run API
        ↓
      Python
        ↓
   Gemini API

The website itself remains a conventional HTML website, while Cloud Run handles only the parts that require AI processing.

Run Python Only When Needed

Another reason Cloud Run works particularly well for Rap Dojo is that a small indie service like this does not need a backend running continuously.

Python only needs to execute when someone generates a rap.

For that reason, a serverless service such as Cloud Run was a better fit than maintaining an always-on server.

At relatively low traffic levels, infrastructure costs can remain very low as well.

I think Cloud Run is a practical option when you want to add Python or generative AI functionality to specific parts of an otherwise conventional website.

I used to associate AI apps with specialized application environments, but in practice, combining a standard HTML-based website with Cloud Run was enough to launch a fully functional service.

6. Challenges Unique to AI Web Applications

One thing I noticed after operating Rap Dojo in production is the instability that comes with relying on an external LLM API.

With a conventional website, as long as your own servers and code are functioning correctly, you can generally continue providing the service.

A generative AI application introduces another dependency:

Rap Dojo
↓
LLM API
↓
External AI service

As a result, even when there is nothing wrong with your own code, the application may temporarily become unavailable because of issues on the LLM provider’s side.

API Changes Can Suddenly Break Your Application

During the early development of Rap Dojo, I used a GPT API.

At one point, an API specification change caused a process that had previously been working to suddenly stop.

I had not changed my own code, but a change to the external API still affected the service.

That experience made me much more aware of this risk.

Errors Caused by Model-Side Load

I had similar experiences after switching to Gemini.

With one of the Gemini Flash models I was using at the time, high load on the model side occasionally resulted in API errors, temporarily preventing users from generating rap lyrics.

The service is more stable now, but once you operate a real product, you quickly realize that you cannot assume an LLM API will succeed 100% of the time.

Design LLM Applications with Failure in Mind

The main lesson from this experience is that when building a generative AI service, implementing only the success path is not enough.

You also need to consider scenarios such as:

The API temporarily does not respond.
Responses take too long.
The model returns an error.
The API or model specifications change.
The model you depend on is changed or discontinued.

For a production service, it is important to think about what happens when the LLM fails, including error messages, retries, and potentially falling back to another model.

In traditional web development, I mainly thought about my own code and infrastructure.

AI web applications add another dependency: the external LLM service.

Operating Rap Dojo taught me that designing around this dependency is an important part of building AI products.

7. What I Learned After Launching It

After launching Rap Dojo, I learned several things beyond the technical side of development.

One of the most interesting lessons was that even a small web service on a brand-new domain can attract meaningful traffic if it combines a niche user need with effective SEO.

For Rap Dojo, I registered the domain rapdojo.com and built the site with SEO in mind from the beginning.

SEO is also part of my professional background, so I researched search demand and optimized the site and its content accordingly.

As a result, the site began ranking for relevant Japanese keywords such as “ラップ AI” (“rap AI”) and “ラップ作って” (“make me a rap”).

Today, around 3,000 people visit the site each month.

Of course, this is not a large-scale service. But considering that I am not running any advertising and started from a completely new domain, I think it is an encouraging result for an indie web application.

This experience made me think that the following combination can work particularly well for indie projects:

Niche search demand
+
A genuinely useful tool
+
SEO

Traffic Does Not Necessarily Mean Monetization

There was, however, another important lesson.

Getting users to visit a product and turning that product into a viable source of revenue are two completely different challenges.

Rap Dojo is mainly something people use casually for fun, and I do not think it is the kind of service most users would pay for.

For that reason, it remains essentially free to use.

However, even a free service has operating costs.

Gemini API, Google Cloud, and other services all cost a small amount of money each month.

That creates a simple situation:

“There is no revenue, but the product still costs a little money every month.”

At the same time, the site has gained search rankings and people are actively using it, so shutting it down feels like a waste.

As a result, Rap Dojo has become a product that I continue to maintain while paying a small amount each month to keep it running.

Next Time, I’ll Think About What Happens After Launch

For one project like Rap Dojo, this is not a major issue.

But if I were to create five or ten similar personal projects, each one would come with API fees, cloud costs, domain fees, and ongoing maintenance work.

That has made me realize that for my next web product, I should think not only about building and launching it, but also about how I plan to maintain it afterward.

For example:

How will it be monetized?
How long will I test the idea?
What metrics would justify continuing the product?
If those goals are not achieved, should I shut it down?

Defining criteria like these in advance may be useful.

With indie development, building and launching something is fun in itself, so it is easy to keep creating new products without thinking too much about what happens afterward.

However, if you want to manage several products over the long term, deciding what to keep and what to shut down may be just as important as deciding what to build.

I Plan to Keep Rap Dojo Running

That said, I currently have no plans to shut down Rap Dojo.

I do not plan to make major feature additions or actively develop it on an ongoing basis, but I still use it from time to time to create rap lyrics for fun.

Rather than trying to turn Rap Dojo into a large business, I plan to maintain it as a small AI product that I built and still use myself.

From a monetization perspective, it has not been a successful product.

But in terms of what I learned, the project has been extremely valuable:

I successfully launched a real service powered by an LLM API.
I acquired users through SEO starting from a brand-new domain.
The product continues to attract regular users.
I learned about the operational challenges and costs that come after launch.

Overall, it has been a very rewarding project.

8. Conclusion

I’d like to finish with a short introduction about myself.

As a hobby, I build AI-powered products and indie projects like Rap Dojo.

Professionally, I primarily work in SEO, and more recently I have also been conducting research and analysis related to GEO and AI Search.

My main areas of interest include:

SEO
GEO / AI Search
Generative AI
Data analysis and research
AI-powered product development

When it comes to indie development, I enjoy more than simply writing code.

I like coming up with an idea, turning it into a real product, launching it, attracting users through SEO, and then operating and improving it over time.

If you read this article and thought:

“I’m working on something similar.”
“I’d be interested in researching GEO or AI Search together.”
“There might be an opportunity to collaborate on an AI-powered product.”

I’d be very happy to connect.

You can find more information about the projects and research I’m working on here:

Heysho

https://heysho.com/