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

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

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

Компания торжественно отчиталась: новой фичей воспользовались десять тысяч раз за месяц. Праздник. Слайд на совете директоров — график вверх и вправо. Продуктовой команде выписали премию. В квартальном письме инвесторам — строчка про «успешное внедрение».

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

Знаете, что произошло с отчётом? Ничего. В отчёте осталось «10 000». Слайд не отозвали, премию не пересчитали, строчку инвесторам не поправили. Цифра уже сделала свою работу — всех порадовала. Зачем её трогать.

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

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

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

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

Созвоны — это почти всегда больно. Особенно когда их много, а пользы мало.

Вы сидите в очередном Телемосте, Толке или Тимсе, смотрите на мозаику из лиц и аватарок и понимаете: время мучительно тратится впустую.

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

В этой статье я разбираю не абстрактный “AI-хайп”, а реальные кейсы: дипфейк-кражу $25 млн у Arup, открытую ClickHouse-базу DeepSeek, отзыв токенов Hugging Face Spaces, фишинг через легитимные AI-workspace invites, сбой Replit-агента и исследования вроде EchoLeak и BioShocking.

Главный вопрос не в том, “может ли модель взломать компанию”, а в том, какие права мы уже выдали AI-инструментам и что произойдёт, если недоверенный контент станет инструкцией для агента.

Меня зовут Татьяна Перминова. В IT я пришла в 2020 году после пяти лет работы менеджером в банковской сфере. Начинала с тестирования 1С, затем перешла в мобильное тестирование, а позже стала руководителем группы тестирования. Сегодня моя команда отвечает за качество приложения «Гри.управление магазином», разработанного внутри компании, которым ежедневно пользуются более восьми тысяч человек.

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

Боков Фёдор, Security Vision

Инвентаризация IT‑активов — это процесс учета всего оборудования, программ, учётных записей и сервисов в компании. Считается технической рутиной, но на практике это основа для работы систем безопасности. Без точного и актуального списка активов невозможно эффективно защищать инфраструктуру, нельзя закрыть уязвимость на сервере, о котором не знаешь, или корректно оценить угрозу для системы, не понимая ее роли в сети.

Эта статья рассматривает, как данные инвентаризации напрямую влияют на работу основных классов продуктов информационной безопасности. В качестве примера мы рассмотрим использование инвентаризации и её преимуществ в продуктах Security Vision SOAR, VM и CMDB. Их функциональность и точность напрямую зависят от качества и скорости наполнения базы активов.

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

Мы в Совкомбанке сами внедряем ИИ в процессы разработки на различных этапах — не везде и всюду, а лишь там, где это имеет смысл. Поэтому мы хотим измерить, насколько глубоко ИИ проник в процессы разработки. А ещё хотим понять, в каких сферах его уже внедрили системно, а в каких ещё есть пространство для развития. Измерять решили через оценку по 7 направлениям техкультуры по шкале от 1 до 10, плюс включили несколько открытых вопросов. Потом поделимся подробными результатами исследования.

Джефф Безос не вывел бы Amazon на вершину рынка, не овладев искусством принятия решений. В письме акционерам в 2015 году он предложил разделять решения, с которыми регулярно сталкиваются предприниматели и руководители, на два типа.

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

Кейс CTO AlpinaGPT Сергея Андриянова: как из боли с код-ревью в аутсорс-команде вырос продукт Evolver, и почему мы сознательно отказались от автономных агентов в проде.

В конце мая мы собирали внутреннюю мастер-встречу по AI-трансформации, и один из докладов оказался настолько содержательным, что я не могу удержаться и не пересказать его. Выступал Сергей Андриянов — наш CTO в AlpinaGPT и одновременно основатель аутсорс-компании WebRegul, которой уже больше пятнадцати лет. Сергей рассказал, как они с командой автоматизировали код-ревью через мультиагентную систему: время ожидания упало с двух суток до нескольких часов, на рутинных мердж-реквестах — до пятнадцати минут, и они освободили примерно сто часов работы команды в месяц.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT, Head of AI Alpina Digital и автор тг-канала «Готовим ИИшницу».

Эта статья будет полезна для CTO, тимлидов и продактов, которые думают о том, чтобы внедрить ИИ в работу команды разработки. По ходу — собственные комментарии как Head of AI: где этот опыт ложится в общую картину рынка, а где это редкая практика, на которую стоит обратить внимание.

С чего всё началось: рост команды в три раза и ревью на двое суток

Контекст у Сергея был типичный для растущей аутсорс-разработки. По его словам: «Два года назад мы в компании столкнулись с довольно-таки быстрым ростом. Разработчиков стало много, выросли буквально в три раза за один год, и процессы очень сильно поменялись. И после этого код-ревью из полезной практики местами начал превращаться в ад».

Меня зовут Вероника. Я технический проджект-менеджер в финтехе и мама троих детей: студентки, школьницы и детсадовца. Когда люди узнают оба этих факта, обычно задают два вопроса: “Как ты всё успеваешь?” и “Ты вообще спишь?”

На оба вопроса у меня один ответ — все дело в процессах, детка.

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

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

Привет, Хабр! В 2022 году я пришёл в Ozon Tech на позицию специалиста технической поддержки склада и начал разбираться, как настраивать и поддерживать оборудование на ФФ (фулфилмент), огромном складе площадью 70 000 м², где проходят операции от приёмки и хранения товаров до их подготовки к отправке на сортировочные центры. В тот момент всё работало стабильно. На складах использовались терминалы Zebra (ТСД — терминал сбора данных), вендор был на рынке, поддержка оставалась доступной, и никто особенно не задумывался, как всё устроено внутри. 

После изменения условий работы с вендором нам пришлось глубже разобраться в процессе настройки и поддержки устройств, чтобы сохранить стабильную работу терминалов на объектах. Оказалось, что поддерживать работу десятков тысяч терминалов по всей стране стало задачей с множеством неизвестных. Притом именно через них проходит большая часть складских операций, от приёмки и размещения товара до сборки и отгрузки заказов. Впереди нас ждали несколько лет разборов, ошибок, временных решений и постепенной перестройки всей системы. В какой-то момент казалось, что мы зашли в тупик. Но в итоге справились. Сейчас мы сократили время настройки терминала с 30 до 6 минут, управляем тысячами устройств удалённо и имеем единый лаунчер. В этой статье расскажу, как мы заново выстроили процесс настройки и управления терминалами на складах. Поехали!

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

Самое удобное объяснение звучит так: значит, набрали слабых инженеров. Я хочу показать, что это объяснение неверное, и что за последние два года накопилось достаточно данных, чтобы говорить не про чьи-то личные провалы, а про свойство самой системы.

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

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

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

Итог двух недель: 178 релизов, 1.4 млрд токенов, 0 строк кода, прочитанных человеком перед мержем. И неожиданный вывод — я не перестал быть программистом, а стал кем-то вроде бухгалтера, который отложил счёты и осваивает Excel.

Я поставил череду экспериментов: по очереди убирал куски «обвязки» вокруг модели и смотрел, что сломается. Один эксперимент чуть не похоронил репозиторий за одну задачу: +25 зависимостей и +6000 строк на ровном месте. Рассказываю, что выяснилось.

Всем привет!

Меня зовут Дмитрий Бутенко, я эксперт-разработчик банка Уралсиб.

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

О том, какими были эти вопросы и задачи, и о том, что из этого вышло — речь пойдёт ниже.