Спасибо за развёрнутый комментарий - это как раз тот риск, который я и стараюсь проговорить в статье.
SDD не предполагает, что один "постановщик" написал большой документ, а остальные обязаны его героически читать. Наоборот, идея в том, чтобы разложить знания на слои артефактов и связать их трассируемостью: домен → требования → сценарии → архитектура → проверки. В таком виде это не монолитное ТЗ на 120 страниц, а связанный контур, где каждый слой читается и ревьюится своей ролью.
Бутылочное горлышко "никто не читает SRS" действительно существует давно. Но чаще проблема не в том, что люди не умеют читать, а в том, что документ не встроен в инженерный цикл. Если требования не связаны с архитектурой, тестами и решениями - их и правда игнорируют. Когда же изменение требования автоматически тянет пересмотр сценария и следа верификации (через PR и ревью), документ перестаёт быть "бумагой ради бумаги".
По поводу применимости - да, SDD не универсальная серебряная пуля. Он разумен там, где документация - это инструмент управления изменениями, а не формальность. В маленькой команде с быстрой итерацией overhead может быть избыточным. В R&D, регуляторных или сложных интеграционных проектах - наоборот, окупается.
И, пожалуй, важный момент, методика не усиливает "власть постановщика". Она как раз снижает зависимость от одного человека, потому что знания становятся распределёнными и проверяемыми через связанный граф артефактов и ревью. Если система держится на одном авторе ТЗ - это организационная проблема, и никакой ИИ её сам по себе не решит.
Так что вопрос не в том, кто будет "грести деньги", а в том, готова ли команда инвестировать в управляемость и прозрачность решений. SDD - это инструмент для тех, кто видит в этом ценность.
Понимаю, что формат может выглядеть непривычно для Хабра, но это не дипломная и не магистерская работа - она у меня уже давно защищена. Текущая публикация - отдельный исследовательский материал по методике SDD, который решил выложить в исходном виде, чтобы зафиксировать сам подход и иметь на него открытую ссылку.
Такие тексты обычно читают те, кто занимается архитектурой процессов разработки, инженерией требований и docs-as-code практиками - аудитория не самая массовая, но для профильных специалистов тема оказывается вполне прикладной.
Спасибо за комментарий! В данном случае статья действительно сохраняет академический стиль осознанно - это публикация, основанная на исследовательской работе, поэтому текст оставлен максимально близким к исходной научной версии. Отдельно позже планирую подготовить более прикладные материалы, где подход будет разобран в практическом формате и на реальных кейсах внедрения.
Да, согласен, в текущих LLM действительно есть такая проблема. Я как раз читал о ней - https://www.getpanto.ai/blogs/the-illusion-of-thinking-why-apples-findings-hold-true-for-ai-code-reviews всё сводится к тому, что для корректной проверки сложного кода LLM-ам необходим дополнительный контекст (история изменений, архитектурные документы и обсуждения команды), иначе и человек, и ИИ могут попасть в "иллюзию понимания" - видеть только "что написано", но не "зачем и почему".
Эксперимент в рамках данной публикации не проводился - статья опирается на анализ литературы и существующие исследования (например, SlimCode и др.), где показано, что минификация снижает затраты токенов и может увеличивать объём обрабатываемого кода без потери точности для LLM. Собственные тесты не проводились, так как пока отсутствуют LLM, специально обученные на минифицированном коде - было бы интересно увидеть такие работы в будущем. Все выводы статьи основаны на обзорах и публикациях других исследователей.
я думаю все дело в размере обрабатываемого контекста и стоимости обработки, с каждым днем все лучше и больше можно обработать/заместить с помощью ИИ, также не все могут работать с ИИ, уметь организовать работу ИИ, это сравнимо с умением организацией работы целого отдела...остается учиться этому и развивать ИИ
Спасибо за развёрнутый комментарий - это как раз тот риск, который я и стараюсь проговорить в статье.
SDD не предполагает, что один "постановщик" написал большой документ, а остальные обязаны его героически читать. Наоборот, идея в том, чтобы разложить знания на слои артефактов и связать их трассируемостью: домен → требования → сценарии → архитектура → проверки. В таком виде это не монолитное ТЗ на 120 страниц, а связанный контур, где каждый слой читается и ревьюится своей ролью.
Бутылочное горлышко "никто не читает SRS" действительно существует давно. Но чаще проблема не в том, что люди не умеют читать, а в том, что документ не встроен в инженерный цикл. Если требования не связаны с архитектурой, тестами и решениями - их и правда игнорируют. Когда же изменение требования автоматически тянет пересмотр сценария и следа верификации (через PR и ревью), документ перестаёт быть "бумагой ради бумаги".
По поводу применимости - да, SDD не универсальная серебряная пуля. Он разумен там, где документация - это инструмент управления изменениями, а не формальность. В маленькой команде с быстрой итерацией overhead может быть избыточным. В R&D, регуляторных или сложных интеграционных проектах - наоборот, окупается.
И, пожалуй, важный момент, методика не усиливает "власть постановщика". Она как раз снижает зависимость от одного человека, потому что знания становятся распределёнными и проверяемыми через связанный граф артефактов и ревью. Если система держится на одном авторе ТЗ - это организационная проблема, и никакой ИИ её сам по себе не решит.
Так что вопрос не в том, кто будет "грести деньги", а в том, готова ли команда инвестировать в управляемость и прозрачность решений. SDD - это инструмент для тех, кто видит в этом ценность.
Понимаю, что формат может выглядеть непривычно для Хабра, но это не дипломная и не магистерская работа - она у меня уже давно защищена. Текущая публикация - отдельный исследовательский материал по методике SDD, который решил выложить в исходном виде, чтобы зафиксировать сам подход и иметь на него открытую ссылку.
Такие тексты обычно читают те, кто занимается архитектурой процессов разработки, инженерией требований и docs-as-code практиками - аудитория не самая массовая, но для профильных специалистов тема оказывается вполне прикладной.
Спасибо за комментарий! В данном случае статья действительно сохраняет академический стиль осознанно - это публикация, основанная на исследовательской работе, поэтому текст оставлен максимально близким к исходной научной версии. Отдельно позже планирую подготовить более прикладные материалы, где подход будет разобран в практическом формате и на реальных кейсах внедрения.
Да, согласен, в текущих LLM действительно есть такая проблема. Я как раз читал о ней - https://www.getpanto.ai/blogs/the-illusion-of-thinking-why-apples-findings-hold-true-for-ai-code-reviews всё сводится к тому, что для корректной проверки сложного кода LLM-ам необходим дополнительный контекст (история изменений, архитектурные документы и обсуждения команды), иначе и человек, и ИИ могут попасть в "иллюзию понимания" - видеть только "что написано", но не "зачем и почему".
Эксперимент в рамках данной публикации не проводился - статья опирается на анализ литературы и существующие исследования (например, SlimCode и др.), где показано, что минификация снижает затраты токенов и может увеличивать объём обрабатываемого кода без потери точности для LLM. Собственные тесты не проводились, так как пока отсутствуют LLM, специально обученные на минифицированном коде - было бы интересно увидеть такие работы в будущем. Все выводы статьи основаны на обзорах и публикациях других исследователей.
спасибо за замечание! исправил
я думаю все дело в размере обрабатываемого контекста и стоимости обработки, с каждым днем все лучше и больше можно обработать/заместить с помощью ИИ, также не все могут работать с ИИ, уметь организовать работу ИИ, это сравнимо с умением организацией работы целого отдела...остается учиться этому и развивать ИИ
Так держать - великие дела начинаются с малого!!!