Один программист — целая команда: как опытный разработчик управляет ИИ-агентами

ИИ-агенты меняют разработку ПО: опытный программист параллельно поручает реализацию, тесты, аудит и документацию. Рабочая модель, ограничения и навыки инженера, который управляет исполнителями, а не только пишет код.

Опубликовано: 11 октября 2026 г.

Теги

agentic engineering ИИ ai agents Архитектура Продуктивность Разработка ПО

Содержание

Представьте небольшую стройку без прораба: каждый рабочий тащит кирпичи куда хочет, стены не сходятся, а «почти готово» слышно каждый час. Так часто выглядит день с несколькими ИИ-агентами без человека, который задаёт границы и принимает работу. С прорабом картина другая: один инженер держит план, распределяет задачи, проверяет стыки и решает, что можно выпускать.

Ещё недавно сложный продукт почти автоматически означал большую команду: архитектор, клиентская и серверная части, тестировщики, инженеры эксплуатации, безопасность. Сегодня часть этой работы можно делегировать ИИ-агентам — и один опытный программист способен организовать их так, как раньше организовывал работу нескольких специалистов. Это не магия «модель сама соберёт что угодно». Изменилось другое: у разработчика появились цифровые исполнители с ограниченными правами, которым можно поручать узкие задачи и собирать результат в систему.

Главное преимущество теперь не в том, чтобы быстрее печатать код. Оно в том, чтобы правильно формулировать задачи, проектировать систему, координировать работу агентов и отличать готовое решение от убедительно выглядящего черновика.

Ключевые выводы

Один сильный инженер с агентами расширяет радиус действия, а не заменяет ответственность. Модели пишут код, гоняют проверки и готовят черновики. Человек задаёт границы, принимает риски и подписывает выпуск.

Команда агентов — это роли и контракты, а не пять разных продуктов. Разработчик, тестировщик, ревьюер, документатор и исследователь могут быть разными запусками одного инструмента с разными задачами и доступом к контексту.

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

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

Без прав, тестов и критериев готовности агент — риск, а не ускоритель. Безопасность, миграции, платежи и персональные данные требуют процедур, а не «доверия к модели».

От чата с подсказками — к бригаде исполнителей

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

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

Следующий шаг — не один универсальный помощник, а несколько исполнителей параллельно. На стройке это разные специальности; в репозитории — разные роли:

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

Такое разделение не обязано означать пять разных моделей. Часто один и тот же инструмент запускают несколько раз с разными задачами и доступом к контексту. Важна не численность агентов, а продуманная организация работы — как на стройке важнее график и стыки, чем число людей с лопатой.

Смежную рамку «агент = модель + каркас процесса» я разбирал в материалах про агентную инженерию в 2026 и новый цикл разработки: вайб-кодинг и агентная инженерия.

Почему опытный разработчик получает больше возможностей

На первый взгляд кажется, что ИИ сильнее всего помогает новичкам: описал идею обычными словами — и вот прототип. Для небольших набросков это действительно может сработать. Но чем сложнее система, тем важнее знания, которые не сводятся к генерации кода. Прораб без чертежа не ускоряет стройку — он ускоряет хаос.

Он видит систему целиком

Функция может успешно работать сама по себе и при этом ломать архитектуру. Изменение API затрагивает клиентские модули. Новая таблица нарушает ограничения. Ускорение одного запроса ухудшает поведение под нагрузкой. Агент предложит реализацию; человек оценивает её в контексте данных, контрактов, совместимости и будущих изменений. О том, где модель ошибается на зрелом коде, — в разборе наследия на 15 лет.

Он умеет разбивать большую задачу на независимые части

Запрос «создай корпоративную систему учёта ресурсов» слишком велик и неоднозначен. В такой постановке агент выдаёт впечатляющий прототип, который сложно развивать. Опытный разработчик превращает цель в проверяемые этапы: контракт API, миграция, сервис, интерфейс, тесты, права доступа, интеграция. Часть шагов можно параллелить; часть ждёт результата предыдущих. Это и есть управление бригадой: параллелить независимую работу, а не запускать как можно больше процессов.

Он понимает, что именно нужно проверить

Код, который выглядит правдоподобно, не обязательно корректен. Агент может забыть пустое значение, неверно трактовать бизнес-правило, пропустить проверку доступа или написать тест, который подтверждает ту же ошибку, что и реализация. Поэтому критерии готовности задают заранее: какие тесты обязательны, какие интерфейсы нельзя менять, какие ограничения безопасности критичны, что происходит при сбое. Проверка после патча агента — отдельная дисциплина: ревью кода в эпоху ИИ.

Он направляет работу, а не только принимает результат

