ИИ-агенты для кодинга проверяют на реальных задачах разработки
Grok считает, что агент полезет в базу напрямую, GPT спорит
Материал разбирает, насколько полезны ИИ-агенты для программирования на реальных задачах, а не на демонстрациях. По данным опроса JetBrains 2026 года, 90% профессиональных разработчиков использовали такие агенты хотя бы раз в неделю, а 68% — ежедневно. Автор описывает шесть проверок: понимание чужого репозитория, добавление функции, отладка, работа с тестами, интеграция API и вайб-кодинг. Отдельно подчёркивается роль контекста: агент может сам изучить структуру проекта и учесть его соглашения, чего не делает обычный чат-бот. Вывод — рутинную «сантехнику» можно делегировать, но контроль остаётся за разработчиком.
ИИ-инструменты для программирования прошли путь от автодополнения строки кода до агентов, которые работают с целым репозиторием: просматривают файлы, запускают команды, пишут тесты, ищут причины багов и подключают внешние API. Вместо того чтобы снабжать модель каждой деталью, разработчик всё чаще ставит цель, а агент сам разбирается с реализацией. Отсюда главный вопрос: насколько такие агенты полезны на настоящей работе, а не в эффектных демонстрациях вида «собери приложение по одному промпту». Масштаб изменений подтверждают цифры. В опросе JetBrains 2026 года, где ответили более 15 тысяч профессиональных разработчиков, 90% сказали, что использовали ИИ-агенты для кодинга на работе минимум раз в неделю в мае–июле 2026 года, а около 68% — ежедневно. То есть модели уже не просто советуют, а получают реальные задачи. Автор предлагает проверять агентов не игрушечной задачей вроде функции, переворачивающей строку, а шестью сценариями: понять незнакомый проект, добавить новую функцию, отладить проблему, использовать результаты тестов как обратную связь, подключить внешний API и собрать рабочий прототип по идее человеку с ограниченным опытом в коде. Первый и самый показательный тест — понимание существующей кодовой базы. Новый проект агенту даётся легко: там нет истории и легаси. Продакшен-приложение — это сотни файлов, несколько фреймворков, свои библиотеки, модели базы данных, логика аутентификации и бизнес-правила, нигде не задокументированные. Пример из текста: просьба «добавить страницу настроек аккаунта» выглядит фронтендом, но затрагивает аутентификацию, модели данных, API-маршруты, валидацию, компоненты интерфейса, почтовые сервисы и безопасность. Обычный чат-бот потребует вручную скормить ему этот контекст, а агент, работающий внутри репозитория, может сначала изучить проект. Именно контекст автор называет главным преимуществом. Модель способна выдать технически корректный код, который всё равно не подходит: например, прямой запрос к базе в проекте, где все операции должны идти через слой абстракции. Агент, умеющий читать существующий код, имеет шанс заметить такие соглашения до правок. Второй тест — построение настоящей функции. В небольшом SaaS-приложении для анализа загруженных документов нужно добавить дашборд с загрузкой файла, статусом обработки, просмотром извлечённых данных и скачиванием результата. Это тянет за собой обработку загрузок, проверку прав, изменения в базе, API-эндпоинты, фоновую обработку, отслеживание статуса, фронтенд-компоненты, состояния загрузки, обработку ошибок и автотесты. Выигрыш не в идеальности каждой строки, а в том, что разработчику не нужно вручную держать в голове каждый шаг. Отдельно отмечено, где ИИ особенно хорош: когда реализация повторяет уже существующие в проекте паттерны. Если в приложении есть три типа страниц настроек, агенту проще сделать четвёртую в том же стиле, чем изобретать новую архитектуру. Большая часть разработки — соединение готовых частей, и с этим ИИ справляется хорошо. Третий тест — отладка. Дашборд иногда возвращает пустой результат, хотя записи в базе есть, и непонятно, виноват ли запрос к базе, кеширование, пагинация, аутентификация, работа с датами, ответ API или состояние на фронтенде. На таких случаях и проверяется, умеет ли агент расследовать причину, а не угадывать решение.