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

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

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

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

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

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

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

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

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

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

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

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

И где TRUE/FALSE?

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

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

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

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

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

Классический подход к Application Security сегодня переживает кризис, ситуацию усугубляет бум AI-помощников (GitHub Copilot, Cursor, Claude). Разработка ускорилась кратно, но вместе с ней масштабировалась и генерация небезопасного кода. Разработчик теперь может сгенерировать за час то, что раньше писал день, при этом уязвимости тоже начинают появляться с такой же скоростью. Если процесс безопасности остался прежним, AppSec быстро превращается в узкое место.

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

Решение объединяет SAST, SCA, Secrets, DAST, Pentest, Code Fuzzing и API Fuzzing в единый DevSecOps / MLSecOps-контур.

Статья продуктовая, но мы ее публикуем на HABR не как рекламную, а как концептуальную. Хотим показать, как меняются подходы к безопасной разработке и насколько неэффективным становится «разрозненный» AppSec в эпоху ИИ и вайб-кодинга.

Привет, Хабр! Меня зовут Артур, директор по безопасности NtechLab и энтузиаст вайб-кодинга). Сегодня поговорим о применении вайб-кодинга в информационной безопасности внутри компании: реально ли использовать нейросеть для создания продукта «под ключ» или это заранее путь в никуда. Присаживайтесь, нас ждет увлекательное путешествие и море слез - без этого никуда:)

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

Идея создания «продукта под себя» родилась не из абстрактного желания поиграться с нейросетями, а ради формирования еще одного контура безопасности. Сотрудники уведомлены о применяемых средствах защиты, но мне хотелось не тотальной слежки, а понятной системы предотвращения и разбора инцидентов.

Первое «почти готово»

Для обычной команды разработки сделать полноценный продукт - работа на несколько этапов. Еще до написания кода пришлось бы отдельно описать, от кого мы защищаемся, какие данные считаем важными и какие действия разрешены каждой роли. В режиме вайб-кодинга задача звучала гораздо проще: «там почти все готово, давай соберем». ИИ ответил ровно так, как умеет отвечать: уверенно и деятельно. Начались сборки.

Наши аналитики почти перестали писать SQL руками и ходить к разработчикам с вопросом «как работает эта фича». Сделал это инструмент, который мы строили совсем для другого: он должен был сам закрывать задачи разработки. С исходной целью он провалился: ноль автономно закрытых боевых задач. Зато неожиданно закрыл больше половины исследовательских запросов аналитиков. Рассказываю, где именно сломалась идея «агент делает простые задачи», почему это управленческий, а не технический провал, и как побочный продукт оказался главным.

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

Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, которые можно перенести в проект сразу — от DORA-метрик и фитнес-функций до GQM-подхода.

Как я автоматизировал превращение вайбкодерского PoC в production-ready MVP

За несколько часов с помощью AI можно собрать работающий PoC: интерфейс открывается, кнопки нажимаются, основной сценарий проходит.

Потом кто-нибудь спрашивает:

А это уже можно выкатывать в прод?

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

Мне регулярно приходится заниматься именно второй половиной этой работы — превращать быстро собранные прототипы в поддерживаемые MVP.

В какой-то момент я понял, что каждый раз повторяю примерно один и тот же инженерный процесс. Так появился Pre2Prod — CLI на базе Codex, который последовательно проверяет репозиторий, составляет план исправлений, выполняет его и независимо перепроверяет результат.

Под капотом — один постоянный Reviewer, временные Workers, 41 специализированное ревью и простой цикл:

Review → Plan → Implement → Re-review

Я Анастасия, ведущий SRE-инженер РСХБ.Цифра. В этой статье я расскажу о том, как мы в App.Farm, PaaS-платформе Россельхозбанка, перешли от одной «большой» Kafka до реализации услуги «Kafka as a Service» c индивидуальными кластерами под ключ. Звучит просто, но за этим кроется сложный путь проб и ошибок. 

Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.

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

Существующая оценка качества инженерии субъективна.

Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.

Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.

Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта.

Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии. 

Что вообще такое инженерный уровень?

основные идеи по организации, структурированию и системному управлению знаниями и потоками знаний внутри компании / проекта / стартапа с учетом активного взаимодействия AI и людей в ежедневной рутине.

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

Меня зовут Юлия Аравина, я психолог и коуч IT-руководителей, а также наставник на курсах «Управление командой» и «Технический директор — СТО» в Яндекс Практикуме PRO. В этой статье я хочу разобрать, почему команда перестаёт доверять руководителю, за счёт чего формируется доверие и как его восстановить.

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

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

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

Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.

ИИ увеличивает продуктивность разработчиков на 55% — по крайней мере, к такому выводу пришли в этом исследовании.

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

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

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

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

Шеринг специалистов — парадоксальная тема. С одной стороны шеринг снижает и без того невысокие зарплаты, с другой — дает возможность прилично зарабатывать. Бизнес тоже увидел свой интерес в этой модели. Еще в 2019 году народ со знанием дела говорил, что так работать не будет, а к 2026 году сформировался целый рынок, и даже комиссия ФАС провела несколько заседаний, чтобы не дай бог никто ничего не монополизировал. Мне довелось стоять у истоков, наблюдать как появлялись первые конкуренты, как модель ушла в народ и как в конце концов смешались представления об аутсорсинге, аренде и шеринге. Понимание этой разницы приносит деньги, а непонимание — опыт.

Что ж. Попробуем разобраться.

Меня зовут Костя Дубровин. Я тот парень, который заварил эту кашу и написал об этом книгу.

Мы не планировали делать из этого материал. Просто в какой-то момент накопилось достаточно данных по запросам внутри корпоративной библиотеки Alpina Digital, чтобы можно было ответить на вопрос, какие книги читает нага IT-аудитория.

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

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

Собрал систему скиллов для Claude Code, которая эту стену обходит не за счёт «более умного» агента, а за счёт архитектуры. Девять скиллов, набор всегда активных правил, сабагент-ревьюер.

Внутри — разбор механики:

— Три слоя по частоте: always-on правила / скиллы по требованию / глубокая детализация в references, которая грузится только когда реально нужна. В контексте одновременно — правила плюс один-два скилла плюс максимум один reference, а не весь справочник разом.

— Оркестратор как диспетчер, а не исполнитель: он знает порядок фаз и кому делегировать, но не содержит предметного знания.

— Сабагент-ревьюер без прав на запись, который обязан помечать unverified (no browser tool) вместо того, чтобы выставить правдоподобную оценку по осям, которые он физически не проверял.

— Capability-check: агент инвентаризирует доступные инструменты до начала работы и докладывает пробелы вместе с фолбэками, а не проваливается молча.

Репозиторий открыт, ссылка в статье.

Команда VK Cloud перевела заключительную часть цикла Cilium про защиту цепочки поставок. Часть 1 была про контроль доступа, часть 2 — про укрепление зависимостей. Эта же часть о том, как изолировать секреты CI и продакшена за разными окружениями GitHub, подписывать каждый релиз без долгоживущих ключей через Sigstore Cosign, и какие пробелы безопасности остаются открытыми. Отдельно — разбор дорожной карты безопасности GitHub Actions на 2026 год и того, как платформенные изменения соотносятся с уже выстроенными контролями. Полезно DevOps- и SRE-инженерам, специалистам по безопасности и мейнтейнерам OSS-проектов.