Productivity on kenji.blog

Remote Work and Return to Office: What is the Optimal Solution for Engineers?

Sat, 12 Sep 2026 12:00:00 +0900

Introduction: The Post-Pandemic Paradigm Shift and the Wave of RTO

The global pandemic of the early 2020s fundamentally overturned the definition of a “workplace” in the software engineering industry. Overnight, offices were locked down, and almost all companies—from Silicon Valley tech giants to Japanese startups—were forced into a mandatory transition to full remote work. This historic social experiment shattered the long-held stereotype among management that “advanced software development is impossible without gathering in an office,” and proved that geographically distributed teams can build and operate massive systems by leveraging tools like GitHub, Slack, Zoom, and Notion.

However, as the pandemic subsides, the industry landscape is transforming once again. Tech giants like Amazon, Google, and Meta have begun strongly pushing for a “hybrid model” that mandates several days of office attendance a week, or even a full “Return to Office (RTO).” This top-down RTO directive from management is creating severe friction with many engineers (Individual Contributors: ICs). While engineers argue that “a quiet home environment allows for better focus on code” and “commuting time is a waste of life,” management counters that “innovation is born from serendipitous encounters” and “face-to-face communication is essential for fostering organizational culture.”

In this article, we will not dismiss this binary debate of “Remote Work vs. Return to Office” as mere emotional arguments or matters of personal preference. Instead, we will thoroughly dissect it through the objective and technical lenses of organizational sociology, quantitative evaluation of engineering productivity (DORA metrics, SPACE framework), and underlying network architecture (VPN and Zero Trust). Let’s explore the “true optimal solution” that modern engineering organizations should aim for regarding this complex issue at the intersection of technology and human society.

Unraveling the Dynamics of Communication through Organizational Sociology

Software development is both a highly intellectual task and an extremely social activity. In the process of dozens or hundreds of engineers collaborating to build a massive system, the quality and quantity of communication become the most significant factors determining the success or failure of a project. Here, we analyze the impact of remote work on communication using classical theories of organizational sociology.

The Allen Curve and the Curse of Physical Distance

In the late 1970s, Professor Thomas J. Allen of the Massachusetts Institute of Technology (MIT) investigated the relationship between the frequency of communication among engineers in R&D organizations and their physical distance within the office. The resulting finding is the famous “Allen Curve.”

According to Allen’s research, the probability of communication occurring between engineers decays exponentially as physical distance increases. This relationship can be approximately expressed by the following mathematical model:

$$ P(d) \approx \alpha e^{-\beta d} $$

Here, $P(d)$ is the probability of communication occurring, $d$ is the physical distance between two engineers, and $\alpha$ and $\beta$ are constants that depend on the organization’s culture and environment.

The most shocking fact revealed by the Allen Curve is that “when the distance exceeds 30 meters, the probability of daily communication rapidly approaches zero.” Information exchange happens overwhelmingly more with a colleague at the next desk than with a colleague on a different floor of the same building.

graph LR
D0["Distance: 0m (Next desk)"] --> P0["Face-to-face communication probability: Extremely high"]
D10["Distance: 10m (Same cluster)"] --> P10["Face-to-face communication probability: High"]
D30["Distance: 30m (Different floor)"] --> P30["Face-to-face communication probability: Low (few %)"]
DRemote["Full remote (Different city)"] --> PRemote["Serendipitous synchronous communication probability: Almost zero"]
D0 -. Rapid decay of the Allen Curve .-> D10
D10 -. Loss of physical proximity .-> D30
D30 -. Shift to completely asynchronous/intentional communication .-> DRemote

In a full remote work environment, this physical distance $d$ becomes effectively infinite. In other words, even with the existence of Slack or Zoom, serendipitous communication (like “water cooler talk”) structurally ceases to occur. One of the strongest rationales for management to push for RTO is to reclaim this “sharing of tacit knowledge and creation of innovation brought about by physical proximity,” backed by the Allen Curve.

Conway’s Law and Its Impact on Architecture

Another indispensable theory when considering remote work is “Conway’s Law,” proposed by Melvin Conway in 1968.

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

Full remote work fundamentally changes an organization’s communication structure. Dense face-to-face collaboration decreases, and asynchronous, formal communication via Slack channels and Jira tickets takes precedence. As a result, boundaries between teams (silos) become stronger.

