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

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

Автор статьи, источник: InfoQ

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

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

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

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

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

Основные идеи следующие:

• Не исправляйте код, созданный агентом, исправьте систему, которая генерирует этот код.
• Если в вашей команде кто-то все еще использует «дикую» методику vibe coding с подходом «YOLO (сначала запустим, потом разберемся)», вам следует немедленно остановить это. Инженерные практики важны не только для поддержки вашей системы, но и для постоянного улучшения самого агента.
• Темная фабрика может быть не полностью темной, а сохранять немного света (dim factory), что означает, что вам нужно решить, какой риск вы готовы принять для каждой функции — не все функции подходят для полной автономии.
• Того, кого вы ищете, — это человек, который может максимально эффективно использовать ИИ, обладает прочной инженерной базой и готов делиться знаниями и сотрудничать.
• Ваша конкурентная защита — это захваченные и закрепленные знания, те бизнес-контексты, которые вы сейчас вкладываете в skill, Context и даже ограничения Harness.

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

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

И сейчас Темная фабрика столкнулась с тем же самым сопротивлением.

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

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

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

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

Я предполагаю, что большинство из вас работают в команде, а не в одиночку, и командная работа — это совсем другое дело, чем просто сидеть и печатать что-то в Claude Code.

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

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

Позже появилось понятие «инженерия контекста», что дало разработчикам некоторое облегчение. Оно означает, что это не просто вызовы Prompt — вам также нужно тестировать, оценивать, распространять и оптимизировать Prompt, поэтому действительно присутствует некоторый оттенок инженерии. Но честно говоря, многие разработчики всё ещё чувствуют пустоту от работы исключительно с Prompt и SPEC и ощущают себя не инженерами, а «администраторами промптов».

Но на практике я заметил интересный поворот: когда мы начали внедрять Harness, циклы и даже направлять всю организацию к более высокому уровню автономии, открылся совершенно новый технический путь. Внезапно разработчики стали помогать агентам создавать инструменты — и это мгновенно вдохновило группу людей. Те, кто раньше думал: «Это не моё дело», — вдруг оживились. Они сказали: «Да, мы можем это сделать! Мы обладаем этими знаниями! Мы можем улучшить эту систему с помощью программирования». Получается, интересно, что, когда мы всё время говорили «абстрагируйтесь, абстрагируйтесь, ещё больше абстрагируйтесь», ощущение «ремесленности» вдруг возродилось в другом месте, открыв новое пространство для более сложной инженерной работы.

Мне часто задают вопрос: как справиться с людьми, скептически настроенными к этому? Мой ответ всегда один: эти люди — ваши сокровища. У них в голове накоплено огромное количество скрытых знаний и опыта, которые вам нужно вложить в агента. Вы можете сказать им: «Пожалуйста, изложите все свои знания и критические замечания» — это сделает агента и Harness лучше. Если вы сталкиваетесь с теми, кто упорно сопротивляется и постоянно жалуется: «Код, который генерируется, имеет слишком низкое качество», — используйте их как топливо: превратите эту злость и скептицизм в движущую силу для улучшения системы.

Теперь я хочу дать совет разработчикам компании: сделайте огромный сдвиг в мышлении — перестаньте исправлять код, генерируемый агентом, и начните исправлять систему, которая этот код генерирует. Как несколько лет назад кто-то сказал: «Не создавайте этот объект, создавайте то, что создает этот объект». Сейчас мы находимся именно на этом уровне абстракции, создавая «инструмент для создания» через контекст, харнесс и циклы. Тем, кто все еще находится на уровне «человек в цикле», автодополнения и настройки промптов, нужно задуматься, как подняться до системного мышления.

Нам действительно нужно минимизировать количество вмешательства человека с помощью хороших инженерных практик. В начале всем казалось, что «vibe coding» — это круто: задаешь промпт, получаешь результат — и дальше бежишь, не заморачиваясь. Но теперь все яснее становится, что мы не просто даем агенту команды через промпты — мы на самом деле говорим: «Пиши код вместе с тестами», «Обновляй документацию», «Соблюдай стандарты кодирования». Все те слова, которые мы раньше говорили хорошим инженерам, теперь мы полностью переносим на агентов. Если в вашей команде кто-то все еще использует «дикую» методику «YOLO (сначала запустить, потом разбираться)» для vibe coding, вы должны немедленно это остановить. Инженерные практики важны не только для поддержки вашей системы, но и для того, чтобы агенты постоянно улучшались.

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

На плановой встрече я также заметил интересное разделение. Задачи, которые четко определены и имеют достаточно ясные рамки, можно напрямую передать агенту, поскольку Harness становится все лучше и лучше — они справляются с такими четкими задачами. А те задачи, где границы неясны и требуют обсуждения, остаются за людьми. Таким образом, на плановой встрече возникло естественное разделение труда: эти карточки идут по потоку агента, а эти карточки мы обсудим сами.

