Industry on kenji.blog

How SNS Algorithms Influence Our Thinking and Tech Selection

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

1. Introduction: Democratization of Tech Information and the Rise of Algorithms

In modern software engineering, much of the technical information we consume daily passes through Social Networking Services (SNS) like X (formerly Twitter), Hacker News, Reddit, and LinkedIn, or news aggregators. There was once an era where we gathered information autonomously and chronologically through mailing lists, expert-run blogs, or RSS readers. However, with the explosive increase in frameworks and tools created every day, it has become common practice to entrust information curation to “Recommendation Algorithms” provided by platforms in order to optimize our limited cognitive resources (disposable time and attention).

This paradigm shift has brought the immense benefit of efficiently discovering valuable technical articles and groundbreaking open-source projects. On the other hand, it has also caused a highly critical side effect. That is the fact that “the technical trends and best practices we see are distorted not by pure technical superiority or objective evaluation, but by the algorithm’s ’engagement optimization function’.”

In this article, we mathematically and structurally unravel how the advanced machine learning algorithms running behind the scenes of SNS shape our cognition and influence decision-making in tech selection. Furthermore, we deeply consider the dangers of “Hype Driven Development (HDD),” where one is swept away by the hype created by algorithms, and concrete approaches to break free from it and make objective, robust tech selections.

2. Evolution and Mechanism of Recommendation Algorithms

When we open an SNS, the content displayed on our timeline (feed) is not random. There are machine learning models highly tuned to maximize user retention time and improve ad revenue. First, let’s look at the foundational technologies behind these.

2.1 Collaborative Filtering and Matrix Factorization

“Collaborative Filtering” has served as a powerful baseline from the dawn of recommendation systems to the present. In particular, “Matrix Factorization,” which represents the interaction between users and items (posts or articles) as a matrix and maps them into a latent feature space, is widely used.

Given an evaluation matrix $R \in \mathbb{R}^{M \times N}$ with $M$ users and $N$ items, matrix factorization approximates this large, sparse matrix as the product of a low-dimensional latent feature matrix $U \in \mathbb{R}^{M \times K}$ (user features) and $V \in \mathbb{R}^{N \times K}$ (item features) ($K \ll M, N$).

$$ R \approx U \times V^T $$

The predicted score (probability of engagement) $\hat{r}_{ij}$ of item $j$ for a specific user $i$ is calculated as the inner product of their respective latent feature vectors.

$$ \hat{r}_{ij} = \mathbf{u}_i \cdot \mathbf{v}_j $$

This model is trained to minimize the following loss function ($\lambda$ is a regularization term to prevent overfitting).

$$ \mathcal{L} = \sum_{(i,j) \in \Omega} (r_{ij} - \mathbf{u}_i \cdot \mathbf{v}_j)^2 + \lambda (\|\mathbf{u}_i\|^2 + \|\mathbf{v}_j\|^2) $$

Impact on Tech Selection: This algorithm brings “Person A who is interested in Rust” and “Person B who is interested in Rust” closer together in the latent space. If Person A “likes” a post about an emerging Web framework, posts about that framework will appear on Person B’s timeline with a high probability. Because of this, a phenomenon occurs where specific technologies become locally popular within engineer groups that prefer certain tech stacks.

2.2 Deep Learning Recommendation Model (DLRM)

In recent years, deep learning-based architectures, represented by the Deep Learning Recommendation Model (DLRM), have become widespread, centered around companies like Meta (formerly Facebook). DLRM receives a wide variety of features as input, such as the user’s past behavior history and item metadata, and predicts the Click-Through Rate (CTR) and the like.

The characteristic of DLRM lies in converting sparse categorical features (e.g., User ID, followed hashtags) into dense vectors through an “Embedding Table,” and combining them with continuous dense features (e.g., days since account creation, past average retention time).

$$ \mathbf{e}_{\text{sparse}} = \text{EmbeddingLookup}(\mathbf{x}_{\text{sparse}}) $$$$ \mathbf{h}_{\text{dense}} = \text{BottomMLP}(\mathbf{x}_{\text{dense}}) $$

After combining these through concatenation or interactions like inner products (Feature Interaction), they are input into a Top Multilayer Perceptron (Top MLP) to output the final probability of CTR, etc., using a sigmoid function $\sigma$.

$$ \hat{y} = \sigma(\text{TopMLP}(\text{Interact}(\mathbf{e}_{\text{sparse}}, \mathbf{h}_{\text{dense}}))) $$

Impact on Tech Selection: Giant models like DLRM capture even extremely subtle signals (for example, a slight increase in retention time for “posts with videos” or “posts containing specific buzzwords”) and reflect them in the prediction score. As a result, technical information that includes “radical titles (e.g., ‘React is dead’, ‘The End of Microservices’)” or “visually flashy demos” tends to be algorithmically favored.

2.3 Reinforcement Learning and Multi-Armed Bandits

Recommendation systems must constantly explore the user’s latest preferences. Here is where the “Multi-Armed Bandit problem” comes in. It optimizes the trade-off between “Exploitation” (presenting reliable content based on existing preferences) and “Exploration” (discovering new trends).

In UCB (Upper Confidence Bound), a representative algorithm, the score for selecting arm (content group) $a$ at time $t$ is calculated as follows.

$$ a_t = \arg\max_{a} \left( \hat{\mu}_a + c \sqrt{\frac{\ln t}{N_a(t)}} \right) $$

Here, $\hat{\mu}_a$ is the average reward (engagement rate) of arm $a$ so far, $N_a(t)$ is the number of times it has been selected, and $c$ is a parameter that adjusts the degree of exploration.

Impact on Tech Selection: The algorithm temporarily gives an exploration bonus to posts about newly introduced frameworks or libraries (those with a low number of trials $N_a(t)$) and exposes them to a random group of users. In this initial “exploration phase,” if the reaction from influencers and others is good, $\hat{\mu}_a$ sharply rises, rapidly developing into a buzz (viral). This is the mechanism of “suddenly everyone starts talking about that technology.”