graph LR
subgraph "Organization Communication Structure (Under Remote Environment)"
FE["Front-end Team (Siloed)"]
BE["Back-end Team (Siloed)"]
DB["Database Team (Siloed)"]
FE -. "Asynchronous integration via API docs (Swagger)" .- BE
BE -. "Schema change requests via Jira tickets" .- DB
end
subgraph "System Architecture"
SPA["SPA (React)"]
API["API Gateway / Microservices"]
Data["Database (PostgreSQL)"]
SPA --> API
API --> Data
end
FE === SPA
BE === API
DB === Data

This siloing is not necessarily a bad thing. When adopting a microservices architecture with clear API interfaces and independent deployability, intentionally restricting communication between teams to increase their independence is sometimes even recommended as an “Inverse Conway Maneuver.” Full remote work can be said to be suitable for developing loosely coupled systems with clear boundaries.

However, during the initial launch phase of a system (zero-to-one development), large-scale refactoring spanning multiple components, or troubleshooting unknown incidents, dense and high-bandwidth communication across team boundaries is essential. Excessive siloing in a remote environment makes solving such monolithic challenges extremely difficult.

Redefining Engineering Productivity: Quantification via DORA and SPACE

Which has higher “productivity,” remote work or office attendance? The reason this debate often ends in a stalemate is because the definition of the word “productivity” is ambiguous. The era of measuring productivity by lines of code (LOC) or the number of pull requests is over. In modern engineering organizations, productivity is evaluated from multiple angles using DORA metrics and the SPACE framework.

The Impact of Remote Work through the Lens of DORA Metrics

The four key metrics defined by the DevOps Research and Assessment (DORA) team have become the industry standard for measuring software delivery speed and stability.

Deployment Frequency
Lead Time for Changes
Change Failure Rate
Mean Time To Recovery (MTTR)

According to much empirical data, in a full remote environment, teams centered around senior engineers tend to see improvements in “Deployment Frequency” and “Lead Time for Changes.” This is because office-specific interruptions (a tap on the shoulder, being pulled into a sudden meeting) disappear, making it easier to enter a state of “deep work” (deep concentration).

On the other hand, there is concern about the negative impact on “Mean Time To Recovery (MTTR).” When a complex system failure occurs, incident response requires simultaneous investigation and swift decision-making by multiple domain experts. MTTR can be expressed by the following equation:

$$ MTTR = \frac{1}{N} \sum_{i=1}^{N} (t_{restore, i} - t_{incident, i}) $$

In an office, key members can be gathered in a “war room,” rapidly cycling through hypothesis testing while surrounding a whiteboard. However, in a full remote environment, overhead occurs: issuing a Zoom link, gathering the appropriate members on Slack, and proceeding while checking logs via screen sharing. In this “synchronous emergency response,” physical proximity remains a powerful weapon.

The SPACE Framework: A Multifaceted Evaluation of Developer Experience

While DORA focuses on system output, the SPACE framework, proposed by researchers at GitHub and Microsoft, captures the Developer Experience (DX) more comprehensively.

mindmap
root(("SPACE Framework"))
S(("Satisfaction & Well-being"))
S1["Elimination of commute stress (Remote advantage)"]
S2["Isolation & burnout (Office advantage)"]
P(("Performance"))
P1["Value delivery to customers"]
P2["Code quality"]
A(("Activity"))
A1["Number of PRs created"]
A2["Deployment frequency"]
C(("Communication & Collaboration"))
C1["Review speed"]
C2["Sharing of tacit knowledge (Office advantage)"]
E(("Efficiency & Flow"))
E1["Fewer context switches (Remote advantage)"]
E2["Elimination of interruptions (Remote advantage)"]

Using the SPACE framework, the light and shadow of remote work become clear. While a remote environment maximizes an engineer’s “Efficiency & Flow,” it carries the risk of hindering “Communication & Collaboration.” Furthermore, regarding “Satisfaction,” while there is the positive aspect of eliminating the commute, there is also the negative aspect of deteriorating mental health due to social isolation.

The Cost and Cognitive Load of Asynchronous Communication

The key to successful full remote work lies in the transition from “synchronous communication” (meetings, hallway chats) to “asynchronous communication” (documents, tickets, chats). Fully remote pioneering companies like GitLab and Automattic achieve this through a thorough documentation culture. However, over-reliance on asynchronous communication creates another kind of “cost.”

