Больше AI-кода не ускорило команду. Charity Majors всё равно целилась в 2×.

Больше AI-сгенерированного кода не делает вашу команду быстрее. Он может вас реально замедлить.

Это не анти-AI позиция. Это Charity Majors—сооснователь и CTO Honeycomb—описывает, что происходит, когда генерация масштабируется, а всё ниже по потоку — нет. Honeycomb строит инструменты observability для сложных production-систем. Если кому-то и доверять нарративу скорости, то им. Они всё равно выбрали цель продуктивности 2× вместо погони за 10× и написали AI-ценности раньше мандатов.

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

Писать код никогда не было сложной частью

Majors говорит это прямо годами, задолго до моды на generative AI: писать код не было ограничением при shipping. Review, интеграция, deployment, incident response и видимая клиенту надёжность — были.

AI усиливает то, что у вас уже есть. Сильная observability и дисциплина release превращают codegen в рычаг. Слабый фундамент — в шум, который всё равно придётся исправлять при ночных on-call-оповещениях.

Поэтому компания, чей бренд — «видеть, что делает production», меньше беспокоится о нажатиях в час и больше — может ли кто-то владеть тем, что уходит в прод.

Почему Honeycomb выбрала 2×, а не 10×

Honeycomb приняла компанийный челлендж 2×—по образцу похожего push в Intercom—не как трюк, а как честный потолок. Удвоить impact с AI за год. Не десять раз больше токенов. Не десять раз больше смерженных строк.

Emily Nakashima, VP Engineering в Honeycomb, описывала rollout публично: memo основателей с поощрением экспериментов, затем повторяющийся вопрос инженеров—как вы это измерите?

Ответ Honeycomb поучителен для тех, кто копирует memo «10× engineer» из соцсетей:

• **Снижать акцент на одиночных метриках**, приглашающих к gaming—расход токенов, строки кода, число PR
• **Доверять self-reporting** о том, действительно ли AI увеличил impact, а не активность
• **Считать 2× направлением**, а не квотой, которую можно выполнить, сливая невладеемый output в main

Нарративы 10× звучат смело в board deck. 2× с accountability переживает контакт с production.

AI-ценности сильнее AI-мандатов

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

Фраза, которая быстрее всего летит по engineering Twitter, — и самая операционная:

• **У каждого AI-вывода должен быть человеческий владелец.** Если не хотите своё имя на нём — скорее всего, это не хорошая работа.
• **Качество сначала, количество потом.**

Читайте это как policy, не поэзию. Ownership — как не дать узкому месту сместиться с «набора» на «изменения кода, которые никто не отлаживает». Тот же инстинкт, что и treat agent output как vendor code—только vendor здесь — ваша команда в хороший день.

Мандаты без ценностей дают театр: все используют tool достаточно, чтобы выглядеть занятыми, никто не улучшает путь release, и инциденты в production накапливаются из-за изменений кода, которые никто не может полностью объяснить.

Что реально двигает узкое место

Если генерация дешёвая, инвестируйте туда, где генерация никогда не была проблемой:

• **Cadence release и ясность rollback**—кто может откатить agent-assisted код ночью при on-call-оповещении без chat log?
• **Observability на путях, которые трогает AI**—auth, платежи, запись данных, сторонние интеграции
• **Глубина review на интеграции**, не синтаксисе—ведёт ли себя изменение под реальным трафиком?
• **Готовность on-call**—может ли on-call-инженер объяснить feature без истории промптов?

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

Веб-агентства и продуктовые команды чувствуют это в меньшем масштабе: лендинг клиента с сломанной формой — не «AI failure». Это shipping failure, который начался в окне чата.

Практический чеклист 2× для веб-команд

Не нужен stack Honeycomb, чтобы использовать ту же дисциплину:

• Один **ограниченный** эксперимент за спринт—один funnel, одна интеграция, один perf fix—не «AI везде»
• Именной **человеческий владелец** на каждом agent-assisted PR до merge; нет владельца — нет ship
• Мерить **cycle time до production**, не сгенерированные слова
• Отслеживать **инциденты или reverts** на AI-путях ежемесячно; эта кривая важнее графиков токенов
• Написать три **AI-ценности**, с которыми согласна команда; короче policy doc, сильнее tool mandate

Цель 2× реалистична. Цель 10× — в основном заголовок. Реалистичные цели набирают импульс со временем.

Вывод вразрез

Charity Majors не сказала инженерам печатать меньше. Она сказала владеть больше—and целиться в impact, который переживёт отладку.

Больше AI-кода без человеческой ownership не ускоряет команду. Оно удлиняет очередь инцидентов. Выбирайте 2× с ценностями, не 10× с метриками, которые выглядят впечатляюще, но не измеряют реальный impact. Нужно второе мнение, где agent speed помогает—or обгоняет ваш release и review loop на маркетинговом сайте или product frontend? Напишите.