Интервью

Неисповедимы пути ©
Как проектирование ЧПУ станков довело
до церковнославянского справочника.
И неясно, куда занесет ещё.

Я инженер. Работаю с достаточно сложными проектами в нефтянке
в роли СТО да проектного менеджера с упором на технические вопросы.
Всякое там ТОиР, стройка, проектирование, производство, КиП и тому подобное

Как частный личный проект с год назад с товарищами
задумали и начали делать 3–4 осевые ЧПУ станки небольших форматов.
Итогом добрались до церковнославянского сайта‑справочника и нейросеток.
Грабли банальные, если оглядываться назад и, видимо,
для многих «в теме» очевидные. Но мы по ним
оттоптались знатно. Думаю — будет еще много

Логика странная, но есть.
1. Для отработки конструкционных решений — нужно делать тесты.
Для наших ЧПУ — что‑то с большим количеством мелких элементов,
достаточно объемное и сложное. При этом недорогое и, чтоб не в мусор,
если получается что‑то приятное. Ибо обидно выкидывать.
Случайно наткнулись на православные иконы из дерева.
Подходит. Пробуем. Для отработки нюансов с ЧПУ оказалось шикарно.

2. Проект нежданно расширился в сторону производства икон. Ибо интересно.
Наловили кучу факапов и тонкостей с материалами, фрезами, химией.
Будучи агностиками по сути, реально получаем удовольствие. Факт.
Выяснилось, что тут свой большой объемный и непростой мир. Забавно.
Кардинально пересмотрели некоторые инженерные решения по станкам. Cool

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

4. Проект расширился снова, теперь в програминг для станков. Оказалось,
что есть глобальная разница в G‑code для станка по разному сделанного.
Одна и та‑же модель на одном железе дает кратно разные результаты.
Итогом курсы, обучение, тесты, бессонные ночи и в 2 раза меньше
машинного времени при сильно лучшем результате на той‑же «базе»
Ибо 28 часов работы станка на одно изделие, и 15 таки
существенная разница по всем понятиям.

5. И снова проект расширился. Теперь в сторону информационную.
При всей «банальности» иконы как объекта, нашлась уйма нюансов.
Оказалось, что все сильно непросто в части надписей, шрифтов,
расположений элементов и тому подобных «мелочей». И даже
в епархиях часто спорят и не знают, как «правильно» и «нужно».
Итогом — сайт‑справочник, с надписями, словарем, шрифтами,
написанием и кучей новых (для нас) знаний о старославянском.

6. И снова расширение. Потому что моделей уже сотни,
вариантов куча, программы разные, фото‑видео копятся.
Нужно это все каким‑то образом хранить, холить и лееять.
Да и показывать надо порой выбранные вещи, что уже сложно
в части оперативного поиска да выборки. Банальные каталоги
где‑то на облаке не рабочее решение. Увы.
И снова в помощь codex да grok, и снова
очередной проект, теперь хранилища.

Зачем пишу?
Поделиться очередной иллюстрацией того,
как жизнь порой разворачивается в странные
и забавные проекты, задачи, решения, контакты.
Как относительно простой проект вдруг превращается
превращается, превращается в шорты © в какую‑то экосистему,
и укапывание в неизвестные досель области знаний.

И так...

Две статьи с полным разбором найма в IT позади (раз, два), цифры и графики посмотрели. Но всё равно, статистика это конечно хорошо, но пока не натыкается на живого человека с конкретной историей.

Я запустил сбор реальных историй найма в IT-шечку))

У меня уже есть несколько крутых историй: Ветеринар, который дорос до дата-аналитика в банке и застрял на "теневом айти", тимлид, которого молча назначили руководить отделом, системный аналитик, прошедший 5 кругов собеса в Т-Банке только чтобы услышать "мы взяли внутреннего кандидата" и рассказ о том как устроен коучинг в найме IT, за полторы месячные зарплаты!!!. Всё это не укладывается ни в какую аналитику.

По этому:

Хочу собрать из таких историй отдельный материал, что-то вроде "IT-найм 2026 года глазами тех, кто через него прошёл".

Так что если за последние полгода ты искал работу в IT, удачно или нет (не важно) - напиши мне в личку.

Конечно же я всё обезличу)) Шаблона нет, по этому в свободной форме, вот как душа захочет рассказать так и рассказывайте... Примерно публикацию планирую на 14-ое сентября)

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

Обсудили модели, агентов и наступившее будущее с автором Telegram-канала Dealer․AI

