Changing a prompt usually means: edit a string buried in your codebase, redeploy, test in production because your local setup doesn't quite match, and hope you didn't break the one edge case that was working before. LangSmith's Playground and Prompt Hub exist to take most of that friction away.
Playground: iterate without redeploying
The Playground is a browser-based sandbox for testing a prompt directly - type it in, run it against a real model, and see the output immediately. You can compare multiple models side by side on the exact same prompt, adjust parameters like temperature in real time, and see token usage and estimated cost as you go. None of this touches your codebase; you're editing a prompt in a UI, not a file in your repo.
This matters most in the early, messy phase of getting a prompt right, where you might try fifteen small wording changes in an hour. Doing that as fifteen separate deploys would be painful. Doing it in the Playground is just typing and clicking "run."
Every push creates a new immutable commit; a mutable tag like "prod" points at whichever commit your app should pull.
Prompt Hub: versioning that doesn't overwrite history
Once a prompt is worth keeping, you push it to the Prompt Hub - a centralized, versioned repository. Every push creates a new immutable commit, identified by a hash. Nothing is ever overwritten: you can pull any past commit, indefinitely, even after dozens of edits.
On top of commits sit tags - mutable pointers, like staging or prod, that point at a specific commit. When you're happy with a new version in the Playground, you push it, then move the prod tag to point at that new commit. Your production code, which pulls by tag rather than by a hardcoded prompt string, automatically starts using the new version - no redeploy needed.
from langsmith import Client
client = Client()
# Pull whatever commit the "prod" tag currently points to
prompt = client.pull_prompt("customer-support-reply:prod")prod tag to a bad version is instantly reversible - just point it back at the previous commit hash. You're never editing a prompt in place; you're always creating a new version and choosing which one is live.Where this connects to the rest of the series
Pulling a prompt by tag instead of hardcoding it means a non-engineer - a PM, a support lead, whoever actually knows what a good customer reply sounds like - can iterate on wording in the Playground and ship it themselves, without a code change or your review of a pull request for a single sentence tweak. And because every prompt version is just another input to your traced app, you can run the evaluations from the previous guide against a new prompt commit before ever promoting it to prod, closing the loop between "I think this wording is better" and "I can prove it scored higher."