Новий 10x Інженер Не Пише 10x Код. Вони Будують Систему, Що Його Пише.

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

Але щось цікаве трапилося на шляху до майбутнього, керованого штучним інтелектом: інженер 10x став реальністю. Він просто виглядає зовсім не так, як ми уявляли.

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

Це не 10x; це ближче до 100x. І навичка, яка зробила це можливим, не полягала в тому, щоб друкувати швидше або знати більше алгоритмів. Це була побудова системи, яка робить агентів продуктивними: робочі процеси, обмеження, цикли верифікації, інтерфейси, до яких агенти підключаються, і люди переглядають через них.

Я вважаю, що це є появою нової ключової функції в інженерних організаціях. Я б назвав це Інженерія Оркестрування Штучного Інтелекту.

Три Дисципліни Ідуть У Стендап

Якщо ви глянуть на те, що насправді робить інженер оркестрування штучного інтелекту, ви впізнаєте три знайомі дисципліни, злиті в одну.

Найбільш очевидна складова – DevOps. DevOps централізував процес розгортання. Одна команда конфігурувала робочі процеси CI/CD, які кожен інженер використовував під час випуску коду. Інженерія оркестрування штучного інтелекту робить те саме, але для робочих процесів агентів. Вона визначає, як завдання призначені агентам, як виходи верифікуються, як працюють повтори та резервні варіанти. Це спільна інфраструктура, на якій працюють агенти.

Потім є архітектура, яка перекривається з DevOps більше, ніж ви б очікували. Архітектори вирішують, які інтерфейси заблоковані, які шаблони застосовуються, які межі не можуть бути перетнуті. У світі, керованому агентами, це має ще більше значення. Агентам потрібні чисті, добре документовані кодові бази з чіткими контрактами. Інженер оркестрування штучного інтелекту визначає ці обмеження, не тільки для людської читабельності, але й для розуміння агентами. Брудна репозиторія вже не тільки технічний борг. Це стеля продуктивності для кожного агента, який до неї торкається.

Менше зрозуміла частина – це шар, специфічний для штучного інтелекту. Інженерія промпта, керування контекстом, вибір моделі, конфігурація агента. Сьогодні більшість інженерів робить це розрізнено, завдання за завданням. Кожна людина вибирає свій власний стиль промпта, свій власний набір інструментів, свій власний спосіб вирішення проблем. Інженер оркестрування штучного інтелекту централізує це. Він будує спільні інструкції, повторно використовувані конфігурації, організаційне знання про те, що працює, а що ні, для моделей і випадків використання.

Відокремлено, ці три функції існують у більшості інженерних організацій сьогодні. Аргумент полягає в тому, що об’єднання їх у одну, централізовану роль створює щось якісно інше.

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

Режисер фільму не оперує камерою, не грає в сценах, не редагує кадри. Але кожний кадр відображає його рішення.

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

Інженерія оркестрування штучного інтелекту працює так само. Агенти здатні. Моделі потужні. Але без когось, хто проектує систему, яка координує їх, визначає обмеження, будує цикли верифікації, структурує робочі процеси, ви отримуєте те, що ми всі пережили: несумісні виходи, марно витрачені обчислювальні ресурси, агенти, які працюють у протилежних напрямках, і інженери, які витрачають більше часу на виправлення коду, згенерованого штучним інтелектом, ніж вони б витратили на написання його самі.

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

Чому Більшість Організацій Недоінвестують

Ось що я бачу в галузі: компанії інвестують великі кошти в інструменти штучного інтелекту та майже не інвестують у системи навколо них.

Інженерам надається доступ до Copilot, Claude, Codex. Вони експериментують індивідуально. Деякі стають досвідченими користувачами. Більшість досягає плато на стадії “фанковий автозаповнення”. 20% продуктивних вигод, про які повідомляють дослідження? Це симптом прийняття інструментів без системного мислення.

Організації, які прориваються, ті, які повідомляють про продуктивність у 2 рази або більше, мають щось спільне. Вони централізували роботу оркестрування. Хтось (або якась команда) володіє робочими процесами агентів, підготовкою репозиторію, інфраструктурою верифікації, спільним контекстом, до якого кожен агент може звернутися.

Як Виглядає Ця Роль Насправді

Робочий день інженера оркестрування штучного інтелекту може включати:

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

Ця людина сидить на перетині платформної інженерії, програмної архітектури та експертизи штучного інтелекту. Вони не пишуть функції. Вони будують систему, яка робить доставку функцій швидкою, надійною та масштабованою.

Історичний Шаблон

На початку епохи хмарних обчислень розгортання було побічним завданням кожного інженера. Кожна команда мала свої власні скрипти, свої власні конфігурації серверів, свій власний спосіб отримання коду у виробництво. DevOps з’явився, щоб централізувати цю роботу, і платформна інженерія розвинулася, щоб побудувати її у спільну, самопослугову інфраструктуру.

Штучний інтелект слідує тому ж арку. Зараз використання агентів є побічним завданням кожного інженера. Кожна людина має свій власний стиль промпта, свій власний набір інструментів, свій власний ментальний модель про те, коли штучний інтелект допомагає, а коли ні. Організації, які централізують це, які розглядають це як інфраструктуру, а не індивідуальні експерименти, випередять інших так само, як організації з досконалими практиками DevOps обгоняли тих, у кого їх не було.

Різниця полягає в швидкості. Перехід до DevOps зайняв десятиліття. Цей перехід може зайняти квартали, хоча я зізнаюсь, що це передбачення припускає, що організації розпізнають шаблон швидше, ніж вони зазвичай роблять.

Шлях Вперед

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

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

Новий 10x

Миф про інженера 10x завжди був про індивідуальні героїчні виступи. Одна людина, яка перевершує всіх іншими завдяки чистому таланту та каві.

Реальність інженера 10x у епоху штучного інтелекту полягає в системному мисленні. Людина, яка робить кожного іншого інженера (і кожного агента) більш продуктивним, будуючи правильну інфраструктуру, правильні робочі процеси, правильні обмеження.

Вони не пишуть 10x коду. Вони будують систему, яка його пише.

Я не певен, що ця роль кристалізується точно так, як я її описав тут. Але я досить певен, що організації, які розгадують шар оркестрування (хай як вони його назвуть), будуть тими, хто насправді реалізує продуктивні вигоди, про які всі інші тільки говорять.