IDE годится не только для программирования
(написано для тг-канала Нейрокухня Доловара)
Если вы ведете заметки в блокноте, составляете документы или ведете блог, и при этом у вас возникают мысли вроде "надо бы проверить на опечатки", "не забыл ли я вписать что-то важное" или "чепуха получается, надо что-то переделать, понять бы что именно", то эта статья может быть вам полезна.
TL;DR: Специалистам вряд ли будет интересно, текст для начинающих. Речь пойдет о том, как использовать IDE для управления базой своих текстов. О различиях между конфигами, скиллами и воркфлоу. О названиях файлов и простейших способах экономии токенов. Подобного добра в интернете уже много, но я не со всем согласен, поэтому напишу своё.
У меня есть папка со скромным названием `texts`, в которой лежат, вы не поверите, текстовые файлы. По подпапкам разложены архивы постов в ЖЖ и Телегу, статьи на каких-то площадках, черновики книг, мелкие заметки, документация по разным проектам, заготовки промптов и что-то там еще.
Формат текстовых файлов - Markdown. Это то же самое, что текст, только расширение не `.txt`, а `.md`. Данный формат понимается практически всеми редакторами и позволяет сохранять форматирование, вроде заголовков или выделения курсивом. Немного удобнее, чем просто текст.
Папка регулярно синхронизируется с облачным хранилищем, изменения отправляются в приватный (не в публичный, это важно) репозиторий на GitHub. Это создает бакап (люблю бакапы), а также позволяет подтягивать папку на другие компьютеры или на мобилку. Подредактировал в одном месте - изменения разбегутся по всем моим рабочим местам. Удобно. Плюс могу откатывать изменения, если случайно удалю важный файл или захочу отменить вчерашние изменения. А если я потеряю доступ к блокноту, компьютеру или сервису, то не потеряю свои наработки (не люблю Notion и другие программы с проприетарными хранилищами, которые нарушают мой суверенитет над моими данными).
Но что еще удобнее, так это возможность работать с этой папкой как с проектом в IDE. Integrated Development Environment - это как бы среда разработки, такая специальная большая программа, которая изначально обрастала специальными фичами для работы с кодом какого-нибудь программного продукта. Там есть подсветка кода, предупреждения об ошибках, удобство навигации по множеству взаимосвязанных файлов, автоматизация тестов и деплоймента, а также другие специализированные фишки для программистов. Но, по сути, это просто очень продвинутый текстовый редактор. Который хорошо подходит для работы с базой текстов.
Современные IDE очень сильно продвинулись в работе с ИИ-агентами. Программисты и просто продвинутые пользователи могут в чате с ИИ попросить что-нибудь найти, создать или исправить, и хитро настроенные команды ИИ-агентов (оркестры) бросаются выполнять поставленные задачи, пока пользователь попивает чай, раздумывая о следующем этапе работы. Или проверяет результат работы агентов (на это сейчас уходит основная часть работы - не доверяй, проверяй).
Уже есть много AI IDE, и постоянно появляются новые: VS Code, VS Codium, Cursor, Windsurf, Antigravity, Zed, Trae, PearAI и так далее. Для разных платформ, платные и бесплатные, оконные и консольные. Глаза разбегаются, благо можно обсудить выбор с ИИ, описав ему свои задачи и возможности.
Вернемся к базе текстов. Открываем папку в IDE и начинаем работу - правим черновики, добавляем новые, удаляем старые. Как в обычном блокноте. Например, я пишу новый пост в телегу и... И постоянно вижу работу механизма автодополнения, который предлагает мне продолжение фразы или исправление опечатки в набранном тексте. Могу просто нажать кнопку "Tab", чтобы принять предложение, вместо того, чтобы бежать курсором к месту, в котором нужно исправить опечатку. Или нажать "Esc", чтобы ИИ отстал, убрал свое неуместное предложение. Или просто продолжить писать своё, не обращая внимания на старательного помощника. Автодополнение сейчас вполне умное, но это лишь начало удобств.
При переходе от работы с отдельными документами в Word или Docs к работе с базой текстов быстро появляется ощущение масштаба - дорогого стоит возможность видеть дерево файлов в архиве и делать смысловой поиск по всей базе. Особенно когда текстов становится много.
Набираю новый текст и включаю справа панель для беседы с ИИ-агентом. Привычное окошко чата, в котором я могу попросить ИИ, например, проверить свеженабранный текст на ошибки фактические, смысловые, грамматические, стилистические и любые другие. Теоретически, можно даже попросить ИИ переписать или дописать текст, но не делайте этого (плохая дорога на свалку нейрослопа). Зато можно пообщаться с ИИ, если мысль зашла в тупик - вот тут я что-то хочу выразить, но не могу понять что именно, давай прикинем возможные продолжения.
Разумеется, всё это можно делать просто в веб-браузере на сайте какого-нибудь ИИ, но в IDE этот ИИ будет иметь доступ ко всем вашим файлам, будет лучше понимать ваши интересы и стиль. Зачем постоянно копипастить куски текстов в домик ИИ, если можно пригласить ИИ в гости к текстам?
Впрочем, есть одна причина не звать ИИ в гости - когда вас смущает то, что ваши сокровенные тексты улетят в чужое облако, где разработчики ИИ могут подглядывать. В моем случае все тексты так или иначе превращаются в публикации, поэтому я не против использования GitHub и облачных ИИ. Но, разумеется, не стоит хранить пароли, API-ключи от нейросетей и прочую чувствительную информацию в папке проекта, с которым будут работать ИИ-агенты, и которая будет сохраняться в облаке (пусть даже приватном).
Если у вас есть папка с текстами, и вы ежедневно с ними работаете, то есть смысл попробовать IDE. Например, Antigravity от Google сейчас предоставляет неплохие бесплатные лимиты, вполне можно поставить и пощупать (это не оплаченная реклама, но благодарность за то, что меня всё ещё не забанили за мои эксперименты). Если не понравится, то можно поставить на пробу другую IDE, благо папка с текстами не страдает от смены программы редактирования.
Если понравится, то вы быстро заметите, что ИИ не всегда понимает ваши замыслы, его приходится часто поправлять и направлять. Возникает желание настроить среду под себя. И здесь мы переходим к главной теме: а как вообще можно настраивать ИИ-среду? Об этом и пойдет речь.
При настройке умной IDE под себя важно помнить главное - вы никому ничего не должны. Если в каком-нибудь обучающем видео или статье говорят "обязательно сделайте", то они не правы, слишком увлеклись. Все настройки должны делаться только по одному принципу - я встретил неудобство и хочу его исправить.
Например, мне надоело постоянно объяснять IDE, что вот в такой-то папке у меня лежат заготовки текстов для такой-то площадки, где свои целевая аудитория, формат и прочие особенности. Я хочу это прописать раз и навсегда, чтобы IDE всегда понимала автоматически при любых работах с данной папкой. Такую настройку называем словом "**конфиг**" (системный промпт, пользовательские настройки, политики проекта, правила поведения агентов).
Или я заметил, что часто прошу выступать ИИ в определенных ролях. Если я прошу его побыть скептиком, то ему следует выискивать одно, а если прошу его побыть мотиватором, то ему следует сосредоточиться на другом. В каждой роли есть свои особенности, которые явно не стоит класть в системный промпт, настолько они разные. Это называем словом "**роли**" (специальности, скиллы, навыки).
Еще пример, у меня в работе есть последовательность действий, которую я выполняю регулярно - свеженаписанный текст нужно проверить сначала на соответствие фактам, логичность выводов, затем на читабельность, а в конце на чистописание. Это называем словом "**сценарий**" (алгоритм, скрипт, воркфлоу).
Всё это добро можно положить в один большой промпт, который сохранить как текстовый файл в корневой папке проекта. IDE будет автоматически подгружать его содержимое и учитывать в своей работе. Но если инструкций стало слишком много, если они стали противоречивыми, то появляется смысл разделить их, хранить в разных местах.
На разделении "хранить в разных местах" спотыкаются многие - становится сложно, в правилах можно утонуть, не хочется тратить силы еще и на прописывание конфигов. Напоминаю главный принцип - настройки делаются не из-за "сказали что так надо", а для "вижу возможность добавить удобство". Каждая строчка настроек должна добавляться осознанно. Если настройка уменьшает утомление, то настройки не будут утомительны, даже когда они разрастаются.
Подсматривать в чужие примеры можно, их много есть в интернете, но не для бездумного копирования всего подряд, а для поиска возможностей - ух ты, оказывается еще и это можно автоматизировать, это мне поможет, беру.
Начнем с самого простого - конфиг в корневой папке. Это просто текстовый файл, в котором мы пишем промпт: в данной папке лежит то-то, обращайся с этим так-то, делай хорошее и не делай плохого.
Есть много разнородных рекомендаций о названии такого файла:
- `.cursorrules`, `clinerules`, `.windsurfrules`, `.github/proposals`, `.vscode/*` - лично мне подобные варианты не нравятся из-за привязки к конкретным IDE или инструментам.
- `GEMINI.md` - с таким названием файла Antigravity не будет тратить лишний запрос на чтение, IDE автоматически подтянет файл. А вы будете постоянно видеть рекламу гуглового ИИ в списке своих файлов (хитро придумали).
- `AGENTS.md` - более распространенный вариант, который понимают разные IDE, но лично мне не нравится из-за того, что капслок "мозолит" глаза. Предпочитаю, чтобы взгляд цеплялся за мои файлы, а не за вспомогательные.
- `.ai-rules.md` - мне нравится такой универсальный вариант, но не настаиваю.
- Или любой другой вариант названия, который будет очевидно понятен как человеку, так и ИИ-агентам в любой IDE.
Начать писать такой файл можно одной строчкой текста: "в этой папке лежат мои тексты, не вздумай их переписывать, здесь автором является человек". Ну или что там для вас является главным. Следует добавлять новые правила тогда, когда вы замечаете, что надо бы что-то автоматизировать, зафиксировать или исправить, чтобы не писать это всякий раз в промпте вручную.
Неспешно продумываем и прорабатываем этот файл. Специалисты делают это месяцами. Например, добавляем в конфиг карту проекта - структуру подпапок с описанием желательного поведения в них. Теперь ИИ будет тратить меньше ресурсов на попытки понять, где что искать, и что с этим делать.
Если не понятно, что вообще следует прописывать в конфиге, то можно обсудить это в чате с ИИ - у меня есть вот такая-то задумка, посоветуй возможности. Но я бы советовал добавлять правила только по мере необходимости, а не по принципу "ну люди же делают, авось и мне пригодится".
Если хочется, чтобы ИИ-агенты лучше ориентировались в вашем проекте, но спецификации и прочая документация занимают слишком много места, можно не тянуть их в одну кучу, а ссылаться из файла конфига - если нужна структура, то найдешь в таком-то файле, а если нужны особенности бренда, то смотри вон в той папке. Так, как вы бы объясняли человеку. В таком случае ИИ-агенты не будут загружать в контекст всё подряд на каждый запрос, а будут подтягивать только ту информацию, которая покажется им релевантной для текущей задачи.
Если корневой конфиг разросся слишком сильно, его можно разделить - правила для подпапок перенести в точно такие же файлы конфигов, которые будут лежать в этих подпапках. При этом в корневом конфиге упоминаем "если в папке есть локальные правила, то они имеют больший приоритет", чтобы уменьшить вероятность конфликта инструкций.
Конфиг - это промпт. Часть всего того, что улетит в ИИ для создания контекста, опираясь на который ИИ будет выстраивать свои ответы и действия. А значит, в файле с конфигом можно и следует использовать все правила промптинга, которые вам покажутся уместными - заголовки, списки, выделение болдом ключевых слов и т.д.
Обычно промпты начинают с указания роли: дорогой ИИ, сейчас представь себя таким-то специалистом и следующие инструкции воспринимай с этой точки зрения, поступай профессионально. Проблема в том, что при работе над проектом разные ИИ-агенты должны исполнять разные роли. Прописывать всевозможные роли в файле конфига - это способ создать противоречия и раздуть системные инструкции избытком того, что нужно только при решении некоторых задач.
Можно создать файлы с конфигами для разных ролей, и в основном конфиге прописать что-то вроде "если тебя просят сделать то-то, то смотри дополнительные инструкции там-то". Но в ИИ-индустрии это уже стандартизировали, назвав словом "Skills" (навыки), поэтому имеет смысл ознакомиться со стандартным подходом.
Если вы только знакомитесь с AI IDE, то рекомендую прямо в этой IDE в окне чата с ИИ-агентом поставить ему задачу: я планирую тут использовать таких-то агентов, продумай и создай для них скиллы. Если вы используете достаточно современную и умную AI IDE, то вам выпадет шанс на практике увидеть, как агент создаст папку `.agent/skills`, в которой разложит настройки под каждую роль из списка заказанных. Это и есть стандартный подход к организации ролей - текстовые файлы, разложенные по папкам в специальной директории, где хранятся дополнительные инструкции для ИИ-агентов.
Скиллы от прочих промптов и конфигов отличаются разве что заголовком с "name" и "description". Особенно важно "описание" - оно должно быть кратким, и оно должно позволять ИИ-агентам понимать, в каких задачах следует подтянуть инструкции именно из данной роли.
Кроме "name" и "description" в скиллах можно прописывать и другие ключевые слова, но это уже информация не для начинающих. Желающие могут самостоятельно найти и проверить возможные опции (лично мне нравится disable-model-invocation).
Для работ над базой личных текстов могут пригодиться такие роли: корректор (знаток орфографии и пунктуации), бета-ридер (оценка читабельности и интересности), скептик (спарринг-партнер для проверки идей на прочность), фактолог (борьба с галлюцинациями). Добавляйте роли по мере надобности: индексирующий архивариус, генератор расширений, валидатор списков, сюжетный выравниватель, культурный локализатор, SEO-оптимизатор, хранитель секретов, мастер иллюстраций, искатель трендов, создатель брендбуков... Но не пытайтесь прописать заранее всё, что придумается, добавляйте новое только по мере необходимости.
После создания скиллов можно пробежаться по конфигам в разных папках, добавить советы по привлечению специалистов. Старые тексты - не нужно сюда звать корректора, это уже не будет обновляться. Документация - тут нечего делать бета-ридеру, зато здесь есть работа для библиотекаря. Новая статья - подключай всех подряд.
В интернете есть целые сайты с коллекциями Skills - проработанных, богатых деталями. Можно подсмотреть и забрать себе что-нибудь, если лениво продумывать самостоятельно. Но я бы рекомендовал всё скачанное дорабатывать напильником под себя, чтобы не раздувать промпты тем, что лично вам не нужно. Принцип "выкидывать лишнее" особенно пригодится, если вы решите перейти на платные подписки, где всякий токен имеет свою цену.
И да, существуют скиллы типа "Мастер скиллов" - проработанные промпты, которые учат ИИ-агентов создавать новые или улучшать старые скиллы.
В современных AI IDE есть два режима работы агентов - по-быстрому и с планированием. Во втором случае запускается могучий сценарий совместной работы нескольких ИИ-агентов: сначала вникаем в задачу, задаем дополнительные вопросы человеку, после чего составляем план действий с чек-листом, затем выполняем последовательность намеченных этапов, после чего составляем отчет о проделанной работе. Для сложных задач вроде "создай новый проект" рекомендуется запуск именно планирования. Для более простых задач лучше выбирать режим попроще, чтобы не расходовать лимиты запросов и токенов впустую.
Но и режим "попроще" можно сделать более умным, создавая сценарии для типовых работ. В своей личной работе следует отмечать регулярные последовательности действий - я обычно делаю сначала одно, потом второе, а заканчиваю третьим. Если нужно, чтобы ИИ-агент следовал такому же алгоритму, то следует прописать его где-то, создать соответствующий промпт. Например, в папке `.agent/workflows/` можно вручную создать файл с промптом, в котором расписаны шаги по какому-то сценарию. Или можно ИИ-агента попросить создать, додумать и расписать сценарий, чтобы затем полюбоваться на то, как сценарии вообще должны оформляться (там тоже важен "description" в начале).
В разных IDE могут быть приняты разные названия и формат файлов со сценариями для ИИ-агентов. Если вы планируете попробовать работу с разными IDE, то рекомендуется использовать такие названия папок и файлов, которые будут более-менее универсальны, понятны и человеку, и ИИ. Для верности можно добавить упоминание названия папки со сценариями в корневом конфиге, и тогда умный ИИ-оркестр не пройдет мимо, подхватит и применит при получении соответствующей задачи.
И можно не надеяться на автоматическое распознавание, а при постановке задачи вручную указывать требуемый Скилл или Воркфлоу - используй их сейчас. Зачастую в IDE в поле ввода задачи даже есть кнопки для выбора из имеющихся. Например, в Antigravity можно перетащить файл роли или сценария прямо в беседу с агентом. Или при наборе промпта ввести "/", чтобы получить выпадающий список с доступными ролями и сценариями. Или в конфиге конкретной подпапки прописать "при задаче 'проверить' иди по такому-то сценарию".
Повторим список возможностей по настройке агентов в IDE:
- **Конфиги** - это правила, рекомендации и запреты.
- **Скиллы** - это специализации, уточнение ролей, добавление профессионализма.
- **Воркфлоу** - это сценарии, то есть оптимальные последовательности команд.
Границы между ними размыты. Например, часто конфиги задают ролевое поведение, скиллы содержат воркфлоу, а в сценариях прописаны конфигурационные правила. Не удивляйтесь, когда встретите примеры, где все файлы содержат всё подряд. Главное - чтобы человек, который этим пользуется, понимал и помнил, где у него что лежит.
Можно встретить очень разные архитектуры проектов. Например, в папке `Agents` будут лежать скиллы со сценариями, в папке `Scripts` будут лежать вспомогательные инструменты, а в папку `Executions` будут складываться отчеты о проделанной работе. И в корне проекта будет лежать одинокий `README.md`, в котором для человека и ИИ-агентов будет рассказано, где что лежит, и как этим пользоваться.
И всё это - промпты. А значит не помешает вспомнить, что вообще могут содержать промпты.
Если у вас возникла мысль "что-то конфиг получился маловат, надо бы что-нибудь добавить", то воспользуйтесь следующим чек-листом:
* **Факты**: знания о том, где мы находимся, с чем работать, где искать дополнительную информацию.
* **Установки**: роль и цели ИИ, цели человека.
* **Команды**: что делать (предписания), что не делать (запреты и ограничения, "негативный промпт").
* **Примеры**: образцы критериев, ответов и других опорных точек, которые помогут ИИ лучше понять задачу.
* **Сценарии**: рекомендуемый порядок выполнения последовательности команд (возможны ветвления и переходы, досрочные и аварийные остановки).
* **Маркеры**: заголовки, списки, выделение ключевых слов и прочее форматирование, которое помогает ИИ ориентироваться в тексте и правильно расставлять акценты.
* **Мета-данные**: то, что помогает увязывать несколько последовательных промптов в единую задачу.
Если возникла мысль "вроде бы в конфиге всё есть, но работает плохо", то пригодятся критерии для оценки качества промптов. Еще один полезный чек-лист для выявления возможных проблем:
* **Конкретность**: давать не только общее направление, но и точные инструкции, чтобы ИИ не гадал про замысел.
* **Однозначность**: если инструкция допускает несколько разных толкований, то её следует переформулировать.
* **Ограничения**: помогают в создании конкретности и однозначности.
* **Непротиворечивость**: нельзя требовать разного. В случае каскадного промптинга, когда воедино сливаются промпты из разных файлов, нужно хотя бы прописать приоритеты, например: локальное важнее глобального, сценарий важнее роли.
* **Полнота**: даны все знания и установки, которые нужны для получения качественного результата.
* **Релевантность**: отправляемая информация относится к текущей задаче, а не ко вчерашней или к параллельной.
* **Неизбыточность**: не отправлять за раз слишком много информации и команд, чтобы ИИ не захлебнулся, рассеяв внимание. Обычно помогают конкретность и релевантность, но иногда приходится прибегать к декомпозиции задач.
* **Краткость**: если для инструкции есть несколько вариантов написания, которые похожи по конкретности и полноте, то следует выбрать как можно более короткий вариант.
* **Язык**: из синонимичных выбирайте те выражения, которые лучше понятны ИИ, а не человеку. Ему с этим работать.
* **Консистентность**: единообразие терминов и формулировок. Например, "проверка", "анализ" и "ревизия" - это не одно и то же для ИИ, художественное разнообразие в промптах не нужно и даже вредно.
* **Защищенность**: если в промпт подставляется содержимое произвольных файлов, то оно должно быть оформлено и подкреплено инструкциями так, чтобы случайно (или зловредно) попавшееся подобие команды не сбивало рабочий процесс. В IDE этим занимаются встроенные механизмы оркестрации, но если вы планируете в своей базе текстов держать заготовки промптов, то не помешает добавить в конфиг несколько защитных заклинаний.
* **Структурированность**: формулировки и форматирование помогают ИИ понять, к чему относится каждая фраза. Как минимум, разделяйте факты и команды.
* **Связность**: группируйте схожие инструкции и предваряйте списки заголовками (пояснениями), чтобы ИИ не спотыкался на слишком резких переходах между разнородными мыслями.
* **Акценты**: если есть хоть малейший риск возникновения неоднозначности или переполнения внимания, то указывайте, что является главным, а что второстепенным (форматирование в помощь).
Если данный чек-лист выглядит слишком сложным, то он вам не нужен. На начальном уровне главное - это баланс между крайностями полноты и избыточности. Давать для картины контекста все необходимые детали и не давать лишнего. Если конфиг "захромал", то или не хватает нужного, или есть лишнее.
Когда я пишу в чате с ИИ-агентом "сделай такую-то задачу", в нейронку улетает большой текст, состоящий из разных частей:
- Наверняка добавятся инструкции по конкретной задаче (пользовательский промпт).
- Автоматически добавятся инструкции из системного промпта плюс история беседы (если она была).
- По мере надобности будут догружаться агентские инструкции из конфигов, скиллов и инструментов. Например, агенты могут прочитать содержимое папки, заинтересоваться какими-то файлами и самостоятельно добавить их содержимое себе в контекст.
Поскольку агентские конфиги лежат в корневой директории и в подпапках, скиллы могут подтягивать друг друга, и по мере чтения файлов могут подключаться разные сценарии, можно говорить о том, что мы перешли к каскадному промптингу. И это значит, что приходится больше внимания уделять устранению возможных противоречий и борьбе с избыточностью.
По сути, это уже переход от промптинг-инженерии к контекст-инженерии - мы заботимся уже не только об отдельных формулировках, но и о сочетании формулировок из разных файлов. Мы разделяем промпты по ролям и задачам, а не сваливаем всё в одну кучу, чтобы не переполнить контекст отправкой всего подряд. Если где-то раздувается файл с промптом, значит пора его декомпозировать, разделить на несколько более узко специализированных и прописать, какая часть нужна в каких-то конкретных случаях.
Например, если какой-то скилл стал слишком тяжелым, то выносим тяжелые части в соседние файлы. В `.agents/skills/skillName/` могут появиться подпапки:
- `references` - справочная документация и примеры, которые иногда могут понадобиться при работе данного скилла.
- `assets` - файлы, которые содержат не знания, а дополнительные настройки, шаблоны или иные ресурсы.
- `scripts` - скрипты и утилиты, инструменты, которыми скилл может пользоваться.
- `storage` - логи, индексы и другая информация, которую скилл будет собирать и использовать при работе.
- `tests` - юнит-тесты для проверки логики скриптов и корректности ответов скилла.
На начальном уровне это обычно не требуется, но если вы захотите скачать из интернета какой-нибудь скилл или воркфлоу и увидите, что там не просто файл с кусочком промпта, а какая-то сложная структура, то вам следует знать, что так бывает. И в таком случае вам следует не полениться и заглянуть в скачанное, чтобы проверить, нет ли там чего-нибудь вредоносного. В интернете выкладывают не только полезное, увы.
И вся эта сложность нужна для того, чтобы не переполнить контекст и внимание модели тем, что иногда вроде бы полезно, но не относится к текущей задаче.
На продвинутом уровне в AI IDE подключаются инструменты (начиная с RAG и MCP-сервисов), которые позволяют расширять возможности ИИ-агентов. Например, можно дать своим ИИ-агентам возможность запрашивать информацию из какой-нибудь вашей базы данных. Но я сейчас вернусь к более простым настройкам.
Вы уже настроили бакап ваших ценных файлов в облако? Если вы выбрали GitHub, то не забудьте прописать в файле `.gitignore` списки того, что именно следует отправлять, а что отправлять не нужно (логи и тяжелые архивы лучше не держать рядом с текстами). Плюс настройте автоматическую отправку по времени (вечером) и по нажатию кнопки (после больших и важных изменений). Если вы планируете редактировать вашу базу с разных компьютеров, синхронизируя изменения через облако, то вам также нужно получить информацию о том, как в Git решать возможные конфликты (один файл менялся из двух мест). Как всё это сделать - вам может подсказать ИИ.
Если вам надоела назойливость автодополнения (Suggestions), то следует заглянуть в настройки IDE и выключить лишние опции. Если вам не нравится расположение окон, цветовое оформление, хочется увеличить шрифт или овладеть горячими клавишами для ускорения работы, то следует заглянуть в настройки и справку IDE. Где всё это искать и менять - вам может подсказать ИИ.
Если вам не хватает автоматической проверки орфографии или хочется, чтобы редактируемый абзац подсвечивался немного ярче, чем соседние (это реально удобно), то вы можете добавить в IDE множество плагинов. Их тысячи. В выборе и настройке вам может оказать помощь ИИ.
Если вы решили полностью пересесть на IDE, отказаться от других сервисов автоматизации (N8N, например), то вы можете расширять функционал IDE так, как вам позволит фантазия. Если фантазии не хватает, то можно посоветоваться с ИИ.
Серьезно, современные большие облачные ИИ уже неплохо знакомы с современными AI IDE, их ответы зачастую более информативны и быстры, чем поиск в интернете.
NB: В этом месте я запнулся, потому что Google Gemini 3 попытался убедить меня, что не существует никакой Google Antigravity IDE. Но при этом он охотно подсказал мне список рекомендуемых плагинов для писательской работы в этой IDE. Бывает и такое, пройдет через пару месяцев при обновлении версии.
Здесь самое время вспомнить про существование веб-сайтов, где с этими ИИ можно чатиться. Работа ИИ-агентов в IDE имеет свои ограничения - лимиты на частоту и объем запросов. Особенно на бесплатном пробном тарифе. Чтобы не исчерпать эти лимиты слишком рано, любые вопросы "как мне лучше сделать" или "давай обсудим" следует делать не в IDE, не в чате с агентом, а в браузере, зайдя на привычный сайт любимого ИИ. Лимиты в IDE и лимиты на сайте - это разные лимиты, даже если вы залогинены везде одним аккаунтом. Приберегите ресурсы в IDE для работы, беседовать лучше в других местах.
Предполагаю, что контекст читателя уже переполнился, внимание размылось.
-- Какой заяц? Какой орел? Какая блоха?! (с) мультфильм "Ух ты, говорящая рыба!"
Если вам что-то кажется сложным (какой-то гит, плагины, юнит-тесты, MCP и прочие штучки для программистов), то напоминаю главный принцип - вам нужно только то, что нужно вам. Вам не нужно всё то, что показалось полезным для других.
Начинайте с краю. IDE - это крутой редактор текстов. AI IDE - это крутой редактор текстов с командой ИИ-помощников. Добавляйте в него только то, что облегчает вам жизнь или работу. А бакапить тексты можно и на флешку (любите бакапы).