Google AI Studio: First Prototype Guide for Sri Lanka

A first Google AI Studio prototype should answer one narrow question: can a model perform this task reliably enough to justify further work? For a Sri Lankan business or learner, a small enquiry-classification exercise is easier to evaluate than an ambitious “AI assistant for everything.”

The Google AI Studio quickstart describes experimenting with prompts and settings, then using generated code to continue with the Gemini API. Start with evaluation before connecting the experiment to real customers.

Choose a bounded use case

Imagine a fictional repair business receiving enquiries about phones, laptops and unrelated services. The prototype's job is to classify an enquiry and identify missing information.

It should not quote a price, promise a repair time or contact the customer. Those actions require additional rules and reliable business information.

Write the acceptable outputs before testing. A simple set of categories and an “unclear” option gives you something concrete to review.

Prepare fictional test examples

Use invented names and messages. A prototype does not need real customer records to test whether the basic approach works.

Include difficult examples early. A model that handles three easy cases may still fail on the situations that matter most.

Write the prompt and output contract

Explain the task, allowed categories and how uncertainty should be handled. Ask for a consistent structure that your application can validate.

For example: “Return a category, a short reason and any missing information. Do not invent a price or promise an appointment. If the message is ambiguous, mark it for human review.”

The exact structure depends on the application. Even when the tool supports structured output, the surrounding system should check that the result is valid and appropriate.

Keep an evaluation table

Record the input, expected result, actual result and your judgement. Separate classification errors from formatting errors and unsupported claims.

Change one prompt element at a time, then rerun the same examples. This helps you see whether a change improves one case while breaking another.

Keep a few new examples aside for a later check. Repeatedly tuning only to the original examples can create a misleading impression of reliability.

Plan the step from experiment to product

Before deployment, consider access control, costs, rate limits, logging, data retention and a human fallback. Keep credentials out of client-visible code and public repositories.

Check the current service terms and account settings for the data you intend to process. A personal experiment and a workplace production system may have different requirements.

Do not automatically send replies or make commitments until the workflow has appropriate review and authorisation.

Do you need to choose the newest model?

Choose a model based on the task, quality, speed and cost you can measure. A model name alone is not an evaluation.

How many test examples are enough?

There is no universal number. Cover the important normal and failure cases, then expand the set as real requirements become clearer.

Can a successful demo be called production-ready?

Only after the surrounding application and operational requirements are addressed. A good prompt is one part of the system.

What should you show in a portfolio?

Show the use case, test set, results, limitations and next decisions. Honest evaluation is more informative than a single impressive response.

Related guides

• Google AI Mode for Job Research: A Sri Lanka Workflow
• NotebookLM for Interview Research: Sri Lanka Guide
• AI CV Review Prompts for Sri Lankan Job Seekers

Browse the Sri Lanka work and technology guides for more practical application, AI and workplace projects.