Около 60% черновых требований в 35 внутренних проектах AWS пришлось дорабатывать ещё до того, как по ним начинали генерировать код. Для тех, кто уже привык обсуждать фичи в чате с агентом и получать реализацию «в один проход», это неприятная, но полезная цифра: анализ требований внезапно оказывается важнее очередной модели с более громким названием.
Об этом сообщает The New Stack в материале о новых возможностях Kiro, агентной среды разработки AWS. Главная новинка называется Requirements Analysis: система пытается поймать ошибки не в коде, а в спецификации, из которой этот код потом вырастает. По словам Майка Миллера, директора по AI Product Management в AWS, речь идёт о противоречиях, неоднозначностях и пробелах в требованиях, из-за которых разные разработчики понимают одну и ту же задачу по-разному. Дальше всё по классике: реализация, тесты, прод, а потом недельный сеанс археологии с вопросом, где именно всё пошло не туда.
Технически AWS делает ставку не на «ещё один LLM поверх LLM», а на связку из нейросимвольного подхода и формальных методов. Сначала модель переписывает слишком общие или расплывчатые формулировки в более проверяемый вид. Затем требования переводятся в формальную логическую модель, после чего в дело вступают SMT-решатели, класс инструментов из области automated reasoning, которым уже несколько десятилетий. Идея простая: не гадать, может ли система понять спецификацию правильно, а математически проверить, не противоречат ли требования друг другу и не оставляют ли они дыр в поведении системы.
В Kiro выделяют четыре типовых класса проблем. Первый: неверный уровень детализации, когда требование либо слишком абстрактно, либо, наоборот, уже диктует реализацию вместо ожидаемого поведения. Второй: неоднозначность, когда фраза допускает две интерпретации. Третий: несогласованность, когда два пункта по отдельности выглядят разумно, но вместе невыполнимы. Четвёртый: неполнота, когда для части входных данных или состояний системы поведение просто не описано. Это тот самый случай, когда команда думает, что «и так очевидно», а потом оказывается, что у каждого было своё «очевидно».
Проблема стала острее именно из-за генеративной разработки. В блоге Kiro приводятся исследования 2025 года: при мутации чётких промптов в неоднозначные, неполные или противоречивые Pass@1 падает на 20–40%, а 60–90% синтаксически корректного кода оказываются семантически неверными. Другая работа, на которую ссылается AWS, показывает ещё один неприятный эффект: если требования недоопределены, модели тихо достраивают недостающий смысл за пользователя, а такие промпты примерно вдвое чаще дают регрессии при смене модели или формулировки запроса. Код может компилироваться, тесты могут проходить, но система всё равно делает не то, что бизнес имел в виду.
Для рынка это важный сигнал. Большая часть AI-инструментов для разработки продаёт скорость: быстрее написать, быстрее переписать, быстрее закрыть тикет. AWS, по сути, напоминает о скучной инженерной детали, без которой эта скорость начинает работать против команды. В Kiro анализ требований встроен как дополнительный этап перед проектированием и генерацией кода. Вместо длинного отчёта с формулами пользователь получает короткие развилки с двумя вариантами: что именно имелось в виду, какой сценарий считать допустимым, а какой нет. То есть формальная логика спрятана под капотом, а разработчику оставляют человеческую часть работы: выбрать правильный смысл.
Есть и прикладной слой. По данным The New Stack, особый интерес к таким функциям проявляют отрасли, где ошибки дорого обходятся и плохо уживаются с галлюцинациями: финансы, здравоохранение и другие чувствительные домены. Для них анализ требований выглядит не как академическое упражнение, а как способ поймать дорогую ошибку в тот момент, когда она ещё остаётся строчкой в документе, а не инцидентом в продакшене. Показательно и то, что AWS одновременно продвигает в Kiro ещё две функции: Quick Plan, который после серии уточняющих вопросов сразу собирает требования, дизайн и список задач, и Parallel Task Execution, который, по оценке компании, способен сократить время реализации крупных спецификаций примерно на 75%.
Для русскоязычных команд здесь урок довольно прямой. Если ваши требования по-прежнему живут в тикетах, комментариях и созвонах, а код уже пишет агент, то слабое место сместилось вверх по цепочке. Раньше хороший разработчик часто «додумывал» небрежное ТЗ за заказчика или продакта. Теперь ту же пустоту будет заполнять модель, только без контекста переговоров, внутренней политики и интуиции о том, что имелось в виду на самом деле. В такой схеме анализ требований становится не бюрократией, а защитой от дорогостоящей автоматизации.
Похоже, следующий раунд конкуренции AI IDE пойдёт не только за скорость генерации, но и за качество исходного замысла. Если подход AWS приживётся, обсуждать будут уже не только размер контекстного окна и число поддерживаемых агентов, а то, кто лучше умеет превращать расплывчатое «сделай удобно» в проверяемую спецификацию без сюрпризов на релизе. Проверить исходный материал можно в .