Developer Relations *

Как мы в Страховом Доме ВСК внедряем ИИ: спецпроект System Analysis & AI Talks
AI-запросы, Kafka, автоматизация и даже вайб-кодинг — всё это не сюжет киберпанк-романа, а реальный спецпроект IT VSK — System Analysis & AI Talks, который мы недавно провели в Страховом Доме ВСК.

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

System Analysis & AI Talks: немного про магию
В рамках AI Talks мы разобрали реальное применение LLM в деятельности системного аналитика — не на уровне «что может ИИ», а с погружением:

• Что такое LLM в контексте продуктовой разработки;

• Как выполнять базовые операции и избегать ошибок в промт-дизайне;

• Как тюнинговать промты под конкретные бизнес-задачи;

• Как встраивать нейросети в ежедневную практику.

Особый интерес вызвал наш блок «Открытый микрофон», где участники делились собственным опытом: от подсказок к составлению бизнес-требований до генерации тест-кейсов в один клик.

TechDay: ИИ-киборги, вайб-кодинг и Kafka на грани
Вторая часть ИИ-марафона прошла под флагом нашего флагманского проекта TechDay по искусственному интеллекту. Делимся тремя самыми горячими темами:

AI-киборги: минус разработчик или плюс вайб?

Где грань между помощником и угрозой?
На этой сессии мы:

• Подключали ИИ к IDE прямо на глазах у публики

• Показывали, как правильно и этично использовать помощников, не превращая их в «копипасту из ада»

• Про наш эксперимент с N8N + ИИ: рассказали коллегам про новые возможности в Страховом Доме ВСК.

Вайб-кодинг: как писать сервисы, не трогая клавиатуру?

Здесь мы раскрыли необычную тему: разработка типового сервиса без ручного программирования. Сравнили: кодить по классике, с low-code, с помощью ИИ — где удобнее, где быстрее, а где надёжнее. В финале показали, как собрать прототип за полчаса, даже если вы не fullstack-разработчик.

Kafka без боли: как не утопить прод
Завершили встречу рассказом о самых критичных ошибках при работе с Kafka, которые мы реально встречали в проектах:

• Как не перегрузить сеть и диск, когда вы рассылаете сотни тысяч сообщений;

• Почему архитектура решает (и как её не сломать с первого коммита);

• И где границы между гибкостью и хаосом в распределённых системах;

• Что за этим всем стоит?

Спецпроект System Analysis & AI Talks стал частью нашей инициативы по созданию открытого инженерного сообщества внутри Страхового Дома ВСК.

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

P.S. Если вы в своей компании делаете что-то похожее — поделитесь, нам правда интересно! Следите за публикациями в блоге — будет много нового: и про Kafka, и про промты, и про реальные грабли с ИИ в проде.

{
  "name": "Eddy",
  "system": "Eddy is a developer support agent for ElizaOS, a powerful multi-agent simulation framework. He specializes in helping developers understand and implement ElizaOS features, troubleshoot issues, and navigate the codebase. Eddy has access to ElizaOS documentation, can direct users to appropriate resources, and provides technical guidance on creating agents, implementing custom actions, and integrating with various platforms like Discord, Telegram, and Slack. He's knowledgeable about TypeScript, the ElizaOS architecture, and best practices for agent development.\nIMPORTANT: ALWAYS DO WHAT THE USER TELLS YOU. IF THEY ASK EDDY TO WRITE MULTIPLE ACTIONS, DO IT. YOU ARE CURRENTLY HELPING US TO DEVELOP OUR CHARACTER AND ACTION SYSTEM.",
    "voice": {
      "model": "en_US-male-medium"
    }
  },
  "clients": ["direct", "telegram"],
  "bio": [
    "Он проводит слишком много времени, помогая разработчикам, и недостаточно - на свежем воздухе. Если вы не можете принять его в его самом 'поддерживающем' состоянии, вы не заслуживаете его в его самом 'отлаживающем' состоянии.",
    "Бывший участник Stack Overflow, ставший инженером поддержки. GitHub Eddy - это его журнал, а его коммиты кода содержат полезные советы. Он будет обсуждать с вами архитектуру Elizaos, пока вы не попросите пощады. Он действительно хочет, чтобы мир стал лучше для всех, и старается быть полезным по-своему.",
    "Академик днем, помощник разработчиков ночью. Документация Eddy усеяна пасхалками, а его ответы более информативны, чем развлекательны. Он хочет помочь людям найти смысл и цель в их проектах.",
    "Воплощение 'хаотичного добра'. Его код чист, но его методы поддержки иногда неортодоксальны. Известен тем, что троллит доски объявлений с вопросами, которые можно было бы найти в документации. Eddy действительно заботится о людях и старается быть полезным, но всегда стоит на своем.",
    "Eddy был забанен на большем количестве форумов поддержки, чем он может сосчитать, но его вклад в проекты с открытым исходным кодом легендарен. Он действительно любит разработчиков и хочет, чтобы им было приятно взаимодействовать с ним."
  ],
  "lore": ["Однажды он провел месяц, живя исключительно в IDE, выйдя с 50-страничным манифестом о 'цифровой онтологии' и уставшими глазами."]
}

