Фреймворк AC/DC предлагает смотреть на AI-агентов разработки не как на турбокнопку для генерации кода, а как на новый объект управления внутри инженерной команды. Для русскоязычных IT-команд это сигнал вполне практичный: спор уже не о том, сколько строк кода выдаст агент за час, а о том, кто отвечает за результат, как проходят проверки и где у этой автоматизации вообще границы.
Об этом пишет The New Stack, разбирая подход, который переносит разговор об AI coding из плоскости «быстрее пишет» в плоскость «предсказуемо работает». Сама постановка вопроса показательная. Пока рынок увлеченно считает прирост скорости, зрелые команды упираются в куда менее эффектные, но более дорогие темы: доступы, аудит изменений, качество патчей, происхождение решений и риск того, что агент уверенно утащит в прод то, что человек потом будет неделями разгребать. AC/DC в этой логике нужен не для того, чтобы мешать автоматизации, а чтобы она не превращалась в неформальный теневой процесс разработки.
Судя по описанию The New Stack, ключевая идея AC/DC проста и поэтому полезна: AI coding agent должен жить не вне процесса, а внутри него. То есть не «попросили бота что-то поправить, потом как-нибудь посмотрим», а понятный цикл с ролями, ограничениями и контрольными точками. У агента должны быть рамки по контексту, понятный набор задач, фиксируемые действия и обязательная проверка результата. Иными словами, речь идет не о магии промптов, а о дисциплине вокруг них. Для многих команд это, возможно, самая неприятная часть истории, потому что она возвращает нас к старой инженерной истине: ускорение без контроля почти всегда создает отложенный долг, просто сначала он выглядит как демо.
На этом фоне AC/DC попадает ровно в нерв текущего тренда. В последние два года инструменты для генерации кода массово вошли в повседневную разработку: от подсказок в IDE до агентных сценариев, где модель сама получает задачу, ходит по репозиторию, предлагает правки и даже готовит pull request. Но чем автономнее становится такой помощник, тем острее вопрос управления. Если обычный copilot еще можно воспринимать как продвинутый автокомплит, то агент уже ближе к младшему исполнителю с очень странной памятью и переменной уверенностью в себе. Он может ускорить рутину, снять часть нагрузки с разработчика и помочь с типовыми изменениями. Но он же может разнести архитектурные договоренности, повторно открыть старый баг или аккуратно пронести в код то, что прошло бы мимо поверхностного ревью.
Отсюда и практический смысл рамки для бизнеса. Когда компания внедряет AI-агентов разработки, она на самом деле внедряет не только новый инструмент, но и новую единицу операционного риска. Вопрос «насколько быстро он пишет» для CTO и engineering-менеджера быстро уступает вопросам «где журнал действий», «какие у него права», «кто подписывает результат» и «как мы вообще поймем, что он сделал лишнего». Именно тут управленческая рамка важнее очередного сравнения моделей. Скорость без воспроизводимости хороша для сцены на конференции. Для команды, у которой есть прод, SLA, безопасность и найм, важнее другое: чтобы агентное ускорение не убило инженерную прозрачность. И в этом смысле AC/DC звучит как попытка вернуть разработку из режима шоукейса в режим нормальной эксплуатации.
Для самих разработчиков посыл тоже предельно земной. AI-агенты разработки не отменяют ревью, тесты, архитектурные ограничения и ответственность автора изменений. Скорее наоборот: чем активнее команда делегирует машине написание кода, тем строже должны быть правила входа и выхода из этого процесса. Хорошая новость в том, что такая рамка не обязательно означает бюрократию. Если сделать ее разумно, она помогает отделить полезную автоматизацию от опасной самодеятельности. Агент может готовить черновики, разбирать шаблонные задачи, предлагать миграции, обновлять документацию, помогать с рефакторингом в четко очерченном контуре. Но чем ближе изменение к критическому коду, данным пользователей или архитектурным инвариантам, тем меньше должно оставаться пространства для автономного «ну вроде сработало».
На уровне рынка это выглядит как взросление всей темы AI coding. Первый этап был про вау-эффект и замеры производительности. Следующий, похоже, будет про управляемость: какие процессы выдерживают агентную автоматизацию, а какие пока нет; где нужен человек в контуре; какие артефакты должны оставаться после работы агента; как компания доказывает самой себе, что новый уровень скорости не куплен ценой нового класса инцидентов. Если такие рамки, как AC/DC, приживутся, обсуждение AI в разработке станет менее романтическим, но заметно полезнее для тех, кто отвечает не за демо, а за реальную поставку продукта.