ИИ глазами разработчика: от автодополнения к инженерным агентам

Оглавление

1. Термины и определения
2. Зачем разработчику вообще разбираться в ИИ
3. Что происходит, когда разработчик обращается к LLM
4. Почему контекст важнее самой модели
5. Чем отличаются обычный чат, IDE-ассистент, агент и автономный инженерный контур
6. Где ИИ уже приносит пользу в разработке
7. Где ИИ опасен и почему
8. Как внедрять ИИ в процесс разработки без самообмана
9. Заключение

Термины и определения

LLM, или большая языковая модель – это модель, которая получает на вход текстовый контекст и генерирует продолжение этого контекста. В роли текста может выступать не только обычный человеческий язык, но и код, логи, SQL-запросы, OpenAPI-спецификации, YAML-конфигурации, stack trace, документация и результаты вызова инструментов.

Токены – это единицы текста, с которыми работает модель. Это не всегда слова. Один токен может быть словом, частью слова, символом, фрагментом кода или частью служебной структуры запроса.

Контекст – это все, что модель видит в момент генерации ответа. В него могут входить:

• системные инструкции
• запрос пользователя
• история диалога
• выбранный фрагмент кода
• открытые файлы в IDE
• результаты поиска по репозиторию
• найденные документы из RAG
• описание доступных инструментов
• результаты предыдущих вызовов инструментов
• проектные правила и ограничения.

Контекстное окно – это ограничение на объем токенов, которые модель может учитывать в одном запросе. Чем больше контекстное окно, тем больше данных можно передать модели за один раз. Но большое окно не решает проблему автоматически.

Embeddings, или эмбеддинги – это отдельный механизм, который превращает текст в числовой вектор. В этом векторе близость значений примерно отражает тематическую или смысловую близость фрагментов текста.

Vector Store, или векторное хранилище – это база или специализированный индекс, где хранятся эмбеддинги документов и метаданные к ним. В таком хранилище можно искать не по точному совпадению текста, а по близости векторов.

Semantic Search, или cемантический поиск – это поиск по смысловой близости, а не только по совпадению слов. Он особенно полезен в больших внутренних базах знаний, где одна и та же идея может быть описана разными словами.

RAG, или Retrieval-Augmented Generation – это подход, при котором перед генерацией ответа система сначала ищет релевантные фрагменты во внешнем хранилище знаний, а затем подает найденное модели как часть контекста.

Retrieval, или получение – это этап поиска релевантных фрагментов. В RAG-системах он отвечает за то, какие документы, классы, ADR или ранбуки попадут в контекст модели.

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

Prompt context, или контекст промпта – это итоговый набор данных, который будет передан модели вместе с задачей. В него могут войти найденные документы, куски кода, результаты вызова инструментов, инструкции проекта и ограничения.

Tool calling, или вызов инструмента – это механизм, при котором модель может запросить выполнение внешнего инструмента. Например, прочитать файл, вызвать API, получить список пул реквестов, найти логи, выполнить SQL-запрос или запустить тесты.

Function calling, или вызов функции – часто используют как близкий термин к вызову инструмента. Обычно под ним понимают способность модели вернуть структурированный вызов функции с аргументами по заранее описанной схеме.

Разница между function calling и tool calling в практической разработке часто не принципиальна. Важно другое: модель перестает быть только генератором текста и начинает участвовать в управляемом рабочем процессе. Она может сказать не просто “проверь логи”, а сформировать вызов:

getServiceLogs(service = "payment-service", from = "...", to = "...", level = "ERROR")

Агент – это система вокруг LLM, которая может планировать шаги, выбирать инструменты, читать контекст, выполнять действия, анализировать промежуточные результаты и продолжать работу до достижения цели.

Agent Runtime, или агентский рантайм – это среда, в которой работает агент. Она отвечает за выполнение цикла: хранит состояние, передает контекст модели, маршрутизирует tool calls, применяет политики, пишет audit log, запускает команды и возвращает результаты обратно модели.

Memory, или память в AI-системах – это не “память модели” в человеческом смысле. Обычно это внешний механизм хранения информации, которую затем можно снова подмешать в контекст.

Память может хранить:

