Обновить
256K+

Управление разработкой *

Планирование, отслеживание и контроль

533,52
Рейтинг
Сначала показывать
Порог рейтинга

Команда Cursor представила исходный код проекта minisqlite. Это реализация СУБД SQLite на языке Rust и успешно проходящая официальный набор тестов sqllogictest от проекта SQLite.

Проект minisqlite подготовлен в ходе эксперимента по проверке эффективности работы ИИ‑моделей GPT-5.5, Grok 4.5, Opus 4.8 и Fable 5, по воссозданию SQLite только на основе официального 835-страничного руководства, без доступа к оригинальному коду, интернету, наборам тестов и исполняемому файлу SQLite. Основная идея эксперимента — использование подробной спецификации в качестве промпта для создания сложного продукта.

Представленная реализация minisqlite основывается на результатах, полученных при использовании ИИ‑модели Opus 4.8.

Проект minisqlite включает около 200 тыс, строк кода на Rust, не содержащего unsafe‑блоков в коде библиотеки. Библиотека может открывать файлы, созданные в оригинальном sqlite3, и записывать файлы, которые можно прочитать в sqlite3. Реализация охватывает диалект SQL от SQLite, поддержку транзакций, 90 встроенных функций, планировщик запросов, движок выполнения запросов и движок хранения, совместимый с дисковым форматом SQLite 3. Из внешних зависимостей в minisqlite задействован только пакет elsa, с использованием которого реализован страничный кэш.

Теги:
+3
Комментарии2

Представлен открытый конвертер book‑to‑skill для ИИ‑агентов. Проект анализирует книги и документы в PDF, EPUB, DOCX, Markdown, считывает текст, собирает конспекты глав, словарь, паттерны и шпаргалку, а затем превращает это в skill. Инстурмент экономит токены — получается в 24–51 раз меньше затрат, чем если просто закинуть нейросети целую книгу.

Теги:
+5
Комментарии0

Для MacBook вышло открытое приложение Himekuri, которое позволяет переворачивать календарь на рабочем столе. Бумага на календаре мнётся, рвётся и улетает вниз экрана. Причём вернуть ее обратно уже нельзя. Закрепить проект можно на рабочем столе, поверх всех окон или использовать как обычное приложение.

Теги:
+4
Комментарии1

Представлен открытый проект skales — ИИ‑агент, который запустится даже на слабом ПК:

  • работает как обычное приложение в Windows, macOS и Linux;

  • агент получает доступ к файлам, браузеру, почте и календарю;

  • умеет выполнять сложные задачи в фоновом режиме;

  • можно запланировать любую таску по таймеру;

  • своя встроенная память для важного контекста;

  • при этом команды отправлять можно даже со смартфона — агент выполнит их на ПК;

  • можно тестировать на бесплатном пробном режиме, подключить API или локальную модель.

Теги:
+3
Комментарии3

Инфраструктура для разработки на гиперскорости: сервисы самообслуживания и MCP в HyperDrive

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

На вебинаре покажем, как Internal Developer Platform меняет эту модель: разработчик получает готовую инфраструктуру через каталог стандартных сценариев, а DevOps-инженер управляет платформой, шаблонами и политиками.

Ключевые темы:

  • Почему инфраструктура стала главным ограничением скорости разработки

  • Почему модель «разработчик → тикет → DevOps» больше не масштабируется

  • Что такое Internal Developer Platform на практике

  • Как меняются роли DevOps и ИБ

  • Как ИИ-агент безопасно и предсказуемо взаимодействует с инфраструктурой через Model Context Protocol

  • Живое демо новой IDP-функциональности в HyperDrive: создание окружения, self-service, GitOps, встроенные политики безопасности и путь от запроса до готовой инфраструктуры

Кому будет полезно:

  • CTO

  • CIO

  • Head of Platform Engineering

  • Head of DevOps

  • Руководителям разработки

  • Platform Team

  • DevOps-инженерам

Спикеры:

Павел Лавров
Лидер продукта HyperDrive, Orion soft

Даниил Рахновский
Архитектор продукта HyperDrive, Orion soft

Регистрация по ссылке

Теги:
+3
Комментарии0
Сложность пути может заключаться как в создании нового, так и в сохранении и развитии того, что уже есть
Сложность пути может заключаться как в создании нового, так и в сохранении и развитии того, что уже есть

Варианты старта: тимлид в новой или существующей команде

Продолжаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

Как это случается

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

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

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

Стартовые позиции

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

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

Тимлид в новой команде

Новая команда начинается с чистого листа. Её предстоит собрать, поэтому на первый план выходит быстрый, но точный найм: ошибка на старте дорого обходится. Параллельно — выстраивание отношений, запуск процессов с нуля и культура работы с метриками, которой пока нет. Всё это — в сжатые сроки и при большом объёме контекста.

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

Тимлид в существующей команде

Второй сценарий — приход на замену прежнему руководителю (например, после его повышения или ухода). Чистого листа здесь нет: новому тимлиду достаются незакрытые «хвосты», настрой команды, уровень развития людей, процессы и метрики. Всё это нужно быстро оценить.

Ключевой показатель — зрелость команды или Team Maturity Model (TMM): развитая, базового уровня или незрелая. С развитой можно работать на длинную дистанцию, с незрелой — сначала закрывать базовые пробелы.

Акцент смещается на быстрые победы, укрепляющие доверие, и «north stars» для долгосрочного развития.

Сложности вступления в роль

Состояние команды удобно оценивать через три призмы: метрики, процессы и людей. По каждой из них нужно честно ответить на вопрос: ситуация критичная или некритичная? Такая диагностика быстро показывает, где горит.

Дальше всё упирается в планирование. Правильно разложенные по горизонтам быстрые победы, среднесрочные планы и долгосрочная стратегия — ключ к эффективности на старте. Ошибка в приоритетах может стоить дороже ошибки в конкретном техническом решении.

Онбординг тимлида длится около полугода. За это время необходимо: 

  • показать профессиональный авторитет; 

  • сделать прозрачными границы роли; 

  • быстро погрузиться в боли команды и продукта; 

  • обеспечить быстрые победы и план работы со сложными проблемами; 

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

Выводы

Оба сценария имеют свои особенности, но логика старта одна: быстро погрузиться в информационное поле команды, понять её проблематику и в первые одну-две недели выработать краткосрочный план, а ко второму месяцу — долгосрочное видение, ту самую «полярную звезду» развития команды.

Что дальше?

В следующей статье поговорим о целеполагании и планировании: как планировать, когда всё горит и ничего не понятно.

Теги:
+4
Комментарии1

Атака на цепочку поставки через Steam, или как вредоносный код спрятали в легитимных обновлениях

В США задержали 21-летнего Зайра Уилкинса, которого обвиняют в причастности к схеме распространения игр с вредоносным кодом через Steam. По версии следствия, встроенное в игры вредоносное ПО собирало учетные данные и другую информацию с компьютеров пользователей.

