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

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, и это открыло принципиально другой уровень: не отдельные запросы к модели, а полноценные агенты, которые сами читают файлы, вносят изменения, итерируются по результату.

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

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

Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.

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

Я пару лет собирался написать статью про коммерсов в ИТ – феномен интересный, и возник относительно недавно. Но пока я валандался, стало поздно – ребят смывает, и можно только побурчать им вослед. И я бы забыл про эту плановую статью, но интересный эффект с продажей ИИ заставил к ней вернуться.

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

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

В современной разработке компоненты с открытым исходным кодом (Open Source Software, OSS) стали абсолютным стандартом. От небольших библиотек до целых фреймворков вроде Spring или Hibernate — FOSS (Free and Open Source Software) значительно ускоряет разработку и снижает издержки.

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

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