Google AI Studio Adds ‘Import from GitHub’ to Build Mode, Turning an Existing Repo Into an Editable, Deployable App

Google AI Studio has introduced an ‘import from GitHub’ feature within its Build mode, allowing users to load an existing repository and convert it into a runtime-compatible application. The update was announced on July 8, 2026, by the Google AI Studio account and Logan Kilpatrick, who leads the product.

Build mode currently functions as a development environment where a user describes an application in a prompt, Gemini generates a full-stack app with a live preview, and the developer refines the code through chat or annotation. This new capability adds a starting point by directing Build at a GitHub repository instead of a blank prompt.

The workflow

The process follows three steps: import the repository, iterate on the code within AI Studio, and deploy the application.

Google has not published the internal mechanics of the importer. In plain terms, the tool reads the repository, fits it to the runtime, and opens it in Build. The interactive walkthrough embedded in the original announcement is a concept simulation and does not represent the real backend.

Security and API keys

One documented behaviour concerns the handling of the Gemini API. When importing apps that use the Gemini API, AI Studio configures the GEMINI_API_KEY as a server-side secret. The keys are never included in client-side code.

Developers must plan for a server-side pattern if their repository calls the Gemini API directly from the browser. The example below contrasts the discouraged method with the recommended approach.

Discouraged: calling the Gemini API from the browser exposes the key.

// Discouraged: calling the Gemini API from the browser exposes the key
const res = await fetch(
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-flash-latest:generateContent",
  {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-goog-api-key": MY_KEY, // visible in the client bundle
    },
    body: JSON.stringify({ contents: [{ parts: [{ text: "Hello" }] }] }),
  }
);

Recommended: read the key from the server environment, call the API server-side.

// Recommended: read the key from the server environment, call the API server-side
// GEMINI_API_KEY lives in the server-side runtime, not in shipped client code.
export async function handler(req) {
  const apiKey = process.env.GEMINI_API_KEY; // server-side only
  const r = await fetch(
    "https://generativelanguage.googleapis.com/v1beta/models/gemini-flash-latest:generateContent",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "x-goog-api-key": apiKey,
      },
      body: JSON.stringify({ contents: [{ parts: [{ text: "Hello" }] }] }),
    }
  );
  return new Response(await r.text(), { status: r.status });
}

The endpoint and header above match the Gemini REST API. The point is placement: keep the key on the server.

Use cases

• Reviving a hackathon repo: You built a Vite plus React demo months ago. You import it, ask Build to add a settings page, then deploy to Cloud Run.
• Onboarding a teammate fast: A colleague shares a public repo. You import it, generate a walkthrough UI, and hand back a live preview link.
• Turning a script into an app: You have a small Gemini prototype in a repo. You import it, then use annotation mode to add a real interface.

Comparison with other workflows

The table shows the shape of the change. Import adds the inbound path that was missing.

Exact runtime format, private-repo support, and sync behaviour are still unconfirmed at launch.