В очередной выпуск подкаста в гости к нашему директору департамента стратегического развития ИИ-продуктов Диме Юдину пришел Александр Абрамов, Head of AI и автор Telegram-канала Dealer․AI. Поговорили о мире ИИ — от практики до агентной экономики и будущего технологий. 

Что обсудили:

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

• можно ли доверить свой бизнес полностью ИИ-агентам;

• перспективы агентной экономики;

• парадигму обучения ИИ;

• токен-экономику и как оптимизировать расходы;

• ИИ в кино, новые профессии и наше будущее.

Смотрите на удобной площадке: YouTube | VK Видео | Rutube

Мы запускаем новый подкаст!

Пилотный выпуск подкаста «Путь ИИ» — о том, как трансформировать бизнес с помощью искусственного интеллекта. Ведущие — Алексей Белкин, основатель belkin.digital и ex Chief Data Scientist блока «Финансы» Сбера, и Максим Ульянов, руководитель клиентской разработки RUTUBE и автор подкаста «Куда расти?». В этом выпуске разбираем методологию Vibe Evolve: девять принципов агентизации бизнеса, почему 90% AI-пилотов проваливаются и как научить компанию пересобирать саму себя быстрее конкурентов.

Из выпуска вы узнаете:

• Почему 90% AI-пилотов проваливаются и что не так с подходом «от технологии, а не от результата»?

• Что случится с офисными профессиями, когда агенты возьмут на себя 80–90% работы?

• Как устроена компания будущего: один основатель с роем агентов или 30 человек во главе корпорации?

• Какие три качества нужны руководителю, чтобы управлять армией агентов вместо армии сотрудников?

• Зачем прогонять через ИИ все рабочие артефакты и почему отговорка «это агент накосячил» не принимается?

• Как собрать единый цифровой контекст, если он размазан по почте, CRM и головам сотрудников?

• Почему регламенты становятся программным кодом компании и перестают быть «бумажкой для аудиторов»?

• Что делать с персональными данными и legacy-системами при агентизации?

• Как работает цикл автоулучшения, в котором агент сам находит проблему и предлагает решение?

• С чего начать AI-трансформацию: четыре уровня внедрения от культурной нормы до сквозной автоматизации?

Приятного просмотра и прослушивания!

Смотреть на RUTUBE
Смотреть на YouTube
Слушать в Яндекс Музыке
Смотреть в VK Видео
Слушать в аудио

Полезные ссылки из подкаста:

Телеграм-канал «Путь ИИ» - https://t.me/belkin_digital
Телеграм-канал ULYANOV.LIFE - https://t.me/ulyanov_life
Сайт компании Алексея Белкина - https://belkin.digital
Методология Vibevolve - https://vibevolve.belkin.digital/

Зачем Битрикс24 своя AI-платформа?

Сергей Нотевский — AI Lead в Битрикс24, руководит платформой, на которой работает весь AI компании: от транскрибации звонков до агента BitrixGPT. В новом выпуске обсуждаем, стоит ли компании разворачивать нейросети у себя или брать их как сервис (MaaS), как посчитать железо под открытую модель, почему бенчмаркам нельзя верить, что такое префикс-кэш, и при чём здесь четыре года работы фитнес-тренером.

Из выпуска вы узнаете:

• Чем разработка с AI похожа на менеджмент и кого из инженеров заменят первым?

• Как войти в IT без денег на курсы — по самодельной программе за два месяца?

• Почему Битрикс24 развернул модели у себя и что это даёт клиентам?

• Что такое MaaS (Model-as-a-Service) и за что вы на самом деле платите в цене токена?

• Как посчитать, сколько GPU-памяти нужно модели, и при чём здесь квантизация?

• Почему большое контекстное окно не гарантирует качество и что такое «гниение контекста»?

• Зачем писать свои тесты для моделей и почему бенчмаркам из релизов верить нельзя?

• Что такое префикс-кэш и как он экономит до 95% стоимости входящих токенов?

• Какие роли нужны в команде AI-платформы и что такое харнес (Harness)?

• Куда расти инженеру в эпоху AI и какой навык теперь важнее конкретных знаний?

Рекомендую выпуск особенно тем, у кого сейчас остро стоит вопрос, разворачивать ли нейросети внутри своего контура. В этом выпуске мы собрали подробный гайд по теме self-hosted AI.

Приятного просмотра и прослушивания!

Смотреть на RUTUBE
Смотреть на YouTube
Слушать в Яндекс Музыке
Смотреть в VK Видео
Слушать в аудио

Полезные ссылки из подкаста:

Битрикс24 — https://www.bitrix24.ru
Битрикс24 Вайбкод — https://vibecode.bitrix24.tech/
Вакансии в Битрикс24 — https://careers.bitrix24.ru/
LMArena (бывш. LMSYS Arena) — https://arena.ai
Context Arena — https://contextarena.ai/
LangFuse — https://langfuse.com/
Статья команды Manus про префикс-кэш — https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus

Ставьте реакции, жмите колокольчики, шерьте друзьям и коллегам, и конечно же, пишите обратную связь, потому что это все поможет мне продолжать и улучшаться. 🙏

Меня зовут Максим Ульянов, я руковожу отделом веб-разработки в RUTUBE, отвечаю за все браузерные интерфейсы: сайта rutube.ru, студии блогеров studio.rutube.ru, всех сателлитов и внутренних продуктов платформы. В свободное время я веду подкасты «Куда расти?» и «Путь ИИ», а так же пишу в Telegram-канале ULYANOV.LIFE про жизнь руководителя в ИТ. Буду рад вашим комментариям и обратной связи!

Топ-5 нелепых вопросов на собеседовании и РЕАЛЬНЫЕ ответы на них

Или рубрика «если бы кандидаты говорили правду на собеседовании».

1.      «Вы очень хорошо справились с тестовым заданием, но почему вы прислали его в последний момент?»

Долго думала, хочу ли делать неоплачиваемое тестовое задание, которое прислали через ПОЛГОДА после отклика на вакансию. Кстати, я чудом увидела ваше письмо и вспомнила, кто вы. И да, я прислала задание за 3 часа 8 минут ДО ДЕДЛАЙНА. Последний это момент или нет – вопрос дискуссионный...

2.      «Вы не работаете с октября. И на что же вы живете?»

Эм… честно говоря, не ваше дело. Может, наследство. Или трастовый фонд. Накопления. Помощь родителей. Деньги мужа. Донаты. Подработка. Да может я живу на улице и мне нечего есть? Вопрос звучит как обвинение.

3.      «У вас такое сильное резюме. Почему вас еще никто к себе не забрал? Так сказать, не оторвал с руками и ногами?»

Даже не знаю. Наверное, опыта слишком много. Или слишком мало. Может половина вакансий, на которые я откликалась, это фейк. Или я просто счастливее, жизнерадостнее, моложе, умнее, самодостаточнее или красивее своих потенциальных руководителей/девушек из HR. Сказать сложно, не так ли?

4.      «Тестовое хорошее, но я вижу, что при выполнении тестового задания вы использовали ИИ для генерации юмора. Это так?»

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

5.      «Почему вы всю жизнь учитесь? Как так вышло?»

Потому что дед всегда говорил мне «учись». И вообще «education is not preparation for life, education is life itself» (в переводе «образование – это не подготовка к жизни, образование – это и есть жизнь»). Табличка с этой фразой Джона Дьюи висит на входе в университет Сан-Диего, где мой папа учил английский язык много лет назад. Тот факт, что вы задаете вопрос «Почему вы учитесь?» говорит о том, что… мы с вами очень разные люди.

P.S. где проходит грань между собеседованием и допросом? Вроде бы поиск работы – привычное дело. Отклики, собеседования, офферы, отказы… Да, ты в состоянии неопределенности. Да, вакансии/HR/настроение бывают разные. Но иногда бывают собеседования, после которых ты чувствуешь себя просто куском говядины. Ощущение, что тебя использовали, сняли матрицу и присвоили тестовое задание. Вот как после этого вновь и вновь качественно, с душой продолжать делать тестовые, ходить на собеседования? Ответа нет…

Извините все, не удержалась.

Оффбординг: процесс, о котором все молчат — и зря

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

В новом выпуске «Свободного слота» — Вера Маневич, директор по IT-персоналу в Ozon. Говорим про увольнение честно: с обеих сторон, с личным опытом и без попыток сделать вид, что всё всегда проходит гладко.

Что обсудили

Почему стоимость оффбординга может достигать 200% годового дохода сотрудника — и кто об этом вообще думает заранее. Сколько времени реально нужно на передачу дел и как договориться об этом, не превращая последние недели в ад. Что делать, если человек уходит внезапно — или внезапно передумывает. Как доносить решение команде и что она на самом деле знает об уходе коллеги. Ну и личное: от слёз в переговорной до «лучшего увольнения в жизни».

Слушайте и смотрите новый выпуск на площадках:

📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave

Ещё больше новостей — в нашем телеграм-канале

«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать

Неделю назад КиберËж проводил CyberWeekend (где там правда викенд они нашли в начале недели, я не знаю 😂) и, в том числе, пригласили меня побеседовать про Программно-аппаратный хакинг как одно из самых сложных и интересных направлений в кибербезопасности, объединяющее знания из программирования, электроники, сетей, встроенных систем и реверс-инжиниринга.

