Обновить
256K+

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

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

478,34
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Хуки Claude Code: запрещаем агенту коммитить без прогона тестов

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели7.1K

Правило из CLAUDE.md агент забывает на длинной сессии - это текст, а не механизм. Я разобрал слои дисциплины Claude Code и прибил критичные правила хуками: три гейта, после которых коммит без свежего зеленого прогона тестов не проходит, правка теста поднимает флаг, а завершить работу с грязными тестами нельзя. Под катом механика хуков, код всех трех гейтов с живыми прогонами и эксперимент, где гейт пересилил прямую инструкцию пользователя.

Читать далее

Новости

Harness engineering: как за год собрать фабрику из десятка конвейеров

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели13K

Агент проходит все проверки и сносит то, что трогать было нельзя. Промпт это не лечит — лечит среда вокруг модели. В ноябре я начал собирать такую среду и называл её просто фабрикой разработки. Меньше чем за год из неё выросло почти десять конвейеров, а у занятия, оказывается, есть название: harness engineering. Рассказываю, как оно росло, и показываю схему и скелет в github.

Читать далее

Klipper: опенсорс без сообщества, или почему у вашего принтера никогда не будет тулченджера из коробки

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели9.3K

Человек, чей SeaBIOS бутил ваши виртуалки с 2010 года, сегодня единолично решает судьбу прошивки ваших 3D-принтеров. У Klipper один мейнтейнер, один открытый issue — табличка «трекер закрыт» — и сотни висящих PR. Snapmaker переписал 20% кодовой базы, потому что занести тулченджер в апстрим просто некуда. Разбираю на фактах, как устроен governance де-факто стандарта прошивок для FDM — и во что его отсутствие обходится вендорам, контрибьюторам и вам.

Читать далее

Продакшн‑разработка в одиночку с AI‑агентами: принуждай к правилам, а не объясняй их

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели6.5K

В начале июля я объявил весь код своего проекта легаси. Не модуль — всё: код, архитектуру, документацию. Месяц до этого проект — джоб‑маркетплейс для синих воротничков: мобильное приложение, web, AI‑ассистент — делала команда. Люди сильные, каждый уже работал с LLM‑агентами; не было другого — методологии работы с агентами. Агент пишет код быстрее человека — и энтропию порождает быстрее: все ветки в main, решения только в чате, документация врёт, персональные данные оседают в access‑логах. Каждый исполнитель локально прав, система в целом не работает. Код, который страшно трогать, появился у нас раньше, чем первый работающий флоу. Я остановил всё и начал заново — один.

Читать далее

Как побороть сопротивление ИИ‑агентам в организации

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели6.2K

В начале 2026 года я запустил опрос в отделе: «Какими ИИ-инструментами вы пользуетесь?» Из 20 опрошенных только 3 человека пробовали ИИ-агентов в работе. Большинство технической команды — это хардкорные МЛ-щики, которые создают системы поиска патологий на медицинских снимках, а не просто дергают API ChatGPT с нужным промптом.

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

Узнать почему

Должны ли библиотеки запрещать уязвимые версии зависимостей?

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели6.5K

Когда в зависимости обнаруживают уязвимость, очевидное решение — поднять её минимально допустимую версию во всех библиотеках, которые ее используют. Тогда пакетный менеджер не подтянет уязвимую версию даже при новой установке. Сет Ларсон из Python Software Foundation предлагает не делать этого автоматически. По его мнению метаданные библиотеки должны описывать только совместимость, а контроль безопасности сборки оставаться на стороне приложения.

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

Читать далее

Product Operating Model: что происходит с ролями при переходе к продуктовой модели управления

Время на прочтение5 мин
Охват и читатели4.9K

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

Читать далее

Продуктовый разработчик 2026: кто это, откуда берётся и что с ним делает ИИ

Время на прочтение12 мин
Охват и читатели5.2K

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

