Может ли инженерная команда с поддержкой AI вести операции, рассчитанные на 25 человек?

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

Это утверждение требует важных оговорок. В AppMaster.io операционная команда сократилась с 25 человек до двух инженеров с поддержкой AI, при этом объем работы и контроль доступности сохранились. Это можно утверждать. Но я не стану придумывать процентное изменение числа инцидентов, вымышленную частоту развертываний или аккуратный график по кварталам, которого никогда не публиковали. Важны последовательность действий, меры контроля, не позволившие скорости превратиться в безрассудство, и человеческая работа, которая никуда не исчезла.

Полезный вывод для основателей не звучит как «сократите 23 человека». Это слишком поверхностная трактовка. Суть в том, что продуктовая команда может обходиться с гораздо меньшим объемом координации и ручного выполнения задач, чем принято считать. Но сначала ей нужно заменить эти процессы четкой системой работы.

Почему в операционной команде из 25 человек было больше 25 ролей

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

Это не значит, что люди ленятся. Организация создала такую работу, потому что систему было трудно понять, процесс был описан лишь частично, а знания хранились в отдельных головах. С ростом команды каждая локальная неопределенность порождает еще одну передачу задачи. Передачи создают встречи, статус-обновления, ритуалы приоритизации и ожидание. Затем компания принимает всю эту активность за производственную мощность.

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

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

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

Последняя категория не повод для смущения. Именно здесь находится инженерное руководство. У AI нет коммерческого суждения, личной ответственности за сбой у клиента и права обменивать будущие расходы на поддержку на более раннюю дату запуска. Если делать вид, что это не так, позже придется заплатить за последствия.

Сначала работу нужно было сделать достаточно маленькой, чтобы ей доверять

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

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

Перед передачей рабочему пакету AI-инструменту или другому инженеру нужно ответить на пять вопросов:

1. Какое поведение пользователя или системы должно измениться?
2. Какие файлы, сервисы или интерфейсы входят в область работы?
3. Что не должно измениться?
4. Какие автоматические проверки подтверждают нужный результат?
5. Кто может одобрить выпуск в продакшен и кто может его остановить?

Это сложнее, чем попросить сделать фичу в окне чата. В этом и смысл. Расплывчатый запрос дает правдоподобный код с неизвестными последствиями. Четкий рабочий пакет делает результат проверяемым.

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

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

Сначала мы убирали координацию, а уже потом заменяли выполнение

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

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

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

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

release_candidate:
  stage: release
  script:
    - ./ci/run-contract-tests
    - ./ci/check-migrations --production-safe
    - ./ci/build-release-manifest
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
  artifacts:
    reports:
      dotenv: release.env

production_deploy:
  stage: deploy
  needs: ["release_candidate"]
  script:
    - ./ci/deploy --environment production --revision "$RELEASE_SHA"
    - ./ci/smoke-test --environment production
  when: manual
  rules:
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

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

Документация GitLab приводит связанную с этим мысль о rules: правила оцениваются до запуска задач, поэтому пайплайн не может опираться на переменные, созданные позже в задаче. Это кажется мелочью, пока команда не построит ворота релиза на данных, которых еще нет в момент принятия решения. Изучайте фактическую модель выполнения своей CI-системы. Предположения о порядке работы пайплайна создают предотвратимые сбои релизов.

Практическая проверка была простой: если роль в основном сводилась к копированию статусов, ожиданию ответа или переводу между инструментами, мы спрашивали, зачем продукту и процессу нужен этот человек. Часто он не был нужен. Требовались письменный владелец, правило по умолчанию или машиночитаемый артефакт.

AI взял на себя ограниченное выполнение, но не ответственность

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

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

Но граница оставалась четкой: AI мог подготовить решение, но не принять его и не отвечать за него.

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

Полезное правило ревью такое: чем менее обратимо изменение, тем меньше автономии получает агент. Код за feature flag проще отменить, чем задачу удаления. Обновление теста проще отменить, чем модель прав доступа. Исправление документации проще отменить, чем платежный поток.

