"Add login with Supabase": the same prompt, three ways

"Add login with Supabase" might be the most-typed prompt in vibe coding, and Supabase earns it: the auth is genuinely three lines. But those three lines are the easy 10%. The other 90% — which key the browser sees, what happens when the password is wrong, whether a new user has to confirm their email — is decided by your prompt, or, if you don't decide, by the model's best guess.

We build this site the same way, so here's the honest version: the same request, given three ways to Claude via Claude Code, with the real code it produced each time. Watch what gets pinned down as the prompt gets more specific.

The same request, three ways

add login with supabase

import { createClient } from '@supabase/supabase-js';
const supabase = createClient(SUPABASE_URL, SUPABASE_KEY);

async function login(email, password) {
  const { data } = await supabase.auth.signInWithPassword({ email, password });
  return data;
}

add email + password login with Supabase: read the keys from env, show errors, redirect to /dashboard on success, and include a sign-up option

import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
);

async function login(email, password) {
  const { error } = await supabase.auth.signInWithPassword({ email, password });
  if (error) return showError(error.message);
  window.location.href = '/dashboard';
}

async function signUp(email, password) {
  const { error } = await supabase.auth.signUp({ email, password });
  if (error) return showError(error.message);
  showMessage('Check your email to confirm your account.');
}

same login, but: only ever use the anon key in the browser (never the service key), add a loading state that disables the button while submitting, and handle the 'user already registered' case

// Browser uses the ANON key only. The service key never leaves the server.
import { createClient } from '@supabase/supabase-js';
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY,
);

async function submit(mode, email, password, setLoading) {
  setLoading(true);
  try {
    const fn = mode === 'signup' ? 'signUp' : 'signInWithPassword';
    const { error } = await supabase.auth[fn]({ email, password });
    if (error) {
      if (error.message.includes('already registered'))
        return showError('That email is already in use — try logging in.');
      return showError(error.message);
    }
    window.location.href = mode === 'signup' ? '/check-email' : '/dashboard';
  } finally {
    setLoading(false);
  }
}

The jump from vague to constrained didn't need a smarter model. It needed you to say the parts a careful teammate would ask about: the key, the failure path, the loading state, the duplicate-email case. Each sentence you add is one fewer thing the AI decides for you.

The single most important line is that comment about the anon key. Supabase gives you two keys, and mixing them up is the classic vibe-coding breach: the anon (publishable) key is designed to be public and is safe to ship to the browser, but only when Row Level Security guards your tables. The service key bypasses all of that and must live only on the server.

One habit worth stealing: after the AI writes your login, ask it the verify-loop question, "what happens if the email is empty, the password is wrong, or the same person submits twice quickly?" On our own build, that single prompt is what turned a login that worked into a login that didn't fall over. The model is happy to attack its own code; you just have to ask it to.

Before you ship it

Login proves who someone is; it does not decide what they're allowed to touch. That's a separate job, and it's where most "my data leaked" stories actually begin. Before real users hit your login page:

• Put Row Level Security on every table with personal data — login alone isn't enough. See Authorization vs authentication and Row Level Security, explained.
• Keep the service key on the server, forever. If it's in the browser, anyone can read your whole database — Your API keys are in the browser.
• Rate-limit the login and sign-up routes so nobody can hammer them — Rate limits, explained.
• Turn on email confirmation so people can't sign up as an address they don't own.

Start from What is login, actually? if you want the mental model (it has an interactive two-phone demo of tokens), then come back and prompt for the version that's safe to ship. The pattern repeats for every provider: the auth is easy, the spec is the product.