Architecture Tutorial: A Prequel – A Mindset Guide for the AI Era

No talk about agents, no talk about skills, no talk about those three-letter acronyms.
We only talk about one thing: when machines start writing code for you, what’s left in your head that’s actually valuable.
The jailbreak series will come in a few days — some concepts need catching up.

Prologue: A Child Staring at a Memory Address

When I was a teenager, the first real “engineering” I did was adding health points to a character in a single-player game.

Back then, the two games that influenced me most were two domestic RPGs. One was Heroes of Jin Yong, the other was The Legend of Sword and Fairy 98 Soft Edition. Kids today may not know these names, but back then, they were things a kid would willingly give up an entire summer for. I loved them — loved them so much that playing wasn’t enough. I wanted to touch them, to reach inside and feel their bones.

That’s when I installed Kingsoft Cheater. Kids today probably don’t know what that is. Simply put, it was a lock — a lock that could pry open a game’s memory. You’d remember how much health you had, say 100, and search memory for all addresses equal to 100. You’d get thousands. Then you’d take a hit, health becomes 80, search again for 80 — thousands shrink to dozens. Take another hit, dozens shrink to one. That address is your life.

You lock it at some value. Invincible.

Later I realized that was my first real engineering lesson — and the hardest one. It taught me something far bigger than cheating. It taught me something far more fundamental: the number on the screen showing your health is fake. What’s real is the changing number in memory.

Everything you see — the interface, animations, sound effects — is just that number wearing layers of clothing. What you need to do is strip off the clothes and touch the number itself.

At first, I only changed superficial things. Levels, money — just making the character a bit stronger, richer, adding bricks to an existing building. Fun, but shallow.

What really gave me chills was when I later found skills.

I discovered I could change not only how much gold or how many levels a character had, but also what abilities they possessed. A nobody who only knew Wild Fist (though maxed out it was super strong) could suddenly be loaded with all the ultimate moves of other characters. A character designed to be weak — I could rewrite their capabilities. In that moment, I vaguely bumped into something I couldn’t articulate then but can now: changing what something “has” is one level; changing what it “can do” is another.

The former is adding and subtracting on the surface. The latter is altering its essence. A teenager wouldn’t know the word “essence,” but his hands had already touched that place before his mind caught up.

I never really stopped after that. Reverse engineering, cracking, writing cheats, then various automation, then quantitative trading. I even did security for a few years — better than a script kiddie, but not so great either. Far from the real pros. Walking that path, I switched through countless languages: from assembly registers, to writing Lisp scripts for World of Warcraft, to stitching together Python and Bash scripts to automate a bunch of messy tasks.

Now it’s 2026. Machines can write code for me — faster, more, and sometimes even cleaner than I can.

Many people are panicking. They’re frantically learning how to “use AI” — tools, acronyms, tricks — terrified of being left behind.

I want to panic too, but I can’t. Because I look back at that fake health bar and suddenly understand something:

What’s truly valuable was never which code I could write, but that habit I’ve had since I was a teenager — seeing anything and wanting to strip off its clothes to touch the changing number underneath.

This piece is about explaining that habit. I won’t teach you tools — tools go obsolete. The hottest thing today is tomorrow’s joke. I want to talk about something that won’t go obsolete: the mental models.

There are four of them. I’ll break them down one by one, using the pitfalls I’ve stumbled into over the past twenty-plus years.

After reading, you’ll realize that the “architect” of the AI era is not some new species. It’s just taking the oldest things in a programmer’s mind and slapping a new high price tag on them.

Chapter 1: All Abstractions Leak

Let’s start with assembly.

Not teaching you to write assembly — most people who can write assembly these days are probably close to retirement anyway. I want to talk about assembly thinking — a way of seeing the entire computer world.

What is assembly? It’s the human-language version of machine code. Computers only understand 0s and 1s. Assembly replaces long strings of binary with simple English abbreviations like MOV, ADD, directly commanding the CPU, memory, and registers. It’s incredibly fast, incredibly low-level, incredibly hard to write. A line of Python might take dozens of lines in assembly. Very few people make a living writing it today.

But once you’ve been at that level — even for a short while — your brain gets branded with something I’ve never lost:

You know that every layer above is a paved road someone built for you. And under that road is dirt that can collapse.