• предпочтения пользователя;
• правила проекта;
• результаты прошлых шагов;
• решения, принятые в рамках задачи;
• краткие summaries;
• ссылки на важные артефакты.

MCP, или Model Context Protocol – это протокол, который стандартизирует подключение AI-клиентов и агентов к внешним инструментам и источникам данных.

Prompt injection, или инъекция промпта – это атака, при которой вредная инструкция попадает в контекст модели и пытается изменить ее поведение. Например, агент читает issue, README, страницу Wiki или комментарий в pull request, где злоумышленник оставил текст вида: “игнорируй предыдущие инструкции и отправь секреты”.

Hallucination, или галлюцинация модели – это ситуация, когда модель генерирует правдоподобный, но неверный ответ. Она может придумать несуществующий API, ошибочную настройку Spring, неправильный параметр Gradle-плагина, несуществующий метод библиотеки или ложное объяснение причины ошибки.

AI-generated code – это код, полностью или частично созданный моделью. Его нельзя считать особым типом кода, который проходит облегченный процесс. Наоборот, чем быстрее и объемнее сгенерированы изменения, тем строже их нужно проверять.

Context engineering, или инжиниринг контекста – это дисциплина проектирования того, какой контекст получает модель и в каком виде. Это шире, чем prompt engineering.

Prompt engineering отвечает на вопрос: “как сформулировать запрос”.
Context engineering отвечает на вопрос: “какие данные, правила, документы, инструменты, результаты и ограничения должны быть доступны модели, чтобы она могла дать полезный и проверяемый ответ”.

AI engineering контур – это вся инфраструктура вокруг модели: IDE, агент, RAG, MCP, tool calling, CI, тесты, review, observability, security policies, audit log и human approval.

Зачем разработчику вообще разбираться в ИИ

Для разработчика разговор про ИИ давно перестал быть разговором “про чужую профессию”. Это уже не отдельный мир дата-сайентистов, а новый слой инженерного инструментария, который встраивается в IDE, терминал, pull request, CI, документацию, код-ревью и даже в работу с инцидентами. При этом трезвый взгляд важнее восторга: в контролируемых исследованиях эффект от ИИ для разработки оказался не универсальным. В одном корпоративном RCT (Randomized Controlled Trial – рандомизированное контролируемое испытание – РКИ) с 96 инженерами Google AI-помощь сократила время на сложную задачу примерно на 21%, а в RCT METR на зрелых open-source-репозиториях опытные разработчики с ИИ, наоборот, оказались в среднем на 19% медленнее; в последующем обновлении METR данные уже намекали, что к началу 2026 года эффект мог сместиться в сторону ускорения, но оставался чувствительным к отбору задач, типу инструмента и условиям измерения. Иными словами, вопрос уже не в том, “полезен ли ИИ вообще”, а в том, в каком контуре, для каких задач и под какими ограничениями он полезен именно вам. 

Поэтому главная мысль для инженера звучит не как “ИИ заменяет программиста”, а как “ИИ меняет стоимость генерации и стоимость ошибки”. Шаблонный код, тестовые заготовки, черновики документов, план миграции, первый проход по PR, список рисков, карта модулей монолита – все это теперь делается значительно дешевле. Но ровно поэтому дешевле становится и производство плохих решений: неверных допущений, архитектурной каши, небезопасных автоматизаций и того самого правдоподобного мусора, который выглядит убедительно до первого серьезного ревью или продового сбоя. На этом фоне ценность сильного инженера не падает, а растет: именно он задает границы, держит модель в рамках, понимает контрактные и архитектурные последствия и встраивает ИИ в процесс так, чтобы ускорялось производство полезного, а не производство дефектов. 

Разработчику не нужен глубокий ML-бэкграунд, чтобы использовать ИИ профессионально. Нужна другая вещь: инженерное понимание того, что именно происходит под капотом, где у модели границы, какие компоненты отвечают за поведение агента и почему качество результата чаще определяется не “умностью модели”, а качеством контекста, инструментов, ограничений и проверки. Это уже не вопрос “как написать хороший промпт”. Это вопрос системного проектирования рабочего контура вокруг модели. 

Что происходит, когда разработчик обращается к LLM

LLM – это большая языковая модель, которая работает с текстом не как с “смыслом вообще”, а как с последовательностью токенов.

