От личной магии
к инженерному процессу

Нельзя нормально экспериментировать с пайплайнами

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

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

Нельзя сравнить инженерный процесс

Один тратит $20 на Cursor, другой — $200 на Claude. У одного пять этапов контроля, у другого один промпт по номеру Jira. Снаружи у обоих просто закрыта задача.

У каждого разработчика свой закрытый заводик

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

Разработчик стал менеджером маленького отдела, но весь его менеджмент лежит вне трекера.

Опыт передаётся как фольклор

«Попробуй этот промпт», «дай больше контекста», «запусти через Opus, потом через Codex». Реальную сессию, ошибки и вмешательства человека обычно никто не видит.

Нельзя доказать, что пайплайн стал лучше

«Я улучшил skill в два раза» — это ощущение, пока нет общей выборки задач и понятного критерия сравнения старой и новой версии.

У агентских конфигураций нет регрессионного тестирования — только впечатления разработчиков.

Нет ясных прав и ответственности

Агенту нужны shell, репозиторий, Jira, CI, секреты и иногда production-логи. Но границы полномочий чаще определяются случайным набором доступов на машине разработчика.

У проекта нет единого истинного контекста

В документации написано одно, в коде уже другое, в skill третье, а в голове у лида четвёртое. Каждый агент начинает работу со своей версией реальности.

Проблема не в количестве контекста, а в том, что никто не отвечает за его истинность.

Десять агентов не становятся командой автоматически

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

Ошибки агентов не превращаются в знания

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

Экспертиза другой команды недоступна как инструмент

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

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

У проекта нет общей памяти работы агентов

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

План не считается артефактом задачи

Код хранится в Git, тесты — в CI, комментарии — в Jira. План, определивший архитектуру и реализацию, остаётся временным текстом в локальном чате.

Мы видим ошибку плана только после того, как она превратилась в код.

Plan review скрыт, а code review происходит слишком поздно

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

Мы не знаем, полезен ли сам Plan and Act

Одни разработчики всегда требуют отдельный план. Другие сразу дают задачу агенту и итеративно доводят результат. Оба лагеря опираются главным образом на личные ощущения.

Пока подход не измерен, это не best practice, а популярная привычка.

Исправление ответа агента не улучшает систему

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

Конкретная задача исправлена. Причина класса ошибок осталась на месте.

Разработчик работает прокси между агентом и командой

QA или серверный программист задаёт вопрос. Разработчик копирует его агенту, ждёт ответ и копирует ответ обратно в мессенджер.

Агенты разных команд не могут работать друг с другом

Клиентский агент знает клиентский код и ограничения UI. Серверный агент знает модели данных и backend conventions. Между ними нет общего рабочего пространства.

Два агента существуют рядом, но договариваться между ними снова должны люди.

У межкомандной агентской работы нет общего владельца и бюджета

Клиенту и серверу полезно совместно исследовать задачу несколькими сильными агентами. Но непонятно, чьи лимиты тратить и чья конфигурация считается основной.