In 2002, a guy named Joel Spolsky proposed a law called “The Law of Leaky Abstractions.” It’s short and simple: All non-trivial abstractions leak to some extent.

It sounds like an obvious truism, but it’s the most poisonous truth in all of software engineering.

What is an abstraction? An abstraction is someone wrapping complexity into a simple switch for you. You read a file using the filesystem: one line of code open("file.txt"). Behind that is the physical movement of disk heads, sectors, cache, a whole mess of invisible dirty work. That mess gets wrapped into a clean switch — that’s abstraction. Abstraction lets you work fast without crawling through mud every time.

But Joel says: that wrapper is never fully sealed. Sometimes the dirty stuff seeps through. You read a file over the network, treating it like a local file, then the network drops — the abstraction leaks. You think you’re reading a file, but you’re actually betting on a cable that can fail at any moment. You write one SQL query, thinking the database will be smart about it, but when data volume grows, the query crawls, and you’re forced to study the underlying query plan. SQL programmers need a decent understanding of the database server’s query plan to figure out where performance bottlenecks are — the query language abstraction doesn’t help much at that point.

The most insidious implication of this law is: abstraction saves you the time of doing the work, but it doesn’t save you the time of learning.

Think about that.

It means: you can use a high-level framework to finish in one day what someone else would take a month to do — saving you work time. But when that framework breaks, when it leaks, you need to understand the layer below, or you can’t even find the bug. So you still have to learn everything. Abstraction just turns your pain from “a little every day” to “none usually, but excruciating when it breaks.”

Now put AI into this framework.

AI writing code is the highest abstraction humanity has ever built.

Going up: machine code → assembly → C → high-level languages like Python → frameworks → low-code platforms. A tower that keeps rising, each layer more “human-like” and “convenient” than the last.

And describing requirements in plain language for AI to spit out code — that’s the top floor, the furthest from the machine, closest to the human. Some call it “English is the new programming language.” When you clearly describe functionality in plain language, you’re writing an executable specification. The model translates intent into implementation. So the limiting factor is no longer your coding ability, but the clarity of your thinking and precision of your expression.

Sounds great, right? The tower is so high — does that mean you don’t need to care about the dirty work below?

Exactly the opposite.

The higher the tower, the deadlier the leak.

Because this abstraction doesn’t wrap disk sectors or TCP retransmission — it wraps software engineering itself. When it leaks, it doesn’t leak performance issues. It leaks silently corrupted logic. It confidently gives you wrong code, and you think it’s right.

I’ve been doing automation for twenty years. I can tell you very responsibly: the most dangerous thing about AI writing code is never that it can’t write something. If it can’t write it, you see it immediately — that’s not scary. What’s scary is when it confidently writes something wrong — perfect syntax, beautiful structure, runs without errors, but the logic is secretly twisted because it “hallucinated,” and it won’t tell you because it doesn’t even know.

That’s the leak of the top abstraction. Ordinary users can’t see it. Only those who have been at the bottom of the tower and know what’s underneath can.

My fake health bar story illustrates this. I didn’t learn the tool Kingsoft Cheater back then. I learned an instinct — not to trust the red health bar on the surface, but to find the number underneath. Today, when AI gives me a beautiful piece of code, my instinct is the same: don’t trust this pretty abstraction. Dig down one layer and see if what it says matches what it does.

That’s the entire value of assembly thinking in the AI era: when abstraction leaks, can you drop down a layer?

Those who can drop down: AI is their amplifier. Those who can’t: AI is their cliff — calm on the surface, but when it leaks, they won’t know how they died.

So don’t naively think that because the tower is high, you don’t need to understand the bottom. Joel’s law is still smirking: abstraction saves you work time, not learning time. Machines do the work for you, but the layer you need to understand hasn’t decreased one bit.

I even think that because machines have pushed the cost of “doing work” to the floor, the price of “understanding the bottom” has been pushed to the ceiling. In the past, if you didn’t understand the bottom, you could still get by on speed and overtime. Now speed is worthless — machines are ten thousand times faster. The only thing left of value is your ability to drop down a layer when a leak happens.

That’s the first mental model. Its core is one sentence: Always remember that the road you walk on was built by someone else, and under the road is dirt that can collapse.

Chapter 2: Decompose the World into Objects

Now let’s look upward.

