1. Когда код перестаёт быть обязательным

Традиционное программирование можно представить как последовательность преобразований:

Человек
  ↓
Алгоритм
  ↓
Исходный код
  ↓
Компилятор
  ↓
Машинный код
  ↓
Исполнение

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

В вычислениях, основанных на намерении (Intent-Based Computing), эта предпосылка перестаёт быть единственной. Вместо последовательности инструкций система получает совокупность условий:

Намерение
+ Данные
+ Ограничения
+ Доступные способности (Capabilities)
+ Политики
+ Критерии верификации
              ↓
   Семантическое представление
              ↓
     Вычислительный граф
              ↓
         Исполнение

Человек сообщает, какого результата необходимо достичь. Система сама определяет, каким именно вычислением этот результат получить.

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

Поэтому язык программирования не исчезает. Он поднимается на уровень абстракции.

Вместо:

сделай A
затем B
если C — выполни D

появляется описание:

получи X
при условиях Y
с ограничениями Z
и достигни качества Q

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

2. От библиотеки к capability: что происходит с GitHub

GitHub, менеджеры пакетов и вся экосистема библиотек держатся на одном фундаментальном предположении:

Кто-то должен заранее написать программный компонент, сохранить его и дать другим возможность его использовать.

Типичная цепочка выглядит так:

Человек
 ↓
Репозиторий
 ↓
README
 ↓
Документация
 ↓
Библиотека
 ↓
Интеграция
 ↓
Приложение

Агентная система способна её радикально сократить:

Человек
 ↓
Намерение
 ↓
Обнаружение способностей (Capability Discovery)
 ↓
Сгенерированный граф
 ↓
Верификация
 ↓
Исполнение

Человеку больше не обязательно искать библиотеку, читать README, выбирать пакет, писать glue code и собирать приложение. Ему нужна capability — проверенная способность выполнить определённый класс операций.

Например:

Capability:
    normalize_document

Вход:
    структурированный документ

Выход:
    нормализованный документ

Ограничения:
    сохранить семантику
    сохранить таблицы

Разрешения:
    чтение документа

Верификация:
    структурная эквивалентность

Такой объект гораздо ближе к потенциальному машинному языку будущего, чем традиционная библиотека. Причём capability — это не обязательно код. Она может включать специализированную модель, алгоритмический примитив, retrieval-контур, инструмент, адаптер, набор правил, проверенный workflow или комбинацию нескольких вычислительных компонентов.

В пределе описание вычисления выглядит так:

Намерение
Знания
Данные
Модели
Способности (Capabilities)
Ограничения
Политики
Верификация

А система сама определяет, какое представление этой совокупности окажется наиболее эффективным для конкретной задачи. Это уже не классическое программирование. Это семантическая сборка вычисления.

Значит ли это, что GitHub исчезнет?

Не обязательно.

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

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

Поэтому GitHub может постепенно превратиться из рынка исходного кода в рынок проверяемых вычислительных возможностей. А затем часть этого рынка вообще может оказаться не нужна. Если система способна самостоятельно синтезировать типовую capability, человеку нет смысла искать готовый репозиторий. Он обращается к спецификации, системе верификации и механизму генерации.

Исходный код появляется уже после этого — если он вообще необходим.

И тогда главный вопрос действительно меняется:

Не где находится исходный код, а какими свойствами обладает вычислительная способность и почему мы должны ей доверять?

Ответом становится происхождение (provenance):

Способность (Capability)
   ↓
Происхождение
   ↓
Верификация
   ↓
Идентичность
   ↓
Разрешения
   ↓
История

Доверие перестаёт быть характеристикой интерфейса и становится частью самого вычислительного объекта.

3. Программа становится процессом, а не файлом

Традиционная программа — относительно стабильный артефакт:

Исходный код
 ↓
Бинарный файл
 ↓
Запуск

После компиляции бинарный файл может использоваться тысячи или миллионы раз.

В новой модели вычисление способно постоянно перестраиваться:

Намерение
   ↓
Граф
   ↓
Исполнение
   ↓
Телеметрия
   ↓
Повторная оптимизация
   ↓
Перекомпиляция
   ↓
Исполнение
   ↺

