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

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

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

Чтобы попробовать Claude вместо Codex, нужно запросить новую подписку, дождаться одобрения и объяснить, зачем она нужна. Если эксперимент не сработал, обратный переход столь же неудобен. Даже внутри одной подписки лимит приходится беречь для текущей работы: задача должна быть сделана сегодня, а поиск лучшего процесса конкурирует с ней за те же токены.

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

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

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

Итоговый результат задачи виден. Способ его производства — нет.

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

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

Нельзя определить реальную стоимость принятого результата

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

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

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

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

Вычислительная мощность фрагментирована по людям

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

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

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

Параллельность упирается в локальную среду выполнения

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

Каждая параллельная задача требует отдельной рабочей копии или worktree, своей ветки и изолированного состояния проекта. Несколько экземпляров Unity или редактора быстро съедают RAM и CPU. Сборка, тесты и автоматический QA конкурируют за тот же ресурс. Кэши, зависимости, скриншоты и артефакты множатся на диске.

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

Трекер задач больше не отражает жизненный цикл задачи

Статус «задача у разработчика» теперь скрывает целый производственный пайплайн.

Лид больше не может понять реальную загрузку человека. Он занят и его нельзя отвлекать — или свободен и лишь ждёт завершения долгой агентной реализации, которая может идти пять‑шесть часов подряд? Можно дать ему вторую задачу — или локальный runtime уже забит? Делегирования невидимы, поэтому трекер задач не отвечает на базовый управленческий вопрос: где сейчас находится работа.

Промежуточные результаты не становятся артефактами задачи

Код сохраняется в pull request. Исследование, план, альтернативы, проверка плана и причины внутренних возвратов часто исчезают вместе с персональной историей сессии.

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

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

Разработчики стали менеджерами агентов — без менеджерской дисциплины

С агентом программист всё чаще не производит код, а ставит работу исполнителю, контролирует её и принимает результат. Это уже делегирование, а не просто использование инструмента.

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

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

Руководство тоже не может оценить эти компетенции: Jira не показывает, кто выстроил автономный процесс, а кто весь день микроменеджерил агента. Новая управленческая работа появилась, но организационно её как будто нет.

Реальная человеческая работа не отражается в задачах

Конкретная Jira‑задача всё чаще становится контрольным примером работы, которую разработчик сделал заранее: настроил harness, написал навык, выбрал инструменты и формализовал проектные соглашения.

Когда задача one-shot’ится, невозможно понять роль человека. Он просто скопировал заголовок задачи — или до этого неделями превращал проектную экспертизу в исполняемые инструкции? Если one-shot не произошёл, сильный разработчик обычно не начинает вручную дописывать задачу. Он отлаживает пайплайн: почему агент двадцать раз вызвал один инструмент, почему выбрал неверный prefab, какого контекста не хватило навыку.

В Jira при этом записано, что человек «верстал prefab по макету», хотя он мог не открыть макет ни разу. Его реальная работа — улучшение навыка вёрстки интерфейсов и harness, который должен решать весь класс подобных задач. Трекер фиксирует конечный экземпляр, но теряет создание производственного метода.

Фактический исполнитель недоступен остальной команде

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

QA спрашивает о риске регрессии или просит сделать rebase ветки. Разработчик читает сообщение, копирует его в локальную сессию агента, получает ответ и пересылает обратно. Часто он не добавляет собственной экспертизы: отдельный навык уже умеет сформулировать ответ для QA.

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

Harness недоступен другим людям и другим командам

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

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

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

Доступ, безопасность и ответственность не формализованы

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

Один агент только читает diff, другой имеет shell, write‑доступ к репозиторию, сборке или публикации. Без общего контура эти различия остаются локальными настройками, а единая политика существует только на словах.

Навыки не являются общим управляемым активом

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

QA‑навык, построенный на Linux Computer Use, может быть бесполезен разработчику на Windows. Чтобы запустить его, недостаточно скопировать папку: нужно воспроизвести окружение, инструменты и права. Для разных моделей даже формулировка одной и той же инструкции может требовать разных акцентов.

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

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

Неудачную сессию агента нельзя воспроизвести и проверить

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

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

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

Онбординг деградирует до фольклора: «поставь какую‑нибудь модель, настрой какой‑нибудь harness, попробуй такой промпт». Старая инженерная культура меняется, но новая не возникает, потому что опыт не закреплён в воспроизводимых артефактах.

Память агента формируется на личном наборе задач

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

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

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