To The Crazy Ones

The super individual is a fundamental personality structure.

👦🏻 Author: Henry[0](DeerFlow team)

🥷 Editor: Koji

🧑‍🎨 Layout: NCon

In 1997, after returning to Apple as interim CEO, Steve Jobs personally wrote and narrated the voiceover for the Think Different campaign.

In my view, Jobs had already given the most fitting definition of the "super individual" thirty years ago: The Crazy Ones.

Preface

A Thought Experiment

Let's try an interesting thought experiment:

• 👨🏻‍💻 If, in late 2024, Claude Code founders Boris Cherny and Cat Wu joined your department, and as recent hires they proposed building a command-line-only coding agent — Claude Code — would your department approve it?
• 🦞 If, in late 2025, OpenClaw founder Peter Steinberger worked at your organization and proposed building a 24/7 OpenClaw, would your company sponsor him? Would they let one person own a project/product?

The most easily misjudged phrase is: "We need to cultivate super individuals."

It sounds timely, but it still carries the imagination of the old world:

Send employees to training, give them a set of AI tools, set KPIs around AI adoption rates, hand out certificates, then drop them back into their original positions, responsibilities, and reporting chains — expecting them to naturally produce 10x output, because Anthropic says they did.

My judgment is the opposite: super individuals aren't trained; they're activated by curiosity.

Whether someone can become a super individual depends on more than competence. What matters more is whether they have intense curiosity, whether they're willing to explore the unknown, whether they can self-teach, self-motivate, and turn a vague idea into something usable with their own hands. In other words, a super individual isn't a "stronger role-player," but someone who can reclaim a complete closed loop. Some readers mentioned FDE; you can refer to my article FDE — Has the AI-Era Career Transition Already Begun?[1]

Today, I'd rather call these people AI Builders than trendy terms like "super individual." Through long-term involvement in open source and community, I've been fortunate to meet many people who fit the AI Builder profile at work. They once seemed entirely ordinary: developers, QA engineers, product managers, designers, even HR, BD, and VC investors. But they share one striking trait: when they talk about the AI projects they're building, they can't help but go on and on. In that moment, you easily see the light in their eyes. It's not fleeting excitement about new technology, nor speculative enthusiasm for a hot trend, but something more plain and enduring: they genuinely want to make something, to make it run, to have real users use it, to personally participate in the changes happening in this era.

That's who this piece is for. This isn't an AI coding tutorial for engineers, nor a personal branding manual for entrepreneurs. It's written more for HR, OD professionals, organizational researchers, talent development leaders, and executives at large companies: when you discuss "AI-era talent strategy," the real question isn't "who can use AI," but "does the organization allow a person to go from problem discovery all the way to delivering results."

The daily life of the old role-player often looks like one link in this waterfall:

This waterfall process was once the efficiency engine of industrialized internet. The problem: when AI compresses research, prototyping, coding, testing, copywriting, and data analysis back to a single person, that role-based division starts becoming impedance. Human capability has clearly been amplified by tools, yet the organization still slices them into a local function.

This is the core tension of this article: big companies don't lack talent; role design fragments people.

As Steve Jobs wrote in the Think Different campaign[2], using very short words to describe a certain kind of person: misfits, rebels, troublemakers, and those who see things differently. I don't want to mythologize this copy. Its real value is reminding organizations not to understand creativity solely through "compliant talent models." Many people who drive new productive relations are naturally "round pegs in square holes." They may not be the best at writing OKR reports, not the most skilled at alignment, but they get their hands dirty, they work around inertia, they turn unchartered problems into real things.

Do you know — Naval's three types of leverage? In The Almanack, Naval Ravikant divides commercial leverage into three categories: labor, capital, and "products with no marginal cost of replication." Code and media belong to the third category — almost permissionless, something an individual can launch; labor and capital still require organizational backing. That is, organizations haven't disappeared; they simply must learn to work with new individual leverage. See Find a Position of Leverage[3].

So this article doesn't discuss "how to train every employee into a super individual." That's still assembly-line thinking.

Nor does it treat the super individual as some kind of personal brand persona. What truly deserves organizational attention is whether a person can turn curiosity into action, action into work, work into something delivered to real users, and feed that feedback back into their own judgment system. This is closed-loop behavior, not a competency label.

What this article actually wants to discuss is something else: if the raw material for super individuals already exists scattered inside large companies, how can organizations provide the soil for these people to be fully activated through closed loops.

Because closed loops weren't invented by AI. AI simply made an old capability scalable again.

The answer starts in an era that seems distant. There were no LLMs, no agents, no organizational middle-platforms; many people were still on dial-up. Yet programmers of that era were more complete human beings than many big-company employees today.

Prehistory

I started undergrad in 2002. The Chinese internet was still small, but the software world was bustling. The most common scene in dorms was someone digging tools from the CD bundled with Computer Weekly, someone checking HuaJun Software Park or Sky Software Station for new versions, someone copying a zip file to a USB drive and passing it around. Whether software was good didn't depend on launch events, growth teams, or paid acquisition. It depended on forum word-of-mouth, download site recommendations, magazine editor reviews, and users telling each other "this one works well."

Looking back, that was a wild, vibrant era of a hundred schools contending: many programmers were naturally hexagonal warriors — who wasn't a "company of one"?