Система может обнаружить, что один узел графа слишком медленный. Другой расходует чересчур много энергии. Новая модель даёт более точный результат. Иной NPU оказывается быстрее. Часть задачи выгоднее выполнить локально. Другую часть — дешевле отправить в облако. Изменились входные данные. Появился новый алгоритм. Изменились требования к качеству.

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

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

• модель;
• алгоритм;
• порядок операций;
• уровень точности;
• инструмент;
• место исполнения;
• структуру памяти;
• способ декомпозиции задачи;
• число промежуточных вычислений;
• критерий проверки.

Происходит важный переход:

Классический компилятор оптимизирует программу, а новый вычислительный компилятор может выбирать саму программу.

Именно здесь начинается наиболее радикальное изменение.

4. От языка инструкций к языку ограничений

Современные языки программирования в конечном счёте описывают последовательность операций. Даже высокоуровневый код постепенно превращается в более низкие представления:

Человеческое намерение
     ↓
Исходный код
     ↓
AST
     ↓
Промежуточное представление
     ↓
Машинный код

Возможная архитектура будущего выглядит иначе:

Намерение
   ↓
Семантическое представление
   ↓
Возможные вычисления (кандидаты)
   ↓
Оценка
   ↓
Оптимизация
   ↓
Аппаратно-специфичный граф
   ↓
Исполнение

Здесь язык перестаёт быть исключительно языком инструкций. Он становится языком целей, ограничений и критериев качества.

Например, вместо реализации:

для каждого документа:
    извлечь таблицы
    нормализовать значения
    сравнить строки
    сгенерировать отчёт

система получает спецификацию:

Цель:
    сравнить финансовые документы

Ограничения:
    сохранить семантику источников
    не изменять оригиналы

Качество:
    обнаружить расхождения выше порога

Приватность:
    чувствительные данные остаются локально

Результат:
    верифицированный отчёт о сравнении

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

5. Трансформер становится частью компилятора

Здесь возникает наиболее важный технологический сдвиг.

Современный компилятор получает программу и преобразует её:

Исходный код
      ↓
Компилятор
      ↓
Оптимизированный бинарный файл

Трансформерный компилятор потенциально работает иначе:

Намерение
   ↓
Семантическое представление
   ↓
Графы-кандидаты
   ↓
Оценка
   ↓
Оптимизация
   ↓
Аппаратно-специфичное исполнение

Модель здесь не просто генерирует текст. Она может участвовать в выборе самого вычисления. Для одной задачи она выберет алгоритмический путь А, для другой — путь B, для третьей — обнаружит, что готовый инструмент лучше синтезированной реализации.

После исполнения система получает обратную связь:

Результат
 ↓
Верификация
 ↓
Телеметрия
 ↓
Оптимизация
 ↓
Новый граф

Возникает замкнутый цикл. Именно поэтому понятие Transformer-Native Computing интереснее, чем просто «программирование с помощью ИИ». Речь не о том, что человек перестал писать код вручную. Речь о том, что вычислительная система сама становится участником компиляции.

6. Исчезновение glue code

Огромная часть современного программирования вовсе не является созданием новых алгоритмов. Это соединение уже существующих систем:

API
 ↓
Адаптер
 ↓
Парсер
 ↓
База данных
 ↓
Бизнес-логика
 ↓
Ещё одно API

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

Если вычислительная система сама понимает:

«возьми эти данные, преобразуй их в эту структуру, проверь условие и передай результат туда»,

значительная часть glue code становится временным промежуточным представлением. Исчезает не только ручное написание программы — исчезает необходимость сохранять программу после того, как задача выполнена.

Это один из главных механизмов перехода к эфемерному программному обеспечению (Ephemeral Software).

7. Непрерывная машинная оптимизация

Традиционная программа имеет версию:

v1.0
 ↓
v1.1
 ↓
v2.0

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

Система наблюдает:

Задержка
Энергопотребление
Точность
Стоимость
Память
Частота отказов

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

Например:

Намерение A

День 1:
Модель A → GPU → Облако

День 30:
Модель B → NPU → Локально

День 100:
Модель C → Гибридный граф

При этом пользователь продолжает формулировать одно и то же намерение. Меняется способ его вычисления.

