Все потоки

Я* говорил вам, что ИИ — это инструмент, а не стратегия, а вы переименовывали стартапы в "Что-то-там AI". Теперь у нас сотни питчдеков тысячи мудбордов и ни одного бизнес‑плана, не выплюнутого из той же LLM, вокруг которой типа «строится бизнес».

Я говорил вам, что нужно делать полезный продукт, а вы прикручивали к нему чаты. Теперь у нас вместо полезного продукта — никому не нужная хрень, но с чат‑ботом.

Я говорил вам, что важнее решать проблемы пользователей, а вы оптимизировали метрики. Теперь все KPI зелёные, но пользователи уходят.

Я говорил вам, что код нужно понимать, а вы продолжали копипастить ответы LLM. Теперь всё вроде работает, но никто не знает как это проверить.

Я говорил вам, что инженеров нужно учить архитектуре, а вы учили их писать промпты. Теперь все умеют правильно попросить нейронку написать микросервис, но никто не знает, нахрена он нужен.

Я говорил вам, что нельзя измерять работников просто количеством закрытых задач, а вы продолжали строить дашборды. Теперь у нас рекордные "трудовые" показатели и нереальное количество нейро‑слопа.

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

Я говорил вам, что удалёнка требует специальную рабочую культуру, а вы ставили трекеры активности и считали клики. Теперь у нас всё в графиках продуктивности и ноль доверия.

Я говорил вам, что не нужно заменять джунов чатами, а вы заменяли их агентами. Теперь для джунов нет работы. Джуны прикидываются мидлами, мидлы сениорами, а где взять сениора — х** его знает... Он скорее всего теперь RAG прикручивает.

Я говорил вам, что open source нужно поддерживать деньгами, а вы ставили звёздочки на гитхаб. Теперь весь интернет держится на паре библиотек, которые пилят выгоревшие к хренам мейнтейнеры.

Я говорил вам, что нужно разворачивать свои LLM, а вы оформляли подписку на Claude. Теперь токены стоят больше, чем джун. Джуна у нас нет — он прикидывается миддлом, миддл прикидывается сениором, а сениор занят — он RAG прикручивает.

Я говорил вам, что не нужно отсеивать кандидатов по списку ключевых слов, а вы продолжали искать Senior Kubernetes AI Cloud DevOps Platform Engineer. Теперь вакансии висят по году, а кандидатов «на рынке нет». Откликов тьма, но все "нерелевантные".

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

Я говорил вам, что нельзя делать автоматизацию найма, а вы кликали по кнопке «сгенерировать вакансию». А с обратной стороны «сгенерировать резюме». Теперь у нас миллионы вакансий с миллионами откликов и резюме, но как на собеседовании отличить джуна от сениора - непонятно. У нас ведь сениора нет! Он п****ц как занят — RAG прикручивает.


*Я — собирательный образ

Приходите на второй открытый онлайн Devhands AI Meetup #2!

📅 Когда: 18 июня, начало в 18:30 (Мск)

🔗 Где: Zoom (запись через таймпад) 

Формат: блиц по 7 минут, только личный опыт и кейсы, без воды. ~45 минут выступления подряд без вопросов, ~45 минут — обсуждение и вопросы. Всё бесплатно.

Программа на 18 июня:

• «ACP как база для агентской автоматизации» Алексей Самойлов, Techlead в Fastronome

• «Системный дизайн через AI-скиллы и MCP: от требований до архитектурного решения» Виталий Юшкевич, Lead engineer в Pugofka 

• «Опыт применения AI в стартапе инфраструктурной платформы» Георгий Меликов, no-ops платформа Exordos

• «Организация правил работы с проектами в Claude» Денис Савицкий, разработчик в DeltaSoft

• «Опыт применения AI для анализа фродовых регистраций» Дмитрий Дунаев, Дата инженер в ССР

Ксения Погорельских, хостинг-сервис Deploy-f-, название доклада уточняется (расскажу про факапы, про эксперимент, где 30 агентов-тестировщиков нон-стоп ищут баги, а агент-разработчик эти баги исправляет и отдает на ретест. И почему эти агенты долго не могли выдать мне ветку с фиксами, готовую к мержу в мастер).

Приходи, регистрируйся, это можно сделать через таймпад, или через наш чат, Devhands AI Club. Если интересно участвовать в качестве блиц-спикера - присылай заявку на следующий митап. Темы, которые мы хотим обсуждать:

• Кейс: рассказ о запущенных проектах, опыт внедрения и adoption в компаниях

• Цикл разработки: Agentic SDLC, SDD, ADR, автоматизация QA (unit, smoke, e2e, нагрузочное), деплой, работа с инцидентами, sandboxing, security

• Агенты: возможности/недостатки, опыт, сравнение, новинки, баги 

• Облачное окружение: модели, гейтвеи, стоимость

• Локальные модели: модели, железо, сетапы, скорость и стоимость. 

• Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю. Ошибки, которые я не повторю.

Оружие или зависть? Правительство США заставило Anthropic отключить доступ к новым ИИ-моделям

Приятно пользоваться нейросетью, которая помогает написать код или деловое письмо. Но долго ли эта возможность будет доступна бесплатно или за относительно небольшие деньги? Когда технология становится стратегической, доступ к ней пропадает. Например, начало разработки ядерной бомбы в СССР связывают с письмом ополченца Георгия Флёрова Иосифу Сталину — он отметил, что в научных журналах пропали работы по изучению распада атома, а значит, использование радиоактивного излучения перешло из научной стадии в промышленную. Флёров был отозван с фронта и стал одним из отцов советской ядерной программы. Не по той же ли схеме правительство США приказало Anthropic убрать доступ к двум новым ИИ-моделям — Fable 5 и Mythos 5?

9 июня Anthropic выпустила новые самые мощные ИИ-модели Fable 5 и Mythos 5, а уже 12 июня сообщила об отключении доступа к ним для всех по требованию правительства США. Формально требование касалось только неграждан США, но, видимо, разработчик пока не имеет надёжной системы определения гражданства пользователя. Отметим, что для любой ИИ-модели крайне важно её использование как можно большим числом пользователей — модель дообучается, а разработчик исправляет её недостатки. Поэтому Anthropic крайне невыгоден текущий запрет, и компания старается его оспорить.

Формальная причина запрета — потенциальная возможность использовать Fable 5 для взлома веб-сервисов. Опасность применения злоумышленниками актуальна для любой системы, и поэтому разработчики применяют меры предосторожности. Причём в случае Anthropic моделей две как раз из соображений безопасности: Mythos 5 — мощная ИИ-модель без ограничений для узкого круга специалистов, а Fable 5 доступна широкому кругу пользователей, но имеет массу ограничений.

Специалисты по кибербезопасности считают, что ограничения в любой ИИ-модели можно обойти, и в этом плане Fable 5 не опаснее предшественников: потребуется слишком много усилий, чтобы применить её для взлома. Многие из них просят вернуть доступ к новым моделям Anthropic.

Возможно, дело в том, что использование ИИ с целью взлома систем стало трендом в этом году: современные модели обнаруживают уязвимости пачками. И, возможно, правительство США решило, что пришло время отобрать у других стран доступ к потенциальному оружию.

Есть более человеческая версия. Anthropic готовится к IPO и вслед за SpaceX (включающей xAI) может стать одной из самых дорогих компаний мира. Это вызывает зависть, тем более мы уже рассказывали, что компания ссорилась с правительством США. Добавляет интриги сообщение о том, что правительству на Anthropic настучал — внезапно — её крупнейший инвестор, компания Amazon. Деньги деньгами, но кому-то очень не нравится отдавать рычаги управления миром молодой компании.

А за беспилотные авто в России ответит пользователь

Когда говорят об ИИ, обычно обсуждают вычислительные мощности и размеры ИИ-модели, но есть ещё одно направление, которое может кардинально изменить применение технологии, — это регуляторика, законы и, если хотите, философия применения. По сообщению «Коммерсанта», Минтранс подготовил новую редакцию законопроекта о правилах движения и эксплуатации беспилотных автомобилей, в которой указано, что при ДТП с участием автономного транспортного средства (ТС) возмещать ущерб здоровью потерпевших и их имуществу будут владельцы высокоавтоматизированных транспортных средств (ВАТС). О чём это говорит?

1. Вступление закона в силу планируется уже осенью 2027 года. Видимо, мы уже близки к применению беспилотников на дорогах по всей России. Сейчас они действуют только в экспериментальных зонах.

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