3. The Mathematics of Echo Chambers and Filter Bubbles

As algorithms become more optimized, users find themselves surrounded only by “information they find comfortable or information that reinforces their existing beliefs.” This is the Echo Chamber phenomenon and the Filter Bubble.

In network theory, the tendency for similar individuals to connect is called “Homophily.” In a graph $G=(V, E)$, edges (follow relationships and information propagation) between nodes (users) are more likely to form the higher the similarity of attributes.

SNS recommendation algorithms artificially accelerate this homophily. For example, suppose there is a community of engineers promoting “Serverless Architecture” and another supporting “On-Premises Bare Metal.” The algorithm learns to lower the weight of cross-cutting ties between different communities and strengthen edges within the same community (because opposing opinions often cause user churn and carry the risk of lowering engagement. Or conversely, it might trigger engagement through extreme anger, but the former tends to be more common in tech circles).

As a result, a completely divided technological reality is created, where on your timeline it looks like “companies all over the world are migrating to serverless,” while on someone else’s timeline it looks like “Cloud Repatriation is a global trend.”

4. Hype Driven Development (HDD) Created by Algorithms

The combination of echo chambers and powerful recommendation models triggers one of the biggest anti-patterns in the engineering industry: Hype Driven Development (HDD). HDD is the phenomenon of adopting new technologies simply because “they are trending on SNS” or “they are the latest trend,” without deeply considering the actual merits, trade-offs, or compatibility with one’s own business requirements.

The Mermaid diagram below shows how SNS algorithms spin the feedback loop of HDD.

graph TD
A["Engineers post the 'overwhelming benefits' of a new tech"] --> B["Algorithm measures initial CTR and retention time (Exploration)"]
B --> C["Judged as high engagement, exposure expands to similar users' TLs"]
C --> D["Users stimulated by FOMO (Fear Of Missing Out) further spread it"]
D --> E["Occurrence of Frequency Illusion: 'It's becoming the industry standard'"]
E --> F["Introduced into real projects without sufficient verification (HDD)"]
F --> A

What is terrifying about this loop is that the “Baader-Meinhof phenomenon (Frequency Illusion)” is intentionally triggered by the algorithm. Once you see the name of a new state management library, the algorithm captures it as a signal and fills your feed with topics about that library from the next day. The human brain misidentifies this as a “global pandemic.”

The chart below illustrates the difference in lifecycle between technologies overly hyped on SNS and “Boring Technology” that is plain and dull but robust.

xychart-beta
title Technology Lifecycle and Evaluation Trends
x-axis ["Month 0", "Month 6", "Month 12", "Month 18", "Month 24", "Month 30", "Month 36"]
y-axis "Number of Mentions / Hype Level on SNS" 0 --> 100
line [10, 85, 95, 45, 20, 10, 5]
line [15, 20, 25, 35, 50, 65, 80]

(Note: In the graph above, the line that sharply rises and falls indicates the “Hyped Technology,” while the line that slowly and steadily rises indicates “Boring Technology”)

Hyped technologies face realistic problems such as “lack of documentation,” “critical bugs in edge cases,” and “maintainer burnout” 6 to 12 months after introduction, and rapidly disappear from SNS. However, once technical debt is embedded into a system, removing it costs an enormous amount.

5. “Escaping the Algorithm” Strategies in Tech Selection

So, how should we make objective and calm tech selections under the dominance of these algorithms? Here are some concrete strategies not to hack the algorithm, but to “step off” from it.

5.1 Returning to Primary Information: Source Code and RFCs

The most reliable defense is to shift your information sources from SNS aggregations to Primary Sources.

Read the Source Code: Instead of believing SNS posts saying “This library is blazingly fast,” actually open GitHub and check the core logic’s time complexity and memory allocation mechanisms.
Follow RFCs (Request for Comments): Many mature open-source projects (React, Rust, Python, etc.) adopt the RFC process when introducing new features. RFCs objectively and logically describe “Why this feature is necessary,” “What the design trade-offs are,” and “What the alternatives are,” without worrying about algorithm engagement. This is where true technical value lies.

5.2 Close Reading of Academic Papers and Whitepapers

When it comes to foundational tech selections like distributed systems, databases, or machine learning model architectures, you should directly read papers published in ACM, IEEE, or arXiv, or detailed whitepapers published by companies (e.g., Google’s Spanner paper, Amazon’s Dynamo paper), rather than a few lines of summary on SNS.

SNS posts are optimized to “steal readers’ attention,” whereas peer-reviewed papers are optimized for “factual accuracy and reproducibility.” The evaluation functions are entirely different.

5.3 Building an In-House Decision-Making Framework

To prevent HDD at the team or organizational level, a process is needed to eliminate personal intuition or reasons like “because I saw it on Twitter.” A prime example of this is the introduction of ADR (Architecture Decision Records).

When introducing a new technology, you must always document the following items and undergo a review:

Context: Why is the new technology necessary? What are the current issues?
Decision: What will be adopted?
Consequences: What are the trade-offs? (What is gained at the expense of what?)

By enforcing this process, “Hype” can be transformed into “Engineering.”

5.4 The Philosophy of the Boring Technology Club

There is a famous mantra in the tech community: “Choose Boring Technology.” This is a teaching that Innovation Tokens (the limited resources an organization can spend on new, unknown technologies) should not be wasted on selecting infrastructure or frameworks that are not directly tied to the core value of the business.

SNS algorithms prefer “novelty.” However, to build a robust system that can withstand real-world operations, what is needed is “boring” technology (like PostgreSQL, Redis, or standard REST APIs) that has over 10 years of operational track record and yields millions of Google search hits for disaster recovery procedures.

6. Conclusion: How We Should Face Technology

SNS recommendation algorithms are powerful tools that broaden our technical horizons and provide encounters with wonderful communities. However, as long as their internal structures (Matrix Factorization, DLRM, Multi-Armed Bandits) have “engagement maximization” as their supreme imperative, the information output is inevitably biased.

We need to acquire the literacy to treat the information flowing into our timelines not as “facts” or “absolute trends,” but merely as a single “signal.”