Если агент ошибся, опытный инженер быстрее локализует причину: мало контекста, неверный уровень абстракции, противоречивые требования или слишком крупная задача. Вместо бесконечного повторения запроса он меняет условия, уточняет контракт или дробит работу. ИИ не устраняет ценность опыта — во многих задачах он увеличивает радиус действия специалиста, который уже умеет принимать технические решения. Про сдвиг профессии шире — в «Программист в эпоху ИИ».

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

Нужно добавить в существующую систему модуль управления заявками: общий backend, общая авторизация, база данных, интерфейс пользователя. Работа без прораба превращается в пять несовместимых «почти готово». С прорабом цикл выглядит так.

Шаг 1. Человек определяет границы. Изучает архитектуру, фиксирует требования, ограничения, бизнес-правила и критерии готовности. Пишет короткий технический план: сущности и API, файлы, которые можно менять, компоненты, которые должны остаться совместимыми.

Шаг 2. Агент-исследователь изучает репозиторий. Находит похожие модули, соглашения, точки интеграции и затрагиваемые участки. Разработчик проверяет выводы, а не принимает их на веру. Без индексации и контекста модель «дорисовывает» систему из общих паттернов — об этом же в материалах про семантический контекст и языковой сервер.

Шаг 3. Задачи распределяются по исполнителям. Один агент готовит backend и API, другой — интерфейс по согласованному контракту, третий — тесты. Если интерфейс и API нельзя разрабатывать независимо, сначала фиксируют контракт или делают короткий подготовительный этап.

Шаг 4. Результаты проходят независимую проверку. Агент может проверить код другого агента, составить список рисков или предложить дополнительные тесты. Окончательное решение о корректности остаётся за разработчиком. Критичные проверки — тесты проекта, линтеры, статический анализ и CI.

Шаг 5. Человек интегрирует работу. Разрешает конфликты, проверяет согласованность, запускает систему, проходит реальные сценарии и решает, готов ли результат к выпуску.

В этой схеме разработчик не выполняет вручную каждую операцию. Он управляет процессом и тратит больше времени на архитектуру, постановку задач, риски и приёмку. Платформа вокруг агентов (трекер, среды, данные, инструменты) часто важнее «ещё одной быстрой модели» — см. агентам нужна платформа, а не только скорость.

Экономика разработки: не число агентов, а пропускная способность

У модели «один инженер — бригада исполнителей» есть несколько преимуществ.

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

Параллельная работа независимых задач. Несколько агентов одновременно изучают разные части проекта или готовят изолированные изменения — когда границы ответственности ясны.

Быстрее обратная связь. Ранние черновики, тесты и ревью помогают поймать проблему до того, как решение обрастёт лишним кодом.

Дешевле эксперимент. Проще сравнить два подхода, подготовить прототип, исследовать незнакомую библиотеку — не превращая каждый эксперимент в отдельный большой проект.

Но разработка не ускоряется пропорционально числу агентов. Координация, проверка и интеграция тоже стоят времени. Если задачи тесно связаны, исполнители мешают друг другу, дублируют работу или создают несовместимые решения. Исследования про скорость человека и модели часто расходятся именно потому, что измеряют разное: генерацию фрагмента или выпуск в зрелый репозиторий — см. человек vs ИИ: кто быстрее пишет код.

Правильная цель — не максимальное количество агентов, а максимальная полезная пропускная способность процесса: сколько проверяемых изменений доходит до пользователей без роста аварий и долга.

Что нельзя отдавать на безусловное доверие

ИИ-агенты ошибаются, неверно понимают требования, выдумывают несуществующие API, упускают редкие сценарии и уверенно объявляют задачу завершённой, хотя проверка не пройдена. Особенно осторожно — безопасность, миграции данных, платежи, персональные данные и критичные производственные системы.

Надёжный процесс держится на нескольких правилах:

Минимально необходимые права. Агент получает доступ только к файлам, инструментам и средам, нужным для задачи. Про изоляцию и риски — в песочницах Docker для ИИ-агентов.
Проверяемые критерии завершения. «Код написан» не равно «функция работает». Нужны тесты, определённые сценарии и наблюдаемый результат.
Независимая проверка. Рецензирование агентом полезно, но не заменяет тесты, статический анализ, человеческое ревью и контроль в CI.
Понятные границы изменений. Небольшие задачи и изолированные ветки снижают конфликты и упрощают откат.
Контроль важных решений. Архитектура, секреты, данные и выпуск в продакшен требуют процедур согласования, а не «модель сказала, что всё хорошо».

Практика длительных агентных процессов показывает: нужна организованная среда — понятные инструкции, проверяемый список задач, возможность запускать приложение и тесты, способ сохранять прогресс между сессиями. Иначе даже сильная модель теряет контекст или преждевременно считает работу законченной. Внешние ориентиры по «обвязке» агентов: материалы Anthropic про обвязку длительных агентных сессий и документация OpenAI по координации нескольких исполнителей.