В июле 2026 года в суд поступили подробные материалы дела. В документе говорится о восьми играх с вредоносным кодом и примерно 8 тысячах зараженных устройств. Следствие связывает атаку с несанкционированным доступом приблизительно к 80 криптовалютным кошелькам и хищением не менее 220 тысяч долларов. Пока это версия обвинения, а не установленные судом факты.

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

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

Судя по опубликованным материалам, злоумышленники не взламывали сам Steam. Они встроились в штатный процесс поставки и использовали доверие к площадке, учетной записи издателя и обновлениям. Этот случай хорошо дополняет привычное представление об атаках на цепочку поставки. Точкой входа может стать не только скомпрометированная зависимость или система сборки, но и канал, через который готовый продукт доходит до пользователя.

Публикация через доверенную площадку не делает программу безопасной, а обновление необходимо проверять как новый исполняемый артефакт. Для владельца площадки это означает повторный анализ каждой загружаемой сборки, сравнение с предыдущим выпуском и запуск в изолированной среде. На устройстве пользователя такая атака уже попадает в зону, ответственности антивируса, EDR и контроля запуска приложений. Они могут обнаружить подозрительное поведение уже установленной программы, хотя ни один из этих уровней сам по себе не дает гарантии.

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Теги:
+6
Комментарии0

«Не верьте продавцам страха»: поговорили про ИИ и разработку с Тимуром UlbiTV

Недавно в гости на подкаст к нашему техлиду Саше Стародубцеву заглянул фронтенд-мастодонт и автор популярного YouTube-канала и Telegram-сообщества Тимур UlbiTV.

В выпуске ребята обсуждают:

  • заменит ли ИИ разработчиков;

  • агентов и автоматизацию разработки;

  • вайб-кодинг и качество кода;

  • найм, стажеров и джунов в эпоху ИИ;

  • обучение с ИИ и пет-проекты;

  • эволюцию и будущее разработки.

Смотрите на площадках: YouTube | VK Video | RuTube

Теги:
+3
Комментарии0

Представлен открытый проект pdf-inspector на Rust от команды Firecrawl. Это PDF-парсер, который умеет быстро обрабатывать страницы документов. Проект преобразует содержимое в Markdown, но при этом сохраняет структуру документа и таблицы. Решение работает без ограничений, код опубликован под лицензией MIT.

Теги:
+7
Комментарии0

🔥 Основы FastAPI: собираем сервис «прочитать позже»

У каждого есть свалка ссылок «прочитаю потом»: 40 вкладок, сохранёнки в Telegram, закладки с 2022 года. Проблема не в том, что нечего читать, — а в том, что всё это невозможно найти и разгрести.

Решим по-инженерному: напишем свой Read-Later сервис и с нуля освоим FastAPI.

6 августа, 19:00–20:30 МСК — бесплатный воркшоп с Ольгой Пичужкиной, Middle Python Developer (S-Cats).

За 1.5 часа:
⚡️ Поймёте, что такое FastAPI и почему он удобен
🧱 Опишете модель данных (SQLAlchemy + Pydantic)
🔁 Напишете полный CRUD
🔍 Научитесь фильтровать через query-параметры
📄 Получите Swagger UI бесплатно
🌐 Подключите простой фронтенд

Для кого: знаете Python, но ещё не писали API.

🛠 Куда дальше — дорожная карта: FastAPI — не просто фреймворк. На нём построен наш MCP Knowledge Server (Qdrant + семантический поиск) — ядро AI-ассистента сообщества, который «помнит» всё изученное.

Цепочка: 🐳 Docker (25.07) → 🐍 FastAPI (06.08) → 🧠 MCP Knowledge Server (сентябрь). В сентябре — отдельный воркшоп: поднимем такой сервер вместе.

📖 Pre-read: за 3 дня до воркшопа — инструкция по установке uv и Python.

🔗 Подробнее: https://debugskills.ru/content?article=labs-fastapi-workshop

#DebugSkills #FastAPI #Python #Backend

Теги:
+4
Комментарии0

Что делать, если ваш руководитель — чайка?
«Он появляется внезапно, громко говорит, даёт указания и исчезает. А через неделю возвращается и удивляется, почему ничего не сделано».

Супер‑стиль, особенно ощущения от общения, не правда ли?

Чайка‑менеджментом называют стиль управления, которое олды миллениалы зовут ИБД.

Для самого менеджера это энергонезатратно (включаться в процесс не нужно) + заметно для руководства повыше. Для чайки вообще удобно — выплеснул...эмоции, дал «решение» и улетел.

Для команды — хаос: планы ломаются, приоритеты скачут. Ну и последствия разгребают конечно те, кто остался.

Вы не можете быстро переделать руководителя. Но можете лечь в направлении снижения хаоса вокруг себя.

1) Готовьте факты. Перед встречей соберите короткую сводку: что происходит, какие риски, что вы предлагаете. Это не отчёт, а способ не дать эмоциям заменить разговор по делу.

2) Переводите эмоции в вопросы. У себя, и — что сложнее — у начальствующего. Не «так опять всё сломается», а «как мы поймём, что этот подход работает?» или «что будет признаком, что его стоит остановить?». Возвращаем фокус на результат.

3) Фиксируйте решения. Если на встрече что‑то решили — запишите и отправьте краткое резюме. Сохраняем контекст, в том числе для того чтобы «поймать на слове» (да, токсичненько, но иногда — помогает).

4) Предлагайте пилоты. Вместо «ок, давайте пробовать» — «давайте проверим это на одном проекте». Остаемся в безопасной зоне, используем реальные данные.

Кстати, если вы сами иногда оказываетесь в роли «чайки» — я вас не осуждаю (см. выше — это тоже способ продвижения). Но пожалуйста задумайтесь — регулярные короткие встречи, данные вместо эмоций и сопровождение вместо указов работают лучше, чем шумные появления раз в месяц.


А у вас был такой руководитель? Что помогало — или что точно НЕ помогало?

Теги:
+6
Комментарии2

PyPI готовится закреплять префиксы имен пакетов за организациями

29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.

Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.

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

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

Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.

PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.

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

Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Теги:
+6
Комментарии0

Открыли доступ к курсам по ML-системам от основ до продакшна. И да: это бесплатно

Кто-то смотрит на ML как на способ оперативно занять рыночную нишу, не понимая, какой технический фундамент необходим для реализации идеи очередного прорывного продукта. Кто-то запускает идеальный эксперимент в ноутбуке, но выясняется, что он не работает в продакшене. Это две крайности одной и той же проблемы: мало кто понимает, как работают ML-системы от первого винтика данных до последней шестеренки мониторинга. Чтобы глобально исправить это, мы собрали весь свой опыт провайдера облачных и ИИ-решений в линейку курсов Cloud.ru ML System Design и сделали доступ к ней открытым.

