Что в спецификации написано, то не всегда системой сделано: поможет ли LLM увидеть разрыв?

В командах знания о системе обычно распределены между несколькими артефактами: требованиями, документацией, тест-кейсами, автотестами, спецификациями, заметками аналитиков и договоренностями «в головах». Исторически это уже создавало проблемы: дублирование, расхождения, устаревание и споры о том, что считать актуальным описанием поведения системы.

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

В этом контексте особенно интересно посмотреть на тесты: могут ли хорошо спроектированные тестовые сценарии и автотесты служить не только средством проверки, но и компактным, надежным представлением предметной области?

Это разговор не о том, что «тесты заменят документацию» или что нужно срочно переписать все процессы под AI. Скорее это попытка вместе разобраться:

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

Формат дискуссии здесь особенно важен: у разных команд уже есть свой опыт, свои компромиссы и свои рабочие схемы. Хочется не вывести одну универсальную модель, а собрать спектр подходов и понять, какие из них дают наилучший эффект в реальной разработке. Вишенкой на торте — обсудить, как в реальных условиях организовать тестирование требований и решений (артефактов аналитиков) со стороны тестировщиков.