Но есть компании, которые освоили концепцию продуктового разработчика. Такой человек сфокусирован не только на закрытии задач по ТЗ, а еще стремится донести дополнительную пользу и глубоко погрузиться в бизнес. Где-то говорят про T-shaped специалиста, где-то уже — про M-shaped. Мы решили разобраться в этой роли с точки зрения более-менее прикладного контекста через опыт людей, в чьих командах такие специалисты либо уже есть, либо внедряются.

Читать далее

Фокус на сегодня: как мы сделали aeman — доску для ежедневного планирования инженеров поверх GitHub Projects

Уровень сложностиПростой
Время на прочтение12 мин
Охват и читатели8.3K

Привет, Хабр! Меня зовут Андрей Квапил, я основатель Ænix — мы делаем открытую облачную платформу Cozystack и помогаем компаниям строить инфраструктуру. Мы полностью удалённая компания: 15 человек, несколько команд (две reliability-команды, команда разработки, маркетинг, бэкофис и т.д.), живем в разных часовых поясах. Поначалу мы жили в GitHub Projects, но когнда начали расти, резко упёрлись в ограничения текущих процессов: задачи размазаны по доскам и чатам, на утреннем синке половина времени уходит на выяснение «а что там у нас вообще в работе», незапланированная работа съедает весь день и нигде отдельно не видна.

Эта статья — история о том, как мы решили эту проблему инструментом aeman, который разработали сами и недавно заопенсорсили. Но начать придётся издалека.

Читать далее

Мотивация разработчиков: чек-лист для тимлида

Время на прочтение8 мин
Охват и читатели7.9K

Привет! Я Александр Субботин, руководитель отдела разработки Content AI.

За четыре года в этой роли я провел больше 50 собеседований, собрал 8 команд и несколько раз разруливал ситуации, когда топ-менеджмент считал, что команда демотивирована и с этим надо что-то сделать. Спойлер: в 90% случаев проблема была не в мотивации.

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

Читать далее

Автоматизировать бардак нельзя навести порядок

Уровень сложностиСредний
Время на прочтение23 мин
Охват и читатели10K

В предыдущей статье о ГОЭЛРО я писал о программе «А»: прежде чем строить новые мощности, план предусматривал восстановление и реконструкцию существовавшего энергохозяйства. Сначала вернуть основанию работоспособность — и лишь затем возводить на нём новое. Исторически эта часть плана действительно называлась программой «А»; такое описание приводит, в частности, Минэнерго России.

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

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

По обе стороны баррикады спор обычно формулируют одинаково: кто должен диктовать автоматизацию — бизнес или ИТ?

Я всё больше думаю, что это неправильный вопрос.

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

Читать далее

Как искать проблемы производительности в Python

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели7.2K

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

Меня зовут Юра Ашуров, я тимлид в Точка Банк. В статье расскажу, почему не стоит начинать расследование с профайлера и какие метрики помогают сузить область поиска. Всё это — на примере двух реальных кейсов с высоконагруженными проектами.

Читать далее

Дата-контракты 2.0: как мы автоматизировали обмен данными между продуктами

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели8.1K

Всем привет! С вами на связи Евгений Певцов, эксперт по качеству данных группы развития методологии из МТС. Около года назад мои коллеги уже рассказывали, зачем нам потребовались формализованные соглашения об обмене данными и какую проблему они должны были решить.

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

Сейчас дата-контракты — это полноценный сервис, встроенный в существующие ETL-процессы на всем жизненной пути данных. Им ежедневно пользуются продуктовые команды, архитекторы, аналитики и Владельцы данных. 

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

Читать дальше

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

Почему успешный ИИ-пилот может не окупиться?

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели7.4K

Хорошие показатели пилота еще не означают, что внедрение окупится после масштабирования. На INFOSTART CIO CAMP 2026 ИТ-руководители обсудят реальные затраты, ошибки и результаты ИИ-проектов - в том числе тех, которые пришлось остановить.

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

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

Читать далее

Книга: «Системная инженерия: современные методы проектирования для создания сложных информационных систем. 2-е изд.»

Время на прочтение3 мин
Охват и читатели8.6K

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