Stepping out of the echo chamber, reading source code with our own hands, following RFC discussions, deciphering the math in papers, and facing the true challenges of our business domains. That alone is the only path to practicing true software engineering without being swallowed by the waves of algorithms.

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 '2026 Problem': Is the IT Talent Shortage Really Happening? The Reality on the Ground

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

Introduction: The Trap of the Term “IT Talent Shortage”

For a long time, sensational terms like the “2025 Cliff” and “a maximum shortage of 790,000 IT personnel by 2030” have been flying around the media in the Japanese IT industry. However, what we are currently facing is an entirely new phase of crisis that should be called the “2026 Problem”.

Reports from the Ministry of Economy, Trade and Industry and various media coverage lump things together by saying, “there is an overwhelming shortage of IT engineers.” However, when you listen to the real voices on the ground, the situation is a bit more complex. In reality, it’s not that “everyone is in short supply.” While there is a catastrophic shortage of “highly skilled senior engineers that companies desperately want,” there is an oversupply of “inexperienced or junior engineers,” making it increasingly difficult for them to find jobs. This is an intense “polarization” that is taking place.

This article will deeply explore and explain exactly what is happening in the IT industry right now, covering the paradigm shift from the traditional SIer model to cloud-native and AI-driven development, the cliff of legacy systems, and the disruptive impact brought about by generative AI, represented by GitHub Copilot.

1. Structural Change: The Transition from Traditional SIer to Cloud-Native and AI-Driven Development

For many years, the Japanese IT industry was supported by the SIer (System Integrator) model, accompanied by a multi-tiered subcontracting structure. It was a so-called “labor-intensive” business model, where code was written exactly according to specifications, and test specification sheets were filled out. Here, the value of an engineer was measured in units of “person-months,” and there was an underlying assumption that projects would run as long as the headcount was met.

However, as of 2026, this model has reached its limit. Because the essence of DX (Digital Transformation) has shifted from “mere IT implementation” to “business model transformation,” low-agility waterfall development can no longer keep up with market changes.

Modern development processes are built on the premise of being cloud-native and AI-driven. Containerization (Docker/Kubernetes), microservices architecture, and CI/CD pipeline automation are no longer “special technologies” but “standard infrastructure.”

graph TD
A["Legacy SIer Development Model"] -->|Paradigm Shift| B["Transition Period (Agile Adoption, Lift & Shift)"]
B --> C["Cloud-Native (Microservices/Containers)"]
C --> D["AI/Data-Driven Architecture (MLOps)"]
D --> E["Generative AI Integration Platform (Autonomous AI Agents)"]
style A fill:#f9d0c4,stroke:#333,stroke-width:2px
style E fill:#d4edda,stroke:#333,stroke-width:4px

What companies demand are not just “coders” who merely write code based on provided specifications. They need talent who can look ahead—from cloud infrastructure design to backend implementation, and even the real-world operationalization of machine learning models (MLOps)—and translate business requirements into technical architectures. In an area that demands such broad knowledge and experience, personnel who “simply know the syntax of a programming language” are finding it difficult to generate value.

2. The “Cliff” of Legacy Systems and the Depletion of Data Engineering

As warned by the “2025 Cliff,” many Japanese companies still cling to mainframes and on-premises legacy systems (built with COBOL, etc.). These systems have become black boxes due to years of modifications, and maintaining them has become extremely difficult as the senior generation in charge of maintenance reaches retirement age.

On the other hand, there is a strong demand from the business side to “utilize data to build AI models and provide personalized customer experiences.” A fatal gap exists here. There is an overwhelming shortage of “data engineers” who can cleanse, integrate, and pipeline siloed on-premises data into formats usable by the latest AI/ML pipelines.

A Mathematical Model of Legacy Maintenance Costs and Modernization

Here, let’s consider a simple mathematical model that compares the cost of maintaining a legacy system ($C_{legacy}$) with the investment required for modernization (renewal) and the subsequent operational costs ($C_{modern}$).

The maintenance cost of legacy systems increases year by year. This is due to incident response caused by technical debt and the soaring personnel costs resulting from the scarcity of legacy technicians. Letting $t$ be the number of years, this can be expressed as follows:

$$ C_{legacy}(t) = M_0 \times (1 + r)^t + L_0 \times (1 + i)^t $$

Where:

$M_0$: Initial maintenance cost
$r$: Rate of increase in maintenance costs due to technical debt
$L_0$: Initial legacy personnel cost
$i$: Personnel cost inflation rate due to the scarcity of legacy talent

On the other hand, when modernizing, the initial investment $I$ is significant, but the operational cost $O_m$ is kept low through cloud migration and automation, and it tends to remain constant.

$$ C_{modern}(t) = I + O_m \times t $$

In many cases, it is obvious that $C_{legacy}(t) > C_{modern}(t)$ will occur within a few years (the break-even point). However, the reality of 2026 is that many companies are sinking into the quagmire of $C_{legacy}$ because the “architects” and “data engineers” capable of executing the initial investment $I$ simply do not exist in the market.

pie title Breakdown of the Most Lacking IT Skills as of 2026
"AI/ML Ops Specialists" : 35
"Cloud Architects" : 25
"Data Engineers" : 20
"Legacy Migration (COBOL, etc.)" : 15
"Others" : 5

3. The Disruptive Impact of Generative AI: GitHub Copilot and the Disappearance of Junior Engineers

When discussing the IT talent shortage, we absolutely cannot ignore the rise of Generative AI. Tools like GitHub Copilot, Cursor, and ChatGPT (GPT-4o and the O1 series) have fundamentally altered the productivity of software development.

Previously, a common team structure involved senior engineers dedicating their time to complex design and reviews, while delegating simple CRUD (Create, Read, Update, Delete) operations, boilerplate (standardized code), and test code writing to junior engineers.

However, today, 90% of these “tasks formerly handled by juniors” can be generated by generative AI in seconds to minutes, and with high accuracy. What was the result? Companies have lost the reason to hire junior engineers.

