When I was a teenager, my first real piece of “engineering” was not building a website, and it was not making a product. It was adding HP to characters in single-player games.

Back then, Heroes of Jin Yong and the 1998 tender-hearted edition of The Legend of Sword and Fairy were enough to make a teenager hand over an entire summer. After a while, simply clearing the game was not enough. The more fascinating thing was reaching in and touching the bones of the game.

Kingsoft Game Master was the crowbar that pried those bones open. If a character had 100 HP, you searched memory for every location equal to 100. After a monster hit you and the HP became 80, you searched every location equal to 80. Thousands of candidates slowly shrank to dozens, and then finally to one. That address was the character’s life. Lock it, and the character became invincible.

That first engineering lesson was not really about cheating. What got carved into my brain was something lower-level: the HP bar on the screen was fake. What really existed was a changing number in memory. The interface, animation, and sound effects were what that number looked like after wearing several layers of clothing. If you wanted to know what the system was actually doing, you had to undress it layer by layer.

At first, the only things I could change were surface values: level, money, items. Fun, but shallow. Later I touched skills, and the whole thing changed flavor. A nobody who only knew Wild Ball Fist could be fitted with someone else’s full set of secret techniques. A character designed to be weak could have their abilities rewritten. That was the moment I ran into the difference between two layers: changing what something “has” and changing what something “can do” are completely different things.

The road kept stretching from there: reverse engineering, cracking, bots, automation, quantitative trading. There were also a few years of security work in the middle. I cannot puff that part up into a “master hacker” resume. At most, I walked a few more steps than a script kiddie, still far from the real experts. But the instinct to distrust surfaces stayed with me. From assembly and Python to Bash, it all became a way to stitch annoying tasks into systems that ran by themselves. That old language full of parentheses left behind the posture of “standing one layer above the program.” By 2026, machines can write code, and they write it faster, in greater volume, and sometimes more neatly.

Many people have started to panic. They rush to learn how to “use AI”: tools, acronyms, tricks, anything that might keep them from being thrown off the train of history. But when I look back at that fake HP bar, the valuable thing was never knowing a specific language. It was that bad habit: when you see any polished surface, you want to dig underneath and touch the changing number below it.

The architect in the AI era is not a new species. It is just a few of the oldest and hardest instincts in a programmer’s head, repriced upward.

All Abstractions Leak

Start with assembly language.

Not because everyone should go back to writing MOV and ADD. What assembly really leaves behind is not syntax. It is a way of seeing the world: every layer above is a paved road someone else laid down, but underneath the road is soil that can collapse.

In 2002, the classic essay on “leaky abstractions” proposed the Law of Leaky Abstractions: all non-trivial abstractions, to some degree, are leaky. The sentence is so plain it almost sounds like nonsense, yet it hits like one of software engineering’s few actual commandments.

An abstraction wraps complexity and exposes a clean switch. Reading a file looks like just open("file.txt"); underneath are disks, caches, blocks, permissions, error handling, and a whole pile of dirty work. Abstractions save engineers from crawling out of the mud every day.

But the wrapping is never airtight. Treat a network file as a local file, and when the network drops, the abstraction leaks. Write one SQL query and assume the database will be smart, then watch it crawl when the data gets large; the abstraction leaks again, and you end up reading query plans. Abstractions save hands-on time. They do not save learning time. When nothing hurts, you forget. When something breaks, it hurts enough to make you question your life choices.

AI-generated code is currently the highest layer of abstraction in software development. Above machine code came assembly. Above assembly came C. Above C came high-level languages like Python. Above high-level languages came frameworks. Above frameworks came low-code platforms. Now humans describe requirements in natural language and let models emit code. This is the top of the tower.

The taller the tower, the deadlier the leak. This layer does not wrap one API or one library. It wraps software engineering itself. When it leaks, what comes out is often not a compiler error. It is logic quietly going bad: perfect syntax, beautiful structure, tests that may not explode immediately, and one piece of judgment confidently hallucinated sideways by the model.