В рамках диалога мы с Павлом осветили такие темы, как:
* Почему специалистов в этой области так мало и чем они занимаются на практике.
* Почему искусственный интеллект пока не способен заменить экспертов по аппаратному хакингу: работа с реальными устройствами требует опыта, интуиции и нестандартного мышления.
* Как после 2022 года изменились основные направления атак и почему всё больше внимания уделяется IoT-устройствам и объектам физической инфраструктуры.
* Какие навыки стоит развивать уже сегодня тем, кто интересуется IT, электроникой и информационной безопасностью.

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

Ну и конечно же, интервью можно легко посмотреть в 📺 ВКвидео.

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Конец скучным новостям, новое поколение журналистов - цирковая экспрессия

Это какой-то цирковой номер, а не просто интервью - так с нами общались английские журналистки.

Вообще-то они занимаются отнюдь не театрами, это известные IT-блогеры. На стенде Спецлаб их заинтересовали ИИ-технологии.

Олеся Гришанина
=Спецлаб=

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

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

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

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

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

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

🔵 VK Видео
📺 YouTube
📌 Rutube

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

Собеседование. Часть 3: Магия коллекций в Kotlin — от лямбд до скрытых аллокаций

В прошлых частях мы препарировали алгоритмы и заглянули под капот хэш-таблиц. Сегодня поговорим о том, за что разработчики так искренне любят Kotlin — о коллекциях.

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

Уровень 1: Синтаксический сахар и интерфейсы

Я спрашиваю: «В чем фундаментальная разница между List и MutableList в Kotlin?» Ожидаемый ответ: Kotlin изящно разделил интерфейсы на читаемые (read-only) и изменяемые. У List просто нет методов add или remove. Это спасает нас от случайных мутаций состояния, особенно когда мы гоняем данные в реактивном UI.

Далее переходим к функциям-расширениям. Кандидат пишет классическую цепочку: users.filter { it.age > 18 }.map { it.name }

Выглядит чисто. Здесь же я подкидываю вопрос про reduce и fold. Оба метода сворачивают коллекцию, но если кандидат бездумно использует reduce, я с легкой улыбкой спрашиваю: «А что будет, если список окажется пустым?» Будет больно и UnsupportedOperationException. Поэтому fold с его стартовым значением — выбор тех, кто хочет спать спокойно.

Уровень 2: Срываем покровы компилятора

Когда кандидат уверенно жонглирует лямбдами, пора заглянуть под капот. Я задаю вопрос: «А что конкретно создается в памяти, когда ты вызываешь listOf(1, 2, 3) или mapOf(1 to "A")?»

Многие верят в уникальную магию Kotlin. Но продвинутый разработчик знает, что мы всё еще живем в мире JVM.

• mapOf() под капотом вернет java.util.LinkedHashMap. Но! Контракт Map не гарантирует сохранение порядка. Если вам критически важен порядок вставки, не надейтесь на реализацию «под капотом» — пишите linkedMapOf() явно, иначе в один прекрасный день обновление языка сломает вам логику.

• listOf(1, 2, 3) вернет не обычный java.util.ArrayList. Он вернет внутренний класс java.util.Arrays$ArrayList. И разница тут колоссальная. Это fixed-size обертка над массивом. Если любитель хардкора решит сделать (list as MutableList).add(4), он моментально получит краш в рантайме.

Далее вопрос на засыпку: «Если мы в цикле вызываем filter { ... }, не убиваем ли мы Garbage Collector созданием анонимных классов для лямбд?» Отличный кандидат вспомнит про модификатор inline. Компилятор физически вставляет тело функции в место вызова, поэтому аллокации объектов лямбд не происходит.

Уровень 3: Экспертный взгляд и ловушка Sequences

Вроде бы inline нас спас? И да, и нет. Тут начинается территория архитектуры и производительности. Я возвращаю кандидата к его коду: users.filter { it.age > 18 }.map { it.name }

«Модификатор inline спас нас от лямбд, — говорю я. — Но что будет, если в списке 100 000 юзеров? Что произойдет с памятью?»

Эксперт должен увидеть угрозу: каждая стандартная функция (filter, map) создает новую промежуточную коллекцию. Сначала создастся список из 50 000 взрослых юзеров, а потом еще один из 50 000 их имен. Это колоссальная аллокация памяти.

«Как этого избежать?» Ответ: использовать Sequences — users.asSequence().filter {...}.map {...}.toList(). Последовательности работают лениво, протаскивая каждый элемент по цепочке поштучно, без создания огромных временных списков.