3. Оплачивать ущерб за ДТП с участием ВАТС (беспилотника) будет его владелец. Но потом он может предъявить регрессный иск создателю софта, если авария произошла по причине сбоев в программно-аппаратной части. Вот это третье нововведение тянет на глобальное решение, которое может помочь или затормозить распространение беспилотных машин. Похожей по значимости была ситуация с софтом для первых персональных ПК — регуляторы разрешили продавать софт по принципу «плати как есть» без ответственности разработчика за сохранность пользовательской информации. С одной стороны, это привело к многочисленным случаям потери данных — разработчики заботились о надёжности софта, пока это не мешало получать прибыль. Зато это позволило разрабатывать софт быстрее и большему количеству компаний. И в итоге привело к расцвету ИТ.

Если Минтранс примет новые правила с ответственностью владельца ВАТС за ущерб в ДТП, то, видимо, это потянет рост бизнеса на сдаче беспилотников в аренду (тогда едущий или перевозящий грузы не будет нести ответственность за ДТП), страхование (никто не знает, насколько беспилотники будут хорошо ездить при массовом выходе на дороги, и наверняка владельцы захотят подстраховаться), а главное — развяжет руки создателям программно-аппаратных систем для беспилотных авто. С одной стороны, они могут отнестись к новым ИИ-системам менее ответственно, зато получат больше возможностей для экспериментов, так как меньше ресурсов придётся резервировать, чтобы возместить ущерб пострадавшим при ДТП.

Как разработать Linux-драйвер реального устройства для платформы RISC-V

Если вы хотите лучше разобраться во внутреннем устройстве Linux и узнать, как его ядро взаимодействует с физическими устройствами, то приходите на бесплатный офлайн мастер-класс YADRO. Вместе пройдем полный цикл создания драйвера дисплея LCD1602 для VisionFive2: от теории до добавления новых функциональных элементов и запуске на одноплатнике.

Что будем делать:

• загрузим информацию о дисплее в ядро через Device Tree Overlay;

• выведем текст на дисплей через драйвер Linux для embedded-систем;

• считаем содержимое дисплея из ядра Linux и выведем в консоль;

• научимся управлять подсветкой и курсором через интерфейсы Linux Kernel Driver;

• займемся обработкой IRQ по нажатию кнопки;

• разберем типичные ошибки при разработке Linux-драйверов.

Мастер-класс проведет Никита Косырев, инженер-программист группы системного ПО в YADRO. Никита — энтузиаст embedded-систем и архитектуры RISC-V, несколько лет занимался разработкой драйверов периферийных устройств в ядре Linux. 

Приглашаем инженеров, которые хотят лучше разобраться в низкоуровневой разработке для Linux и особенно тех, кто работает с user space-приложениями. 

Мастер-класс пройдет офлайн 3 июля в московском офисе YADRO, количество мест ограничено. Участие бесплатное, но регистрация обязательна.

Вот такую работу предлагает Райфайзен для Java-разработчиков с опытом от 3 лет. И как это теперь развидеть? 😎

Представлен онлайн‑проект Entry Conditions, с которым можно забыть обо всех мучениях с визами, разрешениями и прочими деталями въезда. Это огромный справочник с информацией по паспортам всех стран, по правилам въезда куда угодно — и с рабочими ссылками на официальные порталы электронных виз. Вся инфа актуальная и проверенная.

🍺 В этот день 150 лет назад родился Уильям Сили Госсет.

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

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

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

Поэтому, когда Госсет в 1908 году опубликовал свой метод, он подписался псевдонимом: Student.

Каждое клиническое испытание, лабораторный эксперимент и A/B-тест, где сегодня используют t-test, опирается на работу Student.

Одна из самых известных фамилий в статистике — ненастоящая.

AviTalk: как инженер становится техническим руководителем юнита

AviTalk — шоу, в котором сотрудники Авито рассказывают о своём профессиональном пути. В этом выпуске — Марк Чайников, Technical Unit Leader в Авито. Ведущий — Виктор Раев, руководитель разработки юнита Services Base.

Разбираем путь Марка: от школьных проектов и поддержки 17 сайтов в одиночку до управления целым юнитом. Поговорили о том, почему переход в менеджмент редко бывает линейным, чем тимлид на практике отличается от более высокого уровня руководства и зачем инженеру вообще идти в управление.

Отдельно затронули не самые очевидные, но важные вещи: как логи и заметки помогают в работе руководителя, почему ops-review — это не формальность, а инструмент управления, и что делать с конфликтами и выгоранием внутри команды.

