# Chapter 19: Separating Research, Planning and Implementation

## Lesson objectives

- **O1** Can define the condition for moving from read-only analysis into implementation authority (artifact: execution-authority gate)
  - Evidence: The execution-authority gate states the entry condition from read-only analysis to implementation authority
- **O2** Can construct a execution-authority gate with branches, vetoes and accountable owners (artifact: execution-authority gate)
  - Evidence: The execution-authority gate contains at least one proceed branch, one stop branch and their owners
- **O3** Can separate read-only analysis from authorized implementation and check authority before action (artifact: execution-authority gate)
  - Evidence: The artifact records current authority, allowed actions, forbidden actions and escalation owner for one request

## Learning paths

- **Novice**: Chapter transfer task: Can separate read-only analysis from authorized implementation and check authority before action. Use the diagram's decision relationship to complete the first evidence item in the execution-authority gate, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can separate read-only analysis from authorized implementation and check authority before action. Submit the execution-authority gate, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: execution-authority gate
- **Diagram kind**: plan-before-action
- **Relationship semantics**: Inputs follow conditional branches into an explicit gate; stop and proceed are exclusive, and red-line failures cannot be offset by other scores.
- **Core concepts**: read-only analysis · implementation authority · verify before action

![Chapter 19 teaching diagram for the execution-authority gate](/learning/diagrams/en/chapter-19.svg)

Follow the conditions in the execution-authority gate and make a traceable stop-or-proceed decision at the gate.

The diagram starts with read-only analysis, branches through the conditions in implementation authority, and reaches a gate controlled by verify before action. Every case must end at stop or proceed; missing evidence and red-line failures cannot be offset by other strengths.

> **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

### 19.1 Reduce uncertainty before implementation

We harbor an irresistible fascination with speed. When AI can generate three hundred lines of code for a complex problem in three seconds, that sense of instant gratification is overwhelming -- something like a dopamine-driven reward response. We marvel at its swiftness, and we feel we wield the most powerful productivity tool on earth.

This obsession with speed is the most dangerous and deceptive trap in AI-assisted programming.

A junior engineer, upon receiving a requirement, reflexively starts writing code immediately. A senior engineer or architect, given the same requirement, reflexively responds: "Hold on -- let me think first." He will spend hours or even days researching, sketching diagrams, comparing alternatives, and assessing risks. He knows that before a single character is typed at the keyboard, the outcome of the battle has largely already been decided in the sand-table rehearsal inside his mind.

AI is not an accountable engineer and has no inherent authority over business or production decisions. Depending on its instructions and tools, it may produce code before important requirements are resolved. Process discipline therefore separates analysis, decision and authorized execution, requiring evidence before action rather than assigning a human seniority label to the model.

Let us first dissect where the "just write code" approach goes wrong:

Error One: You get an unclarified candidate, not a validated solution.

When you present a problem without guidance, such as "How do I implement a plugin-based system?", the model can only generate a candidate from supplied context; it cannot access business meaning that has not been provided. The output may resemble common code, tutorials or design patterns, but its exact internal selection process cannot be inferred from the surface answer.

Problem clarification and requirements analysis may therefore be missing. Is the "plugin" a dynamically loaded DLL/SO or a set of configurable JavaScript objects? What security boundary applies? How do plugins communicate? Unless the prompt, tool workflow or human dialogue resolves those questions, there is insufficient evidence that the candidate fits the business context.

Error Two: You sink prematurely into the swamp of implementation detail.

The moment AI produces a first version of the code, your attention is immediately captured by the code itself -- is this variable name well chosen? Can this loop be optimized? This premature fixation on "implementation detail" is a cardinal sin of architecture design: before you have figured out what the "skeleton" of the entire system ought to look like, you are already agonizing over the decorative pattern on a single "brick."

In psychology this is related to the Anchoring Effect: the first version of code AI produces, good or bad, becomes the "anchor" for all your subsequent thinking. You will unconsciously patch and tweak on top of the "anchor" (confirmation bias), and find it hard to step back and consider whether a completely different and better top-level design might exist. Directly writing code amounts to AI proactively dropping an "anchor of thought" for you, trapping both you and itself on a single narrow implementation path.

Error Three: You abdicate your supreme authority as the "decision maker."

