Industry on kenji.blog

【Проблема 2026 года】Действительно ли существует нехватка ИТ-кадров? Реалии на местах

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

Введение: Ловушка фразы «Нехватка ИТ-кадров»

В японской ИТ-индустрии уже давно циркулируют в СМИ сенсационные фразы вроде «Обрыв 2025 года» и «Нехватка до 790 000 ИТ-специалистов к 2030 году», но то, с чем мы сталкиваемся сейчас, — это кризис совершенно новой фазы, который следует назвать «Проблемой 2026 года».

В отчетах Министерства экономики, торговли и промышленности и различных сообщениях СМИ всех обобщают под утверждением «ИТ-инженеров катастрофически не хватает». Однако, если прислушаться к реальным голосам с мест, ситуация оказывается немного сложнее. На самом деле «не хватает не всех». Происходит сильная «поляризация»: катастрофически не хватает старших инженеров (senior) с продвинутыми навыками, которых компании отчаянно хотят заполучить, в то время как неопытные или малоопытные младшие инженеры (junior) сталкиваются с переизбытком предложения, и им становится все труднее найти работу.

В этой статье мы глубоко разберем и объясним, что на самом деле происходит сейчас в ИТ-индустрии, сдвиг парадигмы от традиционной модели системных интеграторов (SIer) к облачной (cloud-native) и управляемой ИИ разработке, обрыв унаследованных систем, а также разрушительное влияние генеративного ИИ, ярким представителем которого является GitHub Copilot.

1. Структурные изменения: Переход от традиционных SIer к облачной и управляемой ИИ разработке

Долгие годы японскую ИТ-индустрию поддерживала модель системных интеграторов (SIer) с многоуровневой структурой субподряда. Это так называемая «трудоемкая» бизнес-модель, где код пишется строго по спецификациям, а тестовая документация заполняется. Здесь ценность инженера измерялась в «человеко-месяцах», и предполагалось, что если собрать нужное количество людей, проект будет идти своим чередом.

Однако к 2026 году эта модель достигла своих пределов. Суть DX (цифровой трансформации) сместилась от «простой информатизации» к «трансформации бизнес-моделей», и каскадная (waterfall) разработка с ее низкой гибкостью (agility) больше не может поспевать за изменениями рынка.

Современный процесс разработки предполагает, что он является облачным (cloud-native) и управляемым ИИ. Контейнеризация (Docker/Kubernetes), микросервисная архитектура и автоматизация CI/CD конвейеров больше не являются «особенными технологиями», а стали «стандартной инфраструктурой».

graph TD
A["Традиционная модель разработки SIer"] -->|Сдвиг парадигмы| B["Переходный период (Внедрение Agile, Lift & Shift)"]
B --> C["Облачная разработка (Микросервисы/Контейнеры)"]
C --> D["Архитектура, управляемая ИИ и данными (MLOps)"]
D --> E["Интегрированная платформа генеративного ИИ (Автономные ИИ-агенты)"]
style A fill:#f9d0c4,stroke:#333,stroke-width:2px
style E fill:#d4edda,stroke:#333,stroke-width:4px

Компании больше не ищут «кодеров», которые просто пишут код по заданной спецификации. Им нужны специалисты, способные проектировать облачную инфраструктуру, реализовывать бэкенд и даже внедрять модели машинного обучения в промышленную эксплуатацию (MLOps), превращая бизнес-требования в техническую архитектуру. В областях, требующих столь обширных знаний и опыта, людям, которые «просто знают синтаксис языка программирования», становится все труднее создавать ценность.

2. «Обрыв» унаследованных систем и истощение данных-инженерии

Как и предупреждали в связи с «Обрывом 2025 года», многие японские компании все еще полагаются на мейнфреймы и локальные (on-premise) унаследованные системы (созданные на COBOL и т. д.). Из-за многолетних модификаций эти системы превратились в «черные ящики», а в связи с выходом на пенсию старшего поколения специалистов, отвечавших за их обслуживание, поддерживать их становится крайне сложно.

С другой стороны, со стороны бизнеса поступают сильные запросы: «Мы хотим использовать данные для создания ИИ-моделей и предоставления персонализированного клиентского опыта». Здесь возникает критический разрыв. Катастрофически не хватает «инженеров данных» (data engineers), которые могли бы очистить, интегрировать и преобразовать разрозненные локальные данные в конвейеры, пригодные для использования в современных конвейерах ИИ/МО (AI/ML).

Математическая модель затрат на поддержку унаследованных систем и модернизации

Давайте рассмотрим простую математическую модель, сравнивающую затраты на поддержание унаследованной системы ($C_{legacy}$) с инвестициями в модернизацию (обновление) и последующими эксплуатационными расходами ($C_{modern}$).

Затраты на поддержку унаследованной системы растут с каждым годом. Это связано с устранением сбоев из-за технического долга и ростом затрат на персонал из-за нехватки специалистов по старым технологиям. Если $t$ — количество лет, это можно выразить следующим образом:

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

Где:

$M_0$: Первоначальные затраты на обслуживание
$r$: Темп роста затрат на обслуживание из-за технического долга
$L_0$: Первоначальные затраты на персонал для работы с унаследованными системами
$i$: Уровень инфляции затрат на персонал из-за нехватки специалистов по старым технологиям

С другой стороны, модернизация требует значительных первоначальных инвестиций $I$, но благодаря облачным технологиям и автоматизации эксплуатационные расходы $O_m$ остаются низкими и легко поддерживаются на стабильном уровне.

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

Во многих случаях очевидно, что в течение нескольких лет (точка безубыточности) $C_{legacy}(t) > C_{modern}(t)$, однако на рынке просто нет достаточного числа «архитекторов» и «инженеров данных», способных реализовать первоначальные инвестиции $I$. Из-за этого многие компании в 2026 году тонут в болоте $C_{legacy}$.

pie title Структура самых дефицитных ИТ-навыков по состоянию на 2026 год
"Специалисты по AI/ML Ops" : 35
"Облачные архитекторы" : 25
"Инженеры данных" : 20
"Миграция унаследованных систем (COBOL и т.д.)" : 15
"Другое" : 5

3. Разрушительное влияние генеративного ИИ: GitHub Copilot и исчезновение младших инженеров

Говоря о нехватке ИТ-кадров, нельзя не упомянуть появление генеративного ИИ (Generative AI). Такие инструменты, как GitHub Copilot, Cursor и ChatGPT (серии GPT-4o и O1), коренным образом изменили производительность разработки программного обеспечения.

В прошлом типичная структура команды предполагала, что старшие инженеры тратили время на сложное проектирование и проверку кода (ревью), в то время как простые операции CRUD (создание, чтение, обновление, удаление), написание шаблонного кода (boilerplate) и тестов поручались (делегировались) младшим инженерам.

Однако сегодня генеративный ИИ может генерировать 90% этих «задач младших специалистов» за считанные секунды или минуты с высокой точностью. Что произошло в результате? Компании потеряли смысл нанимать младших инженеров.

Изменение мультипликатора производительности за счет генеративного ИИ

Давайте выразим общую производительность команды разработчиков до и после внедрения ИИ с помощью математических формул.

Пусть базовая производительность равна $P$. Пусть прирост производительности старшего инженера благодаря внедрению генеративного ИИ равен $\alpha_{senior}$, а прирост производительности младшего инженера — $\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}) $$

На первый взгляд кажется, что производительность младших инженеров также возрастает. Однако в реальности критически важна способность «проверять правильность сгенерированного ИИ кода, интегрировать его в общую систему и оценивать отсутствие угроз безопасности». Этой способности (понимание контекста и навыки проектирования архитектуры) младшим специалистам не хватает.

В результате старшие инженеры используют ИИ как «суперталантливого ассистента (младшего разработчика, работающего бесконечно)» и повышают свою производительность в 2-3 раза ($\alpha_{senior} \approx 2.0$). Напротив, когда младшие инженеры без базовых знаний используют ИИ, они генерируют «спагетти-код», который вроде бы работает, но содержит огромное количество технического долга, что приводит к увеличению затрат на ревью (бывают даже случаи, когда фактически $\alpha_{junior} < 0$).

В итоге компании осознали, что нанять одного старшего инженера (умеющего работать с ИИ) с зарплатой в 1,2 миллиона иен в месяц — это гораздо менее рискованно и более эффективно, чем нанимать трех младших специалистов с зарплатой по 300 тысяч иен. В этом и заключается истинная суть «нехватки кадров». «Старших специалистов, способных эффективно использовать ИИ», совершенно не хватает.