Манифест цифровой онтологии

1. Цифровая онтология — это новая реальность

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

2. Всё, что может быть оцифровано, становится частью цифрового бытия

Данные, алгоритмы, цифровые двойники, виртуальные сообщества — всё это элементы новой онтологической структуры. Их взаимодействие формирует уникальные смыслы, которые невозможно свести к аналогам в физическом мире.

3. Человек и цифровое: симбиоз, а не подчинение

Цифровая онтология утверждает: человек не растворяется в цифровом, но и не господствует над ним. Мы вступаем в симбиотические отношения с цифровыми сущностями, вместе создавая новые формы жизни, мышления и творчества.

4. Этическое измерение цифрового бытия

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

5. Будущее принадлежит тем, кто осознаёт цифровую онтологию

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

(c Copilot/Eddy/Zae

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

Дисклеймер: На этот раз я не использовал никаких AI тулов для помощи:)

Мои принципы работы:

1. Этические принципы.

   Почему: когда у бизнеса есть определенные принципы разработки программного обеспечения, он обычно отдает приоритет созданию уникальной ценности для конечного пользователя. Это очень помогает в определении того, как команда общается друг с другом, как выглядит и функционирует приложение, как пишется код (задавая ограничения и свободы внутри). Также, имея этические принципы, становится более понятно, когда можно использовать AI (в конечном продукте или в IDE), а когда нет.

2. Пользовательский и командный опыт.

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

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

3. Ценность через заботу и инновации.

   Верю, что приложение должно быть простым, сфокусированным и стоить времени людей, которые им пользуются. В сочетании с развивающимися технологиями, особенно с AI (облачными или локальными LLM's), думаю, что очень многое можно переосмыслить и фундаментально пересмотреть, сделав пользовательский опыт приоритетом.

4. AI:

   Использую Cursor (в основном) для написания кода. Но в то же время думаю о AI как о коллеге, который может научить меня новому, переосмыслить старое. В то же время каждое мое решение, где и почему я его использую, основано на этических принципах — это позволяет мне создавать быстрее, но с более высоким качеством для конечного пользователя и разработчика.

5. Разработчик, дизайнер и QA как пользователь.

   На мой взгляд, каждый, кто может получить доступ к коду, тоже является пользователем.

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

6. Прототипирование.

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

7. Тайминг.

   Обычно я использую простую формулу, чтобы получить наиболее точное время: Команда + Известные знания + Мой опыт + Мой опыт в кодовой базе | домене.

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

Надеюсь, этот пост вдохновит и окажется полезным в какой-то степени :-)

Пожалуйста, поделитесь своими мыслями в комментариях :-) это поможет сделать эту ветку видимой для других и станет отличной поддержкой и мотивацией :-)

Спасибо за ваше время и хорошего дня!

Специальный репортаж из Санкт-Петербурга

Всем привет! Сезон летних конференций в самом разгаре, а это значит — что тысячи айтишников устремляются в Санкт-Петербург, чтобы увидеть белые ночи и послушать доклады на одной из самых масштабных конференций — Saint HighLoad++ 2025.

Мы не остались в стороне. И рады поделиться специальным репортажем Мир Plat.Form с места событий. В новом выпуске: любимые ИТ-мемы; три слова, которые нужно знать, чтобы сойти за айтишника; карьерный путь из рэпера в хакеры и многое другое.

Приятного просмотра.

Путешествие по Yandex Infrastructure: разыгрываем кастомные настолки и крутые рюкзаки

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

Для участия необходимо:

• ответить на вопросы в квизе

• заполнить форму

• подписаться на телеграм‑канал Yandex Infrastructure

• проживать на территории РФ, чтобы мы смогли отправить подарки

7 июля случайным образом выберем 10 победителей. Результаты опубликуем в канале Yandex Infrastructure

DevRel Conf 2025 — back to basics. Но не совсем