They started from their own itch, discovered a problem; then designed the interface themselves, designed the logo, wrote the code themselves, packaged and released it themselves, wrote the documentation themselves, went to forums to answer user feedback themselves, read users complaining about what was hard to use, and emailed software download sites and computer magazines themselves. For smaller teams, even marketing copy, logos, FAQs, installers, user group maintenance all sat with the same person or two or three people.

This wasn't because they had studied "product manager competency models." On the contrary, many roles hadn't even been formally named yet. Product sense, design sense, engineering ability, communication awareness, user feedback — these grew out of a real closed loop.

There are plenty of examples like this in China. Allen Zhang's Foxmail is the most iconic: a 2001 SINA Corporation interview with Zhang still discussed Foxmail in the context of "domestic shareware," mentioning its free strategy and user base at the time for Foxmail 4.0. A later Jiemian News retrospective also explicitly noted its 1997 launch, positioned as free software from day one. More cautiously put, it's a representative case study in the domestic shareware/freeware context. See the SINA Corporation archives[4] and Jiemian News retrospective[5].

FlashGet followed a similar path. Its official tenth-anniversary page states it clearly: JetCar debuted in 1999, was renamed FlashGet in 2000, and gained traction by solving the pain points of dial-up era with multi-threaded downloads and file management. See the FlashGet tenth-anniversary timeline[6].

The same pattern held abroad. Nico Mak Computing, the predecessor to WinZip, states on its official page that it was founded by Nico Mak in 1991. The ACDSee website notes that the first version was distributed via BBS in 1994 for $15. Winamp is generally traced to Justin Frankel, Dmitry Boldyrev, and others releasing the player in 1997, which later became the defining software of the MP3 era. See the Nico Mak Computing retrospective for WinZip[7], ACDSee About[8], and TechSpot's Winamp retrospective[9].

I was fortunate enough to live through that era, and in 2002 I wrote my first shareware to break ten thousand users — MagicCube Lyric Editor[10], a solution that could automatically find, download, and edit embedded MP3 lyrics and upload them to MP3 players (the hardware kind). I handled product design, programming, packaging, distribution, and media outreach myself, and this software also landed me my first internship.

To avoid losing younger readers, I'll stop with these "painfully dated" examples. They don't need to be mythologized or romanticized either. That era of indie software and shareware had its rough edges — piracy, commercialization struggles, unsustainable support costs. Many authors had no stable income and none of today's mature collaboration tools.

But it left us with one crucial insight: super individuals aren't a species that suddenly emerged in the AI era.

The "authors" of that time weren't typically the people with the strongest single skill. They were the ones most willing to explore, most committed to open-source sharing, most capable of self-teaching, most inclined to build with their own hands, and most adept at feeding user feedback back into their own heads. They weren't defined by job descriptions — they were forced to grow into complete closed-loop operators.

Here's something you might not know — why were shareware authors naturally generalists? The core of shareware wasn't simply "free trial." It was the author facing distribution, payment, user support, and word-of-mouth growth directly. No dedicated PM writing requirements, no UX team running interviews, no operations team managing community. The shorter the closed loop, the more a person's comprehensive abilities were activated.

So when we discuss super individuals today, we shouldn't only look at how much AI amplifies individual capability. We should also hear a historical echo: once an organization or market returns the complete closed loop to the individual, the individual will grow into something that exceeds any job description.

What happened next with internet industrialization did the exact opposite. In the name of efficiency, it gradually dismantled what had once been a single programmer role. Over the following two decades, organizations broke that closed loop into specialized positions to achieve scalable delivery.

Fragmentation

After 2006, the internet entered a different narrative: larger traffic, more complex business operations, more granular roles, more powerful platforms.

This was progress, of course. Without division of labor and role formalization, there'd be no large-scale collaboration. Without industrialization, no reliable delivery. Without platformization, no way to govern complex business operations. One person's role was split into job functions.

Let's trace the broad arc.

Phase one: 2006–2012, role formalization.

Web 2.0, Ajax, improved browser capabilities — web pages became "products." Complexity rose, and roles naturally diverged: product managers wrote PRDs, interaction designers mapped flows, visual designers produced mockups, frontend engineers built interfaces, backend engineers provided APIs, QA ensured quality, and operations drove growth. Each role developed its own methodologies, job grades, promotion tracks, and professional vocabulary.

But here's an easily overlooked detail: around the 2010s, the original definition of "product manager" was actually very close to what people today call a super individual.

That generation of product managers was expected to understand users, identify needs, design flows, push development, coordinate with design, monitor launches, analyze data, listen to feedback — even tell stories, write documentation, and drive growth. In other words, organizations had already dimly recognized that someone needed to grab the fragmented product loop and pull it back together. Only that era's product managers didn't have Claude Code — no execution weapon that could directly modify code, build demos, run tests, generate pages, or dispatch agents. They could own the loop, but they couldn't close it with their own hands.

This boosted efficiency while creating the first layer of disconnection. An engineer no longer naturally faced users. A designer no longer naturally cared about shipping. A product manager might no longer personally touch implementation costs. Organizations gained specialization but lost some of people's sense of wholeness.

Phase two: 2013–2017, industrialization.