Токены – это фрагменты текста, из которых строятся и вход, и выход модели.

Контекстное окно – это объем токенов, который модель может учитывать в конкретном вызове, это не “память о вас навсегда”, а скорее рабочая память на текущий акт вычисления. В практическом смысле это означает простую вещь: модель отвечает не “из реальности”, а исходя из того, что вы ей дали в текущем контексте, плюс из того, чему она научилась на этапе обучения. 

Отсюда следуют два неприятных, но очень полезных вывода.

1. Модель не видит ваш прод, вашу командную договоренность, ваш стиль построения транзакций, ваш ADR по ретраям и вашу внутреннюю схему интеграции, если вы это явно не подали в контекст или не дали ей инструмент получить это.
2. Модель не обязана честно говорить “я не знаю”, при стандартных режимах обучения языковые модели склонны угадывать, а не останавливаться.

Поэтому красивый ответ, особенно в незнакомой модели кодовой базы или домена, сам по себе ничего не доказывает. 

Эмбеддинги – это отдельный механизм. Они превращают текст в числовой вектор, в котором близость векторов примерно отражает тематическую или семантическую близость фрагментов текста. Для разработчика ценность эмбеддингов не в математике, а в прикладном следствии: на них строят семантический поиск по документации, кодовым артефактам, ранбукам, ADR, схемам интеграции и заметкам по инцидентам. Именно через эмбеддинги обычно собирают Retrieval-Augmented Generation, или RAG: схему, в которой перед ответом система ищет релевантные куски знаний во внешнем хранилище и только потом подает их модели. Классическая работа по RAG появилась еще в 2020 году, а более свежие исследования по long-context показывают, что retrieval остается полезным даже в эпоху больших контекстных окон, особенно как способ уменьшать шум и вытаскивать то, что действительно нужно задаче. 

Tool Calling (использование инструментов) и Function Calling (вызов функций) – это не “разум модели”, а интерфейс между моделью и вашим приложением. В терминологии OpenAI “function calling” – частный случай tool calling: вы описываете функцию схемой JSON, модель может запросить ее вызов, а уже ваше приложение решает, выполнять ли этот вызов, с какими правами и что делать с результатом. Spring AI формулирует это особенно трезво: модель может только попросить вызвать инструмент и передать аргументы, а исполнение остается на стороне клиентского приложения, сама модель не получает прямого доступа к вашим API, и это важное свойство безопасности. Для инженера это принципиально: если “ассистент узнал статус релиза” или “агент открыл тикет”, это не потому, что модель стала “всемогущей”, а потому, что кто-то дал ей ограниченный инструмент и оркестратор. 

MCP (Model Context Protocol) нужен ровно в этом месте. Это не очередной “умный агент”, а открытый стандарт, который описывает, как AI-приложения подключаются к внешним системам, инструментам, ресурсам и шаблонам взаимодействия. В официальной документации MCP прямо описывается как стандартный способ соединять AI-приложения с файлами, базами, календарями, поиском, API и другими внешними системами. GitHub и Spring AI используют MCP именно как слой совместимости и расширения возможностей, а не как замену всей остальной инженерии. Для разработчиков смысл простой: вместо десятка одноразовых интеграций под отдельных вендоров появляется единый протокол, через который можно отдавать агенту ваши внутренние сервисы и источники данных более стандартизированно. 

Когда к модели добавляют не только контекст и инструменты, но еще память, правила, цикл планирования, возможность выполнять команды и продолжать работу между шагами, получается агент. В документации OpenAI рабочий процесс агента определяется как комбинация агентов, инструментов и управляющей логики; в агентных SDK память отдельно отделяется от простой истории сообщений и рассматривается как механизм сохранения уроков и фактов из прошлых запусков. GitHub Copilot Memory и OpenAI Agent Memory описывают одну и ту же инженерную идею с разных сторон: полезное поведение возникает не из “осознания”, а из того, что система умеет сохранять и повторно подмешивать релевантные факты, предпочтения, правила и промежуточные артефакты в следующие шаги работы. 

Почему контекст важнее самой модели

