Черепашка, Дракон и вайбкодинг. 70 лет попыток обойтись без программиста

В 1959 году создатели COBOL надеялись, что код на нём смогут читать менеджеры. Потом были черепашка Logo, советский ДРАКОН, Visual Basic, no-code платформы, теперь нейросети. Новые инструменты забирали у человека часть рутины и каждый раз упирались в одно и то же: решать, что строить, замечать, когда система ведёт себя не так, и поворачивать её в нужную сторону приходилось людям. Под катом разбираю четыре больших обещания обойтись без программиста и разбираюсь, почему человек всегда оставался у руля.

Мечта старше, чем кажется

Меня зовут Диана Фионина и я работаю в экосистеме ИТ-продуктов Лукоморье ^[1], где мы развиваем no-code платформу Акола. А ещё я много лет занимаюсь взаимодействием человека и компьютера и продуктовой аналитикой, поэтому меня в истории no-code инструментов прежде всего интересует вопрос, где в каждой новой системе остаётся место для человека.

Сегодня идея, что с вайбкодингом программировать может каждый, звучит из каждого утюга. Кажется, что тема появилась вместе с ChatGPT, хотя ей почти семьдесят лет. В мае 1959 года в Пентагоне собрался комитет CODASYL из представителей бизнеса и Министерства обороны США, среди них была Грейс Хоппер. Он создавал COBOL ^[2], язык для бизнес-задач с синтаксисом, похожим на обычный английский. Предполагалось, что писать на языке смогут начинающие программисты, а читать код руководители. Компьютер тогда занимал комнату, программы набивали на перфокартах.

COBOL пережил десятилетия, на нём до сих пор работают банки и госучреждения. Однако язык, задуманный понятным для менеджеров, в итоге потребовал редких специалистов: в 2020 году, когда штатам пришлось срочно обрабатывать поток заявок на пособия по безработице, программистов на COBOL оказалось очень трудно найти ^[3].

Позже Андрей Ершов ^[4], один из основателей советского системного программирования и создатель Сибирской школы информатики, представил идею о массовом программировании под другим углом: он говорил о навыках программирования как о «второй грамотности». Именно так назывался его доклад — «Программирование — вторая грамотность» — на Всемирной конференции ИФИП (IFIP) и ЮНЕСКО в Лозанне в 1981 году.

Ершов сравнивал роль компьютера с книгопечатанием: когда-то печать сделала грамотность всеобщей, и умение программировать тоже должно было стать навыком каждого человека. Путь к этому он видел через школу: «вторая грамотность» для него означала умение мыслить алгоритмически, планировать и предвидеть последствия своих решений. Для достижения этих целей в последние годы жизни он строил школьную информатику и создавал инструменты для обучения ^[5] программированию. О них мы ещё поговорим в этой статье.

А теперь давайте посмотрим, что говорят аналитики: в 2021 году Gartner прогнозировала ^[6], что к 2025-му 70% новых приложений организаций будут использовать low-code или no-code технологии. А в отчёте 2024 года ^[7] Gartner уже говорится, что к 2029 году корпоративные low-code платформы будут применять для критически важных приложений 80% компаний, в 2024-м таких было 15%. Инструменты явно растут, программисты при этом никуда не делись, и это самое интересное в истории.

В инфополе no-code и нейросети показывают красивую картинку: менеджер собирает CRM в конструкторе за чашкой кофе, а всё, что не получилось мышкой, по запросу дописывает модель. Любой, кто сдавал проект заказчику, в этот момент спросит: что если система поймёт меня неправильно? Кто это заметит и поправит?

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

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

Обещание первое: сделать программирование наглядным

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

В 1963 году Айвен Сазерленд показал Sketchpad ^[8], программу из своей докторской диссертации. Она позволяла чертить световым пером прямо на экране и задавать связи между объектами. По сути это был прототип графического интерфейса, а сам Сазерленд стал одним из основателей области взаимодействия человека и компьютера и в 1988 году получил премию Тьюринга. Sketchpad показал, что с машиной можно говорить рисунком. Инженеры довольно быстро нащупали и обратную сторону: чем интуитивнее инструмент, тем меньше он умеет.

Через четыре года Сеймур Пейперт с коллегами ^[9] перенёс идею в школу. В языке Logo ребёнок командовал черепашкой на экране, писал «вперёд 100, поворот 90», и абстрактный цикл превращался в квадрат. Педагогически это было блестяще, трудности начинались, когда ученик хотел сделать настоящую игру или симуляцию: простой логики черепашки на такие задачи уже не хватало. Если бы кто-то всерьёз взялся писать на Logo ERP-систему, черепашка, подозреваю, просто сбежала бы.

Другой пример из Советского Союза. С середины 1980-х советские школьники учили алгоритмы на школьном алгоритмическом языке, который предложил Ершов. Сам язык был текстовым, с русскими словами. Наглядность давали учебные исполнители вроде Робота и Чертёжника: ученик писал команды, а исполнитель сразу показывал результат на экране. Сегодня те же Исполнители живут в среде КуМир ^[10], которую разработали в НИИСИ РАН, и на ней учат в школах. Исполнители снимали страх ^[11] перед первыми опытами, однако стоило перейти к задаче посложнее, и ученик снова терялся, потому что не понимал, в каком состоянии находится его программа. Эффект черепашки повторился.

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

