ИИ-инструменты в разработке - Opinionated Guide

Недавно мы провели опрос по использованию ИИ-инструментов в техотделе. Оказалось, что большая часть людей использует чаты в браузере - ChatGPT, Deepseek и подобное. Специализированные AI-IDE и плагины не дотягивают по активному использованию даже до половины. Из основных причин:

• Отсутствие возможности оплатить иностранной картой - мы готовы компенсировать оплаты с личных карт, но корпоративной иностранной у нас, к сожалению, нет
• Плохо работает
• Нет особого смысла, потому что всё равно надо перепроверять написанное
• Не хочется доверять весь проект и превращать его в ИИ-слоп

Аргументы понятные, поэтому было решено сделать докладик на тему использования ИИ-инструментов в разработке - на основе собственного опыта и постов на Реддите и в Твиттере.

Содержание:

• Типы ИИ-инструментов - классификация разных инструметов с их плюсами и минусами (субъективными, конечно) + как ИИ-агенты ищут нужные куски кода
• Режимы и сценарии работы - как и для каких задач можно использовать ИИ?
• Практические советы - мои топ-5 советов для улучшения качества результата и уменьшения фрустрации
• Как сэкономить - несколько вариантов сетапов инструментов и моделей, чтоб не сливать по 200-300 долларов в месяц
• Заключение и личный опыт - завершающие мысли и рассуждения по теме

Типы ИИ-инструментов

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

Веб-чат

Примеры - ChatGPT, Deepseek, Qwen Chat, Le Chat.

Мой опыт - на заре развития так и пользовался, сейчас точечно тоже.

Плюсы:

• Недорого или вообще бесплатно
• Удобно для точечных вопросов - открыл вкладку, закинул вопрос с контекстом, получил ответ
• Заставляет думать при создании контекста/промпта - нужно вручную собирать нужный контекст, поэтому итоговый запрос получается более точечным и вдумчивым

Минусы:

• Надо руками собирать контекст - это может быть долго или очень сложно при работе в большой кодовой базе
• Мало возможностей для кастомизации под свой процесс работы
• Не может применять инструменты и редактировать код - сгенерированный код надо вручную вставлять в файлы, самому надо запускать команды и скидывать логи в чат

AI-native IDE

Примеры - Cursor, Windsurf, Zed, Kiro, Void.

Мой опыт - около года активно на Курсоре, несколько дней потестил Kiro.

Плюсы:

• Всё изначально заточено под ИИ - не надо ничего дополнительно ставить
• В подписку входит определённое количество запросов к LLM
• Полный фарш - авто-комплит, инструменты, разные роли агентов

Минусы:

• Надо платить бабки за подписку, и чаще всего ещё сверх неё за активное использование
• Имеют склонность к самодеятельности - создают кучу маркдаунов, переходят к кодингу и запускают команды без спроса. Зависит и от модели, конечно, но Cursor точно таким грешит со всеми моделями
• Используют техники сжатия контекста для максимизации своей прибыли - например, не полностью читают нужные файлы и из-за этого тупят

AI-плагины

Примеры - Cline, Roo Code, Augment Code, Kilo Code, Codex.

Мой опыт - пара месяцев с Cline, около недели с Roo Code, установил Augment Code. Кстати, Roo и Kilo - это форки Cline, причём Kilo постоянно мёрджит себе все изменения Roo...

Плюсы:

• Часто быстрее и лучше решают задачи, в том числе потому что не жалеют токенов - большинство инструментов из этой категории относятся к BYOK (bring your own key)
• Не надо покидать любимый IDE (VSCode, PyCharm, даже NeoVim)
• Большинство инструментов опенсорсные, чаще всего не нужна подписка, коммьюнити развивает всякие дополнительные фишки

Минусы:

• Часто жрут тонну токенов - то есть, кучу денег. Однажды я в Roo Code сжёг 25 долларов за 2 минуты работы
• Часто требуют более тонкой настройки, чтоб заработали хорошо

Автокомплит

Примеры - Tabnine, Supermaven, Continue.dev, Copilot (на самом деле они все могут больше, но часто эти инструменты используют именно для комплита).

Мой опыт - Tabnine раньше использовал в VS Code, сейчас использую встроенный в Cursor комплит.

Плюсы:

• Обычно хорошо решают точечную задачу - автокомплит кода
• Для такой задачи может хватить и локальной бесплатной модели

Минусы:

• Ограниченное использование