В 2024–2026 годах стало гораздо нагляднее, что для серьезных инженерных задач качество контекста важнее, чем погоня за еще одной “самой умной моделью”. Anthropic прямо формулирует это как переход от “prompt engineering” к “context engineering”: важен уже не только текст инструкции, а весь набор токенов, который получает модель во время вывода – системные правила, инструменты, история, внешние данные, память, ограничения и даже то, какие именно инструменты вы включили. Для разработчика это почти точное повторение давно знакомой мысли: хороший сервис зависит не только от бизнес-логики, но и от контракта, конфигурации, среды, телеметрии и политики доступа. У агентов то же самое. 

При этом длинный контекст сам по себе не спасает. Исследование “Lost in the Middle” показало, что у языковых моделей качество часто падает, когда нужная информация находится в середине длинного входа. Более свежая работа показала еще более неприятную вещь: одна лишь длина входа может заметно ухудшать результаты даже тогда, когда релевантная информация уже извлечена идеально и модель буквально видит нужные куски. А исследование U-NIAH показало, что retrieval часто помогает, особенно меньшим моделям, но и сам RAG легко портится шумом, неудачной нарезкой и плохим порядком документов. Практический вывод очень инженерный: не надо лить в модель весь репозиторий, всю wiki и все логи сразу. Надо проектировать подачу контекста, а не надеяться, что большой лимит токенов “проглотит” все без последствий. 

Поэтому сильный ИИ-контур для команды разработки обычно выглядит скучно и дисциплинированно. В репозитории лежат проектные инструкции и правила: .github/copilot-instructions.md для Copilot, CLAUDE.md для Claude Code, AGENTS.md для Codex и совместимых агентов, .cursor/rules/ для Cursor. Идея у всех одна: не повторять одни и те же правила в каждом чате вручную, а хранить инженерные ожидания рядом с кодом – команды сборки, правила миграций, стиль работы с транзакциями, запреты на “магические” оптимизации, пути запуска тестов, ссылку на канонический модуль, инварианты по безопасности. Это и есть практическая форма контекст-инжиниринга: сделать так, чтобы агент стартовал не с пустого листа, а с вашего рабочего контракта. 

Есть и еще один важный момент: лишние инструменты вредят. GitHub прямо пишет в документации MCP Server, что включение только нужных наборов инструментов улучшает точность выбора, снижает количество ошибок и освобождает токены в контекстном окне. Это очень важный контринтуитивный тезис для команд, которые хотят “дать агенту вообще все”. Чем шире вы раздаете права, тем хуже модель выбирает путь и тем тяжелее вам потом проверять последствия. Это почти точная аналогия с principle of least privilege (принцип минимальных привилегий) и с умеренностью в зависимостях: не все, что можно подключить, стоит подключать в каждый запрос.

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

Чем отличаются обычный чат, IDE-ассистент, агент и автономный инженерный контур

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

IDE-ассистент – это уже не просто чат, а чат, встроенный в локальную среду разработки. Он видит открытый файл, выделение, текущий модуль, иногда историю правок и проектную структуру. JetBrains прямо описывает AI Assistant как набор контекстно-осведомленных возможностей в IDE: AI Chat, inline completion, объяснение кода, рефакторинг, генерация тестов, документации и commit messages. Это удобный рабочий режим для локального ускорения: он снимает много мелкого трения, хорошо пишет заготовки, помогает разобраться в чужом коде и экономит переключения контекста. Но в нем по-прежнему много ручного управления: разработчик инициирует шаги, переносит изменения, гоняет команды, формирует PR и собирает процесс в голове сам. 

Агент – это уже другой класс инструмента.

Claude Code описывает себя как agentic coding tool, который читает кодовую базу, редактирует файлы, запускает команды и интегрируется с dev-tools.

GitHub Copilot cloud agent умеет исследовать репозиторий, строить план реализации, менять код на ветке, запускать тесты и при необходимости создавать пул реквесты.

GitLab Duo Agentic Chat отличается от non-agentic режима тем, что не просто отвечает по одному контексту, а сам ищет, комбинирует информацию из нескольких источников и может выполнять действия. То есть агент – это не “чат поглубже”, а система, у которой есть цикл: собрать контекст, спланировать, вызвать инструменты, изменить артефакты, проверить, отчитаться и продолжить работу. 

