Katkat

Design a Collaborative Prompt Playground

AnthropicSoftware Engineer · Onsite

Last 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?