git commit -m "better prompt": How Engineering Teams Started Treating Prompts Like Code

Six months ago, the prompt that powers the support bot at a mid-sized fintech company in Raleigh lived in a Google Doc titled 'final_FINAL_v3.' If you'd asked three engineers who last changed it, you'd have gotten three different answers and one nervous laugh.

Today that same prompt sits in a Git repository. It has a version number, a changelog, a set of regression tests, and a pull request history that reads like any other piece of production code. When someone wants to tweak it, they open a PR, a teammate reviews the diff, an automated eval suite runs against a golden dataset of past support tickets, and only then does it merge.

This isn't an outlier. Across US engineering teams — from Boston SaaS shops to LA content platforms — prompts are quietly getting the source-code treatment. And the tooling ecosystem that's grown up around the practice is starting to look a lot like the DevOps wave from a decade ago.

From Anecdote to Artifact

The core problem will be familiar to anyone who's shipped an LLM feature: prompts are the most consequential code in your stack, and until recently they were the least managed. A wording change could swing output quality by double digits, and nobody would know until a customer emailed support.

The teams we looked at converged on a similar stack pattern:

• A shared repository where prompts live as versioned files, often alongside the application code, so a prompt change ships in the same PR as the feature that needs it.
• An evaluation harness — think pytest for prompts — that runs every candidate prompt against a fixed set of test cases and scores the outputs before anything merges.
• A management platform (the category now includes names like PromptLayer, Langfuse, and Humanloop, among others) that logs which prompt version served which request, with tracing back to the exact model, temperature, and inputs.
• A review gate, where prompt changes get the same skeptical eyeball as a change to a payment handler.

The specifics vary. The philosophy doesn't: a prompt is production infrastructure, so it gets production discipline.

What the Reviews Actually Look Like

The most interesting artifact of this shift isn't the tooling — it's the culture. At one Chicago-based logistics startup, prompt PRs include a 'before/after' section with real model outputs, the way a frontend dev attaches screenshots. Reviewers leave comments like 'this instruction conflicts with the system prompt on line 4' or 'we tried this phrasing in March, see issue #212.'

That last one is the tell. Teams are accumulating institutional memory about prompts. Failed experiments stop being tribal knowledge trapped in one engineer's head and become documented history. When a senior engineer leaves, the reasoning behind a weird-looking prompt doesn't leave with them.

The eval suites deserve their own mention. The better teams treat test datasets the way security teams treat pen-test reports: living documents, refreshed with real edge cases from production. One team we heard about adds every customer-reported failure to their eval set within a week. Their prompt regressions have, accordingly, become rare and loud instead of common and silent.

So Long, Prompt Engineer?

Here's where it gets spicy for the LinkedIn crowd. For two years, 'prompt engineer' was the job title du jour, complete with salary-signaling think pieces. But inside the teams building this discipline, nobody's hiring for that title anymore — because the skill is dissolving into existing roles.

It looks less like a specialty and more like literacy. Backend engineers write and review prompts the way they write and review SQL. Product managers read eval dashboards the way they read funnel metrics. The prompt isn't a magical artifact crafted by a wizard; it's a config file with opinions.

That doesn't mean the expertise is gone. The people doing this well share a recognizable skill set: they think in terms of failure modes, they design tests before they tweak wording, and they treat model behavior as something to be measured rather than vibes to be felt. Call that whatever you want — 'LLM systems engineer' seems to be the emerging label — but it's a systems discipline, not a typing one.

The Honest Caveats

Worth saying plainly: this approach has costs. Eval suites take real time to build, and a small team shipping an internal tool probably doesn't need a PR gate for a prompt that summarizes meeting notes. There's also a real risk of over-engineering — some teams have built CI pipelines for prompts that change twice a year, which is ceremony, not engineering.

And the tooling category is young and consolidating fast. Pick a platform and you may be migrating in eighteen months. The teams with the least regret seem to be the ones keeping prompts in plain files in their own repos and treating vendor platforms as add-ons rather than foundations.

The Takeaway

If your team is shipping LLM features and your prompts live in someone's Slack DMs, you're one departure away from an archaeology project. The fix isn't complicated: put prompts in version control, write down why each change happened, and build even a minimal eval set before the next 'quick wording tweak' ships to production.

The teams doing this aren't the ones with the fanciest models. They're the ones who realized that the string of text steering those models deserves the same respect as the code around it. That realization is spreading — repo by repo, commit by commit.