Career on kenji.blog

A Solo Developer's Survival Strategy to Fight Tech Giants and the World

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

Introduction: The Battle of the “Have-nots” Challenging the Giants

In the history of software development, there has never been a time more advantageous for solo developers (indie developers) than now. The democratization of cloud infrastructure like AWS and GCP, the rise of BaaS (Backend as a Service) like Vercel and Supabase, and above all, the automation of coding through the evolution of LLMs (Large Language Models). All of these have created an environment where individuals can compete head-on with the “giants,” the major tech companies.

However, just because technical resources have flattened does not mean you can win by adopting the same strategies as major companies. Individuals are overwhelmingly disadvantaged in terms of capital, marketing power, and brand power. For solo developers to survive and win, a unique “survival strategy” is essential.

In this article, we will thoroughly explain the technical and strategic approaches for solo developers to launch a Micro-SaaS and expand their business globally, incorporating architecture design, economics, and mathematical models.

1. Long Tail Theory and the Mathematics of Niche Markets

Major companies target mass markets with a huge TAM (Total Addressable Market). They need millions of users and billions of yen in revenue to recover their high fixed costs (labor, office space, advertising).

In contrast, the strength of solo developers lies in having an “extremely low break-even point.” If you can generate a few hundred thousand yen in profit per month, it is perfectly viable as a business for an individual. This is where the sweet spot of the “Long Tail Theory” exists.

Zipf’s Law and Market Distribution

The relationship between the rank of a market and its size often follows Zipf’s Law or the Pareto principle. If we let the rank of the market be $k$ and its market size (revenue potential) be $P(k)$, it can be expressed by the following power-law model:

$$ P(k) \propto \frac{1}{k^\alpha} $$

Here, $\alpha$ is a parameter that determines the shape of the distribution (generally $\alpha \approx 1$).

Major companies fight bloody red oceans over huge markets (the head) like $k=1, 2, 3$. On the other hand, niche markets (the tail) like $k \ge 100$ are “markets that would only incur a deficit to enter” for major companies, making them essentially blue oceans with no actual competitors.

xychart-beta
title Market Size Distribution and Solo Dev Target
x-axis ["Mass A", "Mass B", "Niche C", "Niche D", "Niche E", "Niche F", "Niche G"]
y-axis "Market Value" 0 --> 100
bar [95, 60, 20, 10, 5, 3, 2]
line [95, 60, 20, 10, 5, 3, 2]

Solo developers should intentionally target specific niche problems (such as workflow automation tools for a particular industry, or hardcore analytics tools combining specific APIs). The more niche it is, the easier it is to reach target users, and the lower the CAC (Customer Acquisition Cost) becomes.

2. Architecture Design for Overwhelming Agility

Enterprise systems are designed with “stability” and “scalability” as top priorities, which is why Kubernetes and microservice architectures are adopted. However, if a solo developer does the same thing, their resources will be depleted just by maintaining the infrastructure (Ops).

The watchword for a solo developer’s tech stack is “No-Ops” (Zero Operations). You must leverage serverless architectures to the absolute limit and focus solely on writing business logic.

Enterprise vs Solo Developer Architecture Comparison

flowchart TD
subgraph "Enterprise Tech Stack"
A["Load Balancer"] --> B["API Gateway"]
B --> C["Microservice 1 (Go)"]
B --> D["Microservice 2 (Java)"]
C --> E["Kubernetes Cluster"]
D --> E
E --> F["Distributed SQL (Spanner)"]
E --> G["Message Queue (Kafka)"]
H["DevOps / SRE Team"] -.-> E
end
subgraph "Solo Developer Tech Stack"
I["Vercel Edge Network"] --> J["Next.js Server Actions"]
J --> K["Supabase (PostgreSQL)"]
J --> L["External APIs (Stripe, OpenAI)"]
M["Solo Dev + AI Copilot"] -.-> I
end

In an enterprise stack, adding new features requires coordination between multiple teams and setting up DevOps deployment pipelines. On the other hand, in an individual’s stack (e.g., Next.js + Supabase + Vercel), a single git push deploys to a global edge network, and there is no need for DB provisioning.

Leveraging Serverless and Edge Computing

By using edge runtimes like Vercel or Cloudflare Workers, you can eliminate cold start delays and provide low-latency APIs to users around the world.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// app/api/hello/route.ts (Next.js Edge API Route)
import { NextResponse } from 'next/server';

export const runtime = 'edge';

export async function GET(request: Request) {
 const { searchParams } = new URL(request.url);
 const name = searchParams.get('name') || 'World';

 // Edge runtime executes in milliseconds globally
 return NextResponse.json({
 message: `Hello, ${name}!`,
 timestamp: Date.now()
 });
}

3. “Extreme Productivity” Utilizing AI APIs

Features such as “Natural Language Processing,” “Image Generation,” and “Recommendation,” which used to require teams of machine learning engineers and data scientists, can now be implemented with a single API call.

By integrating APIs from OpenAI (GPT-4o) or Anthropic (Claude 3.5 Sonnet) into your own Micro-SaaS, even an individual can instantly launch an “AI-native” product.

Streaming Implementation Using Vercel AI SDK

