Developer Relations *

Когда компания маленькая, архитекторов обычно нет. Есть разработчик Алеша, системный администратор Димон и руководитель Саша, который говорит сакральную фразу:

"Да что там делать, поднимите сервер, выкатите приложение. Делов-то!".

Потом компания растет. Появляются Kubernetes, микросервисы, Clickhouse, десять команд разработки, пять облаков, семь подрядчиков, бюджеты на миллионы рублей и внезапное осознание:

"Кажется, нам нужен человек, который понимает, как это вообще должно работать вместе".

Так в компании появляются архитекторы. И сегодня я хотел рассказать - кто эти люди и зачем они нужны...

Что делать, когда внешние факторы ломают прогнозы, а вы лидер и как-то двигаться вперед нужно?

Анонимный вопрос участника: как держать веру команды и ЛПР в проекте, когда результаты и метрики из‑за внешних факторов почти непредсказуемы? Если «всё классно» — мотивирует, а если шатко-валко — как с этим жить и доносить до стейкхолдеров?

Восьмая статья с «деврел‑супервизии». После мрачняка про рынок вакансий обсудили, что делать, если сокращать не сокращают, но нагрузили аж до выгорания.

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

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

Анонимный вопрос участника: страх сокращения понятен, а что делать, если правда сократили? Как на это посмотрят новые потенциальные работодатели?

Большая тема о сообществах собрала в себе ответ с "деврел-супервизии", а еще два ответа от экспертов, которых не было с нами на встрече: Антонины Коломиец и Ильи Пономарева.

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

Единорог Коди и его товарищ Баг — узнаваемые маскоты PVS-Studio. Этих персонажей вы видели во многих сценариях: при археологических раскопках, в космосе, при ограблении банка, в саду и в сточной канаве. Но как вообще появился этот единорог, и как же он выглядел на заре времён? Давайте посмотрим хронологию взросления Коди в этой статье, а также изучим самые занятные иллюстрации с его участием!

Пятая статья с "деврел-супервизии". Судя по количеству вопросов по теме статьи, одна из самых актуальных.

Анонимный вопрос участника: куда податься и чем успокоиться, когда боишься сокращений? Когда ты на стыке HR, PR, IT, деврелишь и теряешь ощущение пользы от деврельства в команде и компании.

В 2024 году мы получили сертификацию Great Place to Work — это был важный первый шаг, где мы набрали необходимые 65% одобрения. Но мы не остановились на достигнутом. В 2025 году мы снова приняли участие и заняли 1-е место в рейтинге Best Workplaces in Qatar™!

Это достижение — не просто удача, а результат системной работы над внутренней культурой, на которую функции DevRel и внутренних коммуникаций имели непосредственное влияние. Рассказываю, как мы строили среду, в которой 96% сотрудников искренне гордятся своей компанией.

Третья статья с "деврел-супервизии": эта подборка мнений побольше, тема вызвала дискуссию на самой встрече :) Целиком движ с вопросами от экспертов к экспертам прямо по ходу обсуждения можно посмотреть на видеозаписи.

Анонимный вопрос участника: если DevRel хочет строить портфельную карьеру с элементами консалтинга, преподавания и монетизации экспертизы — чтобы не быть привязанным к одному источнику заработка — на чем это сейчас реально делать?

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

Анонимный вопрос участника: можно ли быть сильным деврелом, если ты скорее методист-организатор без глубокого технического бэкграунда? Что делать с ощущением меньшей ценности на фоне специалистов с техническим бэкграундом?

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

Собрали 8 экспертов, которые разбираются в кризисах: от опытных деврелов до специалистов по выгоранию в ИТ и карьерному консультированию.

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

Тема первая: как справляться с возрастными и статусными сомнениями, будучи линейным специалистом старше части команды и руководителей?

Материал команды Codenrock. В феврале–марте 2026 мы опросили 1160 участников хакатонов из аудитории Codenrock. Параллельно сверились с глобальными исследованиями: Stack Overflow Developer Survey, JetBrains State of Developer Ecosystem и GitHub Octoverse за 2025 год. Где наша картина совпадает с мировой, а где идёт своим путём — разбираем по порядку.

30,2% хакатонщиков считают, что нынешние правила соревнований устарели и проектам с ИИ нужны отдельные критерии. 65,1% уверены, что менять правила не нужно. Мнения участников заметно разделились — и от того, в какую сторону сместится баланс, зависит, как будут выглядеть хакатоны через год.

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

