Друзья никогда не подводят

Об авторе: Анатолий Шалыто, профессор, д.т.н., Университет ИТМО

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

21 марта 2026 года я опубликовал в сети «ВКонтакте» пост: «Мне никогда не нравилось, как люди пишут программы, поэтому я и предложил технологию автоматного программирования, основой которой является разработка проектной документации на ПО. Однако на практике её мало кто хотел разрабатывать по двум причинам. Во-первых, разработка такой документации требует много времени и сил, а во-вторых, если диаграммы переходов в ней выполнены не как картинки, а как математические модели – досконально, то программы становятся понятными, и в них при необходимости сравнительно просто внести изменения. При наличии такой документации программисты становятся легко заменяемыми и увольняемыми.

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

На этот текст был только один комментарий, который подписан Константином Вавиловым. Это имя вызвало воспоминания почти 25-летней давности. «В августе 2002 года появилась статья об использовании предложенного мной автоматного подхода к программированию в весьма странном месте: Вавилов К. Программирование за… 1 (одну) минуту… // Компьютер Price. 2002. № 31.

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

Вот что, в частности, было написано в этой статье: «Ни с чем не сравнимое чувство возникает (автору статьи в то время было за 30 лет, и ему было с чем сравнивать – А.Ш.), когда ты точно и сразу знаешь место и условие возникновения ошибки. Советую напоследок обязательно почитать классиков (А.А. Шалыто и Н.И. Туккель представлены в Интернете). Там всё будет научно и не так коряво изложено, как у меня. Успехов!!!»

