Chapter 5: Drop the Fantasy: Large Models Are 'Super Interns,' Not Senior Engineers

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

5.1 The Three Traits of a Super Intern: Vast Knowledge but No Experience, Blazing Execution but No Sense of Responsibility, Logically Consistent but Prone to Confirmation Bias

The reason we keep running into trouble collaborating with AI has its roots in a common misunderstanding: we try to treat the large model like a person, imagining it as an experienced senior programmer. We expect it to understand context, anticipate risks, weigh trade-offs, and take responsibility for the quality of the final code.

This is a fatal mistake.

A large model is not a programmer; it is more like a super intern. The analogy may be a little blunt, but it reveals the essence of AI coding with striking precision. Let us dissect the three traits of this super intern in detail:

Trait one: vast knowledge, but no experience.

This intern is a walking encyclopedia — he has memorized the API docs of nearly every mainstream framework, absorbed the massive volume of open-source code, and read all the best of the Q&A sites. Ask him how to implement a gRPC service in Go and he will immediately hand you a complete code skeleton. In breadth of knowledge and memory, he outclasses any human programmer.

Yet he has no experience at all. Experience is not “knowing” something; it is having “fallen into” a pit. Experience is knowing that a performance trap hides beneath a seemingly smooth business scenario; knowing that some seemingly harmless third-party library leaks memory on a particular operating system; knowing that what the product manager calls “just a small change” may actually drag three modules into a coordinated refactor.

A typical gap: you ask the AI to add a “remember me” feature to a web app. The AI’s “knowledge” lets it immediately produce a solution that stores the auth token in localStorage; a human engineer’s “experience” sets off alarm bells at the sight of localStorage — it carries the risk of cross-site scripting (XSS) attacks, so an experienced developer would choose the safer HttpOnly cookie. The AI offers a solution that “works”; experience leads you to choose one that is “safe and workable.”

Trait two: blazing execution, but no sense of responsibility.

This intern has boundless energy and never complains about long hours. Ask him to write 100 unit tests and he does not bat an eye; ask him to replace every var in the project with let and const, and he is done in an instant. He is a perfect execution machine.

Yet he has no sense of responsibility. A responsible programmer, before committing code, will think over and over: “Will my change affect other modules? Have I considered all the edge cases? Are the logs clear enough?” The AI has none of these concerns. It predicts a next-token distribution from context. Greedy decoding selects the highest-probability item at each step; sampling draws from the distribution rather than always taking its maximum (see Transformers generation strategies). This generation mechanism does not itself constitute a commitment to the project’s engineering reliability.

A typical gap: your project has an urgent bug — a critical function crashes when its input is null. You throw the error log and the code at the AI and ask for an emergency fix. The AI’s “execution” lets it immediately add if (input === null) { return; } at the top of the function — the program no longer crashes, the problem is “solved.” A human engineer’s “responsibility,” however, would dig deeper: why is input null in the first place? Which upstream step caused it? Could an early return plant an even sneakier bug downstream? Should it simply return, or throw an exception so the problem surfaces at its source? The AI used a patch to mask the symptom; responsibility drives you to hunt for the root cause.

Trait three: logically self-consistent, but highly prone to confirmation bias.

The AI’s reasoning ability is often astonishing; it can understand complex code dependencies and make changes on top of them. Yet it is highly prone to confirmation bias — once the AI starts working from a wrong belief or assumption, every later action tends to “confirm” and “defend” that initial error rather than overturn it. This is common in humans too, but it is magnified without bound in the AI, because it has no metacognitive capacity for self-reflection.

A typical gap: you ask the AI to fix a bug it introduced itself — it will not think “my original approach might be wrong”; it will think “my original approach is right, some detail must have been mishandled.” So it keeps adding bricks onto a wrong foundation, trying to straighten a building that is already leaning dangerously, and the more it patches, the messier it gets, until the whole thing collapses. In Chapter 6 we will see the full evolution of this trap.

Summary: treating the AI as a super intern means accepting its imperfection from the bottom of our hearts. Just as we would with an intern in a real-world workplace, we should make full use of its strengths (speed, breadth of knowledge), while using a well-proven set of management practices to guard against its weaknesses (lack of experience, no sense of responsibility, a tendency to dig in its heels). Letting go of the fantasy that AI is a perfect partner is the first — and most critical — step toward controlling it effectively.

5.2 Your Real Role: Tech Lead / Architect / Product Manager / Final Decision-Maker

Since the AI is a “super intern,” what is our role — we human developers?

The answer: Tech Lead, architect, product manager, and ultimately the decision-maker.

In the AI-native era, the value chain of software development is being fundamentally reshaped. In the past, a programmer might spend 80% of their time on implementation — looking up APIs, writing business logic, debugging syntax errors. Today, that implementation-level work is being taken over by the AI with tremendous efficiency. This does not mean human programmers will lose their jobs; it means our core value is shifting from “typing out code” to the higher “thinking through decisions.”

Our job is no longer laying bricks one by one into a wall; it is becoming the person who draws the blueprint, specifies the materials, and inspects the quality. Concretely, your role as decision-maker plays out across the following four key dimensions.