In AI-powered products, the key to user experience (UX) is the “streaming response.” With the Vercel AI SDK, you can achieve this with just a few lines of code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// app/api/chat/route.ts
import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';

// Set the maximum execution time in a serverless environment
export const maxDuration = 30;

export async function POST(req: Request) {
 const { messages } = await req.json();

 const result = await streamText({
 model: openai('gpt-4o-mini'),
 messages,
 system: "You are an excellent SaaS assistant. Please accurately solve the user's problems.",
 });

 return result.toDataStreamResponse();
}

With this kind of implementation, solo developers can provide advanced AI features without worrying about infrastructure complexity. Furthermore, by utilizing AI coding editors like GitHub Copilot and Cursor, the development speed itself has jumped to 5 to 10 times that of traditional methods.

4. The Mathematics of Communication Overhead

Why can solo developers release features faster than major enterprises? The biggest reason is that there is “zero communication overhead.”

According to Brooks’s Law, famously from the software engineering classic “The Mythical Man-Month”, the number of communication channels $C$ within a project increases relative to the number of developers $n$ as follows:

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

When a team of $n=10$ at an enterprise develops a feature, the number of channels reaches $C = 45$, and a massive amount of time is spent on specification adjustments, meetings, and code reviews. However, for a solo developer ($n=1$), the number of channels is $C = 0$.

Because there are no bottlenecks in the process of translating thoughts into code, it is possible to deploy an idea conceived in the morning to the production environment by that evening. This is the greatest weapon of a solo developer, which major enterprises cannot imitate no matter how much money they pile up.

5. Global Expansion and Payment Infrastructure Integration

For a Micro-SaaS competing globally, building a payment gateway is essential. By utilizing Stripe, you can fully automate payments in currencies around the world, subscription management, and even tax processing (Stripe Tax).

Robust Subscription Management Using Stripe Webhooks

Let’s look at a secure payment status synchronization model combining the Next.js App Router and Stripe Webhooks.

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


// app/api/webhooks/stripe/route.ts
import { headers } from 'next/headers';
import { NextResponse } from 'next/server';
import Stripe from 'stripe';
import { db } from '@/db';
import { users } from '@/db/schema';
import { eq } from 'drizzle-orm';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
 apiVersion: '2023-10-16',
});

export async function POST(req: Request) {
 const body = await req.text();
 const signature = headers().get('Stripe-Signature') as string;

 let event: Stripe.Event;

 try {
 event = stripe.webhooks.constructEvent(
 body,
 signature,
 process.env.STRIPE_WEBHOOK_SECRET!
 );
 } catch (error: any) {
 return new NextResponse(`Webhook Error: ${error.message}`, { status: 400 });
 }

 // Processing when a subscription is updated
 if (event.type === 'customer.subscription.updated') {
 const subscription = event.data.object as Stripe.Subscription;
 const customerId = subscription.customer as string;

 // Update the status in the DB
 await db.update(users)
 .set({ subscriptionStatus: subscription.status })
 .where(eq(users.stripeCustomerId, customerId));
 }

 return new NextResponse('OK', { status: 200 });
}

With these few lines of code, you can instantly process credit card payments from users on the other side of the world and automate the provision of your service.

6. Avoiding Infrastructure Lock-in and Ensuring Portability

In a strategy that heavily relies on BaaS and managed services, the risk of “vendor lock-in” is always a subject of debate. For example, if you rely too deeply on Firebase’s Firestore, migrating to an RDB (Relational Database) later becomes extremely difficult.

The optimal solution as a survival strategy is an approach where “you are locked into the infrastructure, but your data and business logic maintain portability.”

Abstracting the Data Layer with ORM

While utilizing managed services like Supabase (PostgreSQL) or PlanetScale (MySQL) for your database, it is standard practice to insert an abstraction layer like Prisma or Drizzle ORM, rather than writing raw SQL or hitting specific BaaS SDKs directly from your application code.

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


// db/schema.ts (Drizzle ORM)
import { pgTable, serial, text, timestamp, varchar } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
 id: serial('id').primaryKey(),
 email: varchar('email', { length: 255 }).notNull().unique(),
 stripeCustomerId: varchar('stripe_customer_id', { length: 255 }),
 subscriptionStatus: varchar('subscription_status', { length: 50 }),
 createdAt: timestamp('created_at').defaultNow(),
});

// app/actions/user.ts
import { db } from '@/db';
import { users } from '@/db/schema';
import { eq } from 'drizzle-orm';

export async function getUserByEmail(email: string) {
 const result = await db.select().from(users).where(eq(users.email, email));
 return result[0];
}

By riding on the standard PostgreSQL ecosystem in this way, even if Supabase’s pricing were to skyrocket, you could migrate to AWS RDS, Render, or your own self-hosted PostgreSQL server with almost no code rewrites.

7. Programmatic SEO and AI-Generated Content

For solo developers without a marketing budget, the ultimate weapon is “SEO” (Search Engine Optimization). In recent years, “Programmatic SEO,” which dynamically generates thousands to tens of thousands of landing pages by combining proprietary databases with LLMs, has been gaining attention.