CLI

Примеры - Claude Code, Codex CLI, Aider. На самом деле не совсем корректно включать их в одну категорию, так как CC и Codex сами собирают свой контекст и, скорее, похожи на Cline/Roo Code, но в терминале. А философия Aider - пользователь должен сам аккуратно собирать нужный контекст из нескольких релевантных файлов.

Мой опыт - немного с Codex CLI и Aider.

Плюсы:

• Часто хорошо решают кодинговые задачи
• Круто для любителей терминала

Минусы:

• Кому-то может быть неудобно работать из терминала, писать слэш-команды
• В Aider надо руками собирать контекст - и плюс, и минус
• CC, Codex - нужно платить бабки за подписку (но Codex входит в обычную подписку ChatGPT)

Прочее

Есть множество инструментов, которые не попадают в одну из предыдущих категорий, например:

• OpenHands - опен-сорсная версия Devin, автономный ИИ-агент, который может делать те же операции, что и обычный разработчик, включая открытие браузера
• OpenManus - опен-сорсная версия Manus (рисёч-агент)
• Lovable, Replit - zero-code платформы для создания приложений с UI. Как я понимаю, их ЦА - нетехнари, которые хотят реализовать свою идею, не написав ни строчки кода.

• Warp - терминал с LLM

Как разные виды ИИ-агентов ищут нужное по кодовой базе?

Чтобы понять, какие файлы прочитать и изменить для решения задачи, есть несколько ключевых подходов

• Индексирование - RAG для кода. Прогоняем код через специальный парсер, делим на разумные куски, эмбеддим эти куски. На инференсе ищем релевантные запросу части кода. Тут можно почитать, как собрать свой индекс.
• Агентский поиск на лету - используем инструменты типа grep для поиска нужных файлов и строчек в файлах
• Ручная сборка контекста - пользователь сам добавляет нужные файлы в контекст, и они попадают туда целиком, так что ничего искать не надо

Как обычно, у каждого варианта есть свои плюсы и минусы. Например, индексирование значительно повышает скорость поиска и снижает количество обращений к LLM для генерации команд поиска, но начинает бредить, если кодовая база изменилась (а меняется она постоянно, а реиндексация ещё не случилась). В Claude Code нет встроенного механизма индексирования, но это сильно повышает количество генерируемых в ходе решения задачи токенов.

Cursor для решения этих проблем использует гибридный подход, а Augment агрессивно реиндексирует репозиторий.

Режимы и сценарии работы

Есть разные режимы работы с ИИ-инструментами по мере возрастания автономности:

• Tab - автокомплит, но может добить не просто имя переменной, а целую функцию
• Tab-Tab-Tab - когда нужно внести похожее изменение во многих местах файла или даже проекта
• CMD + K - выделяем конкретный кусок кода и просим что-то изменить или задаём вопросы
• Controlled Agent - позволяем агенту самому собирать контекст, запускать команды, создавать и изменять файлы, но контролируем все или часть используемых инструментов
• YOLO Agent - описываем задачу и уходим обедать

Оптимальное распределение между этими режимами будет зависеть от ваших предпочтений и роли в компании. Я код на каждодневной основе не пишу, поэтому мои сценарии - это последние два, например, если я хочу протестить идею создания какого-нибудь нового внутреннего инструмента.

Собственно, вот популярные сценарии использования:

• Создать новый проект с нуля - подходит как для throwaway-проектов-однодневок, так и для того, чтобы в 10 раз быстрее засетапить основу репозитория для нового проекта. Просто подход к работе и желательный уровень контроля в этих случаях будет разный.
• Добавить фичу в существующий проект - классика жанра, например, хотим протестировать новую гипотезу и поставить эксперимент или запилить какую-то user story.
• Проанализировать и решить конкретный баг - LLM часто очень неплохо разбирается даже в достаточно обскурных багах (но не всегда).
• Онбординг в репозиторий - можно попросить как в целом описать проект, так и задавать вопросы по конкретным его частям.
• Генерация тестов и документации - может сгенерировать много лишнего, но убирать явно быстрее, чем писать с нуля.
• Ревью изменений - как человеческих, так и собственных. Можно даже интегрировать в CI-пайплайн. Есть специальные инструменты типа CodeRabbit.

Практические советы

В этой секции хочу поделиться несколькими советами по эффективному использованию ИИ-инструментов, подтверждёнными как моим опытом, так и постами в интернете.

Совет #1

