Forem: Zoe Lin

Google I/O 2026 — What I Hoped to See Beyond the Model Announcements

Zoe Lin — Thu, 21 May 2026 10:17:49 +0000

Why I was looking for more than model updates

When I watched Google I/O 2026, I was not only paying attention to the new model announcements. What I cared about more was whether Google was making its AI ecosystem feel easier to build with in a practical way.

That probably comes from my own experience using Google AI Studio, Gemini models, and local Gemma workflows in small projects. After spending time with those tools, it becomes harder to look at a keynote as a list of separate upgrades. What stands out more is whether the path from idea to usable product is becoming clearer.

That was the part I hoped to see this year.

What stayed with me from this year’s I/O

The main thing I noticed was that Google seemed to be telling a more connected story.

AI Studio no longer felt like it was only about testing prompts. Antigravity did not feel like a side experiment. The announcements around models, agents, app building, and deployment all seemed to move in the same direction.

That mattered to me because the difficult part of building with AI is rarely just getting one good output. More often, the real friction comes later: choosing the right tool, turning the result into something usable, connecting it to the rest of the app, and dealing with everything that happens after the prototype stage.

That is why the workflow stayed with me more than the model list itself.

Why lightweight models still matter to me

One reason I see it this way is because of my own experience with Gemma.

What I appreciated about local Gemma workflows was not that they tried to do everything, but that they felt light enough to experiment with and practical enough for focused tasks. For developers who are still learning how to bring AI into real projects, that kind of accessibility matters a lot.

A model does not always need to be the most advanced option to be useful. Sometimes what matters more is whether it is affordable, lightweight, and easy enough to try without turning the whole project into a heavy setup problem.

That is why lightweight models still matter to me, even in a keynote full of bigger announcements.

What I was hoping to feel more clearly from Gemini

With Gemini, my expectation was a little different.

I have already found Gemini useful for prototyping and for turning ideas into something testable more quickly. What I hoped to feel more clearly this year was not only stronger capability, but clearer model roles.

Once you start building actual features, it matters whether a model feels better suited for fast iteration, structured reasoning, creative generation, or more agent-style tasks. When those differences feel clearer, the ecosystem also starts to feel more mature.

That is one of the things I still look for beyond the announcements themselves: not only more capability, but more clarity.

Where I still notice the gap between speed and polish

I felt something similar when using Google AI Studio for visual generation.

What I liked was the speed. It was genuinely helpful for turning an idea into something visible, especially in the early stage of a project. At the same time, the results often felt closer to a strong draft than to something fully refined. They were useful for ideation, but not always polished enough to stand on their own.

That did not make the experience less useful. It just made me care more about refinement.

If Google is moving toward a workflow where ideas can move more quickly from prompt to product, then polish starts to matter alongside speed.

Why Antigravity stood out to me

This is also why Antigravity felt important in this year’s I/O story.

What interested me was not simply that agent-based tooling can do more, but that Google seems to be pushing it toward a more realistic place in the development workflow. Earlier tools already showed convenience, but they also left behind a familiar amount of cleanup: fixing structure, checking code quality, and adjusting the details that still needed human judgment.

Because of that, I found myself looking at Antigravity less as a flashy feature and more as a sign of where Google wants the developer experience to go.

The version of agent-based development that feels meaningful to me is not “AI does everything.” It is the idea that better tooling reduces low-value friction and leaves developers with more time for architecture, design decisions, and quality.

Why the story felt broader this year

One thing I liked about this year’s I/O was that this shift did not stay only inside developer tools.

Gemini Spark made the agent story feel more complete to me, because it suggested a more persistent kind of assistant experience. It felt less like asking for a single reply and more like giving a system a goal and letting it continue the work.

The same thing appeared in the search and commerce direction. Once agents start moving into search, shopping, and more action-oriented tasks, the conversation changes. At that point, it is not only about capability anymore. It becomes about trust, clarity, and whether the workflow feels understandable enough for people to actually rely on it.

