A lot of failed AI work is really failed delegation.

A lot of failed AI work is really failed delegation.

Not because the model was too weak. Because we handed it the wrong kind of job.

We do this constantly. We want judgment, so we write a checklist. We want taste, so we encode heuristics. We want reliability, so we ask the model to “be careful.” Then we act surprised when the system is both brittle and slippery.

The better pattern is almost the opposite:

Give the model the judgment problem.
Give deterministic code the truth problem.
Do not confuse the two.

In this build, the breakthrough wasn’t a cleverer prompt. It was moving from “find these types of quotes” to “find anything worth building a social post around.” That sounds less precise, but it is actually more honest. Interestingness is not a regex. Taste is not a CSS selector. The model is better at judging which passages have tension, consequence, or social gravity than a pile of rules pretending to know.

But the system only worked because we were strict about the other half.

The model did not return copied text. It returned references: stable IDs from a denoised DOM. The actual text, HTML, screenshot, and validation all came from the same source bytes.

That distinction matters.

The model was allowed to judge.
It was not allowed to become the source of truth.

This is the pattern I keep seeing in serious AI systems. The value is rarely in “using AI” more. It is in deciding where AI belongs and where it absolutely does not.

Use the model where ambiguity is the work: selection, synthesis, prioritisation, framing, interpretation.

Use code where drift is unacceptable: identity, permissions, audit trails, calculations, extraction, validation, versioning, provenance.

Most organisations get this backwards. They build committees and rules around the parts that need judgment, then rely on prompt discipline for the parts that need architecture.

That is how you get fragile AI: too much prescription where you need taste, too much trust where you need rails.

The interesting implication is that “prompt engineering” is too small a frame. The real craft is boundary design.

Where does judgment live?
Where does truth live?
Where can the model improvise?
Where must the system be unable to drift?

Those questions matter far more than whether the instruction is beautifully worded.

A checklist can make a model obedient.

A north star, with the right rails around it, can make it useful.

Learn more: https://leverageai.com.au/wp-content/media/articles/66-text-is-the-models-home-turf.html

Originally posted on LinkedIn