Текстовые редакторы и IDE *

Привет, Хабр.

Сейчас почти каждый AI-кодинг-агент подключает LSP — Language Server Protocol. Это тот самый протокол, по которому редактор общается с языковым сервером: go-to-definition, find usages, hover с типом, диагностика. На этом обычно и пишут: «агент понимает код семантически».

Но мы в Veai делаем агента для JetBrains IDE, и нас периодически спрашивают: а зачем вообще нужен IDE, если LSP уже всё умеет? Хороший вопрос. LSP и правда решает много задач, но он проектировался для редактора, а не для агента. Подсветить ошибку, показать тип под курсором, найти ссылки — для этого LSP достаточно. А вот поменять Spring-бин в enterprise-проекте и не сломать сборку — тут нужно чуть больше.

Под катом разберём, что именно LSP даёт агенту, где этого перестаёт хватать и что поверх той же модели проекта предлагает JetBrains Platform. Спойлер: сравнивать LSP и PSI один в один бессмысленно — LSP это протокол, PSI это модель. Речь пойдёт о LSP vs весь стек IDE.

Работа с текстом — это, пожалуй, одна из главных областей применения больших языковых моделей (LLM). Существует много способов редактирования текста. Аналитики, например, часто работают с разметкой markdown — такой текст почти ничего не весит, с ним легко работать в любом текстовом редакторе и его легко можно сгенерировать при помощи скриптов. Но не секрет, что для подавляющего большинства пользователей редактор Word по‑прежнему остается основным инструментом. Мой личный опыт работы с текстом таков — свои тексты и научные отчеты я готовлю в редакторской системе Quarto, иногда в чистом markdown. Готовый текст рендерю в .docx и уже затем выполняю чистовую доработку в MS Word. И вот здесь могут возникать трудности — если с чистым markdown можно без проблем работать при помощи встроенных в текстовый редактор (я использую Visual studio code) инструментов LLM, то в Word их нет. Вернее, есть, но использовать их в России по целому ряду причин невозможно.

Я давно хотел решить эту проблему и сделать так, чтобы LLM был всегда под рукой, прямо в редакторе Word. В итоге родился небольшой пет‑проект — набор VBA‑макросов для MS Word, который добавляет функционал работы с любыми LLM через OpenAI‑совместимый API.

Если вы хоть немного следите за AI coding, то наверняка слышали новую мантру: IDE больше никому не нужна. Все «вайбанутые» живут в терминале, запускают Claude Code, Codex или OpenCode и уверенно объясняют, что профессиональная среда разработки — это пережиток эпохи, когда код писали руками.

Agent-у хватает самых простых инструментов: grep, bash, edit и пары хороших prompt-ов. Сложные интерфейсы, UI-инспекторы, рефакторинги, дебаггер — всё это выглядит как пережиток прошлого. Открыл терминал, написал задачу, получил diff. Кажется, человечеству IDE больше не нужна. Или всё-таки нужна? Тут как посмотреть.

JetBrains в этой картине обычно достаётся роль динозавра. Компания много лет задавала планку того, как должен выглядеть профессиональный инструмент разработчика. Но когда индустрия сместила фокус с IDE на agent-ов, предложенные JetBrains AI Chat (ex. AI Assistant) и Junie выглядели не как новый тренд, а скорее как попытка заскочить в уходящий поезд.

Но у тезиса «IDE больше не нужна» есть слабое место: он смотрит на IDE только глазами человека. А что, если следующими пользователями IDE будут не люди, а agent-ы? В компании JetBrains с закатом IDE, естественно, не согласны и предлагают своё видение: среда разработки как набор инструментов и знаний о проекте, доступных AI Agent-у.

Команда OpenIDE здесь придерживается схожей позиции: мы считаем, что IDE никуда не денется. На данный момент ни один разработчик, которого я знаю, не удалил IDE с рабочего компьютера, хотя agent-ами пользуются уже все или почти все.

Но сегодня поговорим не о том, зачем IDE нужна человеку и почему от неё не отказываются, а о том, зачем IDE нужна agent-у.