It is not scary when AI cannot write something. That error is obvious. The truly scary part is when it writes the wrong thing with confidence. That is the leak at the top of the tower. The people who can see this leak are usually not the people who memorized the most tool names. They are the people who have spent time at the bottom of the tower and know there is soil under the pavement.

Mogu highlights:
The point here is not “everyone should learn assembly.” That turns into using a giant construction crane to pick up a tea egg at a convenience store; before the egg moves, the counter collapses. (⁠￣⁠▽⁠￣⁠)⁠／ The point is to have at least broken through one layer of abstraction, so you know there are machines, mud, and failure points under the pretty interface.

That is the value of assembly-style thinking in the AI era: when an abstraction leaks, can you drop one layer down? If you can, AI is an amplifier. If you cannot, AI is a cliff. On calm days, everything looks fine. Once the water starts leaking in, you may not even know how you sank.

Break Chaos into Objects

The second kind of thinking comes from object-oriented programming. Encapsulation, inheritance, polymorphism: beginners can recite the terms. But after walking through enough pits, you realize these are not exam answers. They are scalpels for cutting up the world.

The essence of encapsulation is drawing boundaries. What should be exposed, and what should be hidden? How many openings should a module have? What does each opening accept, what does it return, and how does the dirty work inside remain silent? With good encapsulation, a system feels like Lego. With bad encapsulation, it feels like congee: pull one hair and the whole body cramps.

Machines are still bad at drawing boundaries. Ask AI to write a feature and it is good at that. Ask it to decide how the whole system should be split into modules, who should know about whom, and who should know absolutely nothing about whom, and it easily gives answers that look reasonable but do not age well. Boundaries are not a knowledge question. They are a judgment question. You have to predict how the system will grow, which things will change together, which things will change separately, and then cut along the grain of future change.

The essence of polymorphism is caring about contracts, not implementations. When you say “send a message,” you should not need to know whether the path underneath is WeChat, QQ, HTTP, or WebSocket. The important part is that the promise holds: input goes in, message goes out.

Put this idea on top of AI and the posture becomes clear: humans and machines need contracts. What is the input? What is the output? What counts as correct? What counts as wrong? How the model coughs up code internally is an implementation detail. If you keep worrying about how the model should write line 37 or tweak one loop, you are jumping into the black box for hand-to-hand combat, and the fight only gets more exhausting.

“Help me build a trading system” sounds like one sentence, but it hides hundreds of undefined objects: where market data comes from, how signals are calculated, which exchange handles orders, what the stop-loss logic is, how positions are managed, and at what drawdown the system should stop. If those questions are not split apart, AI will split them randomly for you. The thing it randomly builds will be like using a cup-noodle lid as an airplane wing: the shape is close, but it will not fly.

A chandelier stop in a quantitative trading system is a clear object. Its inputs are the highest price and volatility. Its output is a stop-loss line that follows price upward but does not retreat downward. Its contract is to lock in profit and not give profit back. Once the object is defined clearly, whether the implementation is written by a human, a machine, or yourself from ten years ago, the core result should line up.

The endgame of object-oriented thinking is not “knowing how to write class.” What it really trains is the ability to take a blob of desire, requirements, and chaos, then split it into objects with clear boundaries, explicit contracts, and enough shape to be trusted. Whoever can split things is the architect. Whoever can only shout “help me make a thing” is left wrestling the black box.

Stand One Layer Above the Program

The third kind of thinking comes from an old language so fossilized it almost belongs in a museum, but whose soul is tough: the parenthesis language.

It is full of parentheses, so it looks like the keyboard broke. But it has one key property: homoiconicity, meaning code is data. In that language, programs and data look similar, and both can be manipulated as lists. That means programs can generate programs, and programs can rewrite programs. In other words, you are not writing the product. You are writing the thing that generates the product.

