Пока рынок спорит, сколько разработчиков заменят AI-агенты, Sarah Wells предлагает менее хайповый и куда более полезный вопрос: кто будет держать систему в руках, когда кода станет в разы больше. В подкасте от 13 июля 2026 года governance в разработке описывается не как бюрократия для галочки, а как набор правил, который снижает сложность, повышает безопасность и не дает командам тратить недели на повторение одних и тех же ошибок.
Об этом, как пишет InfoQ, Wells говорила в разговоре с Майклом Штифелем в серии Architects Podcast. Собеседница не теоретик со стороны: у нее более 20 лет опыта в ролях от разработчика и principal engineer до tech director, а больше десяти лет она проработала в Financial Times в период, когда компания прошла путь от 12 релизов в год до более чем 20 000. На этом фоне ее тезис звучит особенно приземленно: хорошее governance в разработке нужно не для того, чтобы мешать командам, а для того, чтобы они вообще могли двигаться быстро без бесконечного самосаботажа.
Ключевой нерв беседы в том, что governance и архитектуру слишком часто разводят по разным углам. В одной комнате сидят архитекторы с диаграммами, в другой команды, которые просто хотят выкатывать продукт и не умереть по дороге. Wells описывает другой подход. Архитектура, по ее словам, должна концентрироваться на технических решениях, которые трудно откатить: выборе фундаментальных паттернов, границ систем, способе взаимодействия сервисов, общих платформенных ограничениях. А вот решения, которые можно без боли отменить или поменять, не требуют недель согласований и комитетов по смыслу жизни. Для зрелых команд это важная мысль: не каждое инженерное решение надо превращать в архитектурный ритуал.
Отсюда и ее отношение к governance. Проблема не в стандартизации как таковой, а в том, как она внедряется. Если централизованная функция спускает правила сверху, не понимая реальной работы команд, разработчики закономерно воспринимают это как красную ленту в корпоративной упаковке. Wells вспоминает, что во время перехода FT к микросервисам именно этот разрыв был особенно заметен: одни команды строили новые сервисы, а централизованные архитектурные группы предлагали решения, которые не всегда совпадали с реальностью продакшена. Но полностью отпустить все на самотек тоже нельзя. Иначе одна команда поднимает один стек, другая другой, третья изобретает свою сборку велосипеда, и через полгода компания обнаруживает, что платить приходится не только за инфраструктуру, но и за организационный хаос.
Wells называет три вполне земные причины, по которым единые правила все же нужны. Первая — безопасность: чем больше произвольных исключений, тем выше шанс, что где-то забудут базовую проверку или проскочит сомнительная конфигурация. Вторая — стоимость: три способа решать одну и ту же задачу почти всегда означают лишние деньги, лишние интеграции и лишние люди на сопровождении. Третья — сложность, а это уже валюта, которую особенно хорошо считают техдиректора и платформенные команды. Когда все устроено по-разному, инженерам сложнее переходить между командами, тяжелее строить внутренние инструменты и почти невозможно быстро тиражировать удачные практики. И вот здесь governance в разработке перестает быть абстракцией из корпоративных презентаций и становится инструментом снижения трения.
Отдельно Wells делает акцент на чек-листах. Звучит не очень героически, зато работает. По ее логике, targeted checklists снижают когнитивную нагрузку на инженеров: не нужно каждый раз вспоминать весь набор процедур по безопасности, эксплуатации или релизу, особенно когда вокруг уже горит прод. В спокойной обстановке такие списки экономят время, а в стрессовых сценариях вроде критических инцидентов буквально уменьшают шанс на глупую ошибку. Для российских команд, живущих между SLA, импортозамещением, требованиями ИБ и вечной нехваткой старших инженеров, это мысль без лишней романтики: надежность часто выигрывает не самый умный, а самый дисциплинированный процесс.
Во второй части разговора тема закономерно уходит к agentic AI и разработке с участием ИИ. Здесь Wells не впадает ни в технооптимизм, ни в привычную оборону цеха. Она признает, что AI-агенты уже полезны для написания кода, сборки внутренних инструментов и автоматизации рутинных задач. Но дальше начинается то, о чем обычно забывают в демороликах. Сгенерировать код недостаточно; кто-то опытный должен проверить тесты, разобрать результат, убедиться, что выводы модели не конфликтуют с системными ограничениями, и заранее описать архитектурные правила, в которых агент вообще имеет право действовать. Более того, от самих агентов, по ее мнению, нужно требовать повышенной критичности к собственной работе. Иначе компания получает не ускорение разработки, а ускорение производства технического долга.
Для рынка это неприятный, но здоровый вывод. Если AI действительно удешевляет написание типового кода, то дефицит смещается не в сторону промптов, а в сторону архитектурного мышления. Нужны люди, которые понимают, какие решения обратимы, какие нет, где нужна свобода команды, а где обязательны жесткие рамки, и как превратить платформу из набора запретов в сервис для разработчиков. Wells прямо говорит, что такой талант придется искать и поддерживать отдельно. И это, пожалуй, самая практичная часть всей дискуссии для CTO, head of engineering и founders: в мире, где код пишется быстрее, цена ошибки в системном дизайне только растет. ИИ сокращает путь до коммита, но не отменяет ответственность за последствия этого коммита на масштабе компании.
Из разговора Wells следует неприятная для любителей простых ответов вещь: победят не те организации, которые первыми подключат очередного AI-ассистента к IDE, а те, которые сумеют выстроить внятное governance в разработке и отделить обратимые решения от необратимых. Иначе индустрия рискует прийти к парадоксу: кода станет больше, выпускать его получится быстрее, а менять и поддерживать все это хозяйство окажется еще дороже, чем до эпохи AI.