Developer Relations *

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

Собрали 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‑среде, вы наверняка сталкивались с парадоксом: самые стабильные части системы — это те, к которым никто не прикасается годами.

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

AI-агент каждую сессию начинает с нуля — не помнит, что вчера разбирали архитектуру, какие баги нашли и почему выбрали именно это решение. Знакомо?
Я сделал open-source MCP-сервер на Go, который даёт агентам persistent memory с semantic search. Один memory-layer для Cursor, Claude Code и Codex — чтобы контекст не терялся между инструментами.
В статье — не обзор, а инженерный разбор: схема БД, embedding pipeline с fallback между провайдерами (и почему я в итоге от этого отказался), in-memory cosine similarity вместо vector DB, RAG-индексирование с инкрементальным обновлением, и реальные промпты для агентов.
Отдельно разобрал грабли: почему fallback между разными embedding-моделями — это не отказоустойчивость, а источник тихих багов, и как я это починил.

Зачем бизнесу новая позиция в C-suite и что она означает на практике

Когда одни компании обсуждают, нужен ли им ИИ, другие уже нанимают человека, который будет отвечать за него (или сейчас  сам сидит и пилит ИИ-агентов ) и все это на уровне совета директоров. Chief AI Officer — позиция, которая ещё три года назад звучала как фантастика, сегодня становится такой же обычной как СТО (ТехДир), CFO (ФинДир)или CHRO (HR).

Ну и что это за роль такая, откуда она взялась, чем отличается от CTO и CDO(Chief Digital Officer — директор по цифровой трансформации (это в больших банках есть такая позиция)), какие технические компетенции требует — и нужен ли он вам сегодня или как обычно, уже вчера.

LLM научилась запоминать беседу, не подгядывая в контекст. Архитектуры типа Titans и обещают превращение цикла вывода в цикл онлайн-оптимизации

POV: Летишь в Лиссабон на крупнейшую tech-конференцию Европы. В программе — AI Summit, Fintech Summit, выступления экспертов из Google и стартапов-единорогов. Ты готов погружаться в технологии и узнавать про последние тренды.

Рил: На главной сцене Мария Шарапова рассказывает про жизнь, а тиктокер с миллионной аудиторией делится, как использовал ChatGPT — один раз попросил показать, как резать манго 🥭

Привет, Хабр! Меня зовут Иван Манжетов, я портфельный менеджер в IT-компании KODE — мы занимаемся мобильной разработкой. В ноябре 2025 года впервые побывал на Web Summit в Лиссабоне и привез несколько теплых контактов, которые сейчас превращаются в проекты с бюджетами 90k+ евро.

Делюсь тем, как устроен современный стартап-мир, почему 90% AI-проектов используют одинаковую технологию, и что дают международные конференции тем, кто работает в IT.

48 часов, 100 разработчиков, и одна задача — создать с нуля продукт. Именно так работают хакатоны. Мы собрали всё, что знаем про их организацию, и оформили это в большое пошаговое руководство.

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

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

Для начала хотелось бы сказать, что же такое массивы и слайсы.

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

Давайте рассмотрим на примере:

Что для вас хакатон? Тимбилдинг для разработчиков? Тусич с коллегами? Что-то айтишное? А что если хакатон — это вообще не про айтишку, а про... бизнес!?

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

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

Мы проанализировали 240 хакатонов 2025 года и разобрали, какие форматы, навыки и подходы будут определять соревнования в ближайшем будущем. В основе исследования — статистика мероприятий и участников платформы Codenrock. Картину дополняют данные крупных международных отчётов, чтобы увидеть общие тенденции развития IT-сообщества.

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

Четыре года назад меня, откровенно говоря, не воодушевляли результаты моей деятельности. Компания состояла всего из пяти человек, мы генерировали 10 млн рублей выручки в месяц, за два года пришлось сменить трех CEO. Стоило мне добавить в команду хотя бы одного человека, как тут же падало качество работы, рассыпалась культура, люди начинали мешать друг другу…

Сегодня в компании уже 150 человек. Выручка выросла в 150 раз — теперь это 1,5 млрд рублей в месяц. Мы заняли вторую позицию на рынке рекламных агентств-агрегатов, а я никогда не думал, что это возможно. Главное, люди по-прежнему хотят здесь работать — инициатива не угасла, да и качество продолжает радовать. Сейчас это может звучать закономерно, но на пути к результату я был вынужден переосмыслить буквально все, что знал об управлении командой. Ниже делюсь инсайтами и раскрываю подноготную нашего масштабирования.

Все мы знаем стандартную лестницу: Junior, Middle, Senior. Но где на самом деле проходит граница? Почему в одном стартапе «сеньор» — это тот, кто вчера узнал про LINQ, а в кровавом энтерпрайзе от «мидла» требуют проектировать распределенные системы под нагрузкой в миллион RPS?

Я задалась вопросом оценки собственного грейда, когда уходила со своего первого места работы. Кто я для рынка? Почему мои знания на собесе в одной компании соответствуют чуть ли не уровню Senior, а в другой – покрывают максимум вакансию Junior’a?

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

Я решила отойти от субъективности и спросить у самого рынка. В этой статье — результаты анализа 700+ актуальных вакансий .Net разработчика, графы связности навыков и ответ на вопрос: в какой момент количество выученных библиотек наконец-то превращается в качество инженера.