xychart-beta
title Поляризация спроса на вакансии для младших и старших специалистов (2021-2026)
x-axis ["2021", "2022", "2023", "2024", "2025", "2026"]
y-axis "Коэффициент вакансий" 0.0 --> 10.0
line ["Старшие (Архитекторы/MLOps и др.)"] [3.0, 3.5, 4.2, 5.8, 7.5, 9.2]
line ["Младшие (Без опыта/Опыт 1-2 года)"] [2.5, 2.2, 1.8, 1.2, 0.8, 0.3]

4. За пределами промпт-инжиниринга: Какие навыки действительно нужны?

Так каким же должен быть ИТ-специалист в грядущую эпоху? Слишком поспешно думать, что «достаточно просто овладеть промпт-инжинирингом (prompt engineering)». Искусство давать инструкции на естественном языке становится все проще по мере развития ИИ-моделей и превращается в обыденность (коммодитизацию).

В реальных условиях сейчас действительно требуются специалисты, способные охватить следующие три области:

A. Предметно-ориентированное проектирование (DDD) и бизнес-моделирование

ИИ может писать код, но он не может «распутать сложные бизнес-спецификации, найти ограниченные контексты (Bounded Contexts) программного обеспечения и спроектировать подходящую модель данных». Навык «предметно-ориентированного проектирования» (Domain-Driven Design, DDD), который позволяет глубоко понять предметную область клиента и перевести ее на технический язык, является одним из самых ценных навыков в эпоху ИИ.

B. Проектирование архитектуры и нефункциональных требований

Такие «нефункциональные требования», как доступность системы, масштабируемость, безопасность и производительность, не оптимизируются ИИ автоматически. Архитектурные решения вроде «какие облачные сервисы комбинировать», «какой протокол связи между микросервисами использовать» или «где проводить границы транзакций БД», по-прежнему зависят от глубокого человеческого опыта и интуиции.

C. MLOps и построение конвейеров данных

Концепция «MLOps» для непрерывной эксплуатации генеративного ИИ и моделей машинного обучения в производственной среде становится все более важной. Специалисты с такими навыками, находящимися на стыке программной инженерии и науки о данных — мониторинг дрейфа моделей (снижения точности), создание конвейеров для непрерывного обучения, оптимизация ресурсов GPU — сейчас на вес золота.

5. Стратегии выживания для инженеров: Как преуспеть после 2026 года

В таких условиях как нам, инженерам, строить свою карьеру? Особенно для молодых инженеров ситуация может показаться безнадежной. Однако при правильной стратегии есть масса возможностей для прорыва.

Стратегия 1: Стремиться стать «ИИ-оркестратором»

Вместо того чтобы становиться экспертом в одном языке или фреймворке, вам следует развивать свои способности как «оркестратора», который строит всю систему, комбинируя различные ИИ-инструменты и агенты. Необходимо сократить время, затрачиваемое на самостоятельное написание кода, связывать компоненты, написанные ИИ, и иметь «вид сверху», позволяющий окинуть взглядом всю архитектуру.

Стратегия 2: Приобретение знаний о предметной области

Помимо технических навыков, обзаведитесь глубокими знаниями в конкретной отрасли (финансы, медицина, логистика и т.д.). Инженер, который досконально знает болевые точки рабочих процессов, обладает мощной силой убеждения при предложении технических решений, которую ИИ не может сымитировать. Оставьте «КАК (как создавать)» Искусственному Интеллекту, и сосредоточьтесь на том, «ЧТО (что создавать)» и «ПОЧЕМУ (зачем создавать)».

Стратегия 3: Soft skills и управление заинтересованными сторонами

При масштабной разработке систем успех проекта в конечном итоге зависит от «построения человеческих отношений» и «управления ожиданиями». «Человеческие навыки», такие как определение требований с клиентами, фасилитация внутри команды и достижение консенсуса в сложных решениях — это области, которые ИИ сложнее всего заменить. В будущем будут еще больше цениться специалисты, обладающие превосходными коммуникативными навыками, опирающимися на прочную техническую базу.

graph LR
A["Просто кодер"] -->|Замещение ИИ| B["Снижение спроса"]
A -->|Стратегический сдвиг| C["Системный архитектор"]
A -->|Стратегический сдвиг| D["Доменный эксперт"]
A -->|Стратегический сдвиг| E["ИИ-интегратор"]
C --> F["Высокий спрос и зарплаты (Победители после 2026 года)"]
D --> F
E --> F
style B fill:#f9c2c2,stroke:#333
style F fill:#c8f9c2,stroke:#333,stroke-width:2px

Заключение: Не бойтесь, а ловите волну

Как вы могли убедиться, реальность «Проблемы 2026 года» и сопутствующей ей нехватки ИТ-кадров заключается не в простом «дефиците людей», а в «несоответствии из-за резкого изменения требуемых навыков».

Тяжесть унаследованных систем, истощение инженеров данных и сдвиг парадигмы, вызванный генеративным ИИ. Эти волны представляют собой угрозу для традиционных инженеров, но для тех, кто может принять изменения и обновить свой набор навыков, это еще и огромная, беспрецедентная возможность.

ИИ не отнимает у нас работу, это всего лишь инструмент, позволяющий нам сосредоточиться на более сложной и творческой деятельности. Освободиться от «рутины» кодирования и сфокусироваться на «проектировании» систем и «создании ценности» для бизнеса. Это единственный путь к выживанию и процветанию в ИТ-индустрии после 2026 года.

Сейчас самое время пересмотреть свой карьерный путь и взять курс на следующую парадигму. Готовы ли вы «модернизировать» самих себя?

Влияние алгоритмов социальных сетей на наше мышление и выбор технологий

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

1. Введение: Демократизация технической информации и господство алгоритмов

В современной программной инженерии большая часть технической информации, которую мы потребляем ежедневно, проходит через социальные сети (SNS), такие как X (бывший Twitter), Hacker News, Reddit и LinkedIn, а также новостные агрегаторы. Когда-то мы собирали информацию автономно и в хронологическом порядке через списки рассылки, блоги, управляемые конкретными экспертами, или RSS-ридеры. Однако со взрывным ростом числа новых фреймворков и инструментов, появляющихся каждый день, стало обычной практикой полагаться на «алгоритмы рекомендаций (Recommendation Algorithms)», предоставляемые платформами, чтобы оптимизировать наши ограниченные когнитивные ресурсы (свободное время и внимание).

Этот сдвиг парадигмы принес огромные преимущества, позволив нам эффективно находить полезные технические статьи и новаторские проекты с открытым исходным кодом. Однако это также вызвало очень серьезный побочный эффект. Факт заключается в том, что «технологические тренды и передовые методы, которые мы видим, искажаются не объективной оценкой или чисто техническим превосходством, а алгоритмической «функцией оптимизации вовлеченности»».

В этой статье мы с математической и структурной точек зрения разберем, как продвинутые алгоритмы машинного обучения, работающие за кулисами социальных сетей, формируют наше восприятие и влияют на процесс принятия решений при выборе технологий. Кроме того, мы глубоко рассмотрим опасности «Hype Driven Development (HDD: разработки, управляемой хайпом)», когда люди поддаются энтузиазму, порожденному алгоритмами, и конкретные подходы к отходу от этого в сторону объективного и надежного выбора технологий.

2. Эволюция и механизмы алгоритмов рекомендаций

Когда мы открываем социальную сеть, контент, отображаемый на нашей временной шкале (в ленте), не случаен. За этим стоят модели машинного обучения, тщательно настроенные для максимизации времени пребывания пользователя и увеличения доходов от рекламы. Давайте сначала посмотрим на технологии, лежащие в их основе.

2.1 Коллаборативная фильтрация (Collaborative Filtering) и матричное разложение

«Коллаборативная фильтрация» служила мощным базовым подходом с первых дней существования рекомендательных систем до настоящего времени. В частности, широко используется «матричное разложение (Matrix Factorization)», которое представляет взаимодействие между пользователями и элементами (постами или статьями) в виде матрицы и отображает их в скрытом пространстве признаков.

Если мы обозначим матрицу оценок для $M$ пользователей и $N$ элементов как $R \in \mathbb{R}^{M \times N}$, матричное разложение аппроксимирует эту огромную и разреженную (sparse) матрицу произведением матриц скрытых признаков низкой размерности $U \in \mathbb{R}^{M \times K}$ (признаки пользователей) и $V \in \mathbb{R}^{N \times K}$ (признаки элементов) ($K \ll M, N$).

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

