The 7 levels of AI use. You're probably at level 2.

Everyone starts at the bottom of the same staircase: ask a question, get a general answer, decide AI is overrated. That is not AI being bad. That is level 1. Here is the whole climb, with a real copy-paste prompt for every step.

I spent my first year on level 2. Nobody told me there were seven.

Most architects and project managers I meet live on the same two steps. They paste a clause, get a decent answer, and stop. It works, so they never look up the staircase to see what the next step would have given them.

So this is the full climb, in plain English. Each level is one concrete habit, with what it does, when to reach for it, a prompt you can paste today, and the single mistake that quietly wastes it. Nobody jumps from 1 to 7. The climb is the point.

Level 01Ask it a question

Like using a search engine with better manners. General question in, general answer out.

This is where everyone starts, and where most people quit. You ask a general question, you get a general answer, and it feels no better than a web search. Because at this level, it isn't. You've told it nothing about your job, so it can only give you the average of everyone else's.

Use it for: a definition, a first orientation on an unfamiliar topic, a quick "what am I missing" before you go deeper.

Explain [topic, e.g. what a superintendent does under AS 4000] in plain
English, for someone who knows construction but not this specific area.

Give me the short version first, then three things people commonly get
wrong about it. Australian English.

The one mistake: judging the whole tool from this step. A general answer to a general question is exactly what you asked for. The value is on the steps above, once you start handing over the actual job.

Level 02Give it your context

Like briefing a sharp new starter properly, instead of asking them to guess.

This is where most people live, and it is a genuinely useful place to be. Stop asking about the topic in general and paste the actual thing: the real clause, the real brief, the real room schedule. The answer stops being generic the instant it has your specifics in front of it.

Use it for: decoding a specific clause, summarising a long email chain, turning scribbled site notes into clean minutes, sanity-checking a program you actually have.

I need help with a real piece of work, not a general answer.

Here is the actual material:
[PASTE the real clause / brief / email chain / room schedule]

