# Chapter 4: What AI Coding Is and Is Not

## Lesson objectives

- **O1** Can distinguish the scope, owner and handoff between probabilistic generation and deterministic software (artifact: AI-coding capability boundary table)
  - Evidence: The AI-coding capability boundary table states the scope and owner of both probabilistic generation and deterministic software
- **O2** Can construct a AI-coding capability boundary table with inclusions, exclusions and human acceptance conditions (artifact: AI-coding capability boundary table)
  - Evidence: The AI-coding capability boundary table contains at least one exclusion, one handoff and one acceptance condition
- **O3** Can bound one AI-coding task into generation, verification and human approval (artifact: AI-coding capability boundary table)
  - Evidence: The artifact separates one task into generation, verification and human-approval regions

## Learning paths

- **Novice**: Chapter transfer task: Can bound one AI-coding task into generation, verification and human approval. Use the diagram's boundary relationship to complete the first evidence item in the AI-coding capability boundary table, then check each owner and decision rule.
- **Experienced**: Apply this task to a current project before reading the explanation: Can bound one AI-coding task into generation, verification and human approval. Submit the AI-coding capability boundary table, then check the relationship type, missing evidence and authority boundary.

## Teaching diagram

- **Required artifact**: AI-coding capability boundary table
- **Diagram kind**: capability-boundary
- **Relationship semantics**: The dashed frame is the responsibility boundary; handoffs connect the three elements, and work stops when evidence or authority crosses that boundary.
- **Core concepts**: probabilistic generation · deterministic software · human acceptance

![Chapter 4 teaching diagram for the AI-coding capability boundary table](/learning/diagrams/en/chapter-04.svg)

Use boundaries, handoffs and acceptance conditions to test the AI-coding capability boundary table; do not collapse the three elements into one responsibility.

A dashed frame marks the scope of the AI-coding capability boundary table. Three cards represent probabilistic generation, deterministic software and human acceptance. Arrows show defined handoffs, not interchangeable responsibilities; crossing the frame or lacking acceptance evidence requires a stop and escalation.

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

### 4.1 A Typical Scenario (Worked Example): Three Days of Work in Forty Minutes

It's Wednesday afternoon. You're assigned a task: build an internal tool for the team to register and look up equipment borrowing records. The requirements are clear -- a simple web page that can add borrowing records, view a list, and search history.

You estimate the work: frontend page, backend APIs, database design, deployment... at least three days.

But using an AI coding tool, you have a usable version in just forty minutes. The frontend can add records, search, and paginate. The backend can store and query data. The database tables have been created automatically.

This isn't an exaggeration -- it is what today's AI coding tools can achieve (the durations in this example are a worked example of demonstration magnitude; actual figures vary with the project and tool version). Of course, the prerequisite is knowing how to use them correctly.

But look further ahead. Behind this scenario hides the core tension of the AI coding era -- efficiency surges in parallel with quality loss. As the preface described, many teams' AI journey is a parabola of "early gains followed by decline":

- At first, AI shows astonishing productivity. You type a few sentences of natural language and hundreds of lines of code appear instantly; progress leaps forward.
- The turning point arrives quickly: you find that fixing one bug causes the AI to create three new ones; to implement one edge-case feature, the AI quietly alters a core underlying data structure; conversations grow longer, the AI begins to forget its original settings, and the logic becomes a tangled mess.
- In the end, you have to stop developing new features and spend several times more effort than writing code by hand, reading line by line through the obscure, verbose code the AI produced -- the tool that once boosted efficiency has instead become a technical debt that drains your energy.

Why does the same tool let one person deliver a usable version in forty minutes while another sinks into the swamp of "patching an abandoned building"?

The answer: whether they genuinely understand what AI coding is -- and what it is not.

### 4.2 Three Misconceptions That Must Be Cleared Up

Before we begin, let's dispel the three most common misconceptions. Left unchallenged, they will send your learning down the wrong path.

Misconception one: AI coding means generating an entire project automatically.

You give it one sentence, and it outputs a complete, production-ready commercial application. That is a scene from a promotional video, not actuality.