Это разговор не только о карьере, но и о том, как меняется мышление, когда перестаёшь отвечать за код и начинаешь отвечать за систему целиком.

Смотреть выпуск:

🔵 VK Видео
📺 YouTube
📌 Rutube

AviTalk — шоу толковых людей. Гости — сотрудники Авито из разных дирекций и команд, которые делятся своей экспертизой и профессиональным путём.

О новой тактике курьеров Яндекс.Еды по расчистке пути на пешеходных тротуарах...

Когда официальные каналы коммуникации не работают, ничего не остаётся, кроме как попытать счастья в публичном пространстве. Вообще я не люблю такую тактику. Тем более что "Хабр - не жалобная книга". Но так как на горячей линии Яндекса меня отфутболили, то решил попытаться обратиться к компании через Хабр. Возможно, удастся решить проблему.

Итак, уже несколько раз столкнулся со следующим поведением курьеров на тротуарах:

• курьер несётся навстречу на электровеле на бешеной скорости

• если видит препятствие в виде пешехода, то врубает какой-то дикой яркости вспышку

• вспышка слепит пешехода, пешеход впадает в ступор, курьер его объезжает на всё той же бешеной скорости

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

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

Пытался сообщать на горячую Яндекса о проблеме. Но разговор выглядел примерно так:

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

Яндекс, очень надеюсь, что вы чем-то помочь всё-таки сможете. Вам ведь тоже, наверное, хотелось бы жить в комфортной и безопасной городской среде? Где вас не будут слепить вспышками, подвергая опасности (ибо после вспышки вы мало что видите в течение какого-то промежутка времени)

ChatGPT и Claude научили маскироваться под Google Docs — представлено расширение GPTDisguise, где нейросеть выглядит как обычный документ, поэтому со стороны кажется, что пользователь усердно пишет документы. Также доступны режимы под Microsoft Word и Notion.

От падающего теста до правки: как General ведёт задачу в любимой IDE

Когда разработчик открывает AI-чат в IDE, он не думает категориями режимов. Он не формулирует задачу как «сначала Plan, потом Code, затем Test и Review» — он пишет проще:

Почини тест

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

Под этот сценарий в Veai сделан режим General: вы описываете цель обычными словами, а агент сам выбирает маршрут — проход по коду, планирование, тесты, ревью, отладка или подключение субагентов. Специализированные режимы (Ask, Code, Test, Plan, Review, Debug) остаются для случаев, когда вы хотите управлять процессом явно.

Почему ручной выбор режима мешает

Реальная задача редко укладывается в один режим. «Исправить падающий тест» — это сразу несколько подзадач: понять причину, решить, где ошибка (в тесте, production-коде, моках, данных или окружении), внести правку и запустить проверку. Если режим нужно выбрать заранее, новый разработчик начинает не с решения проблемы, а с изучения классификации агентов. General убирает этот выбор из начала задачи.

Что происходит по шагам

На запрос «в сервисе оплаты падает тест, найди причину и почини» General в простом случае ведёт задачу сам:

1. находит и запускает тест через IDE run configuration — в том же окружении, что и разработчик (SDK, профиль, переменные, модули), а не в собранном из терминала, которое может отличаться;

2. читает стектрейс, открывает связанный production-код, при необходимости смотрит usages, warnings и inspections;

3. вносит минимальную правку и перезапускает проверку: тест прошёл или упал — это факт из IDE, а не предположение модели.

Если стектрейса не хватает, агент опирается на отладчик (breakpoints, значения переменных, call tree), а если стектрейс уводит в библиотеку — открывает её код или декомпилированный класс через IDE, а не угадывает API по памяти модели.

Когда подключаются субагенты

Маршрут выбирает не отдельный классификатор, а сама модель: по тексту задачи и первым фактам из проекта она решает, достаточно ли пройтись по коду или стоит разложить работу на субагентов (один исследует причину, второй — зависимости, третий — тесты). Поправить одну строку General сделает сам, большую задачу — распараллелит. Многоагентность здесь не самоцель, а инструмент для задач, где она реально ускоряет результат.