Mobile internet pushed the pace to extremes, and product managers became the kings of this era. Under the banner of "growth hacking," app versioning, channel distribution, event tracking, A/B testing, growth funnels, agile iteration, and continuous integration became daily routines at large companies. Roles weren't just separated — they were strung together by process. A requirement from proposal to launch had to pass review, scheduling, development, integration, testing, gray release, and post-mortem.

By now organizations resembled factory assembly lines. Every link more specialized, every role more replaceable, every project slotable into resource pools. The cost: many people began taking responsibility only for their own slice. User pain points lived in documents. Product success or failure lived in metrics. Real feedback was laundered into dashboards.

Phase three: 2018–2022, platformization.

This period is often simply written off as "the middle-platform craze." But I think the more accurate framing is: organizations began using platforms, permissions, and governance to固化 the complexity accumulated over the previous decade.

Business middle-platforms, data middle-platforms, technical middle-platforms, low-code platforms, DevOps platforms, permission systems, compliance processes, release controls, ticketing systems — layer upon layer. They were meant to solve redundant construction and risk governance, but they also became new organizational boundaries. Want to run a small experiment? Apply for data permissions first. Want to call an API? Find the platform owner. Want to gray-release? Get in the release window. Want to touch user feedback? Pass through customer service, operations, and data team translations. I happened to be a engineering leader at one of China's most "middle-platform-obsessed" major companies during this period. When middle-platform technology was at its zenith, super individuals were nearly extinct — replaced by "cogs."

This is the paradox of platformization: platforms lower the cost of standard actions but raise the cost of non-standard exploration. And the Agent paradigm everyone's discussing today? That's non-standard exploration.

In his 1968 article How Do Committees Invent?[11], Melvin Conway proposed a judgment later repeatedly validated by software engineering: a system's design will inevitably mirror the communication structure of the organization that designed it. Translated to major-company context: how you slice roles is how your product gets sliced; how you divide permissions is how system boundaries grow; how long your reporting chain is, is how slowly user feedback reaches decision-makers. So perhaps companies can't cultivate super individuals not merely because of talent problems, but because organizational structure itself continuously produces "partial people." Assign someone to a local scope, and they'll optimize locally. Force someone to reach others only through interfaces, tickets, meetings, and reviews, and eventually their product will come to resemble interfaces, tickets, meetings, and reviews. Sixty years on, Conway's Law still explains the correspondence between our product and organizational design today — both what works well and what needs improvement.

Did you know — DevOps was never originally synonymous with "more platforms"? The original spirit of DevOps was to shorten the distance between development, operations, and user feedback, making teams accountable for delivery outcomes. Yet in many big tech companies, it ultimately got implemented as a set of platforms, approval gates, and permission systems. The more powerful the tools, the shorter the closed-loop isn't necessarily; the more complete the governance, the more likely individuals are to drift away from real problems.

By this point, the independent individual function has been pretty much dismantled.

Curiosity got assigned to innovation departments. Exploration got assigned to pre-research projects. Self-learning got assigned to training systems. Self-motivation got assigned to performance targets. Hands-on ability got assigned to job responsibilities. People are still getting stronger, but stronger in local domains; organizations are still getting more stable, but stable in their processes. Backend engineers no longer know how their APIs render on the actual webpage. Frontend engineers no longer care about high concurrency or high availability. R&D doesn't understand testing. R&D complains that product managers don't understand technology. Product managers complain that engineers don't understand user needs, move too slowly, can't keep up with competitors.

Standing here in 2026 looking back, this is why AI's impact feels so counterintuitive. The real new variable is that tools are for the first time systematically lowering the cost of cross-functional action. LLMs and Agents don't simply make individual roles more efficient — they push the fragmented capabilities back toward a single person: a product manager can now prototype directly; a designer can run interactive demos directly; a frontend engineer can handle research and copywriting directly; an operator can have an Agent analyze data, generate pages, and organize releases for them.

The question follows: when tools have already started compressing the division of labor, should organizations keep using old roles, old permissions, and old processes to slice people apart?

If the answer is still "yes," then big companies will see a strange sight: employees becoming more complete in external tools, yet more partial when they return to the company. The super-individual hasn't failed to emerge — they've just been pressed back into role-shaped people by organizational structure.

The Backswing

After 2023, the change wasn't "one more chatbot." The real change is this: LLMs and Agents began re-compressing the division of labor.

The preceding history has shown that role specialization, industrialization, and platformization all had their own logic. They solved for scale collaboration, and they also broke the sense of human completeness into local functions.

What's new with AI is that it isn't installing an efficiency plugin for each local function — it's suddenly driving down the cost of cross-functional action. After LLMs appeared, this structure began to swing back.

• A frontend engineer can use Claude Code, Cursor, v0, or a set of Agents to build a clickable, testable, tweakable product prototype in a day.

• A PM can write requirements into an issue, then have Claude Code read the codebase, modify pages, add tests, and open a PR. A designer no longer just hands off static mockups — they can produce interactive demos that transform meetings from "imagine how it would work" to "just try it."

• An ordinary employee can orchestrate Research Agent, Coding Agent, Test Agent, Deploy Agent, Release Agent, stringing together a research pass, an internal tool build, a launch note, and a user feedback collection into one continuous thread.

So the change today isn't that product managers suddenly matter more. Product managers always mattered. The real change is this: in the past, product managers could only close loops through meetings, documents, and influence; now they have, for the first time, the chance to directly execute part of that loop with Agents.