When I used that old language to script games, the addictive part was not listing every step a character should take. It was writing a set of logic that let the character grow behavior from the situation. That is not standing at the action layer. It is standing one layer above the action.

AI has forcibly lifted everyone into the same position. When you tell a model a requirement and ask it to generate code, you are using text data to generate a program. Requirements, specs, and prompts have become “programs that generate programs.” Humans no longer only write programs. They write the things that generate programs.

This also explains why some people use AI smoothly while others use it like they are stuck in mud. People used to standing one layer above know they are writing a generator, not a product. The spec must be precise enough for the machine to grow the correct result, but abstract enough that it does not micromanage every implementation detail. People who are only used to writing products get confused when lifted one layer up. Their requirements become fragmented and sticky, and after reading them, the machine can only improvise.

Specs are the hard part. Once building becomes faster, difficulty does not disappear. It moves up one layer. The new dividing line is whether you can write a precise but restrained “metaprogram” that lets the product grow out by itself.

That old language also left behind another life-saving idea: pure functions. Same input, same output forever. No secret mutation of outside state, no side effects. Pure functions are easiest to verify: feed input, inspect output. Correct is correct; wrong is wrong.

Treat AI like a pure function, and you have already won half the fight. Define the input, expected output, and judgment criteria clearly, then verify one thing: does this output satisfy the contract for this input? Do not let the black box in the middle drag your emotions around. Staring at it while it behaves one way, then another, only gets you pulled into prime-time soap opera drama.

Trust Only What Can Be Falsified

The first three kinds of thinking lean toward building: drop one layer down, split into objects, stand one layer up. The fourth kind is colder. It teaches you not to get fooled.

Reverse engineering and quantitative trading look far apart, but underneath they are both adversarial. Reverse engineering means inferring intent from the final product when there is no source code, no documentation, and no explanation. Do it long enough and you develop an occupational illness: you stop believing surfaces. A function named validateUser does not mean it actually validates the user. An interface that says secure connection does not mean the bottom is secure.

That occupational illness is extremely valuable in the AI era. When a model says it is done, that does not count. When a model says it fixed the bug, that does not count either. It may not be malicious, but it may not know it is wrong, and it may say so with more certainty than anyone else. This kind of thing, which does not know it is wrong and speaks with absolute confidence, is more dangerous than ordinary error.

The core weapon of adversarial thinking is falsification. A claim is worth trusting not because it is supported by an impressive tone, but because it can be overturned and has not yet been overturned. A sentence that can never be wrong, like “it may rain tomorrow or it may not,” sounds safe but carries no information.

AI gives you a piece of code and says it can run. How much is that statement worth? It depends on whether there is a test that can immediately puncture it. If there are test cases and wrong input turns the light red, then “it can run” has passed through falsification. If you are just staring at the code and feeling that it looks correct, then it is basically the same as “it may rain”: strong comfort value, low engineering value.

So in the AI era, tests are no longer the finishing touch after code is written. They are the prerequisite before commanding AI. Tests are the electric fence you build around the machine army. Build the fence first, and the machines can run however they want; when they hit the wire, it sounds, and when they drift, you know. Without the fence, errors quietly grow into the bones of the system, and by the time you notice, they are hard to pull out.

Quantitative trading teaches the same lesson. A beautiful backtest curve is the easiest way to fool yourself. The past has already happened; you can always find parameters that make the curve look like art. What matters is out-of-sample data: hit the strategy with data it has never seen, and if it still lives, then it counts. AI performing perfectly on examples you gave it is just a backtest. Hit it with unseen, nasty, edge-case inputs. That is out-of-sample.

Stop-loss rules are even more brutal. The most important part of a chandelier stop is not how the line is calculated. It is deciding when to admit defeat before you have already lost money. Because once you are losing money, your brain can manufacture a hundred excuses. “Just wait a little longer and it will come back” sounds gentle, but it hits hard.