Разработчики обычно проходят цикл обучения: сначала изучают Prompt, затем лучшие SPEC, далее Context, Harness и циклы — вся отрасль проходит через этот цикл. Но то, что может сделать лидер команды, — это задать темп и ограничения для этого процесса, например, сказать им: «Перестаньте настраивать Prompt, сделайте Context переиспользуемым». «Отлично, этот этап завершен, переходим к следующему». Ценность лидера команды как раз в установлении такого темпа — если вы просто бросите фразу «разбирайтесь сами», это не сработает.

Существует также побочный эффект: как только производительность вашей команды начнёт резко расти, люди вниз по цепочке, например, занимающиеся GTM (Go to Market), не смогут успевать, и даже пользователи могут не успевать. Поэтому вам нужно использовать автоматизацию, чтобы помочь им — ваша система не должна останавливаться на этапе кодирования, она должна быть расширена до их области. То же самое относится и к входящим требованиям сверху: если требования поступают недостаточно быстро, команда застрянет, и эти этапы также необходимо включить в новый рабочий процесс.

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

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

Команда платформы — это типичная совместная организация, которая сейчас, возможно, занимается инфраструктурой, облачными сервисами, шлюзами MCP и т.п., не уделяя особого внимания агентам. Однако появляется множество новых задач, которые им предстоит взять на себя: например, реестр навыков (чтобы никто не изобретал одни и те же навыки в своих углах), система оценки контекста (насколько полезен этот контекст? Можно ли его количественно измерить?), а также специализированные механизмы защиты и управления идентичностью для кодирующих агентов (от имени кого агент отправляет код? Где проходят границы его полномочий?). Поэтому команде платформы нужна поддержка, чтобы помочь им перейти на эту новую центральную роль.

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

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

Но проблема в том, что если каждый сможет произвольно загружать что-то в этот централизованный репозиторий, это быстро превратится в хаос. Например, кто будет поддерживать skill, который был загружен? Другой человек создаст форк похожего skill — и какой из них выбрать? Поэтому необходимо, чтобы у каждого направления был четко определенный ответственный, который обеспечит, чтобы этот элемент был тестируемым и модульным, позволяя другим расширять Context или секцию безопасного сканирования в Harness. Это должно делаться централизованно, а не передаваться случайным образом внутри организации.

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

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

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

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

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

Привлечение помощи — тоже головная боль. Современные названия должностей — полный хаос: инженер по продуктам ИИ, forward deployed engineer, агентный инженер, инженер по ИИ… Эти термины на самом деле не несут реального смысла. По названию невозможно определить уровень зрелости человека, потому что вся отрасль еще не созрела. Однако при размещении вакансий эти слова действительно создают определенные сигналы и привлекают заинтересованных кандидатов, хотя сами по себе они не гарантируют наличие у кандидата соответствующих навыков. Я слышал и еще более странные истории: некоторые кандидаты во время собеседований используют ИИ, который в реальном времени шепчет ответы им в ухо — когда интервьюер задает вопрос, через AirPods приходит совет от ИИ.

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

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

Отделу инженерии нужно отчитаться перед руководством. Мы купили столько лицензий — можно ли доказать окупаемость вложений? Ускорилась ли доставка? Возможно, были обещания, но трудно это подтвердить. Улучшилось ли качество? Тоже сложно утверждать. Но вернемся к двум показателям, о которых я говорил ранее: вы можете продемонстрировать, насколько сократилось количество вмешательств, насколько улучшились результаты и насколько вырос коэффициент повторного использования. Это гораздо проще и убедительнее, чем сравнивать «производительность кодирования с агентом и без него».

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

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

В конечном счете, теневая фабрика может быть не полностью теневой, а сохранять немного света (dim factory), что означает, что вам нужно решить, какой уровень риска вы готовы принять для каждой функции — не все функции подходят для полной автономии. Вы можете инвестировать больше в аудит, например, отслеживание: кто изменил код? Человек или агент? Добавьте валидаторы для проверки, действительно ли код полезен, и инвестируйте в способность к контекстному восприятию при сбоях автоматических процессов. От полного микроменеджмента (каждая строка кода должна быть проверена человеком) до полной автономной одобрения (предположение, что все результаты агента верны) — это целый спектр. Ваша задача — выбрать разный уровень автоматизации для разных типов изменений в зависимости от уровня риска.

А я считаю, что ваше конкурентное преимущество — в улавливании накопленных знаний, тех бизнес-контекстов, которые вы сейчас вкладываете в Skill, Context и даже в ограничения Harness. Для меня это фактически превращает непрерывную доставку в непрерывное обучение. Задайте себе вопрос: насколько быстро мы можем заменить новое в системе и вывести старое? Это ваша реактивная способность. Если вы сможете постоянно улучшать эту способность, ключевой вопрос перестанет быть «Как сделать всю систему более надежной?» и станет «Смогу ли я сохранять надежность системы, одновременно изменяя все больше ее частей?»

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