Будь осторожнее с SDD
Сейчас идёт пик хайпа SDD (Spec Driven Development). Это подход, при котором написанию кода предшествует создание спецификаций (далее - спек), использующихся основой для агентов при генерации кода. На каждой конференции минимум один доклад об этом, всё больше историй успеха, что всю компанию полностью перевели на Agentic SDLC (простыми словами, процесс разработки с помощью агентов), во многих компаниях начинают добровольно-принудительно внедрять этот подход на основе различных фреймворков (OpenSpec, Superpowers, Spec Kit, gsd и т.д.). Но, на мой взгляд, внедрение ради внедрения ни к чему хорошему не приведёт, а только увеличит time-to-market фичей, ухудшит качество и станет источником появления тонны слоп-текста.
Сразу оговорюсь, что мне очень импонирует SDD, я его очень давно использую, ещё до агентов, да и вы, скорее всего, используете. Перед написанием кода для сложных фичей пишем технические решения, проводим архитектурные встречи и оставляем какие-нибудь артефакты (типа ADR). На их основе декомпозируем большие задачи на более маленькие и пишем код.
С агентами такой подход обрёл новый виток развития, так как именно через спецификацию можно более точно контролировать работу агента. Спеки перенесли в markdown-файлы (рядом с кодом), воркфлоу задаётся spec-driven фреймворками, а агенты делают ровно то, что написано в спеках. Красота. И где-то тут рождаются идеи типа описывать спеки не только верхнеуровнево для сложных фичей, а для каждой задачи. Полгода назад, когда я познакомился с OpenSpec (плагин для агентов, предоставляющий механизм работы по SDD и формированию всех артефактов), я побежал его тестировать на сайд проектах. И оказалось, не всё так радужно, как изначально хотелось бы.
Пройдёмся по основным проблемам:
1️⃣ Многие фреймворки (тот же OpenSpec) генерируют main-спецификации (которые описывают актуальное состояние приложения/сервиса/системы) и транслируют идею, что спецификация становится источником истины, а не код. Не только в…
Читать полностью →