Why can't AI "generate an entire project from one sentence"? Because the AI's "brain" (the large language model) has a fundamental limitation: the context window is finite. The amount of information it can "see" at once is limited; the longer the conversation, the more likely it is to "forget" earlier content. Capacity depends on the model's token budget; there is no universal file-count or line-count cutoff. System instructions, tool results, history, and output also consume that budget. Even when material fits, redundancy and hidden dependencies may impair effective use. Select task-relevant material and verify understanding of critical constraints (see [Claude's context documentation](https://platform.claude.com/docs/en/build-with-claude/context-windows)).

The truth is: AI excels at completing well-defined task units. You need to break a large project into small tasks and hand them to the AI one at a time. It's like building a house: you can't tell the construction crew "build me a building" and go off for tea -- you need to tell them to lay the foundation first, then the walls, then the roof.

Misconception two: AI-generated code can be used directly.

The quality of AI-generated code varies. It may be syntactically correct but logically wrong; it may run but contain security hazards; it may meet the current requirement but be hard to extend.

Why does AI write code that "works but isn't safe"? Because the AI's training data contains a large amount of "looks-right" code -- from open-source projects, tech blogs, and Q&A communities, much of it "quick implementation" rather than "secure implementation." The AI has learned "how to write code" but not "how to write secure code." Inspection is a step that cannot be skipped -- just as you wouldn't sign for a package without checking it.

Misconception three: AI coding will make programmers obsolete.

This is a prediction that has been debated endlessly but has never come true. AI coding changes how the work is done, not the value of the work.

A more accurate analogy: calculators did not put mathematicians out of work; they freed mathematicians from tedious manual computation so they could focus on higher-level problems. Likewise, AI coding frees developers from "writing every line of code" and shifts them toward "defining tasks, reviewing output, and integrating systems" -- the role is being upgraded, not eliminated. A developer's core value is no longer "how much code they can write" but "how many correct decisions they can make."

### 4.3 The Essence of AI Coding: Humans Define Intent, AI Executes the Coding

With the misconceptions cleared, let's face the essence.

The essence of AI coding is: humans define intent, AI executes the coding.

You no longer write every line of code yourself, but you must:

- Define Requirements: clearly describe what you want to build;
- Design Architecture: decide the system's structure and module boundaries;
- Inspect Output: check whether the AI-generated code meets expectations;
- Integrate System: connect the modules into a complete system.

It's like going from "laying bricks yourself" to "being the general contractor." You may not lay bricks better than the bricklayer, but you know what the finished building should look like.

*AI-Assisted Programming in Action Based on Blueprint Planning* explains this shift more thoroughly: you must completely separate "writing code" from "doing engineering," forcefully reclaim two irreplaceable rights, and elevate your identity.

First, reclaim the "blueprint planning right." Do not leave the system's architectural design for the AI to guess. Like a true chief architect, before the AI writes its first line of code, you decompose the large system -- precisely defining the database table structures, the inputs and outputs of core interfaces, and the dependencies between modules. What you provide is a clear, unambiguous "construction drawing"; the AI is only responsible for filling in the "bricks" of code according to the drawing.

Second, reclaim the "engineering supervision right." Never blindly trust any unverified code the AI generates. You set extremely strict acceptance standards and audit each of the AI's outputs like a careful, objective engineering supervisor. The moment you find code that drifts logically, over-engineers, or breaks underlying constraints, show zero tolerance: never keep building on a tilted foundation -- halt it decisively, or even tear it down and start over.

In the era of AI-assisted programming, the code itself is no longer the core asset, and the act of generating code no longer creates core value. Only a clear system blueprint and rigorous engineering standards are the cornerstone that keeps a project from becoming an "abandoned building." Let go of the obsession with "individual lines of code" and take command of engineering delivery as a whole -- this is the inevitable leap from "someone who writes code" to "someone who makes decisions."

### 4.4 Where AI Coding Excels and Where to Be Cautious

Based on engineering practice, the following tables show where AI coding performs best and where caution is needed. They are worth bookmarking -- they are your first basis for deciding "should I hand this to the AI?"

High-efficiency scenarios

| Scenario | Description | Examples |
|------|------|------|
| CRUD APIs | Standard data create/read/update/delete | User management, article management |
| Form pages | Data input and submission | Registration forms, order entry |
| Data lists | Query, filter, paginate | Order lists, reports |
| Unit tests | Writing tests for existing code | Testing every branch of a function |
| Code migration | Moving code from one stack to another | jQuery to React |
| Type definitions | TypeScript types, API contracts | Interface types, database models |

Scenarios that need caution

| Scenario | Description | Advice |
|------|------|------|
| Complex business logic | Requires deep domain knowledge | Provide detailed requirement descriptions and examples |
| Security-sensitive code | Involves auth, encryption, payments | Must undergo security review |
| System architecture decisions | Technology selection, module design | Humans decide; AI provides references |
| Legacy system migration | Changes to large existing systems | Understand the current architecture first |

### 4.5 Three Core Concepts: Blueprint, Milestone, Inspection

Before moving to the next chapter, you need to be familiar with three core concepts that run through the entire book. They are the three cornerstones of this methodology; every later chapter unfolds around them.

Blueprint

A blueprint is the architecture design document created before a project starts. It answers three questions:

1. What are we building? (feature list)
2. How will we build it? (technical approach)
3. What comes first, and what comes next? (development order)

No blueprint, no coding -- this is the first discipline. The blueprint's standard filename in a project is CONTEXT.md: it serves as the working context for AI coding tools and contains every architectural decision and domain term they need to know. We cover the complete blueprint methodology in depth in Chapter 12.

Milestone

A milestone is an independently acceptable functional unit. Break a large feature into smaller milestones, each of which can be tested and accepted on its own.

A good milestone breakdown is like cutting a cake: each slice is the right size, has clear boundaries, and can be eaten on its own. More precisely, the milestones of the AI era should be structural milestones -- engineering nodes that can run independently, be tested, and form a fully self-contained logical loop (see Chapter 10).

Inspection

Inspection is a systematic check of AI-generated code. The standard is not "it runs" but "does it match the blueprint's expectations."

The three conclusions after inspection:

- PASS: meets requirements, ready to commit;
- NEEDS_FIX: has minor issues that need fixing;
- REBUILD: deviates too far from the blueprint, roll back and redo.

The three form a closed loop: with a blueprint first, you have direction; breaking work into milestones lets you advance in small steps; inspecting each step keeps you from drifting off course.

### [Exercise] Summarize the Boundary of AI Coding in One Sentence

Prompt: Use one sentence to summarize the boundary of AI coding -- what it is good at, what it is not good at, and where humans must step in.

Guidance: Think along three dimensions -- (1) is what AI excels at "well-defined small tasks" or "vague grand goals"? (2) after the AI generates code, which step can absolutely never be skipped? (3) in moving from "someone who writes code" to "someone who makes decisions," what core duties do you gain?

Reference answer (for instructors): AI coding excels at executing "task units that humans have already defined clearly with explicit boundaries" and is poor at autonomous decision-making under vague requirements and global architecture; therefore humans must always hold the "blueprint planning right" and the "engineering supervision right" -- defining intent and constraints before coding, and inspecting quality after coding; no unverified AI code may ever be used directly. In one sentence: "The AI turns a correct drawing into walls; the human draws the drawing, sets the boundaries, and inspects every wall."

---

## Independent exercise

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

Rewrite 'build an intelligent ticket system' into one classification task with input, output, exclusions, three checks and failure handling.

<!-- chapter-artifact-requirement -->
### Required chapter artifact: AI-coding capability boundary table

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 AI-coding capability boundary table states the scope and owner of both probabilistic generation and deterministic software
- O2: The AI-coding capability boundary table contains at least one exclusion, one handoff and one acceptance condition
- O3: The artifact separates one task into generation, verification and human-approval regions

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

## Reference feedback

Use deidentified titles and return power, mechanical or unknown. Exclude automatic dispatch and real accounts. Check normal categories, refusal to guess unknown inputs and empty-input rejection. Retain manual handling; deterministic exercises are not model evaluations.

### 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 AI-coding capability boundary table, 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.
- [Claude context windows](https://platform.claude.com/docs/en/build-with-claude/context-windows) — Anthropic, 2026-09-17. Context capacity is measured in tokens and is shared by system instructions, tool results, history and output.