This applies equally to designers, frontend engineers, and operators. AI isn't letting them "overreach across roles" — it's letting them turn what previously could only be pushed forward through communication into concrete objects that can be discussed, tried out, and given feedback.

This isn't a return to 2002. The complete individual of 2002 existed because systems were still simple. One person could go from forums to installer packages to help docs to email feedback because the software production chain hadn't yet been sliced apart by platformization, compliance, growth optimization, and datafication.

Today's complete loop isn't built on "doing everything yourself." It's built on AI leverage re-compressing the execution layer back within one person's radius of control. They may not hand-write every line of code, or hand-craft every image, but they regain continuous responsibility from problem to outcome.

Agents take over tasks, not responsibility. A Research Agent can scan materials for you, but can't judge which problems are worth solving. A Coding Agent can modify code for you, but can't bear the consequences after launch. A Copy Agent can generate text for you, but can't face users' misunderstandings. People stand back at the center of the loop because AI has turned large swaths of "waiting for someone else's sprint schedule" into "shipping a first version now."

This is why this round of super-individuals can't be understood merely as high capability. Highly capable people have always existed. The AI-era super-individual is more like a combination of five forces: strong curiosity, strong exploratory and innovative spirit, strong self-learning ability, strong self-motivation, and strong hands-on ability. They don't finish courses before acting — they build a small loop in uncertainty first, and let reality write back.

In organizational terms, these people aren't necessarily troublemakers. They just saw earlier that old role boundaries are no longer sufficient.

The mistake large organizations most easily make here is understanding this backswing as "employee efficiency gains." So the organization keeps describing it in old role terms: frontend efficiency improved by how much, PM output of how many requirements, designer delivery of how many artifacts, operator hours saved.

But the deeper layer of change is this: a person can once again own product sense.

Product sense isn't the ability to write PRDs. It's the ability to roll user pain points, feasible solutions, engineering costs, interaction feel, launch risks, and feedback signals around in the same mind. This capability was fragmented by the division of labor. Now LLMs and Agents have stitched it back together.

Did you know — "research preview" isn't marketing speak? When OpenAI released ChatGPT[12] on November 30, 2022, it explicitly labeled it as being in Research Preview stage: let users try it for free first, collect feedback on strengths and weaknesses. The value of this label isn't just externally managing expectations — it's internally protecting an embryonic product. It allows something immature to be born, to be touched by real users, to grow from their feedback.

Research Preview is fundamentally an organizational institution.

It tells the organization: some things can't wait until the business plan, compliance framework, experience standards, and growth model are all fully worked out before shipping. By the time you've thought it all through, it won't be that thing anymore. This is especially true for LLM products, because model capabilities themselves are still changing rapidly, and product form must grow right against the capability boundary.

So "backswing" isn't nostalgia. It isn't calling for the abolition of professional specialization, nor is it demanding everyone become full-stack engineers, omnipotent designers, or all-capable operators. It simply reminds big companies: AI has already driven down the transaction costs of much old specialization. One person going end-to-end again is no longer individual heroism — it's a new production relationship.

The real question for organizations isn't "have we trained employees into super-individuals," but rather: have we allowed one person to run a closed loop first?

---

To illustrate how "closed-loop activation" happens, we can look at three types of examples: internal prototypes, public Research Previews, and personal open-source Agents.

Boris Cherny, Cat Wu, and Claude Code belong to the first category; ChatGPT's Research Preview belongs to the second; projects like OpenClaw, open-source personal Agents / personal assistants, belong to the third. Viewed together, they appear scattered on the surface, but share a common shape: strategy didn't come first — an individual got itchy first.

When Pragmatic Engineer[13] wrote about Claude Code, it called Boris Cherny the Founding Engineer of the earliest prototype and project, and Cat Wu the Founding Product Manager. This identity needs to be precise: Cat Wu wasn't a "researcher" style bystander. Her value wasn't in packaging a technical toy, but in translating an engineer's itch into product judgment.

Boris originally just wanted to familiarize himself with Anthropic's public API, so he made a small terminal tool. It could see what music was currently playing through AppleScript, and change tracks. This starting point was so small it could barely be project-initiated: no addressable market analysis, no competitive analysis, no quarterly goals, not even the self-awareness of being an "engineering efficiency tool."

Then it connected to the file system, connected to bash, started reading codebases, running commands, chasing context. Model capabilities were suddenly caught by a very朴素 product form. Claude Code didn't begin with "we want to build an AI coding platform" — it wasn't a product planned by the organization, but a product tool played into existence by a super-individual. Its successor imitators, by contrast, will certainly be products planned by other big companies, born of multi-role division of labor.

ChatGPT is another version of the same shape. OpenAI didn't package the November 30, 2022 release as a complete consumer product, but used Research Preview to let real users in first. The key wasn't "releasing a chat product" — it was the organization allowing an incomplete form to face the world, and turning the world's feedback into the next round of product definition.

OpenClaw-style open-source personal Agent / personal assistant projects provide a third example. I won't forcibly assert the complete historical details of any particular project here, because open-source project narratives are often rewritten by secondary传播. But the common direction of this category is clear: products like OpenClaw[14], which connect messaging entry points, files, schedules, email, scripts, and long-term tasks to Agents, are making AI shift from "answering questions" to "doing things for me." They often don't grow out of formal company strategy, but out of developers' dissatisfaction with their own daily workflows.