Traffic distribution also follows a power law. Instead of targeting specific high-volume keywords, you can raise your overall traffic by covering a massive amount of “long-tail keywords” that have low search volume but high conversion rates.

$$ Traffic_{Total} = \int_{x_{min}}^{x_{max}} T(x) dx $$

Even if the traffic $T(x)$ for a niche keyword $x$ is small, integrating them generates massive overall traffic. By using Next.js’s dynamic routing and SSG/ISR, you can deliver these pages rapidly.

8. Unit Economics and the Profit Formula

Finally, let’s look at the mathematical model required to make a Micro-SaaS viable as a business. The basic equation for a SaaS business is as follows:

$$ Profit = \sum_{i=1}^{U} (LTV_i - CAC_i) - Fixed Costs $$

$U$: Number of acquired users
$LTV$ (Life Time Value): $LTV = \frac{ARPU}{Churn Rate}$ (ARPU is Average Revenue Per User, Churn Rate is the cancellation rate)
$CAC$ (Customer Acquisition Cost)
$Fixed Costs$: Fixed costs (server costs, tool costs, etc.)

For solo developers, the advantage is that $Fixed Costs$ are nearly zero. Even combining Vercel’s Pro plan ($20/month), Supabase's Pro plan ($25/month), and other AI API usage fees, it stays around 10,000 to tens of thousands of yen per month. The biggest benefit is being able to exclude your own labor costs from fixed costs (or recovering them from profits).

Zero Marginal Cost Business

For software, especially SaaS, the marginal cost of adding one more user is almost zero. If you can minimize $CAC$ by automating user acquisition (SEO, social media broadcasting, viral loops, etc.), the vast majority of your revenue becomes gross profit outright.

If you build a niche B2B tool for $15/month with a Churn Rate of 5%: $$ LTV = \frac{\$15}{0.05} = $300 $$

If you can keep CAC down to $10 using SEO and content marketing, you generate $290 in profit (gross margin) per user acquired. By delivering this to users around the world with niche problems—say, just 1,000 users—you complete a Micro-SaaS that generates $15,000 (over 2 million yen) in recurring monthly revenue.

Conclusion: Speed and Niche Specialization Are the Ultimate Shield and Spear

The survival strategy for solo developers to fight against tech giants and global rivals boils down to the following three points:

Choose Where to Fight (Long Tail Theory)
- Target niche markets with deep pain points, even if they are small, where large enterprises cannot enter.
Leverage Technological Leverage (Serverless, BaaS, AI)
- Completely externalize operations (Ops) and write only the code (business logic) that solves customer problems, not infrastructure.
Maximize Agility (Zero Communication Cost)
- Capitalize on the solo developer’s greatest weapon, “speed,” by deploying ideas immediately and iterating on market feedback as fast as possible.

We are living in an era with the highest leverage in history. With just a keyboard, the internet, and a passion for solving problems, you can create products that delight users worldwide and compete with giant corporations, all from your own small room.

Now, let’s open the editor and initialize a new project.

1

npx create-next-app@latest my-micro-saas

The battle has already begun.

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 'Human-Specific Engineering Skills' Required in the Era of AI Writing Code

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

The ‘Human-Specific Engineering Skills’ Required in the Era of AI Writing Code

In recent years, the landscape of software engineering has changed dramatically with the rapid evolution of Generative AI and Large Language Models (LLMs). GitHub Copilot and various AI coding assistants are now used on a daily basis, and the phenomenon where “AI instantly generates code if you give instructions in natural language” is no longer science fiction from the future, but today’s reality.

In such an era, it is natural for many engineers to harbor anxiety that “my job might be taken away by AI.” Indeed, “mere coding work (Typing Code)” such as creating boilerplate for routine CRUD applications, implementing simple algorithms, or calling APIs of well-known libraries is rapidly becoming commoditized.

However, the essence of software engineering is not about “typing code.” It is about solving business challenges through technology and building scalable, maintainable systems. In this article, we will explore in profound and technical depth the “human-specific engineering skills” that become even more valuable in the era of AI writing code, looking at it from perspectives such as the technical limitations of LLMs, Domain-Driven Design (DDD), system architecture, and debugging distributed systems.

1. Understanding the Structural Limitations of Large Language Models (LLMs)

To properly evaluate AI’s capabilities and discern the areas where humans should demonstrate value, we must first understand the structural limitations of AI (especially LLMs) from mathematical and architectural standpoints.

1.1 Limits of Computational Complexity and Context in the Transformer Architecture

The majority of current LLMs are based on the “Transformer” architecture introduced by Google in 2017. The core of the Transformer lies in its “Self-Attention Mechanism.” The self-attention mechanism computes how closely each token in an input sequence is related to all other tokens.

This attention calculation formula is expressed as follows:

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Here, $Q$ (Query), $K$ (Key), and $V$ (Value) are linear transformations of the input sequence, and $d_k$ is the dimensionality of the keys. The most critical constraint in this calculation is the computational complexity associated with the matrix multiplication $QK^T$. If the input sequence (number of tokens) is $N$, this computational complexity grows on the order of $O(N^2)$ both in terms of time and space (memory).

$$ \text{Complexity} = O(N^2 \cdot d) $$