Прогнозируемая оценка (вероятность вовлеченности) $\hat{r}_{ij}$ элемента $j$ для конкретного пользователя $i$ вычисляется как скалярное произведение их соответствующих векторов скрытых признаков.

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

Эта модель обучается так, чтобы минимизировать следующую функцию потерь ($\lambda$ — член регуляризации для предотвращения переобучения).

$$ \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) $$

Влияние на выбор технологий: Этот алгоритм сближает в скрытом пространстве «Человека А, интересующегося Rust» и «Человека Б, интересующегося Rust». Если А поставит лайк посту о новом веб-фреймворке, существует высокая вероятность того, что этот пост появится и в ленте Б. В результате возникает феномен, когда определенные технологии локально становятся очень популярными среди групп инженеров, предпочитающих конкретные технологические стеки.

2.2 Рекомендательные модели на основе глубокого обучения (DLRM)

В последние годы получили распространение архитектуры на основе глубокого обучения, такие как Deep Learning Recommendation Model (DLRM), в первую очередь популяризированные Meta (бывший Facebook). DLRM принимает на вход широкий спектр признаков (Features), таких как история прошлых действий пользователя и метаданные элементов, и прогнозирует рейтинг кликов (CTR: Click-Through Rate) и другие показатели.

Особенностью DLRM является то, что он преобразует разреженные категориальные признаки (например, идентификаторы пользователей, хештеги, на которые они подписаны) в плотные векторы (Dense Vector) через «таблицы встраивания (Embedding Table)» и комбинирует их с непрерывными плотными признаками (например, количество дней с момента создания учетной записи, среднее время пребывания в прошлом).

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

После того как они объединяются (Concatenate) или взаимодействуют (Feature Interaction) посредством скалярного произведения, они подаются в верхний многослойный перцептрон (Top MLP), и окончательная вероятность (например, CTR) выводится с помощью сигмоидной функции $\sigma$.

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

Влияние на выбор технологий: Огромные модели вроде DLRM способны улавливать даже самые незначительные сигналы (например, небольшое увеличение времени пребывания на «посте с видео» или «посте, содержащем определенное модное слово») и отражать их в прогнозируемом балле. В результате техническая информация, содержащая «провокационные заголовки (например, “React уже устарел”, “Конец микросервисов”)» или «визуально яркие демонстрации», с большей вероятностью будет алгоритмически предпочтительной.

2.3 Обучение с подкреплением и задача о многоруком бандите (Multi-Armed Bandits)

Рекомендательные системы всегда должны исследовать последние предпочтения пользователей. Здесь вступает в игру «задача о многоруком бандите». Она оптимизирует компромисс между «использованием (Exploitation)», то есть показом надежного контента на основе существующих предпочтений, и «исследованием (Exploration)» для обнаружения новых тенденций.

В типичном алгоритме UCB (Upper Confidence Bound) оценка для выбора ручки (группы контента) $a$ в момент времени $t$ вычисляется следующим образом:

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

Здесь $\hat{\mu}_a$ — среднее вознаграждение (уровень вовлеченности) ручки $a$ к настоящему времени, $N_a(t)$ — количество раз, когда она была выбрана, а $c$ — параметр, регулирующий степень исследования.

Влияние на выбор технологий: Алгоритм временно предоставляет бонус к исследованию для постов о недавно появившихся фреймворках или библиотеках (с малым количеством попыток $N_a(t)$) и показывает их случайной группе пользователей. Если в течение этой начальной «фазы исследования» реакция влиятельных лиц (инфлюенсеров) положительна, $\hat{\mu}_a$ резко возрастает и быстро превращается в вирусный шум (базз). Это и есть механизм, из-за которого «внезапно все начинают говорить об этой технологии».

3. Математика эхо-камер и пузырей фильтров

По мере продвижения алгоритмической оптимизации пользователи начинают окружать себя «информацией, которая им приятна или которая подкрепляет их существующие убеждения». Это и есть феномен эхо-камеры (Echo Chamber) и пузырь фильтров (Filter Bubble).

В теории сетей тенденция схожих людей объединяться называется «гомофилией (Homophily)». В графе $G=(V, E)$ ребра (отношения подписки или распространение информации) между узлами (пользователями) с большей вероятностью образуются при высокой степени сходства атрибутов.

Алгоритмы рекомендаций в социальных сетях искусственно ускоряют эту гомофилию. Например, представьте, что есть сообщество инженеров, продвигающих «бессерверную архитектуру (Serverless)», и сообщество, поддерживающее «локальное размещение на голом железе (Bare Metal)». Алгоритм учится снижать вес ребер между различными сообществами (Cross-cutting ties) и усиливать ребра внутри одного сообщества (поскольку конфликтующие мнения часто вызывают уход с платформы и рискуют снизить вовлеченность. С другой стороны, иногда крайний гнев может повышать вовлеченность, но в технологической среде преобладает первая тенденция).

В результате на вашей временной шкале может показаться, что «компании по всему миру переходят на бессерверные технологии», в то время как на временной шкале кого-то другого будет казаться, что «уход из облака (Cloud Repatriation) — это глобальный тренд». Так создаются совершенно изолированные технологические реальности.

4. Разработка, управляемая хайпом (HDD), порожденная алгоритмами

Сочетание эхо-камер и мощных рекомендательных моделей приводит к одному из крупнейших антипаттернов в инженерной индустрии — Hype Driven Development (разработке, управляемой хайпом). HDD — это феномен внедрения новых технологий просто потому, что они «обсуждаются в социальных сетях» или «являются последним трендом», без глубокого рассмотрения их реальных преимуществ, компромиссов или соответствия бизнес-требованиям компании.

Следующая диаграмма Mermaid показывает, как алгоритмы социальных сетей запускают цикл обратной связи HDD.

graph TD
A["Инженер публикует 'огромные преимущества' новой технологии"] --> B["Алгоритм измеряет начальный CTR и время пребывания (Исследование)"]
B --> C["Определяется высокая вовлеченность, расширяется показ в лентах похожих пользователей"]
C --> D["Пользователи, стимулируемые FOMO (страхом упущенной выгоды), распространяют дальше"]
D --> E["Возникновение иллюзии частотности (ошибочного восприятия), что это 'становится отраслевым стандартом'"]
E --> F["Внедрение в реальные проекты без достаточной проверки (HDD)"]
F --> A

Что пугает в этом цикле, так это то, что алгоритм намеренно вызывает «Иллюзию частотности (Феномен Баадера — Майнхоф)». Если вы однажды увидите название новой библиотеки управления состоянием, алгоритм воспримет это как сигнал и со следующего дня наполнит вашу ленту разговорами об этой библиотеке. Человеческий мозг ошибочно принимает это за «глобальную эпидемию».

На графике ниже показана разница в жизненных циклах технологий, которые чрезмерно расхайплены (преувеличены) в социальных сетях, и простых, скучных, но надежных технологий (Boring Technology).

xychart-beta
title Жизненный цикл технологий и динамика их оценки
x-axis ["0 мес.", "6 мес.", "12 мес.", "18 мес.", "24 мес.", "30 мес.", "36 мес."]
y-axis "Количество упоминаний / Уровень энтузиазма в соцсетях" 0 --> 100
line [10, 85, 95, 45, 20, 10, 5]
line [15, 20, 25, 35, 50, 65, 80]

(Примечание: на графике выше линия, которая резко возрастает и резко падает, представляет «Технологию на хайпе», а медленно и неуклонно растущая линия представляет «Скучную технологию»)

Расхайпленные технологии сталкиваются с такими реальными проблемами, как «нехватка документации», «серьезные ошибки в крайних случаях» и «выгорание мейнтейнеров» через 6–12 месяцев после внедрения, и быстро исчезают из социальных сетей. Однако устранение технического долга, однажды встроенного в систему, требует огромных затрат.

5. Стратегии «отхода от алгоритмов» при выборе технологий

Итак, как мы можем принимать объективные и взвешенные решения о выборе технологий, находясь под контролем этих алгоритмов? Вот несколько конкретных стратегий не для взлома алгоритмов, а для «выхода» из-под их влияния.

5.1 Возврат к первоисточникам: исходный код и RFC

Самая надежная защита — это перенос источников информации с агрегаторов социальных сетей на первоисточники (Primary Sources).