5.3 Four Decision Duties: Define Boundaries and Constraints, Decompose Requirements and Tasks, Validate Results and Quality, Make Trade-Offs

Decision one: define boundaries and constraints (The Architect).

This is your most important duty. At the very start of a project — even before you let the AI write its first line of code — you must, like a city planner, draw clear boundaries for the whole project.

• Technology selection: React or Vue for this project? MySQL or PostgreSQL for the database? You cannot expect the AI to make the optimal choice for you; it will only give you the most “popular” or most “common” option. You need to weigh the team tech stack, business scenario, performance requirements, and operations cost.
• Architecture pattern: microservices or a monolith? Fully separated or coupled frontend and backend? These high-level decisions define the “skeleton” of the code organization, and the AI will fill in the flesh within that skeleton. If the skeleton is wrong, no amount of flesh makes it anything but deformed.
• Environment and compatibility: which operating systems must be supported? What is the minimum browser version to support? Are there special offline, intranet, or domestic “xinchuang” runtime environments? These constraints must be told to the AI immediately in the most explicit language, otherwise it will default to generating code for an ideal, modern environment, producing catastrophic compatibility problems at delivery time.

Decision two: decompose requirements and tasks (The Product Manager).

The AI cannot understand vague, human-laden business requirements. You cannot just throw the product manager’s exact words — “I want a cooler user login experience” — at the AI. You need to play the interpreter and the project manager, decomposing a grand business goal into a series of clear, explicit, unambiguous technical task cards.

• Translating from “What” to “How”: what does a cooler login experience actually mean? Adding social-account login? Implementing passwordless login (phone verification code, email link)? Or adding a dynamic background animation? You need to turn these possibilities into concrete technical requirements.
• Ordering task priorities and dependencies: should the UI come first, or the backend APIs? Does user registration depend on the email-sending service? You need to chart a logically clear workflow for the AI, rather than let it dart around like a headless fly, writing whatever pops into its head.

Decision three: validate results and quality (The QA & Auditor).

The AI has handed in its homework, and your work has only just begun. You are no longer the producer of the code; you are its first quality inspector.

• Functional validation: does the code implement the expected functions? Do all normal business flows run through?
• Boundary and exception validation: does the program crash on null input, oversized strings, or malicious scripts? When the network drops or the server returns a 500, does the frontend show a friendly message? These are exactly the “corners” the AI is most likely to ignore.
• Non-functional validation: how is the performance? Are the logs well-formatted and sufficient for future troubleshooting? Does the code follow the team’s coding standards? Are there obvious security holes?
• Code Review: you still need to do code reviews, but the focus has changed — no more line-by-line syntax and spelling checks; put your energy at a higher level: is the architecture sound? Are the module boundaries clean? Does the naming express business intent? Are there hidden logic bombs?

Decision four: make trade-offs (The Pragmatist).

The essence of software engineering is the art of trade-offs. In a commercial world of limited resources and tight deadlines, there is no “perfect” solution, only the “right” solution.

• “Fast and dirty” vs “slow and beautiful”: for this urgent production bug, do you stop the bleeding quickly with a temporary patch and do a full refactor in the next release? Or would you rather let users wait an extra day and do the most elegant fix in one go? This is a decision the AI cannot make for you.
• Tech debt trade-offs: to make the launch deadline, we introduced a stopgap technical approach, which accrues technical debt. Is that debt acceptable? When, and how, do we plan to pay it back? Like a shrewd financial officer, you need to manage the project’s technical balance sheet.
• Giving up and cutting: during development you realize that some feature (say, IE8 support) costs far more to implement than the value it brings. At that point you need the courage to make the “cut this feature” decision and convince the product manager and your boss, rather than let the AI and you waste your lives together in a bottomless pit.

Going from “the person who writes code” to “the person who makes decisions” is not just a change in job content; it is a profound upgrade of mindset. It demands that we rise above the details of the code and think from the global perspective of systems, business, and engineering. Our value is no longer measured by how many lines of code we wrote, but defined by how many high-quality decisions we made.

5.4 Constraints Are the First Principle: Trade Limits for Certainty

Now we have made it clear: the AI is the super intern, and we are the decision-makers. So how do we pass our decisions to this intern effectively and make sure they are carried out accurately and without error?

The answer is constraints.

In the practice of AI coding, effective constraints are the only bridge between human intelligence and AI compute power. They are the core law by which we turn an uncertain probabilistic world into deterministic engineering products — the first principle of the whole methodology.

Many people instinctively dislike constraints, seeing them as restriction and loss of freedom. But in engineering — especially when collaborating with a system full of uncertainty like a large model — constraints are precisely the only path to freedom and creativity.

The essence of constraints: trade “limits” for “certainty.”

Imagine that the AI’s potential capability is an infinitely vast space of possibilities. When you give it a vague instruction like “write a login page,” it can pick any random point in that space — it might be written in React, in Vue, or in the most ancient jQuery. Every result may differ, full of uncertainty.

Constraints, in turn, draw “fences” inside that infinite space, drastically shrinking the range of the AI’s choices:

