Hardcoding LLM prompts is fine until it isn't. Here's what we built instead.

#ai #llm #promptengineering #showdev

I had a bug last month that took most of a Saturday to find. A support bot we shipped started promising refund timelines that didn't match policy. Customer complaints, frantic Slack messages, the usual.

The prompt had changed three weeks earlier. Nobody could remember why. Git blame pointed to a one-line edit inside a 200-line SYSTEM_PROMPT constant. No PR description, no diff worth reading.

That's when I knew I'd been writing prompts wrong for the last two years.

PromptOT - Prompt Management Platform

Compose prompts from typed blocks, version safely, and deliver to your apps via API. The prompt management platform built for AI engineering teams.

promptot.com

Prompts are code, but we treat them like Notion docs

A typical system prompt for anything useful crams five things into one string:

You are a friendly support agent for Acme. Use this knowledge: {{kb}}.
Follow escalation rules. Never share internal ticket IDs. Reply in plain
text, two to four paragraphs.

That's a role, context, instructions, guardrails, and an output format all jammed together. When the PM wants to soften the tone, they're editing the same string an engineer uses to update the knowledge base. When security adds a guardrail, it lands inches from the response format. One bad edit and every reply ships broken.

We wouldn't write code this way. So why are prompts always a 200-line const somewhere in lib/?

What I built

PromptOT is a prompt management platform. The core idea is small: typed blocks instead of flat strings.

You break a prompt into pieces. Each piece has a type — role, context, instructions, guardrails, output_format, custom. Each one is independently editable, can be toggled on or off, and has its own version history. The compiler joins them into a single prompt string at delivery time.

Block 1 — role:          "You are a support agent for Acme..."
Block 2 — context:       "Knowledge base: {{kb}}..."
Block 3 — instructions:  "1. Acknowledge the issue..."
Block 4 — guardrails:    "Never share internal ticket IDs..."
Block 5 — output_format: "Plain text, two to four paragraphs..."

Now the PM edits one block. The security review adds a guardrail without touching anything else. Each save is a version. Publishing a version makes it immutable. If something breaks in prod, you roll back from the dashboard in two clicks.

The delivery layer

Apps fetch the compiled prompt through a simple API. Production keys return the published version. Development keys return whatever draft is currently being iterated on. Variables resolve at fetch time:

curl https://api.promptot.com/api/v1/prompts/support-bot/compiled \
  -H "Authorization: Bearer pk_live_..." \
  -d '{"customer_name": "Maya", "kb": "..."}'

That's it. No SDK to install. No prompt strings sitting in your codebase. Updating a prompt does not require a deploy.

The part I'm proudest of

PromptOT ships an MCP server with 23 tools, so your AI assistant can manage prompts for you. I can be in Claude Desktop or Cursor and say:

Read my support-bot prompt and add a guardrail about not promising refund timelines.

Claude calls get_prompt, drafts the change, and calls save_draft_version. I review the diff and publish. The whole loop happens in chat. No tab-switching, no dashboard.

claude.ai and ChatGPT connect via OAuth, so they never see a raw key. Other clients (Claude Desktop, Cursor, Codex CLI, Windsurf, Zed) get a scoped install snippet from the dashboard.