Это похоже на то, как современный процессор скрывает от программиста огромный объём микроархитектурной оптимизации. Только теперь объектом оптимизации становится не отдельная инструкция, а весь вычислительный процесс. В результате программа перестаёт быть окончательным артефактом. Она становится гипотезой о том, как лучше выполнить задачу прямо сейчас.

8. Что тогда происходит с профессией программиста

Здесь особенно легко сделать ошибочный вывод: «Программисты исчезнут». Вероятнее другое — разделение труда изменится.

Сегодня бóльшая часть прикладной разработки находится между человеческим требованием и машинным исполнением:

Требование
      ↓
Программист
      ↓
Исходный код
      ↓
Компьютер

Если промежуточный слой синтезируется автоматически:

Требование
      ↓
Намерение / Спецификация
      ↓
AI-компилятор
      ↓
Вычисление

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

Архитектура
Безопасность
Верификация
Предметная экспертиза
Политики
Проектирование способностей (Capability Design)
Системные ограничения

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

Он проектирует не каждую функцию. Он проектирует:

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

Это напоминает исторический переход от ручного управления станком к проектированию автоматизированного производства.

9. Код остаётся там, где цена ошибки высока

Полностью отказываться от исходного кода было бы ошибкой. Чем выше требования к воспроизводимости и формальной проверке, тем ценнее явная реализация.

Код особенно долго сохранится в областях, где необходимо доказать:

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

Поэтому будущее не выглядит как «CODE → ZERO». Скорее:

КОД
 ↓
одно из нескольких представлений

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

10. Новая точка контроля: не код, а capability

Если исходный код перестаёт быть главным объектом, возникает вопрос: где теперь концентрируется власть?

В старой модели контроль распределён примерно так:

ОС
 ↓
Приложение
 ↓
Библиотека
 ↓
Код
 ↓
Пользователь

В новой архитектуре он может сместиться:

Идентичность
   ↓
Политика
   ↓
Способность (Capability)
   ↓
Состояние (State)
   ↓
Вычисление

Ключевым становится не вопрос «Какой код у тебя установлен?», а:

«Какие вычислительные возможности тебе доступны?»

Именно capability становится новой единицей контроля. Платформа, управляющая набором capabilities, способна контролировать гораздо больше, чем платформа, управляющая магазином приложений. Если одна компания определяет, какие модели доступны, какие инструменты разрешены, какие данные можно использовать, какие агенты имеют идентичность и какие действия допускаются policy engine, она фактически контролирует пространство возможных вычислений.

Поэтому конец тяжёлого софта вовсе не означает конец платформенной власти. Он может привести к её концентрации на ещё более глубоком уровне.

11. От монополии приложений к монополии вычислительного пространства

Это важная поправка к тезису о закате Microsoft, Google и других крупных платформ. Исчезновение традиционного приложения не уничтожает монополию автоматически — она просто может переместиться.

Сегодня пользователь привязан к:

Приложение
Формат
Операционная система
Магазин приложений

Завтра он может быть привязан к:

Модель
Идентичность
Реестр способностей (Capability Registry)
Формат состояния
Система политик
Инференс-инфраструктура

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

модели + способности + идентичность + состояние + верификацию + вычислительную инфраструктуру.

Именно поэтому переход к Intent-Based Computing является не только технологическим, но и экономическим сдвигом.

12. Что останется от GitHub

В конечном итоге GitHub не обязательно должен исчезнуть. Может исчезнуть его сегодняшняя необходимость. Репозиторий сегодня отвечает на вопрос: «Где находится программа?» В новой архитектуре важнее другие вопросы:

«Что эта способность умеет?»

«Какие данные ей нужны?»

«Какие права она требует?»

«Кто её проверил?»

«На каких данных и моделях она была создана?»

«Каковы ограничения её применения?»

«Как доказать воспроизводимость результата?»

Поэтому будущая система распространения вычислений может выглядеть уже не как:

Репозиторий
    ↓
Клонирование
    ↓
Сборка
    ↓
Установка

а как:

Реестр способностей (Capability Registry)
       ↓
Доверие / Происхождение
       ↓
Проверка политик
       ↓
Композиция
       ↓
Оптимизация времени исполнения

Исходный код при этом никуда не исчезает. Он просто перестаёт быть обязательной единицей распространения вычислительной способности.