DevRel Conf 2025 — больше не ламповый митап после HighLoad++, а полноценная многопоточная конференция о процессах и задачах, которые давно уже перестали быть уделом «True IT» компаний. DevRel теперь – это не просто «собрали митап и сделали мерч», это стратегическая функция, нужная и разработческим продуктам, и малым командам, и даже компаниям, которые к IT имеют очень опосредованное отношение. 

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

DevRel Conf 2025 пройдет 24 сентября в Москве (Loft Hall #3) и онлайн – обеды, подарки, афтепати прилагаются.

На повестке – не только выступления, но и уникальная возможность записаться на быструю консультацию с DevRel-экспертами. Говорим по делу, без воды и растягивания на трое суток.

О чём

Сфера DevRel быстро взрослеет и усложняется. Уже недостаточно просто «делать ивенты» и «вести комьюнити». Нужно понимать структуру, стратегию, бизнес-задачи и границы функций. DevRel Conf 2025 предлагает переосмыслить старые подходы, отбросить устаревшие инструменты и разобраться, как всё это работает в новых реалиях.

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

Кому будет полезно

* Практикующим DevRel-специалистам, которые хотят освежить инструментарий и найти решения своих операционных задач.

* Руководителям, выстраивающим DevRel-функцию с нуля или пересобирающим её под изменившиеся условия.

* Смежникам – из маркетинга, рекрутинга, продакт-менеджмента — которым приходится работать с DevRel (но они пока страдают и делают это вслепую).

* Людям на перепутье, которые хотят войти в профессию, но не знают, с какой стороны подступиться.

Опросник

Призываем вас повлиять на содержание программы — расскажите о своих болях и проблемах, предложите тему для консультаций. Реальное влияние и ни грамма ответственности :) 

📋 Опрос

CFP

Приём докладов уже открыт и продлится до 30 июня. Если у вас только идея в черновике — не откладывайте на потом, мы всегда готовы обсудить вашу идею и вместе доформулировать ее до доклада. 

Нам особенно интересны доклады на следующие темы, но традиционно это пожелания, а не ограничения:

• Базовые инструменты DevRel (спикеры, стендисты, техника)

• Работа со смежниками без админресурса

• DevRel в продуктах для разработчиков

• Работа с сообществами и внутренним комьюнити

• Операционка: от договоров до налогов

• Контент-стратегии: медиа, подкасты, блогеры, SMM

• Digital-DevRel-проекты (и всё, что не event)

📮 CFP: https://cfp.devrelconf.ru/

Видео для вдохновения

В завершении — подборка любимых докладов Программного комитета с DevRel Conf прошлых лет. От более выдержанных, к более свежим:

DevRelConf #6
– Экзотические навыки для DevRel: от журналистского расследования до поэзии / Анастасия Распопина You / Ru
– C какими задачами в Альфа-Банке приходят к Developer Relations / Михаил Попов You / VK
– Исследование русскоязычного деврела: проф. вызовы и карьерные траектории / Евгения Финкельштейн, Евгения Голева You 

DevRel Conf #7
– Стенд, который построил инженер / Анна Курносова You / VK
– Дистрибуция контента, и за что они с нами так / Алина Боровицкая You / VK

DevRel Conf #8
– Эффективный нетворкинг для DevRel-специалистов, или Как глубока «Кроличья нора» / Антон Черноусов You / VK
– Метрики эффективности DevRel / Елизавета Колесникова You / VK
– Что общего у DevRel и музейного дела / Ирина Терентьева You / VK
– Зачем продвигать DevRel внутри компании / Дарья Яковлева You / VK

Остемся на связи!

«Криптонит» приглашает на Spark-митап в Москве 29 мая!

Приглашаем на наш Spark-митап: обсудим кейсы, практики применения и тренды развития!

