Если вы хоть немного следите за 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-у.

Уже много лет PHP выпускает мажорные версии примерно в конце ноября. PHP 8.5 вышел 20 ноября 2025 года, а PHP 8.4.0 — в конце ноября 2024 года. Если проект сохранит тот же ритм, PHP 8.6 с наибольшей вероятностью выйдет в третью неделю ноября 2026 года. Разумно ожидать релиз в четверг (как и у последних мажорных версий), так что ориентируйтесь примерно на 19 ноября 2026 года или 26 ноября 2026 года, а точная дата будет зависеть от того, сколько потребуется RC.

19-й выпуск IT-новостей от OpenIDE!

Midjourney открыла медицинское подразделение и сканер всего тела вместо МРТ, Cursor строит замену GitHub под AI-агентов, а в OpenIDE крупно прокачали поддержку Go. Тем временем японская Sakana AI без собственной топовой модели обходит Opus 4.8 и GPT-5.5, а Fable 5 от Anthropic остаётся отключённым по всему миру уже 11-й день подряд.

Java на бенчмарках обогнала Go при росте нагрузки: повтор эксперимента 2020 года в котором Mark Nelson и Peter Nagy сравнивали микросервисы на Go и Java на одном железе.

На маленьких нагрузках результаты совпадали.

В 2026-м повторили тест на актуальных версиях: Go 1.26, Oracle JDK 26, JDK с AOT-кэшем Leyden, Helidon SE 4.4 на virtual threads.

При лёгкой нагрузке Go и Java идут вровень.

При высокой нагрузке Java с Leyden AOT обгоняет Go почти вдвое.

Go не выиграл ни одного теста 2020 года. Leyden AOT — почти все.

Авторы подчёркивают: дело не в языке, а в том, что рантайм, фреймворк и настройки сети влияют сильнее, чем выбор языка.

Ранее в рубрике Skill of the Week мы уже разбирали Skill для Spring Data JPA. И, что предсказуемо, в комментариях нашлись те, кто увидел в нём лишнее доказательство простого тезиса: «вот видите, JPA не нужна, она слишком сложная». Аргумент понятный — у AI Agent-а с JPA действительно регулярно случаются «пожары»: ошибки в настройке связей между сущностями, странности с конфигурацией базовых типов, путаница с контекстом персистентности и разными состояниями сущности. Что характерно, ровно на этих же местах спотыкаются и живые разработчики — так что претензия скорее к технологии, чем к модели.

Раз JPA такая сложная — почему бы не взять что-нибудь попроще? Чистый JDBC многим кажется слишком низкоуровневым, и взгляд естественным образом падает на Spring Data JDBC: те же репозитории и сущности, но без прокси, lazy loading и кэша первого уровня. Технология проще — значит, и никакой Skill тут не нужен, верно?

А вот и нет. Умение AI «пользоваться» той или иной технологией зависит не столько от её когнитивной сложности, сколько от того, сколько кода с её использованием модель видела на этапе обучения. Spring Data JDBC объективно проще JPA, но кода с ней в открытом доступе на порядки меньше. Парадокс, но именно для технологий «с малым количеством кода» Skill даёт наибольший эффект: он закрывает ровно тот пробел, который модели нечем заполнить самостоятельно.

В сегодняшнем эпизоде еженедельной рубрики Skill of the Week разберёмся, как, используя Spring Data JDBC Skill, научить своего агента важным навыкам при работе со Spring Data JDBC.

Восемнадцатый выпуск еженедельных IT-новостей от OpenIDE.

Главная история недели: Claude Fable 5 продержался в публичном доступе три дня, после чего Anthropic получили директиву от Министерства торговли США и отключили модель для всех. На следующий день Zhipu AI выпустили open-source GLM-5.2 с прямым намёком на этот случай. Параллельно SpaceX провели крупнейшее IPO в истории и через несколько дней купили Cursor за $60 млрд.

write‑tools, безопасность, метаданные

Это вторая часть статьи по Sping AI в Джеймикс. Короткая аннотация первой — на случай, если прошло время или вы её не читали: мы собрали read‑only агент внутри Джеймикс‑приложения. Пользователь задаёт вопрос на естественном языке; ChatClient из Spring AI крутит agent loop — дёргает @Tool‑методы, пока не наберёт достаточно данных для ответа. Каждый tool данные читает через DataManager с явным fetch plan‑ом, поэтому почти полностью остаётся внутри рамок системы безопасности Джеймикс и возвращает только нужные модели поля. UI — обычный Джеймикс‑вью, без REST‑прослойки. Также, в первой части мы убедились, что выбор модели — не деталь: модель без надёжного native tool calling ломает всю схему. Если первую часть не читали — начните с неё, код ниже строится как продолжение.

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