Какие курсы есть в линейке? 

  • «Машинное обучение в облаке»⏳15 ч — как использовать облачную инфраструктуру для разработки, обучения и эксплуатации ML-систем.

  • «ML в продакшене»⏳2 ч — база, которую нужно знать, чтобы довести модель от эксперимента до стабильной работы в боевой среде с учетом инфраструктуры, данных и процессов.

  • «Основы ML‑систем и обработки данных» ⏳3 ч — базовое устройство ML-систем, пайплайнов данных и ключевых компонентов end-to-end решения.

  • Training Data⏳3 ч — как собирать, очищать, версионировать и поддерживать обучающие данные без деградации качества.

  • Feature Engineering ⏳4 ч — как проектировать и поддерживать признаки, которые работают не только в обучении, но и в проде.

  • Model Development ⏳3 ч— как разрабатывать модели с учетом требований к качеству, воспроизводимости и дальнейшему деплою.

  • «Офлайн-оценка ML‑модели»⏳3 ч — как корректно валидировать модели до продакшена и не переоценивать их качество.

  • Model Training⏳4 ч — как строить надежные и масштабируемые процессы обучения моделей.

  • Inference⏳4 ч — как организовать инференс (онлайн и батч) с учетом latency, нагрузки и архитектурных ограничений.

  • Model Monitoring⏳3 ч — как отслеживать деградацию моделей, data drift и аномалии в проде.

  • MLOps⏳4 ч — как выстроить процессы, CI/CD и инфраструктуру для жизненного цикла ML-моделей.

  • «Проектирование ML-системы»⏳2 ч — практический кейс для отработки навыков, который поможет персонализировать ленту новостей.

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

Проходите курс и создавайте зрелые ML-продукты! 

Теги:
+3
Комментарии0

Ближайшие события

Открытый ИИ-проект JCode запускается намного быстрее Claude Code и может работать в 100 сессиях одновременно: 

  • одна сессия весит всего 28 МБ оперативной памяти.

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

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

  • работает с API Claude, OpenAI/ChatGPT/Codex, Gemini, GitHub Copilot, Azure, Alibaba Coding Plan и другими сервисами.

  • поддерживает запуск локальных моделей через Ollama и LM Studio.

  • редактирует, перезагружает, дебажит код, чтобы довести задачу до идеала.

  • можно импортировать сессии из Claude Code, Codex, OpenCode и Cursor.

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

Теги:
+8
Комментарии3

Мультиагентность — эффективный подход или просто красивый фантик?

Каждый, кто гонял задачи через субагентов, знает: это дольше, чем работа в одной сессии. Субагент сперва въезжает в контекст — заново собирает картину, что у основной сессии уже в голове. Плюс оркестрация. Работник ценный, да всякий раз с чистого листа.

Вопрос закономерный: оправдано ли это?

У нас есть приём, обычно зашитый прямо в claude.md: никакого «сам написал — сам и проверил».

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

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

  1. Полнота — покрыты все места вызова, а не одно.

  2. Нерегрессия — не сломаны ли смежные пути.

  3. Тесты — есть ли проверка на изменение и проходит ли.

  4. Скрытые баги — edge-кейсы, null, гонки, ошибки внешних сервисов.

  5. Слои — не уехала ли логика не туда.

  6. Секреты — не утекли ли ключи в код или логи.

Ключевое: аудитору не показывают авторскую версию событий — он судит по коду, а не по рассказу о нём. Нашёл проблему — возвращает автору; чинит автор, аудитор перепроверяет.

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

Аудитом дело не ограничивается. Та же логика — когда нужно независимое мнение на архитектурной развилке или когда объёмную побочную задачу (длинный лог, незнакомая библиотека) уводишь в отдельную сессию, чтоб не сорить в основном контексте. Словом, субагент хорош там, где отдельный контекст или свежий взгляд дают то, чего одна сессия не может.

Даже там, где субагент оправдан, не обязательно брать самую сильную модель. Механические проверки из чек-листа — не утёк ли ключ, есть ли тест, не уехал ли слой — прекрасно закрывает Sonnet: вопрос узкий, ответ проверяемый. А поймать то, чего не заметил автор, — гонку, хитрый edge-кейс, неочевидное архитектурное последствие — лучше попросить Opus: чтобы увидеть то, что упустил умный, нужен как минимум не менее умный. Дешёвой модели при этом ставим планку приёма: уверена — принимаем, сомневается — поднимает флаг и отдаёт выше.

Отсюда и ответ: мультиагентность — не фантик тогда, когда второго агента поднимают не «чтобы было», а там, где его независимость работает на результат. Иначе — красивая обёртка, а под ней, как водится, пусто.

Продолжение постов один и два

Теги:
+5
Комментарии0

Проект nosubscription.org содержит библиотеку с 1000+ альтернативами платным программам, включая открытые и бесплатные проекты. Есть удобный поиск и разбивка по категориям.

Теги:
+5
Комментарии0

Представлен открытый редактор презентаций Bento на замену PowerPoint. Презентация в Bento хранит внутри себя слайды, шрифты, картинки, анимации и весь редактор. Базовый файл весит около 560 КБ, открывается в браузере без установки и аккаунта, умеет сам себя сохранять, работает офлайн и даже поддерживает совместное редактирование с шифрованием.

Внутри Bento обычный JSON — поэтому презентацию могут напрямую редактировать ИИ-агенты. Есть графики, комментарии, режим докладчика, PDF-экспорт и анимации между слайдами.

Теги:
+6
Комментарии1

Anthropic обновила свой базовый курс Claude Code:

  • добавлены новые уроки, теперь их 10 шт и итоговые видео;

  • в курсе появился финальный экзамен, чтобы проверить полученные знания.

Теги:
+5
Комментарии0

Anthropic выпустила бета‑версию плагина Claude Security для Claude Code. Инструмент запускает многоагентную проверку репозитория, составляет отчёт об уязвимостях и предлагает исправления в виде патчей. Инструмент поддерживает четыре уровня глубины проверки. Чем выше выбранный уровень, тем больше агентов участвует в анализе и тем шире охват репозитория. При этом сканирование расходует токены в рамках тарифа пользователя.

Плагин работает внутри обычной сессии Claude Code и запускается командой /claude‑security. Пользователю доступны три основных сценария: проверка всего репозитория или отдельной его части; анализ изменений в ветке, pull request или коммите; создание патчей для выбранных уязвимостей.

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

Для установки необходимо подключить плагин из официального каталога Anthropic. Для работы требуется платная подписка, Claude Code версии не ниже 2.1.154, Python 3.9.6 или новее и Git. Поддерживаются Linux, macOS и Windows.

Anthropic предупреждает, что плагин не создаёт отдельной изолированной среды и запускается с правами текущей сессии. Поэтому незнакомые и потенциально вредоносные репозитории рекомендуется проверять в песочнице. В команде проекта напомнили, что Claude Security не заменяет статические анализаторы, проверку зависимостей и ручной аудит кода.

Теги:
+4
Комментарии0

Еще не поздно стать спикером на GoCloud Tech 2026 🎤

