Java *

В блоге Anthropic вышла статья Thariq Shihipar, в которой он рассказывает, как агент помогает находить ему Неизвестные Неизвестные (Unknown Unknowns). Я думаю, что мысли из статьи также очень важны для Spec Driven Development, и хорошо объясняют, почему спецификация это живой документ, и получение финального документа возможно только после того, как код уже написан, (ну или во всяком случае, одновременно с этим моментом). Если вы считаете, что Spec Driven Development — это будущее AI‑assisted разработки (намеренно не говорю вайбкодинг), прошу под кат.

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

Спойлер: один из результатов оказался прямо противоположным тому, что я ожидал увидеть.

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

Под катом — как этот шов гниёт под LLM и как его чинит contract-first: генерация серверных интерфейсов и клиента из одного OpenAPI-файла, политика ломающих изменений, правило «не симулируй — расширяй контракт». Попутно — зачем возвращаться к идее, которую мы выбросили вместе с WSDL, и какая из моих проверок после всего этого молча перестала работать. Третья часть цикла, читается самостоятельно.

Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.

Я уже выпускал статью по мотивам вопросов в рамках Spring Айо Академии. Так вот, когда мы разгребали отзывы с первого потока, мы также получили вопрос (это не прямая цитата, я лишь передаю посыл в том виде, как я его понял):

А что насчет натуральных ключей в БД? Если, допустим, у меня есть поле, по которому я могу явно идентифицировать запись, стоит ли его использовать как Primary Key?

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

В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.

У такого подхода есть цена.

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

Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.

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

Что показывают эксперименты, если читать их целиком

Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.

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

Выпущен Jmix 3.0, и это самый значительный шаг, который фреймворк сделал за последние годы. Этот релиз перестраивает основу на современном технологическом стеке, оставаясь полностью совместимым с предыдущими версиями, что делает миграцию гладкой и простой. Наряду с обновлением платформы, 3.0 представляет набор функций, которые активно используют ИИ и предоставляют гибкость в рантайм.

Ниже приведён краткий обзор основных новых возможностей. Полный список изменений, включая все критические изменения, доступен в разделе Что нового документации.

Всех приветствую!

Данная статья будет посвящена довольно важным вещам, таким как: refresh token, метод-уровневой безопасности и примеру реализации правила "свой/чужой профиль"

После вайб-кодинга: почему в 2026 году появляется новый класс Code Clean-up Agents. Как стоимость разработки смещается от генерации к проверке, рефакторингу и контролю изменений

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

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

В этой точке полезно отделить генерацию патча от подготовки изменения к отправке в основную ветку. Для второй задачи в 2026 году формируется отдельный класс инструментов: Code Clean-up Agents.

Как часто, работая с агентом над новой фичей, вы остаётесь недовольны результатом? То что-то не работает, то качество кода неприемлемо. Вы просите агента ещё раз и ещё раз, пытаетесь подобрать «идеальный» промпт — и всё равно не выходит. Уверен: чем дольше вы работаете с агентом, тем чаще разочаровываетесь. И это неудивительно: агент пишет код очень быстро — и именно поэтому ОЧЕНЬ просто получить ОЧЕНЬ много кода, который вам не нужен. Но код — это как раз простая часть. Настоящая задача инженера — строить системы: надёжные, быстрые и поддерживаемые. Именно за это нам и платят — и вот этого агент пока за нас не делает.

Origami Framework — фреймворк для автоматизации тестирования на Java, созданный с целью упрощения построения тестовой архитектуры и ускорения процессов приёмочного и регрессионного тестирования

Несмотря на то, что IntelliJ IDEA уже несколько лет официально недоступна в России, она по-прежнему остаётся одной из самых популярных IDE среди разработчиков. На днях вышла свежая версия 2026.2.

В релиз вошли новые инструменты для работы с ИИ-агентами, изменения в отладчике и автоматизация ряда повседневных операций. Также появилась поддержка Java 27, Kotlin 2.4, TypeScript 7, будущего Gradle 10 и обновления для Spring, Terraform и Docker Compose.

В статье пройдемся по основным изменениям.