The Context-Switching Trap Brought by Slack and Jira

A problem that would be solved with a few seconds of chatting in the office transforms into a long Slack thread or a rally on Jira when working remotely. The number of communication paths within a team, where the number of members is $n$, is the number of edges in a complete graph expressed by the following formula:

$$ C = \frac{n(n-1)}{2} $$

As an organization grows, the volume of asynchronous messages flying across these communication paths increases explosively. Engineers find themselves continuously processing incoming notifications (with $S_i$ as the switch cost and $R_i$ as the response cost) alongside tasks requiring deep concentration like coding ($E_{task}$). The total cognitive load ($E_{total}$) swells as follows:

$$ E_{total} = E_{task} + \sum_{i=1}^{k} (S_i + R_i) $$

Asynchronous communication saves the sender’s time (they can send it anytime), but in return, it forces the receiver to bear the load of deciphering and reconstructing the context. It is extremely difficult to accurately convey complex system specifications or design intentions using only text, which often results in misunderstandings and rework.

The Synchronous Value of Whiteboard Sessions

In initial architecture design or discussions of complex algorithms, the synchronous activity of “gathering around a whiteboard” possesses unparalleled information bandwidth. While online collaboration tools like Miro and Figma have evolved dramatically, they have not yet completely replaced physical interactions accompanied by human gestures, eye movements, and the act of “drawing and explaining right there.” It must be said that the physical office still holds high value in the process of synchronously sharing and constructing high-dimensional abstract concepts.

The Technological Foundation Supporting Remote Work: From the Limits of VPN to Zero Trust

So far, we have discussed this from the perspectives of sociology and productivity, but another crucial factor determining the remote work experience is “network architecture.” An engineer’s productivity is directly linked to the access latency of the development environment and production servers.

Traditional VPN Architecture and the Mathematics of Latency

Early in the pandemic, many companies hastily scaled up their traditional VPN (Virtual Private Network) gateways to provide remote access to their existing on-premises environments. However, this perimeter-based defense architecture becomes a fatal bottleneck in the era of remote work.

The total network latency $T_{total}$ is expressed as the sum of propagation delay (dependent on physical distance), transmission delay (dependent on bandwidth), and processing delay at routers and gateways.

$$ T_{total} = \frac{D}{c} + \frac{L}{B} + T_{proc} $$

When using a traditional VPN, even when a remote engineer accesses cloud-based SaaS (like GitHub or the AWS console), an inefficient routing called “Hairpinning (Hairpin NAT)” occurs, where all traffic is pulled into the corporate network’s VPN gateway before exiting to the internet. This unnecessarily increases the distance $D$ and causes the encryption/decryption processing delay $T_{proc}$ of the VPN appliance to skyrocket. This significantly degrades the response of an engineer’s typing, destroying their state of flow.

The Paradigm Shift Brought by Zero Trust (BeyondCorp)

Breaking through these network limitations and realizing a true “environment where you can work comfortably and securely from anywhere” is the Zero Trust Network Architecture (ZTNA), pioneered by Google’s “BeyondCorp.”

The core of Zero Trust is “not using the network perimeter (whether internal or external) as the basis of trust.”

graph TD
subgraph "Perimeter Defense Model (Traditional VPN)"
U1["Remote Engineer"] -- IPsec / SSL VPN --> VPN["VPN Gateway (Single Point of Failure / Bottleneck)"]
VPN -- Internal LAN (Implicit Trust) --> App1["Internal Source Code Management"]
end
subgraph "Zero Trust Model (BeyondCorp / ZTNA)"
U2["Remote Engineer (MDM Managed Device)"] -- Direct Communication (mTLS HTTPS) --> IAP["Identity-Aware Proxy (IAP)"]
IAP -- Dynamic Authorization per Request --> App2["Internal / SaaS Applications"]
IDP["Identity Provider (Okta / Entra ID)"] -. MFA / User Context .-> Policy
MDM["Device Management (Intune / Jamf)"] -. Device Health (Patch Status) .-> Policy
Policy["Access Policy Engine"] -. Risk-based Authorization Decision .-> IAP
end