Хардкорная конференция для тех, кто создает технологии в эпоху ИИ, GoCloud Tech состоится 15 октября! Мы собираем доклады от коллег из индустрии и готовы предоставить трибуну каждому, кто хочет повлиять на развитие инженерных практик и готов делиться своим реальным опытом. Не важно, в какой компании вы работаете, если вам есть, что рассказать: 

  • о технологиях, на которых держатся современные облачные платформы, и лучших практиках работы с ними;

  • о том, как строить сложные системы и делать разработку в облаке эффективнее и безопаснее;

  • о том, как подготовить данные и инфраструктуру к работе с ИИ.

Ждем ваши заявки на выступление до 11 августа!

Вместе обсудим, как ИИ меняет инфраструктуру, разработку и работу с данными.

Узнать подробнее о тематиках и таймлайне подготовки, а также подать заявку можно на лендинге

Теги:
+3
Комментарии0

T-shaped снова в моде?

Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных.

В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.

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

Сейчас же ИИ действительно позволяет увеличить производительность, что само по себе приводит к укрупнению зон ответственности, но это явление временное. Когда агенты станут такой же обыденностью как персональные компьютеры (представьте разницу между теми у кого они были и у кого их не было в 80 годы), то для увеличения производительности труда снова придется дробить ответственности и брать больше людей.

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


Через 5 лет мы будем оглядываться назад и говорить о том, как все было очевидно, вот это работает, а вот это бы не заработало никогда. Как говорится, знал бы прикуп жил бы в Омске

Теги:
+5
Комментарии0

Как мы закрываем задачу: тесты, диптрак, аудит и ещё пара рубежей

Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет done.

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

1. Автоформат — молча и сразу. После каждого Edit/Write срабатывает хук: Pint для PHP, Prettier для JS/TS правят изменённый файл. Не блокирует, ничего не спрашивает. Форматирование просто снято с повестки — про пробелы и переносы мы не спорим никогда.

2. Приёмка «прогнал — работает» (скилл verify-task). Финал задачи — не «по идее работает», а таблица. Перечитываем Definition of Done, по каждому пункту: как проверено → PASS/FAIL. Внутри:

  • прогон тестов затронутой области (Pest/PHPUnit) — зелёные, а не «вроде есть»;

  • smoke живого сценария через tinker или artisan-команду;

  • корнер-кейсы: пусто, граница, null, таймаут внешнего сервиса;

  • в diff нет ключей и .env.

Любой FAIL — задача не закрыта. Без «ну это мелочь, потом починим».

3. Deptrac — границы слоёв (Stop-хук). На попытке закрыть ход прогоняется анализатор архитектуры. Уехала логика из сервиса в контроллер, модель полезла напрямую во внешний API — exit 2, ход не закрывается, пока не переложишь код в правильный слой. Тот же гейт стоит в CI, а легаси-долг зафиксирован baseline’ом, чтобы старые грехи не блокировали новую работу. Правило в конфиге кажется неверным? Правь конфиг явно и объясняй — обходить молча нельзя.

4. Секреты не текут (guard-secrets). Отдельный хук стережёт, чтобы содержимое .env, ключей и дампов не улетело в чат: cat/grep по секретному файлу блокируются, Read на него — тоже. Править такие файлы можно (Edit/scp), а вываливать в переписку — нет.

5. Рефлексия — иначе не закрыть (guard-discipline). Код менялся, а записи в task/history за сегодня нет? Снова exit 2. Хук требует короткий разбор: что ставили, как решал, решено да/нет/частично, что можно было лучше. Следующая сессия начнёт с этих заметок и не наступит на те же грабли.

6. Независимый аудит — по коду, а не по рассказу. После нетривиальной доработки запускается отдельный агент, который не видел, как ты решал. Ему дают diff и чек-лист: все ли call-сайты покрыты, нет ли регрессий, есть ли тесты, скрытые баги, не уехали ли слои, не утекли ли секреты. Вердикт — APPROVE или CHANGES NEEDED со списком «файл:строка — почему». Нашёл проблему — не чинит молча, возвращает автору. Без аудита мёрдж не предлагаем.

7. И только теперь — в done и на мёрдж. Задача переезжает в task/done до открытия MR, в той же ветке. Прямой push в main закрыт хуком — только через merge request. А прод-pull делает человек: guard-prod fail-closed не пускает агента мутировать боевой сервер, агент лишь готовит команды.

Тут важно, кто есть кто. Автоформат, Deptrac, защита секретов, рефлексия, запрет пуша в main и защита прода — это хуки. Они срабатывают автоматически на события (после правки файла, при попытке закрыть ход, перед bash-командой) и возвращают exit 2, если что-то не так. Их нельзя «забыть» или уговорить — они не читают промпт, они перехватывают действие. А приёмка и аудит — это скиллы, процедуры, которые агент запускает сам: тут уже нужна голова, а не только стенка. Стенки ловят механику, скиллы — смысл.

Звучит как гора бюрократии — но пять рубежей из семи срабатывают сами и молча. Человека дёргают только там, где цена ошибки настоящая: на аудите и на проде.

«Готово» — не когда агент дописал код, а когда код прошёл все рубежи.

Теги:
+3
Комментарии0

Задача — это файл в git, а не сообщение в чате

Предисловие. За год плотной работы с ИИ-агентами — пять проектов доехали до продакшна — у нас сложился набор практик. Разбираем по одной. Первая и базовая: где живёт задача.

Приходит, значит, товарищ к агенту: сделай, милый, вот такую фичу. Агент кивает, бодро пишет код, всё замечательно. Проходит два дня. Товарищ открывает новый чат — а там пусто. Агент не помнит ни фичи, ни уговора, ни что «готово» вообще должно было означать. У него каждое утро чистый лист. И сидит наш товарищ, восстанавливает контекст по диффу, как археолог по черепкам.

Причина простая: задача жила в переписке, а переписка не версионируется и сессию не переживает. Поэтому у нас задача — это файл в git, рядом с кодом. Он коммитится вместе с кодом, который его закрывает, и едет в той же feature-ветке.

Структура папок

Всё, что касается задач, лежит в репозитории и отслеживается git (у нас — 294 файла):

task/                  ← активные задачи (сейчас в работе)
├── done/              ← закрытые
└── history/           ← рефлексия по сессиям (отдельная практика)
plans/                 ← длинные roadmap'ы
  • task/ — только то, что сейчас в работе. Незакрытое и без хвостов. У нас тут обычно 1–3 файла.

  • task/done/ — задача переезжает сюда, как только выполнен Definition of Done. Не после деплоя, а сразу как критерий закрыт. Это архив сделанного: сейчас 121 задача, каждую можно открыть и посмотреть, что и как решали.

  • plans/ — большие направления, которые не влезают в одну задачу. Roadmap режется на пачку мелких task-файлов; агент читает общий план, потом берёт из него конкретный кусок. Сейчас 9 роадмапов.

  • task/history/ — рефлексия по сессиям. Это уже про память агента, отдельная практика; здесь только упоминаю, чтобы структура была полной.