Полностью исключить ошибки модели нельзя. Но General опирается не только на LLM, grep и RAG, а на JetBrains IDE как на источник проверяемых фактов: run configurations, SDK и classpath, структуру кода, usages и inspections, coverage, код зависимостей и ошибки компиляции так, как их видит IDE. Отсюда меньше галлюцинаций API и ситуаций «у агента прошло, а в IDE или CI падает».

Разницу можно измерить. 

Мы прогнали 8 enterprise-задач на Java/Spring через четыре агента на одной модели — Cursor, Claude Code, JetBrains Junie и Veai:

Контроль остаётся у разработчика

Даже когда агент ведёт задачу автономно, последнее слово за человеком: разработчик смотрит diff в окне Agent Changes и решает, что принять. Перед этим General может сам прогнать несколько субагентов-ревьюеров по своим изменениям и устранить критические проблемы ещё до того, как покажет результат человеку, — авторевью встроено в маршрут, а не остаётся отдельным ручным шагом. Идея не в том, чтобы убрать review, а в том, чтобы убрать лишнюю ручную маршрутизацию до него.

Установить Veai 5.12

Обратная связь — support@veai.ru и чат с командой.

На Go непривычно после Python

На работе переводим сервисы на Go. Делюсь ощущениями от Go, как FastAPI-питонист:

• В Go классов нет, есть struct с полями.

• Внутри структур нет методов. Перечислили поля и все. Дальше функцию связываем отдельно со структурой сигнатурой вида funс (s *SomeStruct) Greet () string {}. С аргументами читается еще тяжелее.

• ООП нет, наследования нет. Связь между структурами через композицию.

• Ошибки нужно обрабатывать руками без try ... except с помощью if err != nil {...}.

• nil вместо None

• Эксепшнов нет. Функции возвращают ошибку как обычное значение: val, err := SomeFunc(). Хотя в Python я ответ из кортежей прям не люблю и избегаю, тут это база.

• Зато есть panic, которые по сути – необработанные эксепшны.

• Но на паники есть recover, который лечит последствия паники :)

• Комментарии через два слеша // comment

• Докстринги над сигнатурами, а не под.

• OpenaAPI для Swagger надо собирать самому без FastAPI. Напрочь забытый навык. Даже с либами вроде swaggo/swag делать это надо руками, с ошибками.

• Валидации полей нужно писать руками. Нет аналога Pydantic с батарейками.

• Строка в двойных кавычках "w" – строка. В одинарных 'w' – руна, другой тип данных, который принимает в себя только один символ. Писать слово или фразу в руну нельзя.

• А есть еще backtick ` ` для тегов структур. В них как раз могут задаваться правила валидаций в go-playground/validator:
type User struct {
Name string `validate:"required,min=2"`
}

• len у строк в байтах. Символ в кириллице = 2 байта. len строки на кириллице ~х2, непривычно. Нужно считать длину рунами в строках.

• Иинтерполяция делается через fmt.Printf(). В отличие от f-строк в Python требует в конце явного перевода строки с \n, иначе строки слипаются. 

• Вместо snake_case – lowerCamelCase для приватных идентификаторов пакета, а UpperCamelCase для экспортируемых.

• Первым аргументом в запускаемом приложении командой go run some-script.go неявно выступает путь до файла. Из-за этого появляются идиомы в циклах типо «начни со 2-го аргумента».

• Моржовый оператор a := "some" в Go это инициализация переменной с присваиванием. В Python это оператор в if ... else блоках, который инициализирует переменную только если сработало условие.

• Аргументы у методов – позиционные. DoSomething(first, second, last) против do_something(action=first, modifier=second, final_action=last) у Python. Python умеет в лаконичность, но тут Go в нее заставляет. У методов со сложными контрактами надо сигнатуру подсматривать.

Что в Go нравится:

Тут много наивного по неопытности :)

• Горутины – топ. Не нужно в голове держать асинхронный код, потоки, процессы, футуры, CPU-задачи, IO-задачи – на все горутины. А для передачи данных – каналы. Горутины весят 2-4 КБ против ОС-потока в 2-4 МБ памяти. Нет танцев с GIL. go func и начинаешь в конкурентность.

• Статическая типизация при сборке находит много ошибок без линтеров и mypy. Еще она заставляет явно писать типы данных в аргументах и ответах от функций. Код нагляднее.

• Вместо двоеточий  и отступов фигурные скобки. Я еще с NodeJS любил не капризное авто-форматирование.

