4 типа команд разработки в 2026 году. И почему одни делают фичу за неделю, а другие - за месяц

Последние месяцы я работаю сразу с несколькими командами разработки. Часть из них я перестраиваю на AI-native подход, часть - смотрю со стороны. И заметил простую вещь: разница в скорости между командами - в разы, а люди в них примерно одинаковые.

Дело не в талантах. Дело в том, как устроена работа.

Условно я делю все команды на четыре типа.

1. Традиционные

Работают так же, как работали в 2019 году. Неделю анализируют фичу, месяц её делают. Процесс не пересматривался, потому что «так принято» и «так надёжнее».

Из AI-инструментов - ChatGPT или DeepSeek в соседней вкладке. Спросить, как написать регулярку. Попросить объяснить чужой код. Всё вручную скопировать обратно.

Формально AI используется. По факту - это гугл с человеческим лицом.

2. Традиционные+

Тот же процесс, но компания купила команде Cursor. Обычно на минимальном тарифе, потому что «а вдруг не зайдёт».

Разработчики используют его как продвинутый автокомплит. Дописать функцию, сгенерить boilerplate, быстро переименовать переменные. Ускорение реальное, но небольшое - процентов десять-пятнадцать.

Это самый распространённый тип сейчас. И самая опасная ловушка: руководство считает, что компания «внедрила AI», а по факту купила подписку и поставила галочку.

3. AI-native

Здесь перестроили не инструменты, а саму работу.

Разница принципиальная. В предыдущих типах AI встраивают в существующий процесс. Здесь процесс перестраивают под то, что AI умеет.

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

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

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

4. Оголтелые вайбкодеры

Один человек закрывает объём, на который у команды ушло бы три месяца.

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

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

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

Что из этого лучше

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

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

Сейчас я работаю и с третьими, и с четвёртыми. И честно - совсем неочевидно, что лучше. У обоих подходов есть цена, просто платят её в разные моменты.

А к какому типу относится ваша команда?