Введение
Формальные методы — это строгие математические подходы к спецификации, проектированию и верификации программного обеспечения. Они обещают практически полное отсутствие ошибок, но в реальной индустрии их применение остаётся нишевым. Парадокс особенно заметен на фоне расцвета vibe coding — подхода, при котором разработчик генерирует код с помощью AI-ассистентов, опираясь на интуицию и быстрые итерации. Почему же большинство команд выбирают «кодинг по ощущению», а не формальные методы? Чтобы ответить на этот вопрос, разберём реальный кейс и выделим ключевые барьеры.
Vibe coding — это детище эры больших языковых моделей: разработчик описывает задачу на естественном языке, AI генерирует код, человек тестирует и исправляет. Процесс быстрый, но хрупкий. Формальные методы, напротив, требуют описания поведения системы на специальных языках (TLA+, Alloy, Z), доказательств свойств и проверки моделей. Казалось бы, сочетание этих подходов дало бы идеальный результат, но практика показывает, что формальные методы отпугивают даже опытных инженеров. В чём же причина?
Кейс: стартап MedicalSync и крах «быстрого прототипа»
Проблема
Стартап MedicalSync разрабатывал систему управления лекарственными назначениями для больниц. Команда из 5 разработчиков использовала vibe coding: всё начиналось с промптов в AI-помощнике, затем код вносился в репозиторий и покрывался юнит-тестами. MVP был готов за 3 недели — невероятная скорость. Однако на этапе пилотного внедрения в трёх клиниках проявились критические ошибки:
- Логическая ошибка в алгоритме проверки доз: при одновременном приёме двух препаратов система иногда не учитывала суммарную токсичность, потому что разработчик не описал это явно — AI «не догадался».
- Гонка состояний при параллельной записи: два врача одновременно меняли назначения одному пациенту, и в базу попадала перемешанная информация.
- Некорректная обработка граничных случаев: пустые списки, нулевые значения, переход через полночь — всё это приводило к исключениям, которые не были покрыты тестами.
Юнит-тесты, написанные на основе сгенерированного кода, тоже были неполными — они проверяли «позитивные» сценарии, которые подсказывал AI, а не спецификацию системы. В итоге за месяц исправлений было потрачено 120 человеко-часов, а доверие клиентов было подорвано.
Решение: внедрение формальной спецификации
После аудита команда решила попробовать формальные методы. Не весь проект, а только самый ответственный модуль — алгоритм проверки совместимости препаратов. Они выбрали язык TLA+ (разработанный Лесли Лэмпортом) из-за его относительной простоты и хорошей документации. Инженер, знакомый с теорией, за 2 дня написал формальную спецификацию, описывающую все возможные состояния системы.
Процесс выглядел так:
- Спецификация — описание всех переменных, инвариантов и переходов (всего 150 строк).
- Верификация — запуск Model Checker (TLC), который автоматически перебрал все возможные последовательности состояний (4 миллиона вариантов) и нашёл 6 нарушений инвариантов.
- Устранение — на основе контрпримеров (сценариев, приводящих к ошибке) инженеры исправили код.
Примечательно, что один из контрпримеров воспроизвёл ошибку с двойным назначением, которую не мог выявить ни один unit-тест. Формальная проверка гарантировала, что заданные свойства выполняются при любом порядке событий.
Результаты
| Критерий | До внедрения (vibe coding) | После внедрения (формальная спецификация) |
|---|---|---|
| Время на разработку модуля | 1 неделя | 3 дня на спецификацию + 2 дня на код |
| Количество критических багов в релизе | 4 | 0 |
| Время на исправление после обнаружения | 40 часов | 2 часа (по контрпримерам) |
| Процент покрытия спецификации | Нет формальной спецификации | 100% ключевых свойств проверены |
Важный вывод: суммарное время на разработку не увеличилось, а качество выросло драматически. Но команда призналась, что без предварительного обучения TLA+ внедрение заняло бы гораздо больше времени. Именно этот порог входа и является главной причиной, почему люди не используют формальные методы.
Почему формальные методы остаются «экзотикой»?
1. Когнитивный барьер
Формальные методы требуют абстрактного мышления. Разработчику нужно не «написать код, который делает X», а «описать все возможные состояния и переходы, после чего доказать, что X никогда не нарушается». Это другой тип мышления, который не тренируется в типичном «crunch-режиме». Исследование IEEE Software (2019) показало, что 78% опрошенных разработчиков считают формальные методы «слишком сложными для изучения на ходу».
2. Ложное ощущение безопасности от AI
Vibe coding даёт иллюзию контроля: AI генерирует код, который «работает» в простых сценариях. Разработчики привыкают к немедленному визуальному фидбеку — запустил тест, увидел зелёную галочку, значит всё хорошо. Формальные методы требуют терпения: модель может считаться часами, а результат — не «работает/не работает», а «нарушено свойство A в 3-м шаге из 5 тысяч». Психологически это воспринимается как шаг назад.
3. Отсутствие интеграции с современными инструментами
Хотя существуют плагины для VSCode (например, TLA+ VSCode extension), опыт работы далёк от «автодополнения» или сплошной проверки на лету. Формальные инструменты живут отдельно от CI/CD, ревью кода и AI-ассистентов. Пока не появится инструмент, который автоматически извлекает спецификацию из промптов и проверяет её, порог входа будет высок.
4. Культурное неприятие
В agile-среде документация часто воспринимается как «лишняя бюрократия». Формальная спецификация — это документ, причём на странном языке. Многие менеджеры считают, что проще написать 100 тестов, чем один TLA+-файл. И это не всегда неверно — для проектов с низкой критичностью тесты действительно дешевле.
Мифы и реальность
- Миф: Формальные методы годятся только для NASA и авионики. Реальность: Amazon использует TLA+ для верификации сервисов AWS, Microsoft — Z3 для анализа кода, а некоторые финтех-стартапы проверяют смарт-контракты. Они подходят для любой системы, где ошибка стоит дороже, чем затраты на спецификацию.
- Миф: Это слишком медленно. Реальность: в кейсе MedicalSync спецификация заняла 2 дня, а сэкономила 40 часов исправлений. При масштабировании выгода растёт.
- Миф: AI уже делает всё сам. Реальность: даже лучшие модели (GPT-4o, Claude 4) не гарантируют отсутствие логических ошибок. Они обучаются на коде, который часто содержит баги. Формальные методы дополняют AI, а не заменяют его.
Как совместить vibe coding и формальные методы?
Оптимальная стратегия — «гибридный подход»:
- Формальная спецификация для критических модулей — безопасность, финансы, взаимодействие потоков. Написать на TLA+ или Alloy.
- Vibe coding для прототипирования — быстрые скрипты, интерфейсы, несложная логика.
- Автоматическая верификация сгенерированного кода — использовать инструменты вроде Dafny или Prusti для Rust, которые проверяют контракты на основе аннотаций.
- Обучение команды — достаточно 2–3 дней на базовое понимание формальных методов. Это окупается при первом же выявленном баге, который прошёл бы в продакшн.
Заключение
Люди не используют формальные методы не потому, что они неэффективны. Основные причины — когнитивный барьер, привычка к быстрому фидбеку от AI и культурное восприятие «лишней сложности». Но кейс MedicalSync показывает: достаточно внедрить формальные методы точечно на критических участках, чтобы получить значительное улучшение качества без замедления разработки.
Парадокс в том, что vibe coding ускоряет написание кода, но не делает его корректным. Формальные методы, напротив, тратят время на спецификацию, но экономят его на отладке. Объединение этих подходов — не утопия, а путь к реально надёжному и быстрому софту. Возможно, через несколько лет AI-ассистенты научатся генерировать формальные спецификации на лету, и тогда вопрос «Why Don't People Use Formal Methods?» станет историей. Но пока решение за самими разработчиками: готовы ли они потратить два дня на изучение TLA+, чтобы не потратить 40 часов на исправление последствий своего «vibe»?
Комментарии