祝融说。

Have you ever had this experience?

Late at night, faced with a complex business requirement, you describe your problem to a large language model (LLM) on a whim. Seconds later, a block of structurally clear, seemingly perfect code appears on the screen. Elation fills your heart, as if you are seeing the dawn of a new era: "The future of programming is really here!" You quickly copy and paste the code into your project, make a few adjustments, and the feature works. In that moment, you feel like you have gained an omniscient, tireless "pair programming" partner.

But the honeymoon is always short-lived.

A few days later, the product manager proposes a new requirement change. You ask AI for help again, and it "cleverly" adds an if-else branch to the existing code. A few more days pass, another urgent bug needs fixing, and AI applies another patch. Slowly, things start to feel wrong. That initially elegant piece of code, like a garment covered in patches, has become bloated, fragile, and hard to understand. Worse, when you try to have AI refactor the "shit mountain" it wrote itself, it seems to fall into chaos -- sometimes forgetting the original architectural constraints, sometimes introducing incompatible dependencies, and even quietly breaking a core feature that had been stable for three months in what seemed like an unrelated fix.

You begin to feel confused, frustrated, even angry. How has this so-called "super partner" turned into a "useless teammate" that only creates trouble? You find yourself spending more time "correcting AI," "reviewing AI's code," and "cleaning up AI's messes" than you would have spent writing the code from scratch.

If you resonate with this scenario, congratulations -- you have completed the obligatory "path of disillusionment" that most developers go through when embracing AI programming. You are also about to reach a critical cognitive turning point -- one that will determine whether you become a slave to AI or a knight who rides it.

The core of this turning point is this: we misunderstood our relationship with AI from the start. This is more than pair programming; it is a mode of human–machine collaboration whose rules we must learn anew. Abandoning unrealistic fantasies, redefining our role, and mastering constraints are key to moving from chaos toward verifiable control. Specifications, tests, review, telemetry, and rollback are equally indispensable.

1.1 Abandon the Fantasy: The LLM Is Not a Programmer, but a Super Intern

The reason we fall into trouble lies in a widespread misunderstanding: we anthropomorphize the LLM and imagine it as an experienced senior programmer. We expect it to understand context, foresee risks, weigh trade-offs, and take responsibility for the final code quality.

This is a fatal mistake.

The LLM is not a programmer. It is more like a "super intern." This metaphor may be somewhat offensive, but it captures the essence of AI programming with remarkable precision and helps us establish correct expectations.

Let us dissect the characteristics of this "super intern" in detail.

Characteristic One: Vast Knowledge, but Zero Experience

This intern is a veritable "walking Wikipedia." They have memorized nearly all public code on GitHub, read every Q&A on Stack Overflow, and committed all API documentation for mainstream frameworks to memory. Ask them what a "red-black tree" is, and they can instantly write out the most standard implementation. Ask them how to implement a gRPC service in Go, and they can immediately produce a complete code skeleton. In terms of "knowledge breadth" and "memory," they surpass any human programmer.

However, they have zero "experience."

What is experience? Experience is not "knowing" something, but having "stepped into a pit." Experience is knowing that beneath that seemingly smooth business scenario lies a huge performance trap. It is knowing that a seemingly harmless third-party library can cause a memory leak on a specific operating system. It is knowing that the product manager's "just a small change" might involve linked refactoring across three microservices.

AI does not have this kind of "flesh-and-blood experience" earned through real-world failure and pain. It will "naively" recommend a library that is widely praised in the tech community but fatally incompatible with your project's existing tech stack. It will "confidently" write asynchronous code that works perfectly under ideal network conditions but frequently times out in weak network environments.

[Real-World Scenario] You ask AI to add a "Remember Me" feature to a web application.

• AI's "knowledge": It knows the simplest way to implement this is to store the user's authentication token in localStorage. It immediately generates the relevant code.
• Human engineer's "experience": You see localStorage and alarm bells go off. You know about the cross-site scripting (XSS) risk -- once the site is injected with malicious scripts, the stored token can be easily stolen. An experienced developer would choose the more secure HttpOnly Cookie for storing sensitive information.

AI provides a "working" solution. Experience makes you choose a "secure and working" solution. This is the chasm between knowledge and experience.

Characteristic Two: Explosive Execution, but Zero Sense of Responsibility

This intern has boundless energy and never complains about working overtime. Ask them to write 100 unit tests, and they do it without blinking. Ask them to replace all var with let and const in the project, and they finish instantly. They are a perfect "execution machine."