Часто нам очень лень детально описывать задачу даже своим коллегам, что уж там говорить про ИИ. К сожалению, такие промпты вряд ли приведут нас к желаемому результату:

• “Создай LLM-алерт-менеджер, который будет умным способом группировать алерты из Графаны в инциденты”
• “Добавь в проект фичу по автоматическому анализу сообщений пользователей и изменению уровня критичности инцидента по результатам анализа”

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

Первый самый важный этап - создание документа с описанием задачи - типа дизайн-документа или Product Requirements Document (PRD). Я рекомендую такой пайплайн:

• Описываем задачу или проект по шаблону.
• В шаблон можно включать - цель (чего хотим достичь с точки зрения UX), Definitions-of-Done (можно в формате примеров инпут - желаемый аутпут или списка тестов), ограничения скоупа (что НЕ НАДО делать - очень важно), желаемый стек и подходы, релевантные материалы (всякие PDF, схемы, картинки).
• Просим LLM (в отдельном свежем чате в IDE, в браузере в ChatGPT или в специальном режиме Architect, который есть во многих плагинах) сделать ревью каждого пункта и задать уточняющие вопросы. Обязательно уточняем, что пока НЕ ПИШЕМ код.
• Итоговый план пакуем в Markdown, делаем финальные правки и подаём как контекст в новый чат.
• При работе над большими фичами также полезно попросить модель (а) изучить весь репозиторий и создать REPO_STRUCTURE.md и (б) разбить задачу на список подзадач.

Есть даже специальные инструменты, заточенные именно под этот этап - например, Traycer, который часто хвалят на Реддите.

Кстати, несколько раз встречал такой совет - печатать промпты не руками, а голосом - мол, так мы обычно даём больше информации. Не пробовал - в офисе неудобно, да и как-то менее структурированно получится, как мне кажется.

Совет #2

Столько существует инструментов - хочется попробовать разные, а настраивать каждый под себя лень. Но без дополнительной настройки мы вряд ли получим желаемый результат и, скорее, выбесимся и пойдём пробовать что-то новое.

Что же полезно настроить на основе моего опыта?

Общий или проектный файл с правилами (.cursorrules, AGENTS.md, CLAUDE.md), который будет привязываться к каждому новому чату. Это не панацея, модели всё равно будут тупить и не слушаться, особенно при распухании чата, но польза точно есть. Туда можно включить:

• Общие гайдлайны по написанию кода - стиль, желаемая длина файлов
• Инструкции по запуску разных команд - как запускать энвы, где брать секреты для обращения к разным API
• Что нельзя делать, с упором на то, что особенно бесит лично вас - "не добавляй комментарии к коду, если они не добавляют ценности к его пониманию", "не создавай новые файлы без явного разрешения", "не переходи от стадии планирования и вопросов к написанию кода без явного разрешения", "не изменяй сами тесты, чтоб они проходили, без явного разрешения", "НИ В КОЕМ СЛУЧАЕ не хардкодь никакие эдж-кейсы в коде, даже если никак не получается добиться корректной работы"

Memories / Memory Bank. При старте каждого нового чата модель полностью теряет контекст о вашем проекте и принятых решениях. Можно пытаться документировать важное вручную, но это довольно муторно. Поэтому в ИИ-инструментах почти всегда есть какой-нибудь механизм памяти - разберитесь, как он работает. К примеру, я в какой-то момент обнаружил, что у меня отключены Memories в Cursor из-за какого-то Privacy-режима.

В Roo Code есть популярное стороннее решение для "банка памяти", которое фактически состоит из четырёх постоянно обновляемых файлов:

• activeContext.md - информация о текущей таске
• productContext.md - высокоуровневая информация о проекте  
• progress.md - завершенные и предстоящие задачи
• decisionLog.md - лог принятых решений и их обоснования

Похожее решение реализовано и в Kiro.

MCP. Не утихают споры о полезности MCP - многие считают, что они только забивают контекст и ничем не отличаются от API. Зерно правды в этом есть, но практически я заметил, что польза есть - мне проще настроить разные MCP с нужными доступами, а затем в чате упоминать, когда я считаю вызов того или иного инструмента оправданным. В ином случае нужно отдельно описывать модели, как подключаться к каждому API, где лежат токены, какие эндпойнты там есть... Кроме того, для внутренних инструментов можно писать свои MCP. Я часто использую такие:

• Postgres - read-only для чтения данных из БД со статистикой обработки
• Kubernetes - для чтения логов задеплоенных приложений
• Grafana - для чтения списка алертов
• Context7 - предоставляет актуальные спецификации библиотек
• Puppeteer - для открытия и чтения содержимого сайтов, может даже делать скриншоты

Важно! Обязательно сразу отключите в них лишние инструменты - для безопасности (чтоб LLM не дропнула вам весь кластер в Кубике) и для экономии места в контекстном окне.

В целом рекомендую почитать документацию к своим любимым инструментам, покопаться в настройках, почитать Reddit. Если прям любопытно можно попробовать прикрутить всякие надстройки, которые эмулируют сложный много-агентский процесс разработки (например, RooRoo, RooFlow, SPARC для Roo Code), но, судя по всему, практического толка от них пока не так много.

Совет #3

Конечно, удобно взять один инструмент и какую-нибудь мощную модель и решать все свои задачи только так. Увы, минусы у такого подхода есть:

• Разные инструменты по-разному себя показывают в разных задачах
• Использование мощной модели очень быстро сжигает входящие в подписку токены или кредиты с вашего OpenRouter-аккаунта

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

К примеру, планирование архитектуры решения часто считается наиболее сложным этапом, где лучше не экономить и использовать что-то типа GPT-5 High Reasoning, Claude Opus 4.1 / Sonnet 4, Gemini 2.5 Pro.

Если используете режим оркестрации, то можно взять одну из этих моделей, но часто хорошо себя показывают и большие опенсорсные модели типа Deepseek.

Наконец, на этапе написания кода и тестов многие переключаются на более дешёвые модели - GLM-4.5, Kimi K2, Qwen 3 Coder, Devstral, Gemini 2.5 Flash, Grok Code Fast.

Кроме моделей можно переключаться и между инструментами - к примеру, задизайнить и имплементировать задачу в BYOK-плагине, а тесты добить в Cursor, где в подписку входит определённое количество запросов.

Модели можно переключать и прям в рамках одного чата, но у меня это не так часто приводит к хорошим результатам - лучше стартануть новый чат.

Совет #4

Раз уж мы используем ИИ-инструменты, хочется, чтоб они делали всю работу за нас. К сожалению, пока технологии явно не на том уровне. Поэтому критически важно адаптировать лучшие командные практики разработки и адаптировать их к ИИ:

• Делай ревью написанного ИИ-кода, спрашивай, что делает этот код, если непонятно. При работе с ИИ тупых вопросов не бывает - они так и норовят тебя обмануть.
• На мой взгляд, лучше не делать две фичи параллельно, особенно если они касаются одной части репозитория. В целом ничего не мешает так делать, в каком-нибудь Codex вообще можно запустить 10 агентов, которые будут готовить пулл-реквесты по разным запросам. Но при локальной разработке меня это часто путает, переключаться между контекстами тяжело.
• Намного эффективнее указать модели на правильные файлы, если они известны - потратим меньше токенов и меньше замусорим контекстное окно.
• В конце работы над фичёй попроси модель посмотреть на текущий git diff и прибрать лишний код, убрать бесполезные комментарии и отметить потенциальные проблемы.
• Важно поддерживать хорошую структуру репозитория и умеренную длину файлов - так агенту будет намного проще собирать нужный точечный контекст.
• Важно уделить внимание тестам - как минимум нужно несколько хороших end-to-end тестов, которые будут проверять всю функциональность. С TDD у меня какие-то не очень прикольные результаты получаются, но, может, я просто чего-то не понимаю.

Если это не пет-проект, который не надо будет особо поддерживать, то обязательно следим и бдим:

• Как можно быстрее стопай агента, если он начал творить фигню и откатывайся на предыдущий чекпойнт.
• Помогай, если модель явно запуталась и ходит по кругу. Иногда проще самому разобраться в причине бага и потом указать модели на конкретную причину. Или даже просто вставить в нужное место кусок кода.
• Явно проси добавить дебаг-принты, если разрешение бага затягивается.
• Если всё-таки запускаем агента в YOLO - потом внимательно всё читаем, задаём вопросы, просим объяснить принятые решения.

Совет #5

Наверное, лучше писать всё, что касается одного проекта или фичи, в один чат - чтоб не терялся контекст, так? Нет, не так.

Агенты начинают жесточайше деградировать при распухании контекста. Если началась "компрессия контекста" (когда моделька саммеризирует содержание чата), то я в 90% начинаю новый чат.