We established in Part Two that the core role of the human in AI collaboration is the "decision maker." And the value of a decision lies in weighing and trading off different options. In software engineering there is almost never a "single correct answer" -- Solution A has the best performance but the highest development cost, Solution B is the fastest to build but carries security risks, Solution C is a balance. Which one to choose is a business decision that combines project timeline, team capability, business risk, and future planning.

When you let AI write code directly, you are in effect irresponsibly handing this vital "decision authority" over to AI. And AI, being a probabilistic model with no business sense and no understanding of your company's strategy, will only choose the most "mediocre," most "common" option from its training data. This is a profoundly dangerous power vacuum: you abandon your most valuable work, yet let an "intern" who is the least suited to make decisions determine the fate of the entire project on your behalf.

Conclusion: "Speed" is the cheapest by-product of AI-assisted programming, and also its most expensive temptation. Our first principle is:

> For high-risk work, unfamiliar domains, or new architecture, before the problem is fully understood, the options are fully evaluated, and a decision has been explicitly made, AI is strictly forbidden from generating a single line of substantive business code.

For high-risk, unknown, or new-architecture work, we will strip it of its "right to execute" until we -- as commander-in-chief -- have a complete grasp of the map, the objectives, and the line of march for the entire campaign.

### 19.2 The Standard "Three-Step" Flow: Research → Strategizing → Implementation

To force AI (and ourselves) into "slow thinking," we have designed a standard "three-step" workflow for high-risk work. Requirements of medium complexity or above, unfamiliar domains, or new architecture must first be classified using the table below; once risk or unknowns cannot be covered by existing gates, this process is mandatory.

This flow is, in essence, the explicitation and proceduralization of the tacit "problem-solving model" that lives inside a senior engineer's head.

<!-- code-example:chapter-19-E1 mode:reference -->
> **Example type: reference.** Reference fragment; it is not guaranteed to run alone. Adapt it to the lesson context, project versions and real interfaces, then validate with observed output.
```text
Step One: Research          What are we facing?
    ↓
Step Two: Strategizing      How should we proceed?
    ↓
Step Three: Implementation  Let's get to work!
```

Step One: Research -- What are we facing?

Goal: gather information, clarify requirements, identify constraints. Discussion of any specific implementation solution is forbidden. We are to act like a detective surveying the crime scene, not prematurely naming the culprit.

Core activities:
- Requirement decomposition: break a vague "big requirement" down into a series of smaller, more specific functional points;
- Boundary definition: clarify what the "success criteria" of this requirement are. Where are the scope boundaries? Which items are "must-have," and which are "nice-to-have"?
- Technical pre-research: do relevant third-party libraries or existing techniques exist that we can leverage? What are the pros and cons of each? Are there known "pitfalls" or best practices?
- Risk identification: which parts of the existing system might be affected by implementing this requirement? What known technical risks, performance risks, or security risks exist?

Output: a short, structured "Requirements Analysis and Risk Assessment" document.

AI's role: at this stage, AI is not a "programmer" but your "super research assistant" -- it is exceptionally good at rapidly retrieving information, summarizing documentation, and comparing technologies.

Step Two: Strategizing -- How should we proceed?

Goal: based on the information gathered in the first stage, begin designing and comparing multiple possible solutions. Note: "multiple," not "one." Our aim is to produce options and weigh them.

Core activities:
- Solution design: for the core technical challenge, propose at least two (preferably three) distinct architectural or design solutions;
- Solution comparison: compare these solutions objectively across multiple dimensions (development cost, performance, maintainability, security, scalability);
- Decision making: based on the outcome of the comparison, the human makes the final, explicit technology selection and architectural decision;
- Task decomposition: break the chosen final solution down further into a clear, executable, sequenced "development task list."

Output: a document containing a "solution comparison table" and the final "technical solution and task list."

AI's role: at this stage, AI is your "architectural design advisor." It is good at generating solutions of different styles under constraints and filling in the details of the comparison table. But the final decision must be made by you.

Step Three: Implementation -- Let's get to work!

Goal: only after the "technical solution" and "task list" from the second stage have been finalized do we enter this stage. The goal here is to translate the design into code efficiently and precisely.

Core activities: complete the coding one by one in the order of the task list; write tests for the new code; conduct human review of AI-generated code; update relevant project documentation.

Output: working, tested, standards-compliant code.