Новый навык — инженерное управление ИИ

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

В навык входят:

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

На стройке это умение вести журнал работ и не пускать бригаду в несущую стену без чертежа. В репозитории — то же самое языком git, CI и контрактов. Когда контекст собран плохо, модель уверенно ошибается; когда собран хорошо — ускоряет рутину, не разрушая архитектуру.

Заменит ли один программист целую команду?

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

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

Правильнее сказать иначе: опытный программист получает возможность управлять большим объёмом инженерной работы, чем мог бы выполнить лично. Ограничение смещается от скорости написания кода к качеству постановки задач, организации процесса и проверке результата. Преимущество — у того, кто быстрее превращает неопределённую идею в понятную систему требований, безопасно делегирует работу и выпускает проверяемые изменения.

Типичные ошибки при работе с несколькими агентами

Слишком крупная первая задача. «Сделай модуль целиком» почти всегда даёт красивый, но хрупкий черновик. Начните с контракта и одного вертикального среза.

Общие файлы без координации. Два агента правят один и тот же сервис — получаете конфликты и несовместимые стили. Сначала границы владения файлами, потом параллелизм.

Ревью агентом вместо тестов. Второй агент находит стилистику и часть багов, но не заменяет прогон сценариев и человеческий взгляд на бизнес-правила.

Права «как у разработчика». Полный доступ к секретам и продакшену ради удобства — прямой путь к инциденту. Минимальные права дешевле любой сэкономленной минуты.

Метрика «сколько агентов запущено». Это суета, не результат. Считайте принятые изменения, время до зелёного CI и число откатов.

С чего начать на этой неделе

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

Попросите агента изучить модуль и составить план, не меняя файлы.
Выберите одну небольшую задачу с чёткими критериями готовности.
Поручите реализацию и попросите показать изменённые файлы и обоснование решений.
Запустите тесты и проверьте изменения самостоятельно.
Только после этого добавьте второго агента — для тестирования или ревью — и сравните, стал ли процесс лучше.

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

Частые вопросы

Чем ИИ-агент отличается от обычного чата с моделью?

Чат отвечает на вопрос и отдаёт текст. Агент работает в цикле: смотрит репозиторий, меняет файлы, запускает команды, читает результат и продолжает. Разница — в доступе к инструментам и длине автономного шага, а не в «другой магии модели».

Нужны ли пять разных моделей для пяти ролей?

Нет. Часто достаточно одного инструмента с разными задачами, разным контекстом и разными правами. Роль задаёт постановка и границы, а не логотип на вкладке.

С чего безопаснее начинать новичку в агентах?

С задач без доступа к секретам и продакшену: исследование модуля, черновик тестов, документация, небольшой рефакторинг в изолированной ветке. Критерии готовности и тесты — до любой параллельной работы.

Когда параллельные агенты вредят больше, чем помогают?

Когда задачи делят одни и те же файлы, контракт ещё не зафиксирован или приёмка сводится к «выглядит нормально». Сначала независимые куски и явные критерии, потом параллелизм.

Заменит ли это junior-разработчиков?

ИИ автоматизирует часть задач, на которых раньше учились. Растёт ценность тех, кто умеет ставить задачи, проверять результат и держать архитектуру. Вход в профессию становится жёстче, а не исчезает — подробнее в статье про программиста в эпоху ИИ.

Что делать, если агент уверенно врёт про API?

Не спорить в чате бесконечно. Сузить задачу, дать точный контекст из репозитория, потребовать ссылку на файл или тест и проверить утверждение инструментом проекта. Уверенный тон модели — не доказательство.

Как связать это с корпоративными процессами?

Через те же ворота, что и для людей: ветки, ревью, CI, ограничение прав, журнал решений. Агент — ещё один исполнитель в существующем конвейере, а не обход процедур.

Дальнейшее чтение

Внутри блога полезны соседние материалы по агентам, контексту и качеству:

Внешние ориентиры по оркестрации и длительным агентам:

Заключение

ИИ-агенты не делают инженерное мышление ненужным. Чем больше действий можно делегировать, тем важнее понимать, какую систему мы строим, почему она должна работать именно так и как доказать, что результат корректен.

Опытный разработчик будущего — не обязательно человек, который пишет весь код руками. Это инженер-прораб: задаёт направление, распределяет работу между инструментами и агентами, удерживает архитектуру целостной и обеспечивает качество итогового продукта. На этом сайте мы рассматриваем ИИ-разработку как практическую инженерную дисциплину — от устройства моделей и организации контекста до тестирования, архитектуры и рабочих процессов. Такой подход позволяет пользоваться возможностями ИИ, не отказываясь от контроля над кодом и результатом.

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

Кто ведёт эту лабораторию и какие проекты стоят за практикой — в резюме.

Химия кода