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

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

Как загрузить качественным топливом конвейер разработки? Как измерить эффективность симбиоза человека и машины?

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

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

Хотим выяснить, какие критерии действительно важны при выборе SIEM, что сильнее всего мешает внедрению или переходу и какие доказательства состоятельности продукта нужны до покупки, чтобы принять решение. Не пугайтесь: большинство вопросов — это оценки по шкале от 1 до 10. После опроса мы сравним ответы специалистов из компаний разного размера и с разными задачами и обязательно поделимся результатами в статье.

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

Привет, жители Хабра! Я Ольга Жучкова, один из главных администраторов данных MWS. Я отвечаю за внедрение практик DG в кластере и выступаю амбассадором направления: помогаю продуктовым командам внедрять практики работы с данными и показываю, как эта работа улучшает продукт. В моем кластере работают более тысячи сотрудников. В каждом из этих продуктов, где есть БД, хранятся уникальные или критичные данные. А значит, есть свой администратор данных продукта, с которым я взаимодействую. На примере МТС Premium расскажу, как мы выстроили систему проверок качества распределенных данных — от локальных ошибок в базе до сквозных процессов и бизнес-метрик.

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

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

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

Но вот вы заходите с супер-современные (Pragmata, PUBG, выберите свое), как внезапно выясняется, что там по-прежнему находятся старые добрые конечные автоматы, Behavior Tree (поведенческие деревья), эвристики и тонна ифов, которые говорят NPC, что если игрок достаточно близко, то надо его атаковать, если игрок убежал, то надо немного его поискать, потом покричать, потом …выберите свое…, а если искать его слишком долго, то следует сделать вид, что вообще ничего не заметили и уйти заниматься своими нпсишными делами, мужественно охраняя сундук с лутом от дерзких взглядов местной живности, которая тоже, кстати, на эвристиках.

И это все происходит в современных AAA проектах, где на рендеринг одного кадра работают сотни потоков, физика считается на нескольких уровнях детализации, анимация использует сложнейшие системы смешивания и procedural animation, а навигация строится на огромных графах и разработчики совершенно спокойно используют ML для отдельных частей графического пайплайна, обработки звука или генерации контента. А вот когда дело доходит до вопроса «что сейчас должен делать этот конкретный NPC», внезапно оказывается, что старый switch по состояниям всё ещё является самым лучшим инженерным решением.

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

Меня зовут Игорь Симаков, я тимлид, руковожу двумя командами. Это две классические продуктовые команды, в которых есть все, кто нужен для полного цикла разработки, от discovery до delivery. Сам я бэкенд-разработчик с десятилетним опытом и не пишу код руками с марта 2026 года. Потом я внедрил в командах практики и перевел всех ребят на агентскую разработку: и QA, и бэкенд, и фронтенд. Так что мои команды уже полгода не пишут код руками

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

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

Может, померяем, насколько усердно они бьют по клавиатуре, возьмем количественные показатели из фреймворка DORA… и все равно не поймем, что не так. А как насчёт фреймворка SPACE? Опять чего-то не хватает. Возможно, стоит смотреть и шире, и глубже одновременно. Разработчик же не сферический конь в вакууме: он общается с коллегами, ищет документацию, ждет согласований начальства, и на все это уходят время и силы, которых уже не остается на написание кода. Чтобы учесть скрытые хронофаги и узкие места, DORA и SPACE стоит дополнить метриками DevEx, и тогда, возможно, пазл сложится. Разберем, какие метрики за что отвечают и как ИИ-инструменты меняют измерение DevEx в 2026 году. Подробности под катом.

AI‑агенты позволяют разработчикам закрывать больше задач и быстрее писать код, но изменения всё чаще застревают на ревью и в QA. Растущие MR перегружают процессы проверки, а выигрыш в скорости разработки теряется по пути к production. Разбираемся на данных Faros AI, CircleCI и DORA, почему возникает этот парадокс и как найти узкое место в поставке изменений.

Салют, Хабр!

У GitHub есть GitHub Copilot Code Review, y GitVerse — GigaCode Agent… но мы не можем их использовать, так как это внешние решения, которым не хочется открывать свой код. Когда речь идёт об AI-агентах в разработке, путь большинства крупных компаний — создавать собственный велосипед с нужным количеством колёс и педалей.

Меня зовут Аврора, я занимаюсь инфраструктурой фронтенда в SberDevices. Для упрощения работы мы реализовали систему агентов фронтенда, где скомбинировали два подхода: агентный цикл, где модель получает цель и инструменты, и детерминированный workflow, когда она выполняет отдельные ограниченные задачи. 

Сегодня расскажу о работе наших агентов: об ошибках фронтендеров по статистике AI-ревьюера, парсере для сужения контекста модели и функции системы, которая оказалась (внезапно) самой востребованной.