In recent years, research on hardware-level optimizations like FlashAttention, Sparse Attention, and even alternative architectures capable of linear time $O(N)$ processing such as Mamba (State Space Models) has been advancing. Still, “perfectly comprehending an infinite context and generating globally optimized outputs” remains extremely difficult.

Furthermore, even if the context window can be physically expanded, a phenomenon called “Lost in the Middle” occurs. LLMs are highly susceptible to information at the beginning and end of a prompt, and tend to ignore important requirements and constraints placed in the middle. This is why, if you load the entire source code of a tens-of-thousands-of-lines enterprise system into an LLM and instruct it to “perform optimal refactoring”, it generates code that is locally correct but globally broken.

1.2 Characteristics of Probabilistic Generative Models and “Hallucinations”

The true nature of an LLM is a “probabilistic generative model” that predicts the token with the highest probability of appearing next, based on the input context (prompt) and the generation results so far.

$$ P(w_t | w_{1:t-1}) = \text{softmax}(W \cdot h_t) $$

The model merely learns “statistical co-occurrence relationships of words” from vast amounts of training data, and does not understand the “Semantics” of the generated code or the “real-world implications of the execution results.” This is what causes “hallucinations.” Bugs such as calling imaginary library functions that do not exist, or passing variables with subtly mismatched types, are simply the result of the LLM generating a “grammatically plausible (high probability) sequence of tokens.”

1.3 Lack of Real-World Grounding

AI lacks the ability to intuitively understand “physical constraints” or “real business constraints” (Grounding). For instance, it cannot consider the business reality that “a 100ms delay in payment processing latency reduces the conversion rate by 5%”, or environment-specific tacit knowledge like “transactions are prone to time out during this time period because batch processing runs on this legacy DB at 2:00 AM”, unless explicitly provided as text.

Given these technical and structural limitations, we can see that while AI is an extremely excellent tool for “rapidly generating code within a clearly defined, narrow scope (functions, classes, modules)”, the act of “designing a whole system from ambiguous requirements and aligning it with real-world constraints” remains a uniquely human domain.

2. Human-Specific Skill 1: Extracting “True Challenges” from Ambiguous Requirements

The greatest hurdle in software development is not writing the code itself. Frederick Brooks, author of the software engineering classic “The Mythical Man-Month”, stated:

“The hardest single part of building a software system is deciding precisely what to build.”

Non-technical stakeholders (management, sales departments, customers) are mostly unable to verbalize what they truly want. Every day, engineers receive extremely ambiguous and contradictory requests such as “I want you to make a system that increases sales using AI” or “I want a screen where everything is automated with just the push of a single button.”

Even if you feed a prompt into an AI saying, “Write code for a system that increases sales”, no usable system will come out. What is required of engineers is the following process:

Deep diving into the domain: Drawing out the “real business challenges” hidden behind the stakeholders’ words through dialogue.
Scoping requirements: Weighing technical feasibility against cost (ROI) and deciding “what not to do.”
Formalizing specifications: Translating ambiguous requirements into clear logical constraints (prompts or architecture blueprints) that AI can understand.

This “high-level human-to-human communication and negotiation” is a highly personalized and valuable skill that AI can never replace.

3. Human-Specific Skill 2: Domain-Driven Design (DDD) and Modeling

After eliciting requirements, the most powerful weapon for translating them into software structure is “Domain-Driven Design” (DDD). As AI increasingly generates local code automatically, the DDD concept of where to draw the “boundaries” of the overall system becomes vitally important.

3.1 Establishing a Ubiquitous Language

In system development, if the “meaning of words” differs between the business side and the development side, AI will generate code in the wrong context. For example, the word “user” might refer to a “lead (prospective customer)” for the marketing department, but to an “already-contracted account” for customer support. Human engineers must establish a unified “Ubiquitous Language” across the entire project, and enforce this language all the way down to class names, method names in code, and prompts to the AI.

3.2 Designing Bounded Contexts

Attempting to represent a massive system with a single model will invariably fail. In DDD, a system is divided into meaningful boundaries (Bounded Contexts). For example, in an e-commerce site, the concept of a “Product” has completely different attributes and behaviors it should possess in the catalog (display) context versus the inventory (management) context.

Only when a human architect draws the correct context boundaries and assigns implementations to AI with independent prompts and specifications for each context, can the AI generate “code based on correct domain knowledge.”

The following diagram illustrates the DDD approach and the division of roles in the AI era.

flowchart TD
A["Business Requirements / Stakeholder Requests"] --> B["Domain-Driven Design (Human's Role)"]
B --> C["Defining Bounded Contexts"]
B --> D["Establishing Ubiquitous Language"]
C --> E["Prompting AI / Code Generation"]
D --> E
E --> F["Code Review / Validating Architecture"]
F --> G["System Deployment and Monitoring"]
style B fill:#f9f,stroke:#333,stroke-width:2px
style C fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#f9f,stroke:#333,stroke-width:2px

Rather than instructing AI to “build the entire system”, humans will delegate implementation to AI strictly within the “context boundaries” they have defined. This will become the fundamental paradigm of software development going forward.