Финальная ловушка. Я спрашиваю: «Значит ли это, что нужно использовать asSequence() вообще везде?» Истинный эксперт скажет: Нет. У Sequence есть свои скрытые налоги: создание объектов-оберток (TransformingSequence, FilteringSequence) и накладные расходы на виртуальные вызовы next()/hasNext() для каждого элемента. На коротких списках обычная цепочка filter/map отработает быстрее. Бенчмарки показывают, что Sequence начинает выигрывать только на объемах примерно от 1 000 элементов (в зависимости от тяжести цепочки). Не стоит заниматься преждевременной оптимизацией там, где она не нужна.

Резюме

Коллекции в Kotlin невероятно удобны. Но за синтаксический сахар всегда нужно платить. Важно видеть, как человек переходит от слепого восторга красивым кодом к прагматичному пониманию

Страх как продукт: почему мы до сих пор продаём ужас вместо ценности

Рынок ИБ до сих пор продаёт не защиту, а спокойный сон до следующего квартала. Страх стал валютой - от отчётов «80% компаний под угрозой» до тепловых карт, где всё красное. Ниже — ещё более сжатая выжимка: как устроена эта машина страха и чем её заменить.

Как страх стал главным продуктом:

Доказать эффект от ИБ трудно: мало данных, спорные методики, внутренняя политика сильнее формул. В результате страх стал универсальным инструментом: случился инцидент - рынок завален продуктами и отчётами «как раз от такой угрозы».

Классика жанра:

• Вирус уровня WannaCry использует старые уязвимости, но продаётся как «новая эра вымогателей и уникальных защит».

• Отчёты «80% компаний под угрозой» строятся на кривых опросах своей аудитории и заканчиваются «запросите демо/пилот».

FUD даёт краткосрочное внимание, но в долгую убивает доверие и либо ведёт к хаотичным покупкам «серебряных пуль», либо к апатии: всё кажется одинаково страшным.

Чеклист для CISO:

На любую страшилку ответьте:

1. Какой конкретный сценарий атаки описан?

2. Какова вероятность и ущерб именно для нашей компании?

3. Что изменится в нашей модели угроз, если мы это купим/внедрим?

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

Иммунитет CEO и красные тепловые карты:

У многих CEO уже аллергия на FUD-слайды «Россия в топ‑3 по атакам» и «каждая вторая компания пострадала».В ответ безопасники приносят тепловые карты, где половина клеток ярко‑красные.

Что реально происходит:

• Красный цвет мгновенно бьёт по инстинктам, один слайд перекрывает пачку таблиц.

• Но карта «всё красное» без чисел - это эмоциональный шантаж ради бюджета, а не управление рисками.

Что можно поправить быстро:

• У каждой «красной зоны» должны быть: сценарий, диапазон потерь и время простоя.

• Вместо абстрактных рейтингов - 2–3 реально возможных для вашего бизнеса кейса с понятными цифрами.

Медиа и «исследования»: аналитика или хоррор:

ИБ‑медиа и вендорские отчёты - крупная шестерёнка машины страха.
По оценкам редакторов, 90–95% исследований делаются ради продвижения продукта: методика мутная, цифры разных отчётов по одной теме могут расходиться на порядки.

Полезно:

• Читать аналитику по реально эксплуатируемым уязвимостям и zero‑day в массовых продуктах.

• Разборы реальных инцидентов - их мало, но именно они меняют практику.

Вредно:

• Разгонять фейки, неподтверждённые сливы и «80% под угрозой» без описания выборки.

Фильтр для отчётов

Один вопрос: «Эта цифра способна изменить наше решение?»
Если нет - перед вами маркетинг, а не аналитика.

Регулятор против хакера: чей страх сильнее:

У российского заказчика два фронта: хакеры и регулятор.

Факты:

• 60–70% бюджетов ИБ уходит на комплаенс (приказы, ГОСТы, 152‑ФЗ, отраслевые требования).

• Остаток - на «живую» защиту: SOC, мониторинг, сегментацию, реагирование.

Почему страх регулятора побеждает:

• Атака - вероятностна, может и не случиться.

• Проверка - гарантирована, с датой и понятными санкциями.

