Нейросеть приносит разработчику пользу там, где надо быстро собрать и связать контекст: разобрать незнакомый сервис, проследить путь поля от таблицы в базе до экрана, найти причину плавающего бага, набросать тесты, разобрать логи упавшей игры. Степан, разработчик с чуть более чем годовым опытом агентной разработки, применяет ИИ в работе, аналитике, тестировании, диагностике и хобби, и генерация кода в этом списке занимает лишь часть места (разбор семи сценариев).
Семь сценариев, о которых пойдёт речь: анализ чужой кодовой базы, восстановление пути данных, диагностика сложных багов, хаос-инжиниринг для нестабильных тестов, написание и проверка тестов с запуском в контейнерах, техническая диагностика компьютера по логам и системным инструментам, разбор сложного материала и редактирование текстов.
Рамка одна на все семь пунктов: агент ускоряет сбор фактов и черновики, решение и проверку оставляет человеку. Корпоративный код можно отдавать на анализ только при разрешении политик компании, об этом ниже отдельный раздел. Замеров скорости в исходном разборе нет, поэтому вместо выдуманных процентов ускорения в статье будут критерии проверки результата.
Зачем разработчику AI-агенты, а не только автодополнение кода
Автодополнение предсказывает следующую строку в открытом файле. Чат отвечает на вопрос, который вы целиком описали в промпте. Агент получает доступ к репозиторию, логам и терминалу, сам открывает десятки файлов, ищет связи и возвращает результат многошагового разбора. Разница видна на задаче «почему это поле пустое на экране у части пользователей»: автодополнение тут беспомощно, чат выдаст общий список причин, агент пройдёт по цепочке от контроллера до шаблона и покажет конкретные файлы.
Чем агент отличается от чат-бота с кодом
| Инструмент | Что даёт | Где ломается |
|---|---|---|
| Автодополнение | Скорость набора знакомого кода | Не видит проект целиком, не объясняет связи |
| Чат без доступа к проекту | Общие объяснения, примеры синтаксиса | Отвечает по усреднённому коду, детали вашего проекта додумывает |
| Агент с доступом к репозиторию и инструментам | Навигация, поиск связей, запуск команд, разбор логов | Ошибается в незнакомой архитектуре, требует проверки выводов |
Ключевой фактор - контекст. Если дать нейросети свою кодовую базу и спросить что-то по ней, вероятность ошибок заметно ниже: модели не нужно придумывать архитектуру с нуля, она анализирует то, что уже написано. Правило работает и в обратную сторону: чем меньше в промпте реального кода, тем больше в ответе правдоподобных выдумок.
Какие задачи делегировать агенту, а какие оставить себе
Практическое правило делит работу по цене ошибки. Сбор контекста, поиск связей, черновики тестов и разбор логов стоят дешево, если ответ неверный: вы это увидите на следующем шаге. Архитектурные компромиссы, выбор между решениями и утверждение «баг вызван вот этим» стоят дорого, потому что ошибка всплывёт позже и в другом месте.
- Агенту: навигация по репозиторию, вопросы по существующему коду, черновики тестов, анализ логов и конфигураций, генерация сценариев сбоев.
- Человеку: выбор архитектуры, оценка рисков, финальная причина бага, ревью и запуск тестов, любые действия с продакшеном.
Второй элемент - формулировка запроса. В промпт стоит добавлять требование показывать основание каждого вывода и запрет на догадки: «покажи, на чём основан каждый вывод, не додумывай, перепроверяй, уточняй». Такая фраза не убирает галлюцинации, но делает их заметнее: ответ без ссылок на файлы видно сразу.
Сопротивление части разработчиков делегированию растёт из вопросов авторства и ответственности, а не из качества генерации, и это отдельная тема: почему разработчики не хотят отдавать код ИИ-агентам.
Способ 1. Анализ незнакомой кодовой базы
Самый частый сценарий: вам дали большой сервис, который вы видите впервые. Разбор с агентом экономит часы на переключение между файлами, но не отменяет чтения кода. Механика простая: дать модели репозиторий или его часть и задавать вопросы по существующему коду. Тогда вероятность ошибок ниже, потому что архитектура уже есть и её не надо выдумывать (опыт Степана).
Что спрашивать по существу:
- Где точка входа HTTP-запроса и какие слои он проходит?
- Какие модули зависят от этого сервиса и что сломается при изменении контракта?
- Где обрабатывается конкретный сценарий, например отмена заказа?
- Какие места дублируют одну и ту же логику?
Как подготовить контекст и какие вопросы задавать
Запрос лучше собирать из четырёх блоков: цель, границы, формат ответа, требования к доказательствам. Без границ агент полезет в соседние пакеты и вернёт свалку. Без формата получите эссе на две страницы вместо списка файлов.
Цель: понять, как устроен сервис заказов. Границы: только каталог services/orders, не трогай infra и legacy. Формат: список слоёв с путями к файлам, 10 строк максимум. Доказательства: для каждого утверждения укажи файл и строку. Если данных не хватает, задай уточняющий вопрос, не додумывай.
Ограничение: агент ускоряет навигацию, чтение кода он не заменяет. Каждый вывод проверяйте по указанному файлу, особенно если речь о побочных эффектах и порядке вызовов. И главное: анализировать корпоративный код нейросетью стоит только тогда, когда это разрешено политиками компании. Если правила запрещают передавать код внешним сервисам, сценарий отменяется до разговора с безопасниками.
Способ 2. Отслеживание пути данных от БД до экрана
Пока поле из базы данных попадёт на экран пользователя, оно может несколько раз переименоваться, пройти через DTO и мапперы, объединиться с другими полями и вычислиться из нескольких значений. Вручную такую цепочку восстанавливать утомительно: десятки файлов, постоянные переключения, всё надо держать в голове. Когда путь идёт через несколько сервисов в разных репозиториях, задача растягивается на полдня. Нейросеть собирает цепочку целиком и возвращает её одним куском.
Формат результата, который удобно проверять:
| Слой | Файл | Что происходит с полем |
|---|---|---|
| База данных | миграция, таблица orders | колонка total_cents, целое число в копейках |
| Репозиторий | OrderRepository | читается как total_cents, без преобразований |
| DTO и маппер | OrderMapper | переименование в total, деление на 100 |
| Сервис | OrderService | добавляется доставка, сумма пересчитывается |
| Экран | OrderCard | форматирование по локали, округление |
Такой таблицы обычно достаточно, чтобы найти место, где сумма расходится с ожиданиями.
Промпт для восстановления цепочки через несколько репозиториев
Проследи путь поля total от таблицы в базе до отображения на экране. Укажи каждый слой, файл, преобразование и вычисления. Отдельно отметь места, где значение округляется или меняет тип. Если не хватает доступа к части репозиториев, скажи об этом прямо и перечисли пробелы, не додумывай.
Ограничение: при отсутствии доступа к части репозиториев цепочка получится неполной, и агент может подставить правдоподобный пропуск. Проверяйте каждое звено по файлу и не принимайте таблицу за истину, пока не сверили хотя бы места с преобразованиями типов.
Способ 3. Поиск причин сложных багов с помощью ИИ
Агент в роли аналитика работает, когда у него есть код и четкое требование не фантазировать. В исходном разборе приводится формулировка, которую можно копировать почти дословно:
Проанализируй кодовую базу и найди возможные причинно-следственные связи, которые могли привести к этому багу. Покажи, на чём основан каждый вывод. Не додумывай, перепроверяй, уточняй.
Иногда такой проход позволяет заметить зависимости, до которых вручную пришлось бы добираться очень долго: общий кэш у двух внешне несвязанных модулей, повторное использование одного соединения, порядок инициализации. Ценность в гипотезах, а не в приговоре. Причину подтверждает разработчик: логами, воспроизведением, минимальным тестом.
Как отделять гипотезы агента от подтверждённых причин
- Воспроизводимость: баг повторяется по шагам, которые вы можете записать.
- Лог или метрика: есть запись, где видно отклонение, а не только ожидание «так быть не должно».
- Минимальный тест: падает до правки, проходит после.
- Ссылка на код: файл и строка, где логика действительно работает так.
Просите агента помечать предположения явно: «раздели ответ на две части: подтверждено кодом и требует проверки». Ответ без такого разделения читается как уверенность, которой за ним нет.
Способ 4. Хаос-инжиниринг для нестабильных тестов и обрывов связи
Часть багов не воспроизводится в спокойной среде. Условия другие: большая конкуренция за ограниченные вычислительные ресурсы, нестабильная сеть, внезапно отвалившийся брокер сообщений. В таких условиях тест падает не на каждом прогоне, и обычный запуск ничего не показывает.
В исходном материале Степан упоминает, что ему нужно было починить нестабильный тест, но разбор кейса в доступном тексте обрывается, поэтому конкретные шаги здесь не пересказываются. Схема работы, которая приводит к результату, выглядит так: сначала агенту отдают код теста и описание окружения, затем просят перечислить классы сбоев, затем вместе с ним строят сценарии, которые эти сбои вызывают.
Как агенту поручить генерацию сценариев сбоев
- «Предложи 10 причин, по которым этот тест может быть нестабильным, и для каждой укажи, как её проверить».
- «Сгенерируй конфигурацию docker-compose с задержкой сети и падением брокера на 5 секунд».
- «Напиши скрипт, который ограничивает тестовый контейнер двумя ядрами и 256 МБ памяти».
- «Для каждого сценария объясни, какой класс багов он проверяет и что будет считаться успехом».
Требование объяснять класс багов отсекает бесполезные сценарии вроде случайной паузы перед проверкой. Ограничение жесткое: хаос-инжиниринг запускают в изолированной среде, на тестовом стенде или локально в контейнерах. Обрывы связи и падения брокера в продакшене устраивать нельзя, даже если очень хочется проверить гипотезу.
Способ 5. Написание и проверка тестов, тестирование функционала в контейнерах
Здесь две разные задачи, и путать их дорого. Первая: агент пишет черновик тестов по коду или по описанию поведения. Вторая: агент проверяет готовые тесты на прочность. Черновик ускоряет старт, проверка ловит тесты, которые проходят всегда.
Третья часть - запуск функционала в контейнерах. Агент поднимает сервис в изолированной среде, дергает эндпоинты, смотрит ответы и логи, то есть проверяет поведение, а не только читает код. Это ближе к реальному тестированию, чем вопрос «правильно ли написан этот обработчик».
Почему тесты от ИИ нужно проверять отдельным проходом
Типичные проблемы сгенерированных тестов повторяются:
- тест повторяет код и падает при любом рефакторинге, не проверяя смысл;
- нет негативных кейсов: проверено только счастливое поведение;
- моки подменяют интеграцию целиком, и реальная ошибка в контракте остаётся незамеченной;
- утверждения написаны так, что проходят при сломанной логике.
Отдельный проход формулируется так: «Найди в этих тестах утверждения, которые пройдут даже при сломанной логике. Для каждого предложи изменение кода, которое тест должен поймать». Дальше тесты запускает человек: агент может подогнать проверку под текущее поведение, включая неправильное. Про границы применимости AI-инструментов на своих задачах есть разбор на примере магазина за два вечера, там же чек-лист устойчивости процесса.
Способ 6. Техническая диагностика компьютера: логи, системные инструменты и драйвер RGB-клавиатуры
Агент выходит за пределы репозитория: он читает журналы событий, логи приложений и сведения о драйверах, а вы получаете разбор вместо бесконечного листания форумов. В описании материала Степана есть показательный случай: причиной вылета игры оказался драйвер RGB-клавиатуры. Пошаговый разбор в исходном тексте не раскрыт, поэтому ниже схема, которая к таким находкам обычно и приводит.
- Собрать факты: время вылета, код ошибки, записи в журнале событий системы, последние изменения.
- Попросить агента сгруппировать события по времени и назвать три вероятные причины с обоснованием.
- Проверить гипотезы по одной: отключить подозрительное устройство, обновить или откатить драйвер, посмотреть, повторяется ли вылет.
Драйвер подсветки клавиатуры в такой цепочке выглядит неожиданно ровно до момента, когда видишь в журнале ошибку его службы за секунду до падения игры. Такие совпадения по времени агент находит быстро, человек их потом подтверждает.
Какие данные и доступы нужны агенту для диагностики
- Журналы событий системы и логи приложений за период сбоя.
- Сведения о драйверах: версии, даты установки, ошибки загрузки.
- Конфигурация: модель GPU, версия драйвера, обновления системы.
- Список недавно установленного софта и подключённых устройств.
Доступ к системным инструментам требует осторожности: чтение логов безопасно, удаление драйверов и правка реестра нет. Решение об изменении системы принимает пользователь, агенту достаточно роли аналитика. Если нужен готовый десктопный инструмент, который читает логи и документы через чат, есть отдельный обзор Koda Desktop.
Способ 7. Изучение сложного материала и редактирование текстов с помощью нейросети
Тот же приём, что работает с кодом, работает с теорией: модель полезна, когда вы задаёте ей вопросы по конкретному материалу, а не просите пересказать тему. Разбор сложной статьи или документации превращается в диалог: непонятный термин, пример, границы применимости, проверка понимания.
Как задавать уточняющие вопросы, чтобы действительно понять тему
Цепочка из четырёх шагов закрывает большинство случаев:
- «Объясни этот абзац так, будто я впервые вижу тему, но уже знаю основы программирования».
- «Приведи конкретный пример, где это применяют, и пример, где это ломается».
- «Что здесь главное для практики, а что техническая деталь?»
- «Задай мне три вопроса на понимание и проверь мои ответы».
Последний шаг отличает разбор от чтения: приходится формулировать самому, и пробелы видны сразу.
Редактирование текстов идёт по похожей логике с поправкой на риск. Правка стиля, сокращение, проверка логики абзацев и единообразия терминов делегируются хорошо. Факты, цифры и формулировки требуют проверки: модель может упростить утверждение до неверного или потерять важную оговорку. Практика: правки порциями, по одному критерию за проход, с финальным сравнением смысла до и после.
Безопасность и ограничения: политики компании, обучение на диалогах и внутренний ИИ-ассистент
Правила здесь короткие и без исключений. Анализировать корпоративный код нейросетью стоит только тогда, когда это разрешено политиками компании. Если внутренние правила прямо запрещают передавать код внешним ИИ-сервисам, делать этого не нужно: экономия времени не оправдывает нарушение (практические советы по безопасности).
Второй пункт - настройки сервиса. Хорошая практика: отключить использование диалогов для обучения модели, у большинства популярных сервисов такая настройка есть. Третий - альтернатива: если внешние нейросети запрещены, нередко есть внутренний ИИ-ассистент в корпоративном контуре. Кодовая база остаётся внутри инфраструктуры компании, а преимущества анализа сохраняются.
Что проверить перед загрузкой кода в агент
- Политика компании разрешает этот сервис для кода такого уровня чувствительности?
- Обучение на диалогах отключено в настройках аккаунта?
- В промпт не попали ключи, токены, персональные данные и конфиги с секретами?
- Есть ли внутренний ассистент, который закрывает ту же задачу без выхода за контур?
- Понятно, кто проверяет результат и что считается инцидентом?
Чек-лист не даёт гарантий, он лишь отсекает очевидные нарушения. В компании с жесткими требованиями порядок такой: сначала уточнить у ответственного за безопасность, потом загружать код.
Что в итоге делегировать агенту, а что пока рано
| Сценарий | Что делает агент | Что остаётся человеку |
|---|---|---|
| Анализ кодовой базы | Навигация, ответы по коду, поиск связей | Чтение ключевых файлов, проверка выводов |
| Путь данных | Сбор цепочки через слои и репозитории | Сверка преобразований по файлам |
| Диагностика багов | Гипотезы с обоснованием | Воспроизведение, логи, минимальный тест |
| Хаос-инжиниринг | Сценарии сбоев и конфигурации | Запуск в изолированной среде, оценка риска |
| Тесты | Черновик и проверка на прочность | Запуск, приемка, трактовка результата |
| Диагностика ПК | Разбор логов и совпадений по времени | Решения об удалении драйверов и правках системы |
| Обучение и тексты | Объяснения, вопросы, правка стиля | Проверка фактов и смысла |
Лучше всего агент справляется со сбором контекста и навигацией: там ошибка дешева и видна сразу. Хуже с финальными архитектурными решениями и утверждением причины бага: правдоподобный ответ легко принять за доказанный. Как соотносятся скорость генерации и реальная работа, разбирается в материале про агентов в цикле разработки: там есть и про скрытую нагрузку на ревью.
Начать стоит с одного сценария, где есть своя кодовая база и понятный критерий проверки: разбор незнакомого сервиса или восстановление пути данных. Когда появится привычка требовать ссылки на файлы и проверять каждый вывод, подключайте хаос-инжиниринг и диагностику ПК. Правила безопасности при этом не меняются от удобства инструмента.