{"slug": "reflections-on-the-gemini-ai-hackathon-google-japan-in-tokyo", "title": "Reflections on the “Gemini AI Hackathon @ Google Japan in Tokyo”", "summary": "A developer reflects on lessons from the Gemini AI Hackathon @ Google Japan in Tokyo, where over 300 participants gathered to build AI projects with Google Cloud and Gemini. The developer notes that many attendees worked individually, aided by AI coding tools, and shares plans to improve time management and start with minimal viable versions in future hackathons.", "body_md": "Starting this month, I’ll be participating in the 5th Agentic AI Hackathon with Google Cloud.\n\nThe program kicks off with “Build with Gemini Tokyo” on September 3 and 4, where participants will build AI projects using Google Cloud and Gemini.\n\nSince I’m taking part, I want to approach the development process more effectively this time than I did at my previous hackathon.\n\nBefore 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.\n\nThe 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.\n\nI attempted to build an app using health data from my Apple Watch, but I wasn’t able to complete it before the event ended.\n\nThe immediate cause was that six months of health data exceeded 1 GB, making it difficult to import into the app successfully.\n\nLooking back, however, the real problem wasn’t simply that I had “1 GB of data.”\n\nDespite 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.\n\nI 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.\n\nTo 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.\n\nWhen 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.\n\nI do not know the exact number of attendees, but my impression was that there were more than 300 people at the venue.\n\nWhat 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.\n\nI had expected the event to be mostly local, so the diversity of the participants was one of the first things that caught my attention.\n\n*This is only my personal impression from being at the venue and is not based on confirmed information about participants’ nationalities or backgrounds.*\n\nBefore 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.\n\nI 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.\n\nDuring 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.\n\nWith 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.\n\nLooking 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.”\n\nAs 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.\n\nThat 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.\n\nIf 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.\n\nOnce I started working, the time seemed to disappear almost immediately.\n\nParticipants 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.\n\nAt 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.\n\nAt 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.\n\nHowever, 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.\n\nIn 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.\n\nIn the end, I ran out of time before I could complete the product.\n\nLooking 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.\n\nThe 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.\n\nWith 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.\n\nAt 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.\n\nWhile 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.\n\nWatching 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.\n\nAt 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.\n\nThere 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.\n\nI 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.\n\nWhat stayed with me most was this: as implementation becomes faster, the differences in everything surrounding the implementation become more visible.\n\nHow 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?\n\nI 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.\n\nThe 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.\n\nAt this hackathon, I was not able to finish and submit a completed product.\n\nLooking 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.\n\nAt 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.\n\nBut 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.\n\nNext 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.\n\nBecause I failed to finish this time, I now have a much clearer idea of what I need to change.\n\nAt 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.", "url": "https://wpnews.pro/news/reflections-on-the-gemini-ai-hackathon-google-japan-in-tokyo", "canonical_source": "https://dev.to/heysho/reflections-on-the-gemini-ai-hackathon-google-japan-hackathon-tokyo-16g", "published_at": "2026-09-02 08:54:37+00:00", "updated_at": "2026-09-02 09:23:16.593411+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-tools"], "entities": ["Google Cloud", "Gemini", "Google Japan", "AI Builders", "Apple Watch"], "alternates": {"html": "https://wpnews.pro/news/reflections-on-the-gemini-ai-hackathon-google-japan-in-tokyo", "markdown": "https://wpnews.pro/news/reflections-on-the-gemini-ai-hackathon-google-japan-in-tokyo.md", "text": "https://wpnews.pro/news/reflections-on-the-gemini-ai-hackathon-google-japan-in-tokyo.txt", "jsonld": "https://wpnews.pro/news/reflections-on-the-gemini-ai-hackathon-google-japan-in-tokyo.jsonld"}}