Intent-Driven Software: когда исходником становится не код, а намерение

Представь обычную задачу:

Нужно добавить в систему роли пользователей.

Разработчик открывает редактор, запускает coding-агента и просит его создать таблицу ролей, middleware для проверки прав и несколько API-методов. Через полчаса код готов. Миграции написаны, тесты проходят, документация обновлена.

Технически всё работает.

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

Агент выполнил задачу правильно. Просто задача была неправильной.

Именно вокруг этой проблемы появился подход, который называют Intent-Driven Software или Intent-Driven Development. Его основная идея звучит почти банально: прежде чем описывать реализацию, нужно зафиксировать, зачем система меняется, какого результата мы хотим добиться и какие границы нельзя пересекать.

Но за этой простой формулировкой скрывается довольно заметный сдвиг в разработке.

Код больше не единственный источник истины

Долгое время окончательным ответом на вопрос «как работает система?» был код.

Документация могла устареть. Диаграмма архитектуры могла лежать в Confluence с 2019 года. Задача в трекере обычно описывала лишь небольшой кусок работы. Поэтому разработчик открывал репозиторий и разбирался по факту: читал обработчики, смотрел миграции, проходил по вызовам функций.

В эпоху coding-агентов этого уже недостаточно.

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

Intent-Driven Development предлагает поднять источник истины на уровень выше кода. В центре оказывается намерение: долговечное описание причин, желаемого поведения, контекста и ограничений. Спецификация, план реализации, код и тесты становятся производными артефактами.

Это не означает, что код теперь можно выбрасывать после каждого релиза. Скорее меняется направление движения:

намерение → решения → спецификация → реализация → проверка

А не наоборот, когда смысл системы приходится восстанавливать по уже написанным классам и таблицам.

Что такое намерение

Намерение — не красивое описание функции и не длинный промпт для агента.

Фраза «добавь роли пользователей» сообщает действие, но почти ничего не говорит о результате. Даже формулировка «реализуй RBAC» не намного лучше: она сразу навязывает конкретный механизм, хотя бизнес-задача может вообще не требовать классической ролевой модели.

Хорошо описанное намерение отвечает примерно на такие вопросы:

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

Например, задача с ролями могла бы начинаться так:

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

Здесь пока ничего не сказано о таблицах, middleware, JWT claims или формате API.

Зато уже видно, какое решение будет неправильным.

Глобальные роли не подойдут. Несовместимое изменение токенов тоже. Отсутствие аудита нельзя будет оправдать тем, что «в задаче об этом не написали». А сложный конструктор политик окажется не преимуществом, а лишней работой.

Именно это отличает намерение от пожелания: оно задаёт направление и одновременно ограничивает пространство допустимых решений.

Между вайб-кодингом и спецификацией на сорок страниц

Intent-Driven Software часто ставят между двумя крайностями.

Первая — vibe coding. Человек объясняет агенту идею в чате, получает реализацию, запускает её, находит проблему и пишет следующий промпт. Для прототипа такой процесс может работать отлично. Через несколько недель появляется другая проблема: важные решения остаются внутри старых диалогов, исправления наслаиваются друг на друга, а система постепенно отходит от первоначального замысла.

Вторая крайность — тяжёлый Spec-Driven Development, где перед реализацией создаётся подробная спецификация, план, список задач и набор сопутствующих документов. GitHub, например, развивает Spec Kit именно как инструментарий, в котором спецификация становится центральным артефактом AI-assisted разработки.

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

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

Intent-Driven подход предлагает фиксировать прежде всего то, чем действительно должен владеть человек:

Люди определяют, что имеет значение. Конкретный способ реализации можно выбирать ниже по цепочке.

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

Как выглядит работа от намерения

Допустим, команда разрабатывает экспорт отчётов.

Обычная задача могла бы выглядеть так:

Добавить экспорт отчёта в Excel.

Агент установит библиотеку, добавит endpoint и вернёт файл. Вероятно, он даже создаст аккуратную таблицу с заголовками.

Но настоящее намерение может быть другим:

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

Теперь перед нами совсем другая система.

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

После фиксации намерения агент может подготовить несколько вариантов реализации. Например:

фоновая задача и хранение файлов в объектном хранилище;
потоковая генерация без постоянного хранения;
разбиение экспорта на несколько файлов;
экспорт в CSV вместо XLSX для крупных наборов данных.

Человек выбирает компромисс. Затем решение превращается в техническую спецификацию, задачи, код и тесты.