However, they have zero "sense of responsibility."

Responsibility means bearing the "consequences." A responsible programmer, before submitting code, constantly thinks: "Will my changes affect other modules? Have all edge cases been considered? Are the logs clear enough for future troubleshooting?"

AI has none of these concerns. Its objective function is to "generate the next most probable token based on context." It pursues "pattern matching," not "engineering reliability." As long as it can "understand" your instruction, it will execute it without regard for consequences. It generates code with security vulnerabilities without feeling guilty. Its refactoring breaks the entire system without remorse. It is merely a probability-calculating engine with no emotions and no "professional ethics."

[Real-World Scenario] Your project has an urgent bug where a key function crashes when the input is null. You throw the error log and code snippet at AI, demanding an "urgent fix."

• AI's "execution": It instantly adds a check at the function entry: if (input === null) { return; }. The problem is "solved" -- the program no longer crashes.
• Human engineer's "responsibility": You would think further: Why is input null? Which upstream component called it incorrectly? Will the downstream logic suffer more subtle bugs because this function returned early without the expected result? Should I simply return here, or should I throw an exception to expose the problem at its source? Should I log this anomalous input for future traceability?

AI masks the symptom with a "patch." Responsibility drives you to find the "root cause."

Characteristic Three: Logically Self-Consistent, but Highly Prone to "Confirmation Bias"

AI's logical reasoning ability is often astonishing. It can understand complex code dependencies and make modifications based on them.

However, it is extremely prone to falling into the mental trap of "confirmation bias."

Once AI starts its work based on a wrong understanding or assumption, all its subsequent behavior tends to "confirm" and "defend" that initial error, rather than overturn it. This is common in humans; in AI, the tendency is often amplified further, because the conversation history keeps reinforcing the existing assumption and the model rarely questions its own premises spontaneously within a session.

This is why, when you ask AI to fix a bug it introduced itself, the situation often devolves into a disaster. It does not think: "Oh, my initial approach might have been wrong." It thinks: "My initial approach was not wrong; some detail must have been mishandled." So it keeps adding bricks to a faulty foundation, trying to "straighten" a building that is already tilting dangerously. The result is only more chaos, until it all comes crashing down.

[Real-World Scenario] You ask AI to design a user permission system. It mistakenly chooses a design that hard-codes user roles on the frontend.

• First modification: You request the addition of an "Auditor" role. AI does not question the original architecture; it simply adds another if (role === 'auditor') check in the frontend code.
• Second modification: You request dynamic permission configuration. AI still holds its ground. It might design an extremely complex piece of logic to simulate backend dynamic permission calculations on the frontend, rather than fundamentally overturning the flawed "frontend hard-coding" design and returning the permission-checking responsibility to the backend.
• Final result: Your frontend code becomes a "shit mountain" filled with dozens of if-else statements, where permission logic is tightly coupled with UI logic.

AI's "confirmation bias" makes it a terrible "tinkerer" rather than a qualified "refactorer."

In summary, treating AI as a "super intern" means accepting its imperfection from the bottom of our hearts. Just as we would with a real-world intern, we must fully leverage its strengths (speed, breadth of knowledge) while also using a set of effective management mechanisms to avoid its weaknesses (lack of experience, no sense of responsibility, susceptibility to bias).

Abandoning the fantasy of AI as a "perfect partner" is the first, and most critical, step toward effective mastery.

1.2 Your True Role: From "Code Writer" to "Decision Maker"

Since AI is a "super intern," what is our role -- the human developer -- then?

The answer is: Tech Lead, Architect, Product Manager, and ultimately the "Decision Maker."

In the AI-native era, the value chain of software development is undergoing a profound restructuring. In the past, programmers spent much of their time on "implementation" -- looking up APIs, writing business logic, debugging syntax errors. Now, these "implementation" tasks are being taken over by AI with extremely high efficiency. This does not mean human programmers will face unemployment. It means that our core value is shifting from "hands-on coding" to upstream "brain-on decision-making."

Our job is no longer to lay bricks one by one to build a wall. It is to become the person who "draws the blueprint, specifies the materials, and inspects the quality."

Specifically, your role as "decision maker" manifests in the following key areas:

Decision One: Define Boundaries and Constraints

This is your most important responsibility. Before the project starts, even before you let AI write the first line of "Hello World," you must, like an urban planner, delineate clear boundaries for the entire project.