Even Flutter made the picture feel a little broader to me, because it suggested that this shift is not staying limited to AI-native tools. It is starting to touch more mainstream development workflows too.

What I was really hoping to see

When I step back from all of this, I think what I was really hoping to see at Google I/O 2026 was a clearer sign that Google’s ecosystem is becoming easier to build with in practice.

For me, that means things like:

clearer model roles
smoother movement from prototype to product
less cleanup after generation
more usable agent workflows
and tools that feel more helpful for developers at different stages

Those are not always the flashiest parts of a keynote, but they are often the parts that decide whether people keep building after the excitement fades.

Final takeaway

What I took away from Google I/O 2026 was not that the model announcements were unimportant. They were clearly a big part of the event.

What stayed with me more, though, was the sense that Google is trying to make the space around those models feel more complete. After already using tools like Google AI Studio, Gemini, and Gemma in small projects, that was the part I found easiest to connect with.

This year’s announcements made me think less about how many new model options there are, and more about whether the overall workflow is becoming easier to build on.

That was what I hoped to see beyond the model announcements, and it was the part of Google I/O 2026 that felt most meaningful to me.

Solana Account Data — How I Started Making Sense of Owners, Programs, and Raw Bytes

Zoe Lin — Fri, 15 May 2026 21:05:25 +0000

Where the confusion started

What made Solana feel unfamiliar at first was that it really means it when people say “everything is an account.” Wallets, programs, token accounts, and other kinds of on-chain state all use the same general account model. What changes is not the existence of a completely different object type, but how each account’s fields are set and which program owns it.

I understood that idea early on, but I still did not feel like I could actually read what I was looking at.

A wallet page in Explorer looked manageable, and a transaction page was still readable enough. But once I started using the CLI and looking at RPC responses, fields like owner, executable, and data still felt disconnected. The raw account data itself was even harder to read. It was just bytes, base64, or a hex dump that did not seem to mean anything on its own.

What finally helped me was realizing that Solana account data is not supposed to feel readable by default. It is not a JSON object waiting to be expanded. It is just a byte array, and it only becomes meaningful once you know which program owns the account and how that program defines its layout.

Starting with the simplest comparison

The first useful comparison for me was between a normal wallet account and a program account.

When I inspected my own devnet wallet and compared it with the Token Program using solana account <address>, the pattern changed immediately. It looked something like this:

Account Type	Owner	Executable	Data Length	Purpose
My Devnet Wallet	System Program	No	0 bytes	Holds SOL
Token Program	Loader-related program	Yes	> 0 bytes	Contains executable code

Seeing this contrast made one important idea click for me: on Solana, a program is also just an account, but one that contains executable code.

That also helped me understand another important part of Solana’s model: programs do not usually store their own state inside the program account itself. The executable account holds code, while the state the program works with lives in separate data accounts.

Even before decoding anything, just comparing the owner, executable flag, and data length already made the account model much easier to reason about.

The questions that helped me read accounts more clearly

After that, the way I read accounts changed. Instead of asking why the output looked so cryptic, I started asking a different set of questions:

Who owns this account?
Is it executable?
How much data does it store?
Which program defines what those bytes mean?

Those questions turned out to be much more useful than staring at the raw output and hoping it would start making sense on its own. They also made the broader account model easier to understand, because the same fields kept showing up whether I was looking at a wallet, a program, or a data account.

The Web2 analogy that helped a little

The closest mental model for me was this: a Solana account is less like a nicely structured database row and more like a binary record whose schema lives somewhere else.

The account stores the bytes, but the owning program tells you how to interpret them. That helped me stop expecting account data to explain itself and made the relationship between accounts and programs feel much more natural.

It also made Solana’s model feel less strange from a Web2 point of view. Programs are like executables, while the accounts they work with are more like the files or records those executables read and write.

