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

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

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

Это конспект вебинара. Спикер — Даниил Степанов, разработчик-исследователь Veai, преподаватель ИТМО, ранее работал в JetBrains и Huawei.

AI уже пишет заметную часть промышленного кода, а процессы качества у многих команд остались такими, будто код всё ещё пишет только человек и в прежнем объёме.

Если коротко: проблема чаще всего не в том, что "модель тупая". Проблема в том, что вокруг агента нет инженерного контура: спецификации, ограничений, независимых тестов, security-checks, ревью-пайплайна и артефактов, которым можно верить.

Миграции базы данных вроде бы есть, Liquibase подключен, changelog лежит в репозитории, CI зелёный, релизы проходят регулярно. Значит, процесс под контролем?

Не всегда…

Почему добавление второго consumer«а в очередь может привести к двойным списаниям? Разбираем на реальном кейсе: как один Topic стоил компании 312 дублей за час. »

Сравниваем поведение JMS, Kafka и RabbitMQ, показываем, почему ни одна очередь не даёт exactly‑once из коробки, и как идемпотентность, Dead Letter Queue и правильный выбор канала (команды vs события) делают интеграции надёжными.“

Готовые схемы, продакшен‑код на Java и чек‑лист, который стоит применить прямо сейчас!

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

В последней части про модели конкурентности JVM языков мы сравним разные подходы друг с другом. И ответим на вопрос “А зачем теперь тред пулы, если есть столько модных концепций: корутины, файберы, виртуальные потоки ?”

Первая статья из цикла о каналах обмена сообщениями. Разбираем архитектурные дилеммы, конкурирующих потребителей, message storm, гарантированную доставку и лучшие практики команд, работающих с JMS и Kafka.

В Kotlin деструктурирование выглядело так: val (name, age) = person. Но компилятор берет значения не по именам, а по позиции component1/component2.

Отсюда проблемы. Если поменяли порядок параметров в data class или сделали age вычисляемым свойством: то та же строка начинает доставать другое поле. Причем иногда код даже скомпилируется, но, конечно, смысл изменится: val (age, name) = person.

И вот теперь Kotlin эксперементально переводит круглые скобки на деструктурирование по имени. Синтаксис будет такой: (val name, val age) = person. И порядок внутри скобок не важен. Переименование явно: (val years = age, val theName = name) = person.

Позиционное же деструктурирование остается, но переезжает в квадратные скобки для Pair/Triple и коллекций: val [x, y] = point.

Разбираемся полностью в новом переводе от команды Spring АйО.

Что будем делать или что может быть интересного в статье:

- Пайплайн из двух независимых LLM агентов

- Запуск и анализ ошибки UI автотеста (Root Cause Analysis)

- Фикс автотеста в цикле с его запуском.

- Кастомизация MCP инструментов чтобы оптимизировать контекстное окно.

- Система приоритетов в работе LLM агентов.

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

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

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Coroutine, Fiber, Virtual thread - это всё одно и то же?

Или нет ?

Или нет.

А если под капотом всё равно JVM, почему нельзя просто везде включить virtual threads и успокоиться? Разберемся!

Я сравнил Codex 5.3, Claude Opus 4.6 и GPT-5.5 на реальном многомодульном Java-монолите: скопировал проект в отдельные ветки, дал агентам похожие задачи и прогнал их через цикл правок, ревью и e2e-тестов.

Результат: чем дешевле - тем лучше результат.

В статье рассмотрим ряд техник GenAI, реализованных в модуле Spring AI, и ответим на вопрос: является ли ChatClient лишь тонкой оберткой над API провайдеров LLM или предоставляет функциональные возможности, которые имеет смысл применять в реальных проектах. В качестве примера будем итеративно разрабатывать приложение, интегрированное с Anthropic, и разбирать возникающие по ходу проблемы.

Всем привет! Меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

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

В какой-то момент я поймал себя на мысли:

А как вообще заранее понять, сколько ресурсов будет потреблять сервис под нагрузкой?

