3.4 The "export code" mindset

What “export code” means

The “export code” mindset is simple: treat AI Studio as a prototyping environment, and treat your repo as the source of truth.

Exporting means moving the working parts of a successful AI Studio session into versioned, runnable artifacts:

• Prompt text (as a file)
• Schema (as a file)
• Wrapper code (as a module)
• Verification (tests or smoke checks)

Once exported, you can reproduce results, review diffs, and iterate safely.

Why exporting early makes you faster

Exporting can feel like “extra work” compared to staying in the playground. But it’s the fastest path to shipping because it buys you:

• Reproducibility: you can run the same prompt with the same settings again.
• Reviewability: diffs show exactly what changed.
• Verification: tests/smoke checks become part of the loop.
• Confidence: you can refactor and extend without fear.
• Collaboration: others can see and change what you did.

Without exporting, you get “prototype drift”: behavior changes without a clear reason, and you can’t trace regressions.

What to export (the core artifacts)

At minimum, export these four things:

1. The prompt: the best prompt version that produced good results.
2. The settings: model choice + sampling controls that matter for behavior.
3. The interface: the input/output contract (often a schema).
4. The verifier: a test or smoke script that proves it works.

1) Prompt file

Store prompts as files (not as hidden text in a session). This gives you diff history and makes behavior changes traceable.

2) Schema file (if parsing output)

If your app parses output, store the schema as a first-class artifact and validate every response.

3) Wrapper code

Wrap model calls behind a small module (one responsibility). This makes it easy to:

• swap models,
• change prompts,
• add retries/timeouts,
• log and measure,
• handle errors consistently.

4) Verification (tests or smoke checks)

Export the proof, not just the idea. At minimum:

• a smoke script that runs the prompt on 3–5 example inputs, or
• a unit test suite that validates structured outputs.

The minimal wrapper architecture

A clean export doesn’t require a big framework. The key is separation of concerns.

app (CLI/web) → modelClient (wrapper) → provider SDK
                  │
                  ├─ prompt file(s)
                  ├─ schema(s) + validators
                  └─ logging + retries + error handling

Why this wrapper matters

• Containment: model-related complexity stays in one place.
• Testability: you can mock the wrapper or validate outputs consistently.
• Replaceability: switching models/providers is easier.
• Safety: timeouts, budgets, and secrets hygiene live here.

Version prompts like code

Prompt changes are behavior changes. Treat them with the same discipline as code:

• Store prompts in files (not in chat history).
• Name versions explicitly (v1, v2, or date-based).
• Write a short changelog explaining why a prompt changed.
• Keep examples/evals so you can measure improvements vs regressions.

What to record for reproducibility

• Model name/version (or family)
• Temperature/top-p/top-k (if used)
• Max output tokens
• Schema version (if any)
• Prompt version

Verification-first exporting

Exporting is most valuable when it includes verification. Use this mental model:

• Prototype: prompt works on a few examples in the UI.
• Export: same prompt runs in a script in your repo.
• Verify: script/tests prove the output meets acceptance criteria.
• Harden: timeouts, retries, validation, error handling.

Without verification, exported code becomes “another prototype.”

A practical export workflow (step-by-step)

1. Pick the best prompt: the one that works on your representative cases.
2. Copy it into a file: prompts/task-name/v1.txt (example naming).
3. Define a schema (if needed): store it in schemas/.
4. Build a wrapper: src/modelClient.ts or src/model_client.py.
5. Create a runnable entrypoint: CLI or small web endpoint.
6. Add a smoke script: run prompt on 3–5 cases and validate output.
7. Record settings: model + sampling + versions.
8. Iterate in code: now your loop is prompt file diff → run → verify.

Common export anti-patterns (and fixes)

Anti-pattern: exporting only the code, not the prompt

• Symptom: behavior changes but you can’t explain why.
• Fix: store prompts in files and version them.

Anti-pattern: exporting with no verification

• Symptom: the app “works” until it doesn’t; debugging becomes guesswork.
• Fix: add a smoke test; validate schemas; log outputs.

Anti-pattern: building a huge framework too early

• Symptom: you spend time on architecture instead of shipping a working slice.
• Fix: start with a minimal wrapper and grow it as requirements appear.

Anti-pattern: baking secrets into exported code

• Symptom: leaked keys, unsafe logs, hard-to-rotate credentials.
• Fix: use environment variables and secrets hygiene from day one.

Copy-paste templates

Template: export checklist

- [ ] Prompt saved to repo (versioned)
- [ ] Settings recorded (model + sampling)
- [ ] Schema saved + validator added (if parsing)
- [ ] Wrapper module created
- [ ] Runnable entrypoint created (CLI/web)
- [ ] Smoke test added (3–5 cases)
- [ ] Notes on failure modes captured

Template: wrapper contract

Wrapper responsibilities:
- Load prompt by version
- Call model with recorded settings
- Validate structured output
- Handle timeouts/retries
- Return either:
  - { ok: true, value: ... }
  - { ok: false, error: ... }

Template: prompt file header

# Prompt: task-name v1
Purpose:
...

Inputs:
...

Output format:
...

Constraints:
- ...

Acceptance criteria:
- ...

Where to go next

• 4. Getting Set Up Without Breaking Anything
• 5. Your First “Hello, Vibe” Session