Это не косметические изменения, а ровно те решения, что отделяют демо от приложения, которое можно показывать заказчику.

Полный исходник всего, что мы здесь обсуждаем, лежит здесь: https://github.com/jmix‑edu/ai‑warehouse — можно клонировать и сразу запустить.

Что добавляем

Знание и умение разрабатывать на Spring Data JPA — это обязательный навык для разработчика, если он хочет заниматься разработкой приложений на Spring. Этого мы ожидаем и от AI-агента.

Удовлетворяют ли наши AI-агента этому условию? Во многом зависит от того, насколько продвинутую модель вы используете. Значит ли это, что Opus 4.8 не совершает ошибок? Совсем нет. Более того, иногда удивляешься, почему еще вчера он настроил связь правильно, а уже сегодня сделал ту же работу, но добавил CascadeType.ALL.

В сегодняшнем эпизоде еженедельной рубрики Skill of the Week разберёмся, как, используя Spring Data JPA Skill, научить своего агента важным навыкам при работе со Spring Data JPA.

Это первая из двух статей про построение AI-агента внутри Джеймикс-приложения. Джеймикс (или Jmix, ex. CUBA) - высокоуровневый фреймворк для разработки корпоративных приложений на Java, автор не будет слишком сильно в него погружаться, в наше время любой запрос к AI даст Вам всю нужную информацию. В этой части мы соберем минимальный, но рабочий пример: пользователь задает вопрос на естественном языке, агент решает, какие операции вызвать на бэкенде, дергает их и возвращает осмысленный ответ. В качестве предметной области возьмем склад - сценарий, узнаваемый для большинства бизнес-приложений и достаточно широкий, чтобы во второй части обсудить уже не только чтение, но и запись данных, безопасность, fetch plans и метаданные.

Зачем это вообще нужно? Данные корпоративного приложения живут за списками и формами с фильтрами. Это отлично работает, когда пользователь знает, по каким полям фильтровать - и плохо для размытых, многокритериальных вопросов вроде "где у нас заканчивается кофе тёмной обжарки по северным складам?". Когда иначе пришлось бы открыть несколько экранов и руками свести результаты, AI-агент даёт возможность просто спросить - и собирает ответ из бэкенд-операций, которые у вас уже есть.

Почему строить это внутри Джеймикс-приложения, а не отдельным сервисом? В случае Джеймикса агент едет на том же доступе к данным и той же безопасности, что уже есть во фреймворке, его tools идут через DataManager, поэтому он видит ровно то, что разрешено текущему пользователю - никакого параллельного пути к данным, никакого обхода прав. Именно это свойство делает агента приемлемым в enterprise-контексте, и это поведение - сквозная нить обеих частей.

17-й выпуск IT-новостей от OpenIDE!

Anthropic за одну неделю успели опубликовать страшную статью про рекурсивное самосовершенствование ИИ и выпустить публичную версию Mythos. В России на несколько часов заблокировали Python, GitHub продолжает страдать от 17 млн AI-сгенерированных PR в месяц, а разработчики отказались работать без AI даже ради эксперимента.

Первичное наполнение контекста — крайне важная задача, результаты которой влияют на качество решения/сгенерированного кода, возможно, даже больше, чем выбранная модель. В Claude Code за это отвечает Explore sub-agent, который, к слову, справляется неплохо, ровно до тех пор, пока вы не начинаете "по настоящему" использовать Spring: добавляя собственные starters, используя OpenAPI (Spec-first), определяя Bean/Components в стиле Josh Long (описывая их в конфигурациях), а также внедряя множество других инструментов фреймворка. В этом случае качественный анализ можно провести, только зная особенности работы Spring Framework и экосистемы.

В этом выпуске еженедельного дайджеста Skill of the week разберёмся, как, используя Spring Explore Skill, научить агента понимать специфику Spring-приложения и выполнять качественный первичный анализ.

Если вы следите за текущими тенденциями в мире найма/вакансий, то определенно заметили, что куда-то подевались вакансии Middle и Junior-разработчиков, и у этого есть несколько причин.

Первая: рынок просел, и общее количество вакансий в IT-индустрии сократилось. В результате Middle-позиции теперь можно закрывать Senior-разработчиками. Это уже случалось в нашей истории, но за любым спадом следует подъем.

Вторая — AI-агенты. Senior-разработчики получили "рычаг". Теперь задачи, которые ранее поручали Junior и Middle-разработчикам, можно поручить AI Agent. При этом для Senior мало что меняется, поскольку подробное review делать нужно в обоих случаях.

