4. Getting Set Up Without Breaking Anything

What “setup without breaking anything” means

In AI-assisted building, “setup” is not just “get the UI working.” Setup is the foundation for safe iteration. A safe setup prevents three expensive classes of failure:

• Security mistakes: leaking keys, logging secrets, or granting overly broad access.
• Operational surprises: rate limits, flaky behavior, and unhandled failures.
• Cost surprises: prototypes that suddenly become expensive or slow.

This section teaches you how to get moving quickly without creating hidden risks that will slow you down later.

Four principles for safe setup

1) Least privilege

Only grant the minimum permissions necessary for the current task. This applies to:

• accounts and IAM roles,
• API keys / credentials,
• tool calling permissions,
• data access.

When the model (or your code) can do too much, mistakes are more costly.

2) Separate prototypes from real systems

Prototype in a way that can’t hurt production:

• use separate projects/environments,
• use test data,
• disable destructive actions by default.

3) Make failures observable

Early prototypes often fail silently. Set up your code and workflow so that failures are visible and diagnosable:

• clear error messages,
• basic logging,
• timeouts and retries with explicit reporting.

4) Make the setup repeatable

If setup only works on your machine once, it’s not setup—it’s luck. Aim for:

• documented run instructions,
• environment variables instead of hardcoded values,
• a minimal smoke test that proves the integration works.

What usually goes wrong (and why)

Most setup problems fall into a handful of predictable buckets:

• Permissions: wrong account, missing access, restricted org policies, or misconfigured roles.
• Credentials: using the wrong type of credential, storing it unsafely, or accidentally committing it.
• Rate limits: prototypes that work once, then fail intermittently under repeated calls.
• Safety settings: prompts that work in testing but get blocked unexpectedly in real usage.
• Context and cost: huge prompts that are slow and expensive, causing timeouts and budget surprises.

The rest of this section is basically: “how to avoid these predictable failures.”

Secrets hygiene (non-negotiables)

Secrets are the fastest way to accidentally do real damage. Adopt these rules early and you’ll avoid 90% of “oops” incidents:

• No secrets in prompts. Treat prompts as potentially logged and shared.
• No secrets in logs. Redact tokens and credentials aggressively.
• No secrets in git. Never commit keys. Add .env (or equivalent) to ignore lists.
• Use environment variables. Keep credentials out of code and out of config files that travel.
• Rotate quickly. Assume keys leak eventually; make rotation routine.

Environments: prototype vs production

Setup is easiest when you consciously separate environments. A simple way to think about it:

• Prototype: speed, low friction, strict limits, no sensitive data.
• Production: governance, auditability, least privilege, strong monitoring, safe rollouts.

This section is about prototype setup that won’t sabotage production later.

A practical boundary

• Prototype keys and projects should never have access to production data.
• Production keys should never be used locally “just for a quick test.”
• Prototype code should assume failure and handle it gracefully (timeouts, retries, fallbacks).

Quotas and cost: safe defaults

Many prototypes “break” not because the code is wrong, but because quotas and limits are being hit. Treat quotas as an engineering constraint, not a billing footnote.

Safe defaults you can adopt early

• Set a budget ceiling: know your acceptable max spend for experimentation.
• Prefer smaller models for iteration: escalate only when needed.
• Keep prompts tight: big context is expensive and slower.
• Implement timeouts: don’t let calls hang indefinitely.
• Use retries with backoff: handle transient failures without hammering the API.
• Cache where safe: repeated calls with identical inputs are a cost trap.

Safety settings: what they are for

Safety settings aren’t just policy—they are product behavior. They can affect whether outputs are allowed, blocked, or truncated. If you ignore them during setup, you’ll get surprising failures later.

A safe mindset is:

• Design prompts that avoid risky behavior instead of hoping filters will catch it.
• Build refusal-aware UX (your app should handle “blocked” outputs gracefully).
• Handle sensitive data responsibly (minimize, redact, and avoid logging).

A safe “first run” workflow

Use this workflow to set up without getting stuck:

1. Confirm access: can you open AI Studio and run a trivial prompt?
2. Choose your credential model: understand what credential type you’re using and where it’s stored.
3. Set strict limits: quotas/budget expectations; avoid accidental runaway usage.
4. Build a tiny integration: one script or CLI command that calls the model once.
5. Add one verification check: validate output shape or run a smoke test.
6. Document the run path: “how to run this from a clean checkout.”

Checklists you can reuse

Secrets checklist

• Keys are stored in env vars (not code).
• .env (or equivalent) is ignored by Git.
• Logs do not print keys or raw prompts with sensitive data.
• There is a revoke/rotate path for credentials.

Reliability checklist

• Timeouts are set for model calls.
• Retries exist for transient failures (with backoff).
• Errors are surfaced clearly (not swallowed).
• There is a smoke test that proves the integration works.

Cost/quota checklist

• Model choice is intentional (fast vs smart vs cheap).
• Prompt size is kept small; context is budgeted.
• Repeated calls are minimized (cache where safe).
• You understand the quota/rate-limit failure behavior.

Section map (4.1 → 4.4)

• 4.1 Account access and permissions basics
• 4.2 API keys vs project credentials (the safe mental model)
• 4.3 Rate limits and quotas (why your prototype suddenly fails)
• 4.4 Basic safety settings and why they matter

Where to go next

• Start with 4.1 (access & permissions)
• Then go to 5 (Hello, Vibe)