Mental Model — จากเขียนทุกทางเลือกสู่ออกแบบการตัดสินใจFrom Writing Every Branch to Engineering Decisions

1. The engineering problem

Prerequisites: basic functions, dictionaries and tests; Python 3.11+ and Git. Offline labs need no model account. Read the chapter, run its lab, and record the outcome in section 5.

A conventional program contains branches whose conditions a programmer can inspect. An AI workflow introduces a component whose interpretation of language is learned. The engineering problem is deciding where that interpretation is useful and which consequences remain governed by ordinary code. Replacing every if statement with a model call adds uncertainty to problems that already have exact answers. Keep arithmetic, authorization and explicit state transitions in code; use models where the input really needs interpretation.

Our running project is Patch Workbench: take a software issue, choose a reviewed skill, produce a candidate pricing function, validate it, assess its explanation, and return a draft for a maintainer. The requirement is deliberately small: discount_cents(price, percent) uses integer cents and rounds down. At 1,999 cents and 25 percent, the required result is 1,499 cents. A candidate that returns price minus percent is valid Python but solves the wrong problem. This one counterexample will travel through the course.

2. The boundary to design

Use four precise names. A function transforms explicit values. A skill packages reviewed instructions and resources for a task. Jev supplies typed judgments about supplied state; a generative model supplies proposed code or prose. AI-Core is the architectural question of how much deployed work depends on model decisions and how much authority those decisions hold. Coding a deterministic service with an AI assistant does not by itself make that service AI-Core. This tutorial's draft-only tool is a bounded example for studying those responsibilities, not an empirical claim of model indispensability.

3. Read the implementation

Implementation excerpt from the companion. Run the complete lesson below with its imports and fixtures.

from workbench.runtime import candidate
from workbench.core import output_check, behavior_check

# Familiar deterministic implementation
def discount_cents(price, percent):
    return price * (100 - percent) // 100

assert discount_cents(1999, 25) == 1499

# A plausible generated proposal still needs independent checks
proposal = candidate("def discount_cents(price, percent):\n    return price - percent\n")
print(output_check(proposal).state)    # pass: permitted shape
print(behavior_check(proposal).state)  # revise: wrong behavior

Start by writing a success contract: supported issue, authorized repository, allowed candidate language, correct observed behavior, useful explanation, and no external effect. The last condition is intentional: accepted_draft means ready for human review. It does not mean merged, deployed, or proven correct for every input. Anthropic's workflow/agent distinction supports choosing a fixed code path for this task [1]. Our decision to start with a narrow draft boundary is a course design choice. We will earn additional complexity only when a concrete failure makes it necessary.

4. Compare the outcomes

The following output comes from scripted fixtures that verify architecture behavior. It is not a measurement of live Jev accuracy, latency, or cost.

{
  "old_way": "returns a source string",
  "new_way": "review",
  "lesson": "A string is a proposal, not task success."
}

5. Run, break, and explain

Part 01 code · Implementation · Tests: test_shape_does_not_imply_behavior · Exercise

git clone https://github.com/Anirach/ai-core-engineering-workbench.git
cd ai-core-engineering-workbench
git checkout 18cdfcd4156d3d02acb8badf3b3a0a823113e0ed
python3 -m workbench.lesson 1
python3 -m unittest tests.test_boundaries.BoundaryTests.test_shape_does_not_imply_behavior -v

Your turn

Write a success contract for one feature you currently implement by hand. List three exact rules and one judgment that needs a model.

Keep three artifacts: the input you tried, the resulting state and reason, and an explanation of which boundary owns that result. Do not change an expected result merely to make a test pass.

6. Sources and limits