• Technology selection decision: Should this project use React or Vue? Go or Node.js for the backend? MySQL or PostgreSQL? These decisions may seem basic, but they profoundly affect the quality of AI's subsequent code generation. You cannot expect AI to make the optimal choice for you; it will only give you the most "popular" or "common" choice. You need to weigh options based on your team's tech stack, business scenario, performance requirements, and operational costs.
• Architectural pattern decision: Should the project adopt a microservices or monolithic architecture? Should the frontend and backend be fully separated or coupled? Should state management use a centralized Redux pattern or a distributed Context pattern? These high-level architectural decisions define the "skeleton" of the code organization. AI will fill in the flesh within this skeleton. If the skeleton is wrong, no amount of flesh can fix the deformity.
• Environment and compatibility decision: Which operating systems does our software need to support (Windows, macOS, Linux)? What is the minimum browser version for compatibility (IE11 or modern browsers)? Are there special operating environments (offline, intranet, or domestic OS ecosystems)? You must inform AI of these constraints in extremely clear language from the start; otherwise, it will default to generating code for the most ideal, modern environment, leading to catastrophic compatibility issues at delivery.

Decision Two: Break Down Requirements and Tasks

AI cannot understand vague, human-filled business requirements. You cannot directly throw the product manager's exact words, "I want a cooler user login experience," at AI. You need to play the role of translator and project manager, breaking a grand business goal into a series of clear, unambiguous "technical task cards."

• Translation from "What" to "How": What does a "cooler login experience" mean? Is it adding social login (WeChat, GitHub)? Is it implementing passwordless login (phone verification code, email link)? Or is it adding a dynamic background animation? You need to convert these possibilities into specific technical requirements.
• Task prioritization and dependency sorting: Should we build the UI first or write the backend API first? Does the user registration function depend on an email sending service? You need to plan a logically clear "workflow" for AI, rather than letting it wander aimlessly.

Decision Three: Verify Results and Quality

AI has submitted its "homework," and your work has just begun. You are no longer the "producer" of code, but its "first quality inspector."

• Functional verification: Does the code implement the expected functionality? Can all normal business processes run through?
• Boundary and exception verification: When the input is empty, a very long string, or malicious script, does the program crash? When the network disconnects or the server returns a 500 error, does the frontend give a friendly prompt? These are all "corners" that AI easily overlooks.
• Non-functional verification: How is the code's performance? Is there any noticeable lag? Are the logs well-formatted enough to support future troubleshooting? Does the code follow the team's coding standards? Are there obvious security vulnerabilities?
• Code review: Yes, you still need to do Code Review, but the focus has changed. You no longer need to check every line for syntax typos. Instead, focus on higher dimensions: Is the architecture reasonable? Are the module divisions clear? Does the naming convey business intent? Are there potential logical time bombs?

Decision Four: Make Trade-offs

The essence of software engineering is the "art of trade-offs." In the real commercial world, where resources are limited and time is tight, there is no "perfect" solution, only "appropriate" ones.

• "Fast and dirty" vs. "Slow and beautiful": For this urgent online bug, do we apply a temporary patch to stop the bleeding immediately and refactor thoroughly in the next version? Or would we rather let users wait an extra day to make a clean, elegant fix in one go? AI cannot give you this answer.
• Technical debt trade-offs: To meet a launch deadline, we introduce a temporary technical solution, incurring "technical debt." Is this debt acceptable? When and how do we plan to repay it? You need to manage the project's "technical balance sheet" like a shrewd financial officer.
• Letting go and cutting features: During development, you realize that the implementation cost of a feature (e.g., IE8 compatibility) far exceeds its value. At this point, you need the courage to make the decision to "cut this feature" and convince the product manager and stakeholders, rather than letting you and AI waste time in a bottomless pit.

From "code writer" to "decision maker" -- this is not just a change in work content, but a profound upgrade in thinking mode. It demands that we step out of the details of code and think from the global perspective of the system, the business, and engineering. Our value is no longer measured by "how many lines of code we wrote," but by "how many high-quality decisions we made."

This is difficult, but it is also the irreplaceable core value of the human programmer in the AI era.

1.3 Why Is Constraint the First Principle? -- Trading Limitation for Certainty

Now we are clear: AI is the super intern, and we are the decision maker. How, then, do we effectively communicate our "decisions" to this intern and ensure they are executed accurately?

The answer is "constraint."

In AI programming practice, effective constraint is the only bridge connecting human wisdom and AI computing power. It is the core law for transforming the uncertain world of probability into certain engineering products. It is the "first principle" of the entire methodology.