AI's role: only at this stage may AI finally play the role it is most known for -- "high-speed code generator." Because all the "thinking" and "decision" work has already been completed up front, AI is now traveling along an extremely definite, unambiguous "track," and its speed advantage can be brought to bear safely and efficiently.

This "three-step" flow acts as a mandatory "valve": thinking precedes action (before "what it is" and "how to proceed" are figured out, the valve is closed and no code can flow out); the human holds decision authority (there is an explicit "decision point" requiring human intervention during the "strategizing" stage); the execution stage is efficient (every question that needed "discussion" has already been resolved up front).

### 19.3 Applicability Boundary: Three Steps vs. Full-Automation Mode

"Research, then strategize, then implement" does not conflict with full-automation Workflow/Job mode. The former is a defensive process for risk and unknowns; the latter is authorization after the path and constraints have been made explicit. They are risk tiers, not substitutes. Use the table to choose the mode, then work within the selected mode.

| Decision condition | Mode | Why it is appropriate | If the condition fails or an exception appears |
|--------------------|------|-----------------------|-----------------------------------------------|
| High risk, an unfamiliar domain, or new architecture | Three steps: Research → Strategizing → Implementation | Clarify the problem and compare options first; a human makes business and architecture decisions, so unknowns are not turned directly into code | Stop in research or strategizing and complete the information, options, and human decision; automation must not skip these steps |
| A mature blueprint, a proven technical path, low risk, and a complete test grid: Chapter 25 coverage CI gates, comprehensive regression tests, and key acceptance checks can all run | Full-automation Workflow/Job | Automation can efficiently carry out repeatable execution inside an explicit blueprint and verifiable guardrails, while gates continually demonstrate no regression | If any gate fails, regression coverage is incomplete, results are unknown, or new risk appears, immediately downgrade to the three steps; if risk cannot be classified, stop and ask for human judgment |

Full automation receives permission only to execute an explicit blueprint. It receives neither business-decision authority nor production authority. In either mode, humans remain responsible for business trade-offs, production release, and exception approval; when tests fail, information is unknown, or gates cannot demonstrate safety, the system must downgrade or stop rather than use "full automation" as a reason to proceed.

### 19.4 How to Ask, and What to Ask, at Each Step (with Prompt Templates)

Theory is gray; the tree of life is evergreen. Let us look at how, in practice, we guide AI through each step of this "three-step" flow with concrete prompts. The templates below have been honed in practice; you may adapt them to your needs, but the "thinking structure" behind them is universal.

Stage One: Research -- interrogate AI like a detective.

Goal: squeeze every drop of value out of AI as an "information retriever" and build a comprehensive understanding of the problem. Core phrasings: "Act as a XX role," "analyze / decompose / list for me," "identify risks," "do not provide any solutions."

[Template 19.1: Requirements Clarification and Decomposition]

> Your prompt:
> Context: We have received a new feature request from our product manager. The original request is: "I want a 'smart recommendation' feature that recommends related articles to users based on their browsing history."
>
> Your Role: Act as a Senior Business Analyst. Your task is to break down this high-level, ambiguous requirement into a list of specific, answerable questions that we need to clarify before any technical work can begin.
>
> Task:
> 1. Deconstruct the Requirement: Break the core request into smaller, functional components.
> 2. Identify Ambiguities: For each component, list the key questions we need to ask the product manager to define the scope and success criteria. Examples: What defines "recent" history? What does "related" mean? How many recommendations to show?
> 3. Define Boundaries: List what is explicitly out of scope for this feature's first version.
>
> Constraint: Do not, under any circumstances, suggest any technical implementation or solution at this stage. Your entire focus is on clarifying the "What", not the "How".

[Template 19.2: Technology Selection Pre-research]

> Your prompt:
> Context: For our "Article Recommendation" feature, we need to choose a method to calculate the "relatedness" between articles. Let's assume articles have tags.
>
> Your Role: Act as a Research Engineer. Your task is to conduct a preliminary investigation into common techniques for this problem.
>
> Task:
> 1. Identify Techniques: List at least three common algorithms or techniques for calculating similarity based on tags (e.g., Jaccard Similarity, TF-IDF with Cosine Similarity, etc.).
> 2. Summarize Pros and Cons: For each technique, provide a brief 2-3 sentence summary of its core idea, and list its main advantages and disadvantages. Focus on computational complexity, ease of implementation, and quality of results.
> 3. Find Libraries: For each technique, identify one popular and well-maintained library in [your stack, e.g., Python] that implements it.
>
> Constraint: Do not recommend a "best" option. Your goal is to provide an objective, neutral summary of the available options for my review.

