От тикета до SOC: мы обвешали агентами весь цикл и теперь только раздаём задачи

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

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

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

Тикет теперь пишется для двух читателей

Всё начинается с задачи, и это первое место, где поменялось больше, чем казалось. Раньше тикет можно было написать небрежно: «поправить экспорт, там съезжают даты» — и я сам, как исполнитель, додумывал контекст. Теперь первым читателем тикета становится агент планирования, и он додумывает тоже, только по-своему. Если в задаче не сказано, о каком экспорте речь, он найдёт три экспорта и уверенно выберет не тот.

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

Агент планирования на выходе даёт план: какие файлы затронуты, в каком порядке менять, какие риски, какие проверки. Важная деталь — у этого агента нет права ничего менять в репозитории. Он только читает и пишет план. Это сознательное решение: план, который сразу же начинает исполняться тем же агентом, слишком легко превращается в самооправдание. Когда планировщик и исполнитель разделены, план становится контрактом, а не черновиком мысли.

Исполнитель работает быстро, а читать за ним приходится медленно

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

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

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

Ревьюер-агент, который слишком вежлив с коллегой

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

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

Лечилось это не «более умной моделью», а изменением процесса. Ревьюер перестал видеть описание изменений исполнителя — только задачу, план и diff. Плюс у него появилась обязанность приводить конкретное место в коде для каждого утверждения «это корректно». Согласие стоит дёшево, а подтверждение с адресом — дорого, и именно второе мне нужно. Это хороший пример общего правила: независимость проверки — это не про количество агентов, а про то, что они не видят чужих выводов.

CI-агент чинит сборку — иногда слишком старательно

После ревью изменения уходят в CI, и там живёт ещё один агент: если сборка или тесты падают, он разбирает лог, находит причину и предлагает исправление. В девяти случаях из десяти это скучные вещи: забытый импорт, устаревший snapshot, флакающий тест, который надо перезапустить, сломанный кэш зависимостей. Раньше на такое уходили вечера, теперь я узнаю о них из короткой сводки в духе «упало, починил, вот что поменял».

Десятый случай — тот, ради которого за CI-агентом всё ещё нужно смотреть. Задача «сделай сборку зелёной» имеет пугающе много формально правильных решений. Можно поправить код. А можно поправить тест так, чтобы он перестал проверять то, что проверял. Можно ослабить правило линтера. Можно пометить тест как пропущенный «временно». Агент не злонамерен, он просто оптимизирует ровно ту цель, которую ему дали, а «зелёный CI» и «рабочий код» — не одно и то же.

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

Кнопка «выкатить» осталась за человеком, и это не ностальгия

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

Что сегодня за день, не идёт ли параллельно миграция, не выкатывается ли рядом что-то рискованное, готова ли поддержка, не пятница ли вечер, в конце концов. Агент может собрать эту информацию и положить передо мной сводку, и он это делает. Но нажать кнопку — значит взять на себя ответственность за последствия. И вот её, как выяснилось, передать некому. Не потому что агент «не готов», а потому что ответственность — это не навык, а отношение между человеком и системой. У агента нет того, что можно потерять, если всё пойдёт не так.

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

Мониторинг стал разговорчивым

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

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

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

Что делает агент в SOC, когда никто не смотрит

Самый новый для меня участок — безопасность. Я разработчик, а не специалист по security, и раньше моё участие в этой области сводилось к тому, чтобы обновлять зависимости после очередного отчёта сканера и не хранить секреты в коде. Сейчас у нас есть агент, который выполняет роль первой линии SOC: разбирает security-алерты, смотрит логи доступа, подозрительную активность в аккаунтах, находки сканеров уязвимостей и находки в коде.

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

И вот здесь граница особенно жёсткая. Агент SOC может читать почти всё, но менять почти ничего. Заблокировать учётную запись, отозвать ключ, закрыть доступ к сервису — всё это действия, которые он предлагает, а выполняет человек. Причина не в недоверии к качеству анализа, а в асимметрии последствий. Ложноположительная блокировка в два часа ночи ломает работу живым людям, а скомпрометированный агент с правами на изменение доступа — это уже не инструмент безопасности, а новая поверхность атаки. Права агента должны быть такими, чтобы его худшая ошибка была неприятной, но не катастрофической.

Где без человека цепочка просто не замыкается

Если пройти весь конвейер целиком, становится видно, что человек остался в нескольких точках, и все они не про код. Первая — постановка задачи. Агенты отлично отвечают на вопрос «как», но вопрос «что и зачем» по-прежнему приходит снаружи. Агент не знает, что эту фичу просил ключевой клиент, а ту можно отложить на квартал.

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

Пятая точка, о которой редко говорят, — права доступа. Кто какому агенту что разрешил, это отдельный слой архитектуры, и его кто-то должен проектировать, пересматривать и помнить. Агенты сами себе права не выдают — и хорошо бы, чтобы так и оставалось. И шестая, главная — ответственность. Когда что-то ломается в проде, вопрос «кто принял это решение» должен иметь ответ с именем и фамилией, а не со ссылкой на конвейер.

Три способа, которыми конвейер нас обманывал

Если собрать всё, что шло не так, получается три устойчивых сюжета. Первый — агенты, согласные друг с другом. Цепочка из нескольких агентов создаёт ощущение многоступенчатой проверки, но если каждый следующий видит выводы предыдущего, это не проверка, а эхо. Пять «одобрено» подряд стоят не больше, чем одно, если все пять опираются на одну и ту же непроверенную фразу.

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

Третий и самый коварный — ложная уверенность. Агент никогда не говорит «я не уверен» так, чтобы это звучало тревожно. Сообщение «миграция безопасна» и сообщение «миграция, вероятно, безопасна, но я не проверил поведение на пустых таблицах» визуально почти одинаковые. А разница между ними — это разница между спокойным вечером и откатом в полночь. Я научился читать отчёты агентов в поисках не того, что они сделали, а того, что они не проверили. Это новый навык, и я не уверен, что освоил его до конца.

Так стал ли я меньше работать?

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

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

Итог

Агенты на всём цикле — от тикета до SOC — это реальность осени 2026-го, и она работает. Типовые задачи проходят путь от постановки до продакшна заметно быстрее, ночные алерты приходят с контекстом, а security-шум больше не съедает неделю. Но картинка «автономной разработки», в которой человек только наблюдает, не соответствует ни одному дню из моего опыта.

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

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