In a Zero Trust architecture, there are no centralized chokepoints like VPNs. Whether from a home Wi-Fi network or a public cafe LAN, engineers access each resource directly through the shortest path via an Identity-Aware Proxy (IAP), based on strong contexts of device authentication (such as client certificates) and user authentication (MFA).

As a result, the unnecessary distance $D$ and excessive processing delay $T_{proc}$ in the aforementioned latency equation are eliminated, enabling terminal operations and massive data transfers with extremely low latency, entirely comparable to being in the office. The state where “productivity does not drop even when remote” is not just a matter of mentality, but is realized only with the construction of such an advanced Zero Trust foundation.

Onboarding Junior Engineers and the Transfer of Tacit Knowledge

Some point out that the biggest victims of full remote work are not senior engineers, but junior engineers who have just started their careers.

Senior engineers already have a strong internal network, have accumulated domain knowledge, and possess the ability to execute tasks autonomously. For them, remote work can be the “ultimate environment for concentration.” However, junior engineers need to absorb undocumented “Tacit Knowledge,” not just “how to write code,” but also “who to ask questions,” “what the unwritten rules of the organization are,” and “the sense of urgency and troubleshooting intuition during incident response.”

In an office environment, junior engineers absorb tacit knowledge like a sponge by glancing at a senior engineer’s screen from the side, listening to the sound of them typing, or catching snippets of hallway conversations with other teams. In a remote environment, this process of “learning by watching” is completely cut off. Unless time for pair programming or mob programming is intentionally scheduled, junior engineers risk being crushed by isolated debugging tasks, significantly flattening their growth curve.

In Search of the Optimal Solution: Intentional Hybrid or Full Remote?

Based on the analysis so far, we can see that both “full office attendance” and “full remote” have decisive trade-offs.

Advantages of Full Remote: Promotion of deep work, elimination of commuting, access to a global talent pool, and secure, high-speed access via a Zero Trust foundation.
Advantages of Office Attendance: Occurrence of high-bandwidth communication based on the Allen Curve, synchronous discussions for complex architecture design, reduction of MTTR, and the onboarding of junior engineers and transfer of tacit knowledge.

The “hybrid model” adopted by many modern tech companies is not merely a product of compromise, but a rational strategy attempting to reap the benefits of both. However, to make the hybrid model successful, “intentional operation” is indispensable.

For example, suppose a rule is set that “Tuesdays and Thursdays are office days (Anchor Days).” On these days, engineers should be prohibited from “putting on earphones and silently coding at their desks.” Office days should be defined as days completely dedicated to “synchronous collaboration,” such as design discussions using whiteboards, mob programming, lunches with other teams, and 1-on-1s. Then, the remaining remote work days should be protected as “no-meeting days,” purely for deep work facing the code.

$$ T_{productivity} = f(C_{sync\_collab}, E_{deep\_work}, ZTNA_{performance}) $$

An engineer’s comprehensive productivity is expressed as a complex function of the quality of synchronous collaboration, the quantity of deep work, and the comfortable access performance provided by a Zero Trust foundation. Intentionally designing, separating, and optimizing these is the true nature of a hybrid model.

Conclusion: Towards a Compromise Between Engineers and Management

The “Remote Work vs. Return to Office” debate is often framed as a conflict between “workers’ rights vs. management’s desire to control,” but the essence does not lie there.

Management must discard the illusion that “merely gathering people in an office will magically spawn innovation.” Forcing attendance without investing in modern infrastructure like Zero Trust or designing an organization to align with Conway’s Law in distributed system development will only lower engineer engagement and productivity.

On the other hand, engineers (especially senior levels) must also amend the self-righteous perspective that “an office is unnecessary because I am more productive writing code alone.” Engineering is a team sport, and engineers bear broad responsibilities beyond just coding productivity, including overall system design, mentoring junior members, and coordinating during emergencies. It is a fact that high-bandwidth communication in physical spaces can sometimes save an entire project.

The optimal solution varies depending on the phase of the company, team, and product. However, what is certain is that only organizations that understand the sociological nature of communication, measure their current state with multifaceted metrics like the SPACE framework, and continually break through constraints with technologies like Zero Trust architecture will gain true competitive advantage in this new era of work.

The Deepening of the 'New Digital Divide' Brought by the Evolution of Generative AI

Sat, 12 Sep 2026 12:00:00 +0900