Читайте исходный код: Вместо того чтобы верить постам в социальных сетях о том, что «эта библиотека работает молниеносно», откройте GitHub и проверьте вычислительную сложность базовой логики и механизм выделения памяти.
Следите за RFC (Request for Comments): Многие зрелые проекты с открытым исходным кодом (React, Rust, Python и т. д.) используют процесс RFC при внедрении новых функций. В RFC логично и беспристрастно описаны вопросы «зачем нужна эта функция», «каковы архитектурные компромиссы» и «каковы альтернативы», без оглядки на алгоритмическую вовлеченность. Именно здесь кроется истинная техническая ценность.

5.2 Внимательное чтение научных статей (Academic Papers) и технических документов (Whitepapers)

Когда дело доходит до фундаментального выбора технологий, таких как распределенные системы, базы данных и архитектуры моделей машинного обучения, вам следует читать напрямую научные статьи, опубликованные ACM, IEEE или arXiv, а также подробные технические документы, опубликованные компаниями (например, статья Google о Spanner, статья Amazon о Dynamo), а не резюме в несколько строк в социальных сетях.

Посты в социальных сетях оптимизированы на «захват внимания читателя», тогда как рецензируемые статьи оптимизированы на «фактическую точность и воспроизводимость». Функции оценки совершенно разные.

5.3 Построение фреймворка для принятия решений в организации

Чтобы предотвратить HDD на уровне команды или организации, необходим процесс, исключающий субъективную интуицию или причины вроде «потому что я видел это в Twitter». Типичным примером является внедрение ADR (Architecture Decision Records).

При внедрении новой технологии следующие пункты всегда должны быть задокументированы и рецензированы:

Context (Контекст): Зачем нужна новая технология? Какова текущая проблема?
Decision (Решение): Что будет принято?
Consequences (Последствия): Каковы компромиссы? (Чем мы жертвуем и что получаем?)

Сделав этот процесс обязательным, можно превратить «Хайп (Hype)» в «Инженерию (Engineering)».

5.4 Философия Boring Technology Club

В технологическом мире есть известная мантра: “Choose Boring Technology” (Выбирайте скучные технологии). Она учит нас не тратить токены инноваций (ограниченные ресурсы, которые организация может потратить на новые неизвестные технологии) на выбор инфраструктуры или фреймворков, не связанных напрямую с основными бизнес-ценностями.

Алгоритмы социальных сетей любят «новизну». Однако для создания надежной системы, способной выдержать реальную эксплуатацию, вам нужны «скучные» технологии с более чем 10-летней историей использования, процедуры восстановления после сбоев для которых дают миллионы результатов в поиске Google (PostgreSQL, Redis, стандартные REST API и т. д.).

6. Заключение: Как нам следует относиться к технологиям

Алгоритмы рекомендаций социальных сетей — это мощные инструменты, которые расширяют наш технологический кругозор и позволяют знакомиться с замечательными сообществами. Однако, поскольку их внутренняя структура (матричное разложение, DLRM, многорукие бандиты) имеет своей главной целью «максимизацию вовлеченности», выдаваемая информация неизбежно будет предвзятой.

Нам необходимо развить грамотность, чтобы относиться к информации, поступающей в наши ленты, как к одному из «сигналов», а не как к «фактам» или «абсолютным трендам».

Нужно выйти за пределы эхо-камер, читать исходный код своими глазами, следить за обсуждениями в RFC, расшифровывать математические формулы в научных статьях и смотреть в лицо истинным проблемам нашего бизнес-домена. Это единственный способ практиковать настоящую программную инженерию, не будучи поглощенным волной алгоритмов.

Текущее состояние и проблемы ИТ-образования в Японии: последствия обязательного обучения программированию

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

1. Введение: Свет и тени обязательного обучения программированию

С обязательным обучением программированию в начальной школе в 2020 финансовом году, его расширением на уроках технологий и домоводства в средней школе в 2021 году и введением нового обязательного предмета «Информация I» в старшей школе в 2022 году, ИТ-образование и информатика в Японии за последние годы пережили смену парадигмы беспрецедентного масштаба. В основе этой серии политических мер лежит чрезвычайно острая и национальная необходимость: развитие логического мышления (программистского мышления) для выживания в эпоху Society 5.0 (супер-умного общества) и решение хронической проблемы нехватки высококвалифицированных ИТ-кадров в промышленности.

Однако, если взглянуть на передовую линию образования, становится очевидным, что между идеалом, нарисованным государством, и реальностью возник огромный разрыв. Самая серьезная проблема заключается в том, что «изучение программирования как инструмента» и «освоение компьютерных наук как академической дисциплины» полностью смешиваются. Кроме того, существует множество структурных проблем, требующих решения, таких как технические ограничения, вызванные характеристиками ИТ-инфраструктуры, развернутой в масштабах всей страны, и нехватка специализированных навыков у преподавателей.

В этой статье подведены итоги того, что произошло «после» введения обязательного программирования в Японии, и дан чрезвычайно подробный технический анализ фундаментальных и структурных проблем, с которыми ИТ-образование сталкивается прямо сейчас, с точки зрения теории компьютерных наук, аппаратных ограничений и глобальной конкурентоспособности промышленности. Это не просто рассуждение об образовании, а эссе на 10 000 символов, в котором будущее Японии рассматривается с точки зрения программной инженерии.

2. Ловушка визуального программирования: Глубокая и крутая пропасть между Scratch и текстовым кодированием

Де-факто стандартом в обучении программированию в начальной школе стали языки визуального программирования (блочное программирование), типичным представителем которых является «Scratch», разработанный MIT Media Lab. Тот факт, что три базовые управляющие структуры алгоритмов: «последовательность (sequence)», «ветвление (selection)» и «цикл (iteration)», могут быть изучены визуально и интуитивно путем соединения блоков, как пазлов, с использованием интуитивно понятного графического интерфейса, является великим изобретением, которое следует высоко оценить в качестве вводного образования.

Однако здесь кроется серьезная ловушка, так называемая «ловушка абстракции». Это жестокий факт, что «переход от визуального программирования к полноценным текстовым языкам программирования (Python, JavaScript, C++, Rust и т.д.) чрезвычайно сложен, и многие учащиеся сдаются на этом этапе».

Барьер абстракции и черный ящик компьютерных наук

Среды визуального программирования, такие как Scratch, в высокой степени абстрагируют и намеренно скрывают (инкапсулируют) ключевые элементы, составляющие основу компьютерных наук, такие как сложный синтаксис программирования, строгие системы типов и управление жизненным циклом памяти. Это отлично подходит для снижения когнитивной нагрузки на новичков, но становится огромным препятствием при переходе к следующему этапу — настоящей инженерии. В реальной разработке программного обеспечения абсолютно необходимо понимание области видимости переменных (локальные и глобальные переменные), сложных структур данных (массивы, связные списки, хеш-таблицы, бинарные деревья поиска, графы), операций с указателями и областей памяти heap (куча) и stack (стек).

Следующая диаграмма Mermaid визуализирует препятствия в обучении и точки отсева (drop-off), с которыми сталкиваются новички в процессе перехода от визуального программирования к полноценной информатике.

flowchart TD
A["Начальная школа: Scratch (визуальный/на основе блоков)"] --> B{"Средняя школа: Барьер перехода к текстовым языкам"}
B -->|Сдаются из-за строгих синтаксических ошибок| C["Отсев (Аллергия на синтаксис)"]
B -->|Недостаток понимания переменных и статической типизации| D["Отсев (Барьер типов)"]
B -->|Успешный переход| E["Старшая школа: Информация I (Основы Python/JavaScript и др.)"]
E --> F{"Барьер проектирования алгоритмов и структур данных"}
F -->|Непонимание временной и пространственной сложности| G["Неэффективный код (Снижение производительности из-за злоупотребления O(N^2))"]
F -->|Черный ящик управления памятью и ссылок| H["Превращение в кодера, ограничивающегося поверхностными вызовами API"]
F -->|Концептуальный прорыв| I["Полноценное изучение CS (C/C++, Java, низкоуровневая архитектура)"]
I --> J["Высококвалифицированный ИТ-профессионал, которого жаждет индустрия"]
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;