13. После исходного кода

Если собрать обе части вместе, возникает довольно необычная картина.

Первая часть показала исчезновение обязательного приложения:

Приложение
      ↓
Эфемерное ПО

Вторая — исчезновение обязательного исходного кода:

Исходный код
      ↓
Семантическое представление

Дальше исчезает и идея фиксированной программы:

Программа
      ↓
Адаптивное вычисление

А вместе с ней меняется роль компилятора:

Компилятор
      ↓
Непрерывный вычислительный оптимизатор

Получается новая последовательность:

Человеческое намерение
      ↓
Семантическая спецификация
      ↓
Выбор способностей (Capability Selection)
      ↓
Синтез вычисления
      ↓
Верификация
      ↓
Исполнение
      ↓
Телеметрия
      ↓
Оптимизация
      ↺

В этой архитектуре человек больше не обязан заранее описывать весь путь от намерения до результата. Он задаёт цель, ограничения и критерии приемлемости. Машина выбирает путь.

14. Что действительно может исчезнуть

Наиболее вероятная трансформация выглядит не как внезапная смерть программирования, а как постепенное исчезновение нескольких привычных объектов.

Сначала перестаёт быть обязательным приложение. Затем перестаёт быть обязательной ручная интеграция. Затем уменьшается необходимость в исходном коде как пользовательском артефакте. Затем часть библиотек превращается в способности (capabilities). Затем компиляция превращается в непрерывный процесс синтеза и оптимизации.

И наконец меняется сама единица программирования.

Сегодня мы думаем: «Как написать программу?» В новой архитектуре вопрос постепенно становится другим:

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

Это уже не просто новый способ писать software. Это другая модель вычислений.

15. 2031: что должно быть видно, если этот прогноз верен

Прогноз имеет смысл только в том случае, если его можно попытаться опровергнуть. К 2031 году тезис о переходе к Intent-Based Computing будет выглядеть убедительно лишь при наличии нескольких наблюдаемых признаков.

Первый: локальный Guard или аналогичный контур управления способностями и политиками станет обычным элементом массовых вычислительных устройств, а не экспериментальной архитектурой.

Второй: агентская идентичность и управление полномочиями станут стандартной частью enterprise-инфраструктуры, сопоставимой по значимости с идентичностью человека и сервисного аккаунта.

Третий: генеративные интерфейсы (generative UI) станут рабочим инструментом в реальных продуктах, а не только демонстрационной функцией.

Четвёртый: значительная часть прикладного программного обеспечения будет создаваться агентами динамически, а не распространяться исключительно как заранее собранные приложения.

Пятый: способности (capabilities) и семантические спецификации начнут использоваться как самостоятельные объекты разработки и аудита.

Если ничего этого не произойдёт, а генеративные системы останутся главным образом ассистентами, пишущими код для традиционного software stack, — значит, описанная здесь архитектурная смена парадигмы не состоялась. И это вполне возможный исход.

Заключение: после программы

За последние полвека компьютерная индустрия несколько раз меняла то место, где сосредоточена сложность.

Сначала человек управлял машиной напрямую. Потом появились языки программирования. Затем операционные системы спрятали железо. Графические интерфейсы спрятали операционные системы. Облачные платформы спрятали инфраструктуру.

Теперь модели начинают скрывать сам процесс создания программы.

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

Более глубокий переход выглядит иначе:

Компьютер перестаёт ждать заранее написанную программу и начинает синтезировать вычисление вокруг намерения.

Приложение становится временным. Интерфейс — генеративным. Состояние — независимым от приложения. Код — одной из возможных промежуточных форм. Компиляция превращается в непрерывную оптимизацию. А программирование постепенно смещается от написания инструкций к проектированию намерений, ограничений, способностей и критериев проверки.

Возможно, именно здесь заканчивается эпоха «тяжёлого софта». Не потому, что программ станет меньше. А потому, что программа перестанет быть главным объектом вычислительной системы.

Главным объектом станет способность машины преобразовывать состояние мира под воздействием человеческого намерения. И тогда компьютер будет выглядеть уже не как набор установленных программ. Он будет выглядеть как вычислительная среда, которая каждый раз заново собирает себя вокруг задачи.