Раз в полгода Anthropic балует программистское сообщество новыми большими языковыми моделями. В мае 2025 года вышла модель Opus 4, которая сильно улучшила качество генерируемого кода, а в ноябре — Opus 4.5, основное внимание в которой было уделено способности модели работать с внешним тулингом (MCP, Skills...). Кажется, я что-то пропустил. Ну конечно — Opus 4.1, вышедшая в августе 2025 года, которая запомнилась... небольшими улучшениями в 2–3% на синтетических тестах. Всё логично: именно поэтому это был минорный релиз с небольшим анонсом в блоге. Но в эпоху AI любой «дроп» новой модели — это событие мирового масштаба, и неважно, сколько ты добавил цифр после точки.

Поняв это с Opus 4.1, Anthropic решила выпустить Opus 4.6 «по-настоящему», предложив партнёрам ранние беты, собрав публичные отзывы, подготовив полноценный анонс и раздав bounty в $50 на Opus 4.6 пользователям платных подписок. Но по факту мы имеем минорный релиз без, кажется, серьёзных улучшений для программистов. Так ли это — давайте разбираться.

Странный вопрос, не правда ли? У AI-агентов, конечно, есть разные проблемы, но вряд ли их можно обвинить в медлительности. Спросите, как говорится, любого, какие у него ощущения от AI, и первое, что вы услышите, будет что-то вроде: «AI за 3 часа сгенерировал мне 100 тысяч строк кода». Разве это можно назвать медлительностью?

На этом месте можно было бы и разойтись: 100 тысяч за 3 часа. Покажите мне человека, который способен хотя бы в половину этого, — и «я съем свою шляпу». Но я по‑прежнему утверждаю, что AI-агенты слишком медленные. Не верите? Добро пожаловать под кат…

Пятница, вечер. Обычный коммит перед выходными. В списке файлов — ничего подозрительного. Через пару часов API-ключи от продакшена уже лежат в публичном репозитории.

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

В этой статье разбираем, как API-ключи «утекают» при работе с HTTP-клиентами, почему Postman и IDE создают ложное чувство безопасности и какие системные ошибки приводят к реальным инцидентам с многомиллионными последствиями.

После ухода JetBrains из России и введения экспортных ограничений многие разработчики столкнулись с банальной проблемой: IntelliJ IDEA Ultimate формально недоступна, а работать нужно сейчас. В результате в ходу оказались «активаторы» — shell-скрипты, которые обещают решить вопрос лицензии за пару минут.

Снаружи всё выглядит просто: скачал, запустил, IDE работает. Внутри — Java-агент с Instrumentation-доступом, модификация сетевого стека и вмешательство в криптографические примитивы стандартной библиотеки Java. При этом исполняемый код скачивается с внешнего сервера без подписей и проверок, а установка сопровождается правками системного окружения и использованием sudo.

В статье я разбираю один из популярных активаторов на уровне реализации: от .sh-скрипта до трансформаций байткода и подмены BigInteger#oddModPow(). Без эмоций и морализаторства — только факты, архитектура и последствия для безопасности, стабильности и юридических рисков.

В завершение 2025 года хотелось бы взглянуть на наш проект российского BPM-движка “с высоты птичьего полета” и оценить, насколько нам удалось продвинуться по глобальной функциональной карте. Особенно в свете недавно вышедшего обзора ТБанк, где коллеги пришли к выводам о необходимости создания собственного форка и поставили много вопросов о том, что Camunda-ориентированная разработка архитектурно хороша, но не отвечает многим современным требованиям безопасности.  

Мы в OpenIDE хорошо понимаем, что среда разработки — это не просто набор инструментов и функций. Это пространство, в котором разработчик проводит значительную часть своего времени: думает, экспериментирует, ошибается и создаёт новое. Именно поэтому для нас особенно важны открытость, доступность и ощущение живого диалога внутри экосистемы. 

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

И когда до Нового года остаётся совсем немного времени, а сил на сложные технические материалы почти не остаётся, мы решили немного сменить ритм. Вместо глубоких разборов — лёгкое, тёплое и предпраздничное чтение. Так появилась идея серии интервью с участниками нашего комьюнити — людьми, которые создают плагины для OpenIDE.

Разворачивать приложения в облаке должно быть просто. Но на деле - всё наоборот. Вместо “вжух-вжух и в продакшн” получаем вечер с документацией, пляски с параметрами Terraform и постоянную проверку, правильно ли связались ресурсы.

В статье разберемся, как от использования UI консоли приходят к Terraform, и как OpenIDE позволяет вернуть легкость UI консоли при работе с Terraform.

Amplicode 2025.3 — релиз про новые фичи для Spring Data JDBC, улучшения для HTTP-клиента Connekt (между прочим, убийца Postman), поддержку MyBatis и новые возможности по работе с инфраструктурой вокруг Kubernetes и Terraform.

Ниже — ключевые изменения по блокам.

Данная статья посвящена практическому изучению механизмов Class Data Sharing и AppCDS. В ней рассматривается, какие именно компоненты ускоряются CDS в HotSpot JVM, почему для Spring‑приложений зачастую оказывается недостаточно использования «CDS по умолчанию», а также каким образом можно собрать .jsa‑архив для приложения — как в локальной среде, так и при работе с Docker.

Отдельное внимание уделено теоретическим аспектам JIT‑компиляции и tiered compilation, а также практической части с измерениями времени запуска. В качестве дополнения рассматривается влияние использования Spring AOT, а также переход на Java 25 и применение Spring AOT Cache.

