Профессиональная конференция
для Go-разработчиков
и их руководителей

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

В программе:

✦ Доклад о подсказках для AI-агентов. Расскажем, как правильно кормить AI контекстом, чтобы он выдавал что-то осмысленное, а не «вот код, но он не скомпилится». И с чего вообще начинать внедрение — без фанатизма и попыток переписать все в первый же день.

✦ Мастер-класс по AI в больших проекта. Как применять AI не в пет-проектах, а в настоящей разработке, где есть legacy, code style, безопасность и прочие «радости жизни». Спойлер: просто скопировать из ChatGPT не получится.

✦ Кейсы внедрения. Ребята, которые уже пересмотрели процессы под AI, расскажут, что у них получилось, а что пошло не так. Без причесанных историй успеха — только реальный опыт.

✦ Дискуссия: «А оно нам надо?» Пытаемся честно посчитать экономику. Зовем тех, кто строит локальные фермы с LLM, — пусть расскажут, во сколько на самом деле обходится это счастье. И главный вопрос: есть ли смысл во всей этой движухе или старый добрый «ручной» код все еще рулит? И главное — AI для всех или все-таки для избранных?

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

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

В программе:

✦ Разбор кейсов участников. Обсудим, как донести необходимость рефакторинга, убедить руководство декомпозировать монолит и аргументировать коллеге выбор библиотеки без конфликтов. Форматы работы:

Групповое обсуждение кейсов в мини-группах;

Дискуссия экспертов на сцене с разбором проблемных ситуаций от участников.

✦ Алгоритмы эффективной коммуникации. Практические подходы к ведению переговоров и достижению договоренностей в технической среде.

Миссия платформы — сделать жизнь разработчика лучше. Удобнее, быстрее, стандартизированнее. Чтобы не писать одно и то же руками, чтобы не гадать, как тут принято деплоить, и чтобы инфраструктура не отвлекала от фич.

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

О чем поговорим:

✦ Дискуссия: «Почему хорошей платформы никогда не будет?»

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

✦ Где искать компромисс?

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