Расписание

В докладе мы разберем несколько типовых кейсов, в которых veai агент и платформа вызывают LLM для решения «нечетких» задач, а после доклада слушатели унесут с собой конкретные подходы, основанные на продакшен-кейсах.

Посмотрим, как обстоят дела с FFM API (Project Panama) в 2026 году, как на своем опыте взаимодействия с большими нативными библиотеками вроде Catboost, так и на более гранулярных, но от этого не менее практических примерах вроде своих биндингов к libc.

Расскажем и покажем, как работает под капотом гибридная модель компиляции кода JIT + AOT в Android Runtime и какой профит она дает в реальных приложениях. Сравним решение от Google с проектом Leyden в большой Java.

В этом докладе мы разберем виртуальные потоки Java не как feature, а как инженерное решение.

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

Как Java 25 с FFM API научилась управлять железом без единой строчки C: разбираем эволюцию архитектуры open-source проекта Pi4J: от JNI/JNA до чистой Java, границы применимости, тайминги и память — с бенчмарками и демо на реальных датчиках.

Разберем разные модели конкурентного программирования.

Про Elasticsearch как поисковый движок можно долго спорить. А вот для хранения метрик он оказался неожиданно неплох: расскажу, как мы запустили TSDS под нагрузкой более миллиона метрик в секунду, с какими проблемами столкнулись и почему в итоге пришлось лезть внутрь Elasticsearch и Lucene. Часть наших изменений в downsampling уже попала в upstream и вышла в релизе 9.5.0.

Посмотрим на эволюцию JVM сквозь призму закрытия архитектурных дыр. На примере фреймворка сериализации one-nio мы совершим археологическую раскопку: от Unsafe, MagicAccessorImpl и синтетических аксессоров до современных механизмов — VarHandles, Nestmates и Hidden Classes.

E2E-бенчмарк, красивые графики, внушительный RPS и первое место в таблице легко создают ощущение, что технология объективно быстрее конкурентов. Но что именно показывает E2E-бенчмарк? Поговорим о том, почему не стоит верить красивым показателям производительности и почему такие бенчмарки полезны, но опасны при буквальном чтении.

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

...но так, чтобы никто не заметил.

На JVM Language Summit 2025 года Брайан Гётц рассказал о планах добавить в язык Java классы типов. Доклад основан на рассказе Брайана, так как другой информации по этой теме очень мало, но это не просто пересказ.

Разбираем:

— как профилирование работает под капотом

— какие различия и сходства у инструментов профилирования Java и натива

— специфику профилирования в облаке

Как на Koog'е набросал Kotlin Script с простым агентом. Умом он не блещет, но простой и управляемый: кодом иногда проще объяснить задачу, чем словами.

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

Почему Context Engineering становится новой инженерной дисциплиной, как AI меняет весь жизненный цикл разработки (AI PDLC) и какие компетенции будут определять сильного инженера в ближайшие годы. 

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

Я решил проверить: а что изменится в моей работе, если дать AI-агенту те же инструменты, которыми пользуется сам разработчик: IDE, LSP и базу знаний проекта?

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

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

Расскажу, как заставить агентов создавать UI по гайдам.

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

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

В этом докладе я хочу показать на своем примере и порассуждать о том, какую часть работы берет на себя менеджмент и как можно реально ускорить delivery-процесс.

Мы исполним Шариков-блюз (может быть, и буквально!), чтобы раскрыть сложные аспекты современного понимания обусловленности технологических систем социальными, экономическими и культурными аспектами.

В реальности с ИИ выживут только инженеры: те, кто не отдают свое мышление полностью машинам и остаются субъектами решений, а не операторами интерфейсов.

Доминирующая парадигма развития LLM-систем предполагает, что рост качества решений линейно связан с ростом мощности (и стоимости) базовой модели.

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