Stage Two: Strategizing -- conduct a sand-table rehearsal like a general.

Goal: have AI generate multiple parallel solutions and force it into a "self-debate," with you as the final arbiter. Core phrasings: "design solutions A/B/C," "create a comparison table," "evaluate against the following criteria," "I have decided on Solution X -- draft an execution plan for me."

[Template 19.3: Multi-solution Design and Comparison]

> Your prompt:
> Context: Based on our research, we have the necessary information to design the architecture for the "Article Recommendation" feature. Our core constraints are: the calculation must be fast (under 50ms), and it must run on our existing [Python/Flask] backend.
>
> Your Role: Act as a Solutions Architect. Your task is to propose and compare three distinct architectural approaches.
>
> Task:
> 1. Propose Three Solutions:
>    - Solution A (Simple & Fast): An approach based on pre-calculating and caching similarity scores. Describe how and when this pre-calculation would happen.
>    - Solution B (Real-time & Flexible): An approach that calculates similarity on-the-fly with every request. Describe how to optimize this.
>    - Solution C (Hybrid): A combination of the two, e.g., using a faster, simpler algorithm for real-time and a more complex one for offline batch processing.
> 2. Create a Comparison Table: Generate a markdown table that compares these three solutions across: Performance (Latency), Data Freshness, Implementation Complexity, Infrastructure Cost, Scalability.
> 3. Provide a Recommendation: After the table, briefly state which solution you would recommend and why, explicitly stating the trade-offs it makes.

[Template 19.4: Decision Confirmation and Task Decomposition]

> Your prompt:
> Context: I have reviewed the options. My Decision: We will proceed with Solution A (Pre-calculation). The trade-off of slightly less fresh data is acceptable for the gain in performance and simplicity.
>
> Your Role: Act as a Tech Lead. Your task is to take this architectural decision and break it down into a concrete, step-by-step implementation plan.
>
> Task:
> 1. Define Data Models: Specify any new database tables or data structures needed.
> 2. Outline Key Modules/Functions: List the main new functions or classes we will need to create. For each, give it a clear name and a one-sentence description of its responsibility.
> 3. Create a Sequential Task List: Generate a numbered list of development tasks in the logical order they should be completed. This should be a checklist an engineer can follow.
>
> Constraint: All tasks should be small enough to be completed in a single coding session.

Stage Three: Implementation -- carve with the precision of a craftsman.

Goal: on a fully determined track, maximize AI's code-generation efficiency. Core phrasings: "following our plan, execute Task X," "write code for this function," "write tests for this code."

[Template 19.5: Focused Coding Instruction]

> Your prompt:
> Context: We are now implementing the plan. Our current task is: "Backend: Implement the Jaccard similarity calculation logic."
>
> Your Role: Act as a Senior Pair Programmer.
> Task: Write the Python function calculate_jaccard_similarity(tags1: set, tags2: set) -> float.
>
> Constraints:
> - The function must be pure, with no side effects.
> - It must handle cases where one or both sets are empty (return 0.0).
> - Include a clear docstring explaining the formula.
>
> After you provide the function, immediately provide a second code block with three unit test cases for it using the unittest framework.

Through this set of templates, you transform what was once a one-shot, vague "give me the code" into a structured, human-led, progressively deepening "deep workshop." You are no longer a "user" of AI; you are its "process manager."

### [Flow Diagram] The Mandatory Transit Path for Complex Requirements

To give you a more intuitive grasp of this flow, below is the full diagram, showing clearly how information and decisions flow between the three stages, and the critical "gatekeeper" role of the human decision maker within it.