Rent exemption is part of the storage model too

Another idea that helped me see Solana accounts more clearly was rent exemption. On Solana, keeping data on-chain is not treated as free. Accounts need to hold a minimum lamport balance based on their data size in order to remain rent-exempt.

That detail made the model feel less like abstract blockchain magic and more like a storage system with explicit rules and costs. It also helped explain why account size matters and why storage on-chain is treated as something developers need to plan for.

What I would suggest to another learner

If account data still feels abstract, I would not start with custom programs right away. I would recommend comparing three things side by side:

your own wallet account
a well-known program account
an account with structured data, like a token mint, that you can actually decode

That progression moves from an account with no custom data, to an account that contains code, and finally to an account whose bytes clearly represent state. Once I saw those three cases clearly, Solana’s account model felt much less intimidating.

Final takeaway

For me, the turning point was realizing that the data was not random. I was just missing the schema.

Once I started reading Solana accounts through the lens of owner, executable, and how the owning program defines the data layout, everything began to feel much more structured. That did not make every account immediately easy to understand, but it gave me a much better way to approach what I was seeing.

If you are at the stage where those fields still feel disconnected, try inspecting a few accounts side by side and decoding one real account manually. For me, that was the point where Solana’s account model stopped feeling opaque and started to make sense.

Transactions on Solana — What Sending and Breaking Them Taught Me

Zoe Lin — Sat, 09 May 2026 20:07:12 +0000

Before this week, Solana transactions felt familiar enough to recognize, but not familiar enough to really understand.

I could open a transaction in Solana Explorer and identify the parts. I knew there was a signature, an instruction, a fee, and the accounts involved. But that was mostly recognition, not understanding. What changed that for me was actually working through the full flow myself: sending a transfer, tracking confirmation, and then forcing a transaction to fail on purpose.

The API analogy that helped at first

At first, the easiest way for me to think about a Solana transaction was to compare it to an API request. That analogy helped because it gave me a place to start. A transaction has structure, it includes instructions, and it carries signatures that authorize the action. Looking at it that way made the data feel less mysterious.

But after I started sending transactions myself, that comparison felt less complete.

What changed once I actually sent one

The first shift came when I sent SOL and then looked at the result in Solana Explorer. On the surface, it was just a small transfer from one address to another. But the actual transaction had much more structure than that: a recent blockhash, a fee payer, account inputs, and a specific System Program instruction. That was the first time a transaction stopped feeling like a wallet action and started feeling more like a real on-chain operation.

What confirmation made clearer

The next shift came when I added confirmation progress to my transfer tool. Instead of sending a transaction and waiting for a result, I could watch it move through processed, confirmed, and finalized. That made the lifecycle much easier to understand. It also made Solana feel less like a simple request-and-response system and more like a network where state changes settle in stages.

What failed transactions taught me

I deliberately forced a transfer to fail and then checked the result in Solana Explorer. That ended up teaching me more than I expected. The failed transaction still had a signature, still showed the instruction that failed, still produced logs, and still charged a fee. In my case, the logs clearly showed an insufficient lamports error, which made the failure much easier to reason about.

That was the point where my mental model changed the most. A Solana transaction no longer felt like just a request I was sending somewhere. It felt more like a signed, short-lived, atomic attempt to change on-chain state.

What I am keeping from this week

That shift made several smaller details line up for me. The signature was not just an ID. The instruction was not just metadata. Confirmation was not just one final moment. And failure did not mean nothing happened.

By the end of this week, transactions on Solana started to feel much less abstract and much more understandable.

Gemma 4 Error Log Simplifier — AI-Powered Debugging Insights from Raw Logs

Zoe Lin — Sat, 09 May 2026 18:19:30 +0000

What I Built

I built a lightweight tool called Gemma 4 Error Log Simplifier, designed to turn raw and often confusing error logs into structured, easy-to-understand debugging insights.

