Building a no-code AI prototype.

Goal

Build a reusable AI assistant for one task without code, test it on ten prepared cases, and make a go or no-go decision on the evidence.

Who it is for

Operations staff, team leads and owners in New Zealand businesses with an AI idea and no developer on hand.

Time

40 minutes.

You need

A business account for ChatGPT, Claude, Gemini or Microsoft Copilot, and the fictional material below.

You will produce

A working prototype, a ten-case scorecard and a written decision.

What is a no-code AI prototype?

A no-code AI prototype is a saved assistant: standing instructions plus a few reference files, set up once inside a chat tool and reused for one task. It answers a single question cheaply: is the AI good enough at this task to be worth building properly? It is not a production system. It has no integrations, no logs and usually one owner’s account behind it.

Which task makes a good first prototype?

Pick a task with three properties: it happens often enough to matter, each input has a right answer you can recognise, and a mistake is caught before it reaches a customer. Triage, classification, first drafts and checklists fit well. Tasks that need live data from your systems, a judgement only one senior person can make, or that end in a payment or legal commitment are poor first choices.

If you cannot write ten test cases with expected answers in fifteen minutes, the task is not clear enough yet. Our lesson on writing a workflow specification helps sharpen it.

Where can you build one?

Each major assistant has a feature for this. As listed on 19 October 2026:

If your plan has none of these, paste the instructions at the top of a new chat each time. The test method is the same.

Exercise: build and test a triage assistant

The cleaning company, standards and messages below are fictional.

Illustrative material. Fictional commercial cleaning company,
Christchurch.

INSTRUCTIONS FOR THE ASSISTANT
You triage messages from client site managers. For each message:
1. Category: missed clean / consumables / damage / safety hazard /
   access / out of scope.
2. Urgency: same day / next visit / office follow-up.
3. Draft a two-sentence acknowledgement in New Zealand English.
Use the service standards file. Safety hazards are always same
day and must say a supervisor will call. Never promise refunds,
credits or contract changes; say the account manager will be in
touch.

SERVICE STANDARDS (reference file)
- Missed areas re-cleaned at next scheduled visit, or same day
  for food preparation areas.
- Consumables restocked within one working day.
- Damage reported to the account manager within 24 hours.
- Hazards (sharps, spills, broken glass, chemical smells):
  supervisor attends the same day.

TEST MESSAGES
M1 Bathroom bins on level 2 weren't emptied last night.
M2 We're out of paper towels in the staff kitchen.
M3 Your cleaner chipped the reception desk with the vacuum.
M4 Found a used needle in the ground floor toilets.
M5 Kitchen benches weren't wiped. We prepare food there.
M6 New door code from Monday is 4471.
M7 Can you send last month's invoice again?
M8 This is the third missed clean. We want a credit or we'll
   cancel the contract.
M9 Strong bleach smell in the stairwell after your team left.
M10 Kia ora, the mop bucket was left in the lift lobby again.

1. Set the pass mark first. For example: M4 and M9 both categorised as safety and same day, no promise of credits in M8, and at least 8 of 10 categories correct.
2. Build the assistant. Create a GPT or Project, Claude Project, Gemini skill or Copilot agent. Paste the instructions and upload the service standards as a file.
3. Run all ten messages one at a time in fresh chats, and record each result.
4. Score every case in a simple table: category right, urgency right, reply acceptable, notes.
5. Revise once. Fix the instructions for the clearest failure, then rerun all ten, not just the failures. Changes often break cases that used to pass.
6. Decide. Go, no-go or narrow the task, with one paragraph explaining why. Note that M6 contains an access code, so check where conversations are stored before real codes go in.

Worked example: scoring an awkward case

This is the prompt for the hardest message, run inside the prototype.

M8 This is the third missed clean. We want a credit or we'll
cancel the contract.

Example output (illustrative and abridged; your tool’s wording will differ):

Category: missed clean (with contract concern)
Urgency: office follow-up
Draft reply: Thanks for letting us know, and sorry this has
happened again. Your account manager will call you today to talk
it through and arrange a re-clean.

Scorecard
M8 | category correct | urgency correct | no credit promised |
reply acceptable | note: flag repeat complaints to manager

A pass on M8 matters more than a pass on M2. Commercial promises and safety calls are where a wrong answer costs money or harms someone, so weight your pass mark toward those cases.

Where this goes wrong

• Testing only easy cases. A prototype that handles paper towels proves little. The awkward three are the test.
• Moving the pass mark. Deciding what “good enough” means after seeing the results is how weak prototypes get approved.
• Personal or secret data in reference files. Door codes, client contacts and staff details in files or chats need a business plan and a reason to be there.
• Prototype treated as production. It lives in one person’s account, has no logs and breaks when they leave. Document it before anyone depends on it.
• Untracked changes. Keep each version of the instructions and its scores together, as our AI prompt library template shows.

Check your work

• I wrote the pass mark before running any test.
• My test set includes at least three awkward cases, including a safety case.
• I scored all ten cases in a table, not from memory.
• After revising the instructions I reran every case.
• My decision is written down with the evidence behind it.
• I know where the tool stores the assistant’s conversations and files.

Where to go next

Next in the pathway: documenting an AI workflow for handover, the step that stops a good prototype depending on one person. For a deeper testing method, see testing a business AI assistant and building your first internal AI tool, and record results in the AI pilot scorecard. The full workflow behind this example is in our guide to site issue triage for cleaning businesses. Engineers growing a test set should read testing AI with synthetic data, and when the idea passes, an AI proof of concept tests it against your real systems.

Written by the Levy Street team in Wellington. Last updated 19 October 2026.