Еще пару лет назад разработчики на Java в основном обсуждали новые инструменты для создания программ, особенности архитектуры приложений и способы сделать сервисы быстрее и надежнее. Сегодня к этим темам добавился еще один важный вопрос — как искусственный интеллект меняет профессию программиста. Именно с этого началась пятая встреча в рамках MTC Web Services (MWS) Meetup, которая собрала в Москве Java-разработчиков, архитекторов и инженеров.
Вместо привычной серии докладов организаторы открыли вечер большой дискуссией о том, как меняется современная разработка, чему теперь стоит учиться, какую роль играют ИИ-ассистенты и как их использование влияет на безопасность решений. Обо всем этом — в материале.
Дискуссия про тренды и санкции
Встреча стала не просто площадкой для обмена опытом — она отразила запрос сообщества на понимание глобального вектора развития индустрии. В условиях санкционных ограничений и ухода зарубежных вендоров Java-экосистема в России переживает трансформацию. Компании вынуждены менять подходы к разработке и инфраструктуре, искать альтернативы привычным решениям и адаптироваться к новой реальности.
Один из самых обсуждаемых в кулуарах трендов — постепенный переход со Spring на Quarkus. Этот инструмент привлекает разработчиков меньшим потреблением памяти и более быстрым временем запуска, что особенно важно для облачных сервисов и приложений, построенных на микросервисной архитектуре. Участников интересовал не столько сам инструмент, а куда движется экосистема, какие технологии набирают вес, а какие уходят в прошлое.
Важно, что эти изменения происходят на фоне активного внедрения ИИ, что создает двойной вызов для Java-сообщества. С одной стороны, нужно осваивать новые технологии и адаптировать архитектуру. С другой — учиться работать с нейросетями, которые меняют сам процесс разработки. Именно эти две линии и определили повестку встречи.
Организаторы также отметили, что интерес к мероприятиям такого формата только растет. Всего в рамках серии MWS Meetup запланировано 12 встреч, каждая из которых будет посвящена отдельным аспектам разработки — от инфраструктурных решений до управления командами. Это позволит участникам глубже погрузиться во внутреннюю кухню создания надежных и производительных систем.
Почему разработчики перестали бояться сложных задач
Одной из главных тем обсуждения стало использование генеративного ИИ в повседневной работе разработчиков. Участники дискуссии отмечали, что если раньше нейросети в основном использовали как замену поисковым системам, то сегодня они становятся полноценными помощниками при разработке. ИИ помогает быстрее разобраться в незнакомом проекте, проанализировать код, найти возможные ошибки и предложить варианты решения технических задач.
При этом Николай Кузнецов, ведущий разработчик в Sense, подчеркнул, что ИИ пока нельзя воспринимать как самостоятельного инженера. Его задача — ускорять работу человека, а не принимать решения вместо него.
В свою очередь, Олег Маслов, старший разработчик MWS Big Data, поделился своим опытом использования нейросетей. Он рассказал, что главный эффект от внедрения ИИ — это исчезновение страха перед новой задачей. По его словам, раньше, когда перед ним стояла сложная задача с большим количеством незнакомого контекста, было психологически тяжело даже начать. Теперь он просто загружает информацию в ИИ, и тот помогает разобраться, что значительно снижает порог входа.
Маслов также отметил, что искусственный интеллект стирает границы между специализациями. Если раньше разработчик брался за задачи в областях, где у него раньше не было компетенций, то теперь ИИ выступает в роли наставника и помогает пользователю в решении задач.
Такой подход меняет привычную роль разработчика. Теперь он не столько пишет код, сколько ставит задачи нейросети и проверяет результаты. Это смещает фокус с написания кода на управление нейросетью, и это становится одним из главных изменений в профессии.
От написания кода — к созданию спецификаций
Еще одна тенденция, о которой говорили участники дискуссии, — изменение самого процесса разработки. Как отметил руководитель команды разработки MWS «МТС Аналитика» Александр Бобряков, все чаще программисты начинают работу с подготовки подробной спецификации будущего решения — описания требований, архитектуры и ожидаемого результата. Уже на ее основе ИИ помогает сгенерировать программный код.
Бобряков объяснил, что ключевое изменение заключается в смещении фокуса. Раньше команда работала в итеративном режиме, подбирая нужный код через диалог с нейросетью. Теперь же они тратят время на создание качественной спецификации, которая служит основой для дальнейшей разработки. Код при этом становится вторичным — его можно переписать или сгенерировать заново, но спецификация остается единым источником информации для всех членов команды.
Получается, что в новой реальности инженер все больше напоминает архитектора или аналитика, который проектирует систему на уровне требований.
Где нейросети ошибаются и почему
Практически все участники дискуссии сошлись во мнении, что полностью заменить инженера нейросети не способны. ИИ действительно ускоряет разработку, однако он может ошибаться, предлагать неоптимальные решения или не учитывать особенности конкретного проекта.
Кузнецов рассказал, как нейросети помогли ему освоить язык Go на реальных рабочих задачах. Он консультировался с чат-ботом по архитектурным подходам и паттернам. При этом, по его словам, ни одного негативного инцидента в рабочей среде не произошло — и это заслуга не ИИ, а команды. Все его задачи проходили тщательную проверку кода, и именно опытные коллеги обеспечивали итоговое качество.
Именно контроль кода и коллективная ответственность остаются главным барьером против ошибок. ИИ ускоряет, но не заменяет инженерное мышление и способность принимать ответственные решения. Из этого следует вывод, что даже простые механизмы требуют глубокого понимания системы.
Почему простая функция сложнее, чем кажется
После дискуссии состоялся доклад ведущего разработчика MWS Петра Деменева, посвященный одному из самых распространенных механизмов повышения надежности распределенных систем — Retry Policy.
Идея заключается в том, что, если операция завершилась ошибкой, достаточно повторить ее еще раз. Однако именно такая простота часто становится причиной серьезных проблем.
В качестве примера Деменев привел систему оплаты: если на уровне кода разрешить автоматический повтор, пользователь может случайно заплатить дважды. По его словам, такая ситуация — серьезная проблема, которую необходимо предотвращать на этапе проектирования.
Аналогичные сложности возникают при работе с базами данных, очередями сообщений и взаимодействием между микросервисами. Поэтому при внедрении Retry Policy инженеру приходится отвечать на множество вопросов, включая то, какие ошибки действительно стоит повторять, сколько попыток выполнять, как избежать дублирующихся операций и что делать, если ошибка так и не исчезла.
Отдельное внимание спикер уделил распространенной ошибке — попытке повторять абсолютно все исключения. На практике разные ошибки требуют разных сценариев обработки, поэтому перед внедрением механизма приходится анализировать реальные причины сбоев.
Еще одной важной мыслью доклада стало то, что ни одна библиотека не способна полностью заменить понимание внутренних процессов системы. Иногда собственная реализация оказывается проще и надежнее готового инструмента, особенно если проект предъявляет специфические требования.
Даже такой простой на первый взгляд механизм, как повтор попыток, требует глубокого понимания системы. Готовые библиотеки упрощают жизнь, но не освобождают от ответственности за архитектурные решения. Аналогичная логика работает и в вопросах производительности.
Как незаметные ошибки убивают производительность
Закрыл техническую программу приглашенный эксперт Семен Киреков, старший backend-разработчик «Авито», с докладом о производительности Spring Data JPA. Главная идея выступления заключалась в том, что большинство проблем производительности возникает не из-за сложных алгоритмов, а из-за привычных конструкций, которые выглядят совершенно безобидно.
В качестве примера спикер разобрал ситуацию с загрузкой связанных коллекций данных. Решение, по словам Кирекова, не всегда требует сложной оптимизации. Иногда достаточно изменить порядок получения данных, разбить один большой запрос на несколько более простых или иначе организовать структуру сущностей.
Еще одной темой стала знаменитая проблема N+1, когда приложение вместо одного запроса выполняет десятки или сотни дополнительных. Спикер отметил, что подобные ошибки часто остаются незамеченными на этапе разработки и проявляются только под высокой нагрузкой. Поэтому разработчикам важно регулярно тестировать производительность своих сервисов, а не полагаться исключительно на корректность кода.
Безобидные на первый взгляд конструкции могут привести к колоссальным проблемам под нагрузкой. Производительность нужно проверять не в теории, а на практике, и делать это систематически — так же, как и любой другой аспект надежной разработки.
Не только доклады
Помимо актуальных тем, организаторы позаботились не только о содержательной части, но и о настроении гостей. Между докладами для зрителей провели интерактивную игру: ведущая зачитывала загадки про ИТ-термины, а участники угадывали ответы. Те, кто давал правильные ответы, получали призы — фирменный мерч от МТС.
Особенно отличились те, кто подходил к заданию творчески — например, загадывал термины в стихах. В конце вечера организаторы даже поблагодарили одного из гостей за то, что он «разрядил обстановку и вернул всех с небес на землю» после глубоких технических дискуссий.
Живой интерес к мероприятию подтверждает и статистика участия: офлайн-мероприятие посетили 80 человек, а к онлайн-трансляции подключились 52 зрителя.
Итоги мероприятия
В условиях санкционных ограничений и изменений технологического ландшафта сообщество активно ищет новые пути развития. Внедрение ИИ в разработку теперь норма, и команды, которые эффективно используют нейросети, выигрывают за счет пересмотра процессов: они больше времени тратят на спецификации, тщательнее проверяют код и активнее обмениваются знаниями внутри команды.
Гости и спикеры сошлись на мнении, что без качественного код-ревью, понимания предметной области и ответственности каждого члена команды на каждом из этапов, использовать нейросети буквально небезопасно.
Ну а совсем скоро пройдет следующий митап из цикла про тренды и особенности современной разработки. Следить за новостями можно в сообществе МТС True Tech или на сайте.