• Go-скрипты собираются в бинарники. Для них не нужен установленный Python или JVM. Просто запускаем как обычный баш-скрипт через ./script

• Импортировать пакеты нужно целиком. Как в Python только метод импортировать нельзя. Обязательная лаконичность тут нравится. Импорты аккуратные, а в коде вызов их функций более явный.

• Код модулей удобно читать сверху вниз. Python – интерпретируемый. Все, что не объединено в класс, должно быть объявлено перед вызовом. Код приходится нередко читать снизу вверх. Go – компилируется, порядок кода неважен. Читать код по ходу пьесы проще.

• Стандартный пакет для тестирования go test все умеет из коробки. Аналог pytest как внешняя зависимость не нужен.

• Ради чего все это: перевод сервиса с Python на Go даже тупо с ИИ-агентом, по метрикам Prometheus (АБ 50/50 трафик) снизил время ответа и потребление CPU и IO-ресурсов в десятки раз.

Из-за последнего вас и спрашивают на Python-собесе «готов перейти на Go»? Бабки, с-ка, бабки.

Написал бесплатное приложение для транскрибации — ⚡️ Talkis. Делал для себя как open‑source альтернативу платным сервисам по подписке.

Что оно умеет:

• Расшифровывает созвоны (Zoom, Discord, Telegram и др.) в реальном времени прямо на лету.

• Вытаскивает текст из любых готовых аудио‑ и видеофайлов.

• Умная диктовка: наговариваете мысли голосом, а приложение причесывает и форматирует текст под нужный стиль.

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

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

🤩 GitHub  📥 Скачать

Soft skills для инженеров: корпоративная мода или реальный скилл?

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

В новом выпуске «В SREду на кухне» поговорили о том, что обычно не попадает в job description, но решает карьеру: soft skills в инженерной среде. Вместе с Димой Масленниковым, руководителем центра надёжности Т-технологий в Т-Банке, и Лёшей Обровцом, тренером по публичным выступлениям, разобрались — это реальные навыки или просто модное слово из HR-презентаций.

Что на повестке

Почему сильные инженеры проваливаются в коммуникации — особенно когда всё горит и все смотрят на тебя. Как устроен эмоциональный интеллект в IT и зачем он нужен тому, кто «просто пишет код». Можно ли прокачать soft skills через конференции, командный спорт и конфликты — и стоит ли вообще. Отдельно поговорили про синдром самозванца, blameless-культуру без токсичности и самый недооценённый навык в профессии — который никто не называет в резюме, но все замечают в работе.

Если вы хоть раз думали «я нормально объяснил, просто они не поняли» — этот выпуск про вас.
Смотрите видео на площадках:

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

ИИ-рекрутер встретил ИИ-резюме. Им хорошо вдвоём

На прошлой неделе мне на HH пришло идеальное письмо. Персонализированное: названы мои проекты, мой стек, даже мой MCP-сервер из каталога awesome-mcp-servers. Шесть умных вопросов ровно по моему опыту. «Зацепило сочетание, которое почти не встречается» — приятно же.

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

И тут я понял, что произошло с HH.

HH больше не доска объявлений. Это маркетплейс

У маркетплейса своя логика: карточка товара, фильтры, ранжирование по совпадению. Резюме — карточка. Вакансия — поисковый запрос. Побеждает не лучший, а наиболее совпадающий: точный заголовок, правильные ключевые слова, типовая траектория. «5 лет PM в финтехе, сертификат» матчится идеально. «Практик, который сам пишет себе инструменты» — не матчится ни с чем. Для алгоритма уникальность неотличима от шума.

Раньше этот механизм хоть как-то компенсировал человек: рекрутер листал отклики и мог зацепиться глазом за нестандартное. Сейчас ИИ дошлифовал маркетплейс до идеала. Рекрутер генерирует вакансию и скрининговые вопросы моделью. Кандидат генерирует резюме и сопроводительное той же моделью. ИИ-рекрутер встречает ИИ-резюме, они прекрасно понимают друг друга — два чек-листа сверяются между собой со скоростью API. Люди подключаются в самом конце, к уже отфильтрованному совпадению.

Система работает. Для типовых позиций — честно говоря, лучше, чем раньше: меньше шума, быстрее матчинг, никто не читает 400 откликов руками.

Что умерло по дороге

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

Уникальный специалист на HH сегодня — это кастомный станок на Wildberries. Площадка не виновата. Формат не тот.