Changes in the Productivity Multiplier Due to Generative AI

Let’s express the total productivity of a development team before and after AI adoption using a formula.

Let the base productivity be $P$. Let the productivity improvement rate of senior engineers due to generative AI adoption be $\alpha_{senior}$, and the productivity improvement rate of junior engineers be $\alpha_{junior}$.

$$ \text{Total Output}_{pre} = N_{senior} \times P_{senior} + N_{junior} \times P_{junior} $$$$ \text{Total Output}_{post} = N_{senior} \times P_{senior} \times (1 + \alpha_{senior}) + N_{junior} \times P_{junior} \times (1 + \alpha_{junior}) $$

At first glance, it appears that junior productivity also improves. However, in the real-world field, the ability to “verify the validity of AI-output code, integrate it into the entire system, and judge whether there are security concerns” is indispensable. This ability (contextual understanding and architectural design capability) is lacking in juniors.

As a result, senior engineers master AI as a “superb assistant (an endlessly working junior),” skyrocketing their productivity by $2 \sim 3$ times ($\alpha_{senior} \approx 2.0$). Conversely, when juniors without fundamental skills use AI, they mass-produce spaghetti code riddled with debt, even if it looks like it works at a glance, which instead leads to increased review costs (there are even cases where effectively $\alpha_{junior} < 0$).

Consequently, companies have realized that “hiring one senior (AI user) with a monthly salary of 1.2 million yen” is overwhelmingly lower risk and higher performance than “hiring three juniors with a monthly salary of 300,000 yen.” This is the true nature of the “talent shortage.” There is an absolute lack of “seniors who can master AI.”

xychart-beta
title Polarization of Job Demand Between Junior and Senior Levels (2021-2026)
x-axis ["2021", "2022", "2023", "2024", "2025", "2026"]
y-axis "Jobs-to-Applicants Ratio" 0.0 --> 10.0
line ["Senior (Architect/MLOps, etc.)"] [3.0, 3.5, 4.2, 5.8, 7.5, 9.2]
line ["Junior (Inexperienced/1-2 Years Exp)"] [2.5, 2.2, 1.8, 1.2, 0.8, 0.3]

4. Beyond Prompt Engineering: What Are the Truly Necessary Skills?

So, what kind of IT talent is required in the coming era? It’s premature to think that “mastering prompt engineering is enough.” The skill of issuing instructions in natural language is becoming easier and commoditized as AI models evolve.

The reality on the ground is that talent capable of covering the following three areas is what is truly sought after today.

A. Domain-Driven Design (DDD) and Business Modeling

AI can write code, but it cannot “unravel the complex specifications of a business, discover the Bounded Context of software, and design appropriate data models.” The skill of “Domain-Driven Design (DDD)"—deeply understanding a client’s domain (business area) and translating it into technical terms—is one of the most valuable skills in the AI era.

B. Architecture and Non-Functional Requirement Design

“Non-functional requirements” such as system availability, scalability, security, and performance are not automatically optimized by AI. Architectural decisions like “which cloud services should be combined,” “what the communication protocol between microservices should be,” or “where to draw DB transaction boundaries” still rely heavily on advanced human experience and intuition.

C. MLOps and Data Pipeline Construction

The concept of “MLOps” for continually operating generative AI and machine learning models in production environments is becoming increasingly important. Talent with skills located at the intersection of software engineering and data science—such as monitoring model drift (accuracy degradation), pipelining continuous training, and optimizing GPU resources—is in high demand.

5. Survival Strategies for Engineers: Surviving 2026 and Beyond

Under these circumstances, how should we engineers build our careers? The situation might look hopeless, especially for inexperienced engineers. However, depending on your strategy, there are plenty of ways to break through.

Strategy 1: Aim to be an “AI Orchestrator”

Instead of becoming an expert in a single language or framework, hone your ability as an “orchestrator” who combines multiple AI tools and agents to build entire systems. You need to reduce the time you spend writing code yourself, piece together the components generated by AI, and hold a “higher-level perspective” that oversees the entire architecture.

Strategy 2: Acquire Domain Knowledge

Beyond technical skills, gain deep domain knowledge in specific industries (finance, healthcare, logistics, etc.). Engineers who thoroughly understand the pain points of business workflows possess a powerful persuasiveness that AI cannot imitate when proposing technical solutions. Leave the “HOW” to AI, and focus on the “WHAT” and “WHY”.

Strategy 3: Soft Skills and Stakeholder Management

In large-scale system development, ultimately, “building human relationships” and “expectation management” determine the success or failure of a project. “Human skills”—such as defining requirements with clients, team facilitation, and building consensus on complex decisions—are the areas most difficult for AI to replace. Talent with excellent communication skills, rooted in technology, will be even more heavily prized in the future.

graph LR
A["Mere Coder"] -->|AI Substitution| B["Decreased Demand"]
A -->|Strategic Shift| C["System Architect"]
A -->|Strategic Shift| D["Domain Expert"]
A -->|Strategic Shift| E["AI Integrator"]
C --> F["High Demand / High Rate (Winners in 2026 and Beyond)"]
D --> F
E --> F
style B fill:#f9c2c2,stroke:#333
style F fill:#c8f9c2,stroke:#333,stroke-width:2px

Conclusion: Ride the Wave Instead of Fearing It

I hope you now understand that the “2026 Problem” and the accompanying reality of the IT talent shortage are not a simple “lack of headcount,” but a “mismatch caused by a dramatic shift in required skills.”

The weight of legacy systems, the depletion of data engineers, and the paradigm shift driven by generative AI. These waves are a threat to traditional engineers, but for those who can embrace the change and update their skill sets, they represent a massive opportunity like never before.

AI is not going to steal our jobs; it is merely a tool that allows us to focus on more advanced and creative work. To be freed from the “chore” of coding and focus on the “design” of systems and the “creation of value” in business. That is the only path to surviving—and thriving—in the IT industry from 2026 onwards.

Now is the time to review your career path and steer toward the next paradigm. Are you ready to “modernize” yourself?

