Learning design

Learning design

The course uses realistic engineering work to develop judgment. Participants make decisions, see the results and explain the evidence behind their choices.

Design principles

Connect every exercise to the course architecture

Every exercise must advance at least one course goal and support at least one Workbench stage. Record both links in the exercise design before developing instructions or materials.

Each exercise definition must include:

• The course goal or goals it advances
• The Workbench stage or stages it supports
• The action the participant will perform
• The evidence the action will produce
• The feedback the participant will receive
• The way the skill will appear again later in the course or at work

Remove an exercise if it does not support a goal, a Workbench stage and an observable result.

Start with a consequential problem

Open with a system that appears to work. Its tests pass, but one retrieval path triggers a second billable call. Ask participants to predict the cause and likely effect before they inspect the implementation.

The opening gives the cohort a common experience. It also shows why passing tests do not prove that the software meets the requirement.

Ask for a decision before showing the answer

Participants should make a prediction before they run a test, open a hint or ask an AI agent to investigate. The facilitator records the range of answers, then returns to them when evidence becomes available.

This pattern makes differences in intuition visible. The discussion that follows helps the cohort form a shared understanding.

Move between instruction and practice

Keep explanations short. After a concept is introduced, participants use it in the repository. A typical cycle is:

1. Encounter a problem.
2. Predict what will happen.
3. Gather evidence.
4. Make or review a change.
5. Explain the decision.
6. Apply the lesson to a different case.

Make AI output reviewable

Each AI-assisted step must produce something a person can inspect, such as a specification, plan, test, diff or validation report. Participants should never treat a successful command as proof that the work is correct.

Give feedback at the point of action

Use specification checks, failing tests, architecture rules, contract tests and security gates to provide immediate feedback. Each failure should state what failed and what evidence the participant should inspect next.

Preserve learner choice

The course should define the problem and constraints without prescribing every step. Offer progressive hints instead of one complete prompt:

• Hint 1 identifies the type of problem.
• Hint 2 identifies the relevant boundary or artifact.
• Hint 3 identifies a specific file or test condition.

Participants should be able to compare valid approaches and explain why they chose one.

End with transfer

The final exercise should use an unfamiliar defect or requirement. Participants complete it without the prompts used in the guided lab. This exercise shows whether they can use the workflow on their own.

Learning sequence

Phase	Participant action	Course goal	Evidence
Establish a baseline	Review a scenario and make an independent prediction	Standardize intuition	Initial response and rationale
Build shared context	Separate verified facts, supplied claims and unknowns	Standardize intuition and language	Context audit
Define the work	Convert requirements into testable acceptance criteria	Standardize language	Validated specification
Plan the change	Divide work by system boundary and dependency	Standardize language and behavior	Ordered issue set
Build with evidence	Write a failing test, make the change and rerun the test	Establish behavior change	Test and implementation history
Review independently	Compare the change with the specification in fresh context	Establish behavior change	Findings and dispositions
Transfer the method	Complete a related problem without scripted prompts	All three goals	Independent performance

Workbench process coverage

The exercises should follow the Workbench process in order while allowing participants to return to an earlier stage when evidence requires it.

Workbench stage	Course emphasis	Required participant behavior
Define	Establish intent, context, constraints and acceptance criteria	Identify unknowns and make important requirements testable.
Plan	Bound and order the work	Respect ownership, dependencies and repository boundaries.
Execute	Implement the authorized plan	Produce evidence while making the smallest justified change.
Judge	Evaluate the result independently	Compare claims with requirements and disposition findings.
Learn	Retain outcomes and improve the next cycle	Record what happened, what changed and what should be reused.

The full course must cover all five stages. An individual exercise may support one or more stages, but it must state which ones.

Facilitator responsibilities

The facilitator should:

• Ask participants to commit to an answer before group discussion.
• Ask for evidence when a participant or AI agent makes a claim.
• Use the agreed vocabulary and correct inconsistent usage.
• Delay hints long enough for participants to investigate.
• Discuss differences in reasoning along with the correct answer.
• Record common mistakes for the follow-up exercise.

Participation standard

Running the commands is not enough. Each participant must make at least one prediction, produce or revise one artifact, explain one decision and complete the transfer exercise.