Роль инженера в AI-стартапе: что по-прежнему остаётся на одном человеке

Почему ответственность быстро размывается в маленьких AI-командах

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

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

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

AI ещё и убирает часть трения, которое раньше заставляло команды принимать более взвешенные решения. Раньше люди хотя бы ненадолго замедлялись и успевали задать неудобные, но полезные вопросы. Стоит ли вообще хранить эти данные? Что будет, если очередь будет стоять час? Кто имеет право выкатывать в пятницу вечером? Быстрое создание кода пропускает такие разговоры, и команды выпускают неявные решения вместо явно назначенных.

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

Промпты могут писать код, тесты и документацию. Но они не могут владеть архитектурными границами, риском и последствиями в продакшне.

Что всё ещё должен делать один инженер

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

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

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

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

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

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

Решения, которые никогда не должны оставаться в промптах

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

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

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

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

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

То же касается продакшн-секретов, правил хранения данных, удаления и всего, что влияет на соответствие требованиям или историю аудита. Это операционные решения, а не решения для промптов.

Как назначить ответственность

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

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

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

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

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

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

Хорошее правило простое: если цена ошибки высока, окончательное решение принимает конкретный человек.

Как должны работать права на деплой

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

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

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

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

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

Доступ к продакшну должен оставаться у очень узкой группы — обычно у основного владельца и одного резервного человека. Все остальные могут работать в staging, смотреть дашборды и читать постмортемы без shell-доступа к живым системам.

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

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

Что происходит во время инцидента в продакшне

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

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

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

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

Держите коммуникацию короткой и фактической. Записывайте таймлайн, симптомы, проверки, которые вы провели, и результат каждого действия. Помогают заметки вроде «ошибка резко выросла сразу после деплоя в 14:12». А вот заметки вроде «проблема, наверное, в базе данных» только засоряют картину, если их не подтверждают метрики.

У большинства стартапов хороший результат даёт простое разделение. Один лидер принимает решения. Один инженер проверяет логи, метрики и последние изменения. Другой человек делает откат или hotfix. Ещё кто-то публикует внутренние обновления статуса.

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

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

Простой пример из одной рабочей недели стартапа

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

Во вторник двум клиентам списывают деньги дважды.

В happy-path тестах ничего сломанного не было. Проблема проявилась на реальном трафике. Платёжный провайдер повторил callback, а приложение ещё и повторило часть той же цепочки. AI написал код, который выглядел нормально, но пропустил одно жёсткое правило: платёжные действия должны быть идемпотентными всегда, даже в грязных реальных условиях.

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

За эту неделю команда меняет не только код.

После отката

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

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

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

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

Ошибки, которые создают скрытые пробелы в ответственности

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

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

Ещё одно слабое место — позволять AI менять схему базы данных или файлы миграций без человеческой проверки. AI может написать аккуратную миграцию. Но он же может переименовать поле так, что сломаются отчёты, биллинг или старые API-клиенты. Тесты при этом могут всё ещё проходить, потому что тесты обычно проверяют ожидаемое поведение, а не каждую скрытую зависимость в живой системе.

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

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

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

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

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

Короткий чеклист для маленьких команд

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

• Назначайте одного утверждающего релиз за раз.
• Сделайте откат скучным и быстрым.
• Отмечайте изменения, которые всегда требуют проверки.
• Настраивайте сигналы тревоги вокруг боли пользователей.
• Используйте AI для черновиков, идей для тестов, сводок и проверки diff, но не для финального одобрения риска.

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

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

Что основателям делать дальше

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

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

Один владелец — это один владелец. Не «инженерная команда», не «команда» и не общий чат. Если два человека думают, что у них есть право на деплой и согласование, на самом деле никто не владеет откатом, когда что-то ломается.

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

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

Если роли каждую неделю меняются, внешняя помощь может прояснить границу быстрее, чем ещё один круг встреч. Oleg Sotnikov на oleg.is работает со стартапами в формате Fractional CTO, а также помогает с архитектурой и AI-first delivery — и этого часто достаточно, чтобы превратить размытое общие обязательства в несколько понятных имён и правил.

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