Как создать программу без программиста: 70 лет экспериментов от Черепашки и Дракона до вайбкодинга

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

---

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

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

Сегодня концепция вайбкодинга и всеобщего программирования транслируется отовсюду. Создается обманчивое впечатление, что этот тренд родился вместе с ChatGPT, хотя корням идеи уже почти семьдесят лет. В мае 1959 года по инициативе Пентагона был сформирован комитет CODASYL, объединивший экспертов бизнеса и американского оборонного ведомства, включая Грейс Хоппер. Перед ними стояла задача разработать COBOL — ориентированный на бизнес-процессы язык с синтаксисом, приближенным к разговорному английскому. Задумка заключалась в том, чтобы рядовые сотрудники могли писать простые программы, а руководители — свободно их читать. В те времена компьютеры занимали целые залы, а софт вводился с помощью перфокарт.

COBOL прошёл сквозь десятилетия и по сей день обеспечивает работу банковских структур и госорганов. Тем не менее язык, задуманный предельно прозрачным для менеджеров, в итоге потребовал узких профессионалов: когда в 2020 году государственным ведомствам США потребовалось экстренно обработать лавинообразный рост запросов на пособия, найти квалифицированных COBOL-разработчиков оказалось крайне сложно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На каждом шаге неизбежно возникает задача, которую платформа разрешить не в состоянии.

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

По мере усложнения система начинает вести себя непредсказуемо, и отладка превращается в лотерею. Графическая стрелочка на схеме не отобразит состояние гонки потоков (race condition) или взаимную блокировку (deadlock). Разбираться приходится инженеру, которому достаётся чужая, зачастую неоптимальная визуальная логика: её первоначальный автор просто не обладал достаточной квалификацией, из-за чего схема изобилует лишними элементами.

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

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

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

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

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

С распространением 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, используется миллионами детей по всему миру. Он прививает базовое алгоритмическое мышление без мучительного изучения синтаксиса и успешно функционирует благодаря строгим ограничениям: ребёнок физически не может «сломать» язык, при этом легко осваивая циклы, условные операторы и принципы параллелизма.

Простые внутренние инструменты. Создание дашбордов для отдела продаж, панелей обработки заявок или форм сбора данных. Начиная со старого доброго Microsoft Access и заканчивая современными low-code платформами, подобные задачи решаются за считанные часы. Здесь нет распределенных транзакций, гонок состояний или сложного кастомного UX, поэтому визуальный подход не успевает упереться в технологический потолок сложности.

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

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

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

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

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

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

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

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

 

Источник