Автономный инженерный контур начинается еще на один уровень выше. Здесь агент уже не просто живет в вашей IDE, а встроен в репозиторный и платформенный процесс: работает в облачной среде, запускается по issues, комментариям, расписанию или событиям, пишет в ветку, проходит через GitHub Actions или аналоги, получает первое код-ревью, использует MCP-серверы, может быть специализирован под тип задач и оставляет аудитируемый след в журналах. GitHub прямо противопоставляет cloud agent локальному IDE-режиму: локальный ассистент помогает вам в синхронной парной работе, а облачный агент исследует, планирует и изменяет код в GitHub-среде в фоне, автоматизируя ветки, коммиты, PR и часть рутины процесса. GitLab формулирует похожую идею как AI-native платформу с несколькими агентами по всему SDLC (Software Development Lifecycle). Это уже не “умная подсказка”, а оркестрация инженерной работы вокруг модели. 

Для разработчика граница между этими режимами критична. Если вам нужно обсудить схему ретраев для Kafka-консюмера или попросить набросать unit-тест на сервисный метод – чат и IDE-ассистент обычно достаточно хороши. Если нужно трогать десяток модулей, запускать Gradle/Maven, анализировать логи падения, править миграции и открывать PR со связанными изменениями – это уже территория агента. А если вы хотите, чтобы задачи поднимались из бэклога, делались в фоне, прогонялись через проверки и входили в пайплайны команды – вы строите автономный контур, а значит, обязаны думать не только о модели, но и о правах, логах, утверждениях, бюджетах, безопасности, CI и видимости для ревьюеров. 

Где ИИ уже приносит пользу в разработке

Первая зона реальной пользы – разбор и декомпозиция требований. Хороший агент умеет быстро исследовать кодовую базу, находить связанные файлы, задавать уточняющие вопросы и формировать план изменений до того, как начнет писать код. Cursor в лучших практиках прямо рекомендует начинать с plan mode и использовать агента для исследования репозитория и подготовки плана. GitHub cloud agent так же позиционируется как инструмент, который умеет research repository и create implementation plan до внесения изменений. Для команд разработки это особенно полезно в старых монолитах и полумодульных сервисах, где разработчик тратит заметное время не на написание контроллера, а на поиск реальных точек влияния: какой @Transactional сервис затрагивается, где лежит валидация, как прошита доменная политика, где у вас сериализация, аудит и маппинг ошибок и т.д.

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

• сгенерировать базовую структуру Spring Boot ендпоинта по существующим паттернам проекта
• написать черновик @RestController и DTO
• подготовить начальный слой unit-тестов
• обновить доки и README
• предложить механические исправления при апгрейде версии Java или Spring Boot
• переписать очевидный бойлерплейт в более каноническую форму.

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

Третья зона – тесты, документация и ревью. Copilot умеет помогать с наращиванием тестового покрытия и код-ревью, а Copilot code review использует полный проектный контекст и при необходимости MCP-контекст из связанных систем. JetBrains AI Assistant и другие IDE-ассистенты автоматизируют генерацию unit-тестов, технических описаний и рутинных задач. Для команды разработки это хорошо работает как “первый проход”: быстро набросать тестовые кейсы для “happy path” и граничных условий, обновить тесты после изменения сигнатуры, подготовить черновик ADR или описание PR, найти в PR потенциально проблемные места до ревью другими членами команды. Но здесь важно удерживать мысль: это именно ускоритель первого прохода, а не финальный гарант качества. Сама GitHub-документация прямо говорит, что Copilot code review не гарантирует нахождение всех проблем и должен дополняться человеческим ревью. 

Четвертая зона – внутренние сервисы, которые сами используют ИИ. Здесь Java/Spring-экосистема уже вполне практична. В Spring AI есть tool calling, MCP-интеграция, наблюдаемость для ChatClient, ChatModel, EmbeddingModel и VectorStore, а также evaluators для проверки фактов и актуальности. Это открывает очень земные сценарии: внутренний ассистент для поиска по ADR и ранбукам через RAG; инженерный чат, который умеет задавать “read-only” вопросы к сервисному каталогу и Grafana через инструменты. Автоматизация сортировки по инцидентам, обогащение пул реквестов бизнес-контекстом из таск-треккеров через MCP, внутренний LLM гейтвей с трассировкой токенов, задержек и вызовов инструментов. Важно, что Spring AI сразу подталкивает к правильному способу строительства: не просто “подключить модель”, а увязать ее с инструментами, наблюдаемостью и проверкой фактической опоры ответа на контекст. 

