Мифический человеко-месяц

Ещё 20 лет назад, когда начинал свою карьеру программистом, прочитал немало книг по управлению разработкой. Среди них легендарная книга «Мифический человеко-месяц» Фредерика Брукса, написанная ещё в 60-х или 70-х годах. Брукс управлял разработкой OS/360 в IBM, даже я никогда не сталкивался с этим динозавром.

Так вот, основная мысль этой книги — что нельзя менять человека на месяцы и месяцы на человека. Если один разраб делает задачу 12 месяцев, то 12 разрабов сделают эту работу за 1 месяц — такая модель, по мнению Брукса, неверна (всё как с беременными). Причина, как описывает автор, кроется в бесконечных коммуникациях и разделении ответственности между участниками проекта.

Также Брукс говорит, что серебряной пули не существует: проектирование логики и связей — это сущностная модель любой разработки, и её не могут заменить никакие инструменты или языки программирования.

С чем я столкнулся на своей практике в Гибриде. 3 года назад мы кратно увеличили бюджет на разработку, в людях — это буквально в десятки раз: несколько групп разработки, девопсы, системные аналитики, QA-отдел и т. д. Всё было призвано к тому, чтобы ускорить TTM наших идей. Но на деле скорость выросла не в 10x и даже не в x5. В лучшем случае в 2 раза. Я всегда помнил эти законы Брукса, но в реальности каждый раз рука тянулась к масштабированию людей, хотя и понимал, что эффекта от этого будет несоизмеримо меньше.

Но текущий кризис и эра искусственного интеллекта расставили всё на свои места.

На майских каникулах я практически целые дни проводил в различных агентских платформах. Я поставил цель в одного сделать MVP продукта, отработать все циклы разработки от идеи до CI/CD-процессов и масштабирования продукта в проде. После этого я понял, что конвейерная разработка больше НАХУЙ не нужна.

Брукс был прав: основной затык такой разработки — это коммуникация, согласования, конфликты ответственности и т. д. Каждая человеческая проблема решается другими людьми и автоматически порождает еще две. Всё это в AI-инжиниринге сведено к минимуму. Я сделал, через полчаса проверил, увидел ошибку — исправил — профит. Цикл выпуска фичи снизился с недель до нескольких часов.

Вот основные принципы, которые я выявил при внедрении AI-инжиниринга в компании:

1. В разработку должны быть вовлечены не только технические инженеры, но и руководители и продакты. Всё начинается с планирования и бизнес-требований, и здесь кроется самый большой затык в классическом конвейере: чтобы перевести с бизнес-требований на технический язык, мы как компания тратим чуть ли не треть наших ресурсов. И вполне логично не усиливать разработчиков Claude Code, а вовлечь бизнес непосредственно в разработку. На мой взгляд, это самый большой импакт, который может быть получен от ИИ-агентов.

2. Команда больше не делится на фронт, бэк и т. д. Один человек, вооружившись AI-агентом, может выполнять любую роль. Я в одного могу поддерживать любой продукт, где необходимо как минимум 6 человек. Это точка роста для всех разработчиков в классических конвейерах. Раньше всех пугало слово «универсальность», т. к. это означало заведомо худшую квалификацию в каждой из специализаций. Но AI-инжиниринг — это не то же самое, что и фуллстек.

3. QA — это не сотни тестировщиков, а сотни агентов, которые за ЗП одного тестировщика могут 24/7 тестировать продукт, тыкать кнопки интерфейса, даже если UI поменялся. И главное: за счёт ускорения поставки до потребителя любой баг фиксится за считанные часы. Лучшие тестировщики — это ваши пользователи. Обратите внимание, как часто обновляется Claude Code или Codex: 1–2 раза в день. Не говорит ли это о том, что в их пайплайне отсутствует армия тестировщиков?