Сколько памяти съест приложение? Когда упрется в CPU? Как поведет себя БД при разном кол-ве запросов?

Чтобы ответить на эти вопросы, я написал небольшую библиотеку для локального нагрузочного тестирования на Java Virtual Threads. Она запускает большое количество задач, собирает метрики и формирует отчет - прямо в консоли или в CSV.

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

Давайте попробуем еще раз, в прошлый раз как-то не задалось, но много воды утекло с тех пор. Проект начался как простой способ "заглянуть в БД сервера" собственно таким он и остается до сих пор. Но по мере развития ИИ в нем появились новые фишки.

Как гласит слоган на главной странице: Panopticum — место, откуда видно всё. Собственно я старался сделать его именно таким, чтобы можно было посмотреть и проверить как можно больше из одного места, желательно с одинаковым интерфейсом.

Сначала я просто начал наращивать количество коннекторов. И если сначала это было четыре вида БД, потом шесть, то теперь это 26 разных БД, логи из Kuberneties и просмотр S3 бакетов.

Мы с коллегой делали выпускной проект для курсов CloudJava и CloudJava K8S. Это техзадание на бэкенд распределенной системы - четыре микросервиса, Gateway, обвязка. Изначально оно было доступно только участникам курсов, теперь решили открыть бесплатно, без регистрации или “оставьте email”. Просто страница с текстом и тремя OpenAPI-спеками.

Ссылки сразу, чтобы не листать:

Описание проекта: https://javaops.ru/view/cloudjava3

Само ТЗ: https://javaops.ru/view/cloudjava3/rescue-service.html

Вы пробовали что-нибудь кроме new Thread() ?

Конечно пробовали: Future !

И всё ?!

Разберемся с разными моделями конкурентности в Java, Kotlin, Scala/ZIO и Clojure: у всех JVM под капотом, но подходы разные. Начнём с разбора тредов, пулов, virtual threads из Project Loom и Structured Concurrency. Дальше: корутины, fibers, ZIO runtime и Clojure.

В новом переводе от команды Spring АйО рассмотрим выход Spring Boot 4 и Spring Framework 7. InfoQ взяли интервью у core команды Spring с целью узнать, куда движется самая популярная в Java экосистема.

Spring Boot 4 модуляризировал автоконфигурацию. Теперь при запуске проверяется меньше классов в classpath, а uber-jar будет более компактным: будут подключаться только нужные модули. Параллельно Spring Boot 4 переходит на Jackson 3, но добавлен модуль совместимости с Jackson 2, потому что экосистема ещё догоняет.

Spring Framework 7 тащит core resilience в ядро: RetryTemplate, @Retryable и @ConcurrencyLimit доступны без отдельной зависимости. @Retryable работает и с реактивными типами (через Retry из Project Reactor); для обычных вызовов используется RetryTemplate с политикой retry/backoff. @ConcurrencyLimit помогает ограничивать доступ к ресурсу, что особенно полезно с Virtual Threads.

Хабр, привет!

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

Типичная защита периметра: «свои» внутри, «чужие» снаружи. Но бывает инверсия. Заказчик открывает SAP NetWeaver AS Java в большой мир. SAML в этой системе активируется быстрее, чем вы моргнете — буквально в два клика. Но если на том конце провода не дремлет злоумышленник, а у вас нет 2FA… считайте, что ключи от дома вы спрятали под ковриком.

Мы столкнулись с этой болью на проекте у одного из заказчиков. Нужно было настроить двухфакторную аутентификацию. И вот тут начались нюансы.

В этом материале мы опишем настройку интеграции портала SAP NetWeaver AS Java с внешним Identity Provider (IdP) — Keycloak — с реализацией двухфакторной аутентификации (2FA). До нашего вмешательства аутентификация происходила напрямую в SAP-системе.

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

Далее кратко рассмотрим процесс настройки и разберем возникшие проблемы.