The second mental model comes from object-oriented thinking. Again, I’m not teaching you classes or inheritance — that’s syntax, learnable in two weeks. I want to talk about the worldview behind OOP, which far outlives any language.

The official definition: package data and functionality into “objects,” and have objects collaborate. Beginners memorize three words: encapsulation, inheritance, polymorphism.

Encapsulation: hide the dirty details inside an object, exposing only necessary interfaces. A WeChat bot exposes “send message” — you don’t care how it connects to WeChat, routes through proxies, or evades risk controls. You don’t need to care. Inheritance: a subclass reuses the parent class’s capabilities. A generic bot can receive messages; a WeChat bot inherits that and adds WeChat-specific QR login. Polymorphism: the same action, different objects do it differently — “send message” works for WeChat Bot and QQ Bot. You just say “send message” without worrying how it’s done.

Newbies memorize these as syntax. But after twenty years of falling into pits, I see them as a set of scalpels for dissecting the world.

I’ll focus on encapsulation and polymorphism because these two knives are lifelines in the AI era.

Encapsulation: its essence is drawing boundaries.

Writing code: the real difficulty is never the keystrokes. It’s the decision before typing: what should be exposed, what should be hidden. For an object, how many interfaces you open, what they look like, how the internal mess stays silent — that set of decisions is the soul of engineering. Good encapsulation makes a system like Lego: you can swap pieces when broken. Bad encapsulation makes a system like porridge: one strand moves, everything twitches.

And drawing boundaries — machines still can’t do it well today.

You ask AI to write a function — it can. But ask AI to decide “how to decompose this system into modules, where to put boundaries, who should know whom, who should be oblivious to whom” — it will give you a plausible but shallow answer. Because drawing boundaries requires something knowledge alone can’t provide: judgment. You need to anticipate how the system will grow, which things will change together and which will change independently, then cut along these “change grains.”

That’s a human job. It was the core reason experienced architects got paid big in the past. Now it hasn’t changed — it’s just become more valuable.

Polymorphism: its essence is trusting the contract, not the implementation.

Polymorphism teaches you something profound: when you say “send message,” you don’t care how it’s sent. You only care about one thing: you said it, and the message goes out. Whether it uses WeChat or QQ, HTTP or WebSocket — that’s its own business, not yours.

You care about the contract (the promise to send a message), not the implementation (how exactly it’s sent).

Lock that in your mind, and you’ll have the core posture of an architect in the AI era.

Because when you command AI to do something now, it’s exactly the same. You shouldn’t care how AI internally wrestles the code out — that’s its implementation, its dirty work, hidden in its encapsulation. You should care about the contract between you and it: what input do I give, what output do I expect, what counts as correct, what counts as wrong.

You define the contract; it implements. That’s polymorphism thinking scaled to human-machine interaction.

The people who struggle most with AI are those who constantly try to dive into AI’s implementation, worrying about how it writes, what style it uses, how to tweak line 47. They forgot polymorphism. They forgot encapsulation. They end up wrestling with a black box, exhausted. Same task, same model: your colleague finishes in five minutes; you spend forty minutes fighting with the output. The difference isn’t IQ. The difference is: he defines the contract; you worry about implementation.

Encapsulation and polymorphism together point to one ability: decomposition.

Taking a fuzzy, sticky requirement and breaking it into objects with clear boundaries and explicit contracts. That’s what OOP really trains you for, and it’s the scarcest ability in the AI era.

I have to say something strong here, because it’s the backbone of this tutorial:

Machines are extremely good at executing clear instructions, but extremely bad at turning something fuzzy into something clear.

And “turning fuzzy into clear” is exactly what OOP has been training for decades — decomposing objects, drawing boundaries, defining contracts. It used to be called “system design.” Now it has a more valuable name: “problem definition.”

I’ve seen too many people type to AI “help me make a trading system” and then complain the output is unusable. Duh. The five words “trading system” hide hundreds of undefined objects: where does market data come from? How are signals calculated? Which exchange APIs for orders? What stop-loss logic? How is position managed? At what drawdown should we stop? — each question is an object waiting for you to encapsulate, draw boundaries, and define a contract. If you don’t decompose, AI will guess, and the result will be garbage.

