Better Prompts Are the Starting Point, Not the Operating Model

When I joined the Old Dawgs Talk session, the room was split across different levels of AI use, from people still figuring out the basics to people already testing it in real workflows.

That spread mattered. The right first conversation was prompting, not a deep dive into advanced AI tools or company-specific systems, because that is where most teams either build a better habit or stay stuck in random experimentation.

The session framed the issue clearly: there is a difference between what AI can do for one person once and what it can do reliably for a team. If you skip that distinction, every win stays personal. One person figures out a good way to ask. Another person asks the same task differently and gets a different answer. A third person gives up because the output feels inconsistent.

That is why I started where the room was. Before you standardize anything, you need a better way to ask.

Think about your last owner-architect-contractor (OAC) meeting. If two people on the same project gave the AI the same notes, would they define the same assignment, limit it to the same records, and ask for the same output? If that answer is uncertain, the first issue is not the tool. It is whether the work has been defined clearly enough to repeat.

A mixed room needs a shared starting point

One of the most useful parts of the live conversation was hearing how different people's starting points really were. Inside the same company, or even on the same project, you can have one person treating AI like a search box, another treating it like a drafting assistant, and another treating it like a thinking partner. That is a practical problem because people are operating from different assumptions about what the tool is for.

That is also why broad advice to simply use AI more usually does not help. The room I was speaking to did not need another vague permission slip. It needed a shared baseline for how to ask better questions and how to get more dependable outputs from recurring work.

Prompting is the cleanest place to build that baseline.

It is the first place where you can see whether someone is still asking for magic or whether they are starting to define the work clearly. It is also the first place where a team can begin to notice patterns that should eventually become repeatable methods.

So Part 1 really begins there: not with a perfect method, but with the room learning how to stop asking weak questions.

Stop prompting like a search engine

A lot of people still approach AI the way they approach a search engine: type a question, get an answer, move on.

When the request is vague, the AI is left to fill in what you did not define: which records matter, what decision the output should support, and what it must not guess. The result may be too generic to use or polished enough to carry an assumption you never authorized.

That is why I told the room to think about AI less like a search engine and more like a smart intern or smart person who still needs guidance. The setup is the issue.

A better prompt starts by removing ambiguity.

The structure I walked through was simple: role, context, task, format, and constraints.

Role means telling the AI who it is supposed to be for this task. Context means giving it the records and background it needs. Task means being explicit about what it should actually do. Format means defining the shape of the answer you want back. Constraints mean telling it where to stop.

That last piece matters more than people think.

Constraints keep the AI from wandering into answers that sound impressive but do not fit the assignment. If the audience is nontechnical, say that. If it may use only the documents provided, say that. If it must not invent dates, quantities, or commitments, say that. If the output has to stay short enough for a manager to read quickly, say that too.

This is where prompting starts to look less like chatting and more like directing work. The goal is not a cleverer sentence. It is a prompt another project leader can inspect, correct, and use for a defined task without guessing at your intent.

Once people start doing that, the quality gap becomes obvious very quickly.

A prompt you can use after your next OAC meeting

Here is the anatomy applied to work the room already understood. Replace the bracketed fields and attach only the records the AI is allowed to use.

Role: You are a construction project coordinator.

Context: Use only the current OAC notes and previous action log for
[PROJECT] during [REPORTING PERIOD].

Task: Separate confirmed decisions from discussion. Identify open
questions, actions, and anything affecting budget, schedule, or scope.
Before doing the work, restate the assignment in one sentence.

Format:
1. Executive read, 120 words maximum
2. Decisions
3. Open questions
4. Action | Owner | Due date | Project impact | Source
5. Budget, schedule, and scope flags

Constraints: Do not invent owners, dates, dollars, quantities, or
commitments. Use "Not stated" when the source is silent. Show conflicts
instead of resolving them. Do not send messages or update project records.

Before you run it, answer six questions: Which project records are official? What dates does the review cover? Who will read the result? What decision should the output support? Which facts must the AI never guess? Where must it stop and wait for a person?

That quick check is the difference between a prompt that sounds specific and one that stays inside the actual assignment.

Make the AI show its work before it answers

Once the task has clear limits, the next question is whether the AI understood it before the answer carries weight.

That is where several patterns from the session become useful. Each creates a checkpoint where a person can correct the assignment, the approach, or the missing context.

One of my favorites is rephrase and respond. I use it because I want to see whether the AI actually understood the assignment before I trust the answer. I ask the question, the AI restates what it thinks I am asking, and then I judge whether we are aligned before the response carries too much weight.

Restate what you think I am asking, name the source records you will use, and wait for my correction before answering.Copy prompt

Many weak AI interactions do not fail because the technology is incapable. They fail because the AI is confidently solving the wrong problem, and rephrase and respond exposes that early.

The same logic applies to plan first prompting.

Sometimes I do not want the AI rushing into a solution. I want it to explain the steps it plans to take, so I can correct the approach before it starts producing polished output. That is especially useful when the task involves several records, multiple assumptions, or a judgment call about what matters most.

Do not solve this yet. Show the review plan, what you will compare, and where a human decision is required.Copy prompt

Clarifying questions play a similar role.

If the task is complex, the best first move may be for the AI to question me before it answers. Ask what the real priority is. Ask what the limits are. Ask what kind of audience will read the result. Ask what information is missing. That step often does more to improve the final output than another paragraph of instruction written by the user.

Ask me five clarifying questions before you draft the response. Focus on the decision, source authority, missing information, audience, and limits.Copy prompt

What all three of these patterns have in common is simple: they force the work to become clearer before the answer becomes longer.

Before using any of them, ask: What would I need to see in the AI's restatement or plan before I would let it draft? That answer becomes the point where a person decides whether the work should continue.

That is a better habit for construction work, because so much of our work breaks down when the assignment is assumed rather than defined.

Learn from your own best outputs

There is another mistake people make once they get a decent result from AI. They enjoy the answer, but they do not capture how they got there.

That is where reverse prompting becomes useful.

If you have a document, summary, or update that came out well, ask the AI to work backward from it. What role was implied? What information was likely needed? What steps did the answer follow? What prompt or method would reproduce that quality on the next job?

That move turns a lucky outcome into something teachable, and it also helps people who are not yet confident prompt writers.

The same goes for asking the AI to check its own work. You can ask it to identify weaknesses, revise the answer, and explain what changed. You can also take the output to another AI tool, ask for criticism, and bring that criticism back into the original conversation.

That raises the quality of the work without requiring the user to be the only reviewer in the loop, and it reveals where your instructions were still too loose.

This is also why I do not think prompting should be treated as a collection of isolated tricks. These patterns are more useful when they start stacking together.

A good prompt may define the role, context, task, format, and constraints. Then it may ask the AI to restate the question. Then it may require a plan before execution and a critique at the end.

Once that starts happening consistently, you are no longer just chatting with AI. You are building a repeatable way to get work done.

Know when a prompt pattern should become a reusable method

This is where Part 1 hands off to Part 2.

Prompting is the gateway, not the destination. The signal to move beyond prompting is not that you had one good result. The signal is that you keep using a similar chain of prompts for the same kind of task.

When you notice that pattern, run one small, controlled experiment.

Take one recent task where you used multiple prompts to reach a final result. Write down the inputs, constraints, steps, and output shape, then run the method twice on comparable work. Compare what held steady and what still depended on your judgment.

If the method does not hold up, keep improving the prompt. If it does, decide whether the pattern belongs in your personal toolkit or is ready to become a saved method the team can reuse. Part 2 goes deeper into that choice.

If you test it and want to compare notes, I am always interested in hearing what held up and what did not.