Table of Contents

In AI projects, who writes the prompt — the client or the vendor? Increasingly the client does, because they hold the domain knowledge. So what does the vendor, or system integrator, actually do once the client can write the prompt themselves? That is the real question, and the answer is not “less.” The role shifts rather than shrinks.

In a traditional software project, the vendor drafts and the client confirms — an arrangement that quietly declares who the expert is. In AI projects that arrow often reverses: the client hands over a draft prompt, and the vendor refines it. But the reversal itself is not the interesting part. The interesting part is that the dividing line between client and vendor gets re-cut along a new axis — from expert versus non-expert to domain intent versus system execution.

The old dividing line was about expertise

For decades the implicit division of labor in delivery work was: the vendor produces the first draft, the client reviews it. Whoever holds the draft is the expert; the other party checks. This was true for specifications, for designs, for data models. The line separated the one who knew from the one who approved.

Natural-language prompting quietly dissolves that line. When the interface to the system is plain language, a domain expert on the client side can often express what they want better than the vendor can — because they, not the vendor, hold the domain knowledge. The client writing the first prompt is not an anomaly. It is the natural consequence of an interface that no longer requires specialist authorship.

The new dividing line is about execution inside a system

So if the client can write the prompt, what does the vendor do? The answer is visible the moment you look at what the client’s prompt actually contains — and what it leaves out.

In one real case, the client supplied a prompt for summarizing incoming email. It captured the execution logic precisely: what to summarize, what to emphasize, how to phrase it. What it did not contain — because it is not the client’s domain — was any of the following: what output format the result should take, which fields and objects it should populate, how the data should be structured so it stays useful downstream. The client knew what to do. They did not specify what structure to store the result in so it could be used later.

That gap is exactly where the vendor’s value now lives. The vendor takes the client’s intent and wraps it so it runs inside a system: shaping the output to fit the data model, mapping inputs to concrete actions, designing the schema with future use in mind. The division of labor has moved from “expert versus non-expert” to “domain intent versus system execution.”

The client’s prompt said what to do, but not what structure to hold the result in so it could be used later. That second question is the vendor’s.

The line moves — it doesn’t just relocate once

It would be tidy to say the line simply flipped to a new fixed position. It didn’t. The dividing line moves, and where it settles depends on the maturity of the specific task.

The clearest evidence came from watching two prompts inside the same client engagement end up with opposite authorship. For a mature task with clear execution intent — summarizing email — the client drafted the prompt. For an immature task where even the client could not define the desired output — extracting “issues” from those emails, where no one could yet say whether an issue was a to-do, a request, or a problem — the vendor wrote the prompt.

Same client. Same project. Opposite division of labor. The line did not settle by company; it settled by task maturity. Where the client’s intent was crisp, the client led. Where the intent itself was still unformed, the vendor led. This is why the boundary is best understood as a sliding line rather than a fixed handoff.

What stays constant underneath: making data AI-accessible

The line slides, but it slides across a stable floor. Underneath both prompts sat the same unglamorous, system-bound work: preparing, cleaning, and structuring data so an AI can actually reach it — the data workflows, the retrieval design, the mapping between messy inputs and usable records.

Prompt language has been democratized. The engineering that makes data AI-accessible has not. It is still heavy, still specific to the system it lives in, and it does not disappear just because the client can now write a fluent prompt. The vendor’s durable role is not “the one who writes the prompt” but “the one who makes the prompt run inside a system.”

The consequence: quality becomes a shared, converging output

When the line splits into intent (client) and execution (vendor), one thing follows immediately: neither side can own quality alone. The result is a joint output that both sides have to converge on together — and that changes how the project is actually run.

In traditional delivery, the weekly check-in is a progress report: here is what we planned, here is where we are, here is next week. It is one-directional and it tracks schedule. In an AI project, the same weekly slot turns into something else: the client and vendor sit together, review the LLM’s actual output, and refine the prompt jointly. The direction shifts from one-way reporting to two-way collaboration, and the subject shifts from schedule to the quality of the output itself.

This is a shift in how delivery risk is managed. Traditional projects manage quality risk with a final acceptance gate: measured against a defined spec, pass or fail. But an AI project often cannot fix the spec up front. So quality risk is managed instead by converging weekly — reviewing output together and tuning until it is right. The acceptance gate becomes continuous convergence.

In an AI project, the weekly review is not where you report progress — it is where client and vendor converge on the quality of the output, because quality risk is managed by repeated agreement rather than final inspection.

A note on what this piece does not claim

Everything above describes engagements where the client could express intent as a prompt. There is a further case — organizations where the client cannot yet articulate intent in prompt form at all — where the dividing line would presumably rise even higher, into discovering business intent before any prompt exists, and the skill required would be intent-elicitation rather than prompt-writing. I have not yet worked an engagement shaped that way, so I will not pretend to describe it from experience. I flag it only as the likely next position of the same sliding line.

Frequently asked questions

In AI projects, who should write the prompt — the client or the vendor? Whoever holds the intent for that specific task. For a mature task where the client knows exactly what they want (say, summarizing something in a domain they own), the client often writes the better prompt because they hold the domain knowledge. For an immature task where even the client can’t yet define the desired output, the vendor writes it. The dividing line isn’t fixed by role — it slides by how well-formed the intent is.

If the client writes the prompt, what does the vendor or system integrator do? The vendor’s value moves from authoring the prompt to making it run inside a system. The client’s prompt usually captures what to do; it rarely specifies what output structure to store the result in, which fields to populate, or how to shape the data so it stays useful later. That system-execution work — schema, data modeling, mapping intent to actions — is where the vendor’s expertise now lives.

Does natural-language prompting make system integrators obsolete in AI projects? No. It dissolves one part of the old role (being the sole author of specifications) and relocates value to another (making intent executable inside a system). The engineering that makes data AI-accessible — preparation, retrieval design, mapping messy inputs to usable records — doesn’t disappear just because the client can write a fluent prompt. The durable role is “the one who makes the prompt run in a system,” not “the one who writes the prompt.”

How is quality managed when the client owns intent and the vendor owns execution? As a shared, converging output rather than a final handoff. Because neither side owns quality alone, the weekly cadence shifts from one-directional progress reporting to joint review of the LLM’s actual output. Quality risk moves from a final acceptance gate (pass/fail against a fixed spec) to continuous weekly convergence — because in an AI project you often can’t fix the spec up front.

Takeaway

When the client writes the prompt, the vendor’s role does not disappear — it relocates. The dividing line is re-cut from expertise to execution: the client owns domain intent, the vendor makes that intent run inside a system, and the line between them slides according to how mature each task is. Underneath, the work of making data AI-accessible stays constant, and quality becomes something both sides converge on week by week rather than inspect at the end.