AI-помощники в IDE — уже не фантастика, а ежедневная реальность. Но как сделать так, чтобы они действительно помогали, не лезли не в тему, не сливали код в облако и не требовали подписку на каждого чиха? Ответ — Continue: open source AI-ассистент, который интегрируется с IntelliJ IDEA, GoLand, WebStorm, OpenIDE и другими IDE на базе IntelliJ Platform. 

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

Эта статья дополняет предыдущую. Там мы зафиксировали проблемы. Здесь разберем, что именно мы сделали со стороны Amplicode, чтобы агент начал работать как опытный software engineer: опираясь на структуру проекта, детерминированные генераторы и понятные высокоуровневые операции.

Если коротко, в первой статье было несколько основных болей:

– LLM часто обучены на слегка устаревшем мире, и это вылезает в мелочах (и не только).
– Галлюцинации и нехватка контекста идут рука об руку: «кажется, в этой библиотеке должен быть такой метод» и пошло-поехало.
– Переизбыток контекста тоже зло: агент прочитал половину репозитория, потратил деньги, запутался, а потом еще и забыл начало чата.
– Типичный агентный workflow: «сгенерил простыню кода, оно не компилится, давай чинить, ой теперь сломалось другое».

И на этом фоне появляется логичный вопрос: а можно сделать так, чтобы агент работал не с сырыми файлами, а с моделью проекта и сущностями фреймворка? Чтобы он не гадал, где DTO, как принято именовать контроллеры и какие миграции у вас используются?

Собственно, Spring MCP от Amplicode про это.

Вышла OpenIDE 2025.2 — первая российская IDE с поддержкой Java 25. Мы идём в ногу с платформой и остаёмся на самом острие технологий. Но не только этим релиз интересен: в нём появилась улучшенная отладка виртуальных потоков, обновления связанные с UI, а ещё пара важных обновлений экосистемы.

Поехали по порядку.

Недавно команда TypeScript представила TypeScript 7 — новую версию, переписанную на Go. Главные обещания: до 10× ускорения компиляции и до 8× более быстрый старт анализа проекта. Но самое интересное спрятано чуть глубже: вместе с TS-Go появляется полноценный LSP-сервер, встроенный прямо в компилятор.

Для многих IDE это шаг вперёд.
Для нас, команды OpenIDE, — это ещё и освобождение от ограничений, с которыми TypeScript приходилось поддерживать долгие годы.

В статье делимся контекстом, собственными экспериментами и наблюдениями — что уже работает, что нет и как новый сервер ощущается в реальной IDE.

Реляционные базы данных по-прежнему остаются главным хранилищем наших данных. А значит, вопрос выбора инструмента отображения данных из БД на уровне приложения - всё так же актуален.

Долгое время я выбирал: Spring Data JPA. Уверен, что большинства из вас — тоже. Но времена меняются, и в 2025 для своих новых проектов я использую — Spring Data JDBC.

Почему? Если вам стало любопытно — добро пожаловать под кат.

Данная публикация является переводом статьи Jeff-a Atwood-а почти 20-ти летней давности. Jeff Atwood, один из фаундеров StackOverFlow, написал эту статью как некоторое резюме того, как человечество боролось с проблемой O/R Impedance Mismatch.

Я частично принимаю участие в написании разных ORM решений, например, Spring Data JDBC / R2DBC, и скоро мы вместе с Amplicode проведем online событие (оно бесплатное) по Spring Data JDBC. Будем обсуждать Spring Data JDBC, что в ней хорошо а что в ней плохо. Какие trade-off-ы она имеет.

Я решил выпустить данный перевод с целью того, чтобы напомнить людям - silver bullet-а Spring Data JDBC не придумала. Она лишь заняла конкретную позицию по ряду вопросов, из чего следуют определённые ограничения и преимущества. Их мы и обсудим.

Недавно вышел новый релиз GigaIDE, c момента прошлого релиза прошло значительное количество времени, а значит, команда создающая инструмент, скорее всего не сидела без дела, а неустанно штормила и реализовывала фичи. Завариваем чаю и пробуем. Тем более выход новой версии сопровождался новостями на различных медиа площадках и ребята обещают нам свой собственный маркетплейс.

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

Как измерить эффективность разработки

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

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

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

На какие статьи расходов влияют технологии и как их можно оптимизировать

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

Мы рады сообщить о выпуске Jmix 2.7! Эта версия представляет обновленный дизайнер ролей в Jmix Studio, новые UI-компоненты и включает ряд других улучшений фреймворка. Полный список изменений вы можете посмотреть в разделе "Что нового" документации Jmix.

Ниже приведен краткий обзор основных новых функций Jmix 2.7.

Это может прозвучать необычно, но развитие полноценных веб-приложений фактически началась с фронтенд-технологий. До разделения кода систем на фронтенд и бэкенд все они были как бы разновидностью сайтов, но с более сложными процессами, выполняющимися “на сервере”. На каждый запрос пользователя, сервером ему отдавался новый документ с такой же шапкой и подвалом. За редким исключением эти интерфейсы выходили достаточно примитивными, ведь каждое действие пользователя заставляло систему сначала немного подумать, и затем нарисовать новую страницу для результативного состояния. Значительные манипуляции с содержимым страницы в браузерах обычно были крайней непроизводительными, да и оказывались сложны для реализации. Изначально HTML-сайты или Web задумывались как упрощенный вариант издательской системы, в основе которой лежала идея "гипертекста” с переходами от одних страниц к другим через ссылки.