Analogy: instructions to an engineer in the office
Imagine you brief an engineer in the practice.
Bad version: “Make the frame study better.” No scope, no deliverables, no units, no file to open, no rule about what not to invent. What comes back may be brilliant… or a thing you did not ask for. And if you never fixed the criteria, you have no clean way to reject it.
Clear version: “Review the level-3 frame in file X. Units in kN and m. List assumptions, loads, and warnings. Do not invent engine results: if they are missing, ask. Deliver in sections: assumptions, facts, open items. If the model does not open, stop and say so.”
That is not a spell. It is a work order. Prompt engineering, in office language, is exactly that: designing the instructions you give the assistant — here, an “engineer” inside the digital firm — so the work is verifiable, not merely persuasive.
Bad instructions (no clarity, no scope, no deliverables) produce work you did not want. Good instructions do not guarantee magic; they guarantee that you can audit, reject, and repeat.
This note is part of the series on the AI harness for civil engineering. Read it with the system prompt (where policy lives) and the LLM’s role (why two runs can differ).
You wrote “better” and pasted it into the report
You ask for a “clearer” calculation memo. The chat answers with clean prose. You paste it into the report. Half an hour later, out of curiosity, you run the same request again. The tone changed. An assumption moved. A number appears with different wording — or a different value.
You wrote “better” and treated it as procedure. It was not.
The belief worth breaking: prompt engineering is a course in tricks, or asking it to “think step by step” until it sounds professional. In an AEC office, prompt engineering is something else: designing verifiable instructions — the kind you would give anyone on the team — and testing them before they touch a deliverable.
What prompt engineering is (without the course)
In practice, prompt engineering is writing instructions so the model generates more consistently what you asked for. It does not guarantee bit-for-bit identity between runs. The output is non-deterministic by default: it can vary even when the request is the same. That is developed in the piece on the LLM’s role.
A good office prompt usually includes:
- A bounded role (what it is and what it is not).
- Clear delimiters (what is data, what is the request, what is an example).
- The minimum necessary context (not the whole project “just in case”).
- An output format (sections, units, what to mark as assumption).
- Examples of right and wrong when the risk justifies them.
- Rejection criteria: when it must say “I cannot” instead of inventing.
That is not a spell. It is an incomplete procedure until you version it and run it more than once.
Vague orders versus clear orders
Illustration — a desktop demo, not a client case.
Request A: “Write this memo better.”
Request B: the same brief with role, delimiters, a checklist (assumptions, loads, units, warnings), and the rule “do not invent engine results; if they are missing, ask.”
You run B twice. The second does not match the first completely. That is not a failure of your prompt: it is the nature of the model. That is why a prompt that worked once is not office procedure.
If the second run changes a number you thought was “closed,” do not paste it. Ask for engine evidence or treat the text as a drafting draft, not as a calculation.
The difference between A and B is not “more magic tokens.” It is the same difference as a vague email and a work order a principal can review.
User prompt versus system policy
Persistent policy — the system prompt / instructions / rules — says how the assistant should always behave: role, units, prohibitions, when to stop. That is company level.
The user prompt — the request — says what work has to be done now: today’s frame, the fragment to rewrite, the annexes.
Prompt engineering does not replace that policy. It uses it. If you mix everything in one message, you are designing a work order that dilutes itself. If you separate policy (system) and request (user), you are designing as a practice does: the quality manual is not rewritten on every task; the day’s order is.
A harness without clear prompts is a workshop with hands and no contract. Clear prompts without a harness are contracts nobody executes or checks.
A practical office checklist
In instructions / system (persistent)
What should not change with every frame: role, units, prohibitions, base format, when to stop. See the system prompt.
In the request (user)
Today’s deliverable, the data, the fragment to rewrite, the annexes. Explicit scope. Explicit deliverable.
Before you paste it into the report
- Save the prompt with a version (date + change).
- Run it at least twice with the same input.
- Note what changed: tone, structure, assumptions, numbers.
- Define which differences are acceptable and which stop the flow.
- If there is a critical number, demand a tool/engine or refuse the paste.
- Mark assumptions versus facts in the output.
- If you cannot say which file or engine backs a number, do not sign it.
Reproducibility aids in some APIs (seeds, snapshots) can reduce variety; they do not turn the chat into ETABS. They are software aids, not a solver substitute.
Immediate action (under 15 minutes)
Take one prompt you already use in the office.
- Add a role.
- Separate data and request with delimiters.
- Add a short example of acceptable output.
- Run it twice.
- Mark what changed.
- Do not paste it into the report yet.
If it did not survive two runs with acceptable differences, it is not procedure: it is a draft.
Relation to neighbouring pieces
- The system prompt answers where persistent rules live.
- The LLM’s role answers why two runs can differ even when the request is identical.
- The harness answers who executes, checks, and asks for a signature.
Conclusion
You wrote “better” and pasted it into the report. That is the scene this article wants to cut.
A prompt that worked once is not a procedure. Prompt engineering in civil engineering is designing verifiable instructions — the kind you would give an engineer in the office — versioning them and testing them, knowing the model is not deterministic and that a serious number comes from an engine, not from a lucky sentence. They are not tricks. They are work orders.
Sources
- OpenAI — Prompt engineering (official guide: instructions, structure, and good practice).
Evaluation and limitations
Treat the notes below as evaluation context, not as a verified calculation or code check.
Version prompts as work orders. If the result changes without the data changing, do not treat it as a reproduced calculation.