17 марта вебинар про сокращение техдолга и уязвимостей в AI-разработке
Искусственный интеллект — это не только про скорость разработки и генерации кода, это еще про баги, уязвимости и технический долг. На вебинаре на примере LLM и VS Code будем разбираться, как встроить большую языковую модель в разработку так, чтобы результат был предсказуемый и безопасный. Настроим IDE под ваш стиль, включим защитные ограничения от небезопасных действий и мониторинг качества и безопасности кода с помощью SonarQube.
Если тезисно, то вебинар ответит на три вопроса:
как быстро запустить и контролировать генерацию кода с LLM в VS Code в enterprise-подходе;
как при работе с LLM выстроить правила, ограничения и стандарты: стиль, безопасность, предсказуемость результата;
как настроить ранний контроль качества и безопасности через SonarQube и использовать MCP-серверы для более качественного кода.
Ждем всех, кто внедряет LLM в ежедневную разработку, отвечает за стандарты и качество кода, выстраивает безопасные практики разработки, оценивает риски использования LLM или отвечает за управляемость и предсказуемость разработки.
📅 Когда? Вторник, 17 марта, в 11:00 мск.
📍Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы экспертам в прямом эфире.
Кстати, это третий вебинар цикла «Сценарии применения AI в корпоративной среде», который начался в феврале. Записи первого и второго вебинара есть на сайте.
Разговоры вокруг отечественного связного 💬 Макс не унимаются с момента его официального выхода. Блогеры по всему миру "изучают" безопасность приложения, выискивая, куда он "ходит" и какую "секретную" информацию передает. В основном, все инфоповоды крутятся вокруг изучения манифеста приложения и его разрешений в системе, не углубляясь в изучение сетевых пакетов, исходники и декомпилляцию. А я как раз тот ленивый инфобезник, который еще ни разу не высказался относительно данного вопроса, поэтому исправляюсь.
В прошлую пятницу на весь 🇷🇺 российский интернет прогремела новость: все фото из ваших чатов в Макс может увидеть любой человек по ссылке.
Когда в личный чат или в папку «Избранное» в мессенджере загружается изображение, для него генерируется статичная гиперссылка. Ее можно найти в коде страницы в веб-версии Max. Эта ссылка открывается с других браузеров и устройств без авторизации в мессенджере - обнаружили пользователи. Более того, фото по ссылке останется в открытом доступе, даже если его удалить из переписки в Max.
На лицо классический IDOR. Но если мы проанализируем ссылки на фотографии, которые генерирует Макс, мы обнаружим, что изображения по ним действительно доступны без авторизации. Часть адреса у разных изображений совпадает, однако они содержат различающиеся подстроки длиной не менее 21 символа (минимум 16^21 комбинаций), а значит получить доступ к таким изображениям простым перебором адресов невозможно. Более того, EDR и WAF вас уже на 1000 запросе за несколько секунд обнаружат и отправят отдыхать минут на 5. Ну а про хранение файлов "закон Яровой" никто не отменял.
А знаете, где еще применяется такая технология? В недавно (октябрь 2024 года) заблокированном мессенджере Discord. Все медиа файлы из приложения можно открыть в исходном качестве по прямой ссылке без регистрации и смс (именно поэтому его многие использовали как файлообменник, а платформа ограничивала размер передаваемого файла 8 мегабайтами). И, о новость, если потом данный файл удалить, он все равно остается доступным по прямой ссылке (см. прилагаемое видео).
Возвращаясь к Максу, не могу не обратить внимание, что его разработчиком является крупнейший IT-гигант Mail.ru. Я лично принимал участие в тестировании его на безопасность в период 2020-2021 годах и могу с уверенностью сказать, что там более чем секьюрно. Кроме того, опыт в обеспечении безопасности ВК, ОК и других массовых продуктов у них уже в генах.
Более того, у Макса есть Bug Bounty программа от Bi.Zone и за некоторые уязвимости там выплачивают до 10 миллионов рублей:
Получение доступа к приватной переписке определенных пользователей - 10 000 000 ₽ Получение доступа к местоположению определенных пользователей в реальном времени - 4 000 000 ₽ Получение доступа к телефонной книге определенных пользователей - 2 000 000 ₽
За год существования программы, было реально найдено 13 багов, за которые суммарно выплатили 873 тысячи. При указанной выборке я могу сделать вывод, что Макс достаточно безопасен, раз никто пока не смог сорвать джек-пот.
Поэтому, не верьте всему тому, что пишут в интернете: делите все минимум на 10. Ну и конечно, что попадает в интернет - остается в интернете, поэтому не забывайте про цифровую гигиену.
Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.
Разработка: Оркестровка агентов по ролевым кластерам (MSF)
Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?
Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.
🧩 Смешанная модель
Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.
Агенты: берут на себя рутинные задачи, прозванивают целостность, генерируют код и тесты, моделируют сценарии.
Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.
🎭 Пример
Архитектор‑человек задаёт CASE‑скелет.
Vibe‑агент генерирует код по его намерению.
Тестировщик‑агент прогоняет сценарии.
Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».
Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.
🔧 Пример: смешанная команда разработки по MSF
Ситуация: корпорация запускает новый сервис аналитики.
Роли и участники
Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.
Vibe‑агент: генерирует код по намерению архитектора.
Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.
Координатор‑человек: принимает решение о переходе к следующему витку спирали.
Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».
Vibe‑агент генерирует код, интегрируя новый модуль в систему.
Тестировщик‑агент прогоняет тесты, выявляет узкие места.
Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».
Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».
Команда делает следующий виток спирали — добавляет новые функции.
Заключение
Это не «ИИ вместо людей» и не «люди без ИИ». Это ансамбль, где роли распределены между живыми и искусственными участниками. И именно такая смешанная команда даёт максимальную плотность: люди держат смысл, агенты — скорость и прозрачность.
CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки
Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.
Современная индустрия разработки ПО переживает переломный момент. С одной стороны — классические методологии, которые дают строгую архитектуру и прозрачные схемы. С другой — «вайб-кодинг», когда разработчик накидывает идеи в поток, а ИИ тут же генерирует код. Между ними — пропасть: Case методологии слишком формальные, вайб-кодинг слишком хаотичен.
Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.
CASE: скелет
CASE-модели позволяют фиксировать архитектуру системы: связи, блоки, уровни. Проблема в том, что переход от схемы к живому коду всегда был мучительным. Программисты ненавидели CASE за «рисование картинок», которые потом приходилось вручную превращать в тысячи строк.
Vibe Coding: энергия
Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.
MSF: спираль
Microsoft Solutions Framework изначально создавался как гибкая методология управления проектами. Его спиральная модель идеально ложится на задачу балансировки изменений: каждый виток фиксирует достигнутое, проверяет целостность и готовит систему к следующему шагу.
ИИ: мост
ИИ становится универсальным переводчиком. Он умеет:
превращать вайб в CASE-модель;
разворачивать CASE в рабочий код;
делать обратный ход — извлекать архитектуру из существующего кода;
проверять целостность пирамиды при каждом изменении.
Что это даёт
Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.
Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.
Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.
Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.
Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.
Эффект для индустрии
Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.
Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.
Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.
Заключение
CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.
Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.
И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.
Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять. — WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять. — Почему? — Например, потому, что практически любой WAF можно обойти. — А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью. В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
Ааа! Я не могу это смотреть! "В чём отличие внешнего ключа от внутреннего?" Или вопрос в Сбере на з.п в 200 косарей (руб/мес если чё): "что такое гит".
Дебилы собеседуют дебилов. Видимо, соревнуются в своей дебильности. Отрицательный отбор в действии.
Я конечно, давно понял, что в больших ИТ-компаниях изрядная доля штата с ОЧЕНЬ низкой квалификацией, но чтобы вот такой убогий уровень - это даже не плинтуса ниже, это ниже уровня пола. Таких ИИ конечно обделает, как можно проиграть абсолютному нулю?
Там описал утилиту sumr, которая саммаризирует файлы проекта через LLM и выдаёт дерево с однострочными описаниями. Коротко: запускаешь sumr в корне — и она выдает структуру папок и файлов с кратким описанием каждого элемента. Это помогает AI-агенту быстро понять, что где находится, без необходимости читать весь код.
Что добавил с тех пор:
Теперь инструмент держит кэш у себя и не трогает ваш проект.
Добавил watch mode. Достаточно запустить sumr watch или sumr watch --detach на папке с проектом — и утилита начинает следить за изменениями. Появился новый файл или изменился существующий — саммари обновляется автоматически. Не нужно каждый раз вручную перезапускать. Запустил один раз в фоне и забыл.
Ещё добавил два флага: -p для указания конкретной папки и -d для ограничения глубины дерева, как tree -L. Их можно комбинировать:
sumr -p ./src # начать с конкретной папки
sumr -d 2 # показать только 2 уровня глубины (как tree -L 2)
sumr -p ./src -d 1 # папки верхнего уровня с саммари
После запуска watch в инструкцию CLAUDE.md добавил рекомендацию:
* Всегда начинай ЛЮБУЮ задачу с команды 'sumr -p ./... -d ...' для получения общей структуры проекта и понимания, где что находится.
Вот примеры использования команды sumr:
sumr -p ./src # начать с конкретной папки
sumr -d 2 # показать только 2 уровня глубины (как tree -L 2)
sumr -p ./src -d 1 # папки верхнего уровня с саммари
И это действительно работает на моих проектах - буквально 1 read корня - 2 read подпапки - старт выполнения задачи :)
В октябре 2025 года в сети распространился ролик,в котором девушка расплачивается улыбкой, используя ... фотографию своего знакомого. Комментаторы, как обычно, разделились на 2 лагеря: на обывателей, которые чихвостят "систему", и технических специалистов, утверждающих, что это фейк. Ну а мы давайте теоретически разберемся, что это и как такое в принципе возможно.
«Оплата улыбкой» — это сервис Сбербанка, который позволяет оплачивать покупки на кассах в магазинах с помощью биометрии. Проект был запущен летом 2023 года как альтернатива ушедшим с рынка платежным сервисам... Для оплаты нужно посмотреть в камеру, которая распознает изображение лица и сопоставляет его с уникальным номером, привязанным к биометрическим данным. Этот номер также привязан к счету карты. Если данные совпадают, оплата проходит. (с) РБК
Вообще, распознавание лиц в биометрических системах обычно работает как конвейер из нескольких шагов. Верхнеуровнево порядок следующий:
Набор камер получает кадр лица
Алгоритм находит лицо на изображении (рамку вокруг лица)
Система ищет ключевые точки (глаза, нос, уголки рта) и “выравнивает” лицо
Нейросеть преобразует лицо в вектор признаков (эмбеддинг) — набор чисел, который компактно описывает уникальные черты
Дальше считается “близость” двух векторов, например, косинусное сходство или евклидова дистанция: если сходство выше порога, то доступ/оплата разрешена.
Системы безопасности в таких устройствах настроены на защиту от подстановки фотографий, масок, а также добавляют проверки на "человечность". Так, системы анализируют блики и глубину, микродвижения, отражения от ИК-камера (кожа и материалы отражают по-разному); определяют объемность и т.д. Поэтому, в профессиональных системах биометрии обычно используется нескольких камер: • обычная RGB: получение изображения лица • ИК: даёт надёжную проверку "человечности" • глубина (3D/ToF): уверенное отделение “лица” от плоской подделки.
Возвращаясь к видео: если мы внимательно изучим аппаратную часть представленного PoS-терминала (можем даже сходить в ближайший магазин и физически его потрогать), то обнаружим только 1 обычную RGB камеру для селфи. В таких обстоятельствах программно-аппаратный комплекс не может провести дополнительные вышеуказанные проверки и надеется только на изображение. В таких обстоятельствах, как показывает международная практика, система может верифицировать злоумышленника по чужой фотографии, видео или даже маске.
При изложенных обстоятельствах, я бы предположил, что видео более похоже на правду, чем на фейк и не рекомендовал бы пользоваться функцией "Оплатить улыбкой" пока все терминалы оплаты не будут оснащены современным техническим оборудованием.
Корректные ссылки из приложения. Раньше ссылки на статью или каталог копировались как https://app.gram.ax/repo-name.... Теперь приложение подставляет домен вашей компании (где развернут веб-редактор), поэтому ссылки ведут в приложение в вашем контуре.
Фильтр по файламв поиске. Добавили режимы «Без вложений», «С вложениями» и «Только во вложениях», чтобы искать не только по тексту статей, но и по содержимому PDF и DOCX-файлов.
Другие улучшения:
Автоматическое решение конфликтов в комментариях. Если несколько пользователей одновременно отвечают или редактируют один и тот же комментарий, изменения корректно объединяются и не ломают комментарии. В связи с этим в «Проверить на ошибки» появился пункт «Комментарии» — он показывает статьи с комментариями, которые не привязаны ни к одному блоку.
Улучшения поиска:
Поиск стал быстрее. Ускорили примерно в 2 раза и оптимизировали индексацию.
Обязательные слова в запросе. Добавили оператор +: поставьте его перед словом или фразой, и они точно будут учитываться в результатах.
Окно поиска по статье сохраняет состояние. При переходе между статьями окно закрывается, но при повторном открытии сохраняется введенный текст (пока приложение открыто).
ИИ-поиск стал точнее. Мы улучшили RAG, поэтому ответы в поиске стали более релевантными и полезными. Подробнее — в статье на Хабре.
Инлайн-тулбар в комментариях, сниппетах и шаблонах. Теперь над полем ввода комментария доступно базовое форматирование: жирный, курсив, код и вставка ссылок. А в редакторе сниппетов и шаблонах появился полный набор инструментов, включая редактирование таблиц.
Превью Excel-файлов. Теперь Excel-файлы можно открыть в режиме предпросмотра: при клике отображается превью в модальном окне.
Быстрая публикация. Список изменений загружается в 3 раза быстрее.
Автоматическое обновление ссылок при редактировании. Если вы меняете текст ссылки и он совпадает с ее адресом, адрес тоже обновится. Если текст и адрес разные — ссылка не меняется.
Сохранение позиции прокрутки между статьями. Если вы перешли в другую статью и вернулись назад, статья откроется там, где вы остановились, а не в начале.
Версия приложения в деталях ошибки. Это помогает быстрее понять, на какой версии возникла проблема и быстрее ее воспроизвести.
Исправление уязвимостей. Теперь перед выпуском новых версий мы автоматически проверяем используемые библиотеки на известные уязвимости.
Как перенести AI-платформу из‑за рубежа в Россию и не переписать код: кейс Worken AI
👨💻 Что за компания
Worken AI — разработчик одноименной платформы, на которой пользователи создают или выбирают готового виртуального сотрудника — Виртса. Такой сотрудник становится частью отдела продаж, поддержки или HR: он отвечает на заявки, обрабатывает заказы или поддерживает в адаптации новых членов команды.
Изначально проект строился на зарубежном облаке с прицелом на глобальный рынок, используя cloud native подход: сервисы платформы работают в Docker-контейнерах, а базы данных и хранилища — на управляемых облачных сервисах.
🚀 Задача
Когда пришли первые российские клиенты с повышенными требованиями к 152-ФЗ и локализации персональных данных, встал вопрос: как быстро и безболезненно развернуть локальный контур в России, не переписывая архитектуру? Задача звучала так:
поднять backend-сервисы и вспомогательные компоненты платформы в Docker-контейнерах, оркестрируемых Kubernetes;
отдельно разместить frontend-часть (веб-интерфейс) платформы;
подключить управляемую СУБД для транзакционных данных и векторного поиска по базам знаний клиентов;
организовать объектное хранилище для документов и других файлов, на основе которых строятся векторные представления (Vector Store) пользователей Worken AI.
Разработчику было критично, чтобы облако одновременно соответствовало требованиям 152-ФЗ и предлагало современный стек managed-сервисов и AI-инструментов.
☁️ Что сделали
Сохранив cloud native подход, Worken AI развернул российский контур платформы на управляемых сервисах платформы Cloud.ru Evolution. Основные backend-сервисы и API-шлюзы разработчик вынес в кластеры Evolution Managed Kubernetes. Для хранения данных пользователей и векторных представлений документов Worken AI использует Evolution Managed PostgreSQL, управляя только схемой базы и запросами приложения. Файлы баз знаний, вложения и резервные копии размещаются в S3-совместимом объектном хранилище. Автоматизации на базе n8n и ряд вспомогательных сервисов разработчик развернул на бесплатных виртуальных машинах. Отдельные контейнерные приложения, которым не нужен полноценный Kubernetes-кластер, запущены в Evolution Container Apps.
🦾 Что получили в итоге
Все ключевые сервисы российского контура платформы Worken AI работают в российском облаке: входящие запросы пользователей проходят через frontend- и backend-сервисы, обращаются к управляемой базе данных и объектному хранилищу, а затем — к выбранным AI-моделям.
В планах сделать работу с моделями еще проще и ускорить вывод новых сценариев в продакшен. Это возможно в цифровой среде AI Factory, где строится единый контур: готовые LLM с OpenAI-совместимым API, сервисы для инференса и дообучения собственных моделей, управляемые Kubernetes-кластеры, объектное хранилище и управляемые СУБД.
Благодаря этому Worken AI может развивать Виртсов одновременно для глобального рынка и российских заказчиков на привычном cloud native стеке, удерживая данные и модели в инфраструктуре, соответствующей требованиям 152-ФЗ и уровню защищенности УЗ-1.
Смертельный марш: почему ваш проект обречен и как в этом выжить
Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).
Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.
Генезис катастрофы: Политика, политика и еще раз политика
Йордан честен: большинство безнадежных проектов рождаются не из-за технических сложностей. Они рождаются из-за того, что кто-то наверху играет в свои игры. Маркетологи наобещали невозможное, чтобы закрыть сделку; менеджеры побоялись сказать «нет» вице-президенту; а высшее руководство живет в мире, где девять женщин могут родить ребенка за один месяц.
В этой среде вы — не просто разработчик, а участник социальной драмы. Вы знаете, что проект обречен. Вы знаете, что обещания руководства — пустой звук. Вы принимаете эти правила игры не из наивности, а потому что это текущая реальность, в которой нужно как-то функционировать.
Классификация неизбежного: В каком аду вы находитесь?
Йордан делит безнадежные проекты на четыре типа. Понимание того, где вы, определяет вашу стратегию поведения:
«Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.
«Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.
«Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.
«Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.
Принцип «Сортировки» (Triage)
Термин заимствован из военной медицины. Когда раненых слишком много, врач не спасает всех — он выбирает, на кого тратить ресурсы. В «Смертельном марше» происходит то же самое.
Вы понимаете, что 80% функционала, о котором мечтает заказчик, никогда не будет реализовано. Профессионализм здесь заключается в том, чтобы сосредоточиться на тех 20%, которые позволят системе выдать хоть какой-то результат в день релиза. Всё остальное — белый шум и декорации. Вы просто игнорируете второстепенные задачи, не тратя на них ни капли энергии, даже если менеджер бьется в истерике.
Эстетика процесса
Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».
Смертельный марш — это не про успех продукта. Это про вашу личную устойчивость в условиях тотального хаоса. Пока вы сохраняете дистанцию и понимаете, что это просто роль в плохой пьесе, вы остаетесь профессионалом.
P.S. Циатата:
Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.
Включая меня. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот.
В минувшею пятницу, 26 февраля, на площадке Кибердома прошла премьера фильма «Как получить доступ ко всему: реверс-инжиниринг».
Исходя из описания под трейлером, этот
Документальный фильм расскажет, как люди учатся вскрывать сущность комплексных технологических систем. Разбирая устройство или технологию по частям, мы получаем доступ к их структуре и замыслу создателей. Эксперты в области обсудят реверс-инжиниринг в СССР и России – от промышленности после Первой мировой до искусственного интеллекта и «киберпанка», который ждет нас в ближайшем будущем.
Я, к сожалению, на премьеру попасть не смог по причине конфликта в графике. Поэтому, чтобы "изучить материалы по теме" мне пришлось посмотреть фильм в четверг, то есть за день до его официальной премьеры! Enumeration is the key (c) OffSec, и если хорошенько прошерстить интернет, то можно найти и посмотреть документалку без регистрации и СМС на официальном портале PREMIER: Как получить доступ ко всему: реверс-инжиниринг.
Естественно, не буду спойлерить детали, однако скажу, что фильм снят очень качественно, а в создании участвовали эксперты из Positive Technologies, «Лаборатории Касперского», Т-Банка, «Иви», SR Space, Музея криптографии, «Росатома», Elverils, интернет-проекта «Я помню» и другие неравнодушные люди и организации. Как посмотрите, приглашаю вас в комментарии, чтобы обсудить увиденное и высказать свои мысли по поводу фильма!
Как перестать быть центром всех решений и не потерять контроль :)
Когда команда растет, руководитель постепенно становится обязательной точкой во многих процессах. Кажется, все логично, ведь так быстрее и надежнее. Проблема становится заметной, когда появляется вопрос: что будет, если руководитель на время выпадет из работы?
С этим столкнулась Катя, руководитель операционного отдела. Консультации, планирование дежурств и часть сложных решений постоянно замыкались на ней. Это замедляло работу, снижало самостоятельность команды и создавало риски на случай ее отсутствия.
Попросили Катю рассказать, как она пересобрала процессы так, чтобы решения не требовали ее обязательного участия, а система оставалась управляемой и прозрачной.
1️⃣ Что происходит, когда процессы держатся на одном человеке
Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.
У нас закрывались задачи, клиенты получали ответы. Но по факту консультации, планирование дежурств и нестандартные решения замыкались на мне. И чем больше становилась команда, тем сильнее росла эта зависимость.
2️⃣ Три страха, которые мешают передавать процессы
Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:
Я стану не нужна
Перегружу команду
Команда что-то сделает не так
Самым тяжелым оказался последний страх. Руководителю трудно осознать, что кто‑то может принять решение иначе. Но иначе не значит хуже.
А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.
3️⃣ Как мы перестроили систему консультаций
Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.
Поэтому мы разложили консультации на типы: технические, процессные, бизнесовые. Дальше я посмотрела на реальную экспертизу внутри команды и распределила роли.
Опытные аналитики по каждой заявке
Скриптолог дня для базовых техвопросов
Техлиды для сложных техвопросов
Третья линия как финальная инстанция
В этой схеме больше нет обязательного шага «спросить у Кати» :)
Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это,и дала возможность сказать, если что‑то не работает.
В результате консультации ускорились, экспертиза выросла, а я перестала быть узким горлышком.
4️⃣ Как мы перестали тратить часы на планирование дежурств
Каждую пятницу я собирала пожелания в чате и сорок минут составляла график, учитывая личные обстоятельства и роли. Когда меня заменяли, на это уходило по два-четыре часа.
Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.
Мы сделали общую таблицу, где каждый выбирает удобные слоты. Если остается неудобное время, люди договариваются между собой. Через несколько минут после сообщения в пятницу график уже заполнен.
Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.
5️⃣ Как быть с кризисными ситуациями
Передавая процессы команде, важно понимать: это не означает, что руководитель больше не нужен. В кризисной ситуации именно руководитель остается тем, кто подключается, принимает решения и берет на себя ответственность. Но разница в том, что кризис перестает быть повседневностью.
У нас был показательный случай: у команды одновременно отсутствовали тимлид и техлид. Младший аналитик пришел ко мне и сказал, что сам проведет встречу по планированию, потому что понимает, что процесс не должен останавливаться.
В этот момент я поняла, что эта система — уже часть нашей культуры, и она работает. Команда не ждет указаний — каждый понимает, что он часть процесса и может на него влиять.
Я не считаю этот подход универсальным. Но если есть процесс, который держится только на вас, это повод задать вопрос: это стратегическое решение или просто привычка?
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструктычистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Как будет выглядеть рабочий день инженера в 2029 году?
Ответ на этот вопрос можно найти в подкасте руководителя клиентской разработки RUTUBE Максима Ульянова. В гостях — Артём Арюткин, CPO платформы для разработчиков в Авито.
В этом выпуске обсуждаем, зачем компаниям нужны платформы, что важно учесть при их проектировании, для каких команд они действительно дают эффект, в чем измерять «счастье разработчика» и к каким изменениям стоит готовиться разработчикам в 2029 году.
Из выпуска вы узнаете:
▪Чем CPO в DevEx отличается от CTO и зачем платформе продуктовый подход? ▪Что входит в техническую платформу Авито и почему важен принцип iPhone для разработчика? ▪Почему онбординг — это не «приятный бонус», а одна из ключевых метрик DevEx? ▪Зачем нужна технологическая стратегия и в каких бизнесах она реально избыточна? ▪Какие метрики первыми стоит начать считать для эффективности инженерных команд? ▪Почему платформы в крупных компаниях похожи и какие этапы развития они обычно проходят? ▪Каким компаниям нужна платформа и что меняется на масштабе 100 vs 500 инженеров? ▪Почему IT-индустрия «не зрелая» и какие ответы давно найдены в других отраслях? ▪Что такое «счастье разработчика» и почему его проще всего услышать в «разговорах у кулера»? ▪Почему в эпоху GenAI платформы могут стать ещё важнее?
Приятного просмотра и прослушивания!
Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активах «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.
Продуктовая разработка с агентами, замена agile-команд и роль продакт-инженера — эти и другие темы я обсудил с Юрой Агеевым, основателем ProductSense, в новом выпуске подкаста make sense.
Таймкоды: 00:00 — Введение 01:58 — Личный сетап агентов, эксперименты и первые сценарии 03:34 — Почему тема агентов — это про орг. модель, а не про игрушки 06:05 — Откуда взялся Agile: ответ на рост сложности продуктов 09:10 — Идея мини-команд для быстрого тестирования гипотез с агентами 11:10 — Риски одиночки: туннельность, критика, фактор автобуса 12:05 — Платформенная команда: стандарты, «золотой путь» и «ворота качества» 14:05 — Зависимость централизации от культуры компании 16:12 — Продакт-инженер: продукт и инженерия в одном цикле 17:32 — Схлопывание ролей: инженеры учат продукт, продукты учат технику 19:33 — Практика пайплайнов в работе с агентами: сначала документация, потом код 26:03 — Контекст как главная ценность и способ удержания клиентов 29:01 — Один в поле не воин: почему запуск и масштаб важнее кода 30:28 — Можно ли доверять агентам? 33:54 — Конкуренция заставит ускоряться: когда агенты станут нормой? 35:55 — Практика внедрения агентов: выделенные пилоты и команды добровольцев 37:35 — Главные риски: стоимость токенов и деградация навыков 42:09 — Как будут трансформироваться процессы и agile-роли? 50:57 — Как правильно строить эксперимент: задачи, команды, обучение и метрики
А еще я много пишу про продуктовую разработку и управление командами в своем блоге. Так что если прониклись темой подкаста, рекомендуем заглянуть туда.
Жду, когда Cursor и Claude Code будут стоить по $2000-$3000 в месяц. Они уже заменяют джунов, но скоро под нож пойдут и миддлы, и сеньоры. А здесь простой ROI (возврат инвестиций) для компаний: не болеет, не ходит на перекуры, не выгорает, не увольняется. Соответственно, нет сопутствующих затрат. Сейчас идет этап адаптации и принятия, поэтому действуют «дешевые» тарифы по $200.
Одной из важнейших задач реверс-инжиниринга является восстановление электрической схемы. Для того чтобы полностью и на низком уровне понять, как работает устройство, необходимо не только его разобрать, но и часами "прозванивать" дорожки: берем мультиметр, включаем диодную прозвонку и начинаем устанавливать связь между элементами.
В зависимости от сложности схемы, печатная плата может быть выполнена в 1-2 слоя: тогда дорожки можно визуально "проследить", просветив их фонариком. К слову сказать, лет 20-30 назад инженеры вообще не испытывали таких проблем, так как печатные платы были формата сквозного монтажа и все дорожки были снаружи и, как правило, контрастные.
К современным сложностям восстановления схемы я бы еще отнес SMD компоненты, которые отличаются между собой разве что только цветом: черный - резисторы, коричневый - конденсаторы, синий - индукция и т.д. И так как размеры элементов достаточно малые, производители не маркируют их характеристики: соротивление резисторов, емкость конденсаторов... Для того чтобы установить характеристики, необходимо выпаять каждый SMD элемент и измерить его мультиметром, после чего запаять на схему обратно.
Ну и вишенка на торте - использование чипов, даташиты на которые отсутствуют "в природе": сколько не гугли маркировку, ничего не найдешь. В узких кругах и для избранных производитель чипов, конечно же, предоставляет документацию. Но нам, как аппаратным хакерам, такая роскошь не всегда доступна ) В общем, производители все делают для того, чтобы производимое ими устройство сложно было скопировать, зареверсить или ... отремонтировать.
В данном случае, у меня на исследовании ключ автомобильной сигнализации. Как можно видеть по схеме, вся электроника крутится вокруг чипа A3XA5 QFN, работающего на частоте 27.6 МГц. С учетом того, что данное устройство является элементом безопасности, в интернете ноль информации по плате, чипу, алгоритму и т.д. Но это ненадолго: я провел собственное исследование и в скором времени опубликую свои находки! Поэтому, не переключайтесь ;)
п.с. Кстати, навык восстановления схемы нередко является одним из требований к вакансии, когда вы ищите работу по +- смежному направлению. Поэтому, если вы нацелены на данную профессию, советую потренироваться на несложных устройствах.