This is the real starting point of super-individuals.

Not "high capability" written on a resume, but a person sensitive enough to inefficiency, curious enough about the unknown, bold enough with tools, unafraid enough of failure, and impulsive enough to build. They make a toy demo first, not because they've already figured out the business model, but because they feel uncomfortable not building.

Did you know — what is Product Overhang?

In the context of Claude Code, Product Overhang can be understood as "model capability has already outpaced existing product forms." The model can already do certain things, but the product hasn't yet given it the right entry points, permissions, context, and feedback loops. Those who spot Overhang first are usually not the strategy department, but frontline workers ground down by specific workflows day after day.

Abstract these cases into an information flow, and you get a very short chain. Many large companies also have personal itches, toy prototypes, and frontline employees with strong self-learning abilities. The difference lies in whether the prototype gets killed by old processes on its journey from a personal computer to internal Lark, then to team adoption, then to formal resources.

Old processes ask a familiar set of questions: Which department owns this? Does it conflict with existing projects? Who's responsible for security? Is it in this year's OKRs? Why write code before design specs? Why ship a preview without user research?

These questions aren't wrong. The problem is, they appear too early.

Embryonic products aren't most afraid of skepticism — they're afraid of being asked to prove adult-level revenue before they've even grown a heartbeat. What Product Overhang needs is to let a small group of real users touch it first, then watch the adoption curve, complaints, reuse, misuse, and workaround behaviors. What the organization needs to do isn't write a business plan for it, but first of all, not pull it out of the soil to inspect whether its roots meet standards.

Translated into organizational language: those who look like "round pegs in square holes" are often people that old grids can't contain new closed loops. If large companies only see them as "not following process," they'll miss the earliest batch of sensors in this AI industrial revolution.

So the lesson from these cases for large companies is quite plain.

Super-individuals aren't produced in training sessions. They first appear as personal itches, as toy prototypes, as things that "don't look like formal projects." Whether the organization can catch them depends on whether it allows curiosity, self-drive, self-learning, exploration, and hands-on ability to grow for a while outside of KPIs.

The real question isn't "Does our company have a Boris?" The real question is: If Boris is already in your department, will his AppleScript toy survive its first week?

What determines whether it survives its first week is usually not technical difficulty, but how the management system receives early signals.

---

Many people interpret large-organization leaders' lag in AI as an attitude problem: not open enough, not young enough, not technical enough.

On this, I respectfully disagree.

I was a leader from 2007 to 2024 — 17 years — and successively led traditional R&D teams of 70+ people at two of China's top-tier internet giants.

I believe the more accurate framing is: leaders' time structures, risk responsibilities, and evaluation metrics place them in a position of natural hindsight. This isn't moral criticism; it's cognitive delay caused by organizational structure. They were once the vanguard who overthrew "PowerPoint reporting," overthrew "waterfall development," and championed "data-driven" approaches.

Why frontline employees become Early Adopters first has a very simple reason: they're closest to the pain.

Engineers are tortured daily by legacy code, test failures, missing documentation, repetitive reviews. PMs constantly switch between requirement clarification, competitive research, prototype validation, user feedback. Designers are chased by "three more directions" and "can you just do a rough version that looks okay first." Operations, HR, finance, legal — everyone has large volumes of concrete, repetitive, clearly bounded but mentally draining tasks.

So their first reaction to LLMs isn't "will this reshape the organization?" but "can this bullshit torture me a little less today?"

This is precisely the soil from which super-individuals grow. Curiosity isn't an abstract quality — it's the exploratory impulse awakened by concrete problems. Self-learning ability isn't a training certificate — it's staying up late trying prompts repeatedly, and by next morning an AI Coding demo with documentation is quietly posted to the work group. Self-drive isn't a label on a performance review — it's building out an Agent workflow when nobody asked you to. Hands-on ability isn't just knowing how to code — it's being willing to stitch research, scripts, spreadsheets, copy, publishing, and feedback into a running loop.

The world of traditional leaders is different. Their time is sliced into half-hour meetings; information enters as reports, weekly updates, industry research, vendor proposals, and strategy offsites. What they see isn't "this Agent saved me an hour of pain," but "does AI Coding affect the R&D system," "are there security risks," "should we centralize procurement," "should we form a special task force."

These questions are all reasonable, but they're inherently slow.

---

There's a key difference in this picture: frontline employees learn with their bodies; leaders learn through materials.

LLMs, Prompting, AI Coding, Agents — these things weren't knowledge at first; they were "feel." Unless you personally hand a task to Claude Code, watch it misread a file, break a test, then get corrected back by you, it's hard to understand where it's actually strong and weak. Unless you've personally written many failed prompts, you'll mistake Prompting for "just speaking clearly." Unless you've personally orchestrated multiple Agents, you'll think parallelism just means opening a few more windows.

Thus, an information gap emerges.

Frontline employees are already using Agents to generate tests, write scripts, do research, tweak pages, produce demos, organize meeting notes. Leaders might still be asking: "When does it launch?" "Don't do it alone — I'll add 10 more people, can we speed up 10x?" "What's this tool's positioning relative to our existing platform?" Frontline employees already feel that complete PMF has run through, while leaders are still understanding it through the lens of role-based efficiency gains.