The Current State and Challenges of IT Education in Japan: After the Mandatory Programming Education

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

1. Introduction: The Light and Shadow Brought by Mandatory Programming Education

With the mandatory implementation of programming education in elementary schools in 2020, its expansion in junior high school technology and home economics classes in 2021, and the mandatory introduction of the new subject “Information I” in high schools in 2022, IT and information education in Japan have experienced an unprecedented paradigm shift in recent years. At the root of this series of policies lies a very pressing national demand: the cultivation of logical thinking skills (programming thinking) necessary to survive in the Society 5.0 (Super Smart Society) era, and the resolution of the chronic shortage of highly skilled IT professionals in the industry.

However, looking at the front lines of education, it has become apparent that there is a massive disconnect between the ideal envisioned by the government and reality. The most serious issue is the complete conflation of “learning programming as a tool” and “mastering the academic discipline of computer science.” Furthermore, structural challenges are piling up, including the technical limitations due to the hardware specs of the nationwide IT infrastructure, and the lack of professional skill sets among the teachers who are supposed to instruct the students.

This article summarizes the “aftermath” of the mandatory programming education in Japan and explores in detail and technically the fundamental and structural problems facing IT education today. It examines these issues from the perspectives of computer science theory, hardware architecture constraints, and global industrial competitiveness. Spanning approximately 10,000 characters, this is not just an educational discourse, but an essay that considers the future of Japan from the viewpoint of software engineering.

2. The Trap of Visual Programming: The Deep and Steep Chasm from Scratch to Text Coding

The de facto standard in elementary school programming education is visual programming languages (block programming), represented by “Scratch” developed by the MIT Media Lab. The fact that it allows beginners to visually and intuitively learn the three basic algorithmic control structures—sequence, selection, and iteration—by combining puzzle-like blocks using an intuitive graphical interface makes it a great invention that deserves high praise as introductory education.

However, there is a major pitfall here, which can be called the “trap of abstraction.” That is the cruel reality that “transitioning from visual programming to a full-fledged text-based programming language (Python, JavaScript, C++, Rust, etc.) is extremely difficult, and many learners drop out at this stage.”

The Wall of Abstraction and the Black-Boxing of Computer Science

Visual programming environments like Scratch highly abstract and intentionally hide (encapsulate) the fundamental elements of computer science, such as the complex syntax of programming, strict type systems, and memory lifecycle management. While this is excellent for lowering the cognitive load on beginners, it becomes a massive barrier when advancing to genuine engineering. In actual software development, an understanding of variable scope (local and global variables), complex data structures (arrays, linked lists, hash tables, binary search trees, graphs), pointer manipulation, and memory heap and stack regions is absolutely essential.

The following Mermaid diagram visualizes the learning hurdles and dropout points that beginners face during the transition from visual programming to authentic computer science.

flowchart TD
A["Elementary School: Scratch (Visual/Block-based)"] --> B{"Junior High: The Wall of Transition to Text Languages"}
B -->|Frustration from strict syntax errors| C["Dropout (Syntax Allergy)"]
B -->|Lack of conceptual understanding of variables and static typing| D["Dropout (The Wall of Types)"]
B -->|Successful Transition| E["High School: Information I (Basics of Python/JavaScript, etc.)"]
E --> F{"The Wall of Algorithm Design and Data Structures"}
F -->|Lack of understanding of time and space complexity| G["Inefficient Code (Performance degradation from mass-producing O(N^2))"]
F -->|Black-boxing of memory management and references| H["Becoming a coder who only does superficial API calls"]
F -->|Conceptual Breakthrough| I["Full-scale CS Learning (C/C++, Java, Low-level Architecture)"]
I --> J["Highly skilled IT professionals coveted by the industry"]
classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px;
classDef error fill:#ffcccc,stroke:#cc0000,stroke-width:2px;
classDef success fill:#ccffcc,stroke:#00cc00,stroke-width:2px;
class C,D,G,H error;
class J success;

As is evident from this flowchart, merely accumulating the experience of “writing code to move characters on a screen” will not cultivate true software engineers who can design scalable distributed system architectures and optimize performance down to the millisecond. Between the task of assembling colorful Scratch blocks with a mouse and reading the C source code of the Linux kernel to trace the behavior of the TCP/IP stack, there lies an absolute conceptual disconnect that cannot be dismissed simply as “a difference in the language used.”

3. The Limits of Coding Without “Mathematics” and “Discrete Logic”: An Approach from Computational Complexity Theory

The greatest weakness and a potentially fatal flaw in Japan’s programming education curriculum is the overwhelming lack of integration between “coding skills” and “mathematics / discrete mathematics.” In top-tier computer science education, such as in the United States and India, the emphasis is placed on algorithm efficiency, mathematical logic, and mathematical proofs rather than the syntax of the programming language itself. This is because code is merely a translation of mathematical formulas.

The Absolute Dominance of Time Complexity and Space Complexity (Big O Notation)

When evaluating and designing software performance, the concepts of Time Complexity and Space Complexity are unavoidable. Landau’s asymptotic notation (Big O Notation) indicates how execution time and memory consumption increase when the input data size to an algorithm is $N$.

Mathematically, $f(x) = O(g(x))$ is strictly defined as follows:

$$ \exists C > 0, \exists x_0 > 0, \forall x > x_0, |f(x)| \le C \cdot |g(x)| $$

In Japan’s information education, when learning about data sorting, for example, there are cases where it simply ends with calling a built-in method like array.sort() in Python. However, what is truly required in information engineering is the mathematical understanding and proof of why the simple Bubble Sort is never used in practical domains, and why Quick Sort, Merge Sort, or Timsort are adopted as standard libraries.

Below are the average time complexities of representative sorting algorithms.

Bubble Sort: $O(N^2)$
Selection Sort: $O(N^2)$
Insertion Sort: $O(N^2)$
Merge Sort: $O(N \log N)$
Quick Sort: $O(N \log N)$
Heap Sort: $O(N \log N)$