Читать далее

Document Driven Development: превращаем хаос разработки в порядок с помощью TypeSpec и не только

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели8.2K

Всем привет! Меня зовут Егор Гурин и я разработчик в компании MTC Web Services. Работаю в стриме, который занимается разработкой контактного центра МТС. Практически любые обращения клиентов в компанию, будь то неработающий интернет или вопрос по заказу в интернет-магазине, проходят через нас. 

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

В этом материале я поделюсь инструментами, которые помогли наладить процессы в нашей команде в рамках методологии Document Driven Development, — возможно, вам она знакома под такими терминами как design-first или API-first. Покажу, как в удобной форме описывать контракты с помощью TypeSpec, использовать мокирующие сервера не дожидаясь реализации серверной, а еще — расскажу про инструмент кодогенерации на Go и автотесты с помощью Schemathesis.

Читать дальше

Как мы показываем клиентам документацию по проекту из приватного репозитория, не пуская их в репозиторий

Уровень сложностиСредний
Время на прочтение3 мин
Охват и читатели12K

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

За последний год мы переписали почти всю проектную документацию в markdown и положили в тот же git, где лежит код. Причина простая: после перехода на Cursor и Claude Code так было удобнее работать. Модели нормально обрабатывают markdown и не лопатят десятистраничный google-док, диффы видно в PR, доки лежат рядом с кодом, который описывают. Всегда можно обратиться к инфе по проекту, внести обновления - короче пользоваться документом, а не хранить его для красоты.

И тут вылезла проблема, о которой лично мы заранее не подумали: документацию читает не только тот, кто её пишет. Её читают клиенты, менеджеры, дизайнеры, эйчары. А они в репозиторий не полезут никогда.

Дать клиенту доступ в GitHub/GitLab — так себе затея сразу по нескольким причинам: там лежит то, что ему видеть не надо, это лишний разговор про безопасность, да и сам интерфейс гитхаба человека не из айтишки отпугивает. Плюс требуется регистрация. В итоге мы делали то же, что, по-моему, делают все: копировали markdown в google docs, чтобы клиент мог прочитать и покомментировать, а потом при каждом изменении заново выгружали и сводили комментарии руками. Год так жили.

Что смотрели, прежде чем пилить своё:

GitBook и Mintlify хотят, чтобы ты писал в их редакторе. Ради шеринга пришлось бы бросить тот самый workflow, ради которого мы в git и переехали. Плюс ценник.

Читать далее

Почему AI не заменит разработчиков. Или заменит

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели10K

Уже куча народу высказалась по этому поводу - было и “мы все умрём, мы мамонты с лапками, нас заменят роботы”, было и “я сверхсущество, а эта машина лишь инструмент”.

Но я не встретил честной экспертной точки зрения с позиции бизнеса и разработки вместе. Были либо технарские, либо бизнесовые. 

Бизнес хочет либо “срезать косты”, либо “увеличить продажи”. Точнее даже так - об этом активно говорят бизнесмены, которые пытаются продать ИИ. От них только и слышишь маркетинговые лозунги. Написанные через ИИ.

А вот про риски никто не говорит! А это суть предпринимательства - работа с рисками. Сколько крупных игроков откатывают свои ИИ-стратегии сейчас? А ваш бизнес может позволить себе работать пару лет в дикий убыток ради эксперимента?

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

И где TRUE/FALSE?

Читать далее

Мост между SAST и фаззингом: как из сработки SAST получить подтверждённую уязвимость

Уровень сложностиСложный
Время на прочтение17 мин
Охват и читатели9.7K

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

В этой статье мы расскажем про то, как в INFERA AI.SafeCode уменьшаем поток ложных срабатываний в целом, зачем для этого формируем единый реестр знаний о проекте, и как строим мост от SAST к автоматически подтверждаемой уязвимости.

Читать далее

Как управлять командой в 2026 году: зумеры, удаленщики и методы, которые не раздражают

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели7.4K

Привет, Хабр!

Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud.

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

Читать далее
1
23 ...