More troublesome: old metrics punish exploration.

Large-company managers are responsible for stability, compliance, costs, team equity, resource allocation. If a leader encourages everyone to casually experiment with Agents and a data leak, quality incident, or procurement waste occurs, the responsibility is his. If he doesn't encourage it and just moves slower, the responsibility is less clear. Thus organizational incentives naturally bias toward "waiting for the standard answer to appear."

This is also why many leaders misread Early Adopters as "unfocused."

Did you know — why are Early Adopters often misread as "unfocused"? Because their learning paths don't look like project paths. They try Claude Code today, MCP tomorrow, write an internal bot the day after, then migrate their workflow to another tool the day after that. To some this looks like random flailing, building in secret. Through the lens of the new world, this is searching for the boundaries of new closed loops.

In old organizations, exploration must first be translated into projects, projects must correspond to metrics, metrics must enter reporting chains. Yet the most valuable explorations in the early AI industrial revolution often have no stable name at first. It doesn't start as a "platform," a "strategy," or an "innovation initiative" — it's just an employee's impulse that "this thing should probably be automatable."

Delay happens in this translation process.

The frontline employee's language is: I tried it, and it actually runs. The leader's language is: is this direction worth resource investment. Between these two sentences lies an entire old-era apparatus of budgeting, legal, compliance, architecture, performance, and leveling systems.

So if large companies want to activate super-individuals, the first step isn't calling on leaders to "embrace change." That language is too light.

The first step is changing how leaders receive new signals. Today, leaders at large companies easily live in information cocoons woven — unintentionally or intentionally — by the layer below them, living in Xiaohongshu, Douyin, and WeChat video AI marketing accounts. Skip one layer of reporting, watch one more real demo. Ask less "which department owns this," ask more "who's already using it spontaneously." Judge embryos less by quarterly ROI, judge direction more by adoption curves, reuse frequency, user complaints, and task closed loops. More importantly, leaders themselves need to get their hands dirty using LLMs, Prompting, AI Coding — those capable should build a few Agents themselves, or they'll always understand the industrial revolution through materials alone.

Delay isn't irredeemable, but it won't be cured by training sessions. It can only be cured by new practice structures: letting leaders reconnect with frontline pain points, letting frontline Early Adopter micro-loops be seen, letting those who are curious, self-learning, self-driven, and hands-on not have to first disguise themselves as traditional project managers to prove they're pushing the organization forward.

Misjudgment

People who don't easily become super-individuals aren't unintelligent.

Quite the opposite — many are high-scoring students, excellent employees, reliable backbone talent. They're accustomed to first understanding systems and principles, first mastering foundational knowledge, first finishing courses, first waiting for tools to mature, then starting to act. They feel that if someone else has already done something in a category, they can't do it too. This posture was very effective in organizations of the past twenty years, because past knowledge structures were relatively stable — learn the framework first, then do projects, was a high-win-rate path.

But the AI era has one problem: tools change faster than courses, product forms change faster than categories, real problems change faster than organizational processes.

Thus past learning postures begin to become action resistance in the new world.

The most typical first type: people who always want to ask about categories first.

They ask: "How many categories of Agents are there?" "What's the boundary between Prompt Engineering and Context Engineering?" Explain to me: "Should AI Coding tools be categorized by IDE, CLI, Plugin, or Agent platform?" "Are Claude Code and Codex the same thing?" These questions aren't without value. The problem is, if categorization is a prerequisite for action, a person will wait forever at the entrance.

People are accustomed to asking about categories first; super-individuals first ask whether it can solve their problem.

The second type: people who always want to find courses first.

They hope there's a "systematic Agent learning" course, ideally covering concepts, history, tools, cases, and best practices from start to finish. But Agent itself is still in the process of becoming — today's best practices may become historical baggage in three months. Courses can help people avoid detours, but they can't substitute for putting your hands in the mud.

The third type: people who always want to wait for the system first.

Waiting for the company to approve a purchase, waiting for someone else to buy a Claude Code Pro/Max account and teach you, waiting for IT to grant permissions, waiting for the platform team to release standards, waiting for security to whitelist a tool, waiting for your manager to add "AI efficiency" to your OKRs. By the time everything lines up, the window may have closed. Super-individuals don't ignore risk — they create a small closed loop within controllable boundaries and let reality emerge.

The fourth type: people who always want to ask how they differ from competitors first.

"How is this different from Cursor?", "What's the difference between Skills and Prompt?" (pronounced "Promote"), "How does this differ from Lark's existing AI features?", "Does this conflict with the company's AI roadmap?" These questions belong in product review meetings, not as your first instinct when exploring something new. It's as if once someone else has done it, you can't. Many new things start without clear differentiation — differentiation grows through use.

Did you know — "How to systematically learn Agent" might be an old-world question? The hidden assumption is: stable knowledge first, correct action second. But much of Agent knowledge comes only after action. Let it do a research run for you, revise a document, execute a test, organize user feedback once — failure will teach you the boundaries faster than any course.

This isn't anti-intellectualism. I'm not saying taxonomy, courses, systems, and competitive analysis don't matter. They matter enormously. But their position has shifted.