Error messages from different environments—such as Python, JavaScript, Java, SQL, or DevOps tools—are usually verbose and inconsistent in format. Instead of manually scanning through stack traces, users can paste an error log into the tool and quickly get a clearer explanation of what is happening and how to approach fixing it.

The output is organized into a consistent structure that includes:

a concise summary of the error
possible root causes
practical debugging steps
suggested fixes

The goal is to reduce the cognitive load during debugging and make it easier to switch between different tech stacks without losing time interpreting error messages.

This project is implemented as a simple local web application using FastAPI and Jinja2, with Gemma 4 integrated via the Gemini API as the core reasoning engine.

Demo

Code

GitHub Repo

How I Used Gemma 4

The application uses gemma-4-26b-a4b-it through the Gemini API to process and interpret error logs.

Error logs are semi-structured but often noisy, with useful signals mixed together with irrelevant details. This makes them difficult to parse programmatically with traditional approaches. Gemma 4 is well-suited for this task because it can understand patterns across different programming languages and extract meaningful context from unstructured input.

To make the output predictable and easy to render in the UI, I designed the prompt to enforce a consistent response format. Each response follows the same structure: summary, causes, debugging steps, and suggested fixes. This ensures both readability and usability in real debugging scenarios.

On the backend side, I added a simple retry mechanism to handle occasional API instability and improve reliability during repeated requests.

Final Thoughts

This project focuses on a practical use case where large language models can directly support everyday developer workflows. Instead of generating content, the model is used to translate raw technical data into actionable insights, which can significantly reduce the time spent understanding and resolving errors.

Reading Solana Data — What Started to Feel Real in My Second Week

Zoe Lin — Sat, 02 May 2026 10:28:35 +0000

Before this week, I still thought of blockchain data as something more abstract than it probably needed to be.

I expected it to feel very different from the kinds of APIs and database reads I was already used to in Web2. But during the second week of 100 Days of Solana, that started to change. What made the difference was actually querying the data myself.

What started to feel familiar

The first shift came when I read a wallet balance directly from devnet. That did not feel as unfamiliar as I expected. It felt more like making a read call and getting back public state.

Fetching recent transactions made that idea clearer. Once I could see signatures, slots, timestamps, and statuses directly in the terminal, Solana started to feel less like a black box and more like a system I could inspect.

What surprised me most

What surprised me most was how consistent the pattern felt across different tasks. I used RPC calls to read balances, fetch transaction history, compare the same address across devnet and mainnet, and then render that data in a browser dashboard.

The tools changed, but the core flow stayed very similar: connect to an RPC endpoint, query public data, and display the result in a useful way.

That was the point where the “public database” framing started to feel real to me.

What changed in my mental model

The accounts-vs-databases comparison also helped a lot. My Web2 instincts still apply in some ways, but Solana accounts are not rows in private tables. They are public state objects on a shared ledger, with different rules around storage, ownership, and access.

If the first week helped me understand wallets and keypairs, the second week helped me understand that blockchain data is something I can query directly.

For me, that was the point where Solana started to feel less abstract and more like a real development environment.

Wallet Experiments — What Clicked for Me in My First Week of Solana

Zoe Lin — Mon, 27 Apr 2026 17:39:04 +0000

One of my biggest highlights from Week 1 of 100 Days of Solana was realizing how the same keypair model appeared across very different wallet experiences.

I generated a keypair, connected Phantom in a browser app, compared CLI, browser, and mobile wallets, and explored how they behaved on devnet. The screenshot below shows one of the moments that stood out most to me: connecting a browser wallet and seeing the address and balance appear inside the app.

What surprised me most was how much the UX could change while the core identity model stayed the same. That was the point where wallets stopped feeling like “accounts” and started making more sense as tools for managing keys.

Next, I’m looking forward to learning how to read more on-chain data and understand what is happening underneath the wallet interface.