Что с этим делать

Не воевать с алгоритмом, а разделить игры.

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

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

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

Заходите к нам на огонёк! 24 июня состоится закрытая творческая встреча клуба корпоративных авторов Хабра

Мероприятие пройдет в Москве, в формате офлайн. Регистрация уже идёт! Делюсь ссылкой на страницу, как и обещала ранее, и благодарю всех, кто принял участие в опросе. Ваши вопросы будут озвучены на встрече, а ответят на них звезды Хабра.

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

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

На нашей встрече в следующую среду будет уютно, тепло и интересно! Много классных спикеров, творческая атмосфера, возможность пообщаться с единомышленниками, найти новые идеи и вдохновиться! Будем обсуждать поиск тем, лайфхаки и секреты написания крутых статей, общаться со звездами и легендами Хабра, а также с победителями, организаторами и членами жюри «Технотекста». Пора уже узнать их секреты!

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

📆 До встречи осталась меньше недели, поэтому регистрироваться нужно уже сейчас! Для тех, кто в других городах, проведем потом встречу в онлайн-формате. Об этом сообщу дополнительно!

🔥 Мероприятие бесплатное, но количество мест ограничено. По всем вопросам пишите, пожалуйста, мне в личку — буду рада пообщаться и увидеть вас на нашей встрече! 🫶

Программа нашей встречи:
 

14:00 — 15:00
Сбор гостей

15:00 — 15:05
Приветственное слово от Хабра. 

15:05 — 15:30
«Статья, которая зайдёт: как вовлечь аудиторию в чтение». Приёмы для создания лидов, заголовков и секреты интересной подачи материала». Виктория Гонгина, старший редактор-эксперт команды онбординга и обучения коммерческого департамента Хабра, куратор Технотекста. 

15:30 — 15:50
«Писать, отложить, вернуться: о процессе подготовки сильных статей». Артур Думчев, дважды победитель «Технотекста», техлид бэкенда в SberDevices. 

15:50 — 16:10
«Что творится с нейрослопом в научных статьях и как детектируют и борются с GenAI». Дмитрий Ватолин, победитель Технотекста, руководитель лаборатории компьютерной графики и мультимедиа ВМК МГУ.

16.10 — 16.30
«Как стать автором и взорвать Хабр». Игорь Данилов, технический пиарщик в дуэте с автором корпоративного блога «Цифрового Сибура» Иваном Васильевым. 

16.30 — 17.00
Перерыв на общение и перекус. 

17:00 — 17:20
«Как не похоронить хороший текст. О темах, смыслах, хабах, ключевых словах, реакции аудитории и секретах качественной статьи». Павел Соколов, руководитель группы контент-маркетинга IT-компании «Онлайн патент».

17:20 — 17:40
«100500 комментариев и 1 автор: как искупаться и не утонуть». Анастасия Распопина, автор и редактор текстов IT-тематики.

17:40 — 18:00
«Курсы, игры, два стола. Как Хабр помогает развиваться корпоративным авторам». Лилия Лущенко, старший редактор-эксперт в команде онбординга и обучения Хабра.

18:00 — 19:00
Креативный нетворкинг. Вместе генерим идеи для будущих статей.

19:00 — 19:30
Завершение мероприятия.

Проходите мини-курс «Безопасная разработка ПО»

Привет, Хабр! Мы выпустили вторую и третью части бесплатного курса в Академии Selectel. Материалы будут полезны опытным специалистам, которые хотят углубить знания и освоить инструменты защиты. Приступите к обучению прямо сейчас — изучение займет около двух часов.

Перед стартом рекомендуем пройти первую часть «Безопасная разработка: проектирование ПО». Это упростит понимание материала.

Часть 2 «Реализация»

Чтобы обеспечить безопасность ПО, важно корректно работать с кодом, данными и внешними компонентами. Во второй части рассмотрим, как проверять и ограничивать входные данные, безопасно обрабатывать информацию, взаимодействовать с внешними системами и отправлять выходные данные.

Часть 3 «Проверка безопасности и управление уязвимостями»

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

graphics.h в 2026 году: зачем и как запустить

graphics.h — это часть библиотеки BGI (Borland Graphics Interface) родом из 1990-х. В современных IDE её нет: она несовместима с 64-битными системами и не является частью стандарта C++. Тем не менее в учебных задачах она до сих пор встречается — особенно там, где нужно быстро визуализировать алгоритм или сдать лабораторную.