Мы использовали три уровня работы AI:

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

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

Для доступности нужны меры контроля, не зависящие от размера команды

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

В Google SRE Book целевой показатель уровня сервиса определяется как цель, измеряемая через индикатор уровня сервиса. Там также не рекомендуют стремиться к стопроцентной надежности, потому что такая цель может заставить организацию тратить слишком много на осторожность и слишком мало на полезные изменения. Важна не терминология. Важно заранее согласовать, какое поведение для пользователя имеет значение и что делать при ухудшении надежности.

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

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

Минимальная карточка сервиса может выглядеть так:

Service: account provisioning
User action: create a production workspace
Success signal: completed provisioning requests / total requests
Target: set by product and engineering together
Alert: sustained failure rate above the agreed threshold
First responder: current on-call engineer
Mitigation: disable new provisioning, preserve existing workspaces
Rollback: redeploy previous approved revision
Escalation: product owner decides on customer communication and exceptions

Значение цели намеренно не указано. Скопированная цель в 99,9% не является SLO. Ее должны определять фактическое обещание продукта, характер трафика и сценарий сбоя. Генератор отчетов может допускать более медленное восстановление, чем поток создания рабочего пространства. Для платежного действия могут требоваться более строгие меры контроля, чем для внутренней административной страницы.

Google SRE Workbook идет дальше и рекомендует политику бюджета ошибок, которая определяет, что меняется после его исчерпания. Именно этого часто не хватает стартапам. Они измеряют сбои, обсуждают их потом, а затем выпускают изменения с прежней скоростью, потому что так стоит в календаре. Письменная политика убирает спор в самый неподходящий момент.

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

Метрики должны описывать поставку, а не занятость

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

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

Используйте компактную сводку:

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

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

Фраза «сохранить объем работы» тоже требует точности. Она не означает, что нужно выпускать столько же задач или часов кода. Она означает, что клиенты по-прежнему получают нужные изменения продукта, исправления и операционные реакции. Если команда из 25 человек тратила половину времени на внутреннюю координацию, замена этой активности AI должна уменьшить число задач. Это не потеря.

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

Сбой обычно возвращает скрытую работу через боковую дверь

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

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

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

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

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

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

Человеческое суждение стало заметнее, а не исчезло

Чем меньше команда, тем очевиднее, что принятие решений - отдельный вид работы. Оно не растворяется в промпте и не становится проще только потому, что код появился быстрее.

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

Это не крайние случаи. Именно такие решения определяют, сохранит ли стартап целостность по мере роста.

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

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

Небольшой команде нужен другой ритм управления

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

Замена - не нулевая коммуникация. Это коммуникация, привязанная к решениям.

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

На планировании нужно ограничивать объем незавершенной работы. Два инженера могут дать неожиданно большой результат, но не способны безопасно вести десять несвязанных инициатив одновременно. AI создает впечатление, что переключаться между контекстами стало дешевле, потому что он быстро находит код. Цена возвращается, когда людям приходится проверять, интегрировать, объяснять и поддерживать все эти изменения.

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

Здесь может помочь внешний обзор. Аудит Team & AI должен выявить ручную работу, неясную ответственность, небезопасные пути релиза и скрытую координацию, мешающие компактной команде работать безопасно. Сначала нужно найти работу, которую можно убрать, и только потом принимать решение о численности.

Последовательность важнее заголовка о численности

Последовательность была не такой: «купить AI-инструменты, сократить штат и надеяться». Сначала мы сделали процесс поставки видимым и ограниченным. Убрали координацию, не создававшую ценности для клиентов. Автоматизировали детерминированные проверки и передали AI ограниченные задачи выполнения. Защитили продакшен измеримыми целевыми показателями сервиса, воротами релиза, путями отката и правилом на случай ухудшения надежности. После этого оставшиеся люди сосредоточились на решениях, требующих суждения.

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

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

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