In the past, they were safety nets before action. In the new world, they're more like organizing tools after action. Build something small first. Let it hit real problems. Collect failure samples. Then name, classify, and methodologize retroactively. This path looks undignified, but it's closer to how knowledge actually gets generated in the AI era.

So the real reason it's hard to become a super-individual isn't weak capability — it's that your personality structure hasn't been activated by action. Curiosity delayed by taxonomy. Exploration spirit replaced by coursework. Self-learning ability outsourced to systems. Self-drive frozen by approvals. Hands-on ability consumed by competitive analysis.

The armies of "classify first" people in big companies aren't bad people or laggards. They've simply been too successfully trained by the old system. Stable organizations most reward exactly this posture: align first, learn first, write the proposal first, don't move without permission.

But the super-individual's launch sequence is the opposite.

They see a problem and ask: "Can I use AI to push this forward today?" Not guaranteed to succeed. Not guaranteed to be elegant. Not guaranteed to get resourced. But they get things moving first. Once things move, courses gain context, taxonomy gains meaning, systems gain handles, competitive differences become real judgments rather than conference room conceptual games.

This is the deepest misjudgment between old and new worlds: people think super-individuals possess more knowledge. What's actually happening is that super-individuals reconnect knowledge, tools, problems, and feedback into an action loop.

Soil

Can super-individuals be cultivated?

If "cultivation" means pulling people into a conference room, running them through a curriculum, handing out certificates, and requiring standardized AI innovation project outputs, my assessment is: very difficult.

Because a super-individual isn't first a bundle of skills — it's a foundational personality structure.

• Strong curiosity, strong competitiveness too

• Strong innovative spirit, and simultaneously troublemakers in others' eyes

• Strong self-learning ability

• Strong self-drive

• Strong hands-on ability

These five aren't the complete definition of a super-individual, but they constitute that person's bottom-layer engine. What organizations can do isn't manufacture personality — it's place that personality structure in a field where closed loops can happen.

The problem: old training systems excel at transmitting established knowledge and fail at igniting this engine. They can teach someone what a Prompt is, what an Agent is, what a Workflow is. They can't make someone suddenly itch over real problems, let alone push forward without a standard answer.

So the more accurate framing isn't "cultivate super-individuals" but: use organizational closed loops to activate super-individuals.

This requires four soils.

• Complete problem ownership: A person can't receive only chopped-up tasks. They need to see through from problem definition, solution selection, prototype validation, to user feedback and consequences. Without complete problems, there's no ultimate responsibility.

• Tool permissions: Hands-on ability in the AI era already extends beyond coding. It includes tuning models, connecting tools, running data, building prototypes, shipping gray releases, reading feedback. Deny tool permissions and you're asking people to innovate with their mouths only.

• Direct user feedback: Super-individuals don't grow in reporting chains — they get polished in user feedback. User confusion, delight, churn, and reuse are more authentic training signals than manager evaluations.

• Organizational recognition: The organization must recognize "personal itches," "informal prototypes," "build it first and see," "fail faster, fail earlier" as legitimate work, not side projects, hobbies, or dereliction of duty.

Map it out and it looks roughly like this:

This is also why in many organizations, product managers, designers, and frontend engineers often grow into super-individuals faster than some more "model-literate" roles.

Product managers naturally sit close to problem definition — they know where users get stuck. Designers naturally sit close to experience details — they can feel whether a product form holds together. Frontend engineers naturally sit close to interactive prototypes — they can ship a clickable demo by evening when they have an idea that morning.

These three share one trait: they stand relatively close to complete closed loops.

They may not deeply understand Transformers, may not explain the difference between LoRA and MoE. But they can quickly connect AI capabilities into concrete workflows: auto-generate a report, shave three steps from a customer service flow, make an internal knowledge base callable by natural language, let users touch a new feature in half-baked form first.

Model papers solve "can this capability emerge." Product form solves "can this capability be used by people." Workflow solves "can this capability repeatedly change human behavior." Super-individuals often first stand at the intersection of the latter two.

Did you know — understanding models doesn't equal seeing products? People who understand models can judge a capability's technical boundaries. People who see products can judge whose which action this capability should embed into. The former answers "what can the model do." The latter answers "will people change how they work because of this." In the AI era, the second kind of eyes is often what's truly scarce.

So if big companies genuinely want to "cultivate super-individuals," their first instinct shouldn't be building an AI academy curriculum. Curriculum can exist, but it's fertilizer, not soil.

More critical are four organizational questions: Does this person have complete problems? Tool permissions? Direct visibility into user feedback? Will the organization recognize new capabilities that grow outside their formal role?

If all four answers are no, more training just slaps AI labels onto old positions.

If the four answers gradually become yes, curiosity will find its own problems, self-learning will fill its own knowledge gaps, self-drive will cross its own boundaries, hands-on ability will turn ideas into prototypes. At that point, so-called "super-individuals" aren't taught by instructors — they're forced out, nurtured out, illuminated out.

Conclusion

If the assessments in previous chapters hold, the conclusion isn't "organizations will be replaced by individuals."

On the contrary, super-individuals aren't the endpoint of division of labor — they're the starting point of a new division of labor.

Old division of labor sliced a complete person into positions: product manager handles requirements, designer handles experience, engineer handles implementation, QA handles quality, operations handles growth, customer service handles response, finance handles settlement, management handles coordination. Its strengths were stability, scalability, replaceability. Its problem: human complete loops were sliced too thin, and ultimate responsibility got diluted layer by layer.