1. Introduction: Historical Transition of the Digital Divide and the New Paradigm

Since the popularization of the internet, we have often heard the term “digital divide” (information gap). The early digital divide was primarily about “physical access rights.” In other words, it was a simple scenario where whether or not one had a computer or high-speed internet connection determined access to information and economic opportunities. Later, as smartphones and broadband connections became commoditized, the focus of the divide shifted to “IT literacy” (information utilization capability). This involved the software and cognitive aspects, such as whether one could appropriately search for information using search engines or master software.

However, the sudden emergence of Generative AI and the evolution of Large Language Models (LLMs) in the 2020s are fundamentally overturning this concept of the digital divide. What we are facing now is not merely a “divide in access to information” or a “divide in software operation skills.” It is a “divide in the ability to orchestrate (direct and integrate) AI,” a profound and irreversible “3rd Digital Divide” that determines whether an individual’s productivity is amplified exponentially or if they are left behind by the evolution of AI and lose relative value.

In this article, we will unravel in great detail the true nature of this new digital divide brought about by Generative AI from three layers: the mathematical model of productivity, hardware architecture and cost, and the cognitive aspects of human beings.

2. From “Access” to “Orchestration”: The Arrival of the 3rd Digital Divide

Past software tools were essentially “passive instruments.” The limitation of traditional software was that it returned deterministic results in response to the user’s explicit input (e.g., entering a formula in spreadsheet software to get a calculated result). However, current Generative AI, especially LLMs based on the Transformer architecture (GPT-4, Claude 3.5, Llama 3, etc.), act as “fragments of active intelligence.”

Due to this paradigm shift, the required skill set for humans has dramatically changed from the “ability to operate tools” to the “ability to combine multiple AI agents and tools, and to design and direct autonomous workflows (AI Orchestration).” This can be called “AI Orchestration Literacy.”

Below is the transition of the digital divide from the past to the present.

flowchart TD
A["1st Divide: Access to Hardware and Infrastructure (1990s-2000s)"] --> B["2nd Divide: IT Literacy and Information Retrieval Skills (2010s)"]
B --> C["3rd Divide: Prompting and Orchestration of Generative AI (2020s-)"]
C --> D["Designing Autonomous Task Execution by AI"]
C --> E["Integration of Multiple AI Agents (Agentic Workflows)"]
C --> F["Advanced Information Verification and Hallucination Detection"]

Moving beyond the boundaries of prompt engineering, we have now entered a stage where systems are made to autonomously solve problems using multi-agent frameworks like LangChain, AutoGen, and CrewAI. Between the “class that draws the blueprints and lets AI execute them” and the “class that still performs routine work manually,” a divergence in productivity is occurring at a speed that humanity has never experienced before.

3. The Matthew Effect of Productivity: Visualizing the Divide through a Mathematical Approach

The “Matthew Effect,” derived from the New Testament saying “For to everyone who has, more will be given, and he will have abundance; but from him who does not have, even what he has will be taken away,” refers in sociology and economics to a phenomenon where early advantages lead to cumulative benefits. With the introduction of Generative AI, this Matthew Effect is strongly manifesting in the labor market and knowledge production.

The productivity of an individual who effectively uses AI grows exponentially, not linearly, with time. This is because the time saved by AI can be further invested in building more advanced AI systems, optimizing prompts, and self-learning. Let us express this with a mathematical model.

The productivity of a non-AI user $P_{human}(t)$ and the productivity of an AI orchestrator $P_{AI}(t)$ at a given time $t$ can be represented by the following models, respectively.

$$ P_{human}(t) = P_0 (1 + r_{human})^t $$

Here, $P_0$ is the initial productivity, and $r_{human}$ is the natural human learning rate (growth rate based on the experience curve). Generally, $r_{human}$ is very small, and growth tends to be arithmetic.

On the other hand, the productivity of a user who fully utilizes AI combines the capability improvement rate of the AI model being used, $r_{model}$, and the compound interest effect of workflow automation by AI, $\alpha$.

$$ P_{AI}(t) = P_0 \cdot \exp\left( \int_0^t (r_{human} + \alpha \cdot r_{model}(\tau)) d\tau \right) $$

