70 лет без программиста: история от COBOL до нейросетей и вайбкодинга

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

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

Мечта о доступной разработке: от COBOL до «второй грамотности»

Идея о том, что писать инструкции для машин смогут не только узкие специалисты, возникла еще в середине прошлого века. В 1959 году был инициирован проект COBOL — языка, чей синтаксис напоминал обычный английский. Создатели рассчитывали, что руководители компаний смогут самостоятельно читать такой код, а начинающие сотрудники — быстро осваивать написание программ. На практике же COBOL, на котором до сих пор функционируют многие финансовые системы, стал вотчиной редких профессионалов. В 2020 году в США возник острый дефицит специалистов этого профиля, когда потребовалось экстренно обновить государственные системы выплат.

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

Согласно прогнозам аналитиков Gartner, к 2029 году до 80% компаний будут использовать low-code платформы для создания критически важных приложений. Однако рост популярности таких инструментов не приводит к исчезновению профессии программиста, а лишь меняет границы его ответственности.

Попытки визуализации: от детской черепашки до космического ДРАКОНа

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

Особое место занимает язык ДРАКОН, созданный в 1986 году для космической программы «Буран». Его основной целью была наглядная коммуникация между инженерами разных отраслей. ДРАКОН-схемы строятся по жестким эргономическим правилам, исключающим пересечение линий, что делает алгоритм легко читаемым. Инструмент до сих пор востребован в медицине (для описания клинических рекомендаций) и атомной энергетике (для тренажеров операторов ядерных установок). Он выжил как язык описания логики, позволяющий человеку сохранять контроль над сложными процессами.

Эпоха Visual Basic и ловушка быстрого интерфейса

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

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

Современный no-code и скрытые сложности автоматизации

Актуальные low-code и no-code платформы позволяют ускорить создание типовых модулей на 50–70%. Однако при попытке реализовать сложную бизнес-логику заказчики часто сталкиваются с непредвиденными препятствиями. Платформа может предложить готовую кнопку, но она не может спроектировать оптимальный пользовательский путь или предусмотреть сценарии отказа.

Основные проблемы возникают на этапах:

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

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

Нейросети и концепция вайбкодинга

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

Отчет GitClear за 2025 год демонстрирует, что доля скопированных строк кода в мировых репозиториях выросла до 12,3%, одновременно увеличился объем кода, который переписывают сразу после создания. Исследование Uplevel показало, что использование ИИ-ассистентов вроде GitHub Copilot может привести к росту числа багов на 41% при отсутствии заметного ускорения в долгосрочных проектах.

Модели ИИ часто успешно справляются с изолированными задачами, но в 63% случаев ошибаются при сложном рефакторинге (по данным CodeScene). Нейросеть не владеет бизнес-контекстом и архитектурными ограничениями конкретного проекта. Человек без технической базы не способен эффективно отладить сгенерированный код, что снова возвращает профессионального разработчика к роли контролера.

Причины устойчивости профессионального программирования

Феномен возвращения программиста к управлению автоматизированными инструментами объясняется тремя фундаментальными факторами:

Когнитивные ограничения

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

Экономические барьеры

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

Технологическая разобщенность

В отличие от текстовых языков, имеющих общую инфраструктуру (Git, CI/CD, системы контроля версий), визуальные среды часто изолированы друг от друга. Логику невозможно легко перенести из одной платформы в другую. Даже в «вайбкодинге» промпты и контекст чатов не всегда проходят через стандартные циклы версионирования, что затрудняет понимание замысла при коллективной работе.

Ниши, где визуальный подход доказал эффективность

Несмотря на критику, визуальные инструменты успешно применяются там, где сложность систем остается управляемой. Это касается обучения (среда Scratch), создания простых внутренних инструментов (отчеты, формы сбора данных) и автоматизации интеграций между сервисами (Zapier, Make). Также визуальность естественна в профессиональных творческих средах: дизайн интерфейсов в Figma или проектирование уровней через Unreal Blueprints.

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