В любом случае создаём новый чат под каждую новую задачу, а иногда даже подзадачу.

Чтоб не терять контекст обязательно:

• Подаём на вход наш дизайн-док и общий ридми по репозиторию.
• Полезная штука - попросить модель саммеризировать текущее состояние работы над задачей, а затем подать это саммери на вход в новый чат.

Как сэкономить?

Какие есть варианты не разориться?

• У Windsurf есть бесплатный уровень, его часто используют для автокомплита
• Можно достаточно бюджетно пользоваться Roo Code или Cline - на Reddit полно советов в постах и главное в комментариях (раз, два)
• Aider очень экономно расходует токены по сравнению с другими инструментами
• Codex CLI и плагин для IDE входит в подписку ChatGPT (но мне пришлось засетапить, чтоб запросы шли через Shadowsocks)

В BYOK-инструментах огромное значение имеет выбор моделей, разброс гигантский, вот текущие цены за миллион входных и выходных токенов на OpenRouter:

Кроме того, есть всякие дополнительные лайфхаки для экономии:

• Бесплатные модели на OpenRouter (да, есть лимиты, могут отвечать медленно, но как один из вариантов) - например, сейчас есть DeepSeek V3 0324, Qwen3 Coder 480B A35B, GLM 4.5 Air, Kimi K2 0711
• Новые модели в cloak-режиме часто дают бесплатно попробовать как на OpenRouter, так и в Cursor - буквально сегодня появился новый Grok 4 Fast (называется Code-Supernova)
• Гугл даёт бесплатные кредиты на каждый акк в GCP

Локальные модели не порекомендую - на мой и не только взгляд, они годятся только для простейших задач.

Заключение и личный опыт

Мне нравится такая банальная метафора - работа с ИИ-агентами похожа на управление командой талантливых, но странных разработчиков.

• Нужно правильно поставить задачу и дать весь нужный контекст
• Обязательно следим за прогрессом и вмешиваемся при пробуксовке или явно ошибочном направлении
• Сами всегда оцениваем план и принимаем окончательное решение, ведь ответственность за результат лежит на нас
• Чёткие инструкции, контроль промежуточных результатов, код-ревью, тесты - маст-хэв
• Запрещаем использовать стек или архитектурные решения, которые сами не понимаем

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

Я долго пользовался Cline и Continue.dev в VS Code, потом пересел на Cursor, а недавно решил попробовать Roo Code и Kiro. И не всегда первое впечатление соответствует итоговому. К примеру, в Kiro сначала мне очень понравилось, как организован процесс, очень резонирует с тем, как у меня был устроен процесс в Курсоре:

• Если проект не новый, то сначала создаются три документа, которые всегда подаются в контекст - верхнеуровневое описание проекта, список технологий и структура репозитория
• Начинаем в режиме Spec - создаём спецификацию, обсуждаем детали и уточняющие вопросы
• Затем переходим в режим Design, где создаётся tasks.md со списком задач и подзадач (что-то типа todo-листа в Курсоре, но круче)
• И потом только начинается имплементация

Сначала всё было прям круто, но где-то на 5 задаче из 10 случился какой-то ужас, модели начали просто сходить с ума, и у меня так и не получилось никакими способами вернуть решение задачи на правильный путь, так что я просто вернулся в Курсор и добил её в полуручном режиме. В общем, перед тем как делать выводы, обязательно надо решить с помощью инструмента хотя бы пару задач разного масштаба.

Если говорить об эффекте для меня лично - ИИ-инструменты открыли возможность в свободное от основной работы время попробовать с нуля реализовать с нуля реализовать несколько идей, которые давно хотелось попробовать. Ускорение тут исчисляется десятками раз. Если проект потом кем-то будет использоваться или поддерживаться - важно не потерять момент, в который нужно перехватить контроль, но для быстрого прототипирования - это незаменимая штука.

Ещё один аспект, который я почти не затронул - командная разработка и ИИ-инструменты. К примеру, тут чел с Реддита поднял интересный вопрос - а что делать со всеми этими маркдаун-файлами, добавлять в git? Как решать конфликты? Или жить пока в традиционной парадигме, и пусть каждый член команды живёт со своими документами? В комментах предложили любопытный подход - добавить в CI-пайплайн LLM, которая будет объединять memory-банки разных членов команды. Но у меня такого опыта нет, и в version control мы никакие ИИ-документы не коммитим.