• Мини-действие

  • Разложите бюджет на «комплаенс» и «реальную защиту».

  • В каждый комплаенс‑проект заложите хотя бы одну меру, которая действительно снижает риск.

  Как уйти от продажи страха к продаже ценности:

  Нужный сдвиг: от управления страхами - к управлению рисками и бизнес‑ценностью.

  На практике:

  • Переводите «страшно» в «сколько стоит и что конкретно делаем в ответ».

  • Привязывайте ИБ к бизнес‑метрикам: простои, выручка, операционные издержки, скорость изменений.

  • Используйте новости и инциденты как материал для обучения и улучшений, а не как повод продавить очередную «серебряную пулю».

  Если вы:

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

  • Хоть раз в неделю спросите команду: «Мы сейчас управляем риском или реагируем на хорошо проданный страх?» - значит, вы уже выходите из режима «страх как продукт» и начинаете говорить с бизнесом на взрослом языке.

  А у вас решения по ИБ сейчас чаще объясняют «по регулятору надо», «видели страшный кейс» или нормальным разговором про риски и деньги?

Этот пост ждал своего часа. Я даже хотела, чтобы обстоятельства сложились именно так: сегодня мне отказали по вакансии, потому что я использую ИИ в работе. Одна компания, с которой мне доводилось работать в 2022–2025 годах над одним большим проектом, позвала меня на интервью, потому что мой опыт в разработке правовых конструкций максимально релевантен запросу по их вакансии.

Дальше было тестовое. После него я получила вопрос от HR: использовала ли я ИИ при подготовке тестового задания? Вопрос обычный, вроде бы, да? Ну и я с гордостью заявляю, что в свои 29 могу позволить себе оплатить пару подписок, навайбкодить мини-агента-аналитика-Анастасию и вместе с ним двигаться по рабочим процессам в три раза быстрее первоначальной скорости (которая, если что, уже с лет с 16 была вполне себе очень высокой).

Дальше все как в тумане: странный вопрос на предмет «следов ИИ», хотя я вроде не данные обрабатывала для дашбордика, созвон, на котором я объясняю весь процесс работы с LLM: от того, что такое Claude, до того, как промптить правовые задачи. Потом пресловутый откат в стиле: «Мы не знаем, когда руководитель вернется с ответом».

И тут я задумалась: неужели для российской действительности все еще НЕ круто, когда сотрудники пользуются языковыми моделями? Причем какие сотрудники - сильно не джуны и даже не мидлы. С этого момента я начала ждать отказ. Я даже очень его хотела. Хотела, чтобы моя гипотеза подтвердилась и чтобы я впредь знала: можно обернуть мою совместную с нейронкой работу в конфетку, которую я без зазрения совести продам как что-то «уникальное». «Да-да, я сама выровняла все в документе, раскрасила все шильдики и пронумеровала пункты глоссария» (ага, делать мне нечего, извините).

И вот сегодня я наконец-то получила отказ. Отказ на позицию, для которой (со слов руководителя, с которой мы непринужденно болтали об общих правовых болях) подходила идеально - как пазл в картинку, где сплошное голубое небо. Несостоявшийся руководитель сопроводила звонком и уточнила, что коллеги ищут сотрудника, который в состоянии работать без нейронок. Понимаю, очень (но не совсем)! Однако.. эти же коллеги видели и знают уровень моей работы в ДОLLMную эпоху, хихик).

Зато теперь я знаю, как удивлять российских НЕтехнических специалистов: fake it till you make it в той реальности по прежнему работает как часы.

🧠 Топовый сайт для подготовки к собеседованию

Я хотел порешать задачи по System Design и нашел нефть hellointerview.com.

Расскажу про основные плюсы сайта:

1. Материал без воды, но при этом сложные темы раскрыты очень подробно

2. Видео и статьи, где вам рисуют диаграммы и детально объясняют решения

3. Куча практики, где ваше решение проверяет ИИ (и делает это реально хорошо)

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

Если вам интересно, как под капотом работают Google Docs или Elasticsearch, вам сюда.

Еще на сайте есть:

1. Low Level Design (Object-Oriented Design) Тут тоже отличные практические задачи и теория строго по делу. Чего только стоит эта фраза о полезности ООП-паттернов:

Most online resources still dutifully list all 23 GoF patterns like they’re equally important. They’re not.

2. Code (алгоритмы и структуры данных) Тоже полный фарш - статьи, видео с визуализацией алгоритмов и много практики.

3. ML System Design, Behavioral, AI Coding, Salary Negotiation и гайды по интервью в FAANG.

Сайт платный и на английском. Из рф купить его, скорее всего, нельзя, но есть русская копипаста - nowinterview.ru (правда, тоже платная).

👨‍💻 Джуниор

Создатель Sphinx — о 25 годах в инженерии, провале бизнес-модели и жизни внутри Авито

