Представлен открытый проект Odysseus. Это самостоятельно размещаемое рабочее пространство для ИИ (самодостаточная версия пользовательского интерфейса, аналогичного ChatGPT и Claude). «Работает на вашем собственном оборудовании, с вашими собственными данными — приоритет локальности, приоритет конфиденциальности и отсутствие троянов», — пояснил автор проекта PewDiePie:
проект запускается локально на рабочем ПК или сервере — никаких аккаунтов, телеметрии и облаков;
на борту уже есть агенты — умеют в веб-браузинг, редактирование файлов, анализ документов, сортировку писем и многое другое;
Odysseus также поддерживает Deep Research и глубокие исследования;
через API можно подключить любые локальные модели;
удобный интерфейс и полная поддержка работы со смартфона;
интернет-подключение не нужно, если работаете локально.
Инженер Netflix Теджас Чопра разработал открытый инструмент Project Headroom, который сжимает контекст перед отправкой в языковую модель и за счёт этого помогает пользователям экономить на ИИ-запросах.
Проект Headroom работает с контекстом, который отправляется в языковую модель: историей переписки, логами, результатами работы инструментов, файлами, документацией и другими данными. Перед отправкой в LLM программа сжимает этот контекст и удаляет из него избыточную информацию. По оценке Чопры, до 90% токенов в таких данных могут быть фактически лишними для модели.
Идея проекта появилась после того, как Чопра получил счёт на $287 за использование Claude Sonnet в домашнем проекте. Речь шла о типичных задачах: отладке, рефакторинге, работе с MCP-инструментами и запросах к базе данных. После анализа расходов инженер выяснил, что значительная часть токенов уходит не на его собственные инструкции, а на машинный «мусор»: чрезмерно подробные JSON-схемы, вложенные шаблоны в API-ответах, повторяющиеся колонки баз данных и другую служебную информацию.
Чопра описывает такие данные как «сжимаемую информацию, маскирующуюся под текст». По его словам, проблема особенно заметна в агентных системах, где модель получает не только пользовательский запрос, но и большое количество технического контекста. Чем больше данных отправляется в контекстное окно, тем выше стоимость запроса и тем больше риск, что модель начнет хуже работать из-за перегрузки информацией.
У меня трое детей, и я уверен, что хороший родитель, как правило, является хорошим руководителем.
Сознательный родитель хочет вырастить из беспомощного ребёнка самостоятельного взрослого. Сначала показывает сам, потом делает вместе с ребёнком, в конце только наблюдает и корректирует. Таким образом ребёнок осваивает навык за навыком, будь то умение держать ложку, ходить или кататься на велосипеде.
Мудрый руководитель заинтересован в том, чтобы компетенция сотрудника постоянно росла. Для этого он постепенно передаёт зоны ответственности. Сначала сотрудник решает задачи, затем начинает вести проекты, осваивает проектирование систем, подключается к найму людей и т.д.
Грустная новость: руководители зачастую не занимаются развитием сотрудников, даже, наоборот, ограждают от более сложных задач, чтобы ненароком не вырастить себе конкурентов.
Хорошая новость: руководителей, в отличие от родителей, выбирают.
РБПО по ГОСТ Р 56939—2024: вебинар №19 из 30 — Нефункциональное тестирование
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.19. – "Нефункциональное тестирование". На YouTube. Слайды.
Цели 19-го процесса по ГОСТ Р 56939—2024:
Подтверждение того, что поверхность атаки, модель угроз и архитектура ПО содержат необходимую информацию.
Обнаружение недостатков программы путём выполнения нефункциональных тестов, в том числе имитирующих действия потенциального нарушителя.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S.
Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Их можно смотреть на ускорении. Однако даже в этом случае с учётом дополнительных материалов и отсылок на внешние ресурсы изучение займёт около двух рабочих недель.
Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки. Так будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже познакомились.
Победитель хакатона от Anthropic представил набор из инструментов, команд и скиллов для ИИ‑агентов, которые помогли ему победить — проект называется Everything Claude Code:
183 скилла (для продакшена, миграции баз данных и другие);
48 саб‑агентов (под любые роли в разработке);
69 готовых слэш‑команд;
набор главных правил для разработки на 12 языках;
специальный инструмент AgentShield, который проверяет код на уязвимости и промпт инъекции;
работает не только в Claude Code, но и Cursor, OpenCode и Codex CLI.
Too much going on for you to reasonably comprehend.
На русский это можно перевести как:
Слишком много, чтобы осмыслить.
На мой взгляд, это очень точно попадает в происходящее. Мы привыкли думать, что автоматизация снимает нагрузку. Но на практике агенты и генеративные инструменты нередко добавляют новый слой контроля:
Их надо ограничивать во избежание мусорной информации.
Полуечнный результат надо интерпретировать, так как не всегда понятно, что имеется в виду.
Часто ошибки приходится разбирать уже в боевом продукте, а не в тестовом.
LeadDev хорошо описывает это на примере агентов, которые пишут код. Причём всем людям из статьи всё это нравится. Из-за этого они начинают дольше сидеть за компьютером, в таком же темпе работать и в выходные, и жить с ощущением, что можно успеть сделать ещё немного. Это замкнутый круг. Но вообще это FOMO.
Вместе с командой Т1 мы приехали на конференцию Merge, чтобы впервые провести Ресурсный батл в Казани. На кону — проектные карточки и ограниченные ресурсы. А победит тот, кто умеет договариваться и строить стратегию на ходу.
Смотри в нашем видео, как мы готовились, настраивались на игру и общались с коллегами.
Негативный фидбек: как говорить правду, не сломав человека
«Сэндвич» не работает. Анонимные опросы врут. А честный разговор с руководителем кажется карьерным суицидом. Но без негативной обратной связи команды не растут — и все об этом знают.
В новом выпуске «Свободного слота» разбираем, как всё-таки давать критику так, чтобы её слышали, а не просто вежливо кивали. В гостях — Илья Барбашов, руководитель юнита Platform Experience в Авито.
Что обсудили
Почему нельзя просто взять и выдать обратную связь — и что нужно сделать сначала. Как говорить с руководителем честно и не бояться за репутацию. Когда анонимный фидбек лучше прямого — и наоборот. Как не сломать сотрудника критикой и можно ли вообще её оспорить. И как готовиться к встрече с разбором ошибок: с повинной головой или с готовым планом.
Бонус: в конце выпуска ведущие сами принимают «развивающую» обратную связь от слушателей. Вживую и без купюр.
Почему ИИ, EAM и цифровые двойники ломаются ещё до старта
На любом объекте старше 15 лет один прибор живёт под 4–6 разными именами в разных системах. Между ними нет моста. Именно здесь тонут проекты цифровизации — не потому что плохой ИИ, а потому что данные не готовы.
Пятница. Поздно. Скрипт третий час парсит выгрузку из SCADA 2014 года. Кодировка CP1251 с BOM. Разделитель — точка с запятой, кроме строки 14 287, где кто-то вручную поставил запятую.
В этой строке — датчик давления. В SCADA он PT-2214. В конфиге PLC — AI_CH07_RACK3. В паспорте — серийник завода. В EAM — инвентарный номер. В исполнительной документации 2003 года — PIT-101, потому что так было до первой реконструкции.
Один датчик. Пять систем. Пять имён. Ни одного совпадения.
Заглядывает сменный КИПовщик: «Ну что, ИИ строите?» Смотрит на экран и уходит. Он здесь двадцать лет. Он знает.
Почему так
Никто специально ничего не ломал. Объект просто жил.
В 1990-х пришёл первый PLC — подрядчик назвал каналы по адресам. В 2003-м сделали SCADA — интегратор придумал теги заново. В 2011-м внедрили EAM — бухгалтерия завела инвентарные номера, про теги SCADA не спрашивала. В 2019-м была реконструкция — часть тегов переименовали, часть нет.
В итоге истина о том, что такое PT-2214 и где он стоит, нигде не зафиксирована. Она живёт в голове трёх КИПовщиков, двое из которых уже на пенсии.
Как это убивает проекты
Предиктивный ТОиР. Модель видит аномалию по тегу P-1503. Диспетчер идёт в журнал ТОиР искать историю. Там этот насос записан под инвентарным номером. Связи нет. Алерт считают ложным. Модель отключают.
Модель работала. Идентификаторы — нет.
Цифровой двойник. Подрядчик строит модель по проектной документации 2003 года. На сдаче выясняется: реактор меняли в 2011-м, байпас переврезали в 2017-м, 14 датчиков из модернизации 2019-го отсутствуют.
Модель красивая. Но это двойник установки, которой нет с 2011 года.
Что нужно сделать до старта
Всё начинается не с платформы, не с ИИ и не с 3D. Всё начинается с сопоставления:
Объект Датчик давления
SCADA-тег PT-2214
PLC-адрес AI_CH07_RACK3
Инв. № 5400123778
Серийник SN-8847-XR
Проектное имя. PIT-101
Это маппинг идентификаторов. Без него любая надстройка работает с обрывками реальности.
Строится он в несколько шагов: инвентаризация источников → извлечение с трассируемостью (каждое значение знает свой файл и строку) → нормализация → разрешение конфликтов → связывание объектов в граф.
Конфликты — отдельная история. Когда в PLC написано Pt100, а в паспорте ТСМ 50М — это не ошибка парсера. Это сигнал: кто-то менял прибор и не обновил документацию. Такие места нельзя «усреднять» автоматически. Нужен инженер. Иногда — выезд на объект.
Скан ≠ данные
Многие «проекты оцифровки» заканчиваются на уровне: отсканировали, OCR, разложили по папкам. Называется «архив оцифрован».
Но предиктивной модели нужны не тексты, а связи. PDF со словами «PT-2214» не отвечает на вопрос: какой PLC-канал, какой инвентарный номер, какая история поверки.
OCR делает текст доступным для поиска. Нормализация делает объект доступным для систем. Это разные задачи.
Что мы делаем
Мы берём инженерный архив действующего объекта — в любом состоянии — и превращаем его в структурированную базу, готовую для загрузки в СУИД, EAM, предиктивные системы и цифровые двойники.
Не консалтинг «как надо». Работа с документами, конфигами, бэкапами SCADA и папками, про которые не знал никто, кроме Петровича. И Михалыча...
Опыт на реальных объектах.
Если стоите перед запуском ИИ-проекта или внедрением EAM и понимаете, что данные не готовы — напишите. Возможно, именно мы вам поможем.
Если работали с Honeywell Experion или Yokogawa — расскажите в комментариях, как решали задачу идентификаторов. Сравним грабли.
Почему API переписывают через полгода и как этого избежать
Жесткие дедлайны заставляют жертвовать проектированием API ради скорости запуска. Через полгода структура данных не соответствует реальным потребностям, а каждое изменение вызывает регрессию. Разбираем, что идет не так и как закладывать гибкость на старте.
Запуск нового сервиса обычно проходит в условиях жестких дедлайнов и давления бизнеса. Приоритет — скорость, архитектура API откладывается на потом. Результат предсказуем: через полгода структура эндпоинтов не вписывается в логику продукта, интеграции становятся хрупкими, документация расходится с кодом.
Команда оказывается в ловушке технического долга. Новые функции не ложатся на существующую архитектуру, любое изменение ломает смежные модули, а страх регрессии парализует развитие. Проблема не в квалификации разработчиков или выборе фреймворка — причина в пропуске этапа системного проектирования.
Что ломается первым
Отсутствие контракта между клиентом и сервером — главная причина хрупкости. Когда API проектируется по принципу «сделаем быстро, потом поправим», возникают системные проблемы:
Эндпоинты перегружены логикой — один метод делает слишком много, изменить его без побочных эффектов невозможно.
Структура данных меняется без версионирования — клиенты ломаются на продакшене после деплоя.
Нет единого источника истины для схемы — документация устаревает, разработчики полагаются на догадки.
По данным исследования Postman State of the API 2023, 40% команд тратят больше времени на исправление проблем интеграции, чем на разработку новых функций. Основная причина — отсутствие контракта на этапе проектирования.
Как закладывать гибкость на старте
Системное проектирование API не означает месяцы планирования. Речь о базовых принципах, которые экономят время в будущем:
Определите схему данных до первой строки кода. OpenAPI, JSON Schema или Protocol Buffers — инструмент вторичен, важен контракт между клиентом и сервером. Схема становится единым источником истины и основой для автогенерации кода.
Версионируйте с первого дня. Даже если изменения пока не нужны, структура для версий (через URL, заголовки или content negotiation) должна быть заложена сразу. Переход на версионирование постфактум болезненен.
Проектируйте эндпоинты под бизнес-операции, а не под таблицы базы. CRUD удобен для прототипа, но быстро показывает ограничения. Операции вроде «подтвердить заказ» или «пересчитать баланс» должны быть явными методами, а не набором UPDATE-запросов.
Закладывайте безопасность в архитектуру. Авторизация, валидация входных данных, rate limiting и логирование — не опциональные доработки, а часть контракта. Добавление их потом ломает обратную совместимость и усложняет интеграции.
Trade-offs, о которых молчат
Системное проектирование API требует времени на старте. Это замедляет первый релиз — вместо недели уходит две. Но уже через квартал экономия становится очевидной: меньше правок, стабильные интеграции, отсутствие срочных патчей из-за несовместимых изменений.
Основной риск — переусложнение. Попытка предусмотреть все сценарии приводит к раздутым схемам и избыточной абстракции. Баланс достигается через фокус на реальных бизнес-требованиях, а не гипотетических расширениях.
API, спроектированное с учетом версионирования, контракта и безопасности, масштабируется без переписывания. Вопрос не в том, найдется ли время на проектирование сейчас — вопрос в том, сколько времени уйдет на устранение последствий его отсутствия через полгода.
РБПО по ГОСТ Р 56939—2024: вебинар №18 из 30 — Функциональное тестирование
Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Вебинар посвящен процессу из раздела 5.18. – "Функциональное тестирование". На YouTube. Слайды.
Цели 18-го процесса по ГОСТ Р 56939—2024:
Контроль полноты реализованных функциональных возможностей, обнаружение и исправление ошибок с использованием технологий функционального тестирования.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.
Свой ML-завод: что дает собственная ML-платформа и как ее запустить
Большинство корпоративных ИИ-пилотов не дают измеримых результатов. Не из-за моделей, из-за инфраструктурного хаоса вокруг них.
Специалисты тратят время на подготовку данных и настройку окружения вместо экспериментов. Стек собирается из разрозненных инструментов, интеграция съедает месяцы, видеокарты простаивают и сжигают бюджет. А поверх всего — ужесточение требований к субъектам КИИ и приближающиеся сроки перехода на отечественное ПО.
На вебинаре разберем, как выстроить нормальный процесс разработки ИИ — от загрузки данных до обучения моделей на кластере видеокарт. Покажем, как платформа Evolution Stack.ML от Cloud.ru превращает этот хаос в работающий ML-завод: готовые сервисы убирают месяцы интеграций, единое управление наводит порядок в инфраструктуре, а развертывание внутри контура закрывает требования регуляторов.
Будет полезно специалистам по данным и ML-инженерам, руководителям команд, ИТ-архитекторам, DevOps-инженерам, специалистам по ИБ, техническим и ИТ-директорам.
Что обсудим:
почему ИИ-проекты не взлетают: разрозненные инструменты, простой GPU и другие грабли;
во сколько на самом деле обходится машинное обучение (спойлер: затраты на видеокарты лишь вершина айсберга);
три пути к ML-платформе и скрытые ловушки каждого из них: облако, самостоятельная сборка на базе решений с открытым кодом, готовый продукт;
когда локальное развертывание дешевле облака — и почему это работает не всегда;
в каких отраслях платформа внутри контура необходима и какие задачи она закрывает;
как устроена Evolution Stack.ML и зачем нужны рабочие пространства.
В практической части покажем:
как создать рабочее пространство и подключить внешние источники данных;
как запустить Jupyter-сервер на готовом образе — от выбора образа до открытия среды разработки;
весь путь от первого запуска до распределенного обучения на нескольких GPU;
как отслеживать метрики прямо из интерфейса платформы.
📅 2 июня в 11:00 мск 📍 Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикеру в прямом эфире.
Свежие задачи для 1С-специалистов на Бирже заказов Инфостарта
На Бирже заказов появились новые задачи для разработчиков и консультантов 1С. В подборке — заказы, размещенные с 20 по 27 мая: доработки обработок, настройка обменов, интеграция с «Честным Знаком», задачи по маркировке, ЗУП, УТ, ERP, КА и даже 1С 7.7.
Биржа заказов Инфостарта помогает быстро найти исполнителя под задачи по 1С: от разовой консультации до доработки конфигурации, настройки обмена, интеграции с внешними сервисами или сопровождения проекта.
Для заказчиков доступны прямой обмен контактами, работа без комиссии, рейтинги исполнителей и безопасная сделка по желанию.
Как подружить ИБ и разработку через командные топологии: вебинар с разбором реального кейса
Разработке важно быстро выпускать изменения, а ИБ-командам — снижать риски и соблюдать требования безопасности. На практике это часто приводит к тому, что проверки начинают тормозить релизы, а взаимодействие между командами превращается в бесконечные согласования.
Один из способов решить проблему — посмотреть не только на инженерные практики, но и на устройство и взаимодействие самих команд. Метод командных топологий помогает выстроить работу так, чтобы ИБ была частью потока поставки, а не контролирующим контуром. На вебинаре 5 июня техлид «Экспресс 42» разберёт:
как связаны оргструктура команд, коммуникации между ними и архитектура разрабатываемых систем;
как использовать командные топологии для анализа вашей текущей модели взаимодействия;
как выглядит применение подхода на реальном проекте: от исходной ситуации до рекомендаций по изменениям и ожидаемого эффекта.
Регистрируйтесь и подключайтесь 5 июня в 12:00 (МСК), чтобы узнать, как командные топологии помогают снизить конфликтные ситуации и ускорить поставку изменений.
Когда регрессия уже не спасает: что почитать тестировщику про современный QA
QA больше не живёт в мире, где достаточно прогнать чек‑лист, закрыть пару багов и сказать: «ну вроде работает».
Сейчас тестировщику приходится думать шире: какие ошибки реально блокируют релиз, почему зелёные E2E‑тесты могут ничего не проверять, как flaky‑тесты ломают доверие к CI и где ИИ помогает, а где просто уверенно угадывает.
Начать стоит со статьи «Почему классический подход к QA больше не работает (и виновата ли в этом эпоха ИИ)». Это не очередной текст про «ИИ заменит тестировщиков», а разбор того, как меняется сама роль QA: от проверки готового продукта к работе с качеством на уровне архитектуры, данных, инфраструктуры, процессов и поведения системы после релиза.
В статье объясняется, почему старый подход уже трещит: современные продукты зависят от микросервисов, облаков, внешних API, ML‑моделей, пользовательских данных и цепочек интеграций. Поэтому тестировщику всё чаще нужно не просто находить баги, а понимать, где система может сломаться, как это повлияет на пользователя и что делать с качеством до, во время и после релиза.
А чтобы глубже разобраться в отдельных QA‑болях, собрали ещё несколько материалов:
«Ты QA и у тебя баги. Какие из них блокируют релиз?» Практичный разбор для ситуаций, когда до релиза осталось два часа, багов несколько, а чинить всё уже невозможно. В статье — как оценивать дефекты не по страшности описания, а по последствиям: деньги, данные, доступ, личная информация, заявки, отчёты и возможность быстро откатиться.
«5 распространенных ошибок новичка в E2E‑тестах» Для тех, кто пишет автотесты и не хочет получать зелёный, но бесполезный отчёт. На примерах Playwright разбираются ошибки вроде проверки интерфейса без проверки реального взаимодействия, неправильного ожидания событий, слабых локаторов и опасного использования force.
А если хочется не только читать, но и разбирать QA‑подходы на практике — присмотритесь к бесплатным открытым урокам OTUS. Разделили ближайшие темы по направлениям: от ИИ в автотестах до мониторинга и инцидент‑менеджмента.
ИИ в тестировании и автотестах
2 июня, 20:00. «Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ». Записаться
16 июня, 20:00. «ИИ в автотестах: помощник или угроза?». Записаться
18 июня, 20:00. «Тесты, которые чинят себя сами: практика ИИ в UI‑тестировании». Записаться
API, автотесты и инструменты
4 июня, 20:00. «API под контролем: тестирование сервисов с помощью Postman». Записаться
4 июня, 20:00. «Быстрая настройка конвейера автотестирования для 1С с хранилищем и Git». Записаться
16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться
Выбирайте тему под свой текущий фокус: ИИ в автотестах, API, мониторинг или инциденты. А если хочется посмотреть всё расписание — полный календарь открытых уроков OTUS.
И подписывайтесь на канал OTUS в MAX — там делимся новыми статьями, анонсами открытых уроков и полезными материалами для IT‑специалистов.
Представлен открытый учебный проект 100 free open-source github repos everyone needs - 100 бесплатных репозиториев для решения любых задач. У них полностью открытый код и актуальные инструменты:
ИИ-агенты и скиллы для них;
Локальные альтернативы SaaS-сервисам;
Фреймворки и плагины для любых задач;
Топовые тулзы для разработчиков;
Курсы и справочники по всевозможным темам;
Дизайн и фронтенд-разработка;
Извлечение данных и аналитика;
Безопасность и приватность в сети;
Сборник инструментов для подготовки контента.
При этом у каждого проекта своя лицензия, а авторы подробно разбирают их назначение и способы применения.
При запуске стартапа не делайте его мультиязычным, пока нет стабильного дохода и команды для поддержки этого. Вы не можете знать, станет ли стартап прибыльным, и в начале лучше тратить время на поиск PMF и привлечение пользователей. ИИ может написать скрипты для управления файлами переводов и помочь с переводом текстов, но это будет некачественным решением. С таким же успехом пользователи могут включить переводчик в браузере.
Если вы сразу сделаете сервис на 10 языках, вы замучаетесь это поддерживать. При любом изменении интерфейса вам нужно будет изменять файлы переводов на всех языках. Хотя большинство ваших пользователей скорее всего поймут интерфейс на английском. Но если вы делаете проект для определенной страны, делайте его на языке этой страны и не добавляйте английский. Даже 2 языка на старте хуже, чем 1 язык. При одном языке вы можете добавлять текст прямо в код и не выносить в отдельные файлы переводов.
Создание условий для снижения рисков внедрения вредоносного ПО посредством воздействий на ПО или механизмы его доставки до получения ПО конечными пользователями и недопущение компрометации данных (информации) или информационной системы, использующей такое ПО.
Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Цикл вебинаров проведён компанией ООО "ПВС" совместно с учебным центром "Маском". Организаторами выступили Андрей Карпов и Виталий Пиков. Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
P.S. ООО "ПВС" регулярно проводит вебинары и подкасты, и не только по теме РБПО :) Приглашаем желающих принять в них участие как в качестве зрителей, так и в качестве экспертов.
В кабинет зашла девушка в ослепительном платье. Руководитель отдела обратился к нам: «Ребята, знакомьтесь, это Марина, стажёр». Наш сугубо мужской коллектив притих: это что же, теперь и ругнуться будет нельзя?
Марина, выпускница МГТУ им. Баумана, быстро училась, разбиралась в продукте и писала качественный код.
Со временем штат стажёров расширился, ребята за короткое время выросли до младших разработчиков. Держались они вместе, стайкой, постоянно подкалывая друг друга.
Когда пришёл начальник отдела и объявил нового руководителя группы, ребята усмехнулись: это что же, наша Маринка — и тимлид? Через неделю шутки закончились: Марина начала активно осваивать новую роль.
За следующие 7 лет Марина выросла до руководителя службы разработки API «Яндекс.Карт», а позже стала директором по продукту рободоставки в Яндексе.
Каждый раз, назначая человека тимлидом, я вручаю ему подарок. Это настольная книга руководителя. За последние пять лет я раздал этих книг уже больше сотни. И получил множество откликов. Начинающим руководителям книга помогает освоиться в новой роли, ответить на вопросы и разобраться в сложных рабочих ситуациях.
Книга называется «Мама, я тимлид». Автор — Марина Перескокова.
Как выйти из кризиса перегрузки без найма: опыт двухнедельного Stop the Line
Команда тонет не когда задач много, а когда поток работы не соответствует пропускной способности. Разбираю на примере условного «ФинТеха», как двухнедельная остановка конвейера возвращает управляемость без расширения штата.
Типичная картина: дедлайны не двигаются, найм заморожен, техдолг растёт, инциденты множатся, люди выгорают. Первая реакция — «давайте ускоримся ещё сильнее». Это только усугубляет кризис.
Проблема не в скорости разработки, а в том, что система перестала справляться с объёмом параллельных задач. Когда в работе одновременно 20 фич, а команда реально может закрыть 5 в спринт — каждая задача тормозит остальные. Контекстные переключения съедают до 40% времени, код-ревью затягиваются, интеграция превращается в русскую рулетку.
На практике видел это десятки раз. Компания вводит «режим ускорения»: сокращает ревью, откладывает рефакторинг, пилит MVP параллельно с production-фиксами. Через месяц скорость не растёт — падает. Команда тушит пожары вместо того, чтобы делать продукт.
Что даёт Stop the Line
Двухнедельная остановка конвейера — это не каникулы. Это хирургическое вмешательство: временно прекращаешь приём новых задач и закрываешь то, что уже в работе. Параллельно команда разгребает техдолг, который мешает двигаться дальше: чинит CI/CD, актуализирует документацию, закрывает критичные уязвимости.
Ключевой момент — это не просто «месяц на техдолг». Это сознательное решение восстановить пропускную способность. За две недели команда из условного «ФинТеха» может:
Закрыть 15 из 20 зависших фич — вместо того чтобы держать их в работе ещё месяц
Разобрать backlog инцидентов и понять, какие из них — симптомы одной проблемы
Автоматизировать то, что отнимает 2-3 часа в день у каждого разработчика
Обновить зависимости, которые тянут за собой уязвимости и блокируют миграцию на новые версии
После Stop the Line команда не становится быстрее в два раза. Но она возвращает управляемость: понятно, сколько задач реально можно взять в спринт, какие риски несут новые фичи, где узкие места. Вместо хаоса — предсказуемый поток.
Как продать это бизнесу
Главный вопрос от менеджмента — «мы потеряем две недели разработки». Нет. Вы потеряете две недели добавления новых задач в очередь, но выиграете месяцы на выходе из болота. Показывай цифры: сколько фич завершено за последние два спринта, сколько инцидентов повторяются, сколько времени уходит на переключения между задачами.
Опыт показывает: после Stop the Line скорость delivery возвращается к нормальной в течение месяца, а качество выходит на новый уровень. Главное — не скатываться в ту же воронку снова. Установить WIP-лимиты, внедрить метрики cycle time, договориться с бизнесом о реалистичных планах.
Ограничение подхода — он работает, если команда ещё не выгорела окончательно и проблема в процессах, а не в людях. Если половина уже ищет новую работу — Stop the Line не спасёт. Но если команда готова работать, просто задыхается под грузом — это работает.
С 13 по 22 мая на Инфостарт Бирже заказов появились новые задачи для 1С-специалистов: доработки типовых конфигураций, внешние печатные формы, автоматизация скидок, работа с документами и проекты с использованием ИИ.
Собрали часть актуальных заказов, которые можно взять в работу.
Представлен открытый проект waylandcraft - это полнофункциональный композитор Wayland полностью интегрирован в мод Fabric для Minecraft Java 26.1.2.
«Запускайте приложения и открывайте окна прямо в вашем мире Minecraft. Перетаскивайте данные из одного окна в другое. Закрепите видеоплеер на вашем HUD. Выбор за вами. Важно: этот мод работает только под Linux! MacOS и Windows не поддерживаются», — пояснил автор проекта.
РБПО по ГОСТ Р 56939—2024: вебинар №16 из 30 – Использование инструментов композиционного анализа
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Создание условий для снижения рисков наследования уязвимостей и недекларированных возможностей при использовании заимствованного кода в коде ПО разработчика.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
ИИ фри пост. Весь habr и linkedin стал пестрить людьми с AI в должности. Почти каждый стал AI Product Manager, даже если просто использует ChatGPT с дипресерчем и 1 функция вызывает Gemini Flash 2.5 по апи
Естественно начинают появляться курсы по Claude Code для продактов, вайбкодинг для нетехнарей и тд. Но у меня интерес не об этом. Мне любопытно видите ли вы спрос от работодателей на найм всех этих AI Inspired сотрудников? Не AI Engineer/DS/MLe/SWE для обвязки, а именно сопровождающих? Или мы наблюдаем новое переобуваение из Project Management/Agile/Product Management/Strategy/OKR (подчеркните для себя что застали).
РБПО по ГОСТ Р 56939—2024: вебинар №15 из 30 – Обеспечение безопасности используемых секретов
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Примечание — В данном подразделе под секретами понимаются данные в любом виде, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.), в том числе путём применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)
Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?
Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.
Представлен учебный открытый проект Awesome CUDA Books. Это подборка всех основных книг по программированию на CUDA — от начального до продвинутого уровня, C++/Python, архитектура, оптимизация и последние релизы 2024–2026 годов. Основано на практических, высококачественных ресурсах для параллельных вычислений на графических процессорах Nvidia.
Робот "видит" набор пазлов, а человек мыслит объёмно, где каждый пиксель - жив в живой структуре
AI как промышленный ускоритель: почему работа с нейросетями — это жесткий контроль, а не «вброс промптов»
В последнее время в ИТ-сообществе не утихают споры о том, заменят ли нейросети программистов. Кто-то пророчит скорую смерть профессии, кто-то брезгливо морщится при упоминании сгенерированного кода. На своем опыте я убедился: правы и не правы обе стороны. Всё зависит от того, кто сидит за пультом управления.
Для меня взаимодействие с AI — это не слепой «вброс» абстрактных запросов в надежде получить готовое приложение. Это плотная, изнурительная аналитическая работа. AI сегодня — это лучшая в мире справочная система, сильный ассистент и неплохой аналитик. Но он остается исполнителем, за которым нужен неусыпный надзор.
Работая над архитектурой своего семантического ядра «Эстафеты Хвоста» (высоконагруженный движок на Lazarus/FPC под Jetson Nano в концепции Green Computing), я наглядно прочувствовал физику этого процесса.
Вот главные выводы, к которым я пришел:
1. Чем выше мощность, тем сложнее контроль
AI обладает огромной производительностью, и она отнюдь не иллюзорна. Он может за секунды выплюнуть сотни строк кода или развернуть сложную математическую модель. Но здесь кроется главная ловушка: если усыпить собственную бдительность, система мгновенно наплодит скрытых архитектурных галлюцинаций. Наш тандем выкристаллизовался именно тогда, когда я жестко поправлял ассистента в вопросах топологии графа, фрактальных маркеров и хронологии всплытия веток из ОЗУ. AI предлагает варианты — человек выносит вердикт и ведёт таргетинг алгоритма (в смысле следит за системным подходом к алгоритмизации, если алгоритмы новы или "вращаются" вокруг ядра с новым алгоритмом - кроме человека это делать некому, так как эти алгоритмы для AI неизвестны). Именно так мне удалось извлечь из одного стёка три UX - бонуса, только жёстко контролируя ответы AI, постоянно тергетируя целевой алгоритм ядра, постоянно внося поправки (ну я пользуюсь бесплатным, от поисковой системы браузера - более быстрые ответы в сравнении с локальными на мои 8 G видеокарты, всегда актуальная документация по IDE, ну и меньше углеродный след).
2. Время как решающий фактор
То, что нейросеть приходится постоянно корректировать, направлять и проверять «под микроскопом» — с лихвой окупается скоростью выдачи базовых конструкций. AI берет на себя рутину, синтаксический шум и написание boilerplate-кода. Моя цель — решить этим проектом ряд прикладных задач, чтобы высвободить личный временной ресурс для дальнейшего масштабирования системы. AI дает инженеру главное преимущество — время.
3. Шлифовка результата — это и есть работа
Когда вы управляете огромной мощностью, ваша роль меняется. Вы больше не просто пишете строки кода — вы выступаете в роли главного архитектора и системного аудитора. Вычистить листинг, довести логику развертывания дерева до константного состояния, убрать холостые циклы ради экономии милливатт энергии на ARM-процессоре — это и есть настоящая работа.
Итог
AI не заменит тех, кто умеет думать и проектировать. Если не отдавать бразды правления слепому алгоритму, а использовать его как реактивный бустер под строгим человеческим контролем, результат взаимодействия всегда будет строго положительным.
Почему я думаю, что мой пост нужен невзирая на тысячи прдшевственников? Потому что у меня есть конкретный результат по успешному созданию новой и очень эффективной архитектуры, исторические корни аналогов (с их проблемами) которой уходят в эпоху зарождения баз данных и веба, и в работе мне помогал AI ассистент.
Мы выжали максимум из этой синергии: код вычищен, теоретическая база подготовлена, бэкенд готов к масштабированию. Двигаемся дальше.
Представлен открытый проект tokenspeed (онлайн-версия), который показывает, насколько быстро на самом деле обрабатываются разные количества токенов в секунду. Все бенчмарки локальных LLM показывают пропускную способность: «47 токенов/с на M3», «180 токенов/с на 4090», «500 токенов/с на Groq». Но если вы не видели потоковую передачу токенов с такой скоростью, эти цифры трудно понять. tokenspeed — это терминальная утилита, которая передаёт фиктивные токены с любой заданной вами скоростью, так что вы можете увидеть, как эти цифры выглядят на самом деле.
РБПО по ГОСТ Р 56939—2024: вебинар №14 из 30 – Управление доступом и контроль целостности кода при разработке программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.
Цели 14-го процесса по ГОСТ Р 56939—2024:
Обеспечение управления доступом к исходному коду и его целостности.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Узнай, как AI сегодня меняет продукты и процессы, от спикеров митапа Garage Eight
Высшая лига по цене дворового футбола: как ИИ-агенты делают технологии разработчиков доступными Спикер: Михаил Никишин, основатель школы прототипирования с ИИ — Startend․ru, ex-Product Lead Спортмастер YouTube | VK Видео
AI-агенты в исследованиях: как не потерять в качестве, но выиграть в скорости Спикер: Евгений Вечирко, продуктовый маркетолог в Первый Бит, основатель AI club SPb YouTube | VK Видео
разработчикам, которые планируют перейти в руководство,
начинающим тимлидам,
менеджерам, которые хотят систематизировать управленческие практики и усилить навыки работы с командой.
На курсе разбирают:
техническое лидерство и архитектурные решения,
управление командой и развитие сотрудников,
Agile-подходы (Scrum, Kanban),
процессы планирования и релизов,
коммуникацию с бизнесом,
обратную связь и 1-on-1.
Отдельный фокус — практика. Студенты отрабатывают управленческие навыки с наставниками — действующими руководителями разработки, а также обмениваются опытом с другими тимлидами и менеджерами.
Что нового в тарифах:
Расширенный тариф: практические отработки управленческих задач и собеседований.
Максимальный тариф: всё из расширенного тарифа, работа с карьерным консультантом, дополнительный модуль по аргументации для руководителей.
Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта
Иногда задают вопрос: "Как статический анализ ускорит Time to market?"
Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.
Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.
Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.
Какой вопрос правильный?
Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?
Другое дело. Если нужно выпустить качественный продукт, то статический анализ может выявить многие ошибки и дефекты безопасности быстрее и дешевле, чем другие методы. Некоторые виды дефектов лучше обнаруживаются статическим анализатором кода, чем юнит-тестами, динамическим анализом, ручным тестирование и так далее.
Впрочем, это свойство и других методик. Есть дефекты, которые наиболее эффективно будут обнаруживать юнит-тесты, поэтому профессиональные разработчики не пытаются выбрать какой-то один подход, а используют сразу несколько. Эти разные меры усиливают друг друга.
Статический анализ применяется на этапе конструирования, то есть написания кода, поэтому позволяет устранить многие ошибки ещё до этапа тестирования. Хотя на анализ предупреждений необходимо тратить время, это окупается сокращением числа дефектов, которые выявляются на других этапах проверки продукта и его эксплуатации. Известно, что чем раньше ошибка найдена, тем дешевле её исправление.
29 мая 2026 года компания «Диасофт» проведет третью партнерскую конференцию DiasoftPartnersDay, посвященную искусственному интеллекту и модернизации корпоративных систем на базе платформы Digital Q.ERP и экосистемы low-code разработки Digital Q.
Фокус деловой программы – применение искусственного интеллекта в развитии ERP-решений, технологические подходы к импортозамещению и новые стандарты ИТ-индустрии, которые трансформируют процессы разработки программных продуктов. Специалисты «Диасофт» продемонстрируют возможности экосистемы Digital Q, в которую технологии ИИ уже интегрированы и используются для повышения эффективности разработки и эксплуатации решений.
К участию приглашаются топ-менеджеры, директора по информационным технологиям компаний различных отраслей экономики, а также ведущие разработчики и ИТ-специалисты, заинтересованные в применении искусственного интеллекта для развития ERP-систем и создания сложных программных продуктов.
Посмотреть программу мероприятия и зарегистрироваться можно по ссылке.
ИИ уже не тренд — это новая реальность для всех, кто работает в IT. Но чем больше инструментов, тем больше вопросов: не деградируют ли компетенции, если за тебя всё делает нейросеть? Как растить джунов, которые умеют думать, а не только промптить? И во сколько на самом деле обходится работа с ИИ?
В новом выпуске «Свободного слота» сразу два Александра в гостях: Александр Мазько, управляющий директор дивизиона SberWorks в Сбербанке, и Александр Лукьянченко, директор департамента разработки Architecture в Авито.
Что обсудили
Вспомнили исследование Anthropic о том, как агенты влияют на обучение джунов — и поспорили, хорошо это или нет. Разобрали эффект Uber: почему реальная стоимость работы с ИИ может оказаться совсем не такой, как кажется. Поговорили про бэкграунд-агентов, утечки данных и то, как вообще оценивать инженеров в мире, где ChatGPT есть у всех. И, конечно, порассуждали о будущем — благо тема не даёт скучать.
РБПО по ГОСТ Р 56939—2024: вебинар №13 из 30 – Обеспечение безопасности сборочной среды программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
P.S. В вебинаре рассказывается, в том числе, про GitFlic. Отмечу, что PVS-Studio совместим с платформой GitFlic. Благодаря этому разработчики могут получать результаты сканирования PVS-Studio напрямую в интерфейсе GitFlic, что упрощает процесс разработки и тестирования.
РБПО по ГОСТ Р 56939—2024: вебинар №12 из 30 – Использование безопасной системы сборки программного обеспечения
Команда ООО "ПВС" совместно с Виталием Пиковым из учебного центра "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, обусловленных небезопасными преобразованиями кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации, подготовленная Андреем Карповым, доступна по ссылке: ГОСТ56939.РФ.
P.S. Мы регулярно проводим вебинары на различные темы, не обязательно связанные с РБПО. У нас появился подкаст «Разбаговка»! Приглашаем слушать и принять участие в качестве гостя.