Как ясно из этой блок-схемы, простой опыт «написания кода, который перемещает персонажей на экране» не воспитает настоящих инженеров-программистов, способных проектировать масштабируемую распределенную системную архитектуру и оптимизировать производительность до миллисекунд. Между сборкой разноцветных блоков Scratch с помощью мыши и чтением исходного кода ядра Linux на C для отслеживания поведения стека TCP/IP существует абсолютный концептуальный разрыв, который нельзя объяснить просто словами «разница в используемых языках».

3. Ограничения кодирования без «Математики» и «Дискретной логики»: Подход с точки зрения теории сложности

Самой слабой стороной и фатальным недостатком учебной программы по программированию в Японии является острая нехватка связи между «навыками кодирования» и «математикой/дискретной математикой (Discrete Mathematics)». В лучших программах по информатике (computer science) в США, Индии и других странах акцент делается на эффективности алгоритмов, математической логике и математических доказательствах, а не на самой грамматике языков программирования. Ведь код — это не что иное, как перевод математических формул.

Абсолютное доминирование временной и пространственной сложности (Big O Notation)

При оценке и проектировании производительности программного обеспечения нельзя избежать концепций временной сложности (Time Complexity) и пространственной сложности (Space Complexity). Асимптотическая нотация Ландау (Big O Notation) показывает, как увеличивается время выполнения и потребление памяти, когда размер данных, вводимых в алгоритм, равен $N$.

Математически $f(x) = O(g(x))$ строго определяется следующим образом:

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

В японском ИТ-образовании, например, при изучении сортировки данных, часто встречаются случаи, когда все заканчивается простым вызовом встроенного метода array.sort() в Python. Однако то, что действительно требуется в информационной инженерии, — это математическое понимание и доказательство того, почему простая пузырьковая сортировка никогда не используется в практических областях, и почему быстрая сортировка (Quick Sort), сортировка слиянием (Merge Sort) или Timsort принимаются в качестве стандартных библиотек.

Ниже приведена средняя временная сложность типичных алгоритмов сортировки:

Пузырьковая сортировка (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)$

Например, временная сложность сортировки слиянием $T(N)$ в рамках парадигмы «разделяй и властвуй» (Divide and Conquer) выражается следующим рекуррентным соотношением:

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

Путем разложения и решения этого рекурсивного уравнения с использованием основной теоремы (Master Theorem) выводится идеальная сложность $T(N) = O(N \log N)$.

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

При анализе современных больших данных и обработке трафика в масштабе веб-приложений $N$ достигает огромных порядков — сотен миллионов и миллиардов. Если невежественный программист реализует неэффективный алгоритм $O(N^2)$, для данных размером $N = 10^6$ потребуется $10^{12}$ (1 триллион) ненужных операций сравнения, и система фактически зависнет или рухнет. С другой стороны, с $O(N \log N)$ это будет завершено примерно за $2 \times 10^7$ (20 миллионов) операций. Утверждать «я умею программировать» без этой жестокой математической поддержки — все равно что строить небоскреб, не зная строительной механики, и это крайне опасно.

4. Управление памятью и превращение системной архитектуры в черный ящик

Еще более глубокая проблема заключается в том, что понимание управления памятью (Memory Management) и архитектуры ЦП полностью отсутствует. Учащиеся, изучающие только языки высокого уровня с автоматической сборкой мусора (GC), такие как Python и JavaScript, которые в настоящее время преподаются в школах, никогда в жизни не будут задумываться о том, где в физической памяти (RAM) размещаются переменные и объекты (в куче или в стеке), как они выделяются и когда/как освобождаются.

 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


// Пример явного и прямого выделения памяти и манипуляций с указателями в C
#include <stdio.h>
#include <stdlib.h>

int main() {
 int n = 1000000;
 // Динамическое непрерывное выделение памяти в куче (системный вызов к ОС)
 int *array = (int*)malloc(n * sizeof(int));

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

 // Инициализация массива с помощью арифметики указателей
 for(int i = 0; i < n; i++) {
 *(array + i) = i * 2; // Эквивалентно array[i] = i * 2
 }

 // Явное освобождение ресурсов для предотвращения утечки памяти (Memory Leak)
 free(array);
 array = NULL; // Предотвращение появления висячих указателей (Dangling pointer)

 return 0;
}

Концепции указателей (прямые ссылки на адреса памяти), размещение данных для максимизации частоты попадания в иерархию кэш-памяти ЦП (кэш L1/L2/L3) (Data Locality), а также знания о состоянии гонки (Race Condition) и взаимном исключении (Mutex/Semaphore) в многопоточной среде абсолютно необходимы для разработки высокопроизводительных бэкенд-систем, 3D-игровых движков или встроенных систем для IoT. Приходится признать, что нынешняя учебная программа Министерства образования, культуры, спорта, науки и технологий ограничивается «созданием поверхностных приложений» и сильно отклоняется от своей первоначальной академической цели — «понимания глубин компьютерных наук».

5. Барьер баз данных и персистентности: Отсутствие реляционной алгебры

В современных приложениях сохранение и поиск данных (персистентность) являются неизбежными темами. Однако большая часть школьного образования ограничивается «обработкой данных в памяти», которые исчезают после завершения программы. Математическая теория, лежащая в основе реляционных баз данных (RDBMS) и SQL, а именно «реляционная алгебра (Relational Algebra)», предложенная доктором Эдгаром Ф. Коддом, преподается редко.

Операции с базами данных определяются следующими базовыми операциями, основанными на теории множеств:

Выборка (Selection, $\sigma$): Извлечение кортежей (строк), удовлетворяющих условию.
Проекция (Projection, $\pi$): Извлечение определенных атрибутов (столбцов).
Соединение (Join, $\bowtie$): Условное пересечение нескольких отношений.

Кроме того, изучение структуры индекса «B-Tree (B-дерево)» для мгновенного поиска нужных данных среди огромного количества записей является лучшей практикой применения структур данных. B-Tree минимизирует количество операций ввода-вывода (I/O) на диске и гарантирует скорость поиска $O(\log N)$. Невозможно создать надежную систему, не зная свойств ACID (Atomicity, Consistency, Isolation, Durability) транзакций.

6. Безопасность и теория криптографии: Сложность разложения на множители как опора социальной инфраструктуры

Хотя обучение информационной грамотности включает поверхностное обучение безопасности, такое как «давайте использовать сложные пароли» и «давайте не будем переходить по подозрительным ссылкам», математика «теории криптографии», которая является основой интернет-общества, почти не преподается.

Связь по протоколу HTTPS и цифровые подписи, которые мы используем каждый день, защищены криптографией с открытым ключом, такой как алгоритм RSA. Безопасность RSA зависит от математической сложности (которая считается NP-промежуточной задачей): «разложение огромных целых чисел на простые множители невозможно решить за реальное время на современных классических компьютерах».

Математические формулы, лежащие в основе криптографии RSA, красивы и применяют функцию Эйлера (totient) и малую теорему Ферма:

Выберите два очень больших простых числа $p$ и $q$.
Вычислите $n = p \times q$ (это станет частью открытого ключа).
Вычислите $\phi(n) = (p-1)(q-1)$.
Выберите $e$ и $d$ такие, что $e \times d \equiv 1 \pmod{\phi(n)}$.
Шифрование: $C \equiv M^e \pmod{n}$
Расшифровка: $M \equiv C^d \pmod{n}$

Таким образом, обучение программированию демонстрирует свою истинную мощь только тогда, когда оно тесно связано с обучением математике. Процесс перевода математических формул в код и их внедрение в общество — вот в чем заключается истинная прелесть науки.

7. Концепция GIGA School и безнадежные ограничения инфраструктуры: Chromebook и облачные IDE

Говоря об ИТ-образовании в Японии, нельзя не упомянуть о «Концепции GIGA School», национальном проекте, на продвижение которого Министерство образования, культуры, спорта, науки и технологий потратило огромный бюджет. Ожидалось, что этот проект, который обеспечит «одно устройство на каждого ученика» и высокоскоростную сетевую среду для учащихся начальных и средних школ по всей стране, станет катализатором для преодоления отставания в цифровизации. Однако аппаратные характеристики и архитектура реально распределенных терминалов стали серьезным препятствием для полноценного обучения программированию.

Низкопроизводительные терминалы и потеря среды локальной разработки

Многие терминалы, представленные в качестве стандартных спецификаций концепции GIGA School, — это чрезвычайно дешевые Chromebook, iPad или бюджетные устройства Windows. Их стандартные характеристики таковы:

ЦП: Intel Celeron или дешевый процессор ARM
Память (RAM): 4 ГБ (Минимально достаточный объем только для запуска современной ОС)
Хранилище (eMMC): от 32 ГБ до 64 ГБ (Чрезвычайно низкая скорость ввода-вывода)

Из-за этих скудных аппаратных ограничений фактически невозможно создать «среду локальной разработки», которую профессиональные инженеры используют каждый день. Запуск контейнеров Linux с использованием Docker, запуск тяжелых IDE, таких как Visual Studio Code, с полной функциональностью или запуск локальных серверов Node.js/Python для установки тяжелых библиотек приведет к немедленному истощению памяти и зависанию системы.

В результате сфера образования вынуждена полностью полагаться на облачные IDE (Google Colaboratory, Replit или легкие веб-инструменты от издателей учебников), которые работают в браузере.

flowchart LR
subgraph "Терминал GIGA (Chromebook / iPad / Бюджетный Windows)"
A["Веб-браузер (Только рендеринг UI)"]
end
subgraph "Удаленная облачная инфраструктура (AWS / GCP и др.)"
B["Веб-сервер облачной IDE"]
C["Среда компиляции/выполнения бэкенда"]
D["Персистентное файловое хранилище"]
end
A -->| Связь HTTP/WebSocket: Серьезные задержки из-за узких каналов связи в школах | B
B <--> C
B <--> D

Полная зависимость от облачных IDE вызывает следующие чрезвычайно серьезные пробелы в образовании:

Непонимание файловых систем и архитектуры ОС: Поскольку у них нет локальной среды, они вообще не приобретают необходимые знания, которыми ИТ-инженеры должны владеть, как воздухом для дыхания (грамотность UNIX), такие как структура каталогов, концепции абсолютных/относительных путей, настройка переменных среды, права доступа к файлам и операции с ОС через CLI (интерфейс командной строки).
Задержки в сети и уязвимости инфраструктуры: Поскольку предполагается постоянное соединение, по всей стране часто происходят инциденты, когда вся школа получает доступ к сети одновременно, пропускная способность школьной сети исчерпывается, браузеры зависают, а обучение полностью останавливается.
Лишение опыта управления версиями (Git): Они лишаются возможности изучить концепции Git и GitHub для управления историей изменений исходного кода и совместной разработки с командами по всему миру через черный экран терминала.

Когда профессиональный инженер-программист занимается разработкой, работа в терминале (оболочке) является абсолютной основой. Невозможно воспитать настоящие ИТ-кадры без приземленного опыта прямого взаимодействия с ядром локальной ОС с помощью таких команд, как ls, cd, grep, chmod, git rebase. Если играть только в песочнице (sandbox) Chromebook, из вас никогда не получится full-stack инженер, который может видеть систему целиком.

8. Безнадежный разрыв с миром: Расхождение между требованиями индустрии и школьным образованием

Последней и, пожалуй, национальной кризисной проблемой японского ИТ-образования является колоссальное снижение конкурентоспособности в глобальном контексте.

Интенсивное образование в области компьютерных наук в других странах

В Великобритании (UK) предмет под названием «Вычисления» (Computing) стал обязательным с 5 лет (Key Stage 1) еще в 2014 году. Их учебная программа не ограничивается простым «опытом программирования», а охватывает в высшей степени академическую и систематическую полноценную информатику, начиная от логического проектирования алгоритмов, понимания логических схем с использованием булевой алгебры (Boolean algebra) до сетевых топологий и аппаратной архитектуры.

В Соединенных Штатах существует строгая стандартная учебная программа K-12 (от детского сада до окончания средней школы), установленная Ассоциацией преподавателей компьютерных наук (CSTA), а в курсе AP (Advanced Placement) Computer Science A, который проходят старшеклассники, полноценное объектно-ориентированное программирование с использованием Java, полиморфизм, рекурсия, реализация структур данных и оценка сложности алгоритмов преподаются на высоком уровне первого курса университета. Жесткость STEM-образования в Индии и Китае, а также глубина выпускаемой оттуда элиты не нуждаются в упоминании.

Безнадежный разрыв между требуемыми навыками и тем, чему обучают

Требования, предъявляемые современной индустрией, особенно глобальными мега-венчурными компаниями и технологическими гигантами (GAFAM и др.), к новым инженерам-программистам усложняются с пугающей скоростью каждый год. Требуется обширный и глубокий опыт, включая создание облачной инфраструктуры (AWS, GCP, Kubernetes), проектирование распределенных систем с микросервисной архитектурой, реализацию конвейеров машинного обучения и глубокие знания в области безопасности.

На следующем графике концептуально показан безнадежный разрыв между уровнем достижения навыков, предоставляемым японским школьным образованием в настоящее время, и уровнем навыков, требуемым передовой индустрией.

xychart-beta
title Навыки в школьном образовании Японии vs Требования индустрии
x-axis ["Визуальные языки", "Базовый синтаксис/переменные", "Алгоритмы/сложность", "ОС/Сети", "БД/Проектирование систем", "Облачная/Распределенная архитектура"]
y-axis "Уровень достижения / Требования (%)" 0 --> 100
line "Уровень достижений в современном школьном образовании" [95, 60, 15, 5, 2, 0]
line "Уровень, требуемый индустрией/технологическими компаниями" [0, 20, 85, 90, 95, 100]

Чтобы преодолеть этот огромный разрыв (Долину Смерти - Death Valley), необходим радикальный сдвиг парадигмы школьного образования и колоссальные инвестиции. В условиях острой нехватки учителей, специализирующихся на «информатике», по всей стране, невозможно воспитать инженеров высшего уровня, способных конкурировать в мире, при нынешней системе, когда учителя математики, естественных наук или технологий и домоводства преподают программирование в свободное от основной работы время без надлежащего обучения.

9. Обесценивание «кодирования» в эпоху ИИ (LLM)

Ситуация еще больше осложняется взрывным распространением больших языковых моделей (LLM), таких как ChatGPT, и помощников по программированию на базе ИИ, таких как GitHub Copilot. В наши дни, когда ИИ может мгновенно сгенерировать идеальный код на основе инструкций на естественном языке и даже написать тестовый код, рыночная стоимость так называемых «кодеров (Coders)», которые знают только «синтаксис Python» или «как вызывать API», стремительно падает.

В эпоху ИИ от инженеров-людей не требуется умение запоминать синтаксис языков программирования. Требуются следующие способности:

Определение требований и предметно-ориентированное моделирование (Domain modeling): Способность выделять сложные реальные проблемы, которые необходимо решить, и моделировать их как системы.
Проектирование архитектуры: Способность составить чертеж всей системы для обеспечения масштабируемости, доступности и ремонтопригодности.
Математическая/логическая верификация: Способность теоретически проверить и доказать, что сгенерированный ИИ код не содержит дыр в безопасности или узких мест вычислительной сложности.

По иронии судьбы, все это области глубоких абстрактных «компьютерных наук и математики», а не «поверхностного программирования». Если японское образование обучает только «низкоуровневым навыкам, которые легко заменяются ИИ», это можно назвать лишь национальной потерей.

10. На пути к интеграции математических наук и программирования: Предложения для образования следующего поколения

Срочной задачей японского ИТ-образования в будущем является отказ от отношения к программированию как к «цели и средству» и возвращение к «исследованию компьютерных наук как математической науки». Язык программирования — это всего лишь инструмент для выражения мыслей, а лежащая в его основе математическая и логическая структура имеет универсальную ценность, которая не меркнет с течением времени.

Например, в основе искусственного интеллекта (ИИ) и машинного обучения тесно переплетаются линейная алгебра (матричные операции и тензоры), многомерный анализ (градиентный спуск) и теория вероятностей/статистика (байесовский вывод и количество информации). Оптимизация весов в нейронных сетях глубокого обучения формулируется через цепное правило (Chain Rule) с использованием частных производных и обратного распространения ошибки (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)} $$

Именно кадры, способные перевести такие сложные математические формулы в код и реализовать их, доведя параллельные вычисления (Parallel Computing) до максимума с учетом аппаратной архитектуры GPU (CUDA) или TPU, поведут за собой ИТ-индустрию следующего поколения. Вот почему мы должны немедленно переключиться с поверхностного образования, которое просто заставляет заучивать синтаксис, на глубокое образование, которое задается фундаментальными принципами вычислений (First Principles).

11. Заключение: Трудный путь к истинной ИТ-нации и наша решимость

