Команду разработки в 2026 собирают от задач, а не от штатки: какие роли берут агенты

Кто нужен на новый продукт? Ответ зависит от того, что пользователь должен сделать. Кабинету клиента нужны вход и просмотр заказа, а не должность сама по себе.

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

Ниже учебный пример кабинета заказов. Это заготовка для обсуждения с исполнителем, а не наш клиентский проект или оценка срока.

Нужны ли отдельные люди на экран, серверную часть и тесты? Работы нужны в любом случае. Раздать каждую из них отдельной вакансии теперь не единственный способ.

Инженер ведёт машину агентов vibecoding.ru. На открытом экране работы было 7 032 коммита за 98 дней на срез 7 октября 2026.

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

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

Работу сайта на странице подписки сопоставляют с 13 позициями, включая редакторов и иллюстратора. Это оценка состава команды, а не 13 разработчиков.

Для собственного продукта перечень будет другим. Если вам нужен кабинет заказов, редакция новостей в его бюджет не входит.

На /open сравнивается месячная цена инженера с машиной и команды для той же работы. Кратность ×8 относится к модели, а не к экономии клиента.

Можно ли начать без собственного отдела? Можно привлечь инженера или подрядчика под задачи. Но кто-то должен решить, как устроен продукт и что считать готовым.

Владелец знает бизнес, инженер оценивает технические последствия. Экран заказа без проверки доступа выглядит готовым, но выпускать его рано.

Для этого не обязательно нанимать каждую роль на полную ставку. Важно назначить ответственного и согласовать результат его работы до старта.

Команда должна договориться о результате на стыках. Рабочий экран заявки ещё не доказывает, что она сохранится и попадёт менеджеру.

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

Проверяющий должен пройти путь пользователя и увидеть последствия действия. Ответ агента «готово» не заменяет эту приёмку.

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

Новые агенты увеличат очередь, если инженер не успевает проверять. Если работа ждёт решения владельца, дополнительный разработчик не поможет.

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

Когда нанимать своего специалиста? Когда регулярно нужна его работа. Если продукт сам использует ИИ, выбор роли разобран в статье про ИИ-инженера в штат.

Для постоянных правок есть подписка на исполнение. Тариф «Все проекты» на 7 октября 2026 стоит 500 000 ₽ в месяц и включает три потока.

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

Неясно, кто ставит задачи и принимает работу? Пройдите тест для руководителя. Он оценивает организацию работы, а не штат будущего продукта.

Для регулярного исполнения условия есть на странице агентной разработки для бизнеса. На звонок приходите с первым результатом, который нужен продукту.

1. Начните с действия пользователя. Опишите, что должно получиться после него.
2. Назначьте владельца решения и принимающего. Эти функции нужны при любом исполнителе.
3. Поручайте агентам ограниченные задачи. Принимайте целый путь, включая случай ошибки.
4. Добавляйте людей там, где работа регулярно ждёт. Сначала выясните причину ожидания.
5. До запуска закройте поддержку. Согласуйте, кто исправляет поломку и как восстановить работу.