A few weeks ago I wrote a breakdown of Cloud Next '26 for developers Link to keynote and closed it with a line to other frontend devs: play with Agent Studio. I took my own advice.
I tried to take my own advice and faced a technical issue with Google Cloud's new prepayment wall and pivoted. This post is what happened next: spending an hour in Google AI Studio, iterating one prompt three times and finishing with Typescript I could drop into a Next.js project. No billing required, no Cloud project. Just a Google account.
If you're stuck at the same prepayment wall, or if you just want to know what the Gemini playground actually looks like before committing to anything paid, this is for you.
What AI Studio actually is
A quick note for anyone confused by the naming, because Google has not made this easy.
There's Gemini Enterprise, which lives in Cloud Console behind a billing account; that's the enterprise stack I wrote about in the keynote piece.
Then there's Google AI Studio at aistudio.google.com, which is the public-facing Gemini playground. Sign in with any Google account. No card, no project, no setup.
| Feature | Google AI Studio | Gemini Enterprise |
|---|
| User Type | Prototypers, Developers | Data Scientists, Enterprise |
| Complexity | Low (Simple) | High (Advanced) |
| Purpose | Experimentation | Production & Scaling |
| Cost | Generous Free Tier | Usage-based |
| Security | Standard | Enterprise-grade (GCP) |
For this walkthrough, I used Gemini 3 Flash Preview which is the cheaper, faster sibling to Gemini 3 Pro. Flash Preview is the right default when you're iterating because the latency difference matters when you're running the same prompt five or six times in a row.
I wanted to see how the same prompt evolved across three versions. One task, three system prompts, same user input. The point wasn't to land at a perfect prompt on the first try; it was to show what changes when you take prompt iteration seriously instead of writing one prompt and hoping.
I used the same input for all three versions:
We need a hero section for our SaaS landing page. The product is a project management tool for small design agencies. Should feel premium
but approachable. Main goal is to get visitors to start a free trial.
This is roughly how a brief actually arrives in a frontend dev's inbox: vague, opinion-loaded, half a sentence longer than it needs to be. The whole point of running it through an LLM is to turn that vagueness into a structured spec a developer can build from. So that's what I tried to make the model do.
V1: The naive prompt
I adjusted the temperature from 1(default) to 0.7 and I gave sytem instructions.
System instructions:
You are a helpful assistant. Generate a component spec based on the design brief the user provides.
The kind of system prompt anyone would write on the first try. No structure, no constraints, just "do the thing."
The output came back more beautifully than expected. An editorial document with visual guidelines, color palette with hex codes, typography choices, three headline options, a copy strategy section and even a Typescript interface for HeroProps inside the markdown.
It's genuinely impressive. And that's the trap.
V1 succeeded as a document.
It did not succeed as a spec.
There's a difference, and that difference is the whole reason this post exists.
If I want to feed this output into a code generator, populate a Notion database, or render fields dynamically in a React form, I can't. I'd have to manually parse the markdown, find the HeroProps interface, scrape the hex codes out of the prose, copy the headline options into an array. The model wrote content for humans, when what I needed was data for machines.
Token cost: 208. Cheap. Fast. Useless if you want to do anything programmatic.
V2: Asking for structure
If V1 returned prose because I asked for prose, maybe V2 returns data if I ask for data. With temperature still set at 0.7 I replaced system instructions.
New system instructions:
You are a frontend architect helping translate design briefs into
component specifications. When given a design brief, return a
structured component spec with the following information:
- Component name
- Purpose
- Suggested props
- Accessibility considerations
- Suggested Tailwind classes for key elements
Return your response as JSON.
The output came back as JSON. Real JSON. Valid JSON.
Look at field names like component_name, purpose, suggested_props, primaryAction, productScreenshotUrl, trustBadges. Some snake_case, some camelCase. Some are top-level, some are nested.
This looks better. But there's a quieter problem hiding in plain sight. I didn't define the schema. The model did.
I ran the prompt again. "DesignAgencyHero" in the first prompt became "CreativeStudioHero". Also, suggested props like "headline" became "title" and "subheadline" became "description" etc. New fields appeared. Old ones vanished.
The output is JSON, but it's JSON I can't trust to stay the same shape across calls. And if the shape isn't stable, I can't write code that consumes it.
Better than V1, still not deployable.
V3: Structured outputs
This is where AI Studio earns its keep.
In the parameters panel, there's a toggle called Structured outputs. Flip it on, and AI Studio gives you a schema editor where you define exactly what comes back. Field names, types, what's required, what's optional, nested objects, all of it. The model has to conform to the shape you specified.
Here's the schema I used:
{
"type": "object",
"properties": {
"componentName": { "type": "string" },
"purpose": { "type": "string" },
"props": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": { "type": "string" },
"type": { "type": "string" },
"required": { "type": "boolean" },
"description": { "type": "string" }
},
"required": ["name", "type", "required", "description"]
}
},
"accessibilityNotes": {
"type": "array",
"items": { "type": "string" }
},
"suggestedTailwindClasses": {
"type": "object",
"properties": {
"container": { "type": "string" },
"heading": { "type": "string" },
"subheading": { "type": "string" },
"ctaButton": { "type": "string" }
}
}
},
"required": ["componentName", "purpose", "props", "accessibilityNotes", "suggestedTailwindClasses"]
}
Defining this schema took longer than writing the prompt. That's the honest tradeoff: structured outputs aren't free, and they aren't fast. You're doing real design work upfront in exchange for output you can actually consume.
The system instruction got simpler:
You are a frontend architect helping translate design briefs into
component specifications. Return a complete, well-considered component
spec based on the design brief provided.
I no longer needed to list the fields in the system prompt. The schema does that job now.
To show the payoff clearly, I ran V3 three times with the same input but different temperatures: 0.2, 0.7, and 0.9.
Temperature 0.2: conservative settings. The model returns a tight, safe spec.
Component name: AgencyHeroSection. Compact descriptions. Predictable choices.
Temperature 0.7: middle ground.
Component name: PremiumStudioHero. Richer descriptions. More distinctive framing.
Temperature 0.9: turn the creativity dial up.
Component name: DesignAgencyHero. The most evocative copy of the three. The descriptions reach for words like "craft" and "flow."
Three runs. Three different creative interpretations. The schema stayed identical across all three. Same fields. Same types. Same nesting. The model varied the content. It could not vary the shape.
That's the entire point. Structured outputs separate the parts of the response you want stable from the parts you want creative. Field names and structure stay locked. Tone, copy, and specifics breathe within those constraints.
A note on cost: V3 at temperature 0.9 burned 9,357 tokens, compared to V1's 208. Schema definitions are part of the prompt the model sees, and a detailed schema is a long prompt. Structured outputs are powerful, but they aren't cheap. For high-volume calls, this matters.
From Playground to Code
Here's the part where this stops being a playground exercise and starts being something I could actually ship.
In the top-right of the Run settings panel, there's a button labeled Get code (<>). I clicked it with V3 still loaded schema enabled, temperature still set, system prompt still in place and AI Studio generates working code in your language of choice.
I picked TypeScript.
Here is the code:
// To run this code you need to install the following dependencies:
// npm install @google/genai mime
// npm install -D @types/node
import {
GoogleGenAI,
Type,
} from '@google/genai';
async function main() {
const ai = new GoogleGenAI({
apiKey: process.env['GEMINI_API_KEY'],
});
const config = {
temperature: 0.7,
thinkingConfig: {
thinkingLevel: ThinkingLevel.HIGH,
},
responseMimeType: 'application/json',
responseSchema: {
type: Type.OBJECT,
required: ["componentName", "purpose", "props", "accessibilityNotes", "suggestedTailwindClasses"],
properties: {
componentName: {
type: Type.STRING,
},
purpose: {
type: Type.STRING,
},
props: {
type: Type.ARRAY,
items: {
type: Type.OBJECT,
required: ["name", "type", "required", "description"],
properties: {
name: {
type: Type.STRING,
},
type: {
type: Type.STRING,
},
required: {
type: Type.BOOLEAN,
},
description: {
type: Type.STRING,
},
},
},
},
accessibilityNotes: {
type: Type.ARRAY,
items: {
type: Type.STRING,
},
},
suggestedTailwindClasses: {
type: Type.OBJECT,
properties: {
container: {
type: Type.STRING,
},
heading: {
type: Type.STRING,
},
subheading: {
type: Type.STRING,
},
ctaButton: {
type: Type.STRING,
},
},
},
},
},
systemInstruction: [
{
text: `You are a frontend architect helping translate design briefs into
component specifications. Return a complete, well-considered
component spec based on the design brief provided.
`,
}
],
};
const model = 'gemini-3-flash-preview';
const contents = [
{
role: 'user',
parts: [
{
text: `INSERT_INPUT_HERE`,
},
],
},
];
const response = await ai.models.generateContentStream({
model,
config,
contents,
});
let fileIndex = 0;
for await (const chunk of response) {
if (chunk.text) {
console.log(chunk.text);
}
}
}
main();
Every parameter I touched in the UI is now a field in the code. Temperature. Thinking level. Response MIME type. The schema. The system prompt. Nothing got lost in translation between the playground and the script.
The SDK is @google/genai, the official Google package. Install with npm install @google/genai mime and npm install -D @types/node. Get a free API key from AI Studio's "Get API key" link in the left sidebar with no billing required and a generous free tier.
This drops into a Next.js API route with minimal changes. The schema travels with the code. The system prompt travels with the code. The temperature you tuned travels with the code. The hour I spent in the playground became 60 lines of TypeScript I can paste into app/api/component-spec/route.ts and call from a frontend form.
That's the bridge. That's what makes AI Studio worth using even if you eventually move to Agent Platform: the iteration happens in the playground, the deployment happens in code, and the handoff is one button.
What this means for frontend devs
Three things I'm taking from this hour:
You don't need Cloud billing to start. AI Studio plus a free API key gets you most of the way to a working Gemini integration. If you're learning, prototyping, or building a personal project, this stack is plenty. The expensive enterprise tools are for a real production app at scale, not for figuring out whether the model can do what you need.
Prompt iteration is engineering. V1 to V2 to V3 wasn't an aesthetic exercise. Each version was a deliberate response to a real problem with the previous one: V1's prose couldn't be parsed, V2's JSON couldn't be trusted, V3's schema solved both. Treat prompts the way you'd treat any other component of your system: iterate them, version them, write them down.
Structured outputs are the real unlock. The moment your model returns the same shape every time, you stop treating AI calls as dice rolls and start treating them as normal API calls. You can write TypeScript types for the response. You can render the output in a UI without defensive parsing. You can build product around the model's behavior, not around its randomness.
The last point is what I want to keep poking at. When my Cloud account clears the prepayment wall and I get into Agent Studio, the question I'm bringing with me is: how do these same patterns translate to a deployed agent?
For now: if you're stuck at billing, don't wait. AI Studio is right here. Sign in, pick a model, iterate something useful.