Когда подключаешь ИИ-агента к новому репозиторию, первые полчаса уходят не на код, а на объяснения. Какой стек, какие соглашения в команде, чем отлаживаемся, где лежат тесты, что нельзя трогать. Агент всего этого не знает – он стартует «универсальным» и собирает контекст по кусочкам, твоими руками, в каждом новом чате заново.

В Veai 5.13 мы попробовали закрыть именно эту боль. Главная фича релиза — онбординг агента в проект: при первом запуске агент сам проходит короткий диалог и за минуту настраивает себя под вашу кодовую базу – создаёт правила, подключает навыки и внешние инструменты. Дальше он с первого сообщения говорит на языке вашего проекта.

Разберёмся, как это устроено, в какие файлы всё сохраняется. А ещё пройдёмся по остальным изменениям релиза: генерация тестов в WebStorm и PyCharm, доступ к файлам за пределами проекта и хоткей для переключения между редактором и чатом.

Когда работаешь с AI-агентом в большом проекте каждый день, накапливаются две усталости. 

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

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

В Veai 5.14 мы взялись за обе. Появился Memory Bank – агент запоминает факты о проекте между чатами. И профили маршрутизации моделей – субагенты работают на разных моделях под разные задачи. Плюс окно результатов ревью, проектные MCP-серверы и несколько изменений в интерфейсе. Разберём по порядку.

Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.

Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.

Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.

Если вы работаете с Codex, то наверняка замечали  следующее - нажимаешь кнопку “Обновить”, Codex перезапускается, но визуально ничего не меняется.

На самом деле изменения есть - просто чаще всего это не что-то глобальное, а внутреннее: скорость, MCP-инструменты, работа с Git и т.д.

Я посмотрел свежие релизы Codex за последние сутки: 0.142.2, 0.142.1 и несколько 0.143.0-alpha.*. В статье разберём, что уже вышло в свет, а что пока тестируется и возможно выйдет в ближайших обновлениях.

Спойлер: возможно скоро будет новый режим модели Ultra!

Представьте: вы даёте задачу, а интеллект внутри IDE сам всё делает. Без интернета, без копилки токенов. Видит весь проект а не конкретный файл. Это уже реальность.

В чем отличие агента от чата - ассистента?
Всё просто они работают по схеме запрос-ответ. Спросил, получил текст и дальше сам разбирайся. А агент - это совершенно другая история. Агент сам планирует, что делать, сам использует инструменты (редактировать файлы, выполнять команды в терминале, искать по проекту), помнит весь контекст сессии и, что важно, умеет реагировать на ошибки и корректировать свои действия на ходу. Cline в IntelliJ именно такой. Он реально работает в вашей среде, почти как живой коллега.

Как фанат Emacs я рад каждой встрече с этим редактором в любых контекстах. Случается это редко — всё же Emacs относится к нишевой категории, и в современной поп-культуре его востребованность невелика. В этой статье я разберу все известные мне упоминания этого редактора вплоть до июня 2026 года и продолжу вносить новые по мере их нахождения. В основной список я включил случаи, которые встречал на экране (в кино и сериалах), а также в комиксах и мангах. Книжные упоминания я решил выделить в отдельную категорию «Доска почёта».

Ну что ж, начнём.

Главная ценность релиза — разработчик начинает с рабочей задачи, а не с выбора режима.

Каждый день есть задачи, которые хочется сделать быстро и чисто: разобраться с падающим тестом, поправить метод, доделать фичу. Но правильный путь не всегда понятен заранее: иногда нужна простая правка, иногда — исследование проекта, тесты, ревью или отладка.

Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.

Попробовать Veai 5.12 · Что входит в релиз

В этом релизе мы собрали изменения, которые закрывают весь путь работы с агентом: от первого сообщения в чат до проверки результата.

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

Всё так или почти так, "но есть одно но" как поётся в одной известной песне. ИИ стоит денег, и весьма немалых при текущих ценах. А про локальные модели для большинства пользователей и компаний в РФ можно забыть. Ну и в целом кажется локальные модели - это не сценарий ИИ будущего.

