Design a Collaborative Prompt Playground
AnthropicSoftware Engineer · OnsiteLast updated
Design a collaborative prompt playground with conflict-aware editing, immutable versions, asynchronous model runs, and reliable input and result provenance.
Design a collaborative prompt playground where users work on prompts together, preserve versions, and execute selected prompt versions against a model.
Constraints & Assumptions
- The source names a collaborative prompt playground and its collaboration, versioning, and execution flow. It is a third-party compilation, not a supplied company architecture.
- Practice scope: authenticated project members can edit a shared draft, create immutable versions, launch model runs, and inspect results linked to their exact inputs and configuration.
- No required collaboration algorithm, provider, model, scale target, or pricing policy is supplied.
- Concurrent editing, retries of run requests, and disconnecting clients must have defined behavior.
Clarifying Questions to Ask
- Is real-time character-level co-editing required, or is conflict-aware document saving sufficient?
- What belongs to a version: prompt text, templates, tools, model configuration, or input variables?
- Who may edit, execute, share results, or access provider credentials?
- Can model runs be canceled or queried after a lost response, and how should uncertain outcomes be shown?
Part 1 — Collaboration and Versioning
Define the draft, revision, and immutable-version model. Explain concurrent edits, reconnection, and the boundary between transient presence and durable document content.
What This Part Should Cover
- An explicit conflict strategy and authorization on edits.
- Stable version identity and immutable content/configuration bindings.
- No accidental mutation of the version already used by a running experiment.
Part 2 — Execute and Inspect a Version
Describe run creation, model execution, output delivery, and retry behavior. Explain how users compare results without losing their provenance.
What This Part Should Cover
- A run bound to a specific version, inputs, model configuration, and operation identity.
- Durable execution state and clear failed or uncertain outcomes.
- Separation of collaboration traffic from expensive model work and access to credentials.
Hints
Hint 1
Freeze before running: Two collaborators can change the draft while a model request is in progress. Decide which exact prompt the resulting output should claim to have executed.
Follow-up questions
- How would you add live co-editing to an initial compare-and-swap save design?
- What should happen when a user loses project access while a model run is active?
- How can two outputs be compared meaningfully if their prompt or model configurations differ?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.