For instance, the time complexity $T(N)$ of Merge Sort is expressed by the following recurrence relation based on the Divide and Conquer paradigm.

$$ T(N) = 2T\left(\frac{N}{2}\right) + O(N) $$

By expanding and solving this recursive relation using the Master Theorem, the ideal computational complexity $T(N) = O(N \log N)$ is derived.

$$ T(N) = \Theta(N \log_2 N) $$

In modern big data analytics and web-scale traffic processing, the order of $N$ is massive, reaching hundreds of millions or billions. If an ignorant programmer implements an inefficient $O(N^2)$ algorithm, it would require a staggering $10^{12}$ (1 trillion) useless comparison operations for data size $N = 10^6$, effectively causing the system to freeze and crash. On the other hand, $O(N \log N)$ would complete in about $2 \times 10^7$ (20 million) operations. To claim “I can program” without this cruelly rigorous mathematical backing is like building a skyscraper without knowing structural mechanics, which is extremely dangerous.

4. The Black-Boxing of Memory Management and System Architecture

At an even deeper layer is the complete omission of the understanding of Memory Management and CPU architecture. Learners who have only been taught high-level languages with Garbage Collection (GC), like Python and JavaScript, in schools today will never in their lives be conscious of where variables and objects are physically allocated in RAM (heap vs. stack), how they are assigned, and when and how they are freed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


// Example of explicit and direct memory allocation and pointer manipulation in C
#include <stdio.h>
#include <stdlib.h>

int main() {
 int n = 1000000;
 // Dynamically allocate memory consecutively in the heap (System call to the OS)
 int *array = (int*)malloc(n * sizeof(int));

 if (array == NULL) {
 fprintf(stderr, "Memory allocation failed! Out of memory.\n");
 return 1;
 }

 // Initializing the array using pointer arithmetic
 for(int i = 0; i < n; i++) {
 *(array + i) = i * 2; // Equivalent to array[i] = i * 2
 }

 // Explicit resource deallocation to prevent Memory Leaks
 free(array);
 array = NULL; // Prevent dangling pointers

 return 0;
}

Knowledge of pointers (direct references to memory addresses), data placement to maximize CPU cache hierarchy (L1/L2/L3 cache) hit rates (Data Locality), and Race Conditions and mutual exclusion (Mutex/Semaphores) in multi-threaded environments are absolutely essential for developing high-performance backend systems, 3D game engines, or embedded systems for IoT. The current curriculum by the Ministry of Education, Culture, Sports, Science and Technology is focused solely on “running superficial applications” and has severely deviated from the original academic goal of “understanding the depths of computer science.”

5. The Wall of Databases and Persistence: The Absence of Relational Algebra

In modern applications, data saving and retrieval (persistence) is an unavoidable theme. However, much of school education remains stuck in “data processing in memory,” which disappears once the program finishes executing. The mathematical theory behind Relational Databases (RDBMS) and SQL, namely the “Relational Algebra” proposed by Dr. Edgar F. Codd, is rarely taught.

Database operations are defined by the following basic operations based on set theory:

Selection ($\sigma$): Extracting tuples (rows) that satisfy a condition
Projection ($\pi$): Extracting specific attributes (columns)
Join ($\bowtie$): Conditional intersection of multiple relations

Furthermore, learning the structure of the “B-Tree index” to instantly search for the desired data from a vast number of records is the best practical application of data structures. The B-Tree minimizes disk I/O operations while guaranteeing a search speed of $O(\log N)$. Without knowing the ACID properties (Atomicity, Consistency, Isolation, Durability) of a transaction, it is impossible to build robust systems.

While superficial security education like “Let’s make passwords complex” and “Don’t click on suspicious links” is conducted in information literacy education, the mathematics of “Cryptography” that fundamentally supports internet society is almost never taught.

The HTTPS communications and digital signatures we use every day are protected by public-key cryptography, such as RSA cryptography. The security of RSA relies on the mathematical difficulty (considered an NP-intermediate problem) that “the prime factorization of massive integers cannot be solved within a realistic time frame by current classical computers.”

The mathematical formulas underlying RSA cryptography are beautiful applications of Euler’s totient function and Fermat’s Little Theorem.

Choose two massive prime numbers $p$ and $q$
Calculate $n = p \times q$ (This becomes part of the public key)
Calculate $\phi(n) = (p-1)(q-1)$
Choose $e$ and $d$ such that $e \times d \equiv 1 \pmod{\phi(n)}$
Encryption: $C \equiv M^e \pmod{n}$
Decryption: $M \equiv C^d \pmod{n}$

In this way, programming education only truly unleashes its power when closely linked with mathematics education. The process of translating mathematical formulas into code and implementing them in society is the true essence of science.

7. The GIGA School Concept and the Hopeless Limits of Infrastructure: Chromebooks and Cloud IDEs

When discussing IT education in Japan, one cannot ignore the “GIGA School Concept,” a national project promoted by the Ministry of Education with a massive budget. This initiative to provide “one device per student” and high-speed network environments to elementary and junior high school students nationwide was expected to be a catalyst to catch up on the delay in digitalization. However, the hardware specs and architectures of the devices actually distributed have become a severe hindrance to full-scale programming education.

Low-Spec Devices and the Loss of Local Development Environments

Many of the devices introduced as standard under the GIGA School Concept are extremely cheap Chromebooks, iPads, or budget Windows devices. Their standard specs are as follows:

CPU: Intel Celeron or budget ARM processors
Memory (RAM): 4GB (barely enough to run a modern OS)
Storage (eMMC): 32GB to 64GB (extremely slow I/O speeds)

Due to these weak hardware constraints, it is virtually impossible to set up the “local development environments” that professional engineers use daily. Attempting to launch Linux containers using Docker, running heavy IDEs like Visual Studio Code with full features, or starting local Node.js or Python servers to install heavy libraries will immediately lead to memory exhaustion and system freezes.

As a result, educational frontlines are forced to rely entirely on cloud IDEs that run in the browser (such as Google Colaboratory, Replit, or lightweight web tools proprietary to textbook publishers).