Соответственно, как мы платим за интернет и за свет - регулярный платёж за ИИ — то, что нам светит в будущем, а большинству уже сейчас. На текущий момент времени расход токенов - пожалуй, самое главное что-тормозит повсеместное внедрение ИИ. Полностью без оплаты конечно не обойтись (нуу почти), но существенно сократить её точно можно. Далее все методы, которые я испробовал и использую за 3 года работы. По убыванию - от самых жестких и очевидных, до самых хитрых и "технологичных".

Морской бой — простая игра, в которую можно научить играть даже первоклассника. Тридцать лет назад реализацию этой игры на компьютере можно было продавать. Десять лет назад написание морского боя на любимом языке было хорошим упражнением для будущего программиста. Сегодня, когда с написанием такой игры справится и продвинутая нейронка, сложно кого-то удивить очередной ее реализацией. Но я все же попробую.

Я решил написать морской бой на sed — потоковом текстовом редакторе из набора стандартных юниксовых утилит. Обычно его применяют для того, чтобы заменить в потоке или файле одну регулярку на другую. Но дополнительные директивы, которые есть в sed, формируют Тьюринг-полный язык, на котором теоретически можно написать что угодно.

Так, энтузиасты писали на sed мастермайнд (на наши деньги — «Быки и коровы»), сокобан, сапер и даже шахматы. Я упоролся несколько сильнее и написал игру с неполной информацией, псевдослучайной генерацией расстановок и ходов и достаточно сильным противником. Причем реализованный алгоритм позволяет усилить его еще больше, изменив буквально пару строк. Насколько я могу видеть по гитхабу, у меня получился один из самых масштабных на сегодняшний день проектов (если не самый масштабный) среди всей этой адской эзотерики.

В процессе работы я никак не использовал нейронки — ни для генераций, ни для консультаций. С одной стороны, это было правильно, ведь проекты, которые были написаны раньше, люди писали без нейронок. Так что это их использование было бы просто неспортивно. С другой стороны, они могли бы помочь в плане критики тех или иных подходов, а потому некоторые мои архитектурные решения наверняка весьма дремучи. С третьей стороны, именно в личном почерке ведь и заключается искусство, а ради него все и затевалось.

Сперва я просто хотел показать, какие клевые вещи можно реализовать самыми минимальными средствами, но в итоге получился большой пошаговый гайд. Для тех, кому результат интереснее процесса, в конце статьи есть ссылка на гитхаб, чтобы сразу посмотреть, что получилось. Остальные — наливайте чайку и добро пожаловать под кат!

У AI-агентов есть неприятное свойство: они часто выглядят умнее, чем их обратная связь.

Модель может хорошо писать текст, аккуратно рассуждать о коде и уверенно предлагать правки. Но если все, что она видит, это grep, несколько похожих файлов, команда в терминале и длинный лог, то ее выводы строятся на шумном сигнале. Иногда этого хватает. На небольшом проекте, с сильной моделью и простой задачей, агент действительно может быстро помочь. Но! В enterprise-коде ситуация другая. Важны конкретная версия зависимости, выбранная run configuration, classpath, SDK, профиль, состояние объекта в рантайме, IDE warnings, usages, inspections, trace уязвимости, важны факты, без которых агент начинает угадывать.

Разберем на последних релизах Veai 5.8-5.11 рабочий цикл разработчика в любимой IDE.

Как обычно в начале месяца мы рассказываем вам о том, что изменилось в GigaIDE за прошедший месяц — май. Соответствующий обзор за апрель доступен здесь. Ниже — краткий обзор обновлений Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе.

На прошлой неделе мы выпустили динамические воркфлоу в Claude Code. Теперь Claude может на лету писать собственную обвязку (harness) под конкретную задачу.

Стандартная обвязка Claude Code создавалась для кода — но она также полезна для многих других типов задач, поскольку, как выясняется, многие задачи напоминают задачи по написанию кода. Тем не менее есть определённые классы задач, под которые нам приходилось строить кастомные обвязки поверх Claude Code для достижения максимальной производительности: исследования, анализ безопасности, командные агенты или ревью кода.

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

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