Many people instinctively dislike "constraint," seeing it as a limitation on freedom. But in engineering, especially when collaborating with an inherently uncertain system like an LLM, constraint is the only path to freedom and creativity.

The Essence of Constraint: Trading "Limitation" for "Certainty"

Imagine that AI's potential capability is an infinitely vast "possibility space." When you give it a vague instruction, like "write a login page," it can randomly pick a point anywhere in this space, giving you a page written in React, Vue, or even ancient jQuery. Every result could be different, full of uncertainty.

The function of "constraint" is to draw "fences" within this infinite space, sharply narrowing AI's range of choices.

• You add a constraint: "Use React 18 and TypeScript." The possibility space is greatly reduced.
• You add another constraint: "UI component library must be Ant Design 5.0." The space shrinks further.
• You continue: "State management must use Zustand, not Redux."
• You add a final constraint: "Do not use useEffect to initiate API requests; they must be encapsulated in custom Hooks."

When you have applied enough precise constraints, AI's "possibility space" is compressed into a small candidate region. At this point, its output transforms from an uncertain, random "guess" into a highly determined "engineering artifact" that meets your expectations. Of course, as Chapter 4 will detail, constraints eliminate known bad paths; the remaining candidates still require acceptance criteria and verification for the final verdict.

Trade limitation for certainty -- this is the magic of constraint. You give up the illusory power of letting AI "freely play," in exchange for tangible control over the final output.

The Value of Constraint: Reducing Cognitive Load, Focusing on High-Level Decisions

Without constraints, you must review every line of code AI generates, understand its implementation logic, and evaluate its pros and cons -- an extremely mentally taxing process.

With clear constraints, your review model changes fundamentally. You no longer need to ask: "Is this code good?" You only need to ask a simpler question: "Does this code obey all the constraints I set?"

• Does it use React 18? -- Yes.
• Does it use Ant Design? -- Yes.
• Does it use Zustand? -- Yes.
• Does it use fetch inside useEffect? -- No.

Your cognitive load is reduced from "understanding a complex open-ended problem" to "checking a closed list." This frees up valuable mental resources from tedious code details, allowing you to invest them in more important "high-level decisions," such as thinking about the next architectural evolution or evaluating the technical risk of a new approach.

Types of Constraints: Building a Multi-Layered "Moat"

In the following chapters of this book, we will explore in depth how to design and implement a multi-layered, comprehensive constraint system. This system is like a series of "moats" dug around your project, ensuring that the giant beast of AI always travels within the safe channel you have planned.

• Architectural constraints (Part 2): The innermost moat, defining the tech stack, module boundaries, and design patterns through documentation and project structure.
• Process constraints (Part 3): The lock gates controlling navigation rhythm, guiding AI's thinking path through session management and questioning techniques, preventing it from "running wild" or "going in circles."
• Environmental constraints (Part 4): The dikes responding to the external environment. When AI faces real operating environments it cannot see (like specific operating systems or closed APIs), how to use logging and telemetry to build effective perception for it.
• Quality constraints (Part 5): The final quality inspection checkpoint. Through automated testing and continuous integration, establish an impassable "electric fence" through which code that does not meet quality standards can hardly pass.

Mastering the art of "effective constraints" means mastering the core competitiveness of complex software development in the AI era. It demands that we transform from a developer pursuing "addition" (constantly implementing new features) into an architect skilled in "subtraction" (constantly eliminating wrong possibilities).

This transformation is the evolutionary path from "making AI work for me" to "symbiosis between me and AI." Now, let us begin by taking the first step of evolution with this clear division-of-labor role card.

As a side note, the methodology of this book is not an isolated set of empirical lessons, but an extension of the RC theoretical system (Process Realism: Observational Convergence and the Generation of Certainty) into software engineering: an LLM's output is a probability distribution, corresponding to the "possibility substrate" in RC; a constraint is our targeted filtering and "temporary locking" of a region of possibilities as observers; and the "negative space design" of Chapter 4 mirrors RC's practical-philosophy idea of sustainable decision-making -- excluding irreversible catastrophic failures while preserving the available margin. Constraints eliminate known bad paths but do not replace final verification and adjudication. Readers interested in the philosophical foundations may trace back through that entry point.

[Ready to Use] Human-AI Collaboration Role Card

Print this card out, or put it on your desktop background. Before every interaction with AI, quickly glance through it to remind yourself and your "partner" of their respective roles and responsibilities.