Identity on Solana — Think SSH Keys, Not Usernames

Zoe Lin — Mon, 27 Apr 2026 11:48:49 +0000

If you come from Web2, identity usually means something managed by a platform. It might be a username on GitHub, an email address tied to your company account, or a password stored in a product database. In all of those cases, identity exists because a service stores it, recognizes it, and decides how authentication works.

This post is my attempt to explain how that changes on Solana in a way a Web2 developer would understand.

Why this felt unfamiliar at first

That is why Solana identity felt unfamiliar to me at first. I kept trying to understand wallets as if they were just another version of app accounts. That mental model was useful for getting started, but it was also misleading. After working through the first five days of 100 Days of Solana, the idea started to make much more sense.

The biggest shift was realizing that a wallet is not really the identity itself. It is the interface for managing the identity. The underlying identity is the keypair.

The SSH analogy that made it click

A Solana keypair feels a lot like an SSH keypair. You have a public key that can be shared, and a private key that stays with you. You prove control by signing with the private key. The basic mechanism is very similar. The difference is that SSH usually proves access to one server, while a Solana keypair works across a whole network.

That distinction matters because it changes what identity actually means. In Web2, identity is usually granted by a platform. A company stores your account, your profile, and your login credentials. If needed, it can lock you out, reset your password, or suspend the account. On Solana, identity is not granted by a company. It is proven cryptographically. If you control the private key, you control the account.

This also makes a public key very different from a username. A username is selected by a user, stored in a company database, and limited to a specific service. A public key is generated cryptographically, portable across applications, and not controlled by one company. The same keypair can be used to hold assets, sign transactions, interact with programs, and participate in governance without creating a separate identity for every app.

What the first five days helped me understand

That idea became much clearer to me because the first week of the challenge forced me to work with the same identity model through different tools.

On Day 1, I generated a keypair and funded it on devnet. That was the first time I really saw a wallet address as something produced from cryptographic keys rather than from account registration. On Day 2, I created a persistent wallet and saved it locally, which made the relationship between the keypair and the wallet feel much more concrete. On Day 3, I looked at balances in both SOL and lamports, which reminded me that the user-friendly wallet experience is only one layer on top of lower-level data structures. On Day 4, I connected Phantom in the browser and saw that my app could read the public address and balance without ever touching the private key. On Day 5, I compared CLI, browser, and mobile wallets and realized that even though their user experience feels very different, they are all ultimately managing the same thing.

The wallet types also made the tradeoffs easier to see:

The CLI wallet felt the most direct and scriptable, which made it great for development and testing, but it also felt the least secure because the private key was just a file on disk.
The browser wallet added a much better user experience, with password protection and approval popups, which made it feel more suitable for dApp interactions.
The mobile wallet felt more natural for personal use because it could rely on device-level protections and a more familiar everyday interface.

What changed in my mental model

What changed across those experiences was the interface and security model. What stayed the same was the identity model.

I think that is the part that makes Solana identity different from the Web2 model many developers are used to. In Web2, identity is usually defined inside a platform boundary. On Solana, identity starts from a cryptographic keypair and can move across applications without asking each one to create or approve a new account. That is why ownership feels different too. The network does not ask whether a company recognizes you. It only checks whether the signature is valid.

If I had to summarize it simply for another Web2 developer, I would say this: on Solana, identity is not a username stored by a platform. It is a cryptographic keypair that you control. Once that idea clicked for me, wallets, ownership, and on-chain interaction all started to make much more sense.

For me, that was the point where Solana identity stopped feeling abstract and started feeling practical.

Agent Launchpad — Why Google Cloud Next ’26 Feels More Buildable for Developers

Zoe Lin — Fri, 24 Apr 2026 10:11:40 +0000

After watching the Google Cloud Next ’26 keynotes, the idea that stayed with me most was Google’s effort to make AI agents feel closer to real development work.

