[Перевод] Как использовать Spec-Driven Development для исследования существующих кодовых баз

Spec Kit - это один из самых амбициозных фреймворков для наведения порядка в разработке с использованием ИИ. В нашем предыдущем посте о spec driven development мы обсуждали его потенциал для закрытия давних пробелов в рабочих процессах с ИИ-ассистентами за счет обеспечения соблюдения стандартов проекта, контекста на уровне функций, принудительной декомпозиции для управляемого объема работ и контрольных этапов (review gates) для контроля качества.

Но исполнение - это то, где теория сталкивается с сопротивлением. Документация Spec Kit - это сильная отправная точка, с понятными видео, подробными руководствами и предписывающими шагами, которые позволяют развернуть его за считанные часы. Сложности начинаются, когда вы покидаете «песочницу». Подобно примерам Animal → Dog → Labrador в учебниках по ООП, примеры учат синтаксису, а не промышленной разработке программного обеспечения.

Пробел заключается не в документации, а в контексте и реальной экспертизе. Чистые примеры прекрасно работают для greenfield-проектов (проектов с нуля), но большинство команд работают с существующими (brownfield) кодовыми базами, сформированными месяцами эволюционирующих решений, компромиссами разработчиков, конкурирующими паттернами и не подлежащими обсуждению стандартами качества.

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