Английская версия этой статьи ранее была опубликована мной в LinkedIn. Для Habr я подготовил адаптированную версию, добавил исторический контекст и подробнее раскрыл главный тезис.

Краткое содержание

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

• Джон Бэкус и команда FORTRAN перенесли работу программиста от машинных инструкций к формулам, циклам и условиям.

• Генеративный ИИ сделал программный код дешёвым и практически мгновенным.

• Главным дефицитом становится точное и целостное описание продукта: его целей, процессов, интерфейсов, данных, ограничений и поведения при сбоях.

• Следующая среда разработки будет работать с моделью цифровой системы, из которой код, тесты, инфраструктура и документация смогут создаваться автоматически.

---

Есть фотография из ранней истории вычислительной техники, к которой я мысленно возвращаюсь снова и снова.

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

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

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

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

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

Настоящий скачок происходил в тот момент, когда менялся сам язык разговора.

«Рукопашный бой с машиной»

В начале 1950-х программирование научных расчётов требовало почти механического перевода математической задачи в длинную цепочку машинных операций.

Джон Бэкус называл эту работу «рукопашным боем с машиной».

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

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

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

В те годы такое предложение звучало крайне смело.

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

Команда Бэкуса потратила около трёх лет на разработку языка и оптимизирующего компилятора. В 1957 году пользователи IBM 704 получили первую рабочую версию FORTRAN.

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

IBM приводит показательный пример: задача, требовавшая до тысячи машинных инструкций, могла быть описана 47 инструкциями на FORTRAN.

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

Именно здесь произошло главное.

Бэкус изменил единицу человеческой работы

FORTRAN часто описывают как один из первых широко используемых языков высокого уровня. Такое определение верно, хотя оно слабо передаёт масштаб события.

Главным изобретением стала новая единица работы программиста.

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

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

Повысилась производительность труда. Расширился круг людей, способных создавать программы. Снизилась стоимость разработки. Учёные и инженеры получили возможность выражать свои задачи напрямую.

У этой революции была важная экономическая причина.

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

Компиляция изменила это уравнение.

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

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

Сложность сохраняется. Она получает новую организацию, автоматизацию и систему контроля.

Эта оговорка особенно важна сегодня.

Код перестаёт быть дефицитом

После FORTRAN тот же исторический рисунок повторялся много раз.

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

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

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

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

Центр притяжения всё равно остаётся прежним: исходный код.

Замысел продукта обычно живёт в других местах:

• в протоколах встреч;

• в макетах интерфейсов;

• в схемах;

• в задачах трекера;

• в таблицах;

• в переписке;

• в документах;

• в памяти отдельных сотрудников;

• в устных договорённостях, которые участники проекта поняли по-разному.

Инженеры собирают эти фрагменты и переводят их в исполняемую форму.

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

Генеративный ИИ сделал эту слабость особенно заметной.

Модель способна написать сотни строк за несколько секунд. Она создаёт функции, компоненты, запросы к базе данных, тесты и конфигурационные файлы.

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

Узкое место перемещается.

Теперь главный вопрос звучит примерно так:

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

ИИ способен быстро написать реализацию.

Качество результата напрямую зависит от качества ответа на этот вопрос.

Разве промпт уже не стал новым языком программирования?

Это естественное возражение.

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

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

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

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

У организации появляется код. Целостная модель продукта при этом отсутствует.

Скорость растёт быстрее понимания.

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

Компилятор Бэкуса переводил формулы в машинные инструкции.

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

Следующий момент Бэкуса

Мне кажется, мы приближаемся к ещё одному изменению уровня абстракции.

Рабочей единицей станет цифровая система как целое.

Человек будет описывать:

• цели;

• участников;

• состояния;

• решения;

• бизнес-правила;

• процессы;

• интерфейсы;

• сущности данных;

• ограничения;

• права доступа;

• внешние механизмы;

• сценарии ошибок;

• критерии правильности.

ИИ-агенты и компиляторы смогут превращать эту семантическую модель в исполняемую реализацию.

Изменится и профессиональный центр тяжести.

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

В разработке возникнет похожая роль.

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

Я использую для этой роли название Code Designer — дизайнер кода или дизайнер цифровых систем.

Его основной материал — структура работающего продукта.

Какой должна быть новая среда

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

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

Редактор кода начинает работу после принятия множества важнейших продуктовых решений.

Новой среде придётся объединить эти разорванные части.

Она должна:

• сохранять исходное намерение;

• показывать связи и зависимости;

• позволять исследовать систему на разных уровнях;

• поддерживать симуляцию сценариев;

• генерировать реализацию;

• проверять результат;

• хранить историю решений;

• связывать каждый видимый элемент с кодом и работающим сервисом;

• обновлять всю модель при изменении её части.

В такой среде интерфейс, логика и данные перестанут существовать как три отдельных мира.

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

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

Сложность никуда не исчезнет

Здесь легко попасть в ловушку красивой футуристической картинки.

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

История абстракций говорит о другом.

Компиляторы не уничтожили сложность процессоров. Объектно-ориентированные языки не уничтожили сложность архитектуры. Облачные платформы не уничтожили сложность инфраструктуры.

Каждый новый уровень переносил часть сложности в платформу и создавал новые способы её контролировать.

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

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

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

Язык для проектирования работающих систем

Подобные переходы почти всегда выглядят сомнительно в самом начале.

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

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

ИИ уже умеет писать код.

Теперь решающим становится другой вопрос:

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

Бэкус дал программистам дистанцию от процессора.

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

Именно этот сдвиг уровня абстракции сейчас ждёт своего часа.

---

Источники и материалы для дальнейшего чтения

1. IBM — история FORTRAN

2. IBM — Джон Бэкус

3. John Backus — The History of FORTRAN I, II, and III

4. John Backus — Can Programming Be Liberated from the von Neumann Style?

5. ACM — John Backus, Turing Award