Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Вечное обещание: история попыток искоренить программистов

up7

Опубликовано 22 января 2026 г.Автор: ivan.turkovic
Оглядываясь на историю программного обеспечения, я замечаю одну закономерность, которая проявляется с поразительной последовательностью: обещание упростить создание программного обеспечения, сделать его дешевле и, в конечном итоге, полностью исключить необходимость в программистах. Это не новая идея. Она является движущей силой нашей отрасли с 1960-х годов. И хотя каждое поколение считает, что является свидетелем чего-то беспрецедентного, на самом деле они участвуют в цикле, который повторяется уже более шести десятилетий.

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

Первородный грех: COBOL и мечта бизнес-пользователя
История начинается в конце 1950-х годов, когда программирование было поистине архаичным. Программисты писали на языке ассемблера или машинном коде, напрямую манипулируя регистрами и адресами памяти. Эта работа требовала глубоких технических знаний и была мучительно медленной. Бизнесу требовалось программное обеспечение, но люди, которые понимали бизнес-проблемы, редко понимали компьютеры, а люди, которые понимали компьютеры, редко понимали бизнес-проблемы.

В дело вступили Грейс Хоппер и комитет CODASYL. В 1959 году они создали COBOL, общий язык, ориентированный на бизнес. Их очевидная цель была революционной: создать язык программирования, настолько близкий к английскому, чтобы руководители предприятий могли читать, понимать и, в конечном итоге, писать на нём сами. Синтаксис был намеренно многословным. Вместо загадочных символов COBOL использовал такие слова, как MOVE, ADD, MULTIPLY и PERFORM. Программа читалась почти как бюрократическая записка.

Маркетинговая стратегия была ясна: COBOL устранит узкое место, связанное с нехваткой квалифицированных программистов. Бизнес-аналитики будут писать собственные программы. «Жречество» технических экспертов будет распущено. Создание программного обеспечения станет доступным для всех.

Всё сложилось иначе.

up7

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

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

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

В 1965 году Герберт Саймон, один из основателей исследований в области искусственного интеллекта, предсказал, что в течение двадцати лет машины смогут выполнять любую работу, которую может выполнять человек. В 1967 году Марвин Мински, еще один пионер в области ИИ, предсказал, что в течение одного поколения проблема создания искусственного интеллекта будет в значительной степени решена. Финансирование поступало в больших объемах. Государственные агентства, особенно DARPA в Соединенных Штатах, вкладывали значительные средства в исследования в области ИИ.

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

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

К середине 1970-х годов вмешалась реальность. Доклад Лайтхилла 1973 года нанес сокрушительный удар по финансированию ИИ в Соединенном Королевстве, систематически выявив разрыв между обещаниями и достижениями в области ИИ. В докладе отмечалось, что ранние успехи в узких областях породили нереалистичные ожидания. Системы, работавшие над упрощенными задачами, потерпели неудачу в реальных сложных задачах. Взрыв комбинаторных возможностей перегрузил вычислительные ресурсы того времени.

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

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

up7

Языки четвертого поколения: перспективы 1980-х годов
К началу 1980-х годов появилась новая надежда: языки четвертого поколения, или 4GL. Аргументация была заманчивой. Язык ассемблера относился к первому поколению. FORTRAN и COBOL — ко второму. Структурированные языки, такие как Pascal и C, — к третьему поколению. Четвертое поколение должно было абстрагироваться от еще большей сложности, позволяя непрограммистам создавать приложения с помощью высокоуровневых объявлений, а не процедурного кода.

Такие продукты, как FOCUS, NOMAD, Ramis, а позже PowerBuilder и Microsoft Access, обещали произвести революцию в разработке программного обеспечения. Вместо написания кода пользователи должны были определять структуры данных, задавать бизнес-правила и проектировать экраны с помощью графических интерфейсов. Базовый код генерировался бы автоматически.

Маркетинговые материалы были поразительно похожи на то, что мы слышим сегодня о платформах без кода. Конечные пользователи будут создавать свои собственные приложения. ИТ-отделы станут скорее помощниками, чем узкими местами. Время разработки сократится в десять и более раз.

Языки программирования 4-го поколения (4GL) добились реального успеха в определенных областях. Благодаря этим технологиям быстрее создавались отчеты, простые приложения для работы с базами данных и инструменты для различных отделов. В частности, Microsoft Access позволил миллионам пользователей создавать функциональные приложения без традиционного программирования.

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

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

up7

CASE Tools и строители соборов
В конце 1980-х и начале 1990-х годов произошел расцвет инструментов автоматизированного проектирования программного обеспечения (CASE). Идея была всеобъемлющей: смоделируйте всю систему с помощью диаграмм и спецификаций, и инструменты сгенерируют полноценные, работающие приложения.

Компании инвестировали миллионы в наборы CASE-инструментов. Проводились конференции. Разрабатывались методологии. Обещание состояло в том, что разработка программного обеспечения наконец-то станет настоящей инженерией, с предсказуемыми результатами, повторяемыми процессами и автоматической генерацией кода на основе спецификаций.

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

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