flowchart LR
subgraph "GIGA Devices (Chromebook / iPad / Budget Windows)"
A["Web Browser (UI rendering only)"]
end
subgraph "Remote Cloud Infrastructure (AWS / GCP, etc.)"
B["Cloud IDE Web Server"]
C["Backend Compile/Execution Environment"]
D["Persistent File Storage"]
end
A -->| HTTP/WebSocket Communication: Severe latency due to narrow school network lines | B
B <--> C
B <--> D

Complete reliance on cloud IDEs causes the following critical educational deficiencies:

Lack of understanding of file systems and OS architecture: Without a local environment, students never acquire UNIX literacy—essential knowledge that IT engineers should use as naturally as breathing, such as directory structures, absolute and relative paths, environment variables, file permissions, and OS operations via the CLI (Command Line Interface).
Network latency and infrastructure vulnerabilities: Because constant connectivity is assumed, there are frequent nationwide incidents where school network bandwidth becomes congested the moment all students access it simultaneously, causing browsers to freeze and learning to completely stop.
Deprivation of version control (Git) experience: Students are robbed of the opportunity to have the concepts of Git and GitHub hammered into them through a black terminal screen, preventing them from learning how to manage source code history and collaborate globally.

When professional software engineers develop, operating within a terminal (shell) is the absolute foundation. Without the gritty experience of running commands like ls, cd, grep, chmod, and git rebase to interact directly with the local OS kernel, cultivating true IT talent is impossible. Playing solely within the sandbox of a Chromebook will never produce full-stack engineers who can oversee the entire system.

8. The Despairing Gap with the World: The Disconnect Between Industry Demands and School Education

The final and arguably national crisis-level challenge facing Japan’s IT education is the overwhelming decline in competitiveness in a global context.

Fierce Computer Science Education in Other Countries

In the UK, the subject “Computing” has been mandatory from age 5 (Key Stage 1) since as early as 2014. Their curriculum goes far beyond mere “programming experiences,” dealing with highly academic and systematic computer science, from logical algorithm design and understanding logic circuits via Boolean algebra, to network topologies and hardware architecture.

In the US, there are rigorous standard K-12 curriculums established by the CSTA (Computer Science Teachers Association). In the AP (Advanced Placement) Computer Science A course taken by high school students, they are tested on authentic object-oriented programming using Java, polymorphism, recursion, implementation of data structures, and algorithmic complexity evaluation at a level comparable to a first-year university course. The fierce STEM education in countries like India and China, and the depth of the elite talent they produce, hardly need further mention.

The Despairing Disconnect Between Required Skills and Taught Skills

The requirements that modern industries—especially globally expanding mega-ventures and tech giants (like GAFAM)—demand of new graduate software engineers are advancing at a terrifying speed every year. Extensive and deep expertise is required, including the construction of cloud-native infrastructure (AWS, GCP, Kubernetes), the design of distributed systems using microservice architectures, the implementation of machine learning pipelines, and advanced security knowledge.

The graph below conceptually illustrates the despairing gap between the skill attainment levels provided by Japan’s current school education and the skill levels demanded by the frontline industry.

xychart-beta
title Skills Provided by Japanese School Education vs. Skill Levels Demanded by Industry
x-axis ["Visual Languages", "Basic Syntax/Variables", "Algorithms/Complexity", "OS/Networks", "DB/System Design", "Cloud/Distributed Arch"]
y-axis "Attainment / Demand (%)" 0 --> 100
line "Current Attainment Level in School Education" [95, 60, 15, 5, 2, 0]
line "Level Demanded by Industry / Tech Companies" [0, 20, 85, 90, 95, 100]

To bridge this massive gap (Death Valley), a radical paradigm shift in school education and enormous investment are required. With an overwhelming nationwide shortage of specialized “Information” teachers, math, science, or technology and home economics teachers are currently teaching programming on the side with insufficient training. Under this system, Japan will never be able to produce top-tier engineers who can compete globally.

9. The Plummeting Value of “Coding” in the AI Era (LLMs)

Further complicating the situation is the explosive spread of Large Language Models (LLMs) like ChatGPT and AI coding assistants like GitHub Copilot. In an era where AI can instantly generate perfect code from natural language instructions and even write test codes, the market value of so-called “Coders” who merely “know Python syntax” or “know how to call an API” is rapidly plummeting.

What is required of human engineers in the AI era is not the memorization of programming language syntax. It is the following abilities:

Requirements Definition and Domain Modeling: The ability to extract complex real-world problems to be solved and model them as a system.
Architecture Design: The ability to draw a system-wide blueprint that guarantees scalability, availability, and maintainability.
Mathematical and Logical Verification: The ability to theoretically verify and prove whether the AI-generated code has security holes or computational bottlenecks.

Ironically, all of these lie not in “superficial programming,” but in the deep and abstract realms of “computer science and mathematics.” If Japanese education is only teaching “downstream skills that are easily replaced by AI,” it must be called a national loss.

10. Towards the Integration of Mathematical Sciences and Programming: A Proposal for Next-Generation Education

The urgent task for future IT education in Japan is to break away from “making programming the goal or a mere tool” and to return to the “exploration of computer science as a mathematical science.” A programming language is merely a tool to express thought, and the mathematical and logical structures underlying it possess universal value that will not fade even as times change.

For example, at the core of Artificial Intelligence (AI) and machine learning, linear algebra (matrix operations and tensors), multivariable calculus (gradient descent), and probability and statistics (Bayesian inference and information theory) are intricately intertwined. The optimization of weights in deep learning neural networks is formulated by the Chain Rule using partial derivatives and backpropagation.

$$ \frac{\partial L}{\partial w_{ij}^{(l)}} = \frac{\partial L}{\partial z_i^{(l+1)}} \cdot \frac{\partial z_i^{(l+1)}}{\partial w_{ij}^{(l)}} = \delta_i^{(l+1)} \cdot a_j^{(l)} $$

