5. AI Product Judgment

Break a complex request into explicit steps rather than one large ambiguous ask. A model asked to "analyze this and write a report" performs less reliably than one walked through: extract the key facts, identify the pattern, then draft the summary.

Showing 2-3 examples of the exact input/output pattern you want is often more effective than describing the pattern in words — the model can pattern-match directly instead of inferring your intent from a description.

State what the model should NOT do as explicitly as what it should. Specify the exact structure expected (JSON, a list, a specific length) rather than assuming the model will infer a reasonable default.

A prompt asking a model to "summarize this document" with no further guidance and getting an inconsistent length and format each time is a prompting gap, not a model limitation — the fix is adding explicit constraints, not switching models.

Unclear instructions, poorly chosen examples, missing hierarchy (which instructions take priority when they conflict), or context that's too long and burying the actual task — each produces a different failure signature.

Change only the examples and re-test, then only the instructions, then only the length. Random full rewrites make it impossible to know what actually fixed — or broke — the output. This mirrors the eval-set discipline from later in this section.

When system, developer, and user instructions conflict, the model has to resolve priority somehow — and if you haven't specified which wins, the resolution is effectively random from your perspective. Being explicit about priority removes that ambiguity.

A prompt that worked well suddenly underperforms after a small edit — isolating exactly what changed, rather than rewriting from scratch, is what finds the actual cause in minutes instead of hours.

Information that changes per-request (a specific customer's account history) should be retrieved dynamically. Information stable across all requests (the system's role, core rules) should be supplied directly. Getting this split wrong means either stale fixed context or unnecessary retrieval overhead.

Irrelevant or excessive context degrades output quality as much as missing context does — a lesson that compounds with RAG later in this section, where retrieving too much is as much a failure mode as retrieving too little.

A system that hardcodes a specific customer's account details directly into every prompt, rather than retrieving them per-request, produces context that goes stale the moment that customer's data changes.

Real, representative inputs — not hand-picked easy cases — paired with a defined standard for what a correct or acceptable output looks like. This is the same discipline Section 6 formalizes for full production evaluation; this lesson is where it starts, at the prompt level.

A prompt change that improves one type of query can silently degrade another. Running the full eval set after every change, not just spot-checking the case you were optimizing for, is what catches these regressions before they reach production.

Spot-checking a single example after a prompt tweak feels fast, but it only tells you about that example — it says nothing about the query types you didn't happen to check.

Embeddings turn text into numerical vectors representing meaning. Chunking splits documents into retrievable pieces. Vector search finds chunks similar in meaning to the query. Reranking reorders retrieved results by relevance before they reach the model.

Hybrid search combines vector similarity with traditional keyword matching, catching cases pure semantic search misses. Grounding means the final answer is actually based on the retrieved content, not just loosely influenced by it — a distinction the next lesson's diagnosis work depends on.

(Sequence / arrow flow)

This is the direct answer to "why doesn't the model know about our internal documents" — it doesn't, unless a retrieval system puts the relevant content in front of it at query time.

Jumping straight to "the model is wrong" and trying a different model wastes time if the actual failure is upstream — in retrieval or chunking. Checking each stage in sequence isolates the real cause instead of guessing at the least likely explanation first.

Ingestion (was the source loaded correctly) → chunking (was information split awkwardly) → retrieval (was the right chunk found) → reranking (was it ranked high enough to be included) → context (did the model see it clearly) → prompting → model.

(Decision tree)

A customer reporting "the answers are wrong" under time pressure is exactly when the temptation to guess is strongest — and exactly when working the chain methodically finds the real cause fastest, a pattern Section 9 revisits under live production pressure.

Prompt engineering fixes instruction clarity. Context engineering fixes what information the model sees. RAG fixes missing external knowledge. Fine-tuning fixes a persistent behavior or style prompting won't reliably follow. Agent architecture fixes the need for multi-step autonomous action.

Prompting → context engineering → RAG → fine-tuning → agents. Each step up costs more in complexity, latency, and maintenance — reaching for a complex lever before ruling out a simple one is the most common overcorrection in this work.

(Sequence / arrow flow)

A team jumping straight to fine-tuning before trying prompt or context improvements is usually solving a problem an inexpensive fix would have handled — worth a direct question before committing to the expensive path.

A schema defines the exact fields and types expected — a JSON object with defined structure, not free-form prose the rest of the system has to parse heuristically.

Even with schema enforcement, a model can occasionally produce invalid output. The workflow needs explicit validation and a defined failure path — retry, fallback, or flag for human review — at this seam, not an assumption that structured output is always perfectly formed.

A downstream system silently breaking on malformed model output is almost always a missing validation step at this seam, not a fundamental flaw in structured output as an approach.

Is the sequence of steps knowable and fixed in advance? If yes, a deterministic workflow — with tool calls where needed — is simpler, more predictable, and easier to debug than an agent. Reach for agent autonomy only when the path genuinely can't be predetermined.

(Decision tree)

An agent given a task that actually has a fixed sequence doesn't just add unnecessary complexity — it adds unpredictable failure modes (unbounded loops, unnecessary tool calls) to a problem that never needed that flexibility in the first place.

When an engineer proposes an agent for a task with a clearly fixed sequence, that's worth a direct question: what part of this actually needs to be decided at runtime, versus already known?

Tools (what the agent can do), memory (what it retains across steps), state (what it currently knows), planning (how it decides next steps), permissions (what it's allowed to do), autonomy level (how much runs without human check-in), and loop handling (what stops it from repeating indefinitely).

You don't need to write the agent framework code. You need to ask whether an unbounded loop is possible, what permissions each tool call carries, and where a human is required to approve — informed questions that catch real risks before they reach production.

A prototype replaces speculation with something people can actually try. Two stakeholders arguing about whether an approach "would feel too slow" resolve the question instantly once they've used a working version — no further argument needed.

The goal isn't production quality — it's a fast, disposable build that answers the specific question in dispute. Narrow scope matters more than completeness here; the prototype's job is to end an argument, not become the shipped product.

Recognizing when a disagreement is actually a "let's just build it and see" situation — rather than continuing a debate that a working example would settle in an afternoon — is a judgment call worth developing deliberately.

Build a rough, disposable prototype that resolves the specific stakeholder disagreement in dispute. Speed and narrow scope over polish — the goal is ending the argument, not shipping the final product.