Новый 10x-инженер не пишет 10 раз больше кода. Они строят систему, которая его пишет.

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

Но что-то интересное произошло на пути к будущему, основанному на ИИ: 10x-инженер стал реальным. Они просто выглядят совсем не так, как мы представляли.

OpenAI недавно поделилась информацией о том, как трехчленная команда использовала Codex, чтобы отправить 1 500 запросов на получение изменений и примерно миллион строк кода, не написав ни одной строки вручную. Три инженера и ноль рукописного кода. Продукт, используемый сотнями внутренних пользователей.

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

Я считаю, что это является возникновением новой ключевой функции в инженерных организациях. Я бы назвал ее инженерией оркестровки ИИ.

Три дисциплины входят в стенд-ап

Если вы присмотритесь к тому, что на самом деле делает инженер оркестровки ИИ, вы узнаете три знакомые дисциплины, объединенные в одну.

Самый очевидный ингредиент – DevOps. DevOps централизовал процесс развертывания. Одна команда настраивала рабочие процессы CI/CD, которые каждый инженер использовал при отправке кода. Инженер оркестровки ИИ делает то же самое, но для рабочих процессов агентов. Это определяет, как задачи назначаются агентам, как результаты проверяются, как работают повторы и возвраты. Это общая инфраструктура, на которой работают агенты.

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

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

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

Метафора шоураннера

Режиссер фильма не работает с камерой, не снимается в сценах и не редактирует кадры. Но каждый кадр отражает его решения.

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

Инженер оркестровки ИИ работает так же. Агенты способны. Модели мощные. Но без человека, который проектирует систему, координирующую их, определяющую ограничения, строящую обратные связи, структурирующую рабочие процессы, вы получаете то, что мы все испытали: непоследовательные результаты,浪费 вычислительных ресурсов, агенты, работающие вразнобой, и инженеры, тратящие больше времени на исправление кода, сгенерированного ИИ, чем они бы потратили на написание его сами.

Режиссер делает фильм больше, чем сумма его частей. Инженер оркестровки ИИ делает то же самое для флота агентов.

Почему большинство организаций недоинвестируют

Вот что я вижу в отрасли: компании вкладывают много средств в инструменты ИИ и не достаточно в системы вокруг них.

Инженерам предоставляется доступ к Copilot, Claude, Codex. Они экспериментируют индивидуально. Некоторые становятся опытными пользователями. Большинство достигают плато на уровне “фанковый автозаполнение”. 20% прироста производительности, о котором сообщают исследования? Это симптом внедрения инструментов без системного мышления.

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

Как выглядит эта роль на самом деле

Рабочий день инженера оркестровки ИИ может включать:

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

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

Исторический шаблон

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

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

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

Путь вперед

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

1. Определите, кто уже делает эту работу неформально. В каждой организации есть кто-то, кто уже разобрался с рабочими процессами агентов, к кому другие инженеры обращаются за советом по подсказкам или настройке инструментов. Этот человек – ваш прото-инженер оркестровки ИИ.
2. Сделайте это явным. Дайте функции имя, мандат и ресурсы. Не позволяйте ей оставаться побочным проектом, прикрепленным к “настоящей” работе.
3. Начните с готовности репозитория. Прежде чем инвестировать в сложные рабочие процессы агентов, убедитесь, что ваша кодовая база – это то, что агенты могут действительно ориентироваться. Чистые интерфейсы, хорошая документация, полные тесты, упрощенная архитектура.
4. Централизуйте то, что работает. Когда кто-то обнаруживает стратегию подсказок или шаблон рабочего процесса, который существенно улучшает выход агентов, захватите его. Сделайте его значением по умолчанию для всей команды, а не племенной знанием, запертым в голове одного человека.
5. Измеряйте на уровне системы. Не только отслеживайте индивидуальное использование инструментов. Отслеживайте, сколько задач агенты завершают от начала до конца, как выглядят показатели проверки и доработки, где находятся узкие места.

Новый 10x

Миф о 10x-инженере всегда был о индивидуальных героических поступках. Один человек, превосходящий всех благодаря чистому таланту и кофеину.

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

Они не пишут 10 раз больше кода. Они строят систему, которая его пишет.

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