Juan Piaggio · 2026-06-29 · 7 min read · ai · prompts · infrastructure
In an AI product, the prompt is not documentation for the feature. It is the feature. Yet most teams treat this load-bearing text like a magic string buried three files deep, editable only by whoever is comfortable opening a pull request.
Think about how much of your AI's behavior lives in prompts. The tone it uses, the fields it extracts, the way it decides whether a ticket is a duplicate, the guardrails that keep it on task, all of that is expressed in natural language you wrote. It is, functionally, configuration. Very important configuration.
Now think about how that configuration usually gets changed. Someone edits a string literal in the codebase, opens a pull request, waits for review, waits for CI, waits for a deploy. A one-line wording tweak, "be more concise" or "always ask for a reproduction step", travels the full software delivery pipeline. The people who best understand what the AI should say, product managers, support leads, domain experts, cannot touch it without an engineer.
This is backwards. We learned this lesson with feature flags and remote config years ago: values that change on a product cadence should not be trapped behind a deploy cadence. Prompts are exactly that kind of value.
The core move of Prompt Ops is simple to state: store prompts as data, not as code. Concretely, that means:
Summarize issue {{issueTitle}} for {{audience}} gets filled with real values when the AI is invoked.Meshworq's Prompt Ops works this way. Its ticket-AI prompts live as templates in the database and are resolved at runtime, so improving how an agent phrases a triage summary or tightens a duplicate check is a data edit, not a code release.
The result is a shorter loop between "we noticed the AI phrases this awkwardly" and "the AI now phrases it well." That loop length is one of the most underrated determinants of AI product quality, because prompt improvement is inherently iterative and empirical. You cannot think your way to the perfect prompt; you have to try, observe, and adjust. Anything that slows the adjust step slows the whole learning curve.
Moving prompts to a database raises a fair objection: now the AI depends on a database row existing and being correct. What happens when the row is missing, malformed, or the store is briefly unavailable?
The answer is that code remains the fallback. The pattern is a resolver that tries the database template first and falls back to a version compiled into the application when the template is absent.
resolvePrompt(key):
template = db.getPrompt(key) // editable, versioned
if template exists:
return render(template, vars)
return render(BUILTIN_PROMPTS[key], vars) // safe default
This gives you the best of both worlds. The database version is the fast, editable, product-owned surface. The in-code version is the guaranteed floor, the thing that ships with the app and can never leave the AI without a prompt. Meshworq uses this resolve-then-fall-back approach, so a database hiccup degrades to a known-good default instead of a broken feature.
The database holds the prompt you are improving. The code holds the prompt you can always fall back to. Neither is optional.
Treating prompts as infrastructure is not just tidier. It changes what your team can do.
Non-engineers become contributors. A support lead who knows the exact phrasing that reduces back-and-forth can make that change directly. The expertise and the edit access finally sit in the same person.
Iteration gets cheap. When a change is a data edit, you make ten small refinements in the time one deploy would have taken. Small, frequent adjustments beat rare, large rewrites for something as empirical as prompt tuning.
Behavior becomes auditable. Versioned templates mean you can answer "what exactly was the AI told to do last Tuesday?" That traceability matters when you are debugging a regression or explaining an AI decision to a customer.
Experiments get structured. Once prompts are addressable data, you can attach them to variables, audiences, and eventually A/B comparisons, rather than forking code paths.
Prompt Ops is not an argument for putting everything in the database and nothing in code. Some judgment applies:
The goal is not to remove engineering from the loop. It is to remove the deploy from the loop for the class of changes that should never have needed one.
Prompts are product infrastructure because they define product behavior, and infrastructure deserves to be versioned, editable, and observable. Store templates as data with runtime variable resolution, let the people who understand the domain refine them without a deploy, and keep code as the always-present fallback so a missing row degrades gracefully. Meshworq's Prompt Ops follows exactly this pattern. Shorten the loop between noticing and fixing, and your AI gets better on a product cadence instead of a release one.