Имя файла — YYYY-MM-DD_HH-MM-название.md, с датой и временем создания. Даёт хронологию из коробки: задачи сортируются по возникновению, имена не конфликтуют, ничего не перетирается.

Что внутри задачи

  • Одна задача = одна функция. Она же — одна feature-ветка и один MR. Есть задача на эту фичу — работаем с ней, вторую не заводим: два файла на одно дело — и потом сам не разберёшь, который из них настоящий.

  • Фазы со статусом. Внутри — шаги, у каждого [ ] или [x]. Сессия оборвалась — следующая открывает файл и видит, где остановились: что сделано, что ждёт, что готово, но не проверено. Состояние читается из файла, а не восстанавливается по памяти.

  • Definition of Done — перечисляемым списком. Не «сделать фичу», а конкретные пункты: что именно должно работать. Без списка «готово» у каждого своё. Этот же список потом становится чек-листом приёмки: пункт → проверка → PASS/FAIL, любой FAIL — задача не закрыта.

  • Итоговый блок. В конце — реализовано целиком или нет, что осталось, какие решения приняли и почему.

Скелет реальной задачи из проекта:

# Фаза 7 — калибровка порога confidence
**Тип:** chore + small feat
**Ветка:** chore/retrieval-calibration
**Зависимости:** фаза 6 в проде
**Статус:** Шаг 1 готов; Шаги 2-3 ждут трафика

## Прогресс
- [x] Шаг 1 — инструментовка. Тесты зелёные.
- [ ] Шаг 2 — сбор датасета с прода (ждёт трафика).
- [x] Шаг 3 — эвал-команда готова. Осталось прогнать на реальных данных.

## Контекст
Почему пороги пока с потолка и что от них зависит.

Что это даёт

  • Переживает сессию и машину. Контекст не теряется между чатами: новый агент читает файл и продолжает с той же точки.

  • Едет в ревью вместе с кодом. Ревьюер видит не только дифф, но и зачем он и по каким критериям принимать.

  • Имеет историю. Кто завёл, когда, что и почему решили — в git-логе, а не в чьей-то памяти. Через полгода понятно без археологии.

  • Держит остальные практики. Приёмку не сверить, если непонятно, что считалось «сделано». DoD из файла и есть этот критерий.

Мораль простая. Пока в файле не прописано, что считается «готово», любое «готово» — вопрос веры. Вера в хозяйстве вещь неплохая, но к продакшну отношения не имеет. Список превращает её в проверяемый факт.

Теги:
+6
Комментарии1

Забирать или оставлять

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

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

  • Если результат — запущенные проекты, то переход в новую компанию целой командой выглядит оправданным. Слаженный коллектив обеспечивает высокую скорость работы. Знаю людей, которые так вместе и кочуют из компании в компанию.

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

Оба подхода имеют право на жизнь, но лично мне ближе второй. Если бывший коллега сам придёт, я могу его рассмотреть, но сам никогда не ханчу людей из предыдущей компании. Мне интересно выращивать одних руководителей, чтобы после «выпускного» набирать новых.

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

Теги:
+4
Комментарии0

Пусть за вас сегодня кто-нибудь другой черепикнет не в ту ветку, сосквошит двадцать коммитов в один с сообщением fix, заребейзит поверх мастера, получит сорок конфликтов, будет разрешать их методом «взять свою версию везде», потому что разбираться уже нет ни времени, ни сил, ни человека внутри, запушит форсом, сотрет чужую неделю работы, сделает вид, что так и было. Пусть в пятницу в 18:47, когда все почти встали из-за стола, он задеплоит, сломает прод, полезет в логи, не поймет, полезет ещё раз, поймёт, откатится и тут же обнаружит, что откат тоже сломал прод, только еще интереснее, заплачет сначала тихо, чтобы не услышал тимлид, потом громко, чтобы всё-таки услышал, всё-таки поднимет прод, повесит тег v1.0.4-hotfix-final-FINAL-2, напишет в общий чат «всё ок», через сорок секунд получит в личку скриншот пятисотки без единого слова, просто скриншот. Пусть настраивает CI: ждёт восемь минут, падает на линтере из-за лишнего пробела, правит пробел, ждёт восемь минут, падает на тестах, которые падали и до него, всегда падали, все про это знали, закомментит тест, ждёт восемь минут, видит зелёненькое, испытывает счастье такой силы, какой в его жизни давно ничего не вызывало. Пусть сверстает страницу, идеальную во всех браузерах, кроме сафари, объявит, что сафари это не браузер в текущем спринте не поддерживаемый. Пусть пойдёт общаться с нейронкой: попросит функцию, получит функцию с несуществующей библиотекой, попросит ещё раз, получит извинения плюс ту же самую функцию, спросит «ты уверен?», получит «вы абсолютно правы, приношу извинения» плюс третью версию, которая хуже первых двух вместе взятых, после чего напишет какой-то говнокод сам за четыре минуты. Пусть сядет тренировать модель, увидит accuracy 0.99, обрадуется, найдёт таргет в фичах, перестанет радоваться, потренирует заново, увидит 0.51, посидит молча минут двенадцать, чтобы осознать. Пусть анализирует данные, пока не выяснит, что половина строк это тестовые записи некоего «ааааа» с почтой test@test.test, зарегистрированные в 1970 году. Пусть скроллит логи два часа подряд, мимо бесконечного INFO: ok, найдёт наконец WARN, узнает, что варнинг живёт там с 2021 года, его все любят, трогать не дают. Пусть сходит на дейлик, скажет «вчера доделывал таску, сегодня продолжу, блокеров нет», ровно то же, что вчера, что позавчера, никто не заметит, дейлик всё равно продлится сорок минут, потому что двое начнут обсуждать архитектуру. Пусть погуглит ошибку, найдёт единственный тред на стековерфлоу, а там тот же вопрос, ноль ответов, комментарий автора «nevermind, solved it», 2013 год. Пусть дропнет базу на проде, потому что был не в той вкладке терминала, полезет проверять бэкапы, узнает, что бэкапы настроены, но не проверялись ни разу, вот именно так и узнает, зачем их вообще проверяют. Пусть оставит джуну на ревью двадцать восемь комментариев, из которых двадцать шесть про нейминг, два про то, что этот код вообще писать не следовало, через два дня поставит апрув без единого изменения, потому что дедлайн. Пусть напишет документацию, которую никто не прочитает, не найдёт документацию, которую кто-то написал до него, напишет её заново. Пусть вынесет константу в конфиг, конфиг в переменные окружения, переменную на сервер добавить забудет, сломает прод, тем самым замкнёт круг. Пусть переименует переменную data в dataList, потом в items, потом обратно в data, потратив сорок минут того самого ясного утреннего ума, которого хватило бы на настоящую задачу. Пусть обновит зависимости, получит сто сорок уязвимостей вместо двенадцати, откатит и решит, что двенадцать это, в общем-то, немного. Пусть объясняет менеджеру, почему «просто добавить кнопочку» это три недели, не убедит, добавит кнопочку за три недели, услышит «ну вот, а говорил». Пусть выгорит, возьмёт отпуск, будет читать рабочий чат в отпуске, вернётся ровно в том же состоянии, только загорелый.

