Для одиночного разработчика локальная работа с агентом может оставаться личным ремеслом. Для команды та же схема превращается в системную проблему: компания больше не видит, как на самом деле производится результат.
Раньше большая часть инженерной работы происходила внутри задач, коммитов и проверки кода. Теперь между постановкой и итоговым кодом возникает отдельное производство: агент исследует проект, строит план, пишет реализацию, запускает проверки; человек возвращает результат, меняет навыки, переключает модель, правит harness и принимает решения. Но трекер задач продолжает показывать одну строку: «задача у разработчика».
Из-за этого агентная разработка пока масштабируется странно. У каждого человека появляется всё более сильный персональный заводик, но команда не получает общего производства. Она видит продукт, не видит способ его изготовления — и поэтому не может этот способ измерять, сравнивать, передавать и улучшать. Компания не станет AI‑native, пока эта работа остаётся невидимой и развивается на ощущениях.
Агентский пайплайн развивается вслепую
Команда не может свободно проверять альтернативы, сравнивать их в одинаковых условиях и считать полную стоимость принятого результата.
1. Нельзя свободно экспериментировать с агентскими пайплайнами
Разработчик получает не вычислительный бюджет компании, а конкретную подписку. Поэтому он исследует не лучший способ решить задачу, а лучший способ уложиться в уже выданный ему инструмент.
Чтобы попробовать Claude вместо Codex, нужно запросить новую подписку, дождаться одобрения и объяснить, зачем она нужна. Если эксперимент не сработал, обратный переход столь же неудобен. Даже внутри одной подписки лимит приходится беречь для текущей работы: задача должна быть сделана сегодня, а поиск лучшего процесса конкурирует с ней за те же токены.
Варианты, которые могут оказаться принципиально эффективнее привычного процесса
Plan → Act → Review: Claude или Fable строит план, Codex реализует, Kimi независимо проверяет результат.
Один сильный агент: Одна дорогая модель на максимальном ризонинге получает полный контекст, подходящие инструменты и проектные навыки.
Swarm: Десять дорогих агентов независимо предлагают решения, а финальный агент собирает лучшее.
Последний вариант может оказаться дорогим по токенам, но дешёвым по человеческому вниманию: задача one-shot’ится, и разработчик тратит пятнадцать минут на принятие результата. Однако проверить эту гипотезу в рамках одной личной квоты невозможно.
Личная квота смещает критерий выбора: вместо поиска наиболее эффективной схемы разработчик старается не исчерпать доступный лимит. В итоге разработчик привязывается к первому доступному процессу и улучшает его локально, не проверяя принципиально иные варианты.
Условный эксперимент: выбор пайплайна ограничен уже доступными подписками и квотами.
2. Инженерные процессы нельзя честно сравнить
Итоговый результат задачи виден. Способ его производства — нет.
Один разработчик говорит, что one-shot’ит задачи. Другой отвечает, что его задачи принципиально сложнее, не one-shot’ятся, а агент только добавляет постановку, ожидание и исправления — то есть удлиняет работу. Проверить ни одну позицию нельзя: люди решают разные задачи, в разных окружениях и с разным количеством ручной доводки. Общего набора контрольных задач нет.
Даже цена подписки ничего не объясняет. Пользователь тарифа за 20 долларов мог построить очень экономный пайплайн — или просто писать половину кода руками, расходуя дорогое человеческое время. Пользователь тарифа за 200 долларов мог добиться высокой автономности — или тратить лимиты на личные проекты и каскад из десяти проверок, который не улучшает результат.
Мы сравниваем рассказы о производстве, а не само производство.
Пока стадии, попытки, вмешательства человека и стоимость принятия скрыты, любое сравнение остаётся фольклором.
Условный пример: календарное время и активное участие человека дают разную картину. Сравнение стоимости экспертизы предполагает одинаковую часовую ставку; расходы на агента здесь не учтены.
3. Нельзя определить реальную стоимость принятого результата
Стоимость принятого результата складывается из двух частей: расходов на агента и времени, когда разработчик активно добавлял свою экспертизу.
Если задача находилась у разработчика шесть часов, это больше не означает шесть часов его работы. Агент мог пять часов выполнять реализацию, а человек — десять минут уточнять постановку и ещё двадцать минут проверять результат. Для расчёта важны стоимость агентной работы и эти полчаса экспертного участия; остальное время было ожиданием.
Результат, сделанный дешёвой моделью, может в итоге оказаться дорогим, если требует перезапусков, микроменеджмента, ручных исправлений и нескольких циклов review. Результат дорогой модели, наоборот, может стоить меньше, если one-shot принимается после короткой проверки. Видимая цена подписки не равна стоимости результата.
Нужно учитывать расход токенов или долю подписки и отдельно фиксировать только активное участие разработчика: постановку, экспертные решения, возвраты, review и ручные правки. Календарное время задачи и ожидание агента не заменяют этот расчёт.
Примечание
За рамками остаются:
дефекты, обнаруженные после merge;
будущая поддержка;
архитектурный долг;
стоимость инцидента;
различия в качестве reviewers;
сложность задачи;
стоимость инфраструктуры;
coordination overhead;
время QA;
влияние на lead time всей команды;
бизнес-ценность результата.
«Принято» не значит «хорошо». Иногда это значит лишь «проверяющий устал».
One-shot rate тоже сомнительная цель. Хороший агент может задать важный уточняющий вопрос. Плохой — молча реализовать удобную ему интерпретацию и с первого раза выдать убедительный мусор. Если one-shot становится KPI, система учится не улучшать результат, а избегать видимых итераций.
Расходы на агента и активное участие разработчика. Это модель стоимости до приёмки; её ограничения перечислены выше.
Вывод: пайплайн развивается без обратной связи
Нет свободного пространства для экспериментов, общего набора контрольных задач и полной цены результата. Поэтому процессы развиваются на ощущениях и личных привычках, а не как измеримая инженерная система.
Вычислительная мощность привязана к людям и ноутбукам
Компания покупает ресурс отдельным сотрудникам, но не может перераспределить простой, закрыть локальный дефицит или масштабировать очередь задач.
4. Вычислительная мощность фрагментирована по людям
У компании одновременно есть оплаченная неиспользуемая мощность и задачи, которые ждут обновления чужой квоты.
Персональная подписка часто представляет собой пакет несовпадающих возможностей. Программист использует Codex, но почти не трогает сильную веб‑модель или генерацию изображений. Художнику нужна именно генерация изображений, но не агент для кода. Один человек упирается в недельный лимит, другой не расходует и половины оплаченной ёмкости.
Централизованный пул изменил бы саму единицу планирования: вычислительная мощность выдавалась бы задаче на нужное время. Чтобы раз в неделю прогнать контрольный набор на Kimi, не пришлось бы покупать месячную подписку конкретному сотруднику. Команда могла бы увидеть общий дефицит и простой, а затем покупать ресурс под реальную нагрузку.
Общий вычислительный бюджет меняет масштаб допустимого эксперимента. Команда может проверять большие технические гипотезы не потому, что заранее уверена в результате, а потому, что стоимость проверки стала приемлемой. Например, временно переписать Java‑сервер на C# не ради немедленного релиза, а чтобы измерить скорость, память и сложность сопровождения. Часто такой эксперимент блокирует не инженерная сложность, а нежелание сжечь личную квоту.
Условный пример: личный лимит исчерпан, хотя часть оплаченного командой ресурса простаивает.
5. Параллельность упирается в локальную среду выполнения
Пока агенты работают без участия человека, разработчик мог бы вести несколько независимых задач. Но фактический предел задаёт его компьютер: обычно именно он выдерживает лишь одну‑две тяжёлые сессии.
Каждая параллельная задача требует отдельной рабочей копии или worktree, своей ветки и изолированного состояния проекта. Несколько экземпляров Unity или редактора быстро съедают RAM и CPU. Сборка, тесты и автоматический QA конкурируют за тот же ресурс. Кэши, зависимости, скриншоты и артефакты множатся на диске.
Даже когда агенту не требуется внимание, человеку приходится следить за локальными процессами, переключаться между окнами и ждать тяжёлую компиляцию. Проверка занимает несколько минут с большими паузами между ними, но паузы нельзя заполнить другими запусками: ноутбук уже занят.
Масштаб агентного исполнения определяется не количеством задач компании, а ноутбуком конкретного разработчика.
Условный пример: новые задачи ждут освобождения локальной машины.
Вывод: мощность нельзя направить туда, где она нужна
Личный дефицит соседствует с оплаченным простоем, а параллельность ограничена отдельными ноутбуками. Ресурс распределён по владельцам подписок и машин, а не по очереди задач компании.
Трекер задач видит задачу, но перестал видеть работу
Агентное исполнение добавило в производство новые стадии и новую роль человека. Корпоративный таск‑трекер продолжает описывать старый мир.
6. Трекер задач больше не отражает жизненный цикл задачи
Статус «задача у разработчика» теперь скрывает целый производственный пайплайн.
Что реально происходит внутри одного статуса таск‑трекера
Постановка — Человек формулирует задачу, ограничения и контекст.
Ожидание — Запуск стоит в очереди, ждёт мощности или работает.
План — Агент исследует проект и предлагает решение.
Проверка плана — Человек утверждает, меняет или возвращает план.
Реализация — Агент пишет код и запускает проверки.
Проверка / QA — Человек принимает, дорабатывает или возвращает результат.
В таск‑трекере: «Новая фича · В работе»
Лид больше не может понять реальную загрузку человека. Он занят и его нельзя отвлекать — или свободен и лишь ждёт завершения долгой агентной реализации, которая может идти пять‑шесть часов подряд? Можно дать ему вторую задачу — или локальный runtime уже забит? Делегирования невидимы, поэтому трекер задач не отвечает на базовый управленческий вопрос: где сейчас находится работа.
Примечание
Проблема не в том, что таск‑трекер не показывает весь внутренний процесс. Он и не должен. Проблема в том, что между задачей и результатом появился новый самостоятельный исполняемый контур, но трекер с ним никак не связан. Поэтому он не различает важные для координации состояния: работа действительно выполняется, ждёт ресурса, заблокирована, требует решения человека или уже готова к приёмке.
Один статус в трекере скрывает разные стадии исполнения.
7. Промежуточные результаты не становятся артефактами задачи
Код сохраняется в pull request. Исследование, план, альтернативы, проверка плана и причины внутренних возвратов часто исчезают вместе с персональной историей сессии.
Обычная проверка кода слишком поздно обнаруживает крупную архитектурную ошибку: решение уже реализовано, и требование переделать всё выглядит как провал процесса. Архитектуру нужно обсуждать до реализации, чтобы на проверке кода оставались локальные риски и качество исполнения.
В агентном пайплайне стадия планирования часто ценнее самой реализации. Именно здесь выбирается архитектура, фиксируются ограничения и отбрасываются альтернативы. Этот план должен быть доступен лиду и команде. Иначе после регрессии невозможно понять, где возник дефект: в самом решении или в реализации правильного решения.
Формально сохраняется
Код, PR, комментарии проверки, финальный статус и иногда краткий отчёт.
Тоже должно сохраняться
Исследование, план, отвергнутые подходы, проверка плана, агентный QA, причины возврата и точки человеческого вмешательства.
8. Разработчики стали менеджерами агентов — без менеджерской дисциплины
С агентом программист всё чаще не производит код, а ставит работу исполнителю, контролирует её и принимает результат. Это уже делегирование, а не просто использование инструмента.
Если воспринимать ИИ как инструмент, постоянные подсказки, микроконтроль и ручная доводка кажутся естественными. Если воспринимать его как исполнителя, те же действия означают слабое делегирование: задача плохо поставлена, исполнитель недостаточно автономен, пайплайн требует слишком много внимания.
Подлинное делегирование заканчивается проверкой и принятием результата. Менеджер, который каждый раз доделывает работу за исполнителем, не построил работающую систему. Но разработчики редко считают число возвратов, вмешательств и сорванных one-shot’ов; не измеряют собственное внимание и не развивают навыки постановки, контроля и приёмки.
Руководство тоже не может оценить эти компетенции: таск‑трекер не показывает, кто выстроил автономный процесс, а кто весь день микроменеджерил агента. Новая управленческая работа появилась, но организационно её как будто нет.
Примечание
Метафора делегирования здесь полезна, но её границы важны. Агент — вероятностная система, а не сотрудник с устойчивой памятью и ответственностью. Поэтому большое число подсказок, ручная доводка или сорванный one-shot сами по себе ещё не означают слабого управления.
Для одноразовой задачи десятиминутная правка может быть рациональнее, чем два дня на универсальный skill, regression dataset и отдельное изменение harness. Развивать производственный контур стоит там, где класс задач повторяется, цена ошибки высока или улучшение можно переиспользовать.
Управленческие практики помогают точнее ставить задачи и выстраивать приёмку, но не задают готовый протокол общения с моделью. Сильная инженерная практика — не максимальная автономность любой ценой, а окупаемый уровень системности.
Цикл делегирования становится частью инженерной работы. Нужный уровень автономности зависит от задачи.
9. Реальная человеческая работа не отражается в задачах
Конкретная задача из таск‑трекера всё чаще становится контрольным примером работы, которую разработчик сделал заранее: настроил harness, написал навык, выбрал инструменты и формализовал проектные соглашения.
Когда задача one-shot’ится, невозможно понять роль человека. Он просто скопировал заголовок задачи — или до этого неделями превращал проектную экспертизу в исполняемые инструкции? Если one-shot не произошёл, сильный разработчик обычно не начинает вручную дописывать задачу. Он отлаживает пайплайн: почему агент двадцать раз вызвал один инструмент, почему выбрал неверный prefab, какого контекста не хватило навыку.
В таск‑трекере при этом записано, что человек «верстал prefab по макету», хотя он мог не открыть макет ни разу. Его реальная работа — улучшение навыка вёрстки интерфейсов и harness, который должен решать весь класс подобных задач. Трекер фиксирует конечный экземпляр, но теряет создание производственного метода.
То, что видно в таск‑трекере, всё чаще выполняет агент. То, что реально делает человек, всё чаще находится вне таск‑трекера.
В задаче виден результат, а работа над способом его получения остаётся за кадром.
Вывод: работа человека не наблюдается от начала до конца
Не видно, где человек создал ценность: в постановке, выборе пайплайна, проверке плана, возврате, ручной правке или развитии harness. Не видна и управленческая нагрузка. Таск‑трекер перестаёт быть источником правды, потому что производственный процесс превращается в чёрный ящик.
Исполнитель и его harness заперты за границей одного человека
Агент может знать задачу лучше всех участников процесса, но взаимодействовать с ним способен только владелец локальной сессии.
10. Фактический исполнитель недоступен остальной команде
Агент исследовал код, написал реализацию и сохранил контекст задачи. Но QA, лид и другой разработчик не могут задать ему вопрос напрямую.
QA спрашивает о риске регрессии или просит сделать rebase ветки. Разработчик читает сообщение, копирует его в локальную сессию агента, получает ответ и пересылает обратно. Часто он не добавляет собственной экспертизы: отдельный навык уже умеет сформулировать ответ для QA.
Сегодняшний маршрут одного вопроса
QA / лид / разработчик → разработчик → локальная сессия → разработчик → ответ
Разработчик превращается в ручной API‑шлюз к собственному агенту. Его посредничество добавляет ожидание, но не добавляет ценность. Фактический исполнитель должен быть цифровой личностью процесса, доступной тем, кому нужен его контекст.
Примечание
Языковая модель не является надёжным свидетелем собственного процесса: она способна сгенерировать убедительное постфактум‑объяснение, которое не соответствует реальной причине ответа.
Разработчик пересылает сообщения между командой и локальной сессией агента.
11. Harness недоступен другим людям и другим командам
Даже хороший пайплайн нельзя просто «передать» гейм‑дизайнеру или соседнему разработчику: он постоянно меняется и зависит от операционной системы, инструментов, секретов и локального окружения.
Можно один раз настроить гейм‑дизайнеру агентный пайплайн для прототипов, но через неделю исходный harness уже эволюционирует, а его копия останется старой. Правильное разделение ролей должно быть другим: инженер, отвечающий за harness, развивает агентский пайплайн, а пользователь запускает его, не воспроизводя всю инфраструктуру у себя.
Изоляция мешает и обычной командной работе. Клиентскому разработчику не обязательно ждать, пока освободится серверный: он мог бы попросить серверного агента собрать временную заглушку и начать интеграцию. Серверный программист, в свою очередь, мог бы уточнить у клиентского агента детали имплементации поддержки серверного контракта. Сегодня каждый агент замкнут внутри владельца и его runtime.
Копия навыка не переносит его окружение, инструменты и права.
12. Доступ, безопасность и ответственность не формализованы
Пока агентские пайплайны живут в персональных конфигурациях, компания не видит границы их доступа и не может формально распределить ответственность.
Один агент только читает diff, другой имеет shell, write‑доступ к репозиторию, сборке или публикации. Без общего контура эти различия остаются локальными настройками, а единая политика существует только на словах.
Размытый локальный риск
Права наследуются от человека, а действия и точки подтверждения не образуют общего журнала.
Формальный контур
Идентичность агента, ограниченные права, разделение чтения и записи, точки подтверждения, изолированные среды выполнения, журнал действий и решений.
Пример разграничения прав: чтение, запись, shell и действия в production.
Вывод: harness изолирован границей разработчика
Контекст, инструменты, сессии, исполнители и права не являются формальной частью процесса. Команда не может продолжить чужую работу, напрямую обратиться к фактическому исполнителю или безопасно открыть harness наружу.
Проект сохраняет код, но теряет опыт его производства
Локальные навыки и сессии эволюционируют, однако их опыт почти не превращается в общий актив команды.
13. Навыки не являются общим управляемым активом
Навык нельзя отделить от пайплайна так же легко, как библиотеку от приложения. Он зависит от среды выполнения, модели, инструментов, зрения, способов запуска и хранения секретов.
QA‑навык, построенный на Linux Computer Use, может быть бесполезен разработчику на Windows. Чтобы запустить его, недостаточно скопировать папку: нужно воспроизвести окружение, инструменты и права. Для разных моделей даже формулировка одной и той же инструкции может требовать разных акцентов.
Zip‑архив расходится по версиям сразу после передачи. Отдельный репозиторий, подключённый как submodule, добавляет синхронизацию всем участникам проекта, даже тем, кому навык локально не нужен и кто всё равно не может его исполнить. Плагин не решает проблему несовпадающих сред выполнения.
При этом навык напрямую влияет на рабочий код, но управляется хуже обычной библиотеки: нет понятной рекомендованной версии, владельца, истории совместимости и процесса вывода из эксплуатации. Поэтому передавать нужно не файл с инструкцией, а весь исполняемый пайплайн, частью которого является этот навык.
Условный обмен навыком: переданные архивы сразу начинают жить независимо.
14. Неудачную сессию агента нельзя воспроизвести и проверить
Фраза «агенты тупые, у меня не получилось» не диагностируема без исходной постановки, контекста, версии навыка, инструментов, модели, следа выполнения и точек ручного вмешательства.
Раньше можно было открыть код, показать ошибочный подход и объяснить, как сделать лучше. Теперь нужно проверять сам процесс делегирования. Но история сессии остаётся локальной, окружение меняется, контекст устаревает, а повторная демонстрация происходит уже на другой задаче и ничего не доказывает.
Из-за этого команда не учится на реальных провалах. Нельзя точно увидеть, где разработчик ошибся: плохо поставил задачу, дал недостаточный контекст, выбрал неподходящий инструмент, пропустил план или вмешался слишком рано.
Онбординг деградирует до фольклора: «поставь какую‑нибудь модель, настрой какой‑нибудь harness, попробуй такой промпт». Старая инженерная культура меняется, но новая не возникает, потому что опыт не закреплён в воспроизводимых артефактах.
Примечание
Даже одинаковый prompt и одинаковые настройки не гарантируют одинакового результата: LLM-запуски могут оставаться недетерминированными, а модель, inference backend, зависимости, repository state и внешние инструменты со временем меняются. Trace позволяет расследовать, что произошло. Он не обязательно позволяет это повторить.
Сохранённая сессия помогает расследовать сбой; точное воспроизведение запуска не гарантировано.
15. Память агента формируется на личном наборе задач
Каждый разработчик развивает своего агента на небольшом фрагменте проектной истории, хотя настоящий источник опыта — все задачи проекта.
Один человек выполнил несколько задач по профилированию, написал навык и накопил понимание типичных ловушек. Через месяц похожую задачу получает другой разработчик и начинает с нуля. Для него это первая такая задача; для проекта — далеко не первая. Миллионы кусочков контекста существуют, но разбросаны по локальным агентам и персональным историям.
Проекту нужна не «моя память», а общая память: успешные подходы, провалы, комментарии проверки, замечания QA, принятые решения и следы того, как агент к ним пришёл. Иначе несколько уменьшенных копий одного пайплайна развиваются медленнее, чем общий исполнитель, обучающийся на опыте всей команды.
Примечание
Под памятью проекта здесь имеется в виду не необработанный архив сообщений и trace.
Чтобы превратить историю запусков в воспроизводимые знания, нужны как минимум:
отбор полезного и связь с проверяемыми артефактами;
маркировка подтверждённого и ошибочного;
дедупликация и разрешение противоречий;
контроль актуальности и политика забывания;
retrieval и оценка того, помогло ли извлечение следующему запуску.
Без этого проект не учится — он лишь складирует всё, что модель когда‑либо сказала уверенно.
Новая задача для человека может быть повторяющейся задачей для проекта.
Вывод: опыт решения задач не становится памятью проекта
Сохраняется итоговый код. Не сохраняется производственный след: какие подходы сработали, какие провалились, что заметили проверка и QA, какие изменения в harness привели к улучшению.
Общая причина: ИИ стал участником производства — процессы должны измениться
ИИ уже не просто персональный инструмент, а самостоятельный участник производства. Поэтому вместе с технологией должны меняться процессы, роли, права и способы накопления опыта.
Общая причина описанных проблем — три характеристики, которые сегодня определяют большинство агентских пайплайнов:
Личный. Подписки, API‑ключи, модели, промпты, навыки, сессии и накопленный опыт привязаны к человеку.
Локальный. Среда выполнения, worktrees, Unity, тесты, активные сессии и вычисления живут на его машине.
Закрытый. Команда не видит стадии, следы, решения, исполнителей, артефакты и причины ошибок.
У компании уже есть множество персональных агентских стеков. Но общего инженерного процесса работы с агентами у неё нет.
Каждую из этих проблем можно закрыть отдельным костылём: добавить скрипт, завести общий репозиторий навыков, договориться сохранять логи или выделить машину для тяжёлых запусков. Но у этих проблем есть общая причина — и решение, которое позволяет работать с ними как с единой системой. Во второй части разберу, как вынести агентную работу из персональных стеков в общий инженерный процесс и что для этого уже можно использовать.