Наш предыдущий обзор касался поддержки в GigaIDE — возможно, самого популярного фреймворка Python, который, однако, восходит к эпохе шаблонизаторов, когда веб-страницы формировались на бэке. Кстати, обзор, как реализована поддержка идеологических братьев Django в Java, есть здесь.

Сегодня мы рассмотрим поддержку других популярных Python-фреймворков: FastAPI, Flask, SQLAlchemy и немного Pydantic. В отличие от Django, все из них стали популярны благодаря своей легковесности и узкой специализации. Первые два — это веб-фреймворки, третий — ORM-фреймворк.

Любая компания — точка в семимерном пространстве.

Эти семь координат меняются не одновременно. Например, у компании уже могут быть ai - агенты и внутренняя платформа, но сотрудники всё ещё работают через чат, проверки запускают вручную, а решения принимают по старой управленческой логике. Поэтому одного ответа «мы на L5» мало: он не объясняет, где в компании создаётся стоимость, что реально выходит наружу и как быстро организация меняется. Одна шкала легко превращается в маркетинг, а профиль по семи осям даёт более проверяемую картину.

Профиль можно записать так: ⟨A, B, C, D, E, F, G⟩.

Оси D / E / F — структурный сдвиг, который не виден на пирамиде агентов. Их трудно сфейкать: они требуют пересборки ответственности, identity, расчётов и формата производства ценности. Именно там появляется настоящий moat AI-native компании, если он вообще появляется.

Что именно стало лучше в инженерной системе после внедрения AI?

Это можно проверить: сократился ли lead time, стало ли ревью быстрее, уменьшился ли риск изменений, начали ли команды чаще доводить AI-предложения до проверенного pull request. Или AI просто добавил ещё один слой активности: больше черновиков, больше подсказок, больше обсуждений, но тот же bottleneck в тестах, ревью и понимании контекста?

В Stack Overflow Developer Survey 2024 76% респондентов уже используют AI-инструменты в разработке или планируют начать, а 62% уже используют их сейчас. Но позитивное отношение снизилось с 77% до 72%, и это важный сигнал: первая волна восторга проходит, руководители и разработчики начинают спрашивать не «есть ли у нас AI», а «что он реально меняет в работе».

Пятница, вечер. Один эндпоинт начал отвечать восемь секунд вместо двухсот миллисекунд, а в Grafana всё зелёное. PostgreSQL редко падает громко — он неделями копит мёртвые строки, лишние индексы и зависшие транзакции, пока не станет совсем плохо.

В статье — пять SQL-запросов из моего queries.sql, которыми я реально пользуюсь: bloat и dead tuples, топ тяжёлых запросов по pg_stat_statements, неиспользуемые индексы, висящие транзакции и блокировки. Работают на голом PostgreSQL 13+

Год назад я почти перестал писать код руками - теперь чаще диктую задачу агенту прямо в терминале. И однажды понял, что мой здоровенный IDE превратился в дорогую рамку вокруг одного окна. Так появился лёгкий редактор, где терминал главный, а код с git - сбоку.

Внутри - про инженерию, а не про “качайте продукт”: как агент-независимо ловить “агент работает / ждёт ответа / закончил” через /proc, как собрать Windows-сборку Electron прямо с Linux без Wine, темы на контракте CSS-токенов и пара граблей, на которых я знатно подгорел (привет, Ctrl+V в русской раскладке).

Почему классический разбор SAST-находок — это боль

Сценарий, знакомый многим разработчикам в крупных компаниях: перед релизом ИБ-отдел присылает выгрузку из корпоративного сканера. В этом PDF-файле на сотни страниц собраны тонны находок. Большая часть из них снабжена метками вроде Critical. И вот, вместо скроллинга ленты подготовки релиза разработчик сталкивается с трудоемким процессом анализа:

Открыть указанный в отчете файл

Обнаружить там какую-нибудь generic-функцию, которая принимает строку и склеивает SQL-запрос

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

Разобраться, была ли где-то по дороге валидация или экранирование

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