Небольшая команда сделала мод-социальную-сеть для Minecraft, который объединяет в общий граф друзей игроков на любых поддерживаемых версиях клиента — от 1.7.10 до 1.21.1. Поддерживаются три популярных загрузчика модов и любые клиенты Minecraft, как лицензионные, так и офлайн. Серверная часть, веб-админка, обвязка и документация — всё своё.

Главное, что хотелось рассказать: дисциплина (не скорость) была решающим ресурсом, и категория продукта изменила правила игры настолько, что классическая формула «MVP на одной версии — потом расширяемся» оказалась контрпродуктивной.

Всем привет, меня зовут Михаил, я back-end разработчик в ОТП банке. Сегодня хочу рассказать о профдеформации - о том, как разработка перестраивает мозг без спроса.

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

И знаете что? Это не лечится.

Дальше - несколько моих личных симптомов. Пишите в комментариях свои, уверен, что у каждого такое было!

Это не совсем привычная для меня статья, но я давно хотел поделиться одним своим наблюдением. В ней не будет никаких вещей, связанных непосредственно с разработкой на Java или Kotlin, не будет кода. Я просто решил поделиться опытом. Я надеюсь, читать эту статью Вы будете вечером, в спокойный, выходной день.

Ну что же, поехали.

Я предполагаю, что Spring АйО читают в основном Java или Kotlin разработчики. В том или ином виде, Java / Kotlin разработчики часто пишут какие-то Enterprise решения. Одной из отличительных особенностей enterprise является сложная доменная область. Если Вы хотя бы какое-то время писали Enterprise бекенд, то я думаю, для Вас это не новость.

Как обучить работе с тренажёрами АЭС группу из 30 человек в Индийском технологическом институте Бомбея (IIT Bombay), если половина аудитории впервые слышит про атомную энергетику, а другая половина уже готова моделировать аварийные ситуации?

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

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

Наблюдая за тем, как ИИ внедряется на работе и дома, я всё чаще ловлю себя на простой мысли: всё труднее писать код самому и всё больше хочется делегировать ИИ. Да ещё и провайдеры ИИ призывают тратить больше токенов, руководители всё чаще призывают команды активнее пользоваться ИИ. В соцсетях регулярно попадаются шуточные видео про то, как CEO предлагает потреблять токены ради самого потребления, а в крупных компаниях уже идёт негласное соревнование: кто больше использует AI‑инструменты, кто больше автоматизирует, кто быстрее покажет, что «мы тоже в игре».

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

Когда AI-агенту дают только stack trace и текст файла с упавшим тестом, он часто чинит симптом, а не причину. Тест зеленеет, баг переезжает в master, через неделю всплывает в другом месте. На простых багах это незаметно, на нетривиальных — становится правилом.

В этой статье — что меняется, если вместо stack trace дать агенту сжатый трейс выполнения, собранный на стороне IDE. Три бага из реального кода, эвристики сжатия трейса, склейка многопоточных вызовов по timestamp и цифры на датасете BugSwarm Pro для DeepSeek V3.2 и проприетарных LLM.

Статья пригодится, если вы:

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

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

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

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

Главное в Veai 5.10 – скиллы теперь подхватываются из dot-директорий других ассистентов. В чат добавили быструю документацию по ссылкам на код.

Запуск и получение конфигураций в Rider

До Veai 5.10 в C#/.NET-проекте нужно было просить агента прогнать тесты в модуле или собрать проект. Агент шёл в терминал и пытался угадать команду: какой dotnet, какой TFM, какой фильтр и какой путь к csproj. На монорепо с несколькими SDK и global.json это регулярно заканчивалось exit code 1 и попыткой починить рабочий код.

Практический разбор того, как я вынес security-проверки Java-проектов из разрозненных CI/CD-скриптов в переиспользуемый Gradle plugin

wkhtmltopdf долгое время был одним из основных инструментов для генерации PDF из HTML. Мы столкнулись с ним на собственном проекте, но, когда потребовалось реализовать сложные макеты, колонтитулы и повторяющиеся заголовки в многостраничных документах — возникли проблемы.