ДРАКОН жив до сих пор, хотя и в нишевых профессиональных направлениях. Активнее всего он развивается в медицине: в 2025 году вышли статьи о его использовании для разработки клинических рекомендаций ^[12] и медицинских алгоритмов ^[13], с описанием инструментов и конкретных схем. На сайте ^[14]drakon.su ^[15] опубликован проект национального стандарта «Схемы алгоритмов и алгоритмических систем в здравоохранении и медицине». Владимир Паронджанов в журнале «Организация здравоохранения» пишет, что ДРАКОН вместе с программой ДРАКОН-конструктор «может играть роль стандарта» для алгоритмов действий врача в клинических рекомендациях.

А в 2021 году в журнале «Морской вестник» Г.А. Ершов, А.Б. Серебряков ^[16]и соавторы предложили описывать ДРАКОН-схемами действия операторов корабельных ядерных энергетических установок в аварийных ситуациях и строить на этом тренажёры. Всё это говорит о том, что язык продолжают развивать, хотя о масштабах внедрения судить сложно. Как платформа разработки он не прижился, зато как язык описания работает десятилетиями.

Из ранних экспериментов можно вынести общий урок: визуальные среды отлично работали в обучении и плохо переносились на производство, потому что за блоками никуда не девались состояния, потоки данных и обработка ошибок. ДРАКОН выжил, потому что делал логику ^[17] видимой, человек мог прочитать алгоритм, проверить его и поправить. Инструмент давал возможность людям контролировать систему и поэтому пережил свою эпоху.

Обещание второе: собрать мышкой

Следующий большой шаг сделал человек, которого сегодня чаще вспоминают как автора книг о проектировании интерфейсов. В конце 80-х Алан Купер работал над прототипом с кодовым названием Tripod ^[18], позже его переименовали в Ruby. Идея Купера состояла в том, что администратору, аналитику и кассиру нужны разные интерфейсы и собирать их должно быть легко. Microsoft купила разработку, соединила её визуальную часть с языком Basic, и в 1991 году появился Visual Basic.

Для своего времени это была революция. Формы собирались перетаскиванием, свойства настраивались в инспекторе, реакция ^[19] на клик писалась в пару строк, прототип можно было показать заказчику в тот же день. По оценке Gartner, Visual Basic занимал около 40% рынка инструментов разработки, а IDC в 1999 году насчитывала 7,2 млн его пользователей из 13,1 млн разработчиков ^[20].

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

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

При этом было бы нечестно записывать Visual Basic в чистые неудачи: идея интерфейса, который подстраивается под роль человека, живёт в современных no-code платформах. Дашборд для аналитика или форму для менеджера сегодня собирают за несколько дней и так же быстро подстраивают под новое направление бизнеса или сезонный спрос.

Обещание третье: собрать без кода

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

На каждом шаге всплывает решение, которое платформа принять не может.

Обычно всё начинается с макетов: заказчик или продакт рисует красивые экраны в Figma, и перенести их в визуальную среду действительно несложно. Но остаются вопросы: как будут переключаться состояния? Где хранятся данные? Что происходит при ошибке ^[21]? Платформа предлагает готовые блоки, но спроектировать пользовательский путь и бизнес-сценарий она за вас не может. В итоге интерфейс есть, но логика либо примитивна, либо хаотична. 

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

Параллельно заказчик приходит с новыми пожеланиями и требованиями, платформа при этом умеет ровно то, что предусмотрели её создатели. Нестандартное поведение ^[22] требует костылей или перехода на код, и обещание обойтись без программистов не срабатывает, порой из-за самого обычного требования.

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

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

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

Обещание четвёртое: попросить нейросеть

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

GitClear в отчёте 2025 ^[24] года проанализировала 211 млн изменённых строк кода за 2020–2024 годы. Доля скопированных строк выросла с 8,3% в 2021 году до 12,3% в 2024-м, авторы отмечают и рост кода, который переписывают вскоре после создания. Это сигналы о рисках для сопровождения, хотя сами по себе они не доказывают, что причиной всех изменений стали ИИ-ассистенты.

Uplevel сравнил около 800 разработчиков с доступом к GitHub Copilot и без него ^[25]. Заметного ускорения по времени и числу принятых pull request’ов не нашлось, зато доля багов у пользователей Copilot выросла на 41%. Есть и противоположные данные: в эксперименте самого GitHub разработчики с Copilot справились с типовой задачей на 55% быстрее. Похоже, многое зависит от вида задачи: изолированная задача в эксперименте и живой проект с историей и контекстом показывают разные результаты.

Самый показательный результат, на мой взгляд, у CodeScene. В раннем бенчмарке «Refactoring vs Refuctoring» ^[26] лучшая из исследованных моделей выполняла корректный рефакторинг примерно в 37% случаев. Когда к генерации добавили специализированную проверку, корректность принятых результатов выросла примерно до 98%. Модель хорошо делает черновик, а вот решать, что из него пойдёт в работу, должен кто-то, кто понимает систему и выстроил проверку.

