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

ИИ увеличивает продуктивность разработчиков на 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-проектов.

Мы с братом вдвоём разрабатываем WorkHub. До этого у нас не было профильного образования и опыта создания цифровых продуктов. Мы не работали внутри IT‑команд и не проходили путь от стажёра до разработчика. Возможность начать появилась во многом благодаря ИИ‑инструментам.

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

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

В настоящее время основным направлением развития экономики и производства является повышение производительности труда. В Современном экономическом словаре, Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б., 2-е изд., испр. М: ИНФРА-М. 479 с., 1999, этому понятию дается следующее определение:

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

Из определения явствует, что трудовым ресурсом является человек (работник), который производит продукцию с определенной интенсивностью за фиксированное время. Измерять результат его труда можно как в количественном, так и в денежном выражении. Главным образом этот показатель эффективности использования ресурсов труда применяется в производстве материального продукта, где его расчет не представляет трудностей. А как быть с расчетом производительности труда, когда его продуктом является: услуга, работа, информация? В настоящей статье этот вопрос рассматриваться не будет, так как это отдельная тема, требующая внимательного изучения.

Всю деятельность любой компании можно разделить на следующие ее составляющие:

·  Основная деятельность.

·  Вспомогательная деятельность.

·  Обеспечивающая деятельность.

·  Управленческая деятельность.

1.  Рассмотрим основную деятельность на производственном предприятии.

На производственном предприятии к основной деятельности можно отнести само производство продукции и все, что этому непосредственно относится, а именно:

Новый сервис в пустом репозитории легко назвать greenfield. А если он должен заменить часть работающей системы, перенести данные за десять лет, сохранить старый API и пройти аудит? «Чистое поле» быстро заканчивается - обычно где-то между первой интеграцией и миграцией данных.

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

С распространением AI-ассистентов и coding agents это различие стало ещё заметнее. Они впечатляюще быстро создают приложение с нуля. Но сколько профессиональной разработки действительно начинается с пустого репозитория? Гораздо чаще нужно сначала понять существующую систему, а затем безопасно изменить её поведение.

Хотя многие считают Linux современной операционной системой, она воплощает в себе идеи, которым уже более 50 лет. Рассмотрим некоторые из этих давних концепций и причины, по которым они сохраняются в современных дистрибутивах Linux.

Этим летом наша детская школа искусств выступает с песнями и танцами на шоу в Диснейленде. Мы все предвкушаем поездку, но мою радость слегка омрачил тот факт, что для доступа к расписанию, графику поездки и информации о проживании придётся установить приложение Travelbound.

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

И я нисколько не преувеличиваю. По своей сути, это приложение представляет текст, картинки и ссылки на PDF-файлы, загружаемые из интернета.

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

Рассматриваем курс MS&E 280: Organizations and Structures с Кэтлин Эйзенхардт.

Привет, Хабр! На связи Дмитрий Созонов, эксперт Directum Projects. В своей работе я много коммуницирую с руководителями проектов и разных продуктовых команд, и их боль - когда задачи снова и снова возвращаются к первоисточнику. Вроде бы поручение выдано, команда работает. Но через несколько дней оказывается, что именно РП согласует каждое решение, отвечает на большинство вопросов, контролирует мелкие детали и принимает практически все спорные решения.

Это явление получило название Reverse Delegation Creep - постепенный возврат всей ответственности за проект обратно к менеджеру.

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

Всем привет! Меня зовут Андрей Бровко, я руководитель тестирования Авито Авто. 

ИИ-агенты генерируют код за секунды, но скорость генерации кода не означает качество продукта. Если процессы разработки выстроены слабо, агенты просто быстрее доставляют дефекты.

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

Всем привет! Меня зовут Андрей, я технический директор в компании “КЕДР Солюшенс”. Как коллеги вы, наверняка, разделяете мнение, что не стоит изобретать велосипед там, где можно обойтись стандартными, проверенными временем решениями. Но сегодня я хочу честно поделиться историей одного нашего проекта, в котором этот постулат дал сбой. Я покажу, как стандартная архитектура хранения данных загнала нас в тупик и какие шишки мы набили при попытке все исправить с наскоку.

Привет, Хабр! В ноябре 2016-го дрон GoPro Karma начал падать с неба. У части аппаратов прямо в полёте пропадало питание, и меньше чем через три недели после старта продаж GoPro отозвала все проданные экземпляры, около 2500 штук. Провалился даже не один гаджет — провалилась попытка компании стать чем-то большим, чем автор одной удачной идеи.

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

В игровой индустрии сложилось устойчивое представление, что успех = масштаб. И часто это действительно так — монументальные хиты вроде The Witcher 3 или Red Dead Redemption 2 создаются усилиями тысяч людей и огромных бюджетов.

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

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

Чтобы понять, как это работает на практике, мы поговорили с Иваном Дворяновым, руководителем игрового направления Magnus Tech. В этой статье делимся его экспертизой и выясняем: почему для коммерческого успеха порой достаточно команды из 7–10 человек и как не сломаться под грузом мультизадачности, выбрав этот путь.

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

В современной разработке AI-ассистенты для кодинга создали кризис, о котором никто не говорит. Junior-инженеры работают быстрее, чем когда-либо. Senior-инженеры проектируют архитектуру с меньшими усилиями. А что происходит с вашими middle-инженерами?

Они тихо тонут: большую часть времени вылавливают ошибки AI, которые не попадают ни на один дашборд.

Я называю это проблемой «невидимого валидатора». Опираясь на опыт создания AI-платформ, которые обслуживали более 100 миллионов пользователей на enterprise-масштабе, в этой статье я разберу, как ваши лучшие инженеры субсидируют продуктивность всех остальных… и что сделать, пока они не ушли.