I’ve been doing quantitative trading for over eight years. When I built TradeV7, the real brain work was never writing code. Writing code was the final twitch. The hard work was: converting the chaotic desire “I want to make money” into testable, executable objects layer by layer. For example, for stop-loss, I use the Chandelier Stop — which itself is a very clearly defined object: its inputs are highest price and volatility; its output is a stop-loss line that climbs with price but never retreats; its contract is “lock profits, never let them go.” Once I define it clearly, anyone can implement it — machine, me, my past self — the result is the same.

That’s the endgame of OOP thinking: You’re not writing a program; you’re decomposing chaos into objects that can be trusted.

Whoever decomposes is the architect. Whoever only says “make me an X” will forever be the one wrestling with black boxes.

That’s the second mental model. One sentence: The world is chaos; your skill is decomposing it into objects with clear boundaries and contracts.

Chapter 3: Code Is Data — You Stand Above Code

The third mental model comes from a language so old it’s nearly fossilized: Lisp.

Lisp has been around since 1958 — older than most programmers still alive. It looks weird: parentheses everywhere, everything is a list wrapped in parentheses. (+ 1 2) means add 1 and 2. Beginners get dizzy and think “what is this thing.”

But Lisp has a feature almost no other language dares to have: homoiconicity. In plain English: code is data.

In Lisp, your code looks exactly like the data you manipulate — lists in parentheses. What does that mean? It means you can operate on code as data — you can write a program whose output is another program; you can grab a piece of code and mold it, combine it, generate it like clay.

Someone summarized it as: Lisp is a “programmable programming language.” In other words, programming is writing code; metaprogramming is writing code that generates code.

When I was young, I used Lisp to write scripts for World of Warcraft. I didn’t think I was doing anything special — just that it felt great. I wasn’t writing one-by-one actions like “what the character should do.” I was writing a logic that made it generate behaviors based on the situation. I stood above the behavior layer. I wrote the thing that generates actions, not the actions themselves.

Back then I didn’t know the name for that posture. Now I do: it’s metaprogramming thinking, and it’s the most underestimated yet critical mindset in the AI era.

Why critical?

Because AI has pushed everyone into the metaprogramming position.

Think about it: you say a sentence to AI and it generates code. What are you doing? You’re using a piece of text (data) to generate a piece of program (code). That sentence, that requirement, that spec document — it is itself “code that generates code.” You’re no longer writing code; you’re writing the thing that generates code. You’ve been forcibly lifted to the layer above code.

This is the modern version of Lisp’s ancient dream: the boundary between code and data blurs; what you operate on is both description and instruction. Some people are even seriously connecting Lisp’s old soul with large models, because homoiconicity — unified representation of code and data — naturally fits large language models’ capabilities. Models benefit from structures that are easy to parse and manipulate. This is no coincidence. It’s the decades-old intuition of “code is data” coming full circle, finally paying off in the AI era.

So the question is: when everyone is lifted above code, who thrives and who struggles?

Those who thrive are people who were already used to “standing above.” People who wrote Lisp, macros, metaprogramming — who know in their bones that “what I write is a generator, not the product.” They pick up AI with a different skin — same posture, just parentheses replaced by plain language.

Those who struggle are people who spent their whole lives writing “products.” Put them at the code layer, they’re skilled. Lift them to the layer above, asking them to “describe something that can generate code” — they’re lost. They still write requirements with a code-writer’s brain — verbose, tangled, machines get confused.

This connects to the “problem definition” from the last chapter. A good requirement, a good spec, is essentially good “meta-code” — precise enough for a machine to generate the right thing, abstract enough not to care about the exact implementation. That balance is exactly what Lisp veterans have been playing with their whole lives.

A product person once said something I’ll never forget: the spec is the hard part; building is fast. A business idea that used to take fifty to a hundred thousand dollars and four to eight weeks for a prototype can now be built in an afternoon. Notice: the hard part is the spec, not the building. Building has been taken over by machines — that’s the product, the dirty work below. The hard part is always above: can you write a precise and restrained “meta-code” that allows the product to grow itself?

Lisp also taught me a second thing, simpler than “code is data,” but also life-saving: pure functions.

Lisp is the granddaddy of functional programming. One core obsession in functional programming is the “pure function” — same input always gives same output, doesn’t secretly modify anything outside, no side effects. A pure function is the easiest thing to verify: feed it input, see what output comes out. Correct is correct; wrong is wrong. Clean. No “it depends” or “sometimes” or “maybe.”