Если вы Java-разработчик, которому в личных целях нужно поднять TLS 1.3 на ГОСТ, создать ГОСТ-сертификаты, подписать документ CAdES, создать свой тестовый УЦ, сделать шифрование и подпись на своем Android — эта статья для вас. Все примеры в этой статье одинаково работают что на JVM 21, что на Android 12+.

crypto-gost —   криптографическая библиотека алгоритмов ГОСТ на Java 21+ и Android 12+, а также сопутствующая обвязка вокруг них, позволяющая использовать в личных целях алгоритмы и стандарты ГОСТ в инфраструктуре Java. Статья написана в академических целях.

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

Strict‑режим включён, схема валидна, ответ успешно парсится — а в проде всё равно всплывают None, пропавшие ограничения и аргументы инструментов не тех типов.

В статье разберём пять ситуаций, где Structured Outputs создают ложное ощущение надёжности, и посмотрим, какие проверки действительно стоит добавить в LLM‑пайплайн.

Локально Testcontainers запускается за секунды, тесты стабильно зелёные, а в CI тот же набор начинает падать в трёх запусках из ста и каждый раз по новой причине.

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

Привет, друзья!

На связи Михаил Поливаха, технический лидер проекта Axelix.

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

Я обещался на все эти вопросы ответить в рамках статьи. На самом деле, одной статьи у меня не вышло, скорее всего, будет серия статей. Надеюсь, будет интересно :)

Привет, Хабр! Меня зовут Александр Бардаш, и я CTO интеграционной платформы MWS Octapi. В одной из предыдущих статей я рассказывал, как мы выбирали движок для low-code и почему остановились на Temporal, отказавшись от Apache Camel. С тех пор регулярно получаю один и тот же вопрос — от продактов, аналитиков, а иногда и от коллег-архитекторов: «Подождите, ну сейчас же есть Karavan, Kaoto, нормальные визуальные редакторы. Аналитик там накидает кубики, настроит логику, разве это не cделает Camel доступнее?» Короткий ответ — нет, не cделает. А вот почему, предлагаю разобрать в материале.

Дисклеймер: это мой личный опыт и опыт команды. Тема спорная, у вас может быть своя картина.

Меня заинтересовал новый плагин DB Client, который идёт в составе OpenIDE. Давайте посмотрим, может ли он уже на текущий момент стать достойной альтернативой платному DataGrip? Я не предъявляю каких-то узкоспециальных требований к таким инструментам. В основном требуется писать и оптимизировать sql-запросы, просматривать структуру таблиц и диаграмму связей между ними, просматривать актуальный DDL, выполнять мелкие правки данных “на лету”, а также делать импорт и экспорт данных в различных форматах. Давайте по этим пунктам и пройдёмся.

Открой свой Spring-проект, которому больше двух лет. Найди пакет common, core или framework — а он там есть, я почти уверен. Загляни внутрь.

Ты увидишь BaseEntity с id, createdDate и version. Увидишь AbstractCrudController<T, ID>, от которого наследуются все твои контроллеры. Увидишь самодельный слой прав — что-нибудь вроде @CheckPermission поверх PermissionEvaluator. Увидишь свой SoftDeleteRepository и аудит-слушатель на JPA-события.

Поздравляю: ты написал фреймворк. Свой, внутренний, недокументированный (себя-то не обманывай), поддерживаемый одним человеком (который уже собеседуется в другую компанию). И построил ты его ровно для того, чтобы не брать «тяжёлый и навязчивый» opinionated-фреймворк — ты сделал это «ради контроля».

Давай честно поговорим про этот контроль.

Наконец-то неплохо продвинувшись в написании своего мультиплатформенного приложения Modern Money мне понадобилась аутентификация для Kotlin Multiplatform.

Хотелось иметь один API для PIN-кода и биометрии, а под капотом использовать Android Biometric Prompt, Windows Hello, Touch ID.

Так появился Koncierge — набор KMP-модулей biometric, auth и auth-compose

Казалось бы, задача довольно стандартная: объявить expect-класс и написать несколько actual-реализаций. На Android это примерно так и получилось. А вот Windows Hello, JVM-модуль и публикация всех артефактов заставили немного разобраться в том,