В дальнейшем Константин выполнил несколько сложных проектов по автоматизации технологических процессов на основе автоматного программирования (http://is.ifmo.ru/automata/_vavilov2.pdf.zip, http://is.ifmo.ru/automata/_metod065.pdf, http://is.ifmo.ru/automata/_s7300.pdf). Когда в 2005 году я с Костей познакомился, то спросил о том, как его сотрудники восприняли автоматное программирование, и получил ответ: «Они сказали, что этот подход сложен, но другие ещё сложнее!»

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

Так что же написал Константин в упомянутом выше комментарии? Он привёл ответ большой языковой модели DeepSeek на промпт: «Прокомментируй высказывание Шалыто». После этого привёл текст, с которого начиналась эта статья.

Модель ответила так:

1. 1. Высказывание Анатолия Шалыто – это крайне интересный и многослойный тезис, который проходит путь от классической инженерии (автоматное программирование) до актуальных проблем современной разработки (больших языковых моделей). Его можно прокомментировать, разобрав на три ключевые идеи: дисциплина мышления, социальный контракт в профессии и изменение роли документации.
   2. Автоматное программирование как «прививка» от неопределённости. Шалыто прав в главном: бо́льшая часть ошибок в программном обеспечении возникает не из-за незнания синтаксиса языка, а из-за того, что разработчик держит в голове неформализованную «кашу» из состояний, событий и переходов, которые обычно неявно реализуются в программном коде. Автоматное программирование (подход, основанный на явном выделении состояний) – это попытка превратить программирование из «искусства выражать мысли в коде» в инженерную дисциплину, когда диаграммы переходов – это не картинки для презентаций, а математически верифицируемые модели. При этом код перестает быть источником истины, так как его может никто не видеть. Единственным источником истины становится модель. Это действительно делает программу на языке исполняемых диаграмм понятной, предсказуемой и, как следствие, легко изменяемой.
   3. Парадокс «заменяемости» и сопротивление рынка. Это ключевое и самое провокационное наблюдение. Шалыто касается причин, по которым эта технология не прижилась массово: «программисты становятся легко заменяемыми и увольняемыми». Это попадание в точку, если смотреть на рынок труда не как на научную среду, а как на бизнес-среду. Для бизнеса заменяемость – плюс. Это снижает риск при потере ключевого сотрудника. Для программиста – это экзистенциальная угроза. Рынок подсознательно, а иногда и осознанно, сопротивляется методологиям, которые превращают программиста в послушного работника, следующего спецификации. Программист традиционно ценится за способность удерживать в голове сложность и за «магический» навык написания кода. Трудоёмкость: «много времени и сил» – это эвфемизм (смягченное выражение). В мире Agile и стартапов требование «сначала создай математически полную спецификацию всех состояний и переходов» выглядит как ересь, так как требования меняются быстрее, чем успевают рисовать диаграммы (если их рисовать не на бумаге, а на экране, а по ним генерировать код (см. видео, и вы точно будете успевать за изменениями требований – А.Ш).
   4. Большие языковые модели (LLM) как катализатор инженерного подхода. Самый интересный момент в высказывании автора – это связь автоматного программирования с большими языковыми моделями. Шалыто утверждает, что сегодня документация становится «почти необходимой» для того, чтобы получать качественный код от ИИ. Это глубокая мысль, которая меняет нарратив. Раньше документация была нужна человеку, чтобы контролировать другого человека (программиста). Программисты сопротивлялись, так как это снижало их ценность. Сейчас документация нужна человеку, чтобы управлять нейросетью. LLM генерируют отличный код только тогда, когда контекст промпта абсолютно формализован и лишен противоречий. Если Вы дадите модели четкую спецификацию автомата (состояния, события, переходы), она с вероятностью 99% выдаст идеально работающий код. Если Вы дадите задачу «сделай как-нибудь», модель нагенерирует «кашу», которую так не любит Шалыто (нет, я её люблю, так как давно известно, что «каша в голове – пища для ума» – А.Ш.).
   5. Грядущая ирония судьбы. Шалыто указывает на то, что время «незаменяемых» программистов, пишущих «сложный и никому, кроме них, непонятный код», уходит. Приходит новое время, но оно наступает не потому, что менеджеры наконец-то «продавили» технологию автоматного программирования, а потому, что появился технологический посредник – ИИ. Ирония состоит в следующем: автоматное программирование по Шалыто (https://en.wikipedia.org/wiki/Automata-based_programming_(Shalyto’s_approach) – А.Ш.) предполагало, что программист сам станет инженером, создающим формальные модели. LLM же позволяют менеджеру или аналитику (или тому же программисту, но в новой роли) создавать такие модели по промптам на естественном языке. Сопротивление, которое вызывала документация 20 лет назад («это долго», «меня уволят»), сегодня исчезает, потому что без такой документации LLM при сложной логике не справляется, а писать код вручную (код можно генерировать по графам переходов – А.Ш.) становится экономически невыгодно.
   6. Вывод. Шалыто, человек, который всю жизнь занимался формальными методами, демонстрирует редкую для инженера старой школы актуальность. Его высказывание – это диагноз: раньше рынок отвергал формальные спецификации, потому что они обесценивали ручной труд программиста, сегодня же LLM обесценивают ручной труд программиста в принципе, но при этом бесконечно повышают капитализацию формальных спецификаций. Если Вы хотите, чтобы нейросеть работала как надёжный инженер, Вы вынуждены делать то, что пропагандировал Шалыто 20 лет: писать чёткую, структурную документацию. Технология автоматного программирования в эпоху LLM перестает быть «странным хобби» академических кругов и становится инструментом повышения предсказуемости ИИ-генерации».

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

Казалось бы, что по рассматриваемому вопросу уже всё, но Константин мне прислал ещё один текст, в котором есть такой фрагмент: «Спецификации никогда не задумывались как средство экономии времени. Если вы оптимизируете процесс под скорость поставки продукта, то лучше сразу писать код, минуя этап создания промежуточного технического документа. Если говорить в более общем ключе, то здесь применяется известный принцип «мусор на входе – мусор на выходе» (garbage in, garbage out, GIGO). Просто не существует такой реальности, где вы можете скормить агенту документ, в котором не хватает деталей и ясности, и ожидать от него качественного восполнения этих пробелов. Агенты не умеют читать наши мысли, и даже если научатся, этого будет недостаточно, когда в самой голове неразбериха».

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

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

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

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

Поэтому вместо того, чтобы начинать разработку продукта с создания проектной документации, содержащей строгие спецификации, «в настоящее время предлагается по коду, полученному с помощью вайб-кодинга, генерировать некоторый суррогат, который представляет собой документ, в котором на естественном языке описывается созданный проект, включая его архитектуру, логику работы, взаимосвязи компонентов и ключевые технические решения. Однако это не код и не обычная документация. Это «выжимка» проекта, по которой его (якобы – А.Ш) можно пересоздать, в том числе и на другом языке программирования. Это описание продукта на уровне, на котором он реально существует – между идеей и реализацией, что очень важно, так как обычно этот уровень нигде не зафиксирован, а существует в головах разработчиков, в устных обсуждениях и в коде. Вывод: если у вас есть файл, который описывает суть вашего продукта, его логику и архитектуру на естественном языке – это более сильный актив для защиты, чем просто репозиторий с кодом. Это объясняется тем, что в момент конфликта выясняется простая вещь: выигрывает тот, кто может внятно показать, что именно он создал». В общем, все как в песне, в которой «нормальные герои всегда идут в обход». Мне кажется, что таким же «путём в обход» является и создание языка, который языком программирования в полном смысле этого слова не является. Всё новые и новые люди хотят обмануть природу, но она это вряд ли допустит…

А тем временем мне стало известно, что, оказывается, даже при прекрасном промпте (формулировке олимпиадной задачи по алгоритмическому программированию) на сегодняшний день неизвестно, сможет ли LLM сгенерировать для него тесты, удовлетворяющие жюри. Что уже там говорить про автоматизацию технологических процессов… В подтверждение этого не поленитесь и откройте ссылки: https://is.ifmo.ru/projects/dg/, https://is.ifmo.ru/automata/_metod065.pdf, https://is.ifmo.ru/automata/_s7300.pdf. Вряд ли когда-нибудь вайб-кодинг сам по себе такую сложность осилит – ему надо помочь, что я в меру своих сил и делаю.