Новый выпуск подкаста AviTalk — разговор с Андреем Аксёновым, автором поискового движка Sphinx и руководителем группы инфраструктуры поиска в Авито.

Sphinx появился в 2001 году — тогда Андрей хотел просто сделать поиск по сайту с текстами песен, а готовых решений не было. Движок оказался лучше того, что было на рынке, и в итоге превратился в один из самых известных open source-проектов российского IT, который лёг в основу поиска Авито.

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

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

Ведёт выпуск Виктор Раев, руководитель разработки юнита Services Base.

Смотрите выпуск на платформах: 

📺 YouTube
🔵 ВК Видео
📌 RuTube

Весна крови. Гонзо-очерк №1

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

Вот так и со мной.

Сейчас весна 2026-го. Я сижу и думаю: тот вид журналистики, что я выбрал, стал для меня сакральным вопросом. Где я окажусь? Зависит от вас? Если ты читаешь это — значит, у нас с тобой получилось.

На улице уже почти совсем хорошо. Люди теряются кто где. Кто-то идет в пуховике, а замерзающие дурни смотрят на него с презрением, не беря в расчет мысли о собственной тупости. Каждый виноват — но не я.

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

Цветы пробиваются из-под земли. Много мусора. Очень много. Его уберут — и всё станет снова красивым. Или трава вырастет так высоко, что он перестанет быть виден.

И да. Эти мерзкие твари.

Сегодня со лба своей ручной лисицы я достал клеща. Этот гад уцепился чуть выше переносицы — в самый лоб. Идеальное место для маскировки, ха! Наверное, у меня есть доля нездорового внимания к таким паразитам. Только увидишь — и начинаешь весь чесаться. Фе. Пришлось рассматривать мерзость под микроскопом. Несмотря на всю технику вываживания кровопийцы, прыткий гад мог оставить подарок в виде отломанного хоботка под кожей лисички. Но всё обошлось. Каждый остался при своем. Разве что клеща пришлось денатурализировать — но его мнения никто не спрашивал.

Отвлекся больше, чем следовало. Вернемся к предмету.

Весна. Эх, она бьет ключом в моих венах. Зажигает сердце и словно барабан стучит в висках: беги! Беги! Скорее! Улица! Птицы! Запахи! Девочки, мальчики! Весна оживляет всё на свете. Серые столбы деревьев на фоне таких же серых домов и дорог — и тут бам! Контрастное зеленое нечто под ногами. Словно океан, молодая короткая трава увлекает меня.

Я должен идти. Я должен делать то, что должен.

И с этого момента — наверное — начинается моя история. История, с которой начинается всё.

Питер Штайнбергер пишет код не в Claude Code. Для многих это окажется неожиданностью, поскольку его проект OpenClaw был задуман в первую очередь как прокладка для общения с большими языковыми моделями компании Anthropic — в том числе в те периоды, когда этот самопис назывался warelay, Clawdbot или Moltbot. Тем не менее разработку Питер предпочитает вести в Codex компании OpenAI.

Прожорливый на токены и максимально небезопасный продукт привлёк внимания много и сразу. Энтузиасты по всему миру срочно ставят чат-бота на Mac mini и виртуальные серверы, чтобы потратить как можно больше токенов языковой модели Claude Opus. Зашла даже речь о продаже проекта. Как известно по интервью, Штайнбергер всерьёз рассматривает предложения приобрести OpenClaw и для этого выдвигает обязательное условие о сохранении открытости проекта. Утверждается, что наиболее интересные оферы поступили от Meta¹ и OpenAI, одних из самых крупных игроков в индустрии искусственного интеллекта.

Вообще, если следить за новостными лентами и его личным микроблогом, можно подумать, что Штайнбергер от дел отошёл, и просто бегает по интервью и встречам с фанатами. На самом деле разработка OpenClaw продолжается, новые версии выходят ежедневно, но и на подкасты про программирование время остаётся. (Ещё бы: Штайнбергер не пишет ни строчки кода, а просто промптит языковые модели — очень модный сейчас подход). К примеру, аккаунт OpenAI Developers обещает выпустить 23 февраля большое видеоинтервью с Питером, где тот расскажет про свой новый рабочий процесс с Codex. Пока что выложили просто небольшой тизер этого видеоролика.

Любопытно, что написал про это интервью сам Штайнбергер. Как он рассказывает, пришлось послать человека сбегать в магазин за новой футболкой — та, в которой австриец пришёл на съёмку, содержала логотип неназванной компании, и сотрудникам OpenAI подобное не понравилось. Штайнбергеру разве что дали выбор, в чём он будет на камере: либо в синей, либо серо-синей футболке.

