Почему идея «программировать без программиста» живёт 70 лет
В мае 1959 года в Пентагоне собрался комитет CODASYL: представители бизнеса и Министерства обороны США, среди них Грейс Хоппер. Комитет создавал COBOL, язык для бизнес-задач с синтаксисом, похожим на обычный английский. Разбор этой истории начинается с того же эпизода, и он задаёт рамку всем последующим попыткам.
Семьдесят лет спустя обещание звучит знакомо: опиши задачу словами, а код появится сам. В 1959 году ставка была на английский синтаксис, в 1980-х на «черепашку» Logo и визуальные схемы, в 1990-х на перетаскивание форм в Visual Basic, в 2010-х на low-code и no-code платформы, сейчас на LLM и вайбкодинг. Сценарий повторяется: инструмент снимает часть рутины, будь то синтаксис, вёрстка форм, типовые модули или генерация кода, и упирается в работу, которую делает человек.
Работа одна и та же во всех поколениях: решить, что строить, спроектировать логику и состояния, заметить, что система ведёт себя не так, как задумано, и направить её в нужную сторону. Пока эти задачи не решены, программист возвращается к рулю, даже если формально перестал набирать код вручную.
Тема родилась не вместе с ChatGPT. Массовой идея «программировать сможет каждый» стала с LLM, но сама постановка вопроса старше чат-ботов на десятилетия.
Три причины, по которым программист возвращается
Когнитивная. Визуальные схемы и генераторы прячут то, что нужно держать в голове: состояния системы и потоки данных. С LLM нагрузка смещается: писать стало быстрее, а читать и проверять чужой код приходится больше. Голова человека остаётся единственным местом, где сходится картина целиком.
Экономическая. Платформа снижает стоимость старта и повышает стоимость выхода. Модель данных, права, интеграции и логика живут в чужом формате, и переезд считается отдельным проектом с бюджетом и сроком.
Технологическая. У визуальных сред нет общей инфраструктуры: язык схем у каждого свой, переносить нечего. У вайбкодинга другая беда: ответ LLM недетерминирован, а промпты редко версионируют рядом с кодом, поэтому воспроизвести результат через месяц получается не всегда.
Причины работают вместе. Инструмент скрывает состояние (когнитивная), закрепляет это скрытие контрактом с вендором (экономическая) и не даёт повторить поведение (технологическая). Дальше это видно на конкретных этапах.
COBOL: язык, который должен был отменить программиста, но создал дефицит специалистов
Расчёт создателей COBOL был простым: код на почти английском прочитает руководитель, а напишет начинающий программист. Ожидания зафиксированы прямо в истории языка: писать смогут новички, читать код - менеджеры.
Язык пережил десятилетия: на нём до сих пор работают банки и госучреждения. И тот же язык, задуманный понятным для менеджеров, потребовал редких специалистов: в 2020 году, когда штатам пришлось срочно обрабатывать поток заявок на пособия по безработице, программистов на COBOL оказалось очень трудно найти.
Причина в разнице между читаемостью и пониманием. Строка ADD AMOUNT TO TOTAL читается как английская фраза, но за ней стоят структуры данных, режимы округления, блокировки записей и правила, по которым бухгалтерия живёт десятилетиями. Руководитель прочитает строку и не увидит ни одного из этих слоёв.
Что COBOL автоматизировал, а что оставил людям
Автоматизировал приближённый к английскому синтаксис описаний и типовых бизнес-операций: чтение записи, арифметику с фиксированной точкой, печать отчёта. Код стал ближе к формулировке задачи, чем ассемблер, и за счёт этого писать стало дешевле.
Оставил людям постановку задачи, выбор структур данных, сопровождение legacy-систем и разбор инцидентов. Ошибка округления в расчёте пособия или потерянная запись при пакетной обработке не находятся чтением текста программы. Нужен человек, который знает, где искать, и умеет воспроизвести сбой.
Logo, «вторая грамотность» и мечта научить программировать всех
Logo и «черепашка» сделали следующий шаг: убрали текст программы с первого плана и показали результат движения на экране. Команда движения рисует линию, ребёнок видит связь между своим решением и картинкой. Синтаксис перестал быть барьером, алгоритм остался.
Взрослая версия этой идеи прозвучала в 1981 году. Андрей Ершов, один из основателей советского системного программирования и создатель Сибирской школы информатики, представил доклад «Программирование - вторая грамотность» на Всемирной конференции ИФИП (IFIP) и ЮНЕСКО в Лозанне. Исторический разбор цитирует его сравнение: печать когда-то сделала грамотность всеобщей, значит и умение программировать должно стать навыком каждого человека.
«Вторая грамотность» для Ершова означала способность мыслить алгоритмически, планировать и предвидеть последствия своих решений. Путь к этому он видел через школу. Формулировка 1981 года до сих пор объясняет, зачем детей учат циклам и условиям: не ради синтаксиса, а ради способа думать.
Чему учит Scratch сегодня и при чём тут взрослые инструменты
Scratch работает по логике Logo: блоки избавляют от точек с запятой, зато требуют разбить задачу на шаги и отладить поведение. Ребёнок, который собрал движение спрайта по лабиринту, уже прошёл через постановку задачи, разбиение на шаги и поиск места, где спрайт застревает.
Навык переносится на взрослые инструменты. В n8n, Zapier, Make и Power Automate блоки те же: триггер, условие, действие. Ошибка в сценарии ловится не компилятором, а поведением: письма ушли не тем адресатам или сценарий зациклился и выжег лимит запусков. Человек, который не умеет разложить процесс на шаги и предвидеть ветвления, будет ломать автоматизацию на любой платформе.
Проверяемых цифр о влиянии Scratch на карьеру в доступных материалах нет, поэтому ограничусь механикой: среда снимает синтаксис, навык декомпозиции остаётся.
ДРАКОН и Visual Basic: визуальные схемы против состояний и потоков данных
Визуальное программирование старше персональных компьютеров: ранние среды вроде Sketchpad показывали, что с машиной можно работать через чертёж на экране. Советский ДРАКОН перенёс идею в прикладную плоскость: алгоритм описывается схемой, где ветвления и циклы нарисованы. Visual Basic в начале 1990-х добавил перетаскивание элементов формы: кнопка, поле, обработчик события.
Что получилось: вёрстка форм перестала занимать день. Что осталось: логика, обработка ошибок, интеграции. Кнопка «Сохранить» рисуется за секунду, а что происходит при потере связи, повторном нажатии или пустом поле, среда не подскажет.
Почему наглядная схема не равна понятной системе
Схема показывает поток управления: сюда идём при истинном условии, отсюда возвращаемся. Состояния она не показывает. Сколько записей в очереди, что лежит в кэше, в каком порядке пришли ответы от двух сервисов, какие данные устарели, всё это живёт вне картинки.
При росте системы схема теряет главное преимущество. На двадцати блоках она читается, на двухстах похожа на схему метро без легенды, и отладка всё равно идёт через логи, точки останова и просмотр данных. Когнитивная причина возврата программиста срабатывает именно здесь: человеку нужна модель состояния, а визуальный язык даёт модель управления.
Low-code и no-code платформы: экономика вендор-лока
Платформы low-code и no-code упаковали предыдущие уроки в продукт: формы, таблицы, права доступа, интеграции и типовые модули уже готовы. Заказчик или аналитик собирает внутренний инструмент без отдельной команды разработки, и на старте это честная экономия.
Про рынок: в исходном разборе упоминаются оценки Gartner по low-code, но конкретных цифр в доступном фрагменте нет, поэтому подставлять их из памяти не буду. Важнее структура расходов, а не размер рынка: подписка, настройка, доработки и стоимость выхода.
Где no-code реально экономит время
Простые внутренние инструменты: заявки, согласования, учёт, дашборд для отдела. Автоматизация и интеграции: n8n, Zapier, Make, Power Automate переносят данные между сервисами и запускают действия по событию. Профессиональные визуальные среды: Figma для дизайнеров и разработчиков, Unreal Blueprints для игровой логики. Четыре разные задачи с общим признаком: ограниченная область и понятные состояния.
Границы видны там же, где у COBOL: сложная логика с десятком исключений, нестандартные требования, высокая нагрузка, специфические права. Платформа упирается в свой набор блоков, а обход через внешний код возвращает вопрос сопровождения.
Экономическая причина возврата программиста и есть вендор-лок. Логика, данные и права живут в чужом формате, экспорт отдаёт часть, а не систему. Смена тарифа, закрытие продукта или рост цен превращаются в проект миграции, который никто не планировал. Считать совокупную стоимость владения и план выхода стоит до первого блока на канве, а не после.
Вайбкодинг с LLM: генерация кода упирается в чтение и проверку
LLM убрали последний барьер: код появляется из описания на естественном языке. Скорость генерации выросла, и вместе с ней вырос объём кода, который кто-то должен прочитать. Узкое место сместилось со ввода символов на ревью.
Замеры спорят друг с другом. По данным, которые приводит разбор влияния ИИ-ассистентов на разработку, GitHub фиксирует 56% ускорения сборки MVP, а сложные задачи замедляют опытных разработчиков на 19% и растят дублирование кода в 8 раз за год.
Автор исходной статьи добавляет свои цифры: GitClear проанализировал 211 млн строк кода, сравнение Uplevel на примерно 800 разработчиках показало рост багов на 41% у пользователей Copilot, бенчмарк CodeScene дал около 37% корректного рефакторинга без проверки и около 98% с ней. Первоисточники в разборе раскрыты не полностью, так что цифры стоит читать как ориентир, а не как приговор инструментам.
Технологическая причина возврата проявляется именно здесь. Ответ модели недетерминирован: та же подсказка в другой день даёт другой код. Промпты редко лежат рядом с кодом в репозитории, поэтому через месяц никто не скажет, чем получен конкретный файл и как его перегенерировать. У визуальных сред проблема была обратной: артефакт существовал, но был заперт в платформе.
Проверка кода, сгенерированного ИИ: что именно проверять
- Граничные случаи: пустой ввод, максимальные значения, отсутствие сети, повторный вызов.
- Обработка ошибок: что видит пользователь, что попадает в логи, не глотается ли исключение.
- Состояния и переходы: не появилось ли состояние, из которого нет выхода.
- Безопасность: секреты в коде, права на эндпоинты, валидация входных данных, зависимости из недоверенных источников.
- Соответствие требованиям: делает ли код то, что просили, а не то, что поняла модель.
- Воспроизводимость: можно ли повторить поведение на другой машине и через месяц.
Проверка меняет результат радикально: те же около 37% корректности без неё и около 98% с ней в бенчмарке CodeScene. Гигиена простая: хранить промпты и версию модели рядом с кодом, фиксировать конфигурацию, держать диффы маленькими, чтобы ревью оставалось чтением, а не расследованием.
Где визуальные и no-code подходы действительно прижились
Список ниш устойчив: обучение (Scratch), простые внутренние инструменты, автоматизация и интеграции (n8n, Zapier, Make, Power Automate), профессиональные визуальные среды (Figma, Unreal Blueprints). Общий признак: ограниченная область, понятные состояния и быстрый цикл проверки.
Figma и Unreal Blueprints: почему профессионалы принимают визуальное
Figma прижилась благодаря общему файлу: в одном месте лежат макет, спецификации и разговор дизайнера с разработчиком. Вёрстку она не заменила, зато сократила число переводов требований. Blueprints в Unreal дают геймдизайнеру собрать логику уровня без правки C++, и это работает, пока логика остаётся уровнем: событие, условие, анимация. За пределами этой области начинается код, и студии возвращаются к нему без драмы.
Визуальное здесь дополняет код, а не отменяет проектирование. Разница между профессиональной визуальной средой и обещанием «заменить программиста» в том, что первая честно очерчивает область, а второе заявляет универсальность.
Критерии выбора инструмента: видно, можно поменять, проверить и откатить
Пять вопросов экономят месяцы. Их стоит задать до того, как первый проект уехал в прод.
- Видно ли, что происходит внутри. Логи, трассировки, доступ к данным, понятная модель состояний. Если платформа показывает только результат, разбор сбоя превращается в гадание.
- Можно ли поменять. Своя логика в обход блоков, собственные интеграции, доступ к API и данным.
- Можно ли проверить. Тесты, воспроизводимое окружение, версионирование промптов и конфигураций.
- Можно ли откатить. Экспорт данных, история версий, план миграции, отсутствие закрытых форматов на критичном пути.
- Есть ли за платформой человек, который разбирается в деталях. Поддержка, отвечающая по существу, а не присылающая статью из базы знаний.
Критерии закрывают три причины возврата программиста по очереди. Видимость и проверяемость лечат когнитивную. Экспорт и план миграции лечат экономическую. Версионирование промптов и воспроизводимость лечат технологическую.
Для тех, кто работает с локальными LLM и AI-агентами, вопросы звучат конкретнее. Кто читает диффы, которые генерирует агент, и по каким тестам видно, что он не сломал соседний модуль? Где лежат описания инструментов и память агента, можно ли их откатить? Сколько времени уходит на ревью, если генерация занимает минуты? Дешевеет именно генерация, а не ответственность за результат: подробный разбор этой асимметрии есть в материале про код, который подешевел, но не ускорил разработку.
Второй вывод касается проектирования. Если код пишет модель, ценность смещается к тому, кто формулирует требования, строит модель данных и задаёт границы. Архитектурное мышление становится узким местом разработки: агенту нужны контракты и спецификации, иначе он угадывает.
Третий вывод про роли. Порог входа упал, делать продукты для одного пользователя стало выгодно, и граница между разработчиком, дизайнером и продактом размывается. Инструмент при этом не снимает вопрос, кто отвечает за поведение системы в проде.
Проверять инструмент стоит на своей задаче и своём масштабе: собрать один реальный сценарий, намеренно его сломать и замерить время на диагностику, правку и откат. Ответ на эти три вопроса точнее любого обещания, что программировать сможет каждый.