### A11 ищет Директора по инжинирингу. А что, если его можно не нанимать, а «написать»?

На днях наткнулся на интересную вакансию в Linkedin. Рекрутинговое агентство A11 ищет для своего клиента, быстрорастущего Legal Tech стартапа, Директора по инжинирингу. Позиция в Милане, все как мы любим: опционы, гибрид, амбиции изменить мир.

**Кратко о компании:**
Это европейский Legal Tech стартап, который создает AI-софт для юристов. Их продукт помогает юридическим фирмам быстрее анализировать, исследовать и составлять документы, опираясь на верифицируемые источники. Компания уже привлекла финансирование, у них есть продукт, клиенты и команда из 30 инженеров. Они делают AI для других. Запомним этот факт, он важен.

**Какую боль пытаются решить?**
Все до банального просто и знакомо каждому, кто проходил стадию роста от Series A к B. Компания хочет масштабироваться. В планах — выход на рынки Германии, Испании, далее везде. Продукт усложняется, количество фич растет. И классический ответ на этот вызов — нанять больше людей. Вакансия прямо говорит: «Scale the engineering organization… from 30 to 60+ engineers».

То есть, ищут опытного «вожака», который придет и удвоит команду. Он должен будет выстроить процессы, наладить конвейер поставки фич, следить за качеством кода, менторить, мотивировать, участвовать в стратегических сессиях с CTO… Словом, делать все то, чем обычно занимается дорогой и опытный Engineering Director. Боль компании — это страх, что при росте х2 все развалится: скорость упадет, техдолг задушит, а лучшие инженеры выгорят и разбегутся. И они пытаются закрыть этот страх одним человеком. Очень по-человечески. И очень неэффективно в 2024 году.

**Как можно было бы решить задачу с помощью ИИ?**
Ирония в том, что компания, строящая AI-продукты, решает свою внутреннюю проблему масштабирования самым консервативным, «до-AI-шным» способом — экстенсивным ростом штата. А что, если вместо того, чтобы нанимать менеджера для управления армией из 60 человек, вложить часть его годового оклада в создание «AI Engineering Director»? Не в виде человекоподобного робота, конечно, а в виде системы, которая возьмет на себя 80% функций, перечисленных в вакансии.

Давайте представим диалог в переговорке этого стартапа.

—

**София (HR):** — Марко, нам нужен сильный лидер. Человек с опытом масштабирования команд в 3-5 раз. Он построит нам процессы, будет следить за качеством, мотивировать ребят… Мы найдем лучшего!

**Марко (CTO, смотрит в окно):** — София, мы ищем человека, который будет следить, чтобы 60 человек эффективно писали код. Который будет отвечать за code quality, testing, deployment reliability. Мы хотим удвоить нашу производительность. Так?

**София:** — Именно! Он принесет экспертизу, поставит все на рельсы.

**Марко:** — А что, если я скажу тебе, что нам не нужно еще 30 инженеров и директор над ними? Что, если наши текущие 30 инженеров могут работать с эффективностью 70-ти? И для этого нам не нужен «вожак», а нужна система. Мы же AI-компания, в конце концов. Давай применим наши же принципы к самим себе.

—

**Подходы и инструменты: Собираем нашего «AI Директора»**

Вместо того чтобы искать одного человека-оркестра, давайте декомпозируем его задачи и найдем для каждой AI-инструмент. Наш «AI Директор» — это не один сервис, а интегрированная система, вшитая в процессы разработки.

1. **Масштабирование производительности (вместо найма +30 инженеров):**
* **Задача:** Удвоить инженерную мощность.
* **AI-решение:** Вместо того чтобы нанимать 30 джунов и мидлов, покупаем на всю команду лицензии GitHub Copilot Enterprise, Cursor или даем доступ к Claude 3 Opus через API. Обучаем кастомную модель на всей кодовой базе проекта. Эффект? Каждый разработчик получает личного ассистента, который знает контекст проекта. Написание кода, юнит-тестов, документации, рефакторинг — все это ускоряется в 2-3 раза. Наши 30 инженеров начинают перформить как 60-70. Мы экономим на зарплатах, онбординге, налогах и увеличении офиса.

2. **Архитектура и Техническая стратегия (функция “Owning architecture”):**
* **Задача:** Проектировать масштабируемые системы, следить за техдолгом.
* **AI-решение:** Используем LLM как архитектурного «спарринг-партнера». Прежде чем принять решение, команда «обсуждает» его с моделью, обученной на лучших практиках и архитектурных паттернах. «Мы хотим внедрить новый сервис для процессинга документов. Какие есть риски? Предложи 3 варианта архитектуры с плюсами и минусами». Для контроля техдолга внедряем AI-инструменты статического анализа (вроде Code-GPT или кастомных решений), которые не просто ищут ошибки, а предсказывают, какие части кода с наибольшей вероятностью вызовут проблемы в будущем.

3. **Инженерная культура и качество (функция “Championing engineering excellence”):**
* **Задача:** Поддерживать высокое качество кода, тестов, процессов CI/CD.
* **AI-решение:** Автоматизированное Code Review. На каждый pull request запускается AI-агент, который проверяет код не только на стиль (это делает линтер), но и на логику, потенциальные баги, соответствие архитектурным гайдлайнам. Он не блокирует мердж, а оставляет комментарии-рекомендации, как это делал бы тимлид. Это снимает огромную нагрузку с сеньоров и стандартизирует подход к качеству. Генерация тестовых сценариев и данных также перекладывается на ИИ.

**Как снизить недоверие и внедрить?**

Конечно, инженеры встретят это с недоверием. «Робот будет учить меня код писать?». Внедрять нужно поэтапно:

* **Шаг 1: Инструменты-помощники.** Начинаем с Copilot/Cursor. Это персональные инструменты, они никого не контролируют, а только помогают. Собираем фидбэк, измеряем velocity команды до и после. Показываем цифры.
* **Шаг 2: AI-ревьюер в режиме “советника”.** Запускаем AI-анализ PR, но его комментарии носят исключительно рекомендательный характер. Пусть команда сама решит, полезны ли они. Через месяц 90% инженеров не смогут без этого жить.
* **Шаг 3: Интеграция в стратегию.** Подключаем AI-аналитику к Jira/GitHub для анализа бэклога, выявления узких мест в процессе и прогнозирования сроков выполнения задач. Это уже уровень помощи CTO и Product-менеджерам.

**Как валидировать результат?**

Эффективность нашего «AI Директора» измеряется проще и объективнее, чем работа живого человека.

* **DORA metrics:** Смотрим на Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, Change Failure Rate. С внедрением AI-инструментов эти метрики должны кардинально улучшиться.
* **Стоимость владения:** Сравниваем стоимость годовой подписки на все AI-сервисы (допустим, $50-100k) со стоимостью годовой зарплаты Директора + 30 инженеров (несколько миллионов евро). ROI будет исчисляться тысячами процентов.
* **Удовлетворенность команды:** Проводим опросы. Инженеры, избавленные от рутины, написания бойлерплейта и бесконечных ревью, становятся счастливее и могут фокусироваться на сложных, творческих задачах.

Вместо того чтобы искать одного супергероя, который будет тащить на себе всю сложность роста, можно построить систему, которая сделает всю команду супергероями. И это, на мой взгляд, куда более надежная и масштабируемая стратегия. Особенно для компании, которая продает AI как будущее. Ведь будущее нужно начинать с себя.