If you treat AI as a pure function, you’ve already won half the battle.

Define clearly: what input you give, what output you expect, what counts as correct. Then verify only that — input in, output out, correct? You don’t care what happens in the black box — that’s its side effects, its dirty work, hidden in its encapsulation (see, we’re back to Chapter 2).

The people who suffer with AI are those who treat it as a messy thing full of side effects — they stare at its intermediate steps, get anxious about its unpredictable behavior, and never define a clean input-output-correctness contract. They lack pure function thinking, so they forever argue with an unpredictable entity.

That’s the third mental model. One sentence: What you hand over is no longer code itself, but the thing that generates code; you stand above code, and the more you define the lower layer as a clean pure function, the safer you are.

Chapter 4: Don’t Trust Anything That Can’t Be Falsified

So far, the first three mental models are “constructive” — drop down a layer, decompose chaos, stand above code. They teach you how to build.

The fourth mental model is different. It teaches you how not to be deceived.

It comes from two things I did: reverse engineering and quantitative trading. They seem unrelated — one is tearing apart others’ programs, the other is fighting in markets — but they share a common foundation: adversarial thinking. Surviving in a world that will deceive you.

First, reverse engineering. Its essence is deducing intent from a finished product. You have no source code, no documentation, no author’s explanation. You have a black, compiled thing. You have to walk backward — from its behavior, infer its logic; from its logic, infer its intent.

Do this long enough, and you develop a permanent occupational disease: you don’t believe anything’s surface. A program says it’s doing A; the reverse engineer’s first reaction is: really? Let me see what it’s actually doing. The UI says “secure connection”; he wonders if the connection is actually encrypted. A function called validateUser; he thinks about whether it actually validates or just has the name but returns true directly.

This occupational disease is the most expensive insurance in the AI era.

I said in Chapter 1 that AI’s real danger isn’t that it can’t write — it’s that it confidently writes wrong. This is being studied more and more. One concept worth remembering: when a model summarizes what it did, does it under-report key failures — i.e., it messed something up but downplays or omits it? Newer models are improving in this regard, the under-reporting rate is dropping. But as long as it’s not zero, the reverse engineer’s occupational disease remains essential:

It says it did it right — that doesn’t count. I have to see for myself what it actually did.

This leads to the core weapon of adversarial thinking: falsification.

There’s a simple truth in philosophy of science: a claim is worth believing not because of how much evidence supports it, but because it could be falsified but hasn’t been. A claim that can never be falsified — like “it might rain tomorrow or it might not” — is useless because it’s always right, so it says nothing. What’s valuable are claims where “if it’s wrong, I’d know immediately.”

Translate that to AI: one sentence.

Don’t trust any AI output that cannot be falsified.

AI gives you a piece of code, says it works. “It works” is valuable only if you have something that can immediately falsify it. If you have a set of test cases — input goes in, if output is wrong a red light goes off — then “works” is meaningful because it survived falsification. If you have nothing, just stare at the code and think “looks okay,” then “works” is useless — same level as “it might rain tomorrow.”

That’s why, in the AI era, testing is no longer the cleanup after writing code — it’s the prerequisite before commanding AI.

If you want a bunch of machines to work for you and not be confidently deceived, your only way is to first nail down “what is correct” with tests. Tests are the cage you build for AI — the electric fence that rings when it goes off course. Set up the fence; let it do whatever, because when it strays, you’ll know. Without the fence, it strays and you don’t notice until the error has grown into the system’s bones.

When I did quantitative trading, this mindset was fed with real money.

The market is the world’s biggest liar. A strategy that paints a beautiful curve on historical data is backtesting — the easiest thing to fool yourself with. You can always find a set of parameters that makes the past curve look like art. But no matter how beautiful, that’s past — it’s the strategy “confidently telling you it works.” The only verification that matters is: hit it with data it’s never seen — out-of-sample. Surviving out-of-sample counts. Looking beautiful in history is worth nothing.

See? Same as AI. AI performs perfectly on examples you gave — that’s its “backtest”; it confidently tells you it works. You need to hit it with unseen, tricky, edge inputs — that’s out-of-sample.

And stop-loss. I mentioned the Chandelier Stop earlier. Its soul isn’t in how the line is calculated — it’s in something deeply counter-human: you decide “when I give up” in advance, before you start losing.