Когда это оправдано

• изучение основ C/C++ и хочется видеть результат за пределами консоли

• разбор алгоритмов компьютерной графики

• подготовка к экзамену по предмету, где преподаватель требует именно graphics.h

Для production-кода и серьёзных учебных проектов лучше сразу смотреть в сторону актуальных библиотек: SDL2 (2D, кроссплатформенная), SFML (ООП-подход, проще в освоении) или OpenGL/GLFW (если нужна 3D-графика и аппаратное ускорение).

О библиотеке

Адаптация для современных Windows называется WinBGIm — её разработал и поддерживает Майкл Мэйн, профессор Колорадского университета в Боулдере. Библиотека открыта для использования и модификации. Скачать можно на официальном сайте: winbgim.codecutter.org.

Если хочется сначала почитать вводный разбор — на Хабре есть статья с обзором WinBGIm, здесь же показан небольшой практический пример-скриншот: инженерная утилита с графическим выводом, которая впоследствии была переписана с использованием современного UI на C++.

Как запустить: общий принцип

Для работы используется адаптация WinBGIm — три файла: graphics.h, winbgim.h и libbgi.a.

Линкер-флаги одинаковы для всех сред:

-lbgi -lgdi32 -lcomdlg32 -luuid -loleaut32 -lole32

Известный баг: в оригинальном graphics.h на строке 302 встречается int right=0 — это вызывает ошибку компиляции. Исправляется заменой на int txtright=0.

Dev-C++

1. Скопировать graphics.h и winbgim.h в MinGW64\x86_64-w64-mingw32\include

2. Скопировать libbgi.a в ...\lib

3. Tools → Compiler Options → Parameters → Linker — вставить флаги

4. Переключить профиль компилятора на 32-bit Release

Code::Blocks

1. Файлы — в соответствующие папки include и lib компилятора MinGW

2. Settings → Compiler → Linker settings → Other linker options — вставить флаги

VS Code

Файлы хранятся внутри проекта. Структура:

project/
  include/  ← graphics.h, winbgim.h
  lib/      ← libbgi.a

В .vscode/tasks.json в массив args добавить:

"-I${workspaceFolder}/include",
"-L${workspaceFolder}/lib",
"-l"-I${workspaceFolder}/include",
"-L${workspaceFolder}/lib",
"-lbgi", "-lgdi32", "-lcomdlg32", "-luuid", "-loleaut32", "-lole32"
bgi", "-lgdi32", "-lcomdlg32", "-luuid", "-loleaut32", "-lole32"

Компилятор MinGW (g++) должен быть прописан в PATH.

По материалам видео-инструкции CodeWar

Тест

#include <graphics.h>
#include <conio.h>

int main() {
    int gd = DETECT, gm;
    initgraph(&gd, &gm, (char*)"");
    circle(250, 250, 100);
    getch();
    closegraph();
    return 0;
}

Должно открыться окно с белым кругом на чёрном фоне. Если компиляция падает с ошибкой cannot find -lbgi — проверьте путь до libbgi.a. Ошибка undefined reference обычно означает, что флаги линкера не подхватились.

Не успел я начать вести свой лингвоблог на Хабре, как у меня неожиданно появился первый коммерческий проект, связанный с лингвистикой — причём не компьютерной или "переводческой", а вполне себе как я люблю, с поиском закономерностей и мысленными экспериментами.

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

Был очень обрадован, что за плату можно позаниматься тем, что я и так обожаю делать. Коллеги из геймдева оказались очень любознательными и продуктивными, с интересом слушали мои мини-лекции по теоретическим аспектам в зуме и выполняли ооочень много "домашней работы" со словарями. Закрыли проект, взаимно довольные друг другом. К сожалению, записей языка в исполнении штатных дикторов услышать пока не удалось (только в своём произношении) — проект ещё в разработке, игровой мир ещё строится в остальных своих аспектах.

Но в целом история немного поучительная, потому что ещё раз показывает, что твоим коммерческим заказом может стать любое твоё нишевое увлечение — даже если у него не было коммерческих перспектив. Теперь подумываю развиваться дальше в этом направлении и заняться придумыванием артлангов на заказ. Пока сделаю похожий проект для себя и для души (coming soon!) — а там видно будет))