Победитель хакатона от 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 в Авито.
Что обсудили
Почему нельзя просто взять и выдать обратную связь — и что нужно сделать сначала. Как говорить с руководителем честно и не бояться за репутацию. Когда анонимный фидбек лучше прямого — и наоборот. Как не сломать сотрудника критикой и можно ли вообще её оспорить. И как готовиться к встрече с разбором ошибок: с повинной головой или с готовым планом.
Бонус: в конце выпуска ведущие сами принимают «развивающую» обратную связь от слушателей. Вживую и без купюр.
Почему 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.РФ.