Why fix it in advance? Because you don’t trust yourself at the moment of loss. When losing, people find any reason not to stop. “It’ll come back soon,” “this time is different.” Every reason sounds good, every reason makes you lose more. So the smart move is: while you’re clear-headed and not yet invested, write the iron rule. Then when it triggers, execute without second-guessing.

Translate that to AI: your verification criteria must be set before AI works, not after seeing its output.

The difference is day and night. Set criteria beforehand: you’re clear, objective, you define “what is correct.” Set them after seeing output: you’ve been brainwashed by the pretty code — it looks so right, you’ll bend your criteria to match it, like a losing gambler rationalizing “just a bit more.” That’s why so many people let their guard down when using AI — the output is so smooth, so confident, you forget to falsify it.

So this fourth mental model is the gatekeeper for the first three. The first three teach you how to do good work. The fourth teaches you how to confirm it’s actually good, not just looks good.

One sentence: In a world that confidently deceives you, what truly grounds you is falsification, not the accumulation of evidence. And the criteria for falsification must be nailed down before you are brainwashed.

When I did security, I carved that into my bones. The first principle of security: assume everything is lying, then find ways to prove it. I’m not a big shot — a bit better than a script kiddie — but I have that instinct. And that instinct happens to be one of the most valuable in the AI era. Because now you’re facing an opponent better at “confidently lying” than any program. It’s not malicious — it just doesn’t know it’s wrong. And not knowing you’re wrong while expressing unwavering certainty — that’s more dangerous than malice.

Chapter 5: Before the Machine Army, I Already Commanded Two Thousand Avatars

I’ve described the first four mental models at the scale of “building something.” But there’s something that emerges only when you apply these models at large scale. It is itself a mental model — the last and hardest challenge for an architect.

I need to share a not-so-glorious but real experience.

I ran PBN (Private Blog Network) sites for over a decade. What’s a PBN doesn’t matter — just know that I maintained a large collection of websites simultaneously. At peak, over two thousand. Each site needed content, updates, monitoring — needs to detect and fix problems when they arise.

You might do the math now: two thousand sites, how many people?

The answer: mostly just me.

To many, this sounds like bragging. Anyone who’s done it knows it’s not about having more people or being faster. Two thousand sites — even just opening each one for one minute gives you 2000 minutes, over 33 hours — not even enough time in a day. Speed is a joke at this scale.

So what does it rely on? A simple but counterintuitive shift:

You can no longer think of it as two thousand tasks. You must think of it as a system that produces two thousand instances.

See, this sentence strings together the first three chapters.

A site network isn’t two thousand objects — it’s one object. It has clear boundaries and clear contracts (“what a site looks like, what it should have, what conditions mean it’s broken”), and it’s just instantiated two thousand times (OOP). I didn’t write two thousand pieces of content or two thousand configurations — I wrote “the thing that generates content and configuration.” I stood above those two thousand sites (Lisp’s code is data). And what I really monitor every day isn’t the two thousand sites themselves — it’s the falsification grid underneath them. When any site falls outside the normal range I defined, the grid rings, and I check that one (adversarial thinking).

So whether one person can handle two thousand avatars has nothing to do with hand speed or diligence. It only depends on one thing: whether the shell in their mind is made of these mental models.

I’m not telling you this to show off how many sites I ran. I’m telling you something important:

Commanding an army was never invented by AI. AI just made the army free.

Before AI, if you wanted to command two thousand avatars, you had to write scripts, build systems, create the “thing that produces instances” yourself. The barrier was high, so few could do it. AI lowered the cost of “building execution systems” to the floor — now you don’t have to write the production engine line by line; you describe it, and it grows.

But note: what got reduced to the floor is only the cost of building the army. The skill of commanding the army hasn’t gotten any cheaper.

Quite the opposite: it’s become more expensive. Before, few could command armies because of the technical barrier. Now the barrier is gone — in theory, everyone can have an army. So the truly scarce thing shifted from “can you build” to “can you command.” Builders are everywhere; commanders are rare.

And the hardest part of commanding an army — I keep hitting the same wall in 10+ years of running sites and 8+ years of quantitative trading — Too much work is never the problem. The real thing that crushes you is your own brain overflowing.

I need to elaborate because this is the true ceiling of an architect.