Сделать программирование обязательным в 2020-х годах, несомненно, было уверенным шагом вперед в том смысле, что это заставило японское общество в целом осознать «важность ИТ и информации». Однако это лишь «разминка» на долгом пути.

Сделать шаг вперед от удовольствия перемещать персонажа-кота в Scratch, научить восторгаться математической красотой алгоритма $O(N \log N)$ и показать радость общения с серверами по всему миру через TCP-пакеты с черного экрана терминала. Восстановить новую образовательную инфраструктуру для преодоления аппаратных ограничений концепции GIGA School, воспитать и расставить преподавателей с высокой специализацией в области CS, а иногда смело привлекать внешних профессиональных инженеров к школьному образованию.

Проблемы, стоящие перед ИТ-образованием в Японии, чрезвычайно глубоки, укоренились и сложны. Однако, когда промышленность, академические круги и правительство серьезно объединятся для решения этих проблем, не отворачиваясь от них, и построят экосистему, способную постоянно выпускать «настоящих инженеров, способных проектировать и создавать системы с нуля», а не «рабочих, умеющих писать код только по спецификациям», Япония снова сможет возглавить мир как истинная ИТ-нация.

Как пережить самый трудный и важный этап «после» введения обязательного обучения программированию? Именно сейчас проверяется серьезность и решимость нас, взрослых.

В этой статье был представлен обзор теории сложности и инфраструктурных ограничений концепции GIGA School. Более специализированные темы по компьютерным наукам (подробности алгоритмов распределенных систем и методы управления памятью на низком уровне) будут последовательно рассматриваться в следующих выпусках этой серии.

Углубление "нового цифрового разрыва", вызванного эволюцией генеративного ИИ

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

1. Введение: Историческая эволюция цифрового разрыва и новая парадигма

С момента распространения интернета мы часто слышали термин «цифровой разрыв» (информационное неравенство). Ранний цифровой разрыв касался в первую очередь «физического доступа». То есть это была простая концепция, где наличие компьютера или высокоскоростного доступа в интернет определяло доступ к информации и экономическим возможностям. Впоследствии, по мере того как смартфоны и широкополосный интернет стали общедоступными (коммодитизировались), фокус разрыва сместился на «ИТ-грамотность» (навыки использования информации). Это программные и когнитивные аспекты, такие как умение правильно искать информацию с помощью поисковых систем или владение программным обеспечением.

Однако стремительное развитие генеративного ИИ (Generative AI) и больших языковых моделей (LLM: Large Language Models), внезапно возникшее в 2020-х годах, фундаментально меняет эту концепцию цифрового разрыва. То, с чем мы сталкиваемся сейчас, — это не просто «разрыв в доступе к информации» или «разрыв в навыках работы с программным обеспечением». Это «разрыв в способности оркестровки (управления и интеграции) ИИ» — крайне серьезный и необратимый «третий цифровой разрыв», который либо экспоненциально увеличит личную продуктивность, либо оставит человека позади эволюции ИИ, лишив его относительной ценности.

В этой статье мы максимально подробно раскроем истинную природу этого нового цифрового разрыва, вызванного генеративным ИИ, с точки зрения трех уровней: математической модели продуктивности, архитектуры и стоимости оборудования, а также когнитивных аспектов человека.

2. От «доступа» к «оркестровке»: Наступление третьего цифрового разрыва

Программные инструменты прошлого были по сути «пассивными орудиями». Ограничение традиционного ПО заключалось в том, что оно возвращало детерминированный результат на явный ввод пользователя (например, ввод формулы в электронную таблицу для получения результата вычислений). Однако современный генеративный ИИ, в частности LLM на базе архитектуры Transformer (GPT-4, Claude 3.5, Llama 3 и т.д.), ведет себя как «фрагмент активного интеллекта».

Из-за этого сдвига парадигмы требуемый от человека набор навыков радикально изменился: от «умения управлять инструментами» к «способности комбинировать несколько ИИ-агентов и инструментов, проектировать и управлять автономными рабочими процессами (AI Orchestration)». Это можно назвать «грамотностью в области оркестровки ИИ».

Ниже показана эволюция цифрового разрыва от прошлого к настоящему.

flowchart TD
A["Первый разрыв: Доступ к оборудованию и инфраструктуре (1990-2000-е)"] --> B["Второй разрыв: ИТ-грамотность и навыки поиска информации (2010-е)"]
B --> C["Третий разрыв: Промптинг и оркестровка генеративного ИИ (2020-е -)"]
C --> D["Проектирование автономного выполнения задач с помощью ИИ"]
C --> E["Интеграция нескольких ИИ-агентов (Agentic Workflows)"]
C --> F["Продвинутая верификация информации и обнаружение галлюцинаций"]

Выходя за рамки простого промпт-инжиниринга (prompt engineering), сегодня мы вступили в стадию, когда мультиагентные фреймворки, такие как LangChain, AutoGen и CrewAI, используются для того, чтобы системы могли автономно решать проблемы. Между теми, кто «создает чертежи и заставляет ИИ их выполнять», и теми, кто «все еще выполняет рутинную работу своими руками», возникает беспрецедентный в истории человечества разрыв в продуктивности.

3. Эффект Матфея (Matthew Effect) в продуктивности: Визуализация неравенства с помощью математического подхода

«Эффект Матфея» (Matthew Effect), происходящий от слов Нового Завета «ибо всякому имеющему дастся и приумножится, а у неимеющего отнимется и то, что имеет», в социологии и экономике означает феномен, при котором первоначальное преимущество приносит кумулятивную выгоду. С внедрением генеративного ИИ этот эффект Матфея интенсивно проявляется на рынке труда и в интеллектуальном производстве.

Продуктивность людей, эффективно использующих ИИ, растет не линейно по отношению к времени, а экспоненциально. Это происходит потому, что время, сэкономленное благодаря ИИ, может быть инвестировано в создание еще более продвинутых ИИ-систем, оптимизацию промптов и самообучение. Давайте выразим это с помощью математической модели.

Продуктивность пользователя, не использующего ИИ $P_{human}(t)$, и продуктивность оркестратора ИИ $P_{AI}(t)$ в момент времени $t$ можно представить следующими моделями:

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

Где $P_0$ — начальная продуктивность, а $r_{human}$ — естественная скорость обучения человека (скорость роста на основе кривой опыта). Как правило, $r_{human}$ очень мала, и рост имеет тенденцию быть арифметическим.

С другой стороны, продуктивность пользователя, в полной мере использующего ИИ, объединяет в себе скорость улучшения возможностей используемой модели ИИ $r_{model}$ и эффект сложных процентов $\alpha$ от автоматизации рабочих процессов ИИ.

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

Поскольку сами модели ИИ развиваются экспоненциально (увеличение количества параметров и объема вычислений на основе законов масштабирования), $r_{model}(t)$ сама по себе увеличивается со временем. В результате разница в продуктивности между ними $\Delta P(t)$ стремительно растет.

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

Этот разрыв визуально показан на графике ниже.

xychart-beta
title Расхождение продуктивности во времени (Эффект Матфея)
x-axis ["Год 1", "Год 2", "Год 3", "Год 4", "Год 5", "Год 6"]
y-axis "Объем выпуска" 0 --> 200
line [10, 15, 30, 60, 110, 180]
line [10, 12, 14, 16, 18, 20]

(Примечание: Синяя линия обозначает продуктивность оркестратора ИИ, а нижняя линия — продуктивность пользователя, не использующего ИИ)

В первый год разница кажется незначительной, но по мере того, как модели ИИ эволюционируют от GPT-3 к GPT-4 и далее к следующим поколениям, пользователи ИИ получают огромный прирост продуктивности просто за счет подключения новых моделей к своим существующим конвейерам автоматизации. Для пользователей без ИИ преодолеть этот разрыв со временем становится математически почти невозможным.

4. Аппаратный разрыв: Барьер локального вывода и ловушка облачных API

Третий цифровой разрыв порождает не только неравенство в навыках работы с программным обеспечением, но и новое аппаратное неравенство — «доступ к вычислениям (вычислительным ресурсам)» для запуска самых передовых моделей ИИ.

Существуют два основных подхода к использованию больших языковых моделей: «использование облачного API» или «локальный вывод (Inference) модели». У каждого есть свои плюсы и минусы, и они становятся новым экономическим и физическим барьером.

Ограничения облачных API и текущие расходы