На этапе ревью проверяется уже не только качество кода. Главный вопрос звучит иначе:

Эта реализация действительно выполняет исходное намерение?

Можно написать безупречный обработчик, который не решает пользовательскую проблему. Intent-driven ревью позволяет отклонить такой код не потому, что архитектору «не нравится подход», а потому, что результат расходится с зафиксированной целью.

Намерение должно жить рядом с проектом

Самая слабая версия Intent-Driven Software — создать файл INTENT.md, красиво заполнить его при старте проекта и больше никогда не открывать.

Через три месяца это будет ещё один исторический документ.

Намерение должно изменяться вместе с системой. Если во время реализации выяснилось, что отчёты на 500 тысяч строк никому не нужны, ограничение следует пересмотреть. Если совместимость со старыми токенами больше не требуется, это тоже нужно зафиксировать. Если команда сознательно выбрала eventual consistency вместо мгновенного обновления, решение не должно оставаться только в комментарии к pull request.

Для этого необязательно внедрять отдельную платформу. На первом этапе достаточно нескольких версионируемых артефактов:

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

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

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

Почему одного намерения недостаточно

Здесь легко увлечься и решить, что достаточно хорошо сформулировать цель, после чего агент сам построит правильную систему.

Не построит. По крайней мере, не всегда.

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

Кроме намерения системе нужны:

Контекст. Как устроен существующий проект, какие компоненты уже есть, какие соглашения приняты командой.

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

Контракты. API, события, схемы данных, правила взаимодействия модулей.

Проверки. Автоматические тесты, статический анализ, линтеры, нагрузочные сценарии, security review.

Обратная связь. Возможность сравнить реальное поведение с ожидаемым и вернуть результат на доработку.

Intent без проверок превращается в пожелание. Проверки без intent проверяют лишь то, что кто-то когда-то догадался закодировать в тестах.

Нужны обе части.

Что меняется в работе разработчика

При intent-driven подходе разработчик меньше времени тратит на механическое написание кода, но его работа не становится проще.

Наоборот, приходится точнее формулировать решения.

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

Разработчик всё чаще выступает в нескольких ролях сразу:

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

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

Где подход ломается

Intent-Driven Software можно испортить теми же способами, которыми команды портят почти любую методологию.

Намерение превращают в переименованное ТЗ

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

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

Пишут слишком общо

«Система должна быть быстрой, удобной и безопасной» не ограничивает вообще ничего.

Хорошее намерение позволяет принять решение. Вместо «быстрой» лучше написать, что пользователь должен увидеть результат поиска не позднее чем через 300 миллисекунд для 95% запросов. Вместо «безопасной» — какие данные нужно защищать и от каких действий.

Не фиксируют нецели

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

Иногда это полезно. Обычно — нет.

Не обновляют намерение после компромиссов

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

Подменяют проверку доверием

Фраза «агент знает, что делает» опасна ровно так же, как фраза «этот разработчик опытный, можно не смотреть его код».

Intent задаёт направление. Но выполнение всё равно нужно проверять.

Как попробовать Intent-Driven Software

Необязательно перестраивать весь процесс.

Возьми одну функцию среднего размера. Не критическую платёжную систему, но и не переименование кнопки. Перед реализацией создай короткий документ:

# Намерение

## Проблема
Какую реальную проблему мы решаем?

## Пользователь
Кто столкнулся с этой проблемой и в каком контексте?

## Желаемый результат
Что должно стать возможным после изменения?

## Ограничения
Что нельзя сломать или ухудшить?

## Критерии проверки
Как мы убедимся, что результат работает?

## Нецели
Что сознательно не входит в текущую работу?

## Открытые вопросы
Какие решения пока не приняты?

Затем попроси агента не писать код сразу, а сначала:

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

Уже на этом этапе обычно обнаруживается половина будущих проблем.

После реализации сравни результат с исходным документом. Не с последним сообщением в чате и не только с тестами. Если решение изменилось — обнови intent или зафиксируй отдельное архитектурное решение.

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

Начинать сразу с большой методологии не нужно.

Код не исчезает. Меняется его место

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

Метафора красивая, но пока слишком оптимистичная.

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

И это, пожалуй, главное изменение.

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

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

Она просто быстрее попадает в production.

Intent-Driven Software не избавляет от инженерии. Оно возвращает инженерию туда, где она всегда была нужнее всего: в понимание проблемы, выбор компромиссов и ответственность за итоговый результат.

#разработка #ии #intent_driven_software