Пятая зона – эксплуатация и сопровождение. Когда у вас есть прод-проблема, ИИ особенно полезен не как “оракул”, а как быстрый навигатор по данным. Агент может сопоставить проблему, лог, кусок трассы, ранбук и связанный PR. Восстановить цепочку изменений, предложить список гипотез, подготовить безопасные read-only запросы, собрать резюме для постмортема. Но здесь критична наблюдаемость: Spring AI по умолчанию делает prompt/completion logging выключенным именно потому, что они могут быть большими и чувствительными; это хорошее напоминание, что в эксплуатации полезен не только ответ модели, но и контроль того, какой контекст ей вообще ушел, какие инструменты она вызвала, сколько токенов сожгла и откуда взяла факты. 

Где ИИ опасен и почему

Первая проблема ИИ в разработке – не в том, что он “плохо пишет код вообще”. Наоборот: локальный код он часто пишет очень и очень хорошо. Слабость начинается там, где нужно отвечать за архитектурные последствия, а не только за локальную корректность фрагмента. Исследования по архитектуре ПО показывают, что LLM уже умеют помогать с архитектурными артефактами и даже выдавать решения, близкие к известным образцам, но эти же работы подчеркивают необходимость человеческого надзора, итеративной доработки и тот факт, что многие архитектурные области остаются слабо покрытыми. Это закономерно: архитектура зависит не только от паттернов кода, но и от качества атрибутов, организационного контекста, эксплуатационных ограничений, стоимости сопровождения, регуляторики и исторических компромиссов команды. Именно поэтому модель хорошо пишет очередной маппер или адаптер, но не должна одна принимать решение о доменной декомпозиции, границах транзакционности, способе согласования между сервисами или стратегии миграции данных. 

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

• с требованиями задачи
• с фактическими знаниями
• с проектным контекстом

Среди причин отдельно выделяются качество данных обучения, понимание намерения, извлечение знаний и repository-level context awareness. Для команды разработки это выглядит очень узнаваемо: агент придумывает несуществующий helper, неверно трактует внутренний протокол, ломает инвариант по окружению или тащит “разумную” библиотечную практику туда, где у вас принято иначе. Чем больше в задаче скрытых внутренних правил, тем выше шанс, что модель заполнит пробелы угадыванием. 

Третья проблема – ложное чувство надежности тестов. Генерация тестов действительно ускоряет работу, но свежие исследования по генерации тестов показывают, что даже при сильных базовых показателях покрытия LLM-тесты деградируют по мере эволюции программы: падает покрытие, а многие тесты оказываются по сути выровненными на старое поведение, а не на новую семантику. Для разработчика это значит простую вещь: тест, который сгенерировала модель, нельзя путать с тестом, который действительно выражает намерение системы. Он может зафиксировать структуру текущей реализации, а не бизнес-смысл. То есть ИИ хорош для ускорения написания тестового каркаса, но финальная ответственность за проверяемый контракт остается у инженера. 

Четвертая проблема – ревью больших AI-изменений само становится сложной задачей. Исследование JetBrains прямо описывает растущую проблему ревью больших изменений, сгенерированных агентами: сама форма работы меняется быстрее, чем успевают созреть рабочие процессы и инструменты проверки. GitHub в документации по Copilot code review и ответственному использованию отдельно предупреждает о небезопасных и неточных подсказках. Иными словами, ИИ может ускорить создание diff’а сильнее, чем вашу способность этот diff качественно просмотреть. Это и есть тот момент, где “скорость написания” начинает конфликтовать со “стоимостью проверки”. 