К середине 1990-х годов CASE-инструменты в значительной степени утратили свою популярность. Некоторые концепции сохранились в инструментах объектно-ориентированного анализа и проектирования, таких как Rational Rose, но грандиозная идея автоматической генерации кода на основе спецификаций оказалась иллюзорной.

up7

Вторая волна ИИ: переосмысление экспертных систем.
В 1980-е годы также наблюдалась вторая волна энтузиазма в отношении ИИ, сосредоточенная на экспертных системах. Такие компании, как Inference Corporation, Intellicorp и Teknowledge, обещали использовать человеческий опыт в системах, основанных на правилах, которые могли бы принимать решения так же эффективно, как и эксперты-люди.

Области применения были весьма привлекательными: медицинская диагностика, финансовый анализ, настройка оборудования и, конечно же, автоматическое программирование. Системы, подобные R1/XCON, разработанные компанией Digital Equipment Corporation, действительно добились успеха, сэкономив компании миллионы долларов за счет автоматической настройки компьютерных систем.

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

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

Вторая «зима искусственного интеллекта» наступила в начале 1990-х годов. Снова финансирование сорвалось. Снова исследователи переименовали свои работы. Снова фундаментальная перспектива создания машин, способных программировать себя, отошла на второй план.

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

Но веб-пространство быстро стало сложнее. JavaScript добавил интерактивности. CSS добавил стилизацию. Программирование на стороне сервера стало необходимым. Базы данных стали основой для контента. Безопасность стала критически важной. Производительность стала конкурентоспособной.

Реакция была предсказуемой: появились новые инструменты, обещающие упростить веб-разработку. Dreamweaver, FrontPage, а позже WordPress и Wix обещали, что любой сможет создавать профессиональные веб-сайты без программирования. Системы управления контентом абстрагировали сложность процесса.

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

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

Архитектура, управляемая моделями, и мечта об UML
В начале 2000-х годов была предпринята еще одна попытка автоматической генерации кода с помощью архитектуры, управляемой моделями (Model-Driven Architecture, MDA). Группа по управлению объектами предложила преобразовывать платформенно-независимые модели в реализации, специфичные для конкретной платформы, с помощью автоматизированных инструментов.

Унифицированный язык моделирования (UML) стал стандартной нотацией. Такие инструменты, как Rational Rose, Together и Enterprise Architect, обещали создавать полноценные приложения на основе UML-диаграмм. Концепция была знакомой: моделируйте свою систему на высоком уровне абстракции, а инструменты позаботятся о деталях реализации.

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

К 2010-м годам концепция MDA (Master of Decision-Advanced) утратила свою актуальность в практическом применении, хотя её принципы оказали влияние на современные методы генерации кода и предметно-ориентированные языки программирования.

Возрождение технологий без кода и с минимальным кодированием
Примерно с 2015 года появилось новое поколение платформ без кода и с минимальным использованием кода. Такие названия, как Bubble, Webflow, Airtable, Zapier и Microsoft Power Platform, обещали дать возможность разработчикам-любителям создавать приложения с помощью визуальных интерфейсов и компонентов, размещаемых методом перетаскивания.

Маркетинг повторял обещания всех предыдущих поколений. Бизнес-пользователи будут создавать собственные приложения. Задержки в ИТ-сфере исчезнут. Цифровая трансформация ускорится. Программисты станут ненужными или, по крайней мере, гораздо менее востребованными.

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

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

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

up7

Крупные языковые модели: современная тенденция
Это приводит нас к настоящему моменту. Крупные языковые модели, такие как GPT-4, Claude и Gemini, могут генерировать функциональный код на основе описаний на естественном языке. GitHub Copilot и аналогичные инструменты помогают разработчикам в режиме реального времени, предлагая варианты автозавершения и генерируя шаблонный код. Улучшения действительно впечатляют.

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

Мы это уже слышали. В 1959 году, с COBOL. В 1973 году, с экспертными системами. В 1985 году, с языками программирования 4-го поколения. В 1995 году, с CASE-инструментами. В 2015 году, с программированием без кода.

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

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

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

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

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

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

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

up7

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

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

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

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

Уроки истории
Какие выводы следует сделать из этой истории, чтобы успешно осваивать нынешнюю волну инструментов разработки на основе искусственного интеллекта?

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

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

Во-третьих, характер работы программиста будет продолжать меняться. Точно так же, как программисты на COBOL выполняют другую работу, чем программисты на языке ассемблера, а веб-разработчики — другую, будущие разработчики будут выполнять другую работу, чем нынешние. Работа изменится, но она не исчезнет.

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

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

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

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

Инструменты меняются. Языки программирования меняются. Платформы меняются. Но потребность в людях, которые глубоко понимают, что они создают и почему, остается неизменной.

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

up7

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

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

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

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

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