Claude Architect · Aula

Decisões Orientadas pelo Modelo vs Codificadas

Deixe o modelo decidir; reserve o código para as garantias.

Decisões Orientadas pelo Modelo vs Codificadas é uma aula grátis de Claude Architect no CoddyKit. Esta é a aula 2 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Claude Architect, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Claude Architect inclui 4 aulas no total.

Partes desta aula ainda não foram traduzidas e aparecem em inglês.

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.

Perguntas Frequentes

A aula “Decisões Orientadas pelo Modelo vs Codificadas” é grátis?

Sim — o texto completo de “Decisões Orientadas pelo Modelo vs Codificadas” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Claude Architect, atualize para CoddyKit PRO. O curso de Claude Architect inclui 4 aulas no total.

O que vou aprender em “Decisões Orientadas pelo Modelo vs Codificadas”?

Deixe o modelo decidir; reserve o código para as garantias. Você pratica Claude Architect com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Claude Architect?

Nenhuma experiência prévia é necessária. Claude Architect no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 2 de 4.

Quanto tempo leva a aula “Decisões Orientadas pelo Modelo vs Codificadas”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Claude Architect?

Sim. Cada aula de Claude Architect inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

O Que Torna um Sistema Agentivo
Decisões Orientadas pelo Modelo vs Codificadas
Quando Usar um Agente
Visão Geral do Ciclo Agentivo

← Voltar para Claude Architect