Comments 9
Где граница spec-driven development? Промпт на разработку кода содержит как правило детальные требования. Как по нему однозначно сказать, что это и есть spec-driven development?
Spec т.е. specification - спецификация, или можно проще документация. Нам надо перед написанием создать эту спецификацию которую ещё и легко менять. например с помощью superpowers, openspec, speckit. Но вот тут как раз и проблема. Часто такое происходит что ты пропускаешь краевые сценарии и не видишь каких то моментов и условно начинаешь кодить и давать задание клоду когда твоя спецификация неполная. Вот в этом и самая большая проблема. Перед кодингом как раз надо удоствовериться что все учтено.
если честно, смутил сам подход использования LLM в вашем кейсе микросервисной разработки: есть CLAUDE.md под каждый микросевис, есть CLAUDE.md под весь проект
зачем кормить LLM весь проект?
на мой взгляд, куда эффективнее самостоятельно разрабатывать документацию и спецификацию к каждому сервису, прибегая к нейросетям как помощникам в проектировании контрактов взаимодействия и работы самих сервисов
а уже каждый отдельный микросервис разрабатывать в изолированной агентной сессии, которая будет опираться только на описание этого сервиса и публичные контракт-спецификации тех сервисов, с которыми она взаимодействуют
больше изоляции, больше документации заранее и, мне кажется, проблема раздувания контекста и лишних ошибок станет менее болезненной
по крайней мере, я использую именно такой принцип в разработке микросервисных приложений
CLAUDE.md не должен раздуваться и часто ллм его игонрирует а например в superpowers это явно указывается что правила в спекек перекрывают правила CLAUDE.md. Общий CLAUDE.md будет при этом огромный если описывать несколько сервисов. я так изаначльно и делал. фича может задевать несколько сервисов поэтому работая только в одном сервисе контекста будет не достаточно. Также портянки трудно ревьюить - нужно схемы, диаграммы - что может ревьюить сам разработчик. И самое главное если явно не скажешь клоду на что обратить внимание - он может это с лёгкостью пропустить. в этом самая большая проблема. а в голове держать всеэти проверки тоже сложно.
фичу, которая задевает несколько сервисов, надо просто правильно декомпозировать на изменение в каждом сервисе по отдельности, где в изолированных, привязанных к конкретному микросервису, агентных сессиях её уже реализовать, следуя заранее проработанному, возможно, совместно с нейронкой, которая знает спецификацию к каждому сервису, но не весь код всех микросервисов, плану изменения
так и сам агент будет лучше и чаще обращать внимание на особенности конкретного микросервиса при реализации фичи внутри него (если, конечно, сам микросервис уж слишком не раздуется, но там уже проблемы другого характера тоже возникнут)
диаграммы и схемы по всей микросервисной системе можно строить, в целом, опираясь лишь на документации к сервисам: описание БД, описание контрактов взаимодействия и т.п., а вот уже неактуальность или недостаточность такой документации говорит о проблемах в выполнении задач в проекте (поскольку документация обычно нужна всем и везде)
ещё раз хочу подсветить, что проблема возникает именно на этапе ресерча. разработчик собирает неполные требования, моделька пропускает краевые случаи , в итоге получается неполная спека , из которой нарезаются неправильные задачи и все это выливается в неправильный код. идея как раз на этапе проработки решения на несколько сервисов дать ллмке как можно больше контекста, как это сделать , ничего не забыв - расскажу во второй и третьей части
Почему spec-driven development плохо работает на микросервисах: часть 1. Где теряется контекст