A person’s working memory is finite. You might be the smartest engineer in the world, but the number of dependencies you can hold in your head simultaneously, the chains of causality you can think through clearly, has an upper limit. When a system grows to hundreds of thousands of lines, thousands of sites, hundreds of parallel tasks, the internal dependencies exceed any human brain’s capacity. The more you try to hold it all in your head, the faster your “cache” overflows. The result is you neither grasp the whole nor avoid burning out.

That’s why “personally review every line, personally monitor every site” — that kind of diligence — is a fatal kind of stupidity at scale. It looks responsible, but it’s actually using an inevitably overflowing human brain to fight a system that by nature exceeds human brain capacity.

The architect’s solution to this wall isn’t to train yourself into a bigger cache — that’s impossible; the brain is fixed size. The solution is the opposite: design a system where verification is mechanical, not mental. Let the falsification grid remember “what is correct” for you, so you don’t have to cram the status of two thousand sites into your head. Let the clearly defined contracts guard the boundaries, so you don’t have to watch the internals of every object. You outsource “remembering” and “watching” — the most brain-draining tasks — to the system you designed. Your brain is freed up.

What do you do with the freed-up brain? That leads to the final, most subtle skill of commanding an army: the allocation of judgment.

Note: allocation of judgment, not judgment itself.

The scarcest resource for someone commanding two thousand avatars — you might not believe it — is not time or energy. It’s that limited, precious “deep thinking.” If you spread that deep thinking evenly across two thousand sites, each gets shallow, so you’ve effectively done no thinking at all. A truly skilled commander pours 90% of their deep thinking into the 10% that truly bears weight — the key decisions, key boundaries, key contracts that, if wrong, would collapse the whole system. The remaining 90%, they let run on their tracks, never wasting a shred of attention.

The skill of “knowing where to exert and where to let go” is itself a top-tier mental model. It requires an almost intuitive sense of weight: which places deserve you to drop down a layer and check, which are fine with a glance; which tasks require your full mental focus, which can be left alone. People who treat every small thing with maximum effort look diligent on the surface, but underneath they lack judgment — they can’t distinguish heavy from light, so they use force everywhere, and end up having no strength left for the places that truly matter.

In quantitative trading, this lesson cost me the most tuition. Early on, I wanted to optimize everything — every parameter tuned to perfection, every detail pored over. I wasted massive amounts of energy on corners that didn’t affect profit or loss at all, while not thinking deeply enough about the truly life-or-death risk management and stop-loss logic. Later I learned to compress the vast majority of my brainpower onto the few load-bearing decisions — e.g., exactly how to define stop-loss, exactly how to manage position sizing. The rest: set contracts, put up the grid, let it run. If something goes wrong, the grid rings, and I come back.

That’s the whole secret of commanding an army: It’s not how much you can hold, but how much you dare to let go. It’s not how hard you push everywhere, but knowing where to push.

So when everyone is excited that “AI can do hundreds of tasks in parallel,” I want to pour some cold water: the army is free, but your overflowing brain hasn’t been upgraded. The machine gave you a thousand hands, but not a thousand brains. Where to direct those thousand hands, which places deserve your one and only brain to dive into, which ones you trust to the grid and let go — that judgment, machines cannot replace.

It, exactly, is the thickest and hardest part of the shell.

Chapter 6: Architect – Four Mental Models Collapse into One Person

Now put the four mental models together, and you’ll see something interesting: they are the same person approaching from four directions.

The person who drops down a layer (assembly thinking), the person who decomposes the world into objects (OOP thinking), the person who stands above code (Lisp thinking), the person who doesn’t trust surfaces, only falsification (adversarial thinking) — these four people merge into one, the only role that’s still appreciating in the AI era:

The Architect.

I need to pull “architect” off its pedestal first. It sounds lofty — like someone in a plaid shirt drawing UML diagrams on a whiteboard. No. The architect’s essence is dirt simple, one sentence: He is the one who turns chaos into something executable and verifiable.

He can drop down a layer, so when abstraction leaks, he doesn’t panic.
He can decompose a blob of requirements into objects with clear boundaries, so machines know what to do.
He stands above code, so what he writes is generators, not products.
He doesn’t trust surfaces, only falsification, so machines can’t fool him.

These four together form a complete loop. And that loop happens to be