Спецификации на пути к автономной разработке
В прошлых постах рассуждал про инженеров будущего и про автономный цикл создания ПО.
Мы работаем над инструментами для такого AI SDLC (как сейчас модно говорить), и масштаб компании даёт как преимущества, так и создаёт проблемы. С одной стороны, мы видим очень много разных проектов. Это даёт возможность проанализировать их и найти общие паттерны, выработать общие подходы к разработке, стараться автоматизировать их. С другой стороны, внутренние инструменты, которые мы создаём, должны отвечать требованиям очень разных команд. Нет возможности срезать углы и закастомить под конкретную команду — всегда должно быть общее решение.
Теперь вернемся к AI SDLC. По моему мнению, сейчас не столь важны инструменты, сколько создание общей среды для агентов и людей. Накопление знаний и создание единого контекста. LLM и инструменты меняются, данные и знания остаются.
Это значит, что первая задача на пути к автономному созданию ПО — максимально «сблизить» данные, которыми оперируют разные специалисты и агенты. И в первую очередь все собирают бизнес-требования. Spec driven development уже давно звучит из каждого утюга. Но проблема в том, что конечный стейкхолдер выдаёт требования обычно обрывочно и неструктурированно. Их нужно собирать с заказчика, анализировать и на основе этих данных синтезировать спецификацию. А потом согласовывать. И обычно этот процесс ведется в удобных инструментах типа гугл-доков или конфлюенсов, где можно оставить комментарии, предложить изменения и т.д.
Но даже после согласования документации есть не менее объёмная задача — поддержание этой документации в актуальном состоянии. И при этом хочется, чтобы конечные доки лежали в том же месте, что и код, и другие артефакты по проекту. Тогда и получится максимально использовать агентов для последующей генерации уже технической спецификации, кода, тестов и т.д.
В целом, работать через mcp с теми же гугл-доками можно. И мы так и делали в первых итерациях. Проблема в том, что «мостиком» между агентом и документацией тогда является человек, который работает с ними. Он должен указать документ, изменить его (например, автоматически обработать комментарии заказчика), а через MCP часто бывает неудобно (перетирается весь док, нельзя включить режим предложений). А обновить документацию уже потом в процессе разработки — отдельный шаг, который точно кто-нибудь забудет. Мы даже разработали плагин к гугл-докам, который умеет обрабатывать комментарии и вносить правки в режиме предложений. Но этого все ещё недостаточно, потому что кодинговый агент, живущий в репозитории, лучше всего работает с артефактами из этого репозитория.
Поэтому единственное качественное решение, к которому мы пришли: вся документация по бизнес-требованиям должна быть в той же репе в гите. Ок, это не проблема для аналитиков, но заказчик точно не захочет смотреть мерж-реквесты в Гитлабе. Он привык к удобным гугл-докам.
Поэтому нам пришлось разработать сервис для просмотра и согласования документации, которая лежит в репозитории. Сервис позволяет комментировать (через комменты к мерж-реквестам) и редактировать (через коммиты) документы прямо онлайн, полностью имитируя процесс гугл-доков. Теперь большинство аналитиков согласуют с заказчиками документацию в нашем сервисе и она автоматически попадает в репозиторий, где её же использует агент. А комменты от заказчиков можно обрабатывать автоматически. Затем разработчики используют документацию уже для программирования и в процессе разработки могут автоматически (агентом) проапдейтить документацию, если было изменение в процессе реализации.
Но мало сделать, надо еще и внедрить. Для внедрения мы сделали простой yaml-конфиг, описывающий структуру документации в репозитории. Разработчикам / аналитикам нужно добавить только этот конфиг и репозиторий автоматически покажется в интерфейсе сервиса для просмотра и согласования документов.
Вуаля, и вот мы сделали маленький, но важный шажок на пути к автономному AI SDLC.
#сергей_чернобровкин
В прошлых постах рассуждал про инженеров будущего и про автономный цикл создания ПО.
Мы работаем над инструментами для такого AI SDLC (как сейчас модно говорить), и масштаб компании даёт как преимущества, так и создаёт проблемы. С одной стороны, мы видим очень много разных проектов. Это даёт возможность проанализировать их и найти общие паттерны, выработать общие подходы к разработке, стараться автоматизировать их. С другой стороны, внутренние инструменты, которые мы создаём, должны отвечать требованиям очень разных команд. Нет возможности срезать углы и закастомить под конкретную команду — всегда должно быть общее решение.
Теперь вернемся к AI SDLC. По моему мнению, сейчас не столь важны инструменты, сколько создание общей среды для агентов и людей. Накопление знаний и создание единого контекста. LLM и инструменты меняются, данные и знания остаются.
Это значит, что первая задача на пути к автономному созданию ПО — максимально «сблизить» данные, которыми оперируют разные специалисты и агенты. И в первую очередь все собирают бизнес-требования. Spec driven development уже давно звучит из каждого утюга. Но проблема в том, что конечный стейкхолдер выдаёт требования обычно обрывочно и неструктурированно. Их нужно собирать с заказчика, анализировать и на основе этих данных синтезировать спецификацию. А потом согласовывать. И обычно этот процесс ведется в удобных инструментах типа гугл-доков или конфлюенсов, где можно оставить комментарии, предложить изменения и т.д.
Но даже после согласования документации есть не менее объёмная задача — поддержание этой документации в актуальном состоянии. И при этом хочется, чтобы конечные доки лежали в том же месте, что и код, и другие артефакты по проекту. Тогда и получится максимально использовать агентов для последующей генерации уже технической спецификации, кода, тестов и т.д.
В целом, работать через mcp с теми же гугл-доками можно. И мы так и делали в первых итерациях. Проблема в том, что «мостиком» между агентом и документацией тогда является человек, который работает с ними. Он должен указать документ, изменить его (например, автоматически обработать комментарии заказчика), а через MCP часто бывает неудобно (перетирается весь док, нельзя включить режим предложений). А обновить документацию уже потом в процессе разработки — отдельный шаг, который точно кто-нибудь забудет. Мы даже разработали плагин к гугл-докам, который умеет обрабатывать комментарии и вносить правки в режиме предложений. Но этого все ещё недостаточно, потому что кодинговый агент, живущий в репозитории, лучше всего работает с артефактами из этого репозитория.
Поэтому единственное качественное решение, к которому мы пришли: вся документация по бизнес-требованиям должна быть в той же репе в гите. Ок, это не проблема для аналитиков, но заказчик точно не захочет смотреть мерж-реквесты в Гитлабе. Он привык к удобным гугл-докам.
Поэтому нам пришлось разработать сервис для просмотра и согласования документации, которая лежит в репозитории. Сервис позволяет комментировать (через комменты к мерж-реквестам) и редактировать (через коммиты) документы прямо онлайн, полностью имитируя процесс гугл-доков. Теперь большинство аналитиков согласуют с заказчиками документацию в нашем сервисе и она автоматически попадает в репозиторий, где её же использует агент. А комменты от заказчиков можно обрабатывать автоматически. Затем разработчики используют документацию уже для программирования и в процессе разработки могут автоматически (агентом) проапдейтить документацию, если было изменение в процессе реализации.
Но мало сделать, надо еще и внедрить. Для внедрения мы сделали простой yaml-конфиг, описывающий структуру документации в репозитории. Разработчикам / аналитикам нужно добавить только этот конфиг и репозиторий автоматически покажется в интерфейсе сервиса для просмотра и согласования документов.
Вуаля, и вот мы сделали маленький, но важный шажок на пути к автономному AI SDLC.
#сергей_чернобровкин