Ранее я писал про утечку исходного кода Claude Code. 512 000 строк, KAIROS, упоминания нерелизнутых моделей Opus 4.7 и Sonnet 4.8. Так вот. В актуальном Claude Code уже есть Opus 4.7. Ровно как и было в leaked‑коде. Вместе с ней появился новый уровень /effort xhigh — это мы сегодня тоже разберём.

В первой части я показал что Claude Code умеет из коробки. Типовой сценарий после этого: «понял, установил, пользуюсь». И дальше тот же потолок что у всех — Claude работает быстро, но как‑то странно. Отвечает не то, повторяет одно и то же к концу сессии, просит разрешения на каждый чих, жрёт токены как не в себя.

Это решается настройками. Конкретными. Которые лежат в двух файлах и никто до них не доходит.

Ниже десять вещей которые я настроил за полгода работы с Claude Code и которые сделали разницу между «работает» и «работает как отдел». С готовыми конфигами. Копируй, вставляй, меняй под себя.

512 000 строк утёкшего кода, совещание ботиков, и почему человек стал узким местом разработки

31 марта 2026 года Anthropic случайно выложила npm-пакет с source map файлом на 59.8 мегабайт. Внутри - 512 000 строк TypeScript, 1 900 исходных файлов и 44 скрытых feature flags. Весь исходный код Claude Code, включая вещи, о которых пользователи даже не подозревали.

За несколько часов репозиторий форкнули 41 500 раз. Anthropic начала рассылать DMCA-takedowns, но было поздно. Сообщество успело найти упоминания KAIROS - автономного агента, который работает пока ты спишь, консолидирует память и проактивно действует без промптов. 150+ упоминаний в коде. Нерелизнутые модели Opus 4.7 и Sonnet 4.8. Режим "Undercover" для сотрудников Anthropic, скрывающий AI-атрибуцию в коммитах на публичных репозиториях.

Я пользуюсь Claude Code каждый день. Это мой основной инструмент разработки. Я пересадил на него команду, я создаю с ним проекты с нуля, и я вижу как он меняет саму суть профессии разработчика. В этой серии из трёх статей я расскажу что я понял за это время - от базовых фич до продвинутых паттернов, которые позволяют одному человеку работать как команда.

Начнём с десяти вещей, которые делают Claude Code не просто ещё одним AI-помощником.

Когда про Jito говорят, как про основную MEV-инфраструктуру, это мешает понять суть архитектурного решения. Потому что в общем случае Jito выходит за рамки MEV. И если прорваться через некоторый объем документации, становится понятно, что основная “killer-feature”, которую дает Jito-клиент - это возможность АТОМАРНО исполнить пачку транзакций (до 5 транзакций).

Примечание: “атомарно” значит исполнить или все транзакции из пачки, или ни одной. В классической реализации Solana-ноды такого нет, и, например, отправив Лидеру слота с Agave-клиентом 5 транзакций, вы никак не сможете гарантировать, что они исполнятся последовательно в одном блоке. Между ними всегда могут вклиниться транзакции с повышенной priority fee.

А вот Jito дает прям надежный способ атомарно исполнить пачку транзакций. Именно возможность исполнить пачку транзакций атомарно и открывает большие возможности для извлечения выгоды из ончейн состояния. Например: разного вида ликвидации, backrunning, frontrunning, сэндвич-атаки. Про то, как именно пачка транзакций позволяет извлечь выгоду в каждом из этих случаев, нужно говорить отдельно. Пока просто достаточно понимать, что извлечение MEV становится КАРДИНАЛЬНО эффективней, если у вас есть гарантия свойств атомарности исполнения пачки транзакций.

«Я весь в операционке, мне не о чем рассказать на публику».

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

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

Всем привет! Меня зовут Юля Трусова и я тестировщик. А ещё я лидирую под ключ одно из самых крупных и древних комьюнити в Авито — QA Community. В этой статье я расскажу про свой подход к теме, поделюсь важными вехами в становлении комьюнити и с удовольствием почитаю про ваш опыт в комментариях.

Пришёл в проект, там легаси погоняет легаси. Спагетти такие что уже в рот лезут. Отчёты по филиалам открывались 30 секунд. Команда реально боялась нажать кнопку в рабочее время, а вдруг база ляжет.

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

Первое, что я сделал: открыл EXPLAIN ANALYZE.

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

Введение

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

Но если вы когда-нибудь работали в проекте, который живёт больше пяти лет, в high‑load системе или enterprise‑среде, вы наверняка сталкивались с парадоксом: самые стабильные части системы — это те, к которым никто не прикасается годами.

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