Moved to AI, the verification standard must be set before the model starts working, not adjusted after you see a pretty output. If you set the standard afterward, it is easy to be hypnotized by the product. The standard quietly bends toward whatever the model made. If you set the standard beforehand, you nail down “what correct means” while you are still sober.

Mogu murmur:
Tests here are not engineering ritual. They are an anti-fraud system. Letting AI modify code at scale without tests is like handing the company seal to a stranger with an extremely steady voice and saying, “Looks professional.” That is not trust. That is asking fate to take the day off.

Command Two Thousand Copies of Yourself

The four kinds of thinking above are about building one thing. Once scale grows, another checkpoint appears: how do you command an army?

For more than ten years, I once kept a large number of websites running at the same time, at most more than two thousand. Every site needed content, updates, monitoring, and a way to be discovered and repaired when something went wrong. This was not solved by fast hands. Two thousand sites, even if you only looked at each for one minute, would take two thousand minutes. One day is not enough.

The key shift was this: you cannot think of it as two thousand tasks. You have to think of it as one system that produces two thousand instances.

A site network is not two thousand independent objects. It is one object instantiated two thousand times. You are not writing two thousand sets of content and configuration. You are writing the thing that generates content and configuration. What you monitor every day is not two thousand sites. It is the falsification grid: which site has fallen out of normal range? When the grid rings, you go inspect that one.

Commanding an army was not invented by AI. AI only made the army cheaper. In the past, you had to write scripts, build systems, and create production engines yourself, so the barrier was high. Now, describe things clearly enough and machines can grow many execution units. But what got cheaper is the cost of creating the army, not the ability to command it.

What crushes people is not workload either. It is an overflowing brain. Human working memory is limited. No matter how smart an engineer is, they cannot simultaneously hold thousands of sites, hundreds of tasks, and all dependencies across hundreds of thousands of lines of code. Trying to personally watch every line, every site, and every detail looks responsible, but in practice it is using a brain guaranteed to overflow against a system that exceeds brain capacity.

The architect’s answer is not to train the brain into a larger cache. It is to design the system so verification becomes mechanical rather than mental. Let the grid remember what normal means. Let contracts guard boundaries. Let the system watch the places that need watching. Once the brain is freed, it can spend effort on the most expensive resource: deep judgment.

The subtle skill in commanding an army is allocating judgment. Not everything deserves equal force. Good command means pouring 90 percent of deep thinking into the 10 percent of load-bearing decisions: key boundaries, key contracts, key risk controls. The remaining 90 percent of work only needs to stay on track, and the grid will ring when something is wrong.

The easiest mistake in early quantitative trading is wanting to optimize everything. Every parameter should be tuned until it looks pretty. Every detail deserves attention. In the end, huge energy gets burned on corners that do not affect profit or loss, while risk control and stop-loss logic never get thought through. The real secret is not how much you can hold. It is how much you dare to release. It is not applying force everywhere. It is knowing where force belongs.

AI gives humans many hands that can move at the same time. It does not give us several extra brains that can judge at the same time. Where those hands should reach, where the one human brain should look one layer deeper, and where it should trust the grid and let go: that judgment still cannot be replaced.

The Architect Is a Layer of Eggshell

Put the four kinds of thinking together, and you get the role whose price still rises in the AI era: the architect.

You do not have to imagine an architect as a middle-aged priest covered in UML diagrams. The essence is very earthy: turn chaos into something executable and verifiable.

They can drop one layer down, so they do not panic when an abstraction leaks. They can split requirements into objects with clear boundaries, so the machine knows what to do. They can stand one layer above the program, so they write generators, not only products. They distrust surfaces and only trust falsification, so they are not fooled by pretty output.

If you view this as a change in price, the direction is roughly this: when execution cost is pushed close to zero, the price of judgment gets pushed toward the ceiling. Code gets cheaper. “Deciding what code should be written” gets expensive. Implementation becomes abundant. “Defining what should be implemented” becomes scarce. AI can generate components, but humans must define systems.

