ИИ в масштабе: как управлять внедрением, метриками и трансформацией команды из 500+ разработчиков
За год экспериментов мы выяснили, что традиционное обучение почти не повышает adoption, а количество пользователей ещё ничего не говорит о бизнес-эффекте. Агенты могут написать от 80 до 99% кода, а могут за 12 часов разрушить архитектуру проекта. Мини-команда из двух разработчиков и бизнес-эксперта с помощью ИИ может сделать интеграционный сервис так же быстро, как команда из пяти человек, но Lead Time при этом может остаться прежним.
Как мы внедряли ИИ на 500 инженеров, а скорость не росла. Часть 2. Почему AI-first команды не делают нас быстрее
В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить использование LLM-инструментов в принципе (MAU LLM), потом использование кодинг-агентов (MAU API) и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.Проблема в том, что локальное ускорение быстро упирается в остальной процесс. Один человек или одна роль могут начать делать свою часть быстрее, но задача всё равно ждёт требований, проверки, тестирования, согласований, соседних команд или бизнес-эксперта. Поэтому дальше мы пошли в Agentic Engineering.
Как мы внедряли ИИ на 500 инженеров, а скорость не росла. Часть 1. Рост использования не равен ускорению разработки
ИИ в разработке сейчас внедряют почти все. Кто-то подключает чат, кто-то раздаёт доступ к кодинг-агентам, а кто-то обучает свои модели. На графиках пользователи и активность растут, инженеры пробуют инструменты и привыкают к новой реальности, но при проверке метрик очень часто выясняется, что работать ничего быстрее не стало.
Границы применимости LLM в мобильном UI-дизайне
LLM уже умеют быстро собирать мобильные макеты, и на первый взгляд результат часто выглядит убедительно. Кнопки похожи на кнопки, bottom sheet на bottom sheet, экран не разваливается, и его можно показать на обсуждении. Но на практике это всего лишь аккуратный черновик, который ещё нужно как следует доработать: посмотреть компоненты, состояния, навигацию, safe area, длинные тексты и поведение на маленьком экране.
Свое или чужое: почему и как мы делаем нашу хаос-платформу
Надежность инфраструктуры обычно существует где-то между красивыми SLO на слайдах и суровой реальностью продакшена. В Райффайзен Банке решили перестать верить в планы на бумаге и начали регулярно «ломать» собственные системы — осознанно и по науке. В этой статье руководитель команды разработки организации расскажет, как они пришли к хаос-инжинирингу, почему не смогли использовать готовые инструменты и как за несколько месяцев собрали собственную платформу для проверки отказоустойчивости и уверенности в том, что сервисы действительно выдержат сбои.
AI без Python: как исправить документацию и внедрить RAG в JVM-стеке
Привет, Хабр! Меня зовут Дмитрий Вдовин, я техлид команды Budget Tool. Мы отвечаем за продукт, через который в банке проходят процессы планирования и контроля расходов. Это внутренняя система, в которой формируются бюджеты, согласуются изменения и фиксируются расходы по направлениям. У нас много терминов, правил и нюансов. Например, чем OPEX отличается от CAPEX, зачем нужны кост-центры и группы расходов, что такое аллокация и реаллокация, как заполнять бюджет.
Организационные и технологические трансформации в банке глазами корпоративного архитектора
Корпоративный архитектор — это «демон Максвелла», и его задача — бороться со сложностью ИТ-ландшафта. У нас в Банке это добрый демон, оперирующий подходами Just Enough Enterprise Architecture (JEEA) и Lightweight Architecture Governance (LAG). Именно корпоративные ценности и культура в Банке делают демона добрым. Поверьте мне, ведь я один из них.