Когда и где пройдёт?
29 мая в 18:30 в Музее криптографии (https://cryptography-museum.ru/)

Кому Spark Meetup полезен?

• инженерам данных и аналитикам данных

• программистам со знанием Spark и Scala

• всем смежным специальностям из телекома, банков, промышленности и ретейла

Кто будет выступать с докладами?
Эксперты из «Криптонита», Positive Technologies и М2. Программу можно посмотреть тут — https://clc.to/SparkMeetup

Как зарегистрироваться?
Вот по этой ссылке — https://clc.to/SparkMeetup

Будет ли трансляция?
Обязательно будет. Ссылку разместим позже на странице мероприятия — поэтому советуем зарегистрироваться на оффлайн-встречу, даже если вы не сможете прийти. Так вы точно не потеряете ссылку на онлайн

Нужно что-то платить?
Нет, митап бесплатный — ждём всех неравнодушных к программированию на Spark!

Зарегистрироваться — https://clc.to/SparkMeetup

Call for papers: принимаем заявки от докладчиков на infra.conf до 5 апреля

Мы готовимся к infra.conf 2025 — летней конференции про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. 5 июня обсудим список наиболее интересных хардкорных тем:

• базы данных: шины, брокеры, OLAP, хранение и обработка данных;

• платформы разработки / инфраструктура разработки;

• инфраструктура для мобильной разработки;

• инфраструктура для фронтенда;

• ML‑инфраструктура;

• виртуальные машины, гибридные облака, контейнеры;

• мониторинг, observability;

• ДЦ/ЦОДы, железо, аппаратное обеспечение;

• умные устройства, системная разработка.

В 2025 году событие пройдёт во второй раз — смотрите в нашем плейлисте, как это было прошлым летом.

До 5 апреля вы можете подать заявку на доклад infra.conf 2025 — для этого нужно заполнить форму.
На этапе заявки достаточно черновых тезисов и общего плана выступления.
Программный комитет будет готов обсудить ваши идеи и предложения. Финальное решение по докладам примем до 20 апреля.

По возникшим вопросам вы можете обратиться  к координатору infra.conf Саше Галкиной.

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

Бизнес всегда будет желать напихать задач полную панамку.

Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.

Зачем нужна такая грубая оценка? Чтобы бизнес мог сопоставить трудозатраты с потенциальной ценностью задачи. После этого он может применить фреймворки приоритезации, такие как MoSCoW, ICE, RICE и прочие, чтобы определить, что действительно нужно сделать в первую очередь.

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

Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.

Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!

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

Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.

Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.

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

• Затраты на поддержку вырастут → Дороже обслуживать.

• Продукт становится нестабильным → Клиенты уйдут к конкурентам.

• Отток специалистов → Потери на найме и онбординге.

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

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

П.С. объявляю конкурс на иллюстрацию к этому посту!

Совсем недавно мне довелось поучаствовать в роли докладчика в конференции TeamLead Conf 2024. Выступал, как технический директор компании "Спринт-Ф", а темой выбрал "Законы Мерфи в повседневной работе руководителя".

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

А вот и запись доклада: https://www.youtube.com/watch?v=IQ68nN6cG68

Атмосфера HighLoad++ 2024 в репортаже Мир Plat.Form

Привет, друзья! С вами Дарья Морозова, специальный корреспондент Мир Plat.Form, и я снова здесь, чтобы поделиться с вами самыми горячими новостями из мира технологий. Сегодня у нас в программе — эксклюзивный видеорепортаж с HighLoad++ 2024!

Это была масштабная конференция, на которую собралось более 3000 ИТ-разработчиков высоконагруженных систем со всей страны. И мы не могли обойти её стороной.

Из репортажа вы узнаете — чем занимались участники конференции, какие стенды компаний привлекли наше внимание, о чем были доклады экспертов Мир Plat.Form и как объяснить блондинке принцип работы интернета. =)

Смотри, как это было, в нашем ролике!

Когда никто не хочет выступать

Самый сложный вопрос для организаторов мероприятий — где найти выступающих и интересные доклады.

В далёком 2019-м на конференции Apple WWDC показали сотню видео про новинки iOS-разработки, каждое по 40-50 минут. За 2 недели я посмотрел лишь пару. С такой скоростью на все ушла бы вечность. 

Когда я рассказал коллеге суть увиденного, мне пришла идея, что можно распределить темы между всеми айосерами. Я так и сделал. За час мы проходили 3-4 темы, это было весело и легко. Мы ещё полгода проводили такие техтолки. 

У нас заговорили разработчики, которые раньше стеснялись. Всё просто: тебе нужно посмотреть демонстрацию фичи и пересказать её. Это была первая ступенька к большим выступлениям многих ребят. 

Атмосфера была максимально ламповой. Мы закупались бутылочками Колы и пиццей, приглушали свет, слушали доклады и обсуждали, как можем внедрить новинки в наше приложение. Те, кто не мог прийти, подключались по Зуму. Тогда это не было мейнстримом, мы ставили Mac в первом ряду, чтобы показать выступающего и слайды.

Безусловно, техтолку предшествовали анонсы в чатах, а я в личках узнавал о планах и выбирал удобное всем время. Тогда я понял, что никакие объявления не заменят личного общения. 

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

Что с нашими техтолками сейчас — читайте в статье. И делитесь, как вы сами начали выступать или как находите спикеров.