What stood out this year was the push behind the agentic enterprise and the Gemini Enterprise Agent Platform. The message felt clear: building an agent is no longer only about model output. It also involves deployment, data, security, governance, and the ability to fit into real workflows. That is what made this announcement interesting to me.

This point mattered to me because I have already used Google Cloud labs, deployed web projects on GCP, and experimented with Google AI Studio for testing chatbot and agent-style ideas. Through those experiences, I found Google’s ecosystem friendly in a practical way. I could move step by step from learning to testing, then to deployment, while still being able to check settings, usage, and limits. That gave me more confidence to try things without feeling lost too early.

Because of that background, this year’s keynote felt more concrete than abstract. I was not only hearing a big vision about agents. I was hearing a platform story that connects more of the parts developers usually struggle with after the demo stage. Once a project needs tools, permissions, deployment, monitoring, and business context, the work changes. That is where many interesting prototypes slow down.

What I liked most about Google Cloud Next ’26 was that it framed this problem clearly. The value was not only in making agents more capable. The value was in making the path around them more complete. For developers, especially newer builders, that matters a lot. The hardest part is often not getting the first result from a model. The harder part is turning that result into something stable, usable, and worth improving.

I still think there is room to make this direction easier to learn. The vision is strong, but newer developers will need more simple examples and clearer paths from experimentation to deployment. Google already does a good job with labs and guided learning, so I hope that continues as these agent workflows become more advanced.

What made Google Cloud Next ’26 memorable for me was how well it connected with my own experience. When the platform reduces friction, I get to spend more time thinking about the agent itself: what it should do, how it should help, and where its limits should be. That is why this year’s announcements stayed with me. They made the distance between learning and launching feel shorter.

Green Habit Coach — AI-Powered Habit Analysis and Eco Coaching

Zoe Lin — Sun, 19 Apr 2026 19:17:49 +0000

What I Built

I built Green Habit Coach, a web app that helps users reflect on their daily habits and get practical eco-friendly suggestions.

Users can log in, fill out a short habit form, and receive an analysis result based on their lifestyle inputs. The app looks at habits such as transportation, meat consumption, air conditioning usage, disposable item usage, recycling behavior, and bring-your-own habits.

After the analysis, users get an eco score, a short summary, top issues, suggestions, and a simple 7-day challenge plan. They can also continue the experience by asking follow-up questions through an AI coach, such as what to improve first this week or which habit is the easiest to start tomorrow.

I wanted to make sustainability feel more personal, more practical, and easier to act on in everyday life.

Demo

Code

GitHub Repo

How I Built It

I built the frontend with React + Vite and the backend with FastAPI.

On the frontend, users can log in, submit their habit data, view their latest analysis, load history records, and ask follow-up questions in the coach section.

On the backend, the app handles authenticated API requests, habit analysis, history storage, coach thread creation, and coach follow-up messaging.

The app uses:

Auth0 for login and protected API access
Backboard for the follow-up AI coach experience
SQLite + SQLAlchemy for storing analysis history
Firebase Hosting for the frontend
Google Cloud Run for the backend

One of the biggest parts of this project was not just building the features, but also making the whole flow work in deployment. I spent a lot of time debugging Auth0 configuration, CORS between the frontend and backend, Cloud Run deployment issues, and async backend integration for the coach flow.

That was actually one of the most valuable parts of the project, because it made the app feel like a real full-stack product instead of only a local demo.

Prize Categories

I’m submitting this project for:

Best Use of Backboard
Best Use of Auth0 for Agents

Backboard powers the coach conversation flow and makes it possible to continue the user journey after the initial habit analysis.

Auth0 helps connect the experience to real authenticated users, protect backend routes, and keep history data scoped to the correct user.

What I Learned

This project helped me practice real full-stack development, especially:

frontend/backend integration
cloud deployment
authentication
production debugging
building AI features that feel useful

It also gave me more experience turning a simple idea into a deployed product with a complete user flow.

