--- title: "Prompt engineering isn't a job title, it's a build step" description: "The discipline is being absorbed into ordinary engineering practice, and that is the correct outcome. With the case against." url: https://coyotiv.com/blog/prompt-engineering-is-a-build-step/ --- 1. [Blog](https://coyotiv.com/blog/) 2. [AI](https://coyotiv.com/blog/ai/) # Prompt engineering isn't a job title, it's a build step The discipline is being absorbed into ordinary engineering practice, and that is the correct outcome. With the case against. Coyotiv - 11 August 2026 - 5 min read _This post was first published on the [Raison blog](https://raison.ist/blog/prompt-engineering-is-a-build-step). [Raison](https://raison.ist/) is Coyotiv’s platform for managing AI prompts as a team: versions, environments, evaluations and rollbacks, without an application deployment._ In 2023 there were job postings for Prompt Engineer with salary bands attached. In 2026 there are far fewer, and the standard reading of that is that the role was a bubble. The standard reading is wrong in an interesting way. The role did not evaporate because prompting stopped mattering. It dissolved because the work got absorbed — the same way “webmaster” dissolved into six specialisms and “DBA” became something every backend engineer does badly until they need someone who does it well. Prompting is now a build step. It sits alongside writing a migration, defining a schema, and adding a test. ## What being a build step actually means The claim is not “prompting is easy.” It is that prompting has the same shape as other engineering work, and therefore inherits the same practices whether or not anyone chose them deliberately: - It is an **artifact** that lives somewhere and needs a home that is not a Notion doc. - It has **versions**, because you will need to know what it said last Tuesday. - It has **tests**, which are [evaluations](https://raison.ist/blog/measuring-prompt-quality), and they are as unglamorous as unit tests and as necessary. - It has **environments**, because you should not [learn things about a prompt change from production](https://raison.ist/blog/prompt-environments-explained). - It has **a review step**, at least for the changes that can hurt you. - It has **a rollback path**, because everything that ships needs one. None of that is exotic. All of it is what happens to any artifact once a business depends on it. The reason it felt like a specialism for two years is that the artifact was new and the practices had not caught up. ## The part that genuinely is a specialism Here is where the argument needs to be honest, because a post that flattens all prompting into “just engineering” would be wrong in a way practitioners would immediately spot. Some of this work does require unusual skill: **Diagnosing why a model behaves a certain way** is a real expertise, closer to debugging a distributed system than to writing a function. The feedback is stochastic, the state is opaque, and the intuition takes months to build. **Designing an evaluation set that measures the thing you care about** is the hardest part of the entire discipline, and most teams are bad at it. It is closer to experiment design than to software engineering, and it does not come free with a CS degree. **Knowing what a model cannot do** — which failures are prompt-fixable and which need retrieval, fine-tuning, or a different architecture — saves quarters of wasted effort. This is genuine seniority. So the accurate version is: prompting is a build step that everyone does, with a hard core that a few people do well. Which is exactly the situation with SQL, or with concurrency, or with CSS. The existence of people who are unusually good at a thing does not make that thing a separate job. ## Why the framing matters practically If prompting is a specialism, prompts live wherever the specialist keeps them, and everyone else files tickets. If prompting is a build step, prompts live in the build. They get versioned, tested, reviewed, and deployed by the same machinery as everything else — and the specialist’s time goes to the hard core instead of to being a bottleneck on tone changes. The second arrangement is better for the specialist too. Nobody’s best contribution is manually editing a string on behalf of the marketing team. ## The strongest objection The case against everything above: **treating prompts as code imports ceremony that does not fit.** Prompts iterate faster than code, by design. A prompt change is often exploratory in a way a code change is not — you are learning what the model does, not implementing a specification. Wrapping every exploratory edit in a pull request, two approvals, and a CI run would kill the loop that makes prompting effective in the first place. That objection is correct, and it is an argument about _where_ the ceremony goes, not whether prompts are engineering artifacts. Drafting should be free and instant. Evaluation should be one command. The gate belongs at promotion, not at authoring — which is [the case for gating constraint removals rather than every edit](https://raison.ist/blog/the-prompt-changes-nobody-approved). A team that puts the friction at authoring will be routed around. A team that puts it at promotion gets both the fast loop and the audit trail. ## Where this leaves the job title Roles that are actually growing have names like ML engineer, AI engineer, applied scientist — jobs where prompting is one tool among retrieval, evaluation, fine-tuning, and systems design. That is a promotion for the work, not a demotion. The tooling should follow the same logic. Prompt infrastructure that assumes a dedicated prompt engineer builds for a role most teams do not have. Infrastructure that assumes prompting is a build step — [versioned artifact, typed inputs, evaluations, environments](https://raison.ist/blog/the-raison-data-model) — builds for the team that exists. Put the friction at promotion, keep authoring free, and the whole thing stops being an argument about titles. Try Raison at [raison.ist](https://raison.ist/), or read [how Coyotiv started Raison](https://coyotiv.com/blog/coyotiv-announces-raison-prompt-management/). In this article 1. [What being a build step actually means](https://coyotiv.com/blog/prompt-engineering-is-a-build-step/#what-being-a-build-step-actually-means) 2. [The part that genuinely is a specialism](https://coyotiv.com/blog/prompt-engineering-is-a-build-step/#the-part-that-genuinely-is-a-specialism) 3. [Why the framing matters practically](https://coyotiv.com/blog/prompt-engineering-is-a-build-step/#why-the-framing-matters-practically) 4. [The strongest objection](https://coyotiv.com/blog/prompt-engineering-is-a-build-step/#the-strongest-objection) 5. [Where this leaves the job title](https://coyotiv.com/blog/prompt-engineering-is-a-build-step/#where-this-leaves-the-job-title) Share - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoyotiv.com%2Fblog%2Fprompt-engineering-is-a-build-step%2F) - [X](https://x.com/intent/post?url=https%3A%2F%2Fcoyotiv.com%2Fblog%2Fprompt-engineering-is-a-build-step%2F&text=Prompt+engineering+isn%27t+a+job+title%2C+it%27s+a+build+step) More from the blog ## Keep reading. [All posts](https://coyotiv.com/blog/) AI - 11 November 2026 - 10 min read ### [Enterprise AI adoption: procurement is getting easier. The hard part starts after the purchase](https://coyotiv.com/blog/enterprise-ai-adoption-the-hard-part-starts-after-the-purchase/) AI - 25 August 2026 - 6 min read ### [Preparing your team for the AI era: why 90% of corporate AI projects end up in the trash](https://coyotiv.com/blog/preparing-your-team-for-the-ai-era-why-90-percent-of-corporate-ai-projects-fail/) AI - 13 August 2026 - 5 min read ### [Nobody needs a prompt management tool until the second incident](https://coyotiv.com/blog/nobody-needs-a-prompt-management-tool-until-the-second-incident/)