К передовым фронтирным моделям, предоставляемым OpenAI, Anthropic и Google (GPT-4o, Claude 3.5 Sonnet и т.д.), обычно получают доступ через API. Однако, если создать продвинутого автономного агента (Agentic Workflow), генерирующего десятки тысяч вызовов API в день, расходы будут стремительно расти.

Общая стоимость API $C_{cloud}$ зависит от количества входных и выходных токенов.

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

(Где $N$ — количество запросов, $T$ — количество токенов, $c$ — цена за токен)

В случае масштабной обработки данных или непрерывной векторизации для RAG (Retrieval-Augmented Generation) эти переменные расходы могут стать фатальным бременем для индивидуальных разработчиков и малого бизнеса.

Локальные LLM и барьер VRAM

С точки зрения избежания облачных затрат и обеспечения конфиденциальности данных растет спрос на локальный запуск моделей с открытыми весами (open-weight), таких как Meta Llama 3 и Mistral. Но здесь возникает физический разрыв в виде «барьера VRAM (видеопамяти)».

Скорость вывода LLM сильнее зависит от пропускной способности памяти (Memory Bandwidth), чем от вычислительной мощности GPU (FLOPS) (свойство Memory-bound). Если количество параметров модели равно $P$, а точность — 16 бит (2 байта), то для загрузки модели в память требуется как минимум $2P$ байт VRAM. Например, модель с 70 миллиардами (70B) параметров потребует более 140 ГБ VRAM.

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

Даже высокопроизводительные графические процессоры, доступные обычным потребителям (NVIDIA RTX 4090), имеют только 24 ГБ VRAM, поэтому запустить модель класса 70B в исходном виде на них невозможно. Здесь на сцену выходят технологии «квантования (Quantization)», такие как AWQ и GGUF, которые сжимают веса до 4 или 8 бит для поиска компромисса, но ухудшение производительности (ухудшение Perplexity) из-за квантования неизбежно.

Кроме того, в последние годы появились «AI PC» с NPU (нейронными процессорами), но текущие показатели TOPS (тера-операций в секунду) у NPU способны потянуть разве что легкие малые модели (SLM: Small Language Models). Для выполнения действительно сложных выводов локально требуются капиталовложения для создания систем с несколькими GPU стоимостью в миллионы иен (десятки тысяч долларов). Это и есть истинная природа «капиталоемкого цифрового разрыва» в сфере ИИ.

5. Когнитивный разрыв: Галлюцинации и цикл верификации

Что еще страшнее, чем неравенство в оборудовании или навыках, так это «когнитивный разрыв». ИИ генерирует очень беглые и убедительные тексты, но в то же время может правдоподобно выдавать фактологически неверную информацию — так называемые «галлюцинации».

Возникающий здесь разрыв — это разделение на тех, «кто способен критически анализировать и проверять (фактчекинг) вывод ИИ», и тех, «кто слепо верит выводу ИИ как авторитетной истине». Первые используют ИИ как мощный инструмент для мозгового штурма или создания черновиков, применяя свои собственные экспертные знания для контроля качества (QA) финального результата. Вторые же выпускают в мир ложную информацию, не только теряя доверие к себе, но и способствуя загрязнению информационного пространства в интернете спамовым контентом.

Процесс цикла когнитивной верификации (Cognitive Verification Loop), направленный на предотвращение этого, показан ниже.

flowchart TD
A["Намерение человека (Intent)"] --> B["Ввод промпта в ИИ (Prompting)"]
B --> C["Генерация моделью ИИ (Generation)"]
C --> D{"Когнитивная верификация (Cognitive Verification)"}
D -- Есть сомнения / логические ошибки --> E["Фактчекинг с помощью RAG и внешних инструментов"]
E --> F["Повторная настройка и улучшение промпта"]
F --> B
D -- Факты и логика обоснованы --> G["Окончательная корректировка на основе предметных знаний человека"]
G --> H["Вывод конечного результата"]

Чтобы этот цикл работал, необходимо не просто знать, как использовать ИИ, но и обладать глубокими «предметными знаниями (доменными знаниями)» в области генерируемого контента, а также «критическим мышлением». По иронии судьбы, чем больше развивается ИИ, тем больше от людей требуются не базовые навыки управления, а крайне высокие когнитивные способности, такие как философское и логическое мышление и эрудиция для различения истины и лжи.

6. Новое классовое общество: Оркестраторы ИИ и работники ручного труда

В будущем (или в текущей реальности), когда это неравенство достигнет своего предела, рынок труда будет поляризован беспрецедентным образом.

1. Оркестраторы ИИ (топ 1-5%) В своей профессиональной области они создают рабочие процессы, в которых автономно действуют несколько ИИ-агентов. Большую часть таких процессов, как исследования, кодирование, анализ данных и создание отчетов, они делегируют ИИ, специализируясь на «проектировании процессов», «обработке исключений» и «принятии окончательных решений». Их продуктивность будет в десятки и сотни раз выше, чем у традиционных работников, создавая колоссальную экономическую ценность.

2. Традиционные работники умственного и ручного труда Это люди, которые пишут код своими руками, работают в Excel своими руками и пишут тексты своими руками. Их работа будет постепенно вытесняться ИИ, или же их оттеснят на позиции «мониторинга и обслуживания на периферии» систем, созданных оркестраторами ИИ, либо на «работу в физическом пространстве». Интеллектуальный труд без использования ИИ столкнется с риском полной потери конкурентоспособности на рынке.

7. Стратегии выживания в условиях разрыва и социальные рецепты

Как люди, компании и общество в целом должны адаптироваться к этому подавляющему разрыву?

Стратегия для людей: Адаптация к смене парадигмы

Самое важное — отбросить недооценку того, что «ИИ — это просто чат-бот». Необходимо рассматривать ИИ как «высококвалифицированного стажера» или «команду экспертов» и постоянно развивать в себе привычку думать о том, как декомпозировать свои бизнес-процессы (Task Decomposition) и делегировать их ИИ. Кроме того, даже если вы не умеете программировать, изучение концепций API и структурирования данных (например, JSON) позволит вам создавать мощную автоматизацию, комбинируя инструменты No-Code/Low-Code (Zapier, Make и т.д.) с ИИ.

Стратегия для компаний: Организационный дизайн, нативный для ИИ

Для компаний недостаточно просто «раздать аккаунты ChatGPT». Необходимы инвестиции в инфраструктуру, такие как реинжиниринг всех бизнес-процессов с учетом ИИ (BPR: Business Process Re-engineering), создание безопасной среды RAG и тонкая настройка (fine-tuning) локальных моделей с использованием уникальных корпоративных знаний. Также требуется внедрение новых KPI для оценки способностей сотрудников к оркестровке ИИ.

Социальные рецепты: ИИ-инфраструктура как общественное благо

На государственном и общественном уровне необходимы системы социальной защиты и образования, чтобы третий цифровой разрыв не привел к серьезному экономическому неравенству и социальной нестабильности. Примерами могут служить государственная поддержка исследований и разработок ИИ-моделей с открытым исходным кодом (Open Source) и введение обязательного обучения «критической ИИ-грамотности» в образовательных учреждениях. Кроме того, на повестку дня должно быть вынесено надлежащее правовое регулирование и обновление антимонопольного законодательства для предотвращения «монополизации моделей ИИ и вычислительных ресурсов» со стороны технологических гигантов.

8. Заключение: Оседлать волну эволюции или быть поглощенным ею

«Новый цифровой разрыв», вызванный генеративным ИИ, перестраивает наше общество быстрее и масштабнее, чем любые технологические инновации в прошлом. Этот разрыв проявляется в виде разницы в аппаратных вычислительных ресурсах, инвестиционных возможностях в облачные API и, что самое главное, в «когнитивных и логических навыках оркестровки ИИ».

Как показывает эффект Матфея в продуктивности, этот разрыв со временем будет увеличиваться до такой степени, что преодолеть его станет невозможно. То, что мы должны сделать сейчас, — это не бояться эволюции ИИ и не верить в него слепо. Мы должны глубоко понять характеристики ИИ как величайшего в истории человечества усилителя интеллекта (Intelligence Amplifier) и осуществить «интеллектуальную самотрансформацию», обновляя свое мышление и рабочие процессы.

Остаться на этой стороне нового цифрового разрыва или оказаться на той? Этот выбор зависит от нашего ежедневного обучения и действий прямо сейчас.

Пожалуйста, оставляйте свои комментарии к этой статье и конкретные примеры внедрения оркестровки ИИ в разделе комментариев или в социальных сетях автора.