Professionals who can translate such advanced mathematical formulas into code, and optimally implement Parallel Computing while remaining conscious of GPU (CUDA) and TPU hardware architectures, are the ones who will lead the next-generation IT industry. That is why we must immediately steer away from superficial education that just makes students memorize syntax, and shift towards profound education that questions the First Principles of computation.

11. Conclusion: The Steep Path to a True IT Nation and Our Resolve

There is no doubt that making programming education mandatory in the 2020s was a solid step forward in terms of making Japanese society as a whole widely recognize the “importance of IT and information.” However, it is merely “warm-up exercises” in a long journey.

We must step beyond the fun of moving a cat character in Scratch, move students with the mathematical beauty of an $O(N \log N)$ algorithm, and teach them the excitement of conversing with servers around the world via TCP packets from a black terminal screen. We must rebuild new educational infrastructures to overcome the hardware constraints of the GIGA School Concept, train and deploy instructors with advanced CS expertise, and sometimes boldly involve external professional engineers in school education.

The challenges facing Japan’s IT education are extremely deep, persistent, and complex. However, if we do not avert our eyes from these issues, and if industry, academia, and government work together in earnest to build an ecosystem that continuously produces not just “laborers who can write code according to specifications,” but “genuine engineers who can design and create systems from scratch,” Japan will once again be able to lead the world as a true IT nation.

How we fight through the “aftermath” of mandatory programming—the most difficult and important phase—is testing the absolute seriousness and resolve of us adults right now.

This article outlined the computational complexity theory and the infrastructural limits of the GIGA School Concept. We plan to cover more specialized computer science topics (such as details of distributed system algorithms and low-level memory management techniques) sequentially in future series.

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.

Industry on kenji.blog

How SNS Algorithms Influence Our Thinking and Tech Selection

1. Introduction: Democratization of Tech Information and the Rise of Algorithms

2. Evolution and Mechanism of Recommendation Algorithms

2.1 Collaborative Filtering and Matrix Factorization

2.2 Deep Learning Recommendation Model (DLRM)

2.3 Reinforcement Learning and Multi-Armed Bandits

3. The Mathematics of Echo Chambers and Filter Bubbles

4. Hype Driven Development (HDD) Created by Algorithms

5. “Escaping the Algorithm” Strategies in Tech Selection

5.1 Returning to Primary Information: Source Code and RFCs

5.2 Close Reading of Academic Papers and Whitepapers

5.3 Building an In-House Decision-Making Framework

5.4 The Philosophy of the Boring Technology Club

6. Conclusion: How We Should Face Technology

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

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

Unraveling the Dynamics of Communication through Organizational Sociology

The Allen Curve and the Curse of Physical Distance

Conway’s Law and Its Impact on Architecture

Redefining Engineering Productivity: Quantification via DORA and SPACE

The Impact of Remote Work through the Lens of DORA Metrics

The SPACE Framework: A Multifaceted Evaluation of Developer Experience

The Cost and Cognitive Load of Asynchronous Communication

The Context-Switching Trap Brought by Slack and Jira

The Synchronous Value of Whiteboard Sessions

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

Traditional VPN Architecture and the Mathematics of Latency

The Paradigm Shift Brought by Zero Trust (BeyondCorp)

Onboarding Junior Engineers and the Transfer of Tacit Knowledge

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

Conclusion: Towards a Compromise Between Engineers and Management

The '2026 Problem': Is the IT Talent Shortage Really Happening? The Reality on the Ground

Introduction: The Trap of the Term “IT Talent Shortage”

1. Structural Change: The Transition from Traditional SIer to Cloud-Native and AI-Driven Development

2. The “Cliff” of Legacy Systems and the Depletion of Data Engineering

A Mathematical Model of Legacy Maintenance Costs and Modernization

3. The Disruptive Impact of Generative AI: GitHub Copilot and the Disappearance of Junior Engineers

Changes in the Productivity Multiplier Due to Generative AI

4. Beyond Prompt Engineering: What Are the Truly Necessary Skills?

A. Domain-Driven Design (DDD) and Business Modeling

B. Architecture and Non-Functional Requirement Design

C. MLOps and Data Pipeline Construction

5. Survival Strategies for Engineers: Surviving 2026 and Beyond

Strategy 1: Aim to be an “AI Orchestrator”

Strategy 2: Acquire Domain Knowledge

Strategy 3: Soft Skills and Stakeholder Management

Conclusion: Ride the Wave Instead of Fearing It

The Current State and Challenges of IT Education in Japan: After the Mandatory Programming Education

1. Introduction: The Light and Shadow Brought by Mandatory Programming Education

2. The Trap of Visual Programming: The Deep and Steep Chasm from Scratch to Text Coding

The Wall of Abstraction and the Black-Boxing of Computer Science

3. The Limits of Coding Without “Mathematics” and “Discrete Logic”: An Approach from Computational Complexity Theory

The Absolute Dominance of Time Complexity and Space Complexity (Big O Notation)

4. The Black-Boxing of Memory Management and System Architecture

5. The Wall of Databases and Persistence: The Absence of Relational Algebra

6. Security and Cryptography: The Social Infrastructure Supported by the Difficulty of Prime Factorization

7. The GIGA School Concept and the Hopeless Limits of Infrastructure: Chromebooks and Cloud IDEs

Low-Spec Devices and the Loss of Local Development Environments

8. The Despairing Gap with the World: The Disconnect Between Industry Demands and School Education

Fierce Computer Science Education in Other Countries

The Despairing Disconnect Between Required Skills and Taught Skills

9. The Plummeting Value of “Coding” in the AI Era (LLMs)

10. Towards the Integration of Mathematical Sciences and Programming: A Proposal for Next-Generation Education

11. Conclusion: The Steep Path to a True IT Nation and Our Resolve

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

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

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

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

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

Limitations and Running Costs of Cloud APIs

The Wall of Local LLMs and VRAM

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

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

7. Strategies and Social Prescriptions for Surviving the Stratified Society

Individual Strategies: Adapting to the Paradigm Shift

Corporate Strategies: AI-Native Organizational Design

Social Prescriptions: AI Infrastructure as a Public Good

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