Полтора года назад я бы написал этот текст про скорость. Про то, как агент за минуту накидывает то, что я писал бы час. Сегодня я пишу про дисциплину — и это, кажется, и есть вся история.
Я уже года полтора живу в режиме, когда значительную часть кода за меня пишет агент. Сначала восторг, потом усталость, потом трезвое понимание: агент без харнеса — это не инженер, это очень быстрый и очень забывчивый джун. Он может за минуту накидать то, что я писал бы час, но он же за эту минуту радостно снесёт соседний модуль, забудет про тесты, придумает несуществующий метод в библиотеке и не вспомнит, о чём мы договаривались пять сообщений назад. Как технический менеджер я смотрю на это просто: проблема не в скорости генерации кода, проблема в отсутствии процесса вокруг этой генерации.
Обычно я применял Github Speckit. Поэтому, когда мне на глаза попался ECC (affaan-m/ECC), я зацепился не за цифры в духе «71 агент и 311 скиллов» — такие цифры меня скорее настораживают, чем радуют. Я зацепился за одну строчку в описании: plan, test, implement, review, verify, remember, improve. Это не фича. Это нормальный инженерный цикл, который мы десятилетиями пытаемся привить живым командам. И вот кто-то предлагает зашить его прямо в поведение агента, один раз, чтобы не переписывать это в каждом промпте. Мне стало любопытно, насколько это работает на практике, а не на лендинге.
Что такое ECC, если коротко
ECC — это не ещё одна модель и не замена Claude Code. Это надстройка, харнес, который садится поверх кодового агента и навязывает ему рабочий процесс. По сути — операционная система для агента: набор специализированных под-агентов, набор навыков, хуки, правила, память и сканер безопасности. Устанавливается как плагин, лицензия MIT, исходники открыты и бесплатны, а деньги проект берёт за облачный хостинг для приватных репозиториев и со спонсоров.
Философия у них сформулирована почти по-инженерному сухо: оптимизируй контекстное окно, всё остальное сохраняй персистентно. Если перевести с языка разработчиков на человеческий: у агента ограниченная память, он физически не может держать в голове весь проект. Значит, всё, что можно вынести из его оперативной памяти в файлы, правила и структуру, нужно вынести. А в голове оставить только то, что нужно прямо сейчас для текущего шага. Мне, как человеку, который много думает про архитектуру систем, эта идея понятна и близка. Это ровно то же самое, что мы делаем, когда проектируем сервис без состояния и выносим состояние в базу.
Установка
Ставить оказалось почти неприлично просто, и это первый плюс. Не нужно клонировать репозиторий, не нужно руками раскладывать конфиги. Есть один установщик, запускаешь его через npx, он сам находит все места, куда можно поставить плагин, спрашивает область установки — глобально на пользователя, на проект или локально — спрашивает профиль хуков и ставит. Всё. Я специально поставил сначала глобально на себя со стандартным профилем, чтобы посмотреть на поведение по умолчанию, а не на вылизанную конфигурацию под конкретный репозиторий.
Отдельно отмечу, что установщик сначала проводит инвентаризацию: показывает, что у тебя уже стоит, куда он собирается писать, и только потом просит финального подтверждения. Для менеджера, который отвечает за несколько машин и за то, чтобы коллеги не превратили свои окружения в помойку, это важный сигнал. Инструмент не лезет напролом.
Реальная задача, на которой я его гонял
Синтетические демки я не люблю, поэтому взял настоящую задачу из нашего бэклога, которую давно откладывал именно потому, что она скучная и рискованная одновременно. Нужно было отрефакторить слой доступа к данным в одном из наших сервисов: вынести разросшуюся бизнес-логику из контроллеров, ввести нормальный слой репозиториев, не сломав при этом десяток существующих эндпоинтов, под которыми уже сидят клиенты. Классический рефакторинг, где цена ошибки — продакшн, а удовольствия почти ноль. Идеальный полигон, чтобы проверить, умеет ли ECC в дисциплину, а не только в генерацию.
Первое, и ожидаемое — агент не бросился писать код. Он сначала построил план. Не абстрактный «щас отрефакторим», а конкретный разбор: вот текущая структура, вот какие эндпоинты затронуты, вот порядок шагов, вот что проверяем после каждого шага. Я как технический менеджер половину жизни трачу на то, чтобы заставить людей сначала подумать, а потом делать. А тут это происходит по умолчанию. Я мог бы план почитать, что-то поправить и только потом дать добро. Естественно, никто на практике сам читать не будет.
Второе — тесты шли до реализации, а не после. На шаге рефакторинга, где легко было всё сломать, агент сначала зафиксировал текущее поведение тестами, потом менял код, потом прогонял тесты снова. Это именно то, что в учебниках называется safety net перед рефакторингом, и чего живые разработчики под дедлайном почти никогда не делают. Здесь это было частью процесса, а не моим героическим усилием.
Третье, и для меня самое интересное, — ревью из свежего контекста. ECC умеет запускать проверку собственной работы так, как будто её делает другой агент, который не видел, как код писался, а видит только результат. Это принципиально другой режим. Когда ты сам написал код, ты смотришь на него влюблёнными глазами и видишь то, что хотел написать, а не то, что написал. А отдельный ревьюер, у которого нет этой привязанности, нашёл пару реальных мест, где поведение чуть изменилось по сравнению с исходным. Поймали до мержа, гуд.
Что сработало хорошо
Дисциплина. Это главное слово. ECC превращает агента из спринтера в инженера, который идёт по шагам. Для задач, где цена ошибки высокая, это бесценно. Я перестал чувствовать, что сижу над агентом с линейкой и бью по рукам.
Память между сессиями. Агент помнил архитектурные решения, которые мы приняли в начале, и не пытался их пересмотреть на пятом шаге. Договорились один раз — он этого держится. Для длинных задач, которые не влезают в одну сессию, это снимает огромный класс головной боли.
Безопасность по умолчанию. Встроенный сканер смотрит на то, что сам агент и его окружение делают: промпты, хуки, конфиги, секреты. Для меня, как для человека, который отвечает в том числе за то, чтобы в репозиторий случайно не уехал ключ или чтобы агентская автоматизация не стала дырой, это не маркетинговая галочка, а реальное снижение риска.
Процесс как код. Самое ценное стратегически. Раньше весь наш agent-процесс жил в головах тех двух-трёх человек, кто умеет хорошо промптить. Это не масштабируется и уходит вместе с человеком. ECC превращает процесс в артефакт, который можно поставить всей команде одинаково. Это ровно то, за что я как менеджер готов платить.
Что напрягло или вызвало вопросы
Объём. 71 агент, 311 навыков, почти сотня команд. Я честно не верю, что человек может держать это всё в голове и осмысленно применять. Большая часть этого богатства у меня простаивала, а новичка такое количество сущностей скорее напугает, чем поможет. Я бы предпочёл меньше, но с более ясной картой, когда что применять.
Непрозрачность решений. Когда агент сам выбирает, какой навык или под-агента подключить, не всегда очевидно, почему он выбрал именно это. В большинстве случаев выбор разумный, но когда он ошибается, разбираться, почему он пошёл именно этим путём, тяжелее, чем с голым агентом, где ты сам всё держишь в руках. Это цена за автоматизацию, и её надо принимать осознанно.
Зависимость от зрелости модели. Весь процесс настолько хорош, насколько хороша модель под ним. На сильной модели ECC раскрывается, план осмысленный, ревью полезное. Я подозреваю, что на более слабом движке вся эта оркестрация начнёт давать красивый процесс поверх посредственных решений, а это опаснее, чем явно слабый агент, потому что создаёт ложное ощущение надёжности.
Один мейнтейнер. Проект в основном держит один человек. Для открытого кода на MIT это нормально, форкнуть всегда можно. Но если я закладываю это в командный процесс, я обязан держать в голове риск того, что темп развития зависит от одного человека, и иметь план на случай, если он выгорит или уйдёт.
Где я готов это держать, а где нет
ECC решает правильную проблему. Большинство инструментов вокруг кодовых агентов пытаются сделать генерацию быстрее или умнее. ECC делает другое и, на мой взгляд, более ценное: он занимается процессом вокруг генерации. А именно процесс, а не скорость печати, отличает инженерию от хаоса.
Для меня как архитектора главный инсайт такой. Агент без процесса — это рычаг без точки опоры. Ты прикладываешь силу, но непонятно куда. ECC даёт точку опоры. Он не делает агента умнее, он делает его дисциплинированнее, а в инженерии дисциплина почти всегда важнее сырого интеллекта.
Буду ли я это внедрять? Как один из инструментов — напомню, что я уже использую Github Speckit — да. На рискованных задачах с высокой ценой ошибки, на рефакторингах, на работе с легаси — скорее да, и именно в проектном скоупе, с настроенными под репозиторий правилами, а не в глобальной конфигурации по умолчанию. На мелких одноразовых задачах, где я и сам всё держу в голове, вся эта машинерия избыточна — там быстрее работать с голым агентом.
Ценность инженера всё меньше в том, чтобы писать код руками, и всё больше в том, чтобы проектировать процесс, по которому код пишется, кем или чем бы он ни писался. ECC — одна из первых серьёзных попыток упаковать такой процесс в устанавливаемый артефакт. Он не идеален, он местами избыточен, но направление мысли у него правильное.