• You add one constraint: “use React 18 and TypeScript” — the space of possibilities shrinks dramatically;
• You add another: “the UI component library must be Ant Design 5.0” — the space shrinks further;
• You keep adding: “state management must use Zustand, not Redux”;
• And finally: “no API requests may be made from a useEffect; they must be wrapped in a custom hook.”

Once you have imposed enough constraints, precise enough ones, the AI’s space of possibilities is compressed into a small candidate region. At that moment, what it produces changes from an uncertain, random guess into a highly deterministic engineering artifact that matches your expectations — though that candidate region still calls for your acceptance check to have the final say.

Trade limits for certainty — that is the magic of constraints. You give up the illusory power of letting the AI run free and gain real, tangible control over the final output.

The value of constraints: lower cognitive load and focus on high-level decisions.

Without constraints, you have to review every line of code the AI generates, understand its implementation logic, and assess its merits — an extremely draining process. With clear constraints in place, your review pattern changes fundamentally. You no longer ask “is this code well written?” You only need to ask a simpler question: “does this code obey every constraint I set?” Is it React 18? Is it Ant Design? Is it Zustand? Is there a fetch inside a useEffect?

Your cognitive load drops from understanding a complex open-ended problem to checking a closed checklist. This frees your precious mental resources from tedious code details and lets you invest them in the more important high-level decisions.

Types of constraints: build an all-around “moat.”

This constraint system is like a set of “moats” dug around your project, ensuring that the AI — that great beast — always travels inside the safe channel you have charted:

• Architecture constraints: the innermost moat. Through documentation and project structure, they define the tech stack, module boundaries, and design patterns (Part Four of this book);
• Process constraints: the locks that control the pace of the voyage. Through session management and questioning techniques, they steer the AI’s thinking path and keep it from running wild or going in circles (Part Six of this book);
• Environment constraints: the levees against the outside environment. When the AI faces a runtime environment it cannot see, they build it effective awareness through log telemetry and similar means (Part Six of this book);
• Quality constraints: the final quality gate. Through automated testing and continuous integration, they set up an impassable “electric fence” that no substandard code can pass (Part Eight of this book).

Mastering the art of effective constraints means mastering the core competency for complex software development in the AI era. It demands that we transform from developers who pursue “addition” (endlessly implementing new features) into architects who excel at “subtraction” (endlessly eliminating wrong possibilities).

[Ready to Use] Human-AI Collaboration Role Assignment Card

Print this card out, or set it as your desktop background. Before every interaction with the AI, take a quick look at it to remind yourself and your “partner” of each side’s role and responsibilities.

Development phase	AI (super intern) role	You (technical decision-maker) role
Requirement analysis	Information retriever & solution generator: quickly find relevant technical material by keywords; generate several initial technical proposal drafts from clear instructions	Interpreter & filter: translate vague business requirements into clear, executable technical tasks; filter out the most feasible options based on experience and project context
Architecture design	Draftsperson & filler: generate code skeletons and directory structures per the specified architecture pattern; fill in the module interfaces and data structures you have already defined	Lead designer & decision-maker: make the final calls on technology selection, architecture pattern, and core module boundaries; define all the key constraints (tech stack, versions, compatibility, security red lines)
Coding implementation	Code generator & grunt worker: write concrete business logic, utility functions, UI components, and unit tests; execute repetitive, pattern-based coding tasks	Commander & quality inspector: issue clear, step-by-step coding instructions; review AI-generated code with focus on logic, boundaries, performance, and maintainability; confirm the code obeys all established constraints
Debugging	Log analyst & hypothesis provider: analyze possible causes from error logs and code; generate debug logging code on demand; propose several possible fix approaches	Detective & lead surgeon: reproduce the problem and gather key evidence; combine experience with the AI’s hypotheses to identify the most likely root cause; decide on the final fix strategy and direct the AI to execute it
Testing & verification	Test case generator: produce unit/integration test boilerplate from function signatures and business logic; quickly generate test data for all kinds of edge cases and abnormal inputs	QA lead: design the overall test strategy (unit, integration, end-to-end); write the core, most critical test cases; build and maintain the automated-testing “electric fence” and set the impassable quality red lines
Refactoring & optimization	Pattern-matching executor: carry out explicit, pattern-based refactoring tasks; scan for and report potential code smells	System health guardian: identify technical debt and architecture bottlenecks in the system; make refactoring decisions and weigh cost against benefit; make sure refactoring does not break existing functionality

---

Independent exercise

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

Write a delegation card with facts, unknowns, editable files, prohibited actions, output format and checks. Replace one unverifiable instruction.

Required chapter artifact: supervision-loop record

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 supervision-loop record draws both a forward path and a return path across candidate generation, engineering review and evidence-based release
• O2: Every stage in the supervision-loop record states its input, decision, output and owner
• O3: The artifact records one candidate, review finding, repair and release rationale

Reveal reference feedback (answer first)

Reference feedback

Replace ‘guarantee correctness like a senior engineer’ with ‘change only the classifier, preserve fixtures and expectations, and report the diff and results.’ Expertise metaphors do not justify trust. List unknown rules for business confirmation.

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.