Модель не знает вашего бизнес-контекста, архитектурных ограничений и UX-паттернов, у неё нет опыта человека, который годами поддерживает похожие системы. Человек без технического бэкграунда не сможет отладить то, что она сгенерировала. Снова история повторяется: заказчик надеется сэкономить на разработке и при первом сложном кейсе всё равно зовёт программиста разбираться в сгенерированном коде.

Почему программист каждый раз возвращается

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

Когнитивный. В визуальных инструментах блоки и стрелки прячут строгую логику состояний, потоков данных и обработки исключений. Рисовать нашему мозгу ^[27] легче, чем держать в голове большой граф зависимостей, и у этой лёгкости есть измеримый предел. Ян Мендлинг, Хайо Рейерс и Вил ван дер Аалст обобщили эмпирические исследования моделей бизнес-процессов ^[28] и пришли к выводу: если в модели больше 50 элементов, вероятность ошибки в ней обычно превышает 50%, поэтому такие схемы стоит дробить на части. Каждый, кто открывал UML-диаграмму с полусотней объектов, знает это ощущение. В другом исследовании ^[29] участникам показывали графы от 25 до 175 узлов. Нагрузка росла до определённого порога, а дальше падала, судя по всему, потому что люди просто сдавались.

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

С нейросетями когнитивная проблема меняет форму. Писать код больше не нужно, зато его приходится читать, проверять и держать в голове логику, которую ты не строил. Ощущение контроля здесь отчасти обманчиво, модель снимает нагрузку с рук и перекладывает её на внимание ^[30].

Экономический. Крупные вендоры вроде Microsoft и Salesforce строят low-code платформы как экосистемы, из которых сложно выбраться. Чем глубже клиент настроил платформу, тем прочнее он к ней привязан: переезд на другое решение или в классическую разработку означает переписывать почти всё. Это осознанная бизнес-модель с заработком на подписке, маркетплейсе расширений и консалтинге. Хороший пример даёт переход с Salesforce Classic на Lightning, который даже внутри одного вендора превращается в заметный проект по переделке интерфейсов и интеграций. По сути клиент отдаёт часть управления своей системой вендору. Бизнес это чувствует и опасается вкладываться в инструмент, который со временем начнёт диктовать свои условия. Проблема здесь в закрытости, сама идея визуальной разработки ни при чём.

Технологический. У текстовых языков есть общая инфраструктура: синтаксис, компиляторы, системы контроля версий, CI/CD. Визуальные среды живут каждая в своём мире, и перенести логику из одной платформы в другую практически невозможно. Человек не может спокойно сравнить версии, откатить изменение или забрать свою логику с собой, а значит, не до конца ею владеет.

С вайбкодингом картина интереснее. Результат здесь обычный код, он лежит в git и проходит через CI/CD, так что общая инфраструктура на месте. Зато настоящий исходник переехал в чат: замысел, контекст и промпты нигде не версионируются, а генерация недетерминирована, и тот же запрос завтра даст другой код. Можно увидеть, что изменилось, но вот понять логику уже сложнее.

Где прижились визуальные языки

Чтобы не создавалось впечатления ^[31], будто я везде вижу одни проблемы, добавлю ремарку про визуальные языки. Они стали массовыми, просто это случилось в узких и чётко очерченных нишах, куда их никто не продавал как замену программистам.

Обучение. Scratch, прямой наследник Logo, используют миллионы детей по всему миру. Он даёт алгоритмическое мышление ^[32] без мучений с синтаксисом и работает благодаря своим ограничениям: сломать язык ребёнок не может и спокойно осваивает циклы, условия и даже параллелизм.

Простые внутренние инструменты. Отчёт для отдела продаж, панель заявок, форма сбора данных. От старого доброго Access до современных low-code платформ такие вещи собираются за часы. Гонок состояний, распределённых транзакций и нестандартного UX здесь нет, и визуальность не успевает упереться в потолок сложности.

Автоматизация и интеграции. Power Automate, n8n, Zapier и Make стали стандартом для связывания сервисов. Сложность здесь измеряется числом интеграций и порядком действий, состояние системы почти не участвует. Поток данных на схеме читается нагляднее кода.

Профессиональные инструменты. Дизайнер рисует интерфейс в Figma, геймдизайнер собирает уровень в Unreal Blueprints, и это обычное разделение труда.

Общее правило простое: визуальность работает, пока человек может охватить систему одним взглядом. Пока граф линейный или слабо ветвится, схема помогает видеть и контролировать, когда он разрастается, та же схема начинает прятать самое важное. Если бы в 90-е кто-то предложил строить банковский core на Access, над ним бы посмеялись.

Вместо заключения

За 70 лет ни один инструмент не убрал из программирования человека: Visual Basic освободил от ручной вёрстки форм, no-code от рутины типовых модулей, нейросети берут на себя всё больше самого кода. Каждый раз граница сдвигалась, и всегда за ней оставалась одна и та же работа: решить, что строить и заметить, что система ведёт себя не так, затем направить её.

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

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

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