С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический CI\/CD, построенный вокруг pull request-ов и человеческого темпа разработки, плохо подходит для мира, где код всё чаще пишут агенты.<\/p>\n
До работы с агентами цикл разработки выглядел так: человек медленно пишет код → оформляет PR → CI прогоняет линтеры, тесты и сборку → другой человек ревьюит изменения → изменения попадают в основную ветку.<\/p>\n
В такой парадигме долгое время работы CI-пайплайна часто было ожидаемым и терпимым, потому что самая большая задержка всё равно была на стороне команды: разработчик писал код часами или днями, ревью тоже ждали часами или днями, PR жил долго.<\/p>\n
С агентами всё меняется: код генерируется быстро и относительно дёшево → задач становится больше → ветки с изменениями плодятся быстрее → PR становится слишком медленной и неудобной единицей работы → валидацию изменений нужно двигать внутрь агентного цикла.<\/p>\n
Но CI\/CD вряд ли не исчезает. Скорее он перестанет быть контуром вокруг которого происходит работа с изменениями и превратится в низкоуровневый слой для быстрой проверки изменений внутри агентного цикла. Почему так?<\/p>\n
CI\/CD в текущем виде был спроектирован для мира, где человек — главный агент.<\/p>\n
Человек держит в голове некое намерение: например, «хочу добавить кнопку оформления заказа». Потом проходит цикл: намерение → код → pull request → CI → код-ревью → merge. На каждом этапе может быть откат назад:<\/p>\n
Это уже агентный цикл, просто раньше агентом был человек. И в этом цикле роль harness-а (упряжки для агента) тоже выполнял человек: разработчик сам фокусировался на цели, писал код, запускал проверки, обрабатывал обратную связь от коллег и инструментов и доводил изменение до слияния.<\/p>\n
Когда код пишет не человек, а агент, меняются масштабы:<\/p>\n
Проблема не только в том, что CI в такой парадигме будет медленным. Проблема в том, что сам процесс слияния изменений становится бутылочным горлышком.<\/p>\n
Если сравнить git с журналом изменений, то все сгенерированные агентами изменения должны попасть в него последовательно. Это начинает напоминать проблему из мира баз данных: транзакции, блокировки, порядок применения изменений (пресловутый serializable). Когда людей мало и они работают медленно, окно для слияния изменений может быть долгим по времени. Когда агенты генерируют пачки изменений параллельно, основная ветка постоянно обновляется, и шанс, что рабочая ветка быстро устареет, резко возрастает.<\/p>\n
Сейчас, когда кодинговые агенты всё больше становятся привычным инструментом для команд, цикл разработки трансформируется примерно в такую схему:<\/p>\n
Цель + план\n ↓\nАгентный цикл:\n генерация кода\n внутренняя валидация: сборка, тесты, линтеры\n внешняя валидация: человек или специализированные агенты\n исправления по обратной связи\n ↓\nMerge Queue\n ↓\nРепозиторий<\/code><\/pre>Кажется, следующим шагом будет сокращение участия человека внутри быстрого агентного цикла. То есть разработчику уже не придётся смотреть каждую итерацию изменений и каждый PR. Для этого появятся специализированные агенты. Можно легко представить такую агентную команду:<\/p>\n
\n- основной кодинговый агент<\/li>\n
- агент-ревьюер по безопасности<\/li>\n
- агент-ревьюер по производительности<\/li>\n
- агент-тестировщик<\/li>\n
- агент-архитектор<\/li>\n
- агент, оценивающий функциональную корректность реализации по требованиям<\/li>\n<\/ul>\n
Человеку уже не нужно будет читать каждый diff, как это было раньше. Он будет смотреть на более высокий уровень:<\/p>\n
\n- была такая цель<\/li>\n
- вот что получилось<\/li>\n
- вот summary изменений<\/li>\n
- вот результат security-проверок<\/li>\n
- вот риски<\/li>\n
- вот демонстрация работы<\/li>\n<\/ul>\n
И только после этого принимать решение: approve, reject или «нужны правки».<\/p>\n
Также ставлю на то, что изменится сама концепция merge queue. Обычной очереди на слияние изменений будет недостаточно. Если много агентов параллельно меняют один и тот же код, системе придётся не просто запускать тесты перед merge, а группировать изменения, разрешать конфликты, проверять совместимость и выстраивать безопасный порядок применения.<\/p>\n
Изменятся и окружения для агентных проверок. Они станут более stateful: с заранее подготовленными зависимостями, прогретыми кэшами, локальным контекстом и сохранённым состоянием между итерациями. Иначе агентный цикл будет слишком медленным.<\/p>\n
В итоге мы получим не просто CI job после git push, а что-то ближе к continuous compute: вычислительную среду, которая постоянно работает вокруг intent-а, кода, валидации и изменений-кандидатов на слияние с основной веткой.<\/p>\n",
"summary": "ИИ-агенты меняют CI\/CD: код генерируется быстрее, PR становятся узким местом, а валидация переезжает внутрь агентного цикла. Разбираю, почему классический software delivery придётся переосмыслить.",
"date_published": "2026-05-14T00:52:40+03:00",
"date_modified": "2026-05-14T00:52:38+03:00",
"tags": [
"AI",
"CI\/CD",
"SDLC"
],
"_date_published_rfc2822": "Thu, 14 May 2026 00:52:40 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "10",
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": []
}
},
{
"id": "9",
"url": "https:\/\/agenticeng.ru\/all\/future-of-mcp\/",
"title": "Будущее MCP",
"content_html": "
Посмотрел доклад David Soria Parra из Anthropic про будущее MCP.<\/p>\n
В 2026 году узким местом для AI-агентов становятся уже не модели, а связность между разными компонентами ИИ-системы: как агент подключается к инструментам, данным, приложениям, какие права доступа у него есть, как вокруг всего этого строить UX и бизнес-сценарии.<\/p>\n
Основые тезисы из доклада Дэвида с моими дополнениями 👇🏻<\/p>\n
MCP — не серебряная пуля, а важный компонент агентной системы<\/h3>\n
Лучшие агенты будут использовать не только MCP, но и:<\/p>\n