Claude Architect · Lesson

Model-Driven vs Hard-Coded Decisions

Let the model decide; reserve code for guarantees.

Model-Driven vs Hard-Coded Decisions is a free Claude Architect lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Claude Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Two Ways to Decide

Every agent you build has to make decisions. Who makes them is the design choice.

There are two options:

Model-driven: Claude looks at the situation and chooses the next step.
Hard-coded: your code forces the step, no matter what.

The rule for the exam: let the model decide, and reserve hard code for guarantees you cannot afford to get wrong.

Why the Model Should Drive

Real tasks are open-ended. The order of steps is not known in advance.

A customer message might need one lookup, or three. A research task might branch in ways you cannot predict. Claude reads the live context every turn and adapts.

If you hard-code the path, you freeze the agent into one rigid script. It breaks the moment reality differs from your plan. So the default is: give Claude tools and let it choose.

The Agentic Loop

Here is the model-driven loop. You send the full message history every turn (the model keeps no state). Then you inspect stop_reason:

tool_use → run the tool, append the result, loop again.
end_turn → the model is done. Stop.

The model decides what to do; your code just executes and loops.

while True:
    resp = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=16000,
        tools=tools,
        messages=messages,  # FULL history every turn
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason == "end_turn":
        break
    if resp.stop_reason == "tool_use":
        results = run_tools(resp.content)
        messages.append({"role": "user", "content": results})

Stop on the Signal, Not the Words

How do you know the agent is finished? Terminate on stop_reason — never by scanning the text for words like "done" or "finished".

Parsing text for completion signals is a classic anti-pattern. The model might say "I'm done thinking" mid-task, or never say "done" at all. The structured stop_reason is the real, reliable signal.

# WRONG — parsing text for a completion word
if "done" in resp.content[0].text.lower():
    break

# RIGHT — terminate on the structured stop signal
if resp.stop_reason == "end_turn":
    break

Iteration Caps Are a Safety Net

You may add a maximum number of loop iterations. That is fine — but understand its role.

An iteration cap is a safety net that stops a runaway loop. It is never the primary stop mechanism. The primary stop is always stop_reason == "end_turn".

If your agent normally finishes only by hitting the cap, the decision logic is broken — you are hard-coding what should be model-driven.

MAX_TURNS = 20  # safety net only

for turn in range(MAX_TURNS):
    resp = client.messages.create(
        model="claude-opus-4-8", max_tokens=16000,
        tools=tools, messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})
    if resp.stop_reason == "end_turn":
        break  # the REAL exit
    messages.append({"role": "user", "content": run_tools(resp.content)})

When Code Must Guarantee

Now the other half of the rule. Some outcomes are too important to leave to a probabilistic model.

A prompt is roughly 90% reliable — it usually follows instructions, but not always. For rules with financial, legal, or safety consequences, "usually" is not good enough.

For those, you reserve hard code, which is 100% deterministic. This is the one place where you take the decision away from the model.

Hooks Enforce the Hard Limits

The deterministic tool for this is a hook. A hook intercepts an action and can block it before it ever happens — with 100% certainty.

Classic example: "never refund more than $500." You do not write that as a prompt instruction. You write it as an outgoing-call hook that blocks any refund over the limit, every single time.

Hooks for guarantees, prompts for judgment.

# Deterministic policy hook — runs before the refund tool executes
def before_process_refund(tool_input):
    if tool_input["amount"] > 500:
        return {
            "block": True,
            "reason": "Refunds over $500 require human approval.",
        }
    return {"block": False}

Programmatic Preconditions

The same idea applies to preconditions — things that must be true before an action runs.

Example: never process a refund until the customer's identity is verified. Prompt guidance ("please verify identity first") is only ~90% reliable. A programmatic precondition — block process_refund until get_customer returns a verified ID — is a deterministic guarantee.

Code enforces the precondition; the model still decides everything else.

def before_process_refund(tool_input, state):
    # Deterministic precondition: identity must be verified first
    if not state.get("customer_verified"):
        return {"block": True,
                "reason": "Call get_customer and verify identity before refunding."}
    return {"block": False}

Don't Over-Hard-Code

The mistake in the other direction is just as costly: hard-coding decisions that the model should make.

If you wrap every step in branching if/else logic, you have rebuilt a rigid pipeline and thrown away Claude's adaptability. The agent can no longer handle the unexpected case.

Reserve hard code for the narrow set of guarantees — money, law, safety, required preconditions. Everything else stays model-driven.

A Clean Division of Labor

Put it together as a division of labor:

Model decides: which tool to call, in what order, when the task is complete, how to recover from an unexpected result.
Code guarantees: policy ceilings (refund ≤ $500), required preconditions (verified ID), and the loop terminating on stop_reason.

The model drives the trajectory. Code draws the hard boundaries it can never cross.

Fixed Pipelines vs Adaptive

One nuance: not every task is open-ended.

For a known, sequential process, a fixed pipeline (prompt chaining) is fine — the steps really are fixed.
For an open-ended investigation, use adaptive decomposition and let the model choose its path.

So "let the model decide" applies where the path is genuinely uncertain. Where the sequence is truly known, structure is appropriate — just don't force structure onto problems that need adaptability.

Quick Check

A support agent must never issue a refund above $500. Refunds at or below $500 should be handled smoothly within the conversation. What is the architect-grade design?

Key Takeaways

Remember the rule: let the model decide; reserve code for guarantees.

Default to model-driven decisions — Claude adapts to live context.
Drive the agentic loop and terminate on stop_reason, never by parsing text.
Iteration caps are a safety net, not the primary stop.
Use hooks and programmatic preconditions for financial, legal, or safety rules — 100% deterministic vs a prompt's ~90%.
Don't over-hard-code: guarantees are a narrow boundary, not the whole agent.

Frequently asked questions

Is the “Model-Driven vs Hard-Coded Decisions” lesson free?

Yes — the full text of “Model-Driven vs Hard-Coded Decisions” is free to read here on the web, and the Claude Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Claude Architect course, upgrade to CoddyKit PRO.

What will I learn in “Model-Driven vs Hard-Coded Decisions”?

Let the model decide; reserve code for guarantees. You practise Claude Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Claude Architect?

No prior experience is required. Claude Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Model-Driven vs Hard-Coded Decisions” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Claude Architect lesson?

Yes. Every Claude Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Claude Architect