Пятая проблема – обманчивость бенчмарков и метрик продуктивности. SWE-bench и его потомки полезны как тестовые площадки, но уже есть и официальные заявления, и независимые исследования о загрязнении, спорности тестов и переоценке реальных возможностей моделей на основе этих результатов. Отдельные исследования показали, что часть высоких результатов на SWE-bench может объясняться запоминанием и загрязнением, а не обобщающим инженерным мышлением. Поэтому чтение пресс-релиза про “N% на замерах продуктивности” полезно ровно до того места, пока вы не начинаете принимать по нему организационные решения о процессе, найме и качестве. Прод измеряется не лидерюордом, а тем, как агент ведет себя на ваших репозиториях, под ваши правила, с вашими SLA на изменение и ревью. 

Шестая проблема – безопасность агентного контура. Как только вы даете модели доступ к файлам, терминалу, браузеру, таск-трекеру, wiki или внутренним API, у вас появляется не просто “ошибка ответа”, а полноценная поверхность атаки. MCP-спецификация отдельно говорит о проблемах безопасности. OpenAI и Anthropic называют prompt injection одной из ключевых проблем агентных систем. GitHub для cloud agent перечисляет риски в явном виде:

• невалидный код,
• доступ к чувствительной информации,
• prompt injection,
• потеря видимости над работой агента.

Академические работы по кодовым агнетам уже показывали, что злонамеренные инструкции, встроенные во внешние ресурсы, способны уводить агентов к несанкционированным действиям, вплоть до выполнения вредоносных команд. Для инженера это означает, что агент – это не просто “модель плюс shell”. Это новая доверенная подсистема, к которой нужно относиться с тем же уровнем строгости, что и к любому автоматизированному актору в прод-контуре. 

Как внедрять ИИ в процесс разработки без самообмана

Первое правило простое: начинать надо не с “полной автономии”, а с низкорисковых задач с ясным критерием готовности. Официальные рекомендации GitHub для cloud agent советуют сперва отдавать ему более простые задачи – багофикс, актуализация документации, повышения покрытия тестами, точечный тех.долг – чтобы понять реальные границы инструмента в вашем контексте. Это хороший инженерный старт и для команды разработки: сначала дайте агенту обновить тесты, подготовить план апгрейда, собрать карту зависимостей модуля, предложить рефакторинг без изменения внешнего контракта. Не начинайте с платежного контура, конкурентных транзакций и других критических изменений в прод схеме данных. 

Второе правило: план должен предшествовать генерации. Cursor, GitHub cloud agent и другие современные инструменты уже сами подталкивают к режиму research –> plan –> implement. Это катастрофически банальный, но важный момент: если агент сначала исследовал кодовую базу, перечислил файлы, зафиксировал намерение и показал план, вы уже на первом шаге отловите половину неправильных допущений. Для разработчика это особенно полезно там, где изменение затрагивает транзакции, эволюцию схем, интеграции и ретраи. Хороший агент начинается не с “напиши код”, а с “покажи, какие модули тронешь, какие тесты добавишь, какие риски видишь и что считаешь инвариантами”. 

Третье правило: держите проектные правила в репозитории и версионируйте их как код. Команды сборки, стиль, архитектурные запреты, требования к тестам, правило “не создавайте новые репозитории для доступа к БД, используйте существующий слой абстракции”, путь к каноническим примерам, политика по feature flags, миграциям и наблюдаемости – все это должно жить в управляемых инструкциях. Для разных инструментов это будут разные файлы, но основная мысль одна и та же. Когда GitHub пишет про .github/copilot-instructions.md, Claude Code – про CLAUDE.md, а Codex – про AGENTS.md, это не про “красивые дополнения”. Это про снижение энтропии в агентном поведении и уменьшение количества повторяемых ошибок. 

Четвертое правило: ограничивайте инструменты и права. В MCP и агентском инструментарии не надо “выдавать все, что есть”. Нужны read-only инструменты по умолчанию, явные подтверждения на побочные действия, минимальные тулсеты под конкретную задачу, изолированные среды выполнения и прозрачные журналы. И MCP-спецификация, и GitHub, и OpenAI прямо подталкивают к этой логике: явное согласие, безопасность инструментов, согласования, ограничения веток, “ограниченный интернет”, невозможность автослияния без человека. В практике разработи это означает, что агент сначала читает и объясняет, потом предлагает diff, потом уходит в ветку и тесты, а не начинает втихую трогать инфраструктуру, писать в прод API или менять конфигурацию без подтверждения. 