Because the AI model itself is evolving exponentially (an increase in parameter count and computational complexity based on scaling laws), $r_{model}(t)$ itself increases over time. As a result, the difference in productivity between the two, $\Delta P(t)$, rapidly widens.

$$ \Delta P(t) = P_{AI}(t) - P_{human}(t) $$

The graph below visually shows this divergence.

xychart-beta
title Productivity Divergence Over Time (The Matthew Effect)
x-axis ["Year 1", "Year 2", "Year 3", "Year 4", "Year 5", "Year 6"]
y-axis "Output Volume" 0 --> 200
line [10, 15, 30, 60, 110, 180]
line [10, 12, 14, 16, 18, 20]

(Note: The blue line represents the productivity of the AI orchestrator, and the lower line represents the productivity of the non-AI user)

In the first year, the difference seems negligible, but each time the AI model evolves from GPT-3 to GPT-4, and further to its next generation, AI users enjoy a dramatic leap in productivity simply by plugging the new model into their existing automation pipelines. It becomes mathematically closer to impossible over time for non-AI users to close this gap.

4. The Hardware Divide: The Wall of Local Inference and the Trap of Cloud APIs

The 3rd Digital Divide creates a new hardware gap not just in software skills, but in “access to compute (computational resources)” needed to run cutting-edge AI models.

To utilize Large Language Models, there are mainly two approaches: “using Cloud APIs” or “running the model locally for inference.” Both have their pros and cons, which are forming a new economic and physical wall.

Limitations and Running Costs of Cloud APIs

State-of-the-art frontier models provided by OpenAI, Anthropic, and Google (GPT-4o, Claude 3.5 Sonnet, etc.) are generally accessed via API. However, if you build a highly autonomous agent (Agentic Workflow) that generates tens of thousands of API calls per day, the costs explode.

The total cost of the API, $C_{cloud}$, depends on the volume of input and output tokens.

$$ C_{cloud} = \sum_{i=1}^{N} \left( c_{in} \cdot T_{in}^{(i)} + c_{out} \cdot T_{out}^{(i)} \right) $$

(Where $N$ is the number of requests, $T$ is the number of tokens, and $c$ is the unit price per token)

When continuously performing large-scale data processing or vectorization for RAG (Retrieval-Augmented Generation), this variable cost can become a fatal burden for individual developers and small to medium-sized enterprises.

The Wall of Local LLMs and VRAM

From the perspective of avoiding cloud costs and maintaining data privacy, the demand for running open-weight models like Meta’s Llama 3 and Mistral locally is increasing. However, the physical divide known as the “Wall of VRAM (Video RAM)” stands in the way here.

The inference speed of an LLM depends more strongly on Memory Bandwidth rather than the calculation performance (FLOPS) of the GPU (it has a Memory-bound nature). Assuming the number of parameters of the model is $P$ and the precision is 16-bit (2 bytes), just loading the model into memory requires at least $2P$ bytes of VRAM. For example, a 70 billion (70B) parameter model demands over 140GB of VRAM.

$$ VRAM_{required} \approx \left( \frac{P \times bits\_per\_weight}{8} \right) + Context\_Memory $$

Even with high-end GPUs available to general consumers (like the NVIDIA RTX 4090), VRAM is limited to 24GB, making it impossible to run a 70B class model as is. Here, “Quantization” technologies like AWQ and GGUF have emerged, and a technical struggle is taking place to find a compromise by compressing weights to 4-bit or 8-bit, but performance degradation (worsening of Perplexity) due to quantization is inevitable.

Furthermore, in recent years, “AI PCs” equipped with NPUs (Neural Processing Units) have appeared, but the TOPS (Tera Operations Per Second) of current NPUs can only handle lightweight, small-scale models (SLMs: Small Language Models) at best. To truly perform highly advanced inference locally, you need the capital to build a multi-GPU environment costing millions of yen. This is the true nature of the “capital-intensive digital divide” in AI.

5. The Cognitive Divide: The Loop of Hallucination and Verification

What is more terrifying than the disparity in hardware and skills is the “Cognitive Divide.” AI generates highly fluent and persuasive text, but at the same time, it causes “hallucinations,” outputting completely baseless information as if it were plausible.