Можно сказать, рынок оказался в "клинче". Сейчас нет времени думать, что будет дальше, поскольку нужно решать текущие вопросы, а когда начнется подъем, нужного количества разработчиков может и не оказаться, поскольку они ушли в "плотники".

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

28 мая вышел Opus 4.8 — через 41 день после 4.7 и с Dynamic Workflows, на которых переписали Bun. Через два дня появился DeepSWE и поставил под сомнение весь лидерборд, включая только что вышедший Opus. Enterprise-клиент без лимитов сжёг $500M за месяц. DeepSeek набирает команду для создания своего агента. А в MySQL закрыли 21-летний баг.

Откуда берётся «среднее приложение с GitHub»? Если попросить агента создать JPA‑сущность или настроить Spring Security, то он выдаст вполне рабочий код. Вопрос только в одном: для какого проекта?

Модели натренированы на миллионах репозиториев: студенческие работы, всех задолбавшая Petclinic, туториалы с YouTube, у меня кстати, есть куча своих:D.

Но без чёткого контекста агент выдаёт типичное «среднее приложение с GitHub»: всё синтаксически верно, но далеко не всегда вписывается в существующий РЕАЛЬНЫЙ проект. С Lombok или без него? Используя @IdClass или @EmbeddedId? Предпочитаешь Record'ы или классические классы? Как у тебя маппятся DTO? Агент этого не знает и чаще всего либо пытается угадать, либо начинает грепать всё что можно и нельзя.

Prompt engineering помогает, но ненадолго. Прикреплять каждый раз примеры сущностей и архитектурные правила — прошлый век. Интеграция в IDE с @ и выбором файлов уже лучше, но всё равно надо постоянно об этом помнить и как РОБОТ писать ему одно и тоже.

Каждый, кто программирует с агентами (Claude Code, Codex и т.д.), знает: перед тем как приступить к задаче, агент исследует проект. Это кажется логичным, естественным и закономерным, ведь люди делают так же. Обычно говорят: «агент наполняет контекст».

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

- задача определена в общем виде (кто знает, что имел в виду автор)
- пути исследования не детерминированы (в общем виде не используется специфика фреймворка)
- используются базовые инструменты (read, grep, cat, find)

В итоге при первичном исследовании легко столкнуться с ситуацией, когда основной контекст заполнен сведениями, слабо относящимися к исходной задаче.

В Anthropic быстро осознали эту проблему и вынесли всю описанную работу в Explore sub-agent. В результате основной agent ставит задачу промптом, Explore выбирает путь исследования, а результат формирует в виде отчета. Проблему чистоты основного контекста они, конечно, решили. Но что с качеством такого анализа?

Наблюдая за работой Explore и видя, как агент, используя «примитивные» инструменты, в агонии пытаясь отыскать недостающее или, наоборот, пропускает важные сведения о проекте, невольно ловишь себя на мысли: «Как так вышло, что последние 10 лет развития индустрии инструментов прошли мимо agent?» А может, это человечество свернуло не туда?

15-й выпуск IT-новостей от OpenIDE!

Вредоносная версия плагина провисела в VS Code Marketplace 18 минут и этого хватило, чтобы слить конфиги Claude Code, ключи AWS и 3800 репозиториев GitHub. 

Параллельно двое братьев удалили 96 правительственных баз данных за ~1 час после увольнения по Teams, а Bolt вообще уволил весь HR-отдел.

14-й выпуск IT-новостей от OpenIDE!

Побывал на HolyJS в Москве, пообщался с фронтендерами и понял разницу в вайбе. Плюс — прогрев к блокировке GitHub, эксперимент Bun с переписыванием на Rust за 9 дней, и немного про частный российский космодром.

AI-агенты уже стали частью повседневной разработки. Сначала это выглядит как магия: формулируешь задачу, получаешь код, тесты, иногда даже готовый PR.

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

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

13-й выпуск IT-новостей от OpenIDE!

Неделя получилась плотной: Grok потерял $175 тыс. без единой строки эксплойт-кода, европейские регуляторы выписали крупный GDPR-штраф «дочке» Яндекса, а Anthropic подписала сделку с куда более неожиданным партнёром.

А ещё обновления маркетплейса OpenIDE, новая архитектура SubQ и 423 закрытых бага в Mozilla благодаря Claude Mythos.

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

На практике же часто можно наблюдать:
– один skill активируется почти всегда, даже когда не нужен
– другой — не включается в момент, когда мы на него рассчитываем
– третий — срабатывает «в паре» с соседними и они мешают друг другу

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

Почему так происходит и что с этим можно сделать, разбираемся в статье.