Email Drafter — Multi-Agent Email Writing with Google ADK and Cloud Run

Zoe Lin — Fri, 17 Apr 2026 06:51:30 +0000

What I Built

I built Email Drafter, a small web app that turns structured user input into a polished email draft using a multi-agent workflow.

The app takes:

recipient type
purpose
tone
language
key points

Instead of using one giant prompt, I split the workflow into multiple specialized roles.

The system works like this:

one agent plans the email
one agent reviews the plan
one agent writes the final draft
one orchestrator coordinates the workflow

I also deployed the system as separate services on Cloud Run, so the app feels much closer to a real distributed AI workflow instead of just a local prototype.

I picked email drafting because it is a practical use case where planning, reviewing, and writing feel like naturally separate tasks. That made it a good fit for experimenting with multi-agent orchestration.

Your Agents

This project uses three specialized agents plus one orchestrator.

Researcher Agent

Creates a structured email plan from the user input.
Judge Agent

Reviews the plan and checks whether it is complete enough before moving on.
Content Builder Agent

Writes the final email draft from the approved plan.
Orchestrator Agent

Coordinates the workflow between the other agents and returns the final result to the frontend.

The overall flow is:

Frontend -> Orchestrator -> Researcher -> Judge -> Content Builder -> Final Email Draft

Key Learnings

This project helped me understand why multi-agent systems can be useful even for a relatively small app.

A few things stood out while building it:

Splitting the workflow made debugging easier. It was much easier to tell whether the issue came from planning, review, or writing than trying to fix one large prompt.
Deployment was harder than the basic prompt logic. Getting multiple services running locally, wiring them together, and then deploying them to Cloud Run took more effort than writing the first version of the agents.
Prompt wording had a big impact on output quality. Small instruction changes made a noticeable difference between getting a planning-style response and getting something that looked like a real email.
Multi-agent design felt more modular and production-oriented. Even for a simple email drafting tool, separating responsibilities made the system easier to reason about and improve.

Demo

Code

GitHub Repo

Hack Desk — Minimal Coding Setup for Global Hack Week

Zoe Lin — Tue, 14 Apr 2026 10:33:13 +0000

My Global Hack Week setup

My laptop, mouse, and a clean desk setup for building, debugging, and shipping projects.

@mlhacks

LogoForge — AI SVG Logo Generator for Brand Concepts

Zoe Lin — Mon, 13 Apr 2026 08:48:05 +0000

What I Built

I built LogoForge, a small web app that generates SVG logo concepts from a brand name, industry, style, and keywords using the Gemini API.

The app supports single and 3-variation generation, validates the model output as structured JSON, retries once if validation fails, and lets users preview the SVG, download it, and copy the JSON output.

I also refactored the project into a frontend and backend proxy setup so the API key is not exposed in the browser. That made the app feel much closer to something I would actually deploy instead of just keeping as a local prototype.

Demo

Code

GitHub Repo

My Experience

This project taught me that prompting works much better when I treat it like writing a product spec instead of giving a loose instruction. The clearer I was about the UI, output format, and SVG constraints, the better the generated app became.

The biggest lesson was reliability. A raw model response can look correct but still fail in subtle ways, so adding validation and a retry step made the app much more stable.

I also learned a lot from the deployment side. I started with a simpler client-side setup, then moved the Gemini call behind a backend proxy and deployed the frontend and backend separately. That part felt much more like real engineering work than just prompt experimentation.

During testing, I also occasionally ran into temporary Gemini API availability issues under high demand. The overall app flow and deployment setup still worked as expected, but it reminded me that real-world AI apps need both prompt design and engineering safeguards.

What I Learned

Clear constraints produce better results
Structured output still needs validation
SVG is a great way to create visual output without image generation
Small engineering steps like retries and safer secret handling make a big difference
AI tools can speed up prototyping, but reliability still depends on developer judgment