С интересом наблюдаю, как инженерные процессы и инструменты, к которым мы привыкли за десятки лет, переосмысливаются под ИИ-нативный подход. Например, классический 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": "4",
"url": "https:\/\/agenticeng.ru\/all\/chto-ne-tak-s-vakansiyami-llm-engineer\/",
"title": "Что не так с вакансиями LLM Engineer",
"content_html": "
В 2026 году вакансий, связанных с ИИ, большими языковыми моделями и агентами, стало заметно больше и в России, и за ее пределами. Технологические компании, банки и даже обычный enterprise поняли, куда движется индустрия, и начали срочно внедрять ИИ в продукты и внутренние процессы.<\/p>\n
Если открыть hh.ru, LinkedIn или Telegram-каналы с вакансиями, легко увидеть набор ролей, которые постоянно пересекаются по описанию и требованиям:<\/p>\n
\n- LLM Engineer<\/li>\n
- ML Engineer<\/li>\n
- AI Engineer<\/li>\n
- AI Architect<\/li>\n
- иногда еще что-то вроде «AI Automation Engineer»<\/li>\n<\/ul>\n
Особенно часто встречается вакансия LLM Engineer. И вот тут начинается путаница.<\/p>\n
Например, в одной вакансии Senior LLM Engineer требуют:<\/p>\n
\n- 2+ года коммерческой разработки на Python<\/li>\n
- практический опыт с LangChain, LlamaIndex, prompt engineering, RAG<\/li>\n
- подтвержденный опыт разработки и внедрения AI-решений<\/li>\n<\/ul>\n
Смотришь другую вакансию — уже Team Lead LLM Engineer. А там:<\/p>\n
\n- создание и развитие RAG-систем, включая Agentic RAG<\/li>\n
- observability для агентов<\/li>\n
- сервисы обработки документов<\/li>\n
- организация разметки данных<\/li>\n
- дообучение мультимодальных моделей<\/li>\n
- LLM-as-a-Judge и quality pipelines<\/li>\n
- вывод моделей и сервисов в production<\/li>\n<\/ul>\n
Проблема в том, что под одним и тем же названием компании часто описывают совершенно разные роли<\/b>.<\/p>\n
Где-то под LLM Engineer реально подразумевается человек, который работает с моделями как с объектом исследования и улучшения: оценка (evals), промптинг, fine-tuning, data curation, quality loops, иногда даже инференс и serving.<\/p>\n
А где-то под тем же названием ищут обычного сильного прикладного инженера, который должен собирать AI-функции в продукте: RAG, агенты, интеграции, пайплайны, наблюдаемость (observability), безопасность, продакшен-уровень.<\/p>\n
А иногда компания просто ищет единорога, который одновременно умеет:<\/p>\n
\n- тренировать и дообучать модели<\/li>\n
- строить RAG и агентные системы<\/li>\n
- делать evals<\/li>\n
- поднимать production-инфраструктуру<\/li>\n
- выстраивать MLOps<\/li>\n
- а в идеале еще и оптимизировать инференс<\/li>\n<\/ul>\n
Естественно, когда бэкенд- или фуллстэк-разработчик, который хочет перейти в прикладной ИИ (applied AI), читает такую вакансию, у него быстро появляется мысль: «я вообще не подхожу».<\/p>\n
И это часто ложное ощущение.<\/p>\n
Где проходит граница<\/h2>\n
Проблема рынка в том, что названия ролей пока не устоялись. Но на практике полезно различать хотя бы два типа задач.<\/p>\n
LLM Engineer<\/h3>\n
Это роль ближе к работе с самими моделями и качеством их поведения.<\/p>\n
Обычно сюда попадает:<\/p>\n
\n- выбор и сравнение моделей<\/li>\n
- построение evals (оценки)<\/li>\n
- prompt engineering как системная дисциплина, а не просто подбор промптов<\/li>\n
- эксперименты с quality loops<\/li>\n
- работа с fine-tuning или post-training<\/li>\n
- участие в проектировании AI-архитектуры на уровне поведения модели и ее качества<\/li>\n<\/ul>\n
Для такой роли действительно полезны:<\/p>\n
\n- хороший кругозор в NLP и LLM<\/li>\n
- понимание того, как устроены современные модели<\/li>\n
- умение читать статьи, документацию и разбирать бенчмарки<\/li>\n
- привычка много экспериментировать и валидировать гипотезы<\/li>\n<\/ul>\n
AI Engineer \/ Applied AI Engineer<\/h3>\n
Это прикладная разработка: создание ценности для продукта с помощью уже существующих моделей и инструментов.<\/p>\n
Обычно сюда относится:<\/p>\n
\n- AI-функции внутри продукта<\/li>\n
- tool calling<\/li>\n
- RAG<\/li>\n
- агенты и их оркестрация<\/li>\n
- интеграции с внешними системами<\/li>\n
- оценка (eval) и наблюдаемость (observability) на уровне приложения<\/li>\n
- надежный продакшен-код вокруг моделей<\/li>\n<\/ul>\n
Здесь важнее другое:<\/p>\n
\n- умение строить сервисы<\/li>\n
- понимать ограничения LLM и не ломать продукт об эти ограничения<\/li>\n
- уметь отлаживать качество: проблема в данных, retrieval, prompt, tool use или модели<\/li>\n
- уметь доводить систему до продакшена, а не просто собирать демо<\/li>\n<\/ul>\n
И вот здесь важный тезис: во многих вакансиях под названием LLM Engineer на самом деле ищут именно AI Engineer<\/b>. То есть разработчика с сильной бэкенд- или фуллстэк-базой, который умеет применять LLM в реальных системах.<\/p>\nКак могут выглядеть вменяемые требования к AI Engineer<\/h2>\n
Например, так:<\/p>\n
\n- уверенное владение Python или TypeScript<\/li>\n
- умение писать чистый код, тесты и поддерживаемые сервисы<\/li>\n
- базовое понимание LLM: токены, контекст, temperature, top-p, ограничения по длине контекста<\/li>\n
- опыт промптинга моделей: шаблоны, few-shot, structured output, tool\/function calling<\/li>\n
- опыт разработки RAG-систем и работы с векторными хранилищами<\/li>\n
- опыт интеграции LLM в сервисы<\/li>\n
- понимание Docker и контейнеризации<\/li>\n
- навыки диагностики качества и производительности AI-сервисов<\/li>\n
- базовое понимание безопасности и ограничений при работе с LLM<\/li>\n<\/ul>\n
Как видно, тут нет обязательного требования знать Transformer на уровне LLM-инженера\/исследователя, заниматься fine-tuning, строить MLOps-платформу или разбираться в CUDA.<\/p>\n
И это нормально.<\/p>\n
Что с этим делать<\/h2>\n
У меня здесь два простых совета.<\/p>\n
Рекрутерам и нанимающим менеджерам<\/h3>\n
Если вам нужен прикладной инженер, который будет встраивать ИИ в продукт, так и пишите.<\/p>\n
Не называйте вакансию LLM Engineer только потому, что это звучит модно. Чем точнее вы обозначите границы роли, тем лучше будет воронка:<\/p>\n
\n- меньше нерелевантных откликов<\/li>\n
- меньше самоотсечения хороших кандидатов<\/li>\n
- выше шанс быстрее закрыть позицию<\/li>\n<\/ul>\n
Не стоит искать единорога там, где на самом деле нужен сильный инженер-разработчик с хорошим продуктовым и системным мышлением.<\/p>\n
Разработчикам, которые хотят перейти в Applied AI<\/h3>\n
Не отбрасывайте вакансию только потому, что в ней в одну кучу свалены RAG, агенты, evals, дообучение, observability и MLOps.<\/p>\n
Очень часто это просто плохо написанное описание, а не реальный список того, чем вы будете заниматься каждый день.<\/p>\n
Поэтому:<\/p>\n
\n- уточняйте на первом же созвоне, что реально входит в зону ответственности<\/li>\n
- показывайте пет-проекты и рабочие кейсы<\/li>\n
- рассказывайте не только про «я пробовал ChatGPT», а про реальные инженерные задачи<\/li>\n
- не думайте, что без опыта в ML\/LLM вам закрыт путь в ИИ разработку<\/li>\n<\/ul>\n
Для входа в прикладной ИИ (applied AI) не обязательно быть исследователем. Во многих случаях достаточно хорошей инженерной базы и нормального понимания того, как LLM ведут себя в реальных системах.<\/p>\n
Рынок еще долго будет путаться в названиях. Но это не значит, что в него нельзя зайти.<\/p>\n",
"summary": "В 2026 году вакансий, связанных с ИИ, большими языковыми моделями и агентами, стало заметно больше и в России, и за ее пределами",
"date_published": "2026-04-10T10:27:43+03:00",
"date_modified": "2026-04-22T11:58:12+03:00",
"tags": [
"AI",
"LLM",
"Карьера",
"Найм"
],
"_date_published_rfc2822": "Fri, 10 Apr 2026 10:27:43 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "4",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
}
],
"_e2_version": 4199,
"_e2_ua_string": "Aegea 11.5 (v4199)"
}