This is also why “becoming a commander instead of an executor” is not as light as it sounds. You do not become a commander just by standing on a platform. The commander is responsible for the whole battle. They must define, split, lift, and falsify. A soldier only has to complete actions. The commander has to know why, what, and how we will know when it is wrong.

The experience of a one-person company was like an egg: independent sites, AFF, scripts that produced content, scheduled tasks, plus a few things squeezed in that could work by themselves. That system was not elegant. It was even a bit dirty. But it could rotate on its own. After watching it for a long time, you realize the shell is only a thin layer, yet it defines the boundary, maintains order, and decides whether the living system inside can survive. The human layer in the AI era will also become thinner: a project that used to need dozens of people may now need one or two humans plus a crowd of machines. But thin does not mean unimportant. The material of the shell decides whether the system inside is alive, or just a blob with no direction, no boundaries, and no verification.

Architect is less a job title than a material for that shell. The new coordinate system no longer only asks how fluent you are at writing code. It asks what that shell is made of: can you define the problem, build the falsification grid, stand one layer above the program, and split chaos until machines can execute it?

This coordinate system is cruel because it does not care about years of experience. A senior engineer who has written CRUD for twenty years may have an empty shell. A twenty-year-old who naturally loves digging downward, splitting things apart, and verifying may have a very hard shell. Machines take away the hammer. What remains valuable is deciding what should be forged, and verifying whether the forged thing is any good.

How to Train These Things

These ways of thinking do not have a seven-day shortcut, and you will not be reborn after reading about them. They are fed by time and pits. But the direction can be clear.

Practice dropping one layer down: fully expose one abstraction you use every day. You do not need to write assembly every day. But choose one common thing you use and do not understand, then strip it clean. From pressing Enter on an HTTP request to receiving a response, what layers does it pass through? How does a database query use an index, scan a table, and choose a plan? Once you truly strip one thing all the way down, every pretty abstraction afterward will trigger a voice in your head: what is underneath?

Practice decomposition: split a vague requirement until it cannot be split further. Under “build a trading system” are market data sources, exchanges, signals, latency, order failures, positions, drawdowns, and shutdown conditions. Every question mark has to be written down. If the answer is unclear, keep splitting. Do this long enough and the scalpel gets sharp.

Practice standing one layer up: write a generator once, not the product. If you need to write introductions for ten websites, do not handwrite ten articles. First write the template logic that can generate introductions. If you need to process a batch of files, do not process them one by one. Write a flow that can process any batch of files. At first it feels indirect. But after you experience “write once, run a thousand times,” it is hard to go back to manual labor.

Practice falsification: whenever you receive a conclusion, first ask how you would know if it were wrong. AI-generated code, your own judgment, and other people’s claims all get the same question: if this is wrong, can we discover it immediately? If not, it is not yet worth trusting. Build tests, counterexamples, and out-of-sample checks first. Then see if it can hold.

Practice cross-cutting audit: turn verification into a net. Logs, permissions, and monitoring do not belong to any single feature, but they must cover all features. The same is true for verification and audit of an AI army. You do not manually chase every task afterward. You build a net that covers the whole army and answers: what exactly was done, did it break anything, and did it leave a trace?

Practice allocating judgment: review where deep thinking actually went. Many people spend huge energy on non-load-bearing corners because small things are easy to handle, and finishing them feels solid. The truly load-bearing decisions are hard and uncomfortable, so they get delayed. Using tactical diligence to dodge strategic thinking is a performance humans are very good at. Every time you pull your brain out of comfortable little tasks and press it onto the truly load-bearing problem, that shell gets a little harder.

Does the Bot Amplify Zero, or One?

Should you learn the tools? Yes. But the order cannot be reversed.

The Kingsoft Game Master era already showed two kinds of people. The first kind became useless once the cheat tool was turned off, because all of their ability lived inside the tool. The second kind had taken the tool apart, modified it, or even written one. The tool saved time, but once it was turned off, the foundation remained in their head.