4. Human-Specific Skill 3: Distributed System Architecture Design and Scaling

Modern software is evolving from monoliths running on a single server to cloud-native microservices architectures and event-driven architectures. Designing such distributed systems is a profoundly difficult area for AI, which can only perform localized logic optimization.

4.1 The CAP Theorem and Judging Trade-offs

When designing a distributed system, engineers constantly confront the “CAP Theorem.” The CAP Theorem is the principle that a distributed system can only satisfy two out of the following three properties simultaneously:

Consistency: Does every node see the same data at the same time?
Availability: Does the system continue to respond even if some nodes fail?
Partition Tolerance: Does the system continue to operate even if a network partition occurs?

$$ P(\text{Availability} \cup \text{Consistency}) | \text{PartitionTolerance} $$

Since partitions are unavoidable in real-world networks, engineers must make severe trade-off decisions directly tied to business requirements, such as “This payment system prioritizes Consistency, so we stop the service during a failure (CP)” or “This SNS timeline prioritizes Availability, so we tolerate temporary data inconsistency (AP).”

While AI can write “code that prioritizes C” or “code that prioritizes A”, it cannot autonomously make the decision of “which should be prioritized,” a decision that involves business risks.

4.2 Asynchronous Communication and Eventual Consistency

As systems scale up, inter-service coordination transitions from synchronous communication via REST APIs to asynchronous communication using message queues (such as Kafka or RabbitMQ). Here, data consistency shifts from immediate consistency to “Eventual Consistency.” At what point should advanced architectural patterns like the Saga pattern or CQRS (Command Query Responsibility Segregation) be introduced? Making these complex decisions and drawing the blueprint for the entire system is exactly where the true worth of a senior engineer shines.

flowchart LR
Client["Client"] --> API["API Gateway"]
API --> Order["Order Service (Context)"]
Order -. "Asynchronous Event (Kafka)" .-> Inventory["Inventory Service"]
Order -. "Asynchronous Event (Kafka)" .-> Payment["Payment Service"]
Inventory --> DB1["Inventory DB"]
Payment --> DB2["Payment DB"]
Order --> DB3["Order DB"]

5. Human-Specific Skill 4: Debugging and Troubleshooting Complex Systems

The more AI-generated code there is, the higher the risk that “code nobody fully understands” runs in the production environment. While it may run smoothly in normal times, the true value of human engineers is tested during troubleshooting when an outage occurs.

5.1 Designing Observability

To rapidly resolve system outages, simply pasting error logs into an AI is insufficient. In a microservices environment, a single request traverses dozens of services. Engineers must appropriately build the “three pillars of observability”—Logs, Metrics, and Traces—into the system. It is a human’s role to utilize tools like OpenTelemetry to build a foundation that can pinpoint “which database query in which service is experiencing latency” through distributed tracing.

5.2 Environment-Dependent Bugs and Chaos Engineering

“Bugs that don’t reproduce in local or test environments, but only occur during peak times in the production environment”—for instance, memory leaks, database deadlocks, connection pool exhaustion, or network packet loss—can never be found simply by static analysis of the source code.

Human engineers form hypotheses while glaring at production environment metrics, analyze thread dumps and heap dumps, and identify bottlenecks. AI cannot tap away at a terminal to directly profile a production server process (nor should it be permitted to do so, as a security requirement). As systems become more complex, the value of engineers possessing “low-level knowledge” of physical infrastructure, network protocols, and OS kernel tuning, along with “intuitive hypothesis-driven reasoning skills”, will skyrocket.

6. The Value Function and Time Allocation of Engineers in the AI Era

As discussed thus far, the skill set required of engineers in the AI era is undergoing a massive paradigm shift. If we model this mathematically, the value created by an engineer ($V$) could be expressed as follows:

$$ V = \left( \sum_{i=1}^{n} \text{DomainKnowledge}_i + \text{ArchitectureSkill} + \text{ProblemSolving} \right) \times \text{AI\_Leverage}^{\alpha} $$

Traditional “coding speed” and “syntax memory” have been eliminated from this formula. Instead, it is structured to generate exponential value by multiplying the “sum” of deep domain knowledge, architecture design skills, and complex problem-solving abilities by the leverage of mastering AI ($\text{AI\_Leverage}^{\alpha}$).

This paradigm shift will also be clearly evident in how engineers use their time on a daily basis (time allocation).

pie title Engineer Time Allocation (Pre-AI)
"Coding / Fixing Syntax Errors": 50
"Requirements Definition / System Design": 20
"Implementing and Running Tests": 20
"Production Ops / Debugging": 10

pie title Engineer Time Allocation (AI Era)
"Domain Modeling and Architecture Design": 40
"Prompting AI and Code Validation": 20
"Advanced Production Debugging and Ops": 30
"Self-Coding (Core Areas)": 10

In the AI era, engineers will be elevated from “code typists” to “conductors orchestrating the entire system.” Precisely because AI will write massive amounts of code, the role of “reviewer” and “architect”—who monitors and governs whether the code is pointing in the right direction, satisfies security requirements, and aligns with the overall system architecture—will be demanded of all engineers, from junior to senior levels.

7. Conclusion: Don’t Resist Evolution, Ride the Wave

