Планирование, отслеживание и контроль
В субботу 23 мая лабораторная — Docker для системных аналитиков! 🐳📊
Присоединиться и получить виртуальную машину со всеми настройками можно через Boosty! 🚀 Скидка для тех, кто хочет попробовать! 💸
Boosty - https://boosty.to/polnyistek
Подробнее - https://debugskills.ru/articles/labs/docker-basics/ 📖✨
ИИ фри пост. Весь 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.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.15. – "Обеспечение безопасности используемых секретов". На YouTube. Слайды.
Цели 15-го процесса по ГОСТ Р 56939—2024:
Обеспечение безопасного использования секретов.
Примечание — В данном подразделе под секретами понимаются данные в любом виде, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.), в том числе путём применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)
Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?
Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.
Самое печальное - некоторые компании не считают это угрозой. Для них это "фича, а не бага". Поподробнее о том почему компании не желают признавать проблему - в моей статье Wayback Machine как архив IDOR: как временные ссылки перестали быть временными.
Представлен учебный открытый проект 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 — это терминальная утилита, которая передаёт фиктивные токены с любой заданной вами скоростью, так что вы можете увидеть, как эти цифры выглядят на самом деле.
Открытый проект Go Interview Practice содержит обширный репозиторий для подготовки к собеседованиям на Go:
внутри — целая интерактивная платформа с задачами всех уровней. Могут готовиться как новички, так и профи.
ИИ‑интервьюер проверяет решения и сразу дает подсказки.
есть таблица лидеров, чтобы соревноваться с топами и видеть свой прогресс.
можно задать вопросы коммьюнити, если задача оказалась слишком трудной.
РБПО по ГОСТ Р 56939—2024: вебинар №14 из 30 – Управление доступом и контроль целостности кода при разработке программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.14. – "Управление доступом и контроль целостности кода при разработке программного обеспечения". На YouTube. Слайды.
Примечание. Во время демонстрации работы 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 Видео
Следующий AI-митап — 27 мая. Регистрация уже открыта ;-))
Запустили новые тарифы курса «Управление командой разработки» — расширенный и максимальный.
Курс подойдет:
разработчикам, которые планируют перейти в руководство,
начинающим тимлидам,
менеджерам, которые хотят систематизировать управленческие практики и усилить навыки работы с командой.
На курсе разбирают:
техническое лидерство и архитектурные решения,
управление командой и развитие сотрудников,
Agile-подходы (Scrum, Kanban),
процессы планирования и релизов,
коммуникацию с бизнесом,
обратную связь и 1-on-1.
Отдельный фокус — практика. Студенты отрабатывают управленческие навыки с наставниками — действующими руководителями разработки, а также обмениваются опытом с другими тимлидами и менеджерами.
Что нового в тарифах:
Расширенный тариф: практические отработки управленческих задач и собеседований.
Максимальный тариф: всё из расширенного тарифа, работа с карьерным консультантом, дополнительный модуль по аргументации для руководителей.
Самое быстрое — «хренак-хренак и в продакшн»: о статическом анализе и скорости выхода продукта
Иногда задают вопрос: "Как статический анализ ускорит Time to market?"
Никак. Статический анализатор не ускорит выход продукта/обновления на рынок. С ним будет дороже и медленнее. Причина — неправильный вопрос.
Аналогично можно спрашивать, как этап тестирования ускоряет Time to market? Точно так же — никак. Тестировщикам мало того, что надо деньги платить, так они ещё будут разработчиков багами отвлекать. Намного быстрее просто написать запускающийся код и выложить дистрибутив. Как говорится, "хренак-хренак и в продакшен". Это самый быстрый вариант.
Но про тестирование, в отличии от статического анализа, такой вопрос не задают. Все понимают, что тестирование — важный элемент создания ПО. Видимо, статический анализ — более молодая методология по сравнению с тестированием, и он просто ещё не стал неотъемлемой частью разработки. Хотя видится очевидным, что и то, и другое неразрывно связано с обеспечением необходимого качества создаваемых программных продуктов.
Какой вопрос правильный?
Как статический анализ ускоряет Time to market при выпуске продуктов заданного уровня качества и надёжности?
Другое дело. Если нужно выпустить качественный продукт, то статический анализ может выявить многие ошибки и дефекты безопасности быстрее и дешевле, чем другие методы. Некоторые виды дефектов лучше обнаруживаются статическим анализатором кода, чем юнит-тестами, динамическим анализом, ручным тестирование и так далее.
Впрочем, это свойство и других методик. Есть дефекты, которые наиболее эффективно будут обнаруживать юнит-тесты, поэтому профессиональные разработчики не пытаются выбрать какой-то один подход, а используют сразу несколько. Эти разные меры усиливают друг друга.
Статический анализ применяется на этапе конструирования, то есть написания кода, поэтому позволяет устранить многие ошибки ещё до этапа тестирования. Хотя на анализ предупреждений необходимо тратить время, это окупается сокращением числа дефектов, которые выявляются на других этапах проверки продукта и его эксплуатации. Известно, что чем раньше ошибка найдена, тем дешевле её исправление.
P.S. Если понадобится, то есть более формальный и развёрнутый вариант этой сентенции – Статический анализ кода и вывод программных продуктов на рынок.
«Диасофт» приглашает на Diasoft Partners Day 2026
29 мая 2026 года компания «Диасофт» проведет третью партнерскую конференцию Diasoft Partners Day, посвященную искусственному интеллекту и модернизации корпоративных систем на базе платформы Digital Q.ERP и экосистемы low-code разработки Digital Q.
Фокус деловой программы – применение искусственного интеллекта в развитии ERP-решений, технологические подходы к импортозамещению и новые стандарты ИТ-индустрии, которые трансформируют процессы разработки программных продуктов. Специалисты «Диасофт» продемонстрируют возможности экосистемы Digital Q, в которую технологии ИИ уже интегрированы и используются для повышения эффективности разработки и эксплуатации решений.
К участию приглашаются топ-менеджеры, директора по информационным технологиям компаний различных отраслей экономики, а также ведущие разработчики и ИТ-специалисты, заинтересованные в применении искусственного интеллекта для развития ERP-систем и создания сложных программных продуктов.
Посмотреть программу мероприятия и зарегистрироваться можно по ссылке.
ИИ и тимлид: кто кого?
ИИ уже не тренд — это новая реальность для всех, кто работает в IT. Но чем больше инструментов, тем больше вопросов: не деградируют ли компетенции, если за тебя всё делает нейросеть? Как растить джунов, которые умеют думать, а не только промптить? И во сколько на самом деле обходится работа с ИИ?
В новом выпуске «Свободного слота» сразу два Александра в гостях: Александр Мазько, управляющий директор дивизиона SberWorks в Сбербанке, и Александр Лукьянченко, директор департамента разработки Architecture в Авито.
Что обсудили
Вспомнили исследование Anthropic о том, как агенты влияют на обучение джунов — и поспорили, хорошо это или нет. Разобрали эффект Uber: почему реальная стоимость работы с ИИ может оказаться совсем не такой, как кажется. Поговорили про бэкграунд-агентов, утечки данных и то, как вообще оценивать инженеров в мире, где ChatGPT есть у всех. И, конечно, порассуждали о будущем — благо тема не даёт скучать.
Слушайте и смотрите новый выпуск на площадках:
📺 YouTube
🔵 ВК Видео
📌 RuTube
🎧 Яндекс Музыка
Ⓜ️ Mave
Ещё больше новостей — в нашем телеграм-канале
«Свободный слот» — терапевтичный контент для тимлидов и тех, кто хочет ими стать
РБПО по ГОСТ Р 56939—2024: вебинар №13 из 30 – Обеспечение безопасности сборочной среды программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.13. – "Обеспечение безопасности сборочной среды программного обеспечения". На YouTube. Слайды.
Цели 13-го процесса по ГОСТ Р 56939—2024:
Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
P.S. В вебинаре рассказывается, в том числе, про GitFlic. Отмечу, что PVS-Studio совместим с платформой GitFlic. Благодаря этому разработчики могут получать результаты сканирования PVS-Studio напрямую в интерфейсе GitFlic, что упрощает процесс разработки и тестирования.
РБПО по ГОСТ Р 56939—2024: вебинар №12 из 30 – Использование безопасной системы сборки программного обеспечения
Команда ООО "ПВС" совместно с Виталием Пиковым из учебного центра "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.12. – "Использование безопасной системы сборки программного обеспечения". На YouTube. Слайды.
Цели 12-го процесса по ГОСТ Р 56939—2024:
Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, обусловленных небезопасными преобразованиями кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации, подготовленная Андреем Карповым, доступна по ссылке: ГОСТ56939.РФ.
P.S. Мы регулярно проводим вебинары на различные темы, не обязательно связанные с РБПО. У нас появился подкаст «Разбаговка»! Приглашаем слушать и принять участие в качестве гостя.
Новый ИИ на старые процессы — это турбодвигатель на телегу.
Красиво. Дорого. Быстро. Но всё равно телега.
Большинство компаний внедряют ИИ именно так: берут процесс, накладывают инструмент и ждут трансформации. Но когда вы ускоряете старый процесс, вы наследуете все его неэффективности. Согласования, которые были лишними, теперь проходят быстрее. Отчёты, которые никто не читал, теперь генерируются автоматически. И всё так же не читаются.
Реальный эффект начинается с другого вопроса: а зачем эта работа делается именно так?
Одна финансовая компания задала его — и получила минус 59% нагрузки и минус 40% затрат. Не от нового инструмента. От нового мышления.
Разбейте процесс на реальные действия. По каждому — три вопроса:
— Зачем это существует?
— Человек или ИИ справится лучше?
— Можно ли убрать вообще?
Третий вопрос даёт самый большой эффект. И именно его никто не задаёт.
Начните этот разговор до того, как купите следующий ИИ-инструмент.
Разработчики из команды «Яндекса» выложили в открытый доступ первое решение на базе большой языковой модели (LLM) для автоматизации миграции iOS‑проектов с Objective‑C на Swift, современный язык Apple. Оно особенно актуально для крупных проектов, накопивших сотни тысяч строк устаревшего кода. Решение ускоряет процесс миграции в 2,5 раза, позволяя разработчикам переключиться с рутинных задач на проверку качества.
Решение Migration toolkit for Swift разработано при миграции кодовой базы «Яндекс Браузера». Команда при переписывании кода столкнулась с целым рядом проблем: затраты времени и ресурсов, неизбежные при ручной работе ошибки, и всё это — при необходимости параллельно развивать проект. В результате за пять лет удалось сократить технический долг только наполовину.
Новый подход на базе LLM не только ускорил миграцию, но и позволил освободить разработчиков от монотонного переписывания кода — вместо этого они валидировали корректность миграции и выполняли сложный рефакторинг. За два месяца команда интегрировала 106 пул-реквестов, переписав около 97,5 тысячи строк устаревшего кода и более двух тысяч файлов. Обработка такого объёма данных вручную заняла бы больше года.
В отличие от существующих конвертеров, не учитывающих контекст, новое решение использует LLM-модель, способную понимать не только грамматику языка, но и архитектуру конкретного проекта. В основе подхода — система из четырёх специализированных промптов, каждый из которых отвечает за свой этап. Первый определяет оптимальный порядок миграции файлов, переписывает код и проверяет результат через компиляцию и тесты. Второй адаптирует полученный код под лучшие практики Swift. Третий проводит автоматическую проверку по чеклисту: заголовки файлов, корректность замены типов, соответствие стандартам. Четвёртый очищает код от устаревших аннотаций, когда необходимость в них отпадает.
Готовые промпты автоматически подгружаются в контекст диалога в большинстве современных агентских IDE, поэтому решение совместимо с популярными инструментами для работы с кодом. Все промпты, скрипты и шаблоны проекта доступны на GitHub и SourceCraft.
Ускорили разработку в 2 раза за счет AI? Понятно.
Вот только релизы не стали быстрее, time-to-market не сократился.
Да, сегодня многие компании пытаются ускориться, просто добавляя AI в старую систему, и не получают результата. Потому что теперь тормозит не разработка, а валидация, качество и согласования. При этом сами команды не изменились: те же роли, процессы, подходы.
Agile создавался как ответ на высокую сложность разработки, но AI эту сложность уже снизил. А значит, текущая модель команд начинает устаревать.
В апреле на Product Focus Club наш CPTO Саша Бондаренко поделился своим видением трансформации команд.
Он рассказал:
— почему инвестиции в AI не дают эффекта без пересборки процессов (на данных Klarna и DORA)
— как появляется новая роль Product Engineer вместо набора узких специалистов
— почему команды из 7-9 человек трансформируются в компактные поды из 2-3 инженеров
— как Platform Engineering становится системой контроля и масштабирования, а не поддержкой
— как выглядит Team Topologies 3.0 и с чего начать переход
Запись выступления доступна для просмотра на YouTube и VK Видео.
Кстати, в рамках эксперимента мы запустили три pod-команды у нас в Garage Eight. И у ребят уже есть крутые результаты! Обязательно поделимся ими в нашем телеграм-канале.
РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.11. – "Динамический анализ кода программы". На YouTube. Слайды.
Цели 11-го процесса по ГОСТ Р 56939—2024:
Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.