Human as a Service

Гипотеза свежего старта.

У меня есть гипотеза, которую я пока не умею доказать. Она основана на двух наблюдениях из моих проектов:

1. По моим наблюдениям, spec-driven агентная разработка сокращает time-to-market на 10–30%. Я встречал и оценки ускорения более чем на 100%, но там, по-моему, неправильно считают 😁
2. По моим наблюдениям, в существующие продукты этот подход внедряется тяжело. Чем больше и старше продукт, тем сложнее. Для некоторых классов продуктов такое внедрение, возможно, вообще не имеет экономического смысла.

Разница в 10–30% кажется небольшой. Но, думаю, за несколько лет команда с таким преимуществом успеет провести больше циклов обратной связи с пользователями и построит качественно другой продукт.

Отсюда моя гипотеза: через 5–10 лет продукты, разработка которых не трансформируется, будут вытеснены с рынка продуктами, созданными сейчас или в ближайшие годы.

Что думаете?

По мере развития AI-assisted development фокус разработчиков смещается с написания кода на формулировку задачи и проверку результата. Когда разработчик работает над задачей с агентом, он передаёт агенту в чате контекст, необходимый для формулировки задачи. Этот контекст живёт только до тех пор, пока жив агент или пока не произойдёт сжатие контекста. Для простых сценариев разработки, когда автономность агентов невелика, это подходящий вариант.

Но по мере роста автономности становится понятно, что нужны артефакты: спеки, в которых нужно хранить формулировку задачи независимо от агентов и разработчиков. Спеки хранятся в репозитории вместе с кодом и доступны агенту при каждом запуске. При первой реализации агент пишет код по спеке. При последующих изменениях она помогает сохранить существующее поведение, когда агент работает над другой задачей.

Спеки также повышают качество ревью другими агентами. У ревьюеров появляется постановка задачи, по которой был написан код.

Типичная спека состоит из следующих частей:

1. Требования: как должна вести себя система.
2. Ограничения.
3. Критерии приёмки.
4. План реализации и список задач, которые агент должен выполнить в процессе реализации.

Есть два популярных фреймворка для работы со спеками:

1. GitHub Spec Kit фокусируется на пайплайне разработки: specify → plan → tasks → implement.
2. OpenSpec фокусируется на жизненном цикле изменений в спеках: explore → propose → apply → archive.

В моём опыте пайплайн в разработке на основе спецификаций (spec-driven development, SDD) выглядит так:

1. В тикете фиксируется краткое описание задачи, цель и критерии приёмки.
2. Владелец продукта вместе с агентом формулирует требования человеческим языком. Я предпочитаю EARS, но формат может быть другим.
3. Разработчик вместе с агентом добавляет технические детали: разбивка на подсистемы, ограничения, технические требования.
4. Разработчик и агент готовят план и список задач для реализации.
5. Один или несколько агентов под присмотром разработчика реализуют фичу по плану и пишут тесты.
6. Разработчик и агент-ревьюер проверяют соответствие кода цели, спеке и критериям приёмки. Выявляют и устраняют расхождения между спецификациями и кодом.
7. Ответственный за приёмку сверяет результат со спекой и критериями приёмки, проверяет, что все автоматизированные проверки прошли (тесты, линтеры, агенты), а затем принимает его.

Если во время ревью или приёмки обнаруживается проблема в спеке или плане, работа возвращается на соответствующий этап пайплайна.

Автономный агент берёт на себя всё большую часть реализации. Разработчик отвечает за спеку и план, а после реализации проверяет результат. Чем автономнее агент, тем сильнее качество кода зависит от качества этих артефактов.

Процесс внедрения агентов в разработку обычно проходит следующие этапы зрелости:

1. LLM as autocomplete: подсказывает продолжение кода прямо в редакторе. Системы вокруг не видит, между запросами ничего не помнит. Помогает с локальным кодом.
2. Agent as a coding partner: агент пишет код, разработчик формулирует задачу, направляет, контролирует результат. Но каждый запуск начинает с чистого листа: проектные инварианты и связи между файлами приходится снова загружать в промпт. Иногда ломает работающий код, потому что не понимает, почему он так написан.
3. Agentic development pipeline: агенты больше не работают поодиночке, а собраны в пайплайн с разделением ролей. У них есть общее знание о системе в виде спеков. Человек смещается из роли «писать код» в роль «одобрять ключевые решения».
4. Agentic SDLC: пайплайны накрывают не только разработку, а весь жизненный цикл: от появления задачи до инцидентов в продакшне. Человек включается только на самом верхнем уровне: стратегия и приёмка.

Большинство команд, которые активно используют AI, сейчас на этапах 2–3. Мой личный процесс разработки сейчас на уровне 3. Вот как он устроен.

Идея в трёх слоях.

Specs driven dev. Сначала спеки, потом план, потом код. Строго в таком порядке. Агент знает, как работает система, только потому что у него есть спеки. Это даёт ревьюеру способ ловить «агент написал больше, чем ему сказали»: всё, чего нет в требованиях, считается багом, даже если код корректный. И наоборот: любое изменение кода, противоречащее существующим требованиям, тоже баг. Спека сначала задаёт задачу, а потом становится критерием приёмки.

Оркестратор и агенты на шаги. Один агент правит спеки и составляет план. Второй реализует по плану: пишет код и тесты. Третий ревьюлит. Оркестратор сам ничего не пишет, только смотрит, чья сейчас очередь. У каждого агента свой набор инструментов, свои промпты и свои запреты. Это принцип минимизации радиуса поражения: ошибка агента не выходит за его зону ответственности. Самый яркий случай — ревьюер. У него вообще нет write-инструментов, поэтому он буквально не может сломать ни строчки в проекте. Только оставить комментарий.

Синхронизация через PR в GitHub. Состояние пайплайна живёт в лейблах PR. Переписка разработчика с агентами и агентов между собой идёт в инлайн-тредах. Отдельный канал координации между агентами не нужен. Лейбл — source of truth для оркестратора. Он по лейблу решает, какого агента запустить, и сам же выставляет новый лейбл, когда шаг закончен. Сам оркестратор stateless: между запусками он не помнит ничего, фазу определяет по лейблу. Из-за этого его можно прервать и перезапустить в любой момент. Задача продолжится с нужного места.

Разработчик в этой схеме остаётся в двух точках: одобряет изменения в спеках и плане, и принимает результат. Это контрольные шлюзы, через которые оркестратор не проходит сам. Всё остальное автоматизировано так, чтобы у него осталось ровно два момента влияния.

Channel created