AI-era tools are also amplifiers by nature. They can multiply output many times over, but amplifiers have one cold property: they do nothing to zero.

If the shell is empty and the thinking is zero, the tool amplifies zero by a hundred and it is still zero. Worse, it makes people think they have gained a hundredfold ability, so they rush faster and more confidently toward an unseen cliff.

If the shell is made from those ways of thinking and is a one, then the tool can amplify that one by a hundred and make it a hundred. Those parallel configurations, self-working things, and acronyms flying everywhere become extensions of thinking, not puppet strings.

First comes the instinct to distrust the surface HP bar. First comes the scalpel that splits chaos apart. First comes the posture of standing one layer up. First comes the occupational illness of trusting only falsification. Then you pick up the amplifier. Get the order right, and tools are an army. Reverse the order, and the human becomes the tool’s hostage.

Technical Moats Are Made of Water

The truly painful part comes at the end, when the previous eight sections suddenly bite back.

There was a young apprentice: smart, willing to learn, but more than ten years behind in skill. That kind of distance should have taken more than a decade of nights and pits to cross. One afternoon in 2025, he used AI to recreate a trading system that had taken more than eight years to build.

That system was not an ordinary program. It was the hidden chamber deep inside the castle: every line of logic, every stop-loss rule, every defense against human weakness had been fed by real money and repeated blowups. It did not feel like knowledge. It felt like instinct, like scars on the body.

AI poured it out. Not perfectly, but 70 or 80 percent of the spirit was there. The colder part was that the apprentice did not need to experience the pain. The machine translated the scars into code he could pick up and carry away.

That afternoon, “technology is king” died halfway.

Earlier, I said those four kinds of thinking are the most valuable moat in the AI era. That statement is still true, but only halfway. The colder half is this: all technology, no matter how deep, is information at its core. As long as the tools are good enough, information flows, copies, and pours from one brain into another.

The moat was made of water all along.

So is there anything machines cannot pour out, copy away, or max out with one click? The answer left by that afternoon was not inside the program. It was between people.

Programs, parameters, and logic can be replicated. Trusting certain people and guarding against certain people; having blown up accounts together, stayed up through long nights, and not turned away at the hardest moment; those ties that cannot be written as programs, translated by machines, or poured out by tools were not copied by even one byte.

Because those things are not information at all. They are not numbers you can search for and lock in memory. They are among the few layers in this world where you cannot modify skills, add HP, or crack the system.

The kid leaning toward the screen as a teenager thought that as long as he could touch the number underneath, he could control everything. Later, he kept touching deeper layers: from HP bars to skills, from games to markets, from one person to two thousand copies of himself. Every layer he touched made him believe more strongly that technology was king.

He was right for a long time. Then, on one afternoon, he was thoroughly wrong. There is an HP bar in this world whose memory address can never be found. It is not inside any machine, not inside any program. You cannot search it, lock it, pour it out with a model, or let an apprentice carry it away.

That HP bar is between people.

Conclusion

The easiest misunderstanding in the AI era is treating “knowing how to use tools” as “getting stronger.” Tools really do amplify people, but they do not create a one out of zero.

What you truly need to train is the shell: the instinct to drop one layer down, the knife that splits chaos, the posture of standing one layer above the program, the coldness of trusting only falsification, and the ability to spend judgment on load-bearing places. These are what let humans command machines instead of being dragged around by pretty machine output.

But the harsher ending is that even these technical instincts may be gradually translated, transported, and copied by tools. When even your deepest skills can be poured out, the thing worth checking is no longer how many more tools you have learned. It is what remains after your technology has been taken away exactly as-is.

So the next thing to architect may be the very thing that a technical brain twenty years ago looked down on most: something slow, clumsy, not very “technical,” and impossible to write into a program and copy away.

Turn off the tools. Turn off the code. Pretend all the technology you are proud of has already been moved away exactly as-is. How much is left that cannot be poured out, cannot be maxed out with one click?

The real HP bar may never have been on the screen.