Транснациональный холдинг Meta (1) — экстремисткая организация, его деятельность запрещена.

Большой разговор о том, что было и будет в мировой ИТ-индустрии

Смотрите наше интервью с Олегом Епишиным, директором «Инферит Техника».

В ролике — инсайдерский взгляд на бум ИИ, мировой кризис оперативной памяти, будущее России в кремниевой сфере и многое другое. Обещаем, будет интересно!

Видео доступно на всех наших площадках: VK, RUTUBE и YouTube. Смотрите, подписывайтесь и оставляйте комментарии.

Скоро — еще больше контента!

Почему мы до сих пор спрашиваем про пирамиду тестирования образца 2010 года

Провожу собеседования на позиции тестировщиков уже много лет. И заметил странную вещь: вопросы по теории не меняются вообще. Те же классы эквивалентности, те же граничные значения, та же пирамида тестирования. Как будто за окном не 2026 год, а 2010.

При этом реальная работа изменилась радикально. Половина команды использует нейросетевых агентов для генерации тестов. Автоматизация пишется в паре с ассистентом. Тест-дизайн делается через промпты. А на собеседовании мы всё ещё спрашиваем "чем отличается верификация от валидации".

Я не говорю, что классика не нужна. Нужна. Но если человек не понимает, как работать с агентами в 2026 году, он будет отставать от коллег с первого дня.

Поэтому собрал 10 тем, которые, на мой взгляд, пора добавить в раздел "теория тестирования" на собеседованиях. Полезно и тем, кто нанимает, и тем, кто ищет работу.

1. Промпт-инжиниринг для тестировщика

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

2. Валидация результатов работы агента

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

3. Границы применимости нейросетей в тестировании

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

4. Работа с контекстом

Как правильно передавать агенту информацию о проекте. Что такое контекстные файлы и зачем они нужны. Почему один и тот же запрос в разных условиях даёт разные результаты. Как не потерять контекст в длинном диалоге.

5. Этика использования нейросетей

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

6. Интеграция агентов в процесс тестирования

Как встроить работу с нейросетью в существующий рабочий процесс. На каких этапах агент полезен: планирование, написание тестов, анализ результатов, документирование. Как не превратить это в дополнительную работу вместо экономии времени.

7. Оценка качества сгенерированных тестов

По каким критериям оценивать тесты, которые написал агент. Покрытие, читаемость, поддерживаемость, соответствие стандартам команды. Как отличить хороший сгенерированный тест от плохого.

8. Работа с разными типами агентов

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

9. Ограничения и риски

Что может пойти не так при использовании агентов. Зависимость от внешних сервисов. Проблемы воспроизводимости результатов. Риск снижения собственной квалификации при чрезмерном делегировании. Как минимизировать эти риски.

10. Критическое мышление в эпоху нейросетей

Почему важно понимать, что делает агент, а не просто использовать результат. Как развивать экспертизу, когда рутину делает машина. Почему человек с глубоким пониманием предмета получит от агента лучший результат, чем новичок.

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

А какие темы про работу с нейросетями вы бы добавили в собеседование?

Звёзды разработки и практикующие инженеры разбирают горячие темы — от FAIL до GOD. Встречайте tech-шоу «АйТир Лист» от МойОфис.

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

Первый выпуск — опенсорс для фронтенда

Дебютный эпизод мы посвятили популярным опенсорс-решениям для фронтенда: от инструментов, которые давно пора отпускать, до стандартов индустрии.

В выпуске:

• Александр Коротаев — эксперт по фронтенду и креативному кодингу

• Алексей Золотых — тимлид команды веб-редакторов МойОфис

• Ведущий — Эдгар Акопян

Обсуждаем инструменты, которые формируют повседневную фронтенд-разработку, и честно отвечаем на вопрос: что сегодня выглядит как GOD-tier, а что застряло на уровне MVP или FAIL.

Смотрите выпуск: YouTube | RuTube | VK

Второй выпуск — фичи и идиомы C++

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

В выпуске:

• Данил Черепанов — архитектор редакторов МойОфис

• Антон Полухин — эксперт-разработчик C++ техплатформы городских сервисов Яндекс

• Ведущий — Эдгар Акопян

Получилось много споров, неожиданных аргументов и ситуаций, где «привычно» не значит «хорошо».

Смотрите и делитесь мнением: YouTube | RuTube | VK

В следующих выпусках продолжим разбирать технологии без скидок на хайп и «так исторически сложилось». Предлагайте темы, а если готовы к жарким спорам – становитесь участниками нашего шоу) А как стать? Пишите в комменты с какой темой бы хотели поспорить!