Chapter 8: The Three Disciplines and One Supplementary Principle

Adapted public course. Concepts, procedures and examples are adapted from the internal textbook. Case sizes, timings, improvement figures and target thresholds are illustrative, not site delivery results or universal standards. Verify tools, platforms and skills in your environment. Prompts do not grant permissions and retry counts do not authorize recovery. Preserve work and verify targets, sharing and external-state effects first.

Lesson explanation

Above the six-step methodology, there are three disciplines that apply throughout. Violating any one of them can cause the project to spiral out of control.

8.1 No Blueprint, No Start

Do not let AI write code without an architecture design.

Why? The information available in a new session depends on the context the system actually supplies; a model cannot be assumed to know omitted project constraints. Without a blueprint it fills gaps in technology, naming and data structures from current input, and different contexts can produce inconsistent choices. User management may adopt one naming convention while order management adopts another, creating conflicting data models.

These few minutes of design can save you hours of rework later (order-of-magnitude example; actual figures vary by project).

8.2 No Validation, No Commit

Do not commit AI-generated code without validation.

Why? Because AI has a “self-consistency trap” — the code it generates looks “correct” on the surface, but may contain logic errors, missing edge cases, or security vulnerabilities. Functional tests only check “did registration succeed,” not “is the password encrypted.” If you commit unvalidated code, these hidden issues become a permanent part of the codebase.

AI self-review can add another inspection pass, but review by the same model is not independent evidence. Run executable checks and have an authorized person verify architecture, security and business boundaries.

8.3 When Chaos Emerges, Rebuild

If you find that AI’s code has drifted far from the blueprint, or that patches are making things messier, roll back and start over decisively.

Why? Because the cost of fixing may exceed the cost of rebuilding. Section 7.5 provides the teaching calculation and applicability boundary, including protection of work and verification costs.

Rolling back is not shameful; patching on top of a broken foundation is.

8.4 Supplementary Principle: No Terminology, No Discussion

Before discussing technical solutions, align on core domain terminology first.

This is not a discipline — violating it will not cause the project to spiral — but it dramatically improves communication efficiency. Ambiguous terminology means the architecture is ambiguous from the start: an “order” can mean a purchase request, a paid transaction, or a fulfillment work order in sales, finance, and warehouse contexts, leading to different data models, state machines, and API designs. Chapter 12 explains how to record such divergence in a glossary.

8.5 The Reasoning Chain Behind Each Discipline (Understanding “Why” Matters More Than Memorizing “What”)

The three disciplines seem simple, but each has a complete reasoning chain behind it. Understanding these chains matters more than memorizing the disciplines themselves.

Discipline 1: No Blueprint, No Start.

• Reasoning chain: project constraints are absent from the current context -> the model fills gaps from supplied information -> different contexts may produce different conventions -> features conflict -> rework and risk increase.
• Key insight: The blueprint is not documentation — it is a “constraint engine.” It compresses AI’s possibility space from “infinite” down to “within your project’s scope.” When the blueprint specifies “use Prisma ORM, camelCase naming, unified AppException error handling,” AI will follow these conventions no matter how many conversations it starts, because every time it reads the blueprint, these “rules” are fixed.
• Implication: The blueprint should cover the critical constraints needed by the current task, remain accurate and be easy to retrieve. It need not describe the whole system, but uncovered items must be marked unknown and trigger confirmation.

Discipline 2: No Validation, No Commit.

• Reasoning chain: fluent code may still contain syntax, logic, architecture or security defects -> one happy-path test proves only limited behavior -> unchecked risk enters the codebase -> later work depends on it.
• Key insight: A typical scenario — you ask AI to implement user registration, the test passes, registration and login work, you commit the code. But a month later you discover passwords are stored in plaintext — because functional tests only checked “registration succeeded,” not “is the password encrypted.” The “self-consistency trap” means: AI will make itself appear “correct” even when the underlying logic is wrong. It won’t proactively tell you “I stored passwords in plaintext” because it considers “it runs” as “it’s done.”
• Implication: Validation must check declared functional, architecture and security criteria, not only whether one path runs. These checks complement one another but do not guarantee that every hidden issue is found (see Chapter 9).

Discipline 3: When Chaos Emerges, Rebuild.

• Reasoning chain: Generation may be cheap, but protecting work, understanding, and verification still cost effort -> compare total repair/rebuild costs for tangled code -> when a verifiable recovery point exists and rebuilding is preferable, recover per Section 10.4 and regenerate with more precise instructions.
• Key insight: Section 7.5 gives the complete teaching calculation; it supports comparing the total cost of fixing and rebuilding in chaotic code, not rebuilding every problem.
• Implication: Use Chapter 9’s acceptance decision tree for rebuild signals and the final branch decision.

---

Independent exercise

Use fictional or authorized deidentified material. Answer independently before revealing the reference. Save chapter-08.md with versions, decisions, evidence and gaps.

Write action cards for a missing blueprint, failed checks and conflicting context: continue or stop, what to preserve, and who confirms.

Required chapter artifact: three-disciplines checklist

The submission for this independent exercise must contain the evidence below. The existing prompts supply content but do not replace these acceptance items.

• O1: The three-disciplines checklist orders goal constraints, acceptance discipline and recovery boundary by dependency
• O2: Every layer in the three-disciplines checklist states its input, completion rule and reviewable evidence
• O3: The artifact identifies the first missing discipline and repair order for one uncontrolled task

Reveal reference feedback (answer first)

Reference feedback

Establish scope and contracts before coding, record failed checks before repairs, and preserve work while reconciling context. Repeated failure triggers diagnosis, not permission to erase a project. Verify recovery targets, sharing and external state first.

Self-review and next steps

Check whether your decision is explicit, evidence reproducible and unknowns honestly recorded. The reference illustrates one defensible approach, not a unique answer. Seek peer review for alternatives with equivalent evidence. Mark unsupported parts unfinished and revisit the corresponding step.