The “era of AI writing code” is not a threat to engineers, but the greatest opportunity in history. Just as the transition from assembly language to C occurred in the past, and just as the evolution from manual memory pointer management to Java’s garbage collection took place, code generation by AI is simply “moving up one level of abstraction.”

Engineers of the future will not be swayed by the trivial specifications of a particular programming language or framework upgrades, but will be able to concentrate their resources on more essential, higher-order human problem solving, such as: “What is the business challenge?”, “How should data be partitioned and integrated?”, and “How do we rapidly recover when the system goes down?”

A true engineer is not someone who writes code, but someone who solves problems. Domain modeling, scalable architecture design, communication with stakeholders, and debugging complex systems. For those who continue to polish these “human-specific engineering skills,” AI will not be an enemy that takes away jobs, but the ultimate partner that expands their own creativity and productivity tens of times over.

What Engineers Should Do to Grow Monthly Traffic on a Tech Blog

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

Introduction: Tech Blog Growth Hacking Only Engineers Can Do

Many software engineers start tech blogs, but few manage to gather a consistent number of views and maintain or expand them over a long period. Writing high-quality technical articles is a prerequisite, but the era of “write a good article and it will naturally be read” is long gone. Today’s search engine algorithms have become complex, and the flow of information on SNS is faster than ever.

However, engineers have an advantage that other professions do not. That is the ability to “understand system architecture, combine tools for automation, and analyze data programmatically.” In this article, going beyond simple writing techniques, we will treat a tech blog as a single “product” and explain in extreme and practical detail the strategies to dramatically increase monthly traffic using the power of engineering.

1. SEO Architecture for Engineer Tech Blogs

The foundational system of a blog (such as a static site generator) and the structure of its HTML are the most critical factors for search engines to interpret content correctly.

1.1 Core Web Vitals Optimization

Google has adopted page experience as a ranking factor, and Core Web Vitals (LCP, FID/INP, CLS) cannot be ignored, even for tech blogs. Tech blogs heavily use large amounts of source code blocks, mathematical formulas (MathJax / KaTeX), and explanatory diagrams. These are factors that delay page rendering.

LCP (Largest Contentful Paint): The loading speed of the main content above the fold. Use WebP or AVIF for the eye-catch image and add the fetchpriority="high" attribute to preload it. Also, huge CSS and JS files for syntax highlighting should be loaded asynchronously or designed to load only on pages where they are needed.
CLS (Cumulative Layout Shift): Layout shifts during page loading. By securing the display area for formulas and images in advance using CSS properties like aspect-ratio, you can prevent layout jank when the DOM is inserted later.
INP (Interaction to Next Paint): Responsiveness to user interactions. Heavy JavaScript (such as dynamic full-text search on the client side or executing a massive Markdown parser) must not be executed on the main thread; it is essential to offload it to a Web Worker or generate it as static HTML (SSG) during the build process.

1.2 Implementation of Structured Data (JSON-LD)

To explicitly tell search engines that the page is an “article” and “who” the author is, implement structured data in JSON-LD format. By utilizing schemas such as TechArticle or SoftwareSourceCode, your content is more likely to appear in Google’s Rich Results, improving the CTR (Click-Through Rate).

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


<script type="application/ld+json">
{
 "@context": "https://schema.org",
 "@type": "TechArticle",
 "headline": "What Engineers Should Do to Grow Monthly Traffic on a Tech Blog",
 "image": [
 "https://example.com/img/eyecatch.jpg"
 ],
 "datePublished": "2026-09-14T10:00:00+09:00",
 "author": {
 "@type": "Person",
 "name": "Kenji",
 "url": "https://example.com/about/"
 },
 "publisher": {
 "@type": "Organization",
 "name": "Kenji's Tech Blog",
 "logo": {
 "@type": "ImageObject",
 "url": "https://example.com/img/logo.png"
 }
 }
}
</script>

1.3 Semantic HTML and Document Structure Optimization

Proper nesting of headings (h1 to h6) is fundamental, but tech blogs require accurate use of HTML5 semantic tags like article, section, aside, and nav. Also, appropriately distinguishing <code> and <pre> for source code, <kbd> for keyboard inputs, and <var> for variables provides machine-readable HTML. This is also a highly effective measure for AI content indexing (LLM training data collection and RAG systems).

2. The Psychology of Search Intent and Keyword Strategy

To maximize incoming traffic from search engines (organic traffic), you need to accurately decipher the search intent—“why did the user search for that keyword?” Search intent in the tech field can be broadly classified into two types.

2.1 “Troubleshooting Type” vs. “Systematic Learning & Review Type”

Troubleshooting Intent
- Example search keywords: Docker "no space left on device" solution, Python IndexError list index out of range cause
- Psychology: Blocked by an error during development, looking for a quick fix command or code snippet right now.
- Strategy: Present the “conclusion (code or command to solve the issue)” at the very beginning of the article (above the fold). Place the background and detailed mechanism explanations after that, first satisfying the user’s desire to “fix it immediately.” This helps reduce the bounce rate.
Systematic Learning & Review Intent
- Example search keywords: React vs Vue 2026 comparison, Rust asynchronous processing tutorial, GCP network architecture design
- Psychology: Wants to select a new tech stack or deepen their understanding from the basics, and is ready to take time to read.
- Strategy: Enrich the Table of Contents (TOC) and heavily use diagrams and architecture charts (Mermaid, etc.). Objectively compare pros and cons and include use cases of how it can be applied in actual work, which can increase time spent on the page.