Context: [one line: what project, what stage, what I'm trying to decide]

Do this:
1. Tell me what it actually says, in plain English.
2. Flag anything ambiguous, missing, or that I should push back on.
3. Give me one clear recommended next step.
Australian English. No filler.

The one mistake: a fresh chat for every question. Stay in one thread for a piece of work. It sharpens the more of the problem it holds at once, and starting over throws all of that away.

Level 03Give it your format

Like handing over a worked example and saying: this is good, now do the next one.

Now it knows the job. Next, teach it your voice. Attach a proposal, a report, or a letter you were genuinely happy with, and say match this. From here on it sounds like your practice, not like a chatbot, because it is copying your work, not the internet's.

Use it for: fee proposals, cover letters, client updates, award submissions, anything that should read like it came from your office.

Here is a piece of writing from my practice that I was happy with. Study
its structure, tone, and level of detail:
[PASTE the past proposal / letter / report you like]

Now write the equivalent for this new job:
[PASTE the new brief / facts]

Match the voice and structure of the example, not a generic template.
Keep every claim to something the facts support. Flag anything you had
to assume. Australian English.

The one mistake: giving it an example you don't actually rate. It will faithfully copy the padding and the hedging too. Feed it your best work, not your most recent.

Level 04Make it argue with you

Like the one colleague brave enough to tell you the fee is too low before the client does.

By default it wants to agree with you. That makes it a poor sounding board and a dangerous one. So turn it around: tell it to attack the fee, the program, the number you're quietly unsure about. An answer that just agrees with you is worth nothing. An answer that finds the hole is worth the whole session.

Use it for: pressure-testing a fee before it goes out, stress-testing a program, finding the weak assumption in a feasibility, rehearsing the questions a client or assessor will ask.

Your job is to disagree with me, not reassure me.

Here is my [fee / program / feasibility / decision]:
[PASTE it]

Do this:
1. Give me the three strongest reasons this is wrong, thin, or risky.
2. Name the single assumption that, if it fails, breaks the whole thing.
3. Ask me the questions a sharp client or assessor would ask that I
   probably can't answer yet.
Be blunt. Do not soften it. I would rather hear it from you than them.

The one mistake: arguing back to win. You are not here to defend the number, you are here to find out if it holds. If it lands a hit, that's the session paying for itself.

Level 05Give it your tools

Like a grad who can finally open the drawing set and the folder, not just talk about them.

Up to here it has only ever talked. This is where it stops talking and starts working. You let it open the actual files, the drawing set, the model, the folder, and it does the work on your own material. Not advice about the claim. The claim, drafted off the six PDFs.

Use it for: a progress claim off subcontractor PDFs, updating the control document, cross-checking a QS assessment, pulling the monthly board pack out of the project folder.

[Point it at your project folder, then:]

Compile this month's progress claim.

Read the subcontractor claims in [/folder], match each to the approved
schedule of values, work out this month's certified amount, flag any
line that's over or missing backup, and draft the payment schedule plus
a one-paragraph summary for the PCG.

Tell me what you did, not how. Hand it back for me to check before
anything is sent.

The one mistake: describing keystrokes instead of the result. Say "reconcile these claims into the cashflow", not "open file A, copy column B into file C". You are the judgment; it is the hands. Steer the outcome.

Level 06Write the workflow down

Like your office SOP, taught once, then run the same way every time, whoever presses go.

The first five levels you do by hand each time. This one you bottle. Once a job runs well, write it down as a Skill: a short file that captures how your practice does it. From then on the fee proposal, the submittal log, the monthly report runs the same way every time, and you stop re-explaining yourself.

Use it for: anything you do the same way month after month: progress certificates, meeting minutes, cost plans, monthly reports.

Help me turn a task I repeat into a reusable Skill.

The task: [e.g. writing the monthly progress report for a project]

Do this:
1. Ask me the five questions you need to understand exactly how I do it.
2. Then write it up as a step-by-step procedure: what to read, what to
   produce, the format, the tone, and what to check before handing back.
3. Short enough to reuse, specific enough to trust.

The one mistake: writing the Skill before the job runs well by hand. Bottle a good run, not a guess. If you can't do it cleanly once yourself, there is nothing worth saving yet.

Level 07Let it run without you

Like handing a trusted colleague a defined job and reviewing it when it lands, not watching over their shoulder.

The top step. You brief it once, it works, and the job comes back finished for you to review. This only works because of every step below it: it has your context, your format, your tools, and a written-down workflow to follow. Skip those and level 7 done badly is just a wrong answer arriving faster.

Use it for: defined, repeatable jobs with a clear finish line and a check at the end: the monthly report run, the register update, the first draft of a recurring deliverable.

Run this job end to end, using the Skill we wrote for it.

The job: [e.g. this month's progress report for [project]]
The inputs: [point to the folder / files it should read]

Work through it without checking in at every step. When it's done, hand
me: the finished draft, a short list of every assumption you made, and
anything you couldn't resolve and left for me. I'll review before it
goes anywhere.

The one mistake: trusting the output because it arrived finished. Finished is not the same as right. Every number it hands you still gets checked by you, the same as you'd check a grad's first draft.

Nobody jumps from 1 to 7. Find your step, then do the one above it this week. The climb is the point.

Where the staircase ends

Here is the honest part, because a guide that only sells the climb is lying to you.

No level on this staircase reads your site. None of them knows your planning scheme, feels the room in a client meeting, or defends a decision under questioning in a design review. Level 7 done badly is just a wrong answer arriving faster, and the higher you climb the more convincing a wrong answer looks.

So the check never leaves you. Every number gets verified. Every assumption gets labelled so it can be challenged, not inherited. The staircase gets you to the judgment faster. It does not make the judgment.

The tool changes at every level. The judgement stays yours the whole way up.