AI Builder Readiness test

Toward the high end, people tend to give a tool the context behind a task, the limits it must work within and the shape of the answer they expect, such as a table, a short list or a function with a given name. Toward the low end, people tend to send a short or partial request and expect the tool to fill in the rest. That is quick for exploring, but on a defined task the answer can miss what was meant and take several more rounds to put right.

Asks in shorthand

You often send a short request and leave the tool to work out the rest, which is quick to write but can leave you redoing answers that missed the point.

This week, add one line to each important request saying what shape the answer should take, such as a table, a list or a named function.

Briefs some requests

You set out context, limits and the shape of the answer on some requests, and send others short, with gaps for the tool to fill.

This week, notice which of context, limits or answer shape you most often leave out, and add it to every request that matters.

Spells it out

You tend to set out the context, the limits and the shape of the answer you expect before the tool starts, which takes longer to write and can rule out an approach you had not considered.

Once this week, send a deliberately open request for an early idea and compare it with what your full brief produces.

Toward the high end, people tend to place a tool's output inside a clear process: they know what it feeds into, who picks it up and what happens after that. Toward the low end, people tend to ask for a draft, an image or a snippet on its own, without deciding where it goes next. That suits trying ideas quickly, but useful output can sit unused in a chat history or need reworking before it fits the next step.

Works in one-offs

You often ask a tool for a stand-alone output and leave its next step for later, which keeps you free to explore but can leave useful work unused.

This week, before you ask for an output, write one line on where it will go next and who will use it.

Plans some hand-offs

Some of your output goes straight into a clear next step with someone to pick it up, and some stays a one-off that you decide about later.

This week, pick one task you repeat, write down its steps, and mark which step the tool does and who takes its output next.

Maps where it goes

You tend to fit output into a clear process, knowing which step it feeds and who picks it up, which keeps work joined up but can feel heavy for a quick question.

This week, let one quick question stay a one-off, and note afterwards whether planning its next step would have changed anything.

Toward the high end, people tend to check important output before they use it: they look up the source behind a claim, test how code or an automation behaves, and ask whether the result fits the job and what could go wrong. Toward the low end, people tend to accept output that reads fluently and carry on. That keeps drafts and other easily undone work moving, but a confident mistake can travel into code, figures or decisions that other people build on.

Takes it on trust

You often use output that reads well before checking its source or how it behaves, so work moves quickly and mistakes can surface later, sometimes for someone else.

This week, before you use one important answer, check one claim against its source or run the code once and watch what it does.

Spot-checks the output

You check important output some of the time, and a fluent, confident answer can still pass without a closer look.

This week, write a short checklist for one kind of output you use often, such as figures, links or code, and run through it every time.

Verifies before use

You tend to check sources and test behaviour before you rely on output, which catches errors early but can slow work where a mistake would cost little.

This week, give low-risk drafts a quick read only, and keep your full check for output that ships or that other people rely on.