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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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