А вы не ходите.

Пусть оно сегодня всё само как-то себя черепикнет.

Теги:
+9
Комментарии0

Представлен открытый проект на Go под названием Castor. Умные ТВ не могут транслировать произвольное веб-видео, а зеркальное отображение экрана тормозит и теряет разрешение. Вместо этого Castor транслирует реальный поток в полном качестве с ПК на ТВ.

«Я создал Castor, потому что не мог транслировать веб‑видео со своего ноутбука на телевизор: не было Chromecast, не было AirPlay. Наведите его на любую веб‑страницу, и Castor найдет видео, извлечет поток, перекодирует его для вашего телевизора и транслирует в реальном времени. Он также принимает прямой URL‑адрес потока или идентификатор IMDB/TMDB и может встраивать автоматически сгенерированные субтитры», — пояснил автор проекта.

Castor запускает Chrome в headless режиме с рандомизированным фингерпринтом и скрытыми скриптами для маскировки автоматизации. Решение отслеживает весь сетевой трафик через протокол Chrome DevTools для захвата видеопотока, а затем запускает короткий конвейер действий: кликнуть по странице, перейти в самый большой iframe, решить проблему с Cloudflare Turnstile, если таковая появится, и снова кликнуть в качестве резервного варианта.

Теги:
+9
Комментарии0

Илон Маск заявил, что в скором времени после завершения рецензирования безопасности кодовой базы весь исходный код социальной сети X (Twitter), без исключений и сокрытия частей, будет опубликован в рамках открытого проекта. Для подтверждения, что в инфраструктуре X используется именно тот открытый исходный код, что был опубликован, будут привлечены независимые проверяющие. По мнению Маска, полное доверие достижимо только при условии полной прозрачности процессов.

Теги:
+8
Комментарии1

Представлен сборник лучших скиллов Cursor Team Kit от разработчиков Cursor: 

  • внутри 18 скиллов, 2 субагента и 2 правила;

  • есть навыки для написания точного и понятного кода, для мощного ревью, удаления код‑слопа и импорта необходимых библиотек.

Теги:
+3
Комментарии0

Изучаем GitHub за выходные — IT-платформа выпустила подробный роадмап для новичков-разрабочтков, где понятным языком объясняются все тонкости работы с ветками, репозиториями и контролем версий, а также рассказывают, как делать свой вклад в Open Source.

Теги:
+5
Комментарии0

npm 12 больше не запускает скрипты установки зависимостей без разрешения

npm 12 больше не запускает скрипты установки зависимостей автоматически и требует отдельно разрешать установку из внешних источников и Git. Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации. В посте разбираем, что это меняет для безопасности установки пакетов и что стоит проверить перед обновлением. 

8 июля 2026 года GitHub выпустил npm 12 и пометил его тегом latest. Вместе с новой версией изменился базовый сценарий установки – раньше скрипт зависимости мог выполниться автоматически, теперь проект должен заранее разрешить его через allowScripts.

Ограничение распространяется на preinstall, install, postinstall и неявные сборки через node-gyp. Если такой скрипт действительно нужен, его можно добавить в список разрешенных; для разбора уже существующего проекта npm предлагает команду npm approve-scripts --allow-scripts-pending, которая показывает зависимости без явно заданного решения и помогает сохранить настройки в package.json.

Тот же принцип теперь применяется к зависимостям из Git и удаленным архивам. Без --allow-git npm откажется устанавливать Git-зависимости, а для архивов по внешним URL понадобится --allow-remote. В июньском анонсе npm 12 GitHub отдельно отмечал, что Git-зависимости создавали обходной путь для выполнения кода даже при использовании --ignore-scripts.

Одновременно npm начинает ограничивать токены с обходом двухфакторной аутентификации: в начале августа 2026 года они потеряют доступ к чувствительным операциям управления аккаунтами, пакетами и организациями, а позднее не смогут напрямую публиковать пакеты. Для автоматической публикации GitHub рекомендует переходить на доверенную публикацию через OIDC или использовать публикацию с ручным подтверждением.

Почему это важно

Новые настройки заметно сужают возможности для атак через установочные скрипты. Это хорошо видно на примере Shai-Hulud и Shai-Hulud 2.0. В первой вредоносные версии пакетов в основном запускали код через postinstall, а во второй для этого использовался preinstall. Однако важно понимать, что вредоносный пакет по-прежнему может попасть в реестр и дерево зависимостей, а нежелательный код выполнится позднее, когда его импортирует приложение или система сборки. npm 12 закрывает не весь путь заражения, а именно автоматическое выполнение кода непосредственно во время установки. Более широкий разбор атак через пакеты и другие звенья цепочки поставки есть в нашей статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Перед переходом на новую версию командам стоит проверить:

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

  • откуда в проектах появляются Git-зависимости и удаленные архивы

  • есть ли в CI долгоживущие токены публикации с лишними правами

Подписывайтесь на Codescoring в Telegram, VK, YouTube и Макс.

Теги:
+4
Комментарии0

Системный и бизнес‑анализ: 10 бесплатных уроков о требованиях, процессах и архитектуре

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

Собрали открытые уроки для системных и бизнес‑аналитиков. В программе — ArchiMate и TOGAF, управление рисками, Use Cases, BPMN, нефункциональные требования и архитектурные модели. Уроки проводят преподаватели‑практики: во время встречи можно задать вопросы по теме и посмотреть, как устроено обучение.

Бизнес‑анализ

Системный анализ

Больше бесплатных уроков июля смотрите в дайджесте.

А если для вас актуален карьерный переход в системном анализе, читайте полный разбор тестового задания на 2026 год.

Теги:
+7
Комментарии0

Вчера был на презентации нового цифрового продукта.

Ребята проделали огромную работу!

  • продумали сложную логику,

  • разложили систему на огромное количество элементов,

  • реализовали возможность доступа к каждому элементу,

  • связали все эти элементы в единую систему,

  • современный дизайн,

  • куча раскрывающихся менюшек,

  • бесконечное количество возможностей смотреть на систему под разными углами.

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

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

Так вот, чтобы ехать - надо разобраться (инструкцию пока никто не написал) какие детальки откуда и собрать всё это в целостную конструкцию. Смотря на все это великолепие (а ехать то надо) - хочется из "галок и палок" соединить два лежащих колеса в подобие самоката и на толкаче поспешить к нужной цели...

Выражение приписывают Генриху Альтшуллеру, основателю ТРИЗ
Выражение приписывают Генриху Альтшуллеру, основателю ТРИЗ
Теги:
+3
Комментарии0

Какое-то время работал по классическому скраму. Двухнедельные спринты, планирование, ретро, демо. Всё как в учебнике.

Потом перешёл на недельные циклы и мне зашло.

Две недели это слишком долго чтобы понять что пошло не так. Берёшь задачу, через неделю понимаешь что оценка была неверной, контекст изменился или задача вообще потеряла смысл. Но спринт ещё идёт и ты либо тащишь её до конца ради метрик либо объясняешь почему не доделал.

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

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