After AI, division of labor doesn't disappear — its scale simply shrinks.

A person can have a team of Agents standing beside them: some for research and data, some for design and prototyping, some for coding and testing, some for operations, customer service, and financial reconciliation. Actions that once required a small group now get compressed onto one person's desk.

But note: the truly critical thing isn't that Agents multiply — it's that the human stands back in the position of ultimate responsibility.

This person's role increasingly resembles a hybrid of founder, FDE[1], product lead, and DRI. They may not personally execute every action, but they must define problems, judge direction, select tools, accept results, bear consequences. Their curiosity determines where problems begin. Their exploratory spirit determines whether boundaries can be pushed. Their self-learning determines whether they fall behind when tools change. Their self-drive determines whether they still act when no one assigns tasks. Their hands-on ability determines whether ideas die in PowerPoint or grow into prototypes users can touch.

These five traits aren't the complete definition of a super-individual, but they constitute the foundational personality structure. Without them, AI only turns people into faster executors. With them, AI can amplify people into new organizational units.

Did you know — the organizational meaning of Think different? Returning to that Apple ad from the opening: it's often read as an individualist manifesto. I prefer to read it as an organizational reminder: those misfits, rebels, troublemakers — their value isn't rebellion itself, but that they often see new combinations first. The question for organizations isn't how to grind them round, but how to give them a closed loop where they can own outcomes to the end.

So super-individuals won't make big companies obsolete. "One-person companies" and "big companies" will coexist for the long term.

Big companies still hold what one-person companies can't get: brand credibility, distribution channels, compute resources, security boundaries, compliance capabilities, complex customers, long-term capital, cross-functional collaboration networks. The problem: once these resources get locked by old positions, old ranks, old reporting chains, they transform from leverage into weight.

The real challenge is singular — can these resources be reconnected to smaller closed loops?

It's not about making super-individuals prove they deserve authority through layers of approval. It's about handing them a controllable territory by default — complete with the full problem, tool permissions, user feedback, and organizational recognition. It's not about waiting until an idea grows into a big project to be seen. It's about allowing it to be used for real, to get real feedback, to be killed for real, while it's still a toy, a demo, an internal script, a half-baked workflow.

The misalignment has already happened.

A product manager can already deploy agents for research, use AI coding for prototypes, write documentation, and organize interviews — yet the organization still treats them as a "requirements document producer." A frontend engineer can already go from user problems all the way to product demos, gray-scale experiments, and data reviews — yet the organization still monitors their "code output volume" and "demand load rate." A designer can already use AI to string together interaction design, copy, pages, motion graphics, and user testing into a closed loop — yet the organization still parks them at the end of the process to pretty up interfaces.

The old ruler can't measure the new leverage. The old division of labor can't contain the new productive capacity. This is the real question to answer — the relations of production themselves.

Industrial-era corporations once compressed complex collaboration into positions, processes, and hierarchies. That was a great achievement of its time. What the AI era demands is not smashing that apart, but recomposing it into a new unit: "human + agent + organizational resources."

Super-individuals aren't born, and they're not mass-produced by training courses. They're ignited in complete closed loops, honed on real problems, amplified by organizational recognition.

The dividing line for next-generation organizations won't be who owns more AI tools or agents. It will be who admits sooner: people are reorganizing production at a smaller scale.

Crossing is looking for independent contributors to write AI product and model reviews.

If you've written pieces like: "Hands-on with PixVerse C1", "Hands-on with LibTV", please contact zeo0811@gmail.com. Your email should include: ① a brief bio, ② AI review articles you've written.

We offer competitive rates. Looking forward to observing and documenting the AI era together 🎪

References

[0] Henry: https://xhslink.com/m/AyUHaIeXWic

[1] FDE — Has the AI-Era Career Transition Already Begun?: https://my.feishu.cn/wiki/LiubwwOU4iqbS4kxn4EcikHGnTf

[2] Think Different campaign: https://www.computerworld.com/article/1629859/the-untold-story-behind-apple-s-think-different-campaign.html

[3] Find a Position of Leverage: https://www.navalmanack.com/almanack-of-naval-ravikant/find-a-position-of-leverage

[4] SINA Corporation archival article: https://tech.sina.com.cn/c/2001-08-24/5372.html

[5] Jiemian News retrospective: https://www.jiemian.com/article/4178068.html

[6] FlashGet 10th anniversary timeline: https://www.flashget.com/10th/

[7] TechSpot retrospective on Winamp: https://www.techspot.com/article/2042-winamp/

[8] ACDSee About: https://www.acdsee.com/en/about/

[9] WinZip's Nico Mak Computing retrospective: https://www.winzip.com/en/learn/old-brands/nico-mak-computing/

[10] In 2002, wrote his first shareware to break 10,000 sales — MagicCube Lyric Editor: https://web.archive.org/web/20030816005420/http://nhzx.njenet.net.cn/henrylee/MagicHelp/Index.htm

[11] How Do Committees Invent?: https://inigomedina.co/library/work/conway-law

[12] ChatGPT: https://openai.com/blog/chatgpt/

[13] Pragmatic Engineer: https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built

[14] OpenClaw: https://openclaw.ai/