<!-- code-example:chapter-19-E2 mode:pseudocode -->
> **Example type: pseudocode.** Pseudocode; it is not executable. It expresses decision order only, so implementation must supply real interfaces, authority and error handling.
```text
┌────────────────────────────────────────────────────────────────────────────┐
│ THINKING ZONE (NO CODE ZONE)                                               │
│ Vague requirement input                                                   │
│   ↓                                                                       │
│ Stage 1: Research → AI requirements analysis and technical exploration      │
│   ↑                  (Templates 19.1 & 19.2)                               │
│   └── Human review: enough information? ── No: keep researching              │
│                         │ Yes: proceed                                    │
│                         ↓                                                 │
│ Stage 2: Strategizing → AI compares several solutions (Template 19.3)       │
│                         ↓                                                 │
│                 Human decision: choose solution A/B/C                     │
│                         ↓                                                 │
│         AI produces the final solution and task list (Template 19.4)       │
│                         ↓                                                 │
│            Final human confirmation: is the plan clear?                   │
│                         │ Yes: authorize execution                         │
└─────────────────────────┼──────────────────────────────────────────────────┘
                          ↓
┌────────────────────────────────────────────────────────────────────────────┐
│ EXECUTION ZONE (CODING ZONE)                                               │
│ Stage 3: Implementation → AI generates code and tests                      │
│   ↑                       (Template 19.5, one task at a time)                │
│   │                                ↓                                      │
│   │                  Human review and integration verification             │
│   └── No: return to implementation  │ Yes → Done                           │
└────────────────────────────────────────────────────────────────────────────┘
```

Diagram notes:

- Thinking zone vs. execution zone: when the applicability boundary above classifies the work as three steps, the whole flow is divided by a clear boundary into a "thinking zone" and an "execution zone." Inside the thinking zone, producing any substantive business code is absolutely forbidden; inside the execution zone, AI is permitted to generate code. The human exercises a "gatekeeper" duty at two key nodes -- solution selection (the pink diamond) and plan confirmation (the pink diamond). This boundary is the physical manifestation of "stripping execution rights."

### [Hands-on] Handling a Typical Requirement with the "Three Steps"

Exercise: Apply "Research → Strategizing → Implementation" to the following requirement: the product manager says, "We want to add a 'people nearby' feature to the App, so users can see nearby merchants."

Guidance:

1. Research stage: do not propose any solution! Have AI act as a business analyst and list the questions that need to be clarified with the product manager (the definition of "nearby"? how large a radius? does it require real-time positioning? what privacy and compliance are involved?).
2. Strategizing stage: have AI act as a solutions architect and propose at least three technical solutions (for example: precise calculation based on geographic coordinates / a grid scheme based on GeoHash / a scheme based on a third-party map SDK), and produce a comparison table.
3. Decision: you (the human) choose the solution -- be mindful of weighing development cost, precision, and scalability.
4. Implementation stage: have AI act as a Tech Lead, break the decision down into a task list, and then execute the tasks one by one.

Acceptance criteria: did the learner hold the line of "no solutions" during the research stage? Did they have AI propose multiple solutions rather than one? Was the decision made by a human rather than by AI? Was there a clear task list before implementation?

---

<!-- cognitive-load-checkpoint -->
## Pause and organise: complete the minimum loop

First write one relationship between read-only analysis and implementation authority, then place it in the execution-authority gate. Confirm that this step has an input, decision and evidence before adding verify before action; do not start the independent exercise until the three are connected.

## Independent exercise

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

For an unfamiliar platform failure, define read-only research, a reviewable plan and authorized implementation, with exit conditions and prohibitions.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: execution-authority gate

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 execution-authority gate states the entry condition from read-only analysis to implementation authority
- O2: The execution-authority gate contains at least one proceed branch, one stop branch and their owners
- O3: The artifact records current authority, allowed actions, forbidden actions and escalation owner for one request

<details>
<summary>Reveal reference feedback (answer first)</summary>

## Reference feedback

Research produces reproduction and hypotheses, without editing or exposing raw logs. Plans define minimal changes, checks and recovery. Implementation requires clear scope and authority. Use stages for uncertainty or risk; avoid ceremony for simple reversible work. Research does not confer production access.

### 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.

</details>

## Sources and boundaries

Registered sources support only the external claims used here. The execution-authority gate, example numbers and exercise scenario are internal instructional design and require project-specific validation.

- [Transformers generation strategies](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. Greedy, sampling and beam search use different next-token selection strategies, and decoding choices affect output.
- [Git reference](https://git-scm.com/docs) — Git project, 2026-09-17. Versions, branches, commits and recovery operations must be verified against repository state.