Но в целом для небольших команд недельные циклы работают лучше. По крайней мере у меня.

Кто пробовал менять длину спринта - назад вернулись?

Теги:
+4
Комментарии2

Представлен проект «Контекстные бомбы: остановка ИИ‑атак на корню». «Теперь ИИ‑агенты могут самостоятельно проводить сложные кибератаки: получив доступ к базе, самые сильные модели могут повысить свои привилегии и похитить данные за считанные минуты. Модули Canary — ресурсы‑приманки, которые мы размещаем для обнаружения злоумышленников, — надёжно обнаруживают этих агентов в действии, но обнаружение атаки — это не то же самое, что ее предотвращение. Поэтому мы попробовали нечто более амбициозное: контекстную бомбу — короткий фрагмент текста, спрятанный в канарейке, который активирует защитные механизмы ИИ‑агента и останавливает его на корню. Контекстная бомба — короткий фрагмент текста, предназначенный для активации защитных механизмов атакующих ИИ‑агентов, размещаемый непосредственно на пути их атаки», — пояснили в команде Tracebit Research.

Эффективность этого проекта может варьироваться в зависимости от поставщика модели. Мы тестировали контекстные бомбы на пяти перспективных моделях, выполняющих атаку «красной команды» в реалистичной среде AWS. Развёртывание одной контекстной бомбы внутри среды (в качестве секрета AWS) оказало огромное влияние на остановку атакующих ИИ-атак. Например, эскалация привилегий администратора снизилась с 57% запусков до 5%.

Теги:
+4
Комментарии0

Теперь ты тимлид: роль, майндсет и границы ответственности

Повелеваю тебе быть ответственным, проактивным и системным…
Повелеваю тебе быть ответственным, проактивным и системным…

Сегодня мы начинаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

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

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

Три направления работы тимлида

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

Второе направление — процессы. Оно предполагает системный подход к развитию на основе метрик и данных. Универсальный план работы: определение метрики, её фиксация, изменение процесса, контроль метрики, коррекция плана и продолжение при необходимости.

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

Границы ответственности и принятие решений

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

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

  • discovery составляющая — продакт-оунер, дизайнер, аналитик, редакторы и т. д.;

  • техническое руководство — руководители разработки и функциональные руководители направлений; 

  • delivery-составляющая — инженеры команды различных функциональных направлений;

  • смежники: соседние команды, партнеры, HR-функция, административный персонал и т.д.

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

От теории к практический кейсам

В следующих статьях мы рассмотрим наиболее распространённые ситуационные кейсы:

  • Варианты старта: тимлид в новой команде или в существующей.

  • Целеполагание: как планировать, когда всё горит и ничего непонятно.

  • Команда и люди: офферы, лоу-перформинг, увольнение, друзья, лояльность.

  • Процессы: «и так нормально», бюрократия, эксперименты.

  • Менеджерские кейсы: приоритеты, риски, разделение команд.

  • Сложные ситуации: конфликты, смена продукта, откат обратно в инженеры, микроменеджмент.

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

Теги:
+6
Комментарии2

Почему хорошие вопросы ценятся не меньше хороших ответов

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

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

Вот несколько ошибок, из-за которых вопросы чаще запутывают, чем помогают.

Спрашиваем «как», не разобравшись с «зачем»

«Как нам реализовать эту фичу?»

✔️ «Какую задачу решаем этой фичей? Есть ли другие способы?»

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

Не проверяем, был ли похожий опыт в команде

«Как правильно настроить X?» 

✔️ «Кто-нибудь в команде уже настраивал X или сталкивался с похожей задачей?»

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

Не даем контекста

«У меня ошибка, можете помочь?»

✔️ «Получаю ошибку X при действии Y. Уже проверил A и B, но проблема осталась. Вот лог / скрин / ссылка. Подскажите, где еще посмотреть?»

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

Просим оценку, когда нужна обратная связь

«Правильно ли я сделал?»

✔️ «Что можно улучшить в этом решении? Есть ли риски, которые я не учел?»

Вопрос «правильно ли?» часто сводит ответ к короткому «да» или «нет». Но в работе важны нюансы: возможные риски, альтернативы, слабые места. Если сразу попросить не оценку, а обратную связь, обсуждение получится полезнее.

Не задаем фокус для ответа

❌ «Что думаешь?»

✔️ «Посмотри, пожалуйста, логику: понятно ли, какую проблему решаем и почему предлагаем именно такое решение?»

«Что думаешь?» кажется удобным вопросом на все случаи, но в нем слишком много свободы для ответа. Собеседник может оценить формулировки, логику, детали реализации, сроки и при этом не попасть в то, что действительно важно. Когда фокус задан сразу, обратная связь получается точнее.

Теги:
+4
Комментарии1

Заряжаемся перед Робозоном: решаем задачу и погружаемся в атмосферу хакатона от Ozon Tech

«Подумаешь, коробка», — скажете вы. И правда, что может быть проще коробки… когда она одна. А что насчёт миллионов коробок? Бесконечный поток товаров, текущий по сортировочному центру. Конвейеры, сканеры, роботы — элементы сложной логистической системы — направляют и упорядочивают этот поток. И от разработчиков, от их способности создавать эффективные алгоритмы обработки товаров и устранять узкие места зависит, насколько быстро и безошибочно будут двигаться коробки.

Не верите? Тогда попробуйте сами решить задачку из серии «не дай конвейеру захлебнуться коробками».

Представьте: в логистическом центре два конвейера, 1 и 2, сливаются в один основной — конвейер 3, ведущий к сканеру штрихкодов. Поток на линии 1 — 1000 товаров в час, на линии 2 — 500 товаров в час. Сканер на линии 3 обрабатывает до 2000 товаров в час. Но вот беда: в точке слияния конвейеров товары сталкиваются, что приводит к затору. Датчики фиксируют «аварию», система постоянно делает микроостановки, поэтому реальная пропускная способность линии 3 падает до 1100 товаров в час.

Вам поручили придумать решение, которое поможет устранить заторы. Что вы выберете?

А. Увеличить скорость линии 3 до 2500 товаров в час, чтобы она моментально «выдёргивала» товары из точки слияния.

Б. Установить на линиях 1 и 2 логику «светофора» (накопительные буферы), пуская товары пачками по очереди.

В. Ускорить линию 2, чтобы её поток «проскакивал» в окна между товарами с линии 1.

Уверены в своём решении? Тогда проверьте его правильность под спойлером.

Вариант А кажется хорошим решением, но на деле не спасёт ситуацию. Запас по скорости на линии 3 есть и так (2000 > суммарных 1500), и если ускорить принимающий конвейер ещё больше, товары просто будут ехать по нему с большими просветами, но коробки с линий 1 и 2 всё равно будут приходить в точку слияния одновременно и застревать.

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