В этой статье — краткий обзор альтернатив (Headless Chrome, Puppeteer, Playwright, WeasyPrint, Gotenberg), их плюсы и минусы, а также наш итоговый выбор и подводные камни, которые всплыли в процессе внедрения.

Единый плагин для сканирования на безопасность Java проектов. Maven. Или как проверять кучу микросервисов на безопасность управляя этим в одном месте

Когда документов и партнёров стало много, модель «один кейс — один шаблон» начала мешать даже простым правкам. Рассказываю, как мы вынесли композицию, версии и публикацию в отдельный backend-слой поверх BIRT, чтобы бизнес мог менять PDF-полисы без постоянного участия разработки.

Всем привет! Меня зовут Илья Григорьев, я старший бэкенд-разработчик в команде Телемоста. В этой статье я разберу наш опыт разработки двух фич последнего года — ИИ-конспект с Алисой Про и облачной записи на Диск. Покажу, как мы проектировали их архитектуру, почему не всё получилось с первого раза, с какими системными и техническими ограничениями столкнулись при работе с медиаданными и как в итоге выстроили пайплайн их обработки и анализа.

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

На этой неделе прошёл JPoint 2026, вышел Amplicode 2026.1 со Spring Agent Toolkit, а Anthropic впервые обогнала OpenAI по оценке на вторичном рынке. Плюс история о том, как AI-агент удалил продакшн-базу данных за 9 секунд.

За несколько лет работы я сменил несколько проектов и команд. Стек менялся: где‑то был Kotlin, где‑то классическая Java, где‑то вообще старый монолит на виртуалках.

Но самое сильное различие было не в технологиях.

Всё решали люди, которые руководят разработкой.

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

И самое неожиданное — один из них, при всех своих минусах, оказался для меня полезнее остальных.

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

Heap‑дампы JVM — бесценный источник информации при разборе аварий с OutOfMemory и оптимизации производительности. Но вместе с тем они же — потенциальные каналы утечки данных, ведь будучи снятыми с боевого сервиса, дампы уносят в себе всё, с чем работал сервис на момент снимка: логины, пароли (иногда в открытом виде), важные ID и тому подобное — словом, всяческие sensitive данные, которые не нужны для анализа, но могут навлечь на получателя дампа серьёзную ответственность и риски. Как этого избежать без ущерба делу — разбираемся под катом.

Всем привет! 👋👋👋👋👋

Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

В этом выпуске рассказываем, когда ждать релиз Java 27 и как Oracle планирует регулировать использование генеративного ИИ при написании кода. Посмотрим детальное интервью о Spring Framework 7 и Spring Boot 4 с самой командой создателей Spring. Почитаем, как безопасно работать с нативной памятью в многопоточной среде с помощью VarHandle. А еще изучим любопытный постмортем, посвященный расследованию раздувания памяти в контейнерах после перехода на JDK 17. Приятного чтения!

LLM пока не может хорошо обращаться с Е2Е автотестами потому что для этого нужно провести целый комплекс мероприятий. Сложность возникает уже на этапе запуска такого автотеста. В отличии от юнит автотестов, Е2Е автотесты почти всегда PageObject и целый проект со своей архитектурой на базе Selenium Appium Espresso и тд.

Всем привет, меня зовут Антон Рыбочкин, я старший разработчик бэкенда в команде Yandex Monium. Monium — это платформа для сбора, хранения и анализа телеметрии (метрик, логов и трейсов). Она позволяет дать оценку того, как себя чувствует сервис, находить причины сбоев, оперативно уведомлять об аномалиях.

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

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

Продолжаем разбирать HikariCP: как выбирать размер пула, что учитывать в Kubernetes и при нескольких сервисах, почему большой maximumPoolSize не всегда помогает, какие настройки стоит пересмотреть перед продом и какие ошибки чаще всего приводят к проблемам с базой.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Сегодня я хочу поделиться историей создания одного интересного проекта — клиента для облачного сервиса Ollama.