Prompt Engineering Isn't Engineering

We named a skill after the first people who did it, and the mistake is keeping AI stuck in one department.

I built a tool to feed my engineering team faster. What I actually built was a business analyst.

Here is what it does. Someone outside engineering opens the Claude desktop app they already use and has a conversation about the thing they want. The skill asks questions, politely and relentlessly: what happens today, what should happen instead, who is affected, what does done look like, what are we explicitly not doing. It refuses to let ambiguity slide. When the conversation ends, out comes a markdown document in exactly the shape our development pipeline expects as input. The requester believes they had a chat about their idea. What they produced is most of a spec.

I built it because I could see our delivery engine was starting to outrun its own supply. A team shipping at our pace needs well-formed work arriving continuously, and a weekly meeting was never going to keep up. That is an engineering problem, and I approached it with an engineering mindset. It took me an embarrassingly long time to notice that the thing I had encoded was not an engineering skill at all.

The category error

Getting a vague wish out of someone's head and into a precise, unambiguous, testable description of what to build is a discipline. It has a name. Business analysts have been doing it for decades, with techniques, training, and scar tissue that predate the transformer by a generation. Requirements elicitation is the whole job.

That is also, almost exactly, what it means to prompt an AI system well. Not the syntax tricks, which are a rounding error. The real skill is knowing which question to ask next, noticing the assumption the requester did not know they were making, and pinning down what done looks like before anyone starts. Those are elicitation skills. We called the discipline prompt engineering because the first people who did it were engineers, and they were the first only because the tools lived in their terminals.

We named the skill after whoever got there first, not after whoever was best at it. I want to be careful here, because plenty of people carrying the prompt engineer title are doing genuinely difficult work, and nothing in this piece is a swipe at them. The problem is what the label does to everyone else.

What the label costs

If prompting is engineering, then every other department waits for engineering to do it for them. That is precisely what happens at most companies. AI adoption stalls inside the one function that had the tools first, and the rest of the organization gets a chat window and a vague instruction to use AI, which is a little like handing someone a kitchen and telling them to use food.

If prompting is elicitation, the picture inverts. Every function already has people with that skill. The analyst who runs requirements sessions. The ops lead who turns a complaint into a process change. The customer team that translates what a client said into what they meant. They have been doing the hard part of prompting for years without a model in the loop. The label was the only thing telling them this was not their territory.

The transferable thing is not the tool

This is the larger claim, and it is the one I care more about. When people ask how to spread what worked in our engineering org to the rest of the company, they usually mean the tooling. That is the wrong artifact.

What actually transfers is the pattern. Work moves through stages. Each stage produces something durable. Nothing advances until someone can explain it. Documentation falls out as a byproduct instead of being a separate chore. Purpose-built skills encode how a specific function actually operates, rather than asking a general model to guess. None of that is about code. Engineering arrived at it first because engineering had the tools first, and it turns out to be a description of disciplined work in any department.

The mindset shift underneath it is the real frontier. It is the move from "use AI" to "figure out how AI actually works in my department." Those sound similar and are not. The first is a mandate. The second is a design problem, and it is an emerging one. My team worked through it for engineering first, but every other function is about to face it, because we are planning for the entire company to work with Claude, not just the people who write code. I would rather build the pattern ahead of that than discover the gap after it opens. Other functions do not need to repeat our learning curve. They need the pattern and one person willing to adapt it.

What the next version looks like

We are building the successor to the intake skill now, and its design principle is the clearest statement of this argument I can offer: friction should scale with ambiguity.

Forms cannot do that. A form is static, so it has to be built for the worst case, which means it carries the right friction for a net-new feature and absurd friction for a broken link. A conversation can start small and go deeper only when the answers warrant it. The new version infers from the conversation whether it is looking at a bug, an improvement, or something that needs design work and wireframes, then gathers exactly what that path requires. The requester never picks a category. The decision comes out of the description.

That is not a nicer form. It is a business analyst's behavior, encoded, and operated by people who would never call themselves analysts.

The role moves up

Jeremy Phillips, who ran my team at Princess years ago, put the consequence better than I had. If AI takes over the mechanical parts of requirements capture and handover documentation, the BA role does not disappear. It gets freed up for bespoke process optimization, the high-value work that always got squeezed out by the paperwork.

That is the same evolution engineers just went through. The typing got cheap, so the job became judgment. Elicitation gets cheap, so the analyst's job becomes deciding which processes deserve to exist. Same shape, one function over. And it suggests the sequence every other department is about to follow, whether or not anyone plans it.

So the frontier is not better prompts. It is each function importing the pattern, adapting it to how that function actually works, and finding the one person in the room curious enough to carry it. We named the skill after engineers. It was never really ours.