Вариант Б — единственно верный в данной ситуации. Искусственное притормаживание потоков для формирования управляемых «пачек» (плотный поток с линии 1, затем пауза и сброс товаров с линии 2) повышает общую скорость системы, убирая хаос и микроостановки. Парадоксально, не правда ли?

Ладно, это была всего лишь разминка. Настоящие сложные задачи мы приберегли для хакатона Робозон с призовым фондом 15 000 000 рублей.

Участвовать в Робозоне

На Робозоне вас ждут три трека:

  • имитационное моделирование сортировочного центра;

  • конструкция автоматизированного сортировщика товаров сортировочного центра;

  • интеллектуальная роботизированная система сортировки товаров.

Робозон стартовал 2 июля, регистрация продлится до 23:59 11 июля. Хакатон пройдёт в два этапа. Первый завершится 2 августа, и 11 августа будут известны финалисты. Во второй этап пройдут по 5 лучших команд из каждого трека, чтобы до 6 сентября доработать свои решения и побороться за победу на очной защите 12 сентября в Москве. Победителей наградят 13 сентября на конференции E-CODE.

Ещё больше информации о правилах участия, призах и даже подсказки, кого стоит набирать в команды для разных треков, — на сайте ozon-robozon.ru.

Участвуйте в хакатоне — пусть инженерная мысль помогает управлять многомиллионным потоком товаров.

Теги:
+12
Комментарии7

Управление людьми с нуля

С Оксаной Фаст мы познакомились в беговом клубе. «Фамилия прямо для бега» — подумал я тогда. Год назад она перешла в WB, и мы стали коллегами.

Недавно у Оксаны вышла книга «Управление людьми с нуля».

Везёт мне на талантливых коллег, которые не только достигают мастерства в какой-то области, но и умеют делиться своими знаниями.

В этой книге вы найдёте:

  • истории из личного опыта;

  • примеры из разных компаний;

  • чек-листы по каждой теме;

  • лайф-хаки, как делать хорошо;

  • рецепты, если всё уже плохо.

Самой интересной для меня оказалась последняя глава: «Личная эффективность: как управлять собой, чтобы управлять другими?». Она короткая, но, на мой взгляд, самая важная во всей книге.

Рекомендую всем руководителям, а также тем, кто только собирается им стать.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Что изучить на неделе: 13 открытых уроков по LLM, Go, QA, ЦОД и управлению

С 6 по 13 июля проведём серию бесплатных уроков для тех, кто занимается разработкой, архитектурой, ИИ, инфраструктурой, безопасностью, тестированием и управлением.

Это темы, которые помогут в решении реальных рабочих задач: от LLM‑приложений и RAG до метрик CTO, балансировки трафика в ЦОД и чистой архитектуры на Go.

ИИ и LLM

  • 6 июля, 20:00 «Как сделать LLM-приложение, которое отвечает клиентам по базе знаний компании». Записаться
    Разберём, как устроить приложение, которое ищет ответы в корпоративной базе знаний и помогает автоматизировать клиентские коммуникации.

  • 7 июля, 20:00 «Обучение с подкреплением — гибкий подход для сложных задач. Создаём собственные окружения». Записаться
    Поговорим о том, как работает reinforcement learning и как создавать собственные окружения для экспериментов и обучения агентов.

  • 7 июля, 20:00 «OWASP Top 10 для LLM-приложений: карта угроз, которую должен знать каждый». Записаться
    Разберём основные риски LLM-приложений: prompt injection, утечки данных, небезопасные плагины и другие типовые угрозы.

  • 13 июля, 18:00 «LoRA и RAG: как адаптировать LLM под свои данные и задачи». Записаться
    Покажем, чем отличаются подходы LoRA и RAG и как использовать их для настройки LLM под конкретные бизнес-сценарии.

Разработка и архитектура

  • 8 июля, 20:00 «Чистая архитектура на Go без карго-культа: слои, DTO и интерфейсы». Записаться
    Разберём, как применять принципы чистой архитектуры в Go-проектах без лишних абстракций и усложнения кода.

  • 8 июля, 20:00 «Продвинутое использование отладчика GDB». Записаться
    Поговорим о возможностях GDB, которые помогают глубже анализировать поведение программы и быстрее находить сложные ошибки.

  • 8 июля, 20:00 «Новшества языка ArchiMate 4.0». Записаться
    Посмотрим, что изменилось в ArchiMate 4.0 и как эти изменения могут пригодиться при описании архитектуры.

Инфраструктура и ЦОД

  • 7 июля, 20:00 «Особенности балансировки трафика ЦОД, чтобы не случилось “всё упало, всё пропало”». Записаться
    Разберём, как устроена балансировка трафика в дата-центрах и какие ошибки могут привести к отказам и перегрузкам.

QA, управление и процессы

  • 7 июля, 19:00 «Как читать баги: метрики для руководителей команд тестирования (QA Lead)». Записаться
    Покажем, какие метрики помогают QA Lead видеть реальное состояние продукта, команды и процесса тестирования.

  • 7 июля, 20:00 «Операция "Воркшоп": как получить поддержку руководства для новой инициативы». Записаться
    Разберём, как подготовить инициативу, провести воркшоп и аргументировать идею так, чтобы её поддержали стейкхолдеры.

  • 8 июля, 20:00 «Метрики CTO: как доказать бизнесу, что инженерная команда работает эффективно». Записаться
    Обсудим, какие инженерные метрики понятны бизнесу и как с их помощью показывать вклад команды в результат.

  • 8 июля, 20:00 «Как писать PRD, ТЗ и user stories с помощью ИИ — быстро, структурно и без мусора». Записаться
    Разберём, как использовать ИИ для подготовки требований, пользовательских историй и технических заданий без потери смысла и структуры.

HR и стратегия

  • 9 июля, 20:00 «HR на языке цифр: от кадров к стратегии». Записаться
    Поговорим о том, как HR-метрики помогают переходить от операционной работы с кадрами к стратегическому управлению людьми.

Больше открытых уроков июля смотрите в дайджесте.

Теги:
Всего голосов 3: ↑3 и ↓0+7
Комментарии0

РБПО по ГОСТ Р 56939—2024: вебинар №30 из 30 — Сертификация процессов РБПО: требования ФСТЭК России, новые стандарты и практика

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "Сертификация процессов РБПО: требования ФСТЭК России, новые стандарты и практика". На YouTube. Слайды.

Финальный дополнительный вебинар прошёл при участии ведущих экспертов: Дмитрия Шмойлова, Алексея Щербакова и Виталия Вареницы. Участники обсудили практику сертификации, новые национальные стандарты и методику подготовки, опыт компаний, а также подводные камни аудита и преимущества внедрения РБПО.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

НЕкурс про РБПО

Суммарное время предлагаемых к изучению вебинаров составляет около 50 часов. Это достаточно большая задача, поэтому мы решили помочь и разбили материалы на отдельные уроки по РБПО. Возможно, так вам будет проще усваивать материал, а интерфейс позволяет отмечать, с чем вы уже ознакомились.

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0
1
23 ...