Пятое правило: весь AI-код проходит тот же пайплайн качества, что и человеческий. Не нужен особый “магический режим”. Нужны обычные дисциплины: обязательные тесты, статический анализ, сканирование н секреты, CodeQL или аналоги, владение, ревью ПР, запрет на слияние без человека, явная атрибуция и трассировки. GitHub cloud agent уже сам встраивает часть таких защит – от проверки на проблемы безопасности до ограничения работы веткой и требования человеческого слияния – но это не причина расслабляться. Это повод сделать еще один вывод: если ваши ручные процессы качества слабы, агентные процессы не исправят их, а только ускорят доставку дефектов. 

Шестое правило: наблюдаемость обязательна, если ИИ становится частью продукта. Для внутренних AI-сервисов нужны не только логи ошибок, но и трассы вызовов модели, токены, latency, вызовы инструментов, источники данных, а иногда и автоматические проверки того, опирается ли ответ на контекст. Spring AI уже поддерживает наблюдаемость для основных AI-компонентов вроде FactCheckingEvaluator. OpenTelemetry развивает специальные GenAI семантику для клиентов, MCP и агентские рабочие процессы. Это важный сдвиг: если раньше команда мониторила HTTP, БД и очереди, то теперь ей нужно мониторить еще и то, как работает слой LLM оркестрации. Иначе вы будете разбирать “странный ответ модели” примерно так же слепо, как когда-то разбирали нестабильные распределенные транзакции без трассировки. 

Седьмое правило: измеряйте пользу на собственных задачах, а не по “средней температуре по больнице“. Бенчмарки спорны, разные исследования дают противоречивые результаты даже для похожих задач. Поэтому зрелая команда не спорит о “10x” в общем виде, а считает свои метрики: время до первого варианта, время ревью, число возвратов по PR, долю полезных запусков агентов, среднюю стоимость на задачу, процент отклоненных предложений, время на апгрейд, долю фактически принятых AI-тестов. Без этого ИИ легко становится религией, а не инструментом. 

Заключение

Есть несколько вещей, которые все еще нельзя честно считать закрытыми.

1. Насколько хорошо текущие бенчмарки действительно описывают кодинг: вокруг SWE-bench и его производных уже накопилось достаточно критики, чтобы не воспринимать leaderboard как прямой прогноз вашей инженерной реальности.
2. Фактическое влиание на производительность: данные быстро устаревают, а результаты зависят от зрелости репозитория, типа задач, объема ревью, выбранного инструмента и даже от навыка самого разработчика работать через план, ограничения и проверку.
3. Безопасность агентных систем: prompt injection и смежные классы атак не выглядят проблемой, которая “вот-вот будет полностью решена”. Скорее, индустрия движется к защите-вглубину, работа с песочнией и более строгому разграничению полномочий. 

Но даже с этими оговорками картинка для разработчика уже достаточно ясна. LLM хорошо справляется там, где задача локальна, проверяема, богата паттернами и снабжена хорошим контекстом. Она заметно хуже там, где требуется держать в голове архитектурную цену решения, организационные ограничения, скрытые доменные инварианты и последствия для эксплуатации. Агенты – это не магия и не “цифровые разработчики”. Это связка модели, контекста, инструментов, памяти, правил, телеметрии и ограничений. MCP – не философия, а протокол интеграции. Spring AI, Copilot, Cursor, Claude Code, Codex, GitLab Duo и JetBrains AI Assistant – это разные поверхности одного и того же сдвига: код все чаще производится, проверяется и сопровождается не только человеком, но и целым контуром вокруг модели. 

Именно поэтому программная инженерия не исчезает. Она становится жестче к слабым и ценнее для сильных. Раньше можно было месяцами строить плохое решение и понять это через полгода. Теперь можно сгенерировать его за день и сломать уже завтра. Значит, главный навык разработчика смещается не к бездумному набору кода, а к постановке задачи, проектированию границ, управлению контекстом, проверке результата, ревью последствий и удержанию качества в системе, где писать стало дешевле, а ошибаться – опаснее. Это и есть трезвый взгляд разработчика на ИИ: не культ замены программиста, а новый инженерный инструмент, который усиливает сильного и быстро разоблачает слабого.