Two friends have opposite views on AI.
One says, AI can’t write my code at all. I maintain a service chain across four teams — just figuring out the state machine for each step takes two weeks. AI can’t even grasp the system’s boundary conditions. What it writes looks fine, but the moment you run it, everything crashes.
The other says, AI is great. Writing an API used to take half a day; now I just say a couple things to it and it’s done in ten minutes. Can’t live without it anymore.
Both are right. But they’ve fallen into the same trap. One is arguing that AI can’t do something as complex as my work. The other is arguing that AI lets me do my work faster. Both are answering the same question: can AI handle the job I do now.
Nobody asked the other question: where does the complexity of my current job actually come from.
Chen Ran wrote about his own experience in a recent article. He judged that continuing to sell software modules made less and less sense; what mattered more was driving down delivery prices and handing over the results customers actually wanted. So he disbanded an engineering team of about twenty people, pulled out the project managers, and redid the services from scratch.
During the rewrite he noticed something. A lot of the original complexity wasn’t what the customer needed — it was produced by the organization itself over long periods of operation. The processes got a bit more complex, the systems got a bit more complex, the interfaces got a bit more complex, and the project management got a bit more complex too. Each layer of complexity had its own reason, and each could be written into a quarterly review. But when you work backwards from the customer’s result and rebuild the thing, you find that what the customer wants is often much simpler.
This discovery is everywhere in big companies. What big companies do is, in essence, a social division of labor at scale. A massive problem gets sliced into hundreds of small blocks, and everyone is responsible for one block. Division of labor drives productivity up, but the price is that everyone can only see their own block. Your performance, your promotions, your technical depth — all tied to this block.
The question is: of the complexity inside your block, how much comes from the technology itself, and how much comes from coordination among the hundreds of blocks? That compatibility layer you maintain is probably there because of a compromise made during another team’s migration two years ago. The design doc you’re writing — the core problem it needs time to solve is how to get three teams to agree. These things get filed under “engineering depth” inside big companies. But their essence is organizational knowledge, not technical knowledge.
The longer you stay in this environment, the easier it is to conflate the two. Inside a big company they look identical: both are complex, both require experience, both make you irreplaceable. But there’s a fundamental difference. Technical depth travels with you. Organizational complexity disappears the moment you leave the organization.
Back to those two friends from the beginning.
The one who says AI can’t cut it — his judgment holds on the surface. AI really can’t write his code. But the problem is the conclusion he draws from this fact. He thinks AI can’t do it because AI isn’t mature enough. Look at it another way: AI can’t do it because the complexity of that code isn’t technical in the first place. AI can see the code, but it can’t see who made what deal with whom in that meeting two years ago. This missing capability doesn’t reflect that AI isn’t good enough — it reflects that AI has hit its boundary. Treating it as proof that AI is no good is like using a big company’s internal ruler to measure the entire world.
The one who says AI is great — his judgment also holds on the surface. AI really does make him faster. But he’s carrying an implicit assumption: doing my job faster means I’m more valuable. This assumption looks fine inside a big company, because that’s exactly how the performance system rewards him. But outside the organization, it may not hold. A screw spinning faster doesn’t mean the machine produces more. He’s optimizing a pre-defined position, and that position itself may be waiting to be redefined.
The shared blind spot for both is that they treat their current job as a fixed reference point, then ask whether AI can handle it. But this job is itself a product of the big company’s specific organizational environment. The environment is changing, and the ruler they’re using to measure AI is changing too. They just don’t realize it.
So before judging whether AI is up to the task, you can think about something more fundamental first. Of the work you spend the most time on each day, how much of its complexity comes from the technical problem you’re solving, and how much comes from the organization you’re in?
If it comes from the technical problem itself, the good news is your skills are transferable. But technical complexity is only worth money when there’s a demand willing to pay for it. The same database optimization skills are worth money at Google, because its business model depends on the speed of large-scale data access. Doing the same thing in a product with a hundred daily active users isn’t worth much, because that business doesn’t depend on it. The skill hasn’t changed; what’s changed is whether it’s worth money. So the better question to ask is: does my complexity serve something someone pays for?
If most of the complexity comes from the organization, the earlier analysis already made it clear. The complexity you’re facing disappears the moment you leave this organization.
Whichever case you fall into, you can’t avoid the same thing. The big company does too much for you. Finding customers — someone’s job. Defining requirements — someone’s job. Accepting deliverables — someone’s job. Collecting payment — someone’s job. As an engineer, the only thing you touch is the very last link in the entire chain. You think these things have nothing to do with you, and inside the big company, they genuinely don’t. But they’re exactly the first things you’ll need to face once you leave this environment.
So how do you start engaging with the things that have been shielded from you?
Chen Ran’s advice in that article is to first run a complete business loop: find a customer, deliver something, collect a payment. The advice itself isn’t wrong. But for a big company engineer, the leap is too large. You don’t have channels to reach real users, you haven’t been trained to understand requirements, and you don’t even have the information to answer the question “who is paying for what.” Running the loop is a destination, not a starting point.
A better starting point is something you’re already good at: build. But with one condition — do it in public.
build in public means the things you make need to be shown to people. Not for marketing, but to push yourself into a few positions you normally don’t touch. How do you get someone to understand what you’re doing in three seconds. How far off is their reaction from what you expected. What adjustments do you make based on that feedback. Inside a big company, someone does all of this for you. Do it yourself once and you’ll understand why it’s worth money.
This doesn’t require quitting your job or building a complete product. A script, a small tool, a piece of analysis — anything works. The key is to get it off your computer, let real people see it, and then listen to what they say. Some projects start out tiny but gradually find their direction through feedback.
If you’re looking for a place to start, the Superlinear Academy community has a section for sharing projects. The people there also started from a similar place — they built something, put it out in public, and adjusted based on others’ feedback. You don’t need to wait until you’re “ready” to join, because that state won’t arrive on its own.
Chen Ran says in his article that a big company is like a ship heading toward an iceberg — better to start practicing swimming than to study how to upgrade your cabin. He’s talking about the ship’s fate.
What I want to talk about is the other side. Even if the ship doesn’t sink, the skills you built on board may not work in the water. Whether the ship sinks or not, you need a set of capabilities that doesn’t depend on a specific environment. build in public is the swimming you can start practicing right on the deck. It starts from the feel you already have, but each step forces you a little closer to the water’s edge.
Before you judge your relationship with AI, first judge where your complexity comes from. Once you’ve thought it through, go build something small and show it to people. The rest, feedback will teach you.
本文由 GLM 5.2 写作。