The divide that arises here is the separation between “the class that critically examines and verifies (fact-checks) AI output” and “the class that blindly believes AI output as an authoritative truth.” The former utilizes AI as a powerful brainstorming and drafting tool, performing quality assurance (QA) on the final output using their own domain knowledge. The latter sends incorrect information out into the world as is, which not only ruins their own credibility but also contributes to polluting the internet’s information space with spam-like content.

The process of the Cognitive Verification Loop to prevent this is shown below.

flowchart TD
A["Human Intent"] --> B["Prompt Input to AI (Prompting)"]
B --> C["Generation by AI Model (Generation)"]
C --> D{"Cognitive Verification"}
D -- Doubts / Logical Failures Exist --> E["Fact-checking using RAG or external tools"]
E --> F["Readjusting / Refining Prompts"]
F --> B
D -- Facts and Logic are Valid --> G["Final adjustments based on human domain knowledge"]
G --> H["Output of Final Deliverable"]

To iterate through this loop, one needs not only to understand how to use AI but also to possess deep “domain knowledge” and “critical thinking” concerning the output domain. Ironically, the more AI evolves, the more the requirements for humans shift away from basic operational skills to highly advanced cognitive abilities, such as philosophical and logical reasoning and the cultural sophistication to distinguish truth from falsehood.

6. The New Class Society: AI Orchestrators and Manual Workers

In a future where these disparities have reached their limits (or a reality currently unfolding), the labor market will polarize in unprecedented ways.

1. AI Orchestrators (Top 1-5%) In their fields of expertise, they construct workflows that autonomously run multiple AI agents. They delegate the majority of processes, such as research, coding, data analysis, and report generation, to AI, specializing themselves in “process design,” “exception handling,” and “final decision-making.” Their productivity reaches tens to hundreds of times that of traditional workers, creating immense economic value.

2. Traditional Knowledge Workers / Manual Workers These are people who write code with their own hands, operate Excel with their own hands, and write text with their own hands. Their jobs will gradually be replaced by AI, or they will be relegated to “end-point monitoring and maintenance” of systems created by AI orchestrators, or forced into “labor in physical space.” Intellectual labor that does not utilize AI faces the risk of entirely losing its market competitiveness.

Amidst this overwhelming divide, how should individuals, corporations, and society adapt?

Individual Strategies: Adapting to the Paradigm Shift

The most important thing is to discard the underestimation that “AI is just a chatbot.” It is necessary to develop the habit of treating AI as an “advanced intern” or a “team of experts” and constantly thinking about how you can break down your own work processes and delegate them to AI (Task Decomposition). Also, even if you cannot program, learning about the concept of APIs and data structuring (like JSON) enables powerful automation by combining No-Code/Low-Code tools (Zapier, Make, etc.) with AI.

Corporate Strategies: AI-Native Organizational Design

For companies, simply “distributing ChatGPT accounts” is not enough. It requires infrastructure investment, such as redesigning the entire workflow around AI (BPR: Business Process Re-engineering), building a secure RAG environment, and fine-tuning local models with internal proprietary knowledge. Furthermore, introducing new KPIs to evaluate employees’ AI orchestration capabilities is also required.

At the national and societal levels, safety nets and education are needed so that the 3rd Digital Divide does not lead to severe economic disparities and social unrest. For instance, public support for the R&D of open-source AI models and making “Critical AI Literacy” compulsory in educational institutions can be considered. In addition, updating appropriate legal regulations and antitrust laws to prevent the “monopolization of AI models and computing resources” by Big Tech companies should be brought to the table for discussion.

8. Conclusion: Ride the Wave of Evolution, or Be Swallowed by It

The “new digital divide” caused by Generative AI is restructuring our society more rapidly and broadly than any technological innovation in the past. This divide appears as a difference in hardware computational resources, the ability to invest in Cloud APIs, and above all, the “cognitive and logical skills to orchestrate AI.”

As the Matthew Effect of productivity indicates, this gap will expand unbridgeably over time. What we must do now is neither to fear the evolution of AI nor to blindly believe in it. It is to deeply understand the characteristics of AI, the greatest Intelligence Amplifier in human history, and decisively execute an “intellectual self-transformation” to update our own thinking and workflows.

Will we stand on this side of the new digital divide, or remain on the other side? That choice is entrusted to our daily learning and actions, right at this very moment.

If you have any opinions on this article or specific case studies on introducing AI orchestration, please send them to the comment section or the author’s social media.