2.2 Exponential Decay Model of Traffic and Long-Tail Strategy

Traffic for technical articles tends to form a spike (surge) right after publication due to buzz on SNS, etc., and then decreases exponentially. This traffic $V(t)$ can be approximated by the following mathematical model:

$$ V(t) = V_0 e^{-\lambda t} + C $$

Where:

$V(t)$: Traffic volume at time $t$
$V_0$: Initial traffic spike volume due to SNS buzz immediately after publication
$\lambda$: Decay constant associated with content obsolescence and forgetting on SNS (depends on the speed of technological trend changes)
$C$: Stable organic search inflow from search engines (baseline traffic)

The key to growing traffic over the long term is not to aim for a temporary buzz ($V_0$), but how to make the constant term $C$ (sustained inflow from search engines) as large as possible. By covering a massive amount of “long-tail keywords”—such as specific niche errors or integration methods between specific tools—that have low search volume but no competition, you can grow the total sum of $C$ into something enormous.

3. Data-Driven Content Analysis Using Google Search Console API

To build a stable traffic foundation $C$, it is necessary to utilize Google Search Console (GSC) data to objectively analyze “how Google evaluates your site.” However, clicking around the GSC Web UI has its limits. If you are an engineer, automate the analysis using the GSC API and Python.

3.1 Automation Approach with GSC API and Python

Create a script that automatically detects “wasteful articles” where the search ranking drops over time (Decaying Content), or where impressions are high but the Click-Through Rate (CTR) is abnormally low. This uses google-api-python-client and pandas.

3.2 Python Implementation Code: Auto-Extracting Content with Decreased CTR

Below is an example of a script that fetches search performance data for the past 30 days from the API and extracts a “recommended list of keywords and article URLs with great room for improvement in title or description” where impressions are 1000 or more and CTR is 2% or less.

 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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


import pandas as pd
from google.oauth2 import service_account
from googleapiclient.discovery import build
import datetime

# 1. Authentication and API service construction
KEY_FILE_LOCATION = 'path/to/your-service-account-key.json'
SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SITE_URL = 'https://your-tech-blog.com/'

credentials = service_account.Credentials.from_service_account_file(
 KEY_FILE_LOCATION, scopes=SCOPES)
webmasters_service = build('searchconsole', 'v1', credentials=credentials)

# 2. Calculation of request period (past 30 days)
today = datetime.date.today()
end_date = (today - datetime.timedelta(days=2)).strftime('%Y-%m-%d')
start_date = (today - datetime.timedelta(days=32)).strftime('%Y-%m-%d')

# 3. Execution of API request
request = {
 'startDate': start_date,
 'endDate': end_date,
 'dimensions': ['query', 'page'],
 'rowLimit': 5000
}

response = webmasters_service.searchanalytics().query(
 siteUrl=SITE_URL, body=request).execute()

# 4. Data processing and filtering using Pandas DataFrame
if 'rows' in response:
 rows = response['rows']
 data = []
 for row in rows:
 data.append({
 'Query': row['keys'][0],
 'URL': row['keys'][1],
 'Clicks': row['clicks'],
 'Impressions': row['impressions'],
 'CTR': row['ctr'],
 'Position': row['position']
 })

 df = pd.DataFrame(data)

 # Filtering condition: Impressions >= 1000 & CTR < 2%
 target_df = df[(df['Impressions'] >= 1000) & (df['CTR'] < 0.02)]

 # Sort in ascending order by position (prioritize high ranking but unclicked)
 target_df = target_df.sort_values(by='Position', ascending=True)

 print("[Recommended List for Title/Meta Description Improvement]")
 print(target_df.head(10))

 # Export to CSV if necessary, etc.
 # target_df.to_csv('improve_candidates.csv', index=False)
else:
 print("No data found.")

By running this script as a cron job or a GitHub Actions scheduled job, you can continuously make data-driven decisions on “which article titles to rewrite.” It’s important to rely on data rather than intuition for continuous improvement (Continuous Content Improvement).

4. Article Lifecycle Management and Rewrite Strategy

Publishing a technical article is not the end. As technology evolves (framework version updates, API deprecations, etc.), content quickly becomes obsolete. Continuing to provide outdated information not only damages the blog’s credibility but also negatively affects SEO.

4.1 Content Lifecycle Management (Gantt Chart)

The ideal content operation lifecycle is shown in a Mermaid Gantt chart.

gantt
title Data-Driven Content Lifecycle Management
dateFormat YYYY-MM-DD
axisFormat %m/%d
section "Phase 1: Planning & Writing"
"Search Keyword & Trend Analysis" :a1, 2026-09-01, 3d
"Draft & Code Verification" :a2, after a1, 5d
"Revision & Proofreading" :a3, after a2, 2d
section "Phase 2: Publishing & Promo"
"Deployment via CI/CD Pipeline" :p1, 2026-09-11, 1d
"Automated SNS Delivery (X, LinkedIn, RSS)" :p2, 2026-09-11, 1d
"Ripple Effect to Bookmarks, etc." :p3, after p2, 3d
section "Phase 3: Observation & Analysis"
"GSC Data Accumulation Period" :m1, 2026-09-14, 28d
"Performance Eval via Python API":m2, after m1, 2d
section "Phase 4: Improvement (Rewrite)"
"Title Fix for Low CTR Articles" :r1, after m2, 3d
"Code Update to Latest Version":r2, after r1, 4d

Treating article creation like a software development project and incorporating the post-release operation/maintenance (rewrite) phase into your plan is the secret to maintaining and improving traffic.

4.2 Mathematical Model of Content Creation ROI (Return on Investment)

Since engineers spend valuable time writing articles, they should be aware of the Return on Investment (ROI). The ROI for a blog can be formulated as follows:

$$ ROI = \frac{\sum_{t=1}^{T} \left( Rev_{ad}(t) + Val_{brand}(t) + Val_{skill}(t) \right) - Cost_{time}}{\text{Cost}_{time}} \times 100 \ (\%) $$

$T$: Effective lifespan of the article (time until it becomes obsolete)
$Rev_{ad}(t)$: Direct revenue from ad earnings, affiliate revenue, and sponsorships
$Val_{brand}(t)$: Monetary equivalent of the positive impact on career due to demonstrating technical skills (e.g., increased offer amount when changing jobs, speaking requests)
$Val_{skill}(t)$: Value of personal skill improvement through learning and research done to write the article
$Cost_{time}$: Time spent writing the article, creating diagrams, and verifying code (converted to personal hourly rate)

The great thing about tech blogs is that even if $Rev_{ad}$ is small, $Val_{brand}$ and $Val_{skill}$ tend to be extremely large. In particular, high-quality technical explanations serve directly as a portfolio, wielding immense power in job hunting or securing side jobs.

5. Distribution via GitHub Actions and External Automation Tool Integration

After creating content, the challenge becomes how to efficiently deliver it to the target audience (distribution). Manually posting links to each SNS every time is inefficient and un-engineer-like.

We will build an architecture that fully automates everything from building, deploying, and notifying multiple platforms the moment a Markdown file is merged into the main branch of a GitHub repository.

flowchart TD
A["Developer (Git Push)"] --> B["GitHub Repository"]
B -->|Webhook| C["GitHub Actions (CI/CD)"]
C -->|Build| D["Static Site Generator (Hugo/Gatsby)"]
D -->|Deploy| E["Hosting (Vercel / Cloudflare Pages)"]
D -->|Generate| F["RSS Feed (index.xml)"]
F -->|Polled by| G["Zapier / IFTTT / Make"]
G -->|API Call| H["X (Twitter) Auto Post"]
G -->|API Call| I["LinkedIn Article Post"]
G -->|API Call| J["Discord / Slack Community Webhook"]
C -->|Actions Script| K["Qiita / Zenn Cross-Post API"]

5.2 Key Points for Building an Automation Pipeline

Build and Deploy with GitHub Actions If using a static site generator, automate the HTML generation and deployment to the hosting provider (Vercel, Netlify, Cloudflare Pages, etc.) using GitHub Actions. At this time, it is also effective to incorporate an image optimization process (such as auto-conversion to WebP) into the build pipeline as a Core Web Vitals countermeasure mentioned earlier.
SNS Integration with RSS Triggers Using Zapier/IFTTT The site generator creates the latest RSS feed (XML) during the build. Feed this into an iPaaS like Zapier or Make (formerly Integromat) to build a workflow such as “When a new item is added to RSS, post the title and URL to X (Twitter) and LinkedIn.” With this, notifications to followers are automatically sent the moment an article is published.
Cross-Posting to Qiita/Zenn (Using Canonical Tags) While the domain authority of your company or personal blog is still weak, borrowing the visitor attraction power of technical platforms like Qiita or Zenn is one strategy. However, simple copy-pasting carries the risk of SEO penalties for duplicate content. This issue can be resolved by setting a Canonical tag in the metadata of the Qiita or Zenn article, pointing to the original article URL on your own blog. By writing a script that hits various platform APIs from GitHub Actions to automatically generate articles from Markdown, you can fully automate multi-channel delivery.

Conclusion: Turning the Cycle of Continuous Improvement

To dramatically increase monthly traffic on a tech blog, the engineering approaches introduced this time are indispensable in addition to the act of “writing.”

Building a robust HTML and site architecture with SEO in mind
Article design that understands the user’s search intent (troubleshooting vs. systematic learning)
Data analysis utilizing the Google Search Console API and Python
Content lifecycle management and rewriting with ROI in mind
Complete automation of distribution through CI/CD and Zapier integration

If you can assemble these as a system, your tech blog will become the strongest asset to powerfully boost your own career. Engineers struggling with stagnant traffic should definitely start “blog growth hacking” today. The programming skills and architecture design abilities cultivated in development work will undoubtedly be your greatest weapons in blog management as well.