Гергей Орос (The Pragmatic Engineer) пересказывает свой доклад на конференции LDX3 в Нью-Йорке: что изменилось в индустрии за год, что сломалось, что осталось прежним и куда всё движется. В августе 2026 года на GitHub агенты создали больше PR, чем люди, в Linear агенты заводят больше задач, чем люди, Cursor и Antigravity ушли от IDE, а код-ревью во многих компаниях превратилось в театр. В статье свежие данные GitHub, Linear и Factory AI, истории из OpenAI, Anthropic, Uber и Ramp.

до форума «СИЛА ПЛАТФОРМЫ» осталось 4 дня!

15 октября 2026 года в Москве (кластер «Ломоносов») и в онлайн-формате пройдет масштабный форум о цифровизации, российском инженерном ПО и технологиях искусственного интеллекта в строительстве. Будут представлены десятки кейсов от ведущих проектных организаций страны и прикладные сценарии применения ИИ. Состоится стратегический диалог о будущем инженерного образования — участие в дискуссии примут представители Министерства цифрового развития, связи и массовых коммуникаций, Министерства транспорта, Министерства науки и высшего образования и Комитета Совета Федерации по экономической политике.

В продукте, который называется «ИИ-сметчик», нейросеть пока не посчитала ни рубля.

Компания по ремонту и отделке квартир в Москве дала мне пять рабочих смет. По ним система выдала 310 замечаний (прогоны 16–21.08.2026). Самая дорогая находка — общий итог одной сметы занижен на 515 786 ₽. Это занижение нашлось ещё при обследовании смет перед ТЗ, а правило под него я написал потом, так что здесь заслуга внимательного чтения, а не кода. Код интереснее другим: 51 подтверждённое замечание он выдал сверх эталонного списка ошибок, составленного при том обследовании. В списке их не было.

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

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

В собственном маркетплейсе я однажды обнаружил ошибку в обработчике платежей. Логика выглядела правильной: проверить статус PENDING, перевести операцию в SUCCESS и начислить баланс. Но при одновременной обработке двух webhook’ов оба запроса могли пройти проверку и начислить деньги дважды. Этот код я написал сам, без AI.

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

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

«Мир Квестов» агрегирует квесты в реальности, и клиенты пишут в чат, чтобы подобрать игру и забронировать. С третьего квартала 2026 года первым в чате отвечает бот Квестоша. Рассказываем, как он устроен: вики из markdown-файлов вместо дообучения, маскировка персональных данных до модели, каталог сайта по MCP, ночной цикл правок с экзаменом и сравнение пяти моделей по двенадцати гейтам безопасности. Вторая часть про людей: карта стейкхолдеров, ожидания смежных команд и пять уроков для тимлида.

Есть профессии, ценность которых определяется не только тем, что человек умеет делать, но и тем, насколько редким остается ресурс, которым он управляет.

В IT таким ресурсом много лет была разработка. Хороших инженеров не хватало, бэклог почти всегда был длиннее возможностей команды, а любое заметное изменение продукта стоило времени и денег. Поэтому вместе с хорошей идеей возникал вопрос: хватит ли у разработки людей, времени и бюджета?

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

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

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

Что же изменилось на самом деле?

Самое простое объяснение обычно звучит так: AI теперь пишет код вместо людей.

От этой фразы у разработчиков часто дергается глаз, и это понятно. Сложные системы не стали простыми. Архитектура никуда не делась, legacy тоже, а прод по-прежнему умеет падать ночью.

Меняется другое. Само производство кода ускоряется, а весь путь от идеи до работающего продукта сокращается куда медленнее.

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

Если спросить тимлида «сколько story points команда сделает в следующем спринте?», чаще всего ответ будет такой: «Ну, в прошлый раз было около 300, давай возьмём столько же». Потом выясняется, что двое уходят в отпуск, один новичок ещё не разогнался, а треть времени съедят баги. Спринт заканчивается авралом, задачи доделывают в последние два дня, и этот аврал попадает в статистику как «нормальная скорость команды». Следующий план строится уже на нём.

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

Привет, Хабр! Меня зовут Завур, я фронтенд-разработчик в Selectel.

Сборка, тестирование и развертывание приложения — операции, которые приходится повторять при каждом изменении кодовой базы. С ростом проекта ручная сборка и деплой начинают отнимать время и приводят к ошибкам. Эту рутину убирает практика непрерывной интеграции и доставки (CI/CD).

Если вам нужен независимый сервер автоматизации, который не привязан к конкретной платформе, подойдет Jenkins — open-source инструмент с большой экосистемой плагинов и поддержкой практически любых технологий. Он может собирать проекты из любого Git-репозитория, запускать тесты, собирать Docker-образы и разворачивать приложения.

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