10892
Рекомендации интересных книг, статей и выступлений от Александра Поломодова (@apolomodov), технического директора в T Tech
[1/2] AI, DevOps, and Kubernetes: Kelsey Hightower on What's Next (Рубрика #PlatformEngineering)
Посмотрел интервью Келси Хайтауэра с командой JetBrains про состояние индустрии в 2025 году. Помню как лет 7 назад изучал Kubernetes по его репозиторию Kubernetes The Hard Way, который был не прост, но помог мне сдать лабы для получения шилдика CKA (Certified Kubernetes Administrator) первым в компании. Это было в те времена, когда мы с моим коллегой Стасом (гостем из первого выпуска подкаста Code of Leadership), Андреем (гостем 43 выпуска Code ...) и Антоном (гостем 17 выпуска Code ..) продумывали как будем переезжать в Kubernetes с виртуалок:)
Но если возвращаться к Келси, то он уже завершил активную карьеру в Google и теперь может философски размышлять про devops и не только. Я выделил 5 тем, что были интересны мне в этом обсуждении
1️⃣ DevOps: Эволюция или провал?
Келси критически оценивает то, во что превратился DevOps во многих компаниях.
- "Футболка вместо навыков": Многие компании просто переименовали системных администраторов в DevOps-инженеров, не изменив суть работы. "О, теперь я DevOps-инженер, дадут ли мне за это футболку?" — иронизирует Келси.
- Правильная имплементация: DevOps был задуман как "чертеж" (blueprint), предполагающий расширение компетенций. Сисадмины должны были научиться программировать, а разработчики - понимать, как работает операционная система (например, тюнить JVM под ядро Linux).
- Проблема опыта: Келси упоминает людей, у которых "20 лет опыта, состоящих из одного и того же года, повторенного 20 раз" (20 years of one-year experience). Это те, кто просто чинит серверы, не пытаясь автоматизировать или изменить подход.
- Platform Engineering: Это не что-то принципиально новое, а эволюция DevOps. Это переход от "я починю сервер, когда он сломается" к созданию продукта (платформы) для внутренних клиентов.
2️⃣ Kubernetes и «скучные» технологии
- Kubernetes - это скучно (и это хорошо): Для stateless (веб) приложений Kubernetes стал скучным еще 6-7 лет назад. Келси сравнивает инфраструктуру с полетом на самолете: "Самолеты интересны только тогда, когда они делают не то, что мы ожидаем. Если при посадке люди хлопают - значит, что-то пошло не так. Мы хотим просто выйти из самолета и не думать о полете".
- Инфраструктура не должна вызывать восторг: Если ваша инфраструктура вызывает у вас сильные эмоции, значит, вы боретесь с поломками или трением. Восторг должен вызывать продукт, который вы строите поверх неё.
- Будущее Kubernetes: Если через 20–30 лет мы всё еще будем обсуждать Kubernetes, это будет провалом индустрии. Мы должны придумать что-то лучшее. Kubernetes должен стать просто деталью реализации (как BIOS или машинный код), скрытой под более удобными абстракциями.
3️⃣ API, Silos (Колодцы) и взаимодействие команд
Келси делает контринтуитивное заявление: "Мне нравятся silos (изолированные команды)", но при наличии четкого API.
- Аналогия с авиабилетом: Когда вы летите в другую страну, вы не идете в кабину пилота обсуждать маршрут. Вы покупаете билет. Билет - это API (контракт). Вы садитесь в кресло, засыпаете и просыпаетесь в другом месте.
- API как контракт: Платформенная команда и разработчики не должны сидеть рядом и постоянно разговаривать. Они должны взаимодействовать через четкий контракт (API): "Мне нужно столько-то памяти, такой-то регион, такая-то версия".
- Когда нужно общение: Разговаривать нужно только тогда, когда вы хотите изменить API или добавить новую фичу в платформу. Для рутинного деплоя общение - это лишние накладные расходы.
Забавно, что примерно эти же моменты про взаимодествие команд мы разбирали со Стасом Халупом в первом выпуске Code of Leadership.
Оставшиеся темы про AI и важность soft skills обсудим в продолжении разбора этого крутого интервью.
#Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes
Netflix's Engineering Culture (Рубрика #Engineering)
Посмотрел подкаст про инженерную культуру Netflix, где Элизабет Стоун, технический директор компании, делилась своими мыслями (в Netflix 3.5к инженеров и это 25% сотрудников компании). Последние информацию про культуру Netflix я получал из интересной книги "No Rules Rules. Netflix and the Culture of Reinvention", но с тех пор утекло много времени и мне было интересно, а что изменилось с тех времен.
Главный принцип - свобода и ответственность остался все тем же: инженерам доверяют самостоятельное принятие решений без бюрократии, а взамен - полная ответственность за результат. Такая модель невозможна без сильной команды: Netflix стремится нанимать только лучших специалистов и ожидает выдающихся результатов от каждого. Благодаря этому решения принимаются на том уровне иерархии, где достаточно знаний и компетенций (уровне людей и их команд). Ошибки рассматриваются как возможность роста, а не причина для блейма. Проблемы обсуждаются открыто и это укрепляет систему и снижает риск повторения сбоев. В Netflix культивируется культура откровенности: ожидается прямота от каждого, а руководство демонстрирует максимальную прозрачность. Такая открытость формирует атмосферу доверия.
Если перечислять основные инженерные принципы, о которых упоминала Элизабет, то они такие
- Непрерывная обратная связь вместо performance review. Netflix отказался от ежегодных формальных оценок сотрудников. Вместо этого поощряется постоянный честный фидбэк и открытый диалог. Ежегодный опрос 360° служит лишь подстраховкой, выявляя проблемы, не всплывшие в ежедневном общении. Такой подход позволяет сразу корректировать курс, не дожидаясь формальных полугодовых аттестаций.
- Keeper Test. Руководители задают себе вопрос вида, "а стал бы я бороться, чтобы удержать этого сотрудника, если он решит уйти?". Если ответ "нет" - пора откровенно обсудить с подчиненным ситуацию. Это помогает держать высокую планку и вовремя расставаться с теми, кто не соответствует культуре.
- Автономия инженеров. Инженерам Netflix предоставлена широкая свобода действий: они самостоятельно принимают технические решения без многоуровневого согласования. Это ускоряет работу и повышает личную ответственность за результат. Даже в рискованных проектах (например, прямые эфиры) команды действуют автономно, полагаясь лишь на минимальные guardrails для снижения рисков.
- Обучение на ошибках. Каждая неудача - повод для анализа и улучшения. Ребята практикуют подход с blameless postmortems, плюс они были пионерами chaos engineering, создав инструмент Chaos Monkey
- Высокая планка найма. Netflix традиционно привлекает только опытных, сильных инженеров, предлагая им конкурентную оплату труда. От каждого нового сотрудника ждут, что он усилит команду и привнесет свежие идеи. Но Netflix отказалась от практики найма только senior и начала брать выпускников, что привело к появлению отдельных должностей для инженеров разного уровня (что сильно отличается от прошлого подхода компании). Но даже при таком найме они стараются практиковать практику, что каждый новичок должен поднимать планку, а не просто заполнять вакансию.
Если обобщать все выступлении, то в Netflix сильная инженерная культура, что строится на доверии, высоких стандартах и готовности учиться на ошибках. Не каждая команда может полностью отказаться от формальных процессов, но ключевые принципы - честный и быстрый фидбэк, автономия талантливых сотрудников, прозрачность лидеров и непримиримость к посредственности - универсальны.
#Culture #Management #Leadership #Processes #Engineering #Software
Как продакты, аналитики и дизайнеры создают ценность через мышление (Рубрика #ProductManagement)
Интересное выступление Кирилла Николаева, моего коллеги, директор по аналитике в Т-Банке. Кирилл разбирает, что на самом деле стоит за jobs to be done (JTBD) и почему не всегда цель продукта - "снять трение": иногда продукт должен намеренно заставлять пользователя подумать, если это повышает качество решения и снижает риски.
Если выделять ключевые идеи, то в разрезе ролей они выглядят так
- Product manager задает рамку смысла: он формулирует «работу» (JTBD) и желаемое изменение поведения, а не список фич. Цель - ценность, а не “проще любой ценой”.
- Аналитик переводит гипотезу в проверяемые критерии, выбирает метрики качества решения (не только CTR): ошибки, возвраты, LTV‑эффекты, время принятия решения.
- Дизайнер (когнитивный интерфейс): проектирует правильное трение - подсказки, подтверждения, микро‑обучение - там, где «подумать» критично (финансы, безопасность, ответственность).
Почему не всегда надо упрощать - упрощая без разбора, легко ускорить неверные решения. Добавленное «осмысленное усилие» иногда повышает доверие, снижает ошибки и улучшает долгосрочные метрики.
Что это значит для инженеров/техлидов:
- Инфраструктура экспериментов: feature‑flags, канареечные релизы, дешёвая постановка A/B системы, единая схема событий.
- Телеметрия качества решения: события «я понял/подтвердил риски», отмены, возвраты, ошибочные действия, dwell/time‑to‑decide.
- Доступ к объяснимости: журнал «критических точек мышления» (какие подсказки/правила сработали) для дебага и аудита.
- Ритуалы: единый JTBD‑бриф на 1 страницу; общий план экспериментов; еженедельный «decision review» по качественным и количественным сигналам.
Антипаттерны:
- "Оптимизация на клики": растит метрики, но ухудшает решения.
- "Простота ради простоты": убивает безопасность/ответственность там, где пользователю нужно разобраться.
- Feature-driven без JTBD: лечим симптомы, а не работу пользователя.
В итоге, ценность возникает на стыке мышления пользователя и инженерной дисциплины принятия решений. JTBD задаёт смысл, аналитика - критерии качества, дизайн - нужную когнитивную нагрузку, а инженерия - инструменты измерения и быстрых проверок.
#Software #Metrics #ProductManagement #Software #Design
[1/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career)
Недавно прочитал книгу Билла Бернетта и Дэйва Эванса из Стэнфорда, что создали курс Designing Your Life. В своей книге авторы переносят принципы дизайн-мышления в область карьеры, где ключевой идеей становится тезис, что работу мечты не «находят» - её проектируют. А значит если вам что-то не нравится в текущей работе, то не обязательно увольняться - часто достаточно сделать рефрейминг и задизайнить роль по другому:)
TL;DR для инженеров выглядит примерно так
- Думайте как дизайнер и используйте цикл: понять → сгенерировать варианты → прототипировать → внедрять.
- Bias to action: меньше «обсждайте» и проводите больше небольших экспериментов.
- Reframing: формулируйте минимально осуществимую проблему вместо общих «всё плохо».
- Good enough for now: перестаньте ждать идеала, улучшайте 1–2 вещи уже сейчас.
- Различайте гравитационные проблемы и реальные задачи. Первые нельзя изменить (так устроен мир) - надо это принять и обойти, а вот вторые можно решить по настоящему.
- Счастье на работе = баланс A‑R‑C: autonomy (автономия), relatedness (связи), competence (компетентность)
Авторы предлагают заменить решение "я увольняюсь" на 4 стратегии
- Re‑enlist - переосмыслить «зачем» в текущей роли (обновить цели/метрики/обратную связь).
- Remodel - перестроить обязанности: убрать «песок», добавить «энерго‑фичи», взять мини‑проект.
- Relocate - сменить команду/продукт внутри компании.
- Reinvent - сменить трек в той же организации (например, из Backend → Platform/SRE/ML).
Как этот подход авторов связан с привычными нам в IT вещами
- Это похоже на рефакторинг легаси систем: сначала маленькие безопасные шаги, затем - архитектурные изменения.
- Прототи работы похож на небольшой a/b тест за фичефлагом.
- Пользовательские интервью напоминают предложенные авторами разговоры с людьми из целевых команд/ролей (инфо‑интервью)
- Backlog продукта напоминает список гипотез, которые повышают вашу ценность и удовлетворённость.
В продолжении я рассказываю как все эти советы могут выглядеть в реальности и укладываться в месяц.
#Career #Software #Design
Жемчужины программирования (Рубрика #Engineering)
Первое издание этой книги Джона Бентли вышло почти 40 лет назад, как раз в год моего рождения. Но я читал уже второе издание, что вышло в начале 2000х годов. Это была книга, которая отличалась от других - она учила думать как инженер, а не просто писать код. Автор книги - исследователь из Bell Labs и Carnegie Mellon, соавтор алгоритма k-d деревьев и усовершенствованного quicksort. Но известен он больше колонкой в журнале "Communications of the ACM", из которой выросла эта книга. Это было в 1980-х годах, эпохе, когда 1 МБ памяти считался роскошью. Бентли писал для практиков, которые хотели не просто “работающий код”, а *красивое решение*. Он сравнивал алгоритм с жемчужиной: реальная проблема - это песчинка раздражения, а изящное решение - результат терпения и формы.
Каждая глава - это короткое эссе с задачей, размышлением и выводом. Они покрывают следующие темы
- Как формулировать задачу и искать ага!-решение;
- Оценка на салфетке, где автор рассказывает про оценку времени и памяти алгоритмов буквально на пальцах;
- Алгоритмические трюки: сортировка, выборка, поиск, оптимизация;
- Как писать корректные и понятные программы.
Интересно, что Бентли написал еще и книгу продолжение "More Programming Pearls", где он добавил следующие темы
- Философия инженерного мышления (“исповеди кодера”);
- Маленькие языки - предтечи DSL и скриптов внутри систем;
- Афоризмы и практические советы вроде “плохую программу ухудшить не грех”.
Если говорить про значимость книги в далекие времена, то автор в ней показал, что программирование - это не набор трюков, а искусство видеть структуру задачи. Когда-то книгу использовали в курсах по алгоритмам и дизайну программ. Сейчас большинство примеров устарело, но подход - нет.
В итоге, книги Джона Бентли по праву считаются сокровищницей знаний для программистов. Они объединяют поколение инженеров 1980-х и современных разработчиков общими ценностями - страстью к изящным решениям и глубокому пониманию задач. «Жемчужины программирования» до сих пор сияют и продолжают вдохновлять новых читателей на поиск красоты в коде.
#Engineering #Software #Architecture #SystemDesign
Водоходъ (Рубрика #ForKids)
Решили прокатиться на кораблике в Нижнем Новгороде. Пришли вчера в кассы компании "Водоходъ" купить билеты, но их на вчера уже не было. Мы решил попробовать покататься сегодня и купили комфорт билеты на сайте Водоходъ. Пришли на посадку, но нам объяснили, что даже с билетами мы не покатаемся на кораблике. На сайте было указано, что для детей до 5 лет включительно билет нужен, но он бесплатный. Опции получить этот бесплатный билет на сайте не было и мы решили получить его в кассах. А в кассах нам сказали, что этот бесплатный билет для детей есть только в тарифе билетов стандарт, а в комфорт надо покупать билеты на всех (но на сайте этой инфы не было). Докупить билет мы не смогли - мест в комфорт не было. Сдать билеты на комфорт нормально тоже не получилось - в кассе сказали "где билет покупали, туда и идите", а на сайте Водохода предлагают заполнять документ и ножками приносить его в офис компании (или присылать письмом Почтой России). Классно, что у нас в Т-Банке есть возможность оспорить любую операцию, по которой не предоставили услугу.
Вывод: оплачивайте картами Т, чтобы иметь возможность оспорить оплату у таких "водоходов".
Дискуссия — «GenAI и dev платформы – как меняется разработка» (Рубрика #AI)
На летнем IT Пикнике мой коллега Дима Гаевский вел дискуссию на эту тему, где участвовали уважаемые джентельмены
- Иван Пузыревский, CTO Yandex Cloud
- Александр Лукьянченко, руководитель разработки платформы в Авито
- Станислав Сычев, руководитель разработки платформы в Т-Банке
Ребята обсуждали следующие темы
1. Роль разработчика меняется
ИИ перестал быть только частью IDE. AI пишет код, предлагает оптимизации, генерирует тесты - а инженер становится ревьюером и архитектором решений, а не только исполнителем. Сильные инженеры теперь курируют и людей, и AI-агентов. Джуны растут быстрее - у них под рукой “AI-ассистент”, который подсказывает, как писать код.
Главный навык будущего - уметь ставить задачи ИИ и проверять результат, а не просто знать синтаксис языка.
2. AI становится частью платформ разработки
- Платформы (CI/CD, IDE, облака) интегрируют AI-помощников, которые анализируют код, собирают метрики, предлагают фиксы.
- AI-модели дообучаются на данных из внутренних репозиториев, понимают корпоративный стиль кода и стандарты.
Как итог: внутренние dev-платформы становятся “живыми системами”, где ИИ не только помогает людям, но и сам учится на их паттернах.
3. Автономность AI пока не так велика
- Ни один из участников не верит в «AI-разработчика без человека».
- Сейчас граница ясна: AI можно доверить рутину (генерацию шаблонов, тестов, фиксов), но не архитектуру и продакшен-код.
- Везде действует правило: «AI предлагает, инженер утверждает» (условно, есть human in the loop). Это связано со стоимостью ошибок
4. Новые роли и процессы
- Появляются новые профессии: AI-инженеры, промпт-дизайнеры, ревьюеры моделей.
- Некоторые частично детерминированные сценарии работают лучше: генерация тест-кейсов, юнит-тестов, агенты для код-ревью, миграции кода
- DevEx-платформы превращаются в экосистемы для людей и агентов: оба учатся на общих данных и повышают эффективность.
5. Что дальше
- AI-first-платформы станут стандартом: без встроенного помощника IDE или CI/CD скоро не обойтись.
- Команды станут меньше и междисциплинарнее - рутину берут машины, людям остаются дизайн, логика и ответственность за свою работу и работу AI-агентов
- AI-грамотность станет новой базовой компетенцией инженера.
- Появятся агентные среды, где несколько AI-сервисов будут решать задачу “от ТЗ до деплоя” под присмотром тимлида-человека.
Если подводить итоги, то ребята
- Не верят, что AI не заменит инженеров - скорее инженеры станут тимлидами команды AI-агентов
- Платформы разработки становятся умнее, интегрируя AI-возможности в себя
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
Сезон кода: Нижний Новгород (Рубрика #Engineering)
Сегодня вечером я уезжаю в Нижний Новгород, где планирую завтра потусить в офисе и пообщаться с коллегами, включая сессию вопросов и ответов, а в субботу загляну на наше мероприятие "Сезон кода", где будет плотная программа про надежность, масштабируемость и полезные инженерные практики. Так что если вы будете на этом событии, то можно будет попробовать найти меня. Правда, я еду в Нижний с семьей: женой и двумя младшими детьми, а значит в планах у меня не только сезон кода, куда я загляну всей семьей, но и более широкомасшабные прогулки по городу, в котором детишки еще не бывали.
#Engineering #Travel #ForKids
[1/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI)
Недавно я был на презентации результатов исследования от IT One и Сколково, где участвовал в панельной дискуссии. Потом я взял это исследование и изучил все 59 страниц, в которых примерно следующая структура
1) Мировая практика: существующая и предстоящая трансформация SDLC под влиянием ИИ - здесь авторы провели мета-исследование, проанализировав отчеты других уважаемых ребят (приведу ссылки ниже при описании результатов)
2) AI в SDLC в России: ландшафт рынка, сервисы, практики и ожидания по развитию - здесь авторы проанализировали публичные сервисы, доступные на рынке Росии + проанализировали крупные анонсы от игроков, даже если сами решения еще не доступны для широкого круга пользователей
3) Взгляд технологических лидеров на AI в SDLC: результаты интервью СТО / CIO и руководителей по разработке крупных компаний - здесь авторы взяли интервью с 50+ уважаемых людей в индустрии (списка этих людей я в отчете не нашел, но поверим на слово)
4) Прогнозы, выводы и рекомендации о возможностях и рисках, с которыми связано использованием AI в SDLC - мнение авторов о том, как дальше будет развиваться AI и как его интегрировать в разработку
Начнем в этом посте с общемировой практики
- Рынку AI-инструментов для разработки : $6,9 млрд → $29,6 млрд к 2032 (х4). Наибольший эффект на этапах разработки и тестирования. Источник Spherical Insights
- 62% разработчиков уже используют ИИ; ещё 13,8% — в планах (по данным 2024 года). Менеджеры оценивают проникновение ниже, но тренд ускоряется. Источник StackOverflow 2024 (я разбирал этот отчет 2024 года, а также разбирал и новый отчет 2025 года)
- Ценность смещается от личной эффективности (быстрее пишет код) к командной: сейчас +10% к скорости кодинга, в горизонте нескольких лет +25–30% к продуктивности команд при работе "ИИ-на-уровне-команд" (чтобы это ни значило). Источник Mia Platform
- Ускорение SDLC: уже 15–20% сейчас (источник: Forrester), потенциал 30–50% на среднесрочном горизонте (источник: rama.sathish/ai-powered-software-development-life-cycle-1ac599ad38bb">medium статья от Сатиш Рама, Director Gen AI @ Paypal)
- Горизонт трансформации процессов - 1–3 года; у 32% техлидеров фактический эффект уже превзошёл ожидания (Источник: MIT, но конкретной ссылки на статью нет)
Отдельно авторы упоминают про исследование METR, где на сложных задачах/репозиториях ИИ может замедлять работу опытных инженеров. Подробный разбор есть в моих постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс.
Интересно, что авторы исследования нашли модель зрелости от министерства DEFRA правительства Великобритании "The AI-Powered SDLC: A Comprehensive Technical and Cultural Maturity Assessment Framework". Я сначала не понял как ведомство, отвечающее за охрану окружающей среды, продовльственную политику и развитие сельских регионов связано с цифровизацией, но потом изучил вопрос и понял:) С середины 2010-х DEFRA стало одним из лидеров цифровой трансформации в британском госсекторе, во многом благодаря активному сотрудничеству с Government Digital Service (GDS) и Central Digital and Data Office (CDDO). У DEFRA тысячи источников данных (от спутников до фермерских отчетов) и огромное разнообразие пользователей. Поэтому именно здесь британское правительство активно тестирует свои AI/ML темы и агентские системы.
Если же говорить про риски AI, которые отмечают западные отчеты, то они такие
- Утечки кода/данных и проблемы с соблюдение требований комплаенса;
- Деградация компетенций инженеров и «слепое» доверие подсказкам;
- Рост техдолга и vendor lock‑in на провайдеров
В итоге, видно, что тема AI-фикации процессов разработки софта сейчас горяча как никогда. На Западе только ленивый не публикует свои отчеты/прогнозы/продукты/... и по большей части они сейчас в положительной тональности. Но многие отмечают, что скачок эффективности будет при переходе от личных копилотов к интеграции в процессы компаний. Дальше поговорим про Россию.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
У наших аналитиков в Т есть подкаст InSAйт, куда они зовут гостей обсуждать интересные темы. Второй сезон заканчивался темой "У системных аналитиков нет комьюнити: миф или реальность", куда ребята позвали гостем Анастасию Кабищеву, Head of project management office компании Ekleft, консультанта по психологической безопасности команд, а также мою жену. В итоге, я не мог ни рассказать об этом подкасте - рекомендую его к прослушиванию всем, кто занимался темой построения коммьюнити.
Читать полностью…
Эволюция метрик и практика применения SPACE (Рубрика #DevEx)
Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (который отдувался за двоих) и я решил поделится кратким саммари этого рассказа.
Если уложить это саммари в одну мысль, то она примерно такая "инженеров нельзя адекватно оценить одной цифрой или простым количественным показателем" - хотя часто это пытались сделать (например, число коммитов, строк кода, выполненных задач), но каждая такая метрика отражает лишь одну сторону дела и сильно зависит от контекста. Например, большое число изменений в коде может свидетельствовать как о высоком темпе команды, так и о переработках или неэффективном процессе – без контекста такие цифры вводят в заблуждение. Ребята привели в докладе кучу примеров того, как приходится учитывать множество граней эффективности: скорость работы, качество результата, командное взаимодействие, удовлетворённость сотрудников и другие факторы.
Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как
- Satisfaction & Well being (удовлетворённость)
- Performance (результативность)
- Activity (активность)
- Communication & Collaboration (коммуникация)
- Efficiency (эффективность)
Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной.
Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств.
Круто, что ребята честно поделились ошибками первого подхода к SPACE. Поначалу они старались измерить «всё и сразу» и получить мгновенный интегральный показатель. Это привело к избытку данных и трудностям в их понимании. Как итог - не стоит пытаться охватить сразу все метрики без приоритизации. Вместо этого лучше выбрать несколько метрик по ключевым измерениям, которые наиболее актуальны для текущих проблем команды, и начать с них. Важно «не перегнуть палку и не утонуть в данных», а подбирать метрики под свой контекст. Постепенно, когда культура работы с метриками начала формироваться, они расширяли охват SPACE-факторов, но уже осознанно и с учётом полученных инсайтов.
Из выступления можно забрать такие мысли
1) Комбинируйте объективные метрики с обратной связью от людей
2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию
3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле
4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению
#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE
[2/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)
Продолжая рассказ о своем докладе, поделюсь своими мыслями о том, как подходить к AI-фикации разработки, которые основаны на whitepaper Measuring Developer Goals. В этой статье авторы рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Для ответа на вопросы о продуктивности удобнее привязывать измерения не к конкретным инструментам, а к тем целям, которые разработчики ставят перед собой при использовании инструментов. Это позволяет отвечать на вопросы, похожие на те, что приведены выше, сохраняя метрики ориентированными на пользователя, а не инструмент. Подробный разбор в блоге, а также есть восьмая серия подкаста Research Insights Made Simple, где мы разбирали эту статью с Сашей Кусургашевым, моим коллегой, что руководит разработкой Spirit (наша внутренняя платформа разработки). Вообще, может быть полезна вся серия статей про "Developer Productivity for Humans", которуя я разбирал в двух постах (1 и 2).
Если привязывать эти идеи к внедрению AI в разработку, то ясно, что надо фокусироваться на главных jobs to be done сценариях, которые массовые/проблемные - помогая с ними можно получить максимальный эффект. Причем начинать стоит с AI-assisted вещей, а по мере улучшения ассистирования двигаться в сторону делегирования всего сценария агенту (правда, тут придется поработать с подготовкой контекста, настройкой evaluation, изменениями в процессах работы людей). И по мере изменений надо уметь измерять эффекты от этих улучшений так, чтобы показывать результаты топ-менеджерам (а они любят цифры).
Про измерения продуктивности (как и зачем) я уже рассказывал раньше, но там были классические DORA, SPACE, DevEx. А в последнее время я пристально наблюдаю за платформой для измерения продуктивности DX, которая была основана теми, кто развивал предыдущие подходы. Эти ребята сделали систему с опросами и интеграцией с системами типа Jira, Wiki, git, CI/CD, ... В общем, ребята придумали свой фреймворк DX Core 4 для измерения инженерной продуктивности (см мой текстовый разбор + разбор в моем подкасте с Женей Сергеевым из Flo), а в этом году они же расширили его веткой для измерения эффективности AI ассистентов и агентов (см мой текстовый разбор + разбор в моем подкасте с Женей).
По-факту, эффективность AI ассистентов и агентов можно измерять с точки зрения трех направлений
1) Utilization - отслеживание внедрения и использования AI-инструментов (DAU, MAU, % сгенерированного кода, % PR с AI ассистированием, ...). Обычно с этого начинаются измерения, так как эти показатели измерить проще, чем те, что в следующих пунктах (Impact, Cost)
2) Impact - измерение реального эффекта на производительность (экономия времени разработчиков, PR throughput, percieved rate of delivery, ...)
3) Cost - отслеживание затрат и чистой прибыли
У ребят из DX есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы.
Если говорить про наш подход в Т-Банке, то мы умеем мерить первый уровень Utilization, а также у нас внедрен фреймворк SPACE для оценки developer productivity. Это позволдяет нам двигаться в сторону оценки Impact. Кстати, про наш фреймворк SPACE ребята рассказывали на IT Пикнике и я позже сделаю разбор этого выступления. Но если у вас не внедрены инструменты для измерения developer productivity в компании, то не стоит грустить. Уровень утилизации можно измерить относительно просто, а большего вам может быть и не надо - сейчас разработка революционно меняется за счет использования AI-ассистентов и AI-агентов, а значит можно не вкладывать кучу сил в измерения старого подхода к делу, а экспериментировать с новым. Условно, не стоит обмерять деревянное колесо диллижанса, если у нас уже его вытесняет металлическое колесо машины:)
Ну а если хочется бенчмарков, то можно поучаствовать в нашем Большом исследовании AI в инженерной культуре России.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
[1/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)
Сегодня с таким докладом я выступал на конференции AI Boost от Surf. В этом посте я тезисно расскажу о самой сути выступления, а также поделюсь всеми материалами для дополнительного изучения. И начать нужно с того, что это выступление продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании", которое задавало рамку и неплохо показывало как и куда стоить идти при внедрении AI. Но в этот раз я сделал фокус на агентах. И начал я с того, что вспомнил про GitHub Copilot и Cursor, которые скорее известны как ассистенты инженеров. И принятие этих инструментов уже произошло, но потом появились Claude Code и OpenAI Codex, которые заявили о себе как об агентских системах для инженеров (сам я экспериментировал с OpenAI Codex и мне понравилось). И кажется, что это gamechanger, так как если агентские системы заработают успешно, то им можно будет делегировать часть jobs to be done сценариев, которые раньше делали люди (пока эти системы зачастую работают не достаточно хорошо). Для улучшения работы этих систем Anthropic и Google придумали соотственственно протоколы MCP и A2A, про которые я уже рассказывал, то есть инфраструктура постепенно собирается.
Есть и экономическое предпосылки перехода к агентами
- Инвестиции в AI: с 2023 года в инструменты ИИ-программирования вложены миллиарды долларов, а компании ожидают отдачи
- Давление на эффективность: Компании ищут пути ускорить разработку и снизить издержки
- Провайдеры AI технологий обещают манну небесную: топ-менеджеры в компаниях-потребителях ждут отдачи инвестиций
И даже есть компании, где такие системы выдают топ-левел результаты - это я про Google с их агентской системой AlphaEvolve (см. мой разбор), где были получены ощутимые результаты
- Повышение эффективности дата-центров: AlphaEvolve разработал эвристику для оркестратора Borg, которая непрерывно восстанавливает в среднем 0,7% мировых вычислительных ресурсов Google.
- Оптимизация чипов: система предложила переписать код Verilog для удаления избыточных битов в арифметической схеме умножения матриц, что было интегрировано в новую версию TPU.
- Ускорение обучения LLM моделей: AlphaEvolve ускорил ключевой компонент архитектуры Gemini на 23%, что привело к сокращению времени обучения Gemini на 1%
На фоне этого уважаемые ученые рассматривают вопросы будущего, например
- "Future of Work with AI Agents" от Stanford, где ребята задались вопросом а что можно уже агентизировать, а также что люди хотят передать машинам, а также как поменяется рынок труда в результате (см мой разбор)
- "Virtual Agent Economies" от Google, где ребята размышляли про экономику, где агенты могут выполнять и координировать работу автономно. Ученых интересовала как это повлияет на нашу привычную экономику и как сделать так, чтобы мы могли управлять этими изменениями (см мой разбор)
- "Towards AI-Native Software Engineering (SE 3.0)", где авторы размышляют про изменение индустрии разработки до третьей версии, где первой было стандартное написание кода, второй - написание кода с ассистентами, а третье - это уже агенты во всей красе с intent-first разработкой. Разбор этой статьи у меня на подходе, но пока вы можете почитать оригинал
Как может выглядеть агентский режим в реальности (у нас в Т-Банке) стоит посмотреть на демках, которые есть и в моем докладе и в уже опубликованном докладе Стаса Моисеева, моего коллеги, который рассказывал об этом и не только на Big Tech Night (см мой разбор). Но для получения эффекта от AI просто агентского режима не хватит - надо работать фокусно по jobs to be done сценариям, что выполняют инженеры в рамках своей работы. Подробнее про это, а также про измерение эффекта будет в продолжении.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
[3/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)
Продолжая рассказ (1 и 2) про панельную дискуссию поделюсь оставшимися темами и начну с рисков.
3. Возможности vs риски: как балансировать ускорение и угрозы
Преимущества ИИ в разработке очевидны и заманчивы. Главные драйверы, которые называют компании: повышение производительности, ускорение релизов и сокращение издержек. Но это тянет за собой шлейф рисков
- Риски качества и ошибок. ИИ склонен “галлюцинировать” – давать уверенные, но некорректные ответы. Разработчики жалуются, что много времени уходит на отладку кода, который почти рабочий. Здесь стратегией может быть создание дополнительных проверок. Автотесты, статический анализ, линтеры – обязательны даже для сгенерированного кода (особенно для него!). Некоторые компании идут дальше: обязывают помечать или ревьюить весь код, внесённый с помощью ИИ
- Риски для организации и процессов. Без грамотного подхода ИИ может усилить узкие места. Например, DORA предупреждает: если компания страдает от устаревших процессов, технического долга, недостатка автоматизации, то ускорение разработки через ИИ приведёт к лавинообразному росту проблем – больше сырого кода вольётся в те же кривые пайплайны. В итоге, в таком случае помимо внедрения AI-инструментов надо заниматься развитием платформы разработки и инженерных процессов.
- Конфиденциальность и безопасность данных. ИИ-инструменты часто требуют отправки исходного кода или данных на внешние сервисы. Для финансовых компаний это красный флаг. Такие компании разворачивают AI решения локально и дорабатывают их под свои сценарии. Если у вас есть договорные отношения с провайдерами LLM моделей, то вы можете попробовать решить эту проблему на уровне договоров.
- Vendor lock-in. Сейчас рынок ИИ-платформ в основном контролируется несколькими игроками – OpenAI (Microsoft), Google, Anthropic и т.д. Если команда плотно подсаживается, скажем, на GitHub Copilot, возникает зависимость, поэтому крупные фирмы стараются диверсифицировать и держать контроль. Практика больших компаний – развивать внутреннюю экспертизу и/или использовать сервисы разных провайдеров (что умножает косты)
- Компетенции команды и “атрофия навыков”. Ирония: мы хотим, чтобы команда работала быстрее с помощью ИИ, но боимся, что от этого люди перестанут расти как профессионалы. Здесь все завязано на обучение сотрудников и мотивацию их не просто копировать ответы модели, а разбираться с ними и понимать как и почему это работает.
4. Как меняются процессы разработки и состав команд?
Широкое внедрение ИИ уже начинает менять структуру и роли в командах разработки. Есть прогноз, что в ближайшие годы потребность в тестировщиках и аналитиках снизится, а число инженеров-разработчиков в штате вырастет.
- Почему меньше тестировщиков? Традиционное ручное тестирование – один из процессов, наиболее поддающихся автоматизации ИИ. Современные инструменты способны сами генерировать тестовые сценарии, подбирать edge-cases и даже поддерживать тесты актуальными при изменении кода.
- Почему меньше аналитиков? Под словом аналитики здесь можно понимать бизнес-аналитиков, системных аналитиков – тех, кто переводит бизнес-требования в ТЗ, прорабатывает спецификации. ИИ начал постепенно отъедать и эту часть работы.
Уже сегодня влияние ИИ ощущается на командных ролях: разработчики становятся центром процесса, опираясь на ИИ, они берут на себя часть задач тестирования и аналитики; тестировщики и аналитики трансформируются в более технические и совмещённые роли, а еще возникают новые позиции. Для бигтеха и финтеха это шанс оптимизировать структуры команд и повысить эффективность, но успех зависит от переподготовки людей. Роль человека будет смещаться к тому, чтобы решать нестандартные проблемы, принимать продуктовые решения и направлять ИИ, в то время как ИИ возьмёт на себя больше рутины. Команды станут более “умными” и кросс-функциональными, а люди – более универсальными.
Окончание будет в финальном посте.
#AI #Engineering #Architecture #ML #Software #Economics #Software
[1/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)
Вчера вечером я был на закрытом мероприятии в SVOY Hamovniki, где прошла презентация большого исследования IT One и Сколково про ИИ в разработкe, а также поучаствовал в дискуссионной панеле «Будущее применение AI в разработке и создании продуктов». В ней участвовали следующие джентельмены
- Сергей Щербинин - CEO Faust Consulting
- Андрей Плужников - СЕО Hoff Tech
- Алексей Ульенков - Первый вице-президент Газпромбанка
- Женя Бобков - главный по цифровым витринам в Мегафон (тут я прям ошибаюсь, но ты меня поправь)
- Дима Немов - директор по развитию продукта IT One
- и ваш покорный слуга
Мы обсудили вопросы ниже, а я решил не останавливаться на разговорной части и поделиться своими мыслями с читателями канала
1. Что изменилось в разработке из-за AI?
2. Как повышать adoption AI? Сверху или снизу?
3. Как выглядит баланс плюсов и минусов: скорость разработки vs баги, утечки данных, vendor lock, снижение квалификации инженеров
4. Как меняются процессы разработки и состав команд?
5. Есть ли доверие к возможностям AI или это просто хайп?
6. Что ждет разработку на горизонте 3х лет? Сингулярность наступит или хайп схлопнется?
Дальше будет три поста с разбором этих вопросов + я отдельно разберу итоги исследования:
- Разбор первых двух вопросов
#AI #Engineering #Architecture #ML #Software #Economics #Software
[1/2] Про Netflix - Бизнес-планы и оргструктура (Рубрика #Business)
После просмотра подкаста с Элизабет Стоун, техническим директором Netflix, мне стало интересно, а как они в общем поживают, куда смотрит бизнес, как выглядит оргструктура и как выглядит инженерная культура и как дела с архитектурой. В первом посте мы обсудим все кроме архитектуры.
Netflix делает ставку на следующие направления
1️⃣ Основной бизнес стриминга
- Здесь увеличиваются инвестиции в оригинальный контент, развиваются инструменты для кинопроизводства
- Совершенствуется персонализация сервиса и монетизируется совмстное использование (платный шеринг)
- Успешно движется пилотирование прямых трансляций
- Идут работы по приросту подписчиков, например, за счет тарифных планов с рекламой
2️⃣ Рекламный бизнес
- Изначально компания быстро вышла на рынок рекламы вместе с Microsoft
- Спустя полтора года после запуска тарифов с рекламой Netflix объявил о создании собственной ad-tech платформы
- Цель - самостоятельно контролировать рекламные технологии, чтобы предлагать брендам более таргетированные и персонализированные объявления для ~270 млн пользователей.
3️⃣ Рынок видеоигр и облачного гейминга
- Начиная с 2021 года Netflix включил мобильные игры в подписку
- В 2024 году Netflix назначил президента по играм Алена Таскана, экс-руководителя студии Epic Games, чьей целью было сделать так, чтобы "играть на Netflix было так же легко, как стримить кино в пятницу вечером"
- В 2025 году Netflix зашла на рынок облачного гейминга и стартовала интеграции игр непосредственно в приложение Netflix на ТВ: пользователь выбирает игру на экране телевизора, а смартфон используется в роли контроллера. Таким образом, Netflix устранняет лишние препятствия для казуальных игроков
- За первые 10 месяцев 2025 года уже есть результаты - количество загрузок игр выросло на 17% (до ~74,8 млн) по сравнению с аналогичным периодом 2024 года.
Если говорить про оргструктуру, то технологическое подразделение играет стратегическую роль. В январе 2023 года сооснователь Рид Хастингс отошёл от оперативного управления, и руководство перешло к двум со-CEO: Тед Сарандос отвечает за контентное направление, а Грег Питерс - за продуктово-техническое. Грег Питерс ранее многие годы возглавлял development и продуктовую организацию Netflix, и с его повышением до co-CEO технологическая повестка получила ещё более высокий приоритет на уровне высшего менеджмента. В конце 2023 года Netflix обновил высший технический состав
- Появилась позиция CTO и на пост главного технического директора назначили Элизабет Стоун (про подкаст с которой я рассказывал раньше). Стоун пришла в Netflix в 2020 году и руководила командой Data & Insights (департамент продуктовой аналитики и науки о данных). Наверное, это назначение подчёркивает, что компания видит свое будущее в тесном симбиозе технологий и анализа данных
- Параллельно должность Chief Product Officer (CPO) заняла Юнис Ким, отвечающая за пользовательский продукт (интерфейсы, рекомендации, игровой UX и т.д.)
По словам Грега Питерса, эти два лидера “будут возглавлять чрезвычайно важную часть нашего сервиса” - то есть всю техническую платформу и пользовательский опыт, улучшая возможности поиска и открытия контента (фильмов, сериалов и игр) для аудитории. Таким образом, на уровне топ-менеджмента создан тандем, в котором технологии и продукт находятся в фокусе развития Netflix.
Если же говорить про инженерную культуру, то ее отлично описала Элизабет в уже упоминавшемся подкасте. А в следующем посте я расскажу про инфраструктуру и архитектуру Netflix (по-крайней мере про то, о чем они рассказывали публично за последние 10-15 лет).
#Culture #Management #Leadership #Processes #Engineering #Software
[2/2] Про Nubank (Рубрика #Business)
Продолжая рассказ про Nubank, я хотел кратко изложить тезисы Витора Оливейра, который рассказывал про технологии в Nubank в подкасте "Hippsters Ponto Tech #459" (правда, подкаст на португальском) в апреле 2025 года, а уже в августе 2025 года его сменил Eric Young (экс-VP Engineering Snap, Google, Amazon), что, как по мне, дало ясный знак инвесторам на то, что Nubank готов масштабировать свою инженерную ветку для глобальной экспании, о которой было рассказано в предыдущем посте.
1️⃣ Тесты как “первая линия обороны” Nubank
- В Nubank большой фокус на тестировании: юнит-тесты, интеграционные, multi-service-тесты и эксперименты с genAI генерацией тестов
- Обоснование в том, что для крупного финтеха это не “nice to have”, а "must have", чтобы защитить чувствительные финансовые данные клиентов и держать высокую планку по стабильности, безопасности и приватности
2️⃣ Эволюция архитектуры: от JVM-стека к cloud-first
- Исторически Nubank строился вокруг JVM-стека (Clojure + Kafka), что задавало определённый стиль архитектуры и инженерной культуры (подробнее про историю можно глянуть в посте "10 years of engineering at Nubank")
- Сейчас у ребят стратегия cloud-first, но не "cloud at any cost": они осознанно балансируют между облаком и on-prem, учитывая три критерия: стоимость, контроль и сущность бизнеса
3️⃣ Ключевые инженерные принципы
Витор подчеркнул фундаментальные принципы, которые направляют технические решения
- Иммутабельность - immutable инфраструктура и сервисы
- Стандартизация - однообразие подходов вместо зоопарка технологий
- Continuous Delivery - непрерыная поставка и безопасные релизы
- Минимизация сложности - сознательное сопротивление "архитектурному энтузиазму", который раздувает систему
4️⃣ Компания как система - это не только про технологии
- Nubank смотрит на себя как на целостную систему, где культура и люди не менее важны, чем код и кластеры
- Важно уметь масштабировать команды и процессы под глобальное развитие (новые рынки, разные регуляции, распределённые команды), а не просто "накидывать микросервисы"
- Витор упоминает Conway’s Law: как структура коммуникаций влияет на архитектуру, и почему без правильного оргдизайна хорошую архитектуру не получить
5️⃣ Generative AI - осторожный, прагматичный подход
- Nubank уже использует gen AU, но очень аккуратно: они не гонятся за хайпом, а ищут конкретные, измеримые проблемы, где ИИ реально улучшает эффективность
- У ребят есть отдельные бюджеты и команды, которые экспериментируют с AI-подходами в тестировании и других задачах, системно отсеивая то, что “не взлетает”.
- Главный фильтр: безопасность и приватность данных
6️⃣ Главная мысль выпуска примерно такая
Зрелый финтех строится не вокруг модной технологии, а вокруг
- Строгой инженерной дисциплины (тесты, стандарты, CD)
- Осознанных архитектурных решений (JVM-ядро, cloud-first, но с пониманием ограничений)
- Системного взгляда на организацию и культуру
- Осторожного, прагматичного внедрения AI, где безопасность и ценность важнее демонстраций "магии"
P.S.
Интересно потом будет сравнить эти тезисы Витора с выступлениями Eric Young, нового CTO, что вышел только в конце лета.
#Software #Engineering #Management #Architecture #Processes #SRE #DevOps #Leadership
[2/2] Designing Your Work Life (Дизайн работы мечты) (Рубрика #Career)
Продолжая рассказ про книгу дизайна работы мечты, можно показать как советы авторов разложить на 4 недели
1) Неделя 1 - Диагностика и рефрейм
- Начать вести энергодневник (5 дней). Отмечайте задачи, которые «заряжают/высасывают». Найдите 2‑3 быстрых улучшения (автоматизация, шаблоны, таймбоксы в расписании)
- Сделать рефрейминг топ‑боли. Например, "Слишком много митингов" можно превратить в задачу "за 2 недели сократить суммарно с 10ч до 6ч через 15‑мин стендапы и ассинк‑апдейты". Это и есть MAP (минимально осуществимая проблема), которую перед собой предлагают ставить авторы
- Разделите гравитацию и задачи. "Акции идут на рынке вниз" - это гравитация; а "у нас нет тестов" - это задача.
2) Неделя 2 - Мини‑эксперименты (bias to action)
- Составьте job backlog: выпишите 10 гипотез, что сделает работу лучше/ценнее; выберите 1 с максимальным эффектом
- Раскатите прототип, например, поставьте добавьте no‑meeting block 2×90 мин в своем расписании, или внедрение pre‑commit hooks с прогоном проверок. Только надо определить метрику успеха заранее.
- Проведите несколько инфо‑интервью. Это могут быть 30‑мин разговоры с людьми из интересных команд/ролей. Просите рассказать истории, а не спрашивайте "есть ли вакансии". Зафиксируйте навыки/артефакты, которые реально ценят.
3) Неделя 3 - Remodel/Relocate
- Составьте 1‑пейджер для изменения в своей работе. Что вы убираете/делегируете, что берёте взамен, выгода для команды, риски, план проверки через 2 недели.
- Попробуйте shadow‑ротацию. Попроситесь на 1–2 технических шэдоу‑слота в соседнюю команду (обзор инцидентов, демо). Это безопасный "relocate‑прототип".
4) Неделя 4 - углубление анализа
- Проведите ARC‑скан. Оцените работу по шкале 1–5: автономия/связность/компетентность и проанализируйте, удовлетворены ли эти потребности в его текущей работе, и как можно улучшить ситуацию.
- Оцените как вы хотели бы выглядеть баланс денег, смысла и саморазвития в работе. В долгосрочной перспективе карьеру нельзя измерять одним показателем (например, только зарплатой)
- Внедрите WIP‑лимиты. Не более 2 параллельных задач; остальное в очередь.
- Практикуйте ритуалы роста. Еженедельный короткий пост‑анализ без обвинений: что попробовать иначе в следующем спринте.
Если улучшения не происходит, то можно начинать думать про "созидательное увольнение", где нужно максимально круто завершить текущую работу, параллельно занимаясь обновлением портфолио/репо/кейсы, собром референсов, составлением историю перехода ("что я изменил и чему научился"). Общий посыл в том, что надо уходить красиво, чтобы текущая работа стала трамлином к новым высотам, а уход не выглядел побегом
#Career #Software #Design
AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)
Записал расширенную версию доклада, который продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании". Тогда я задал рамку и рассказал про то, как подходить к внедрению AI в крупной компании. А на этот раз я сделал фокус на переходе к агентским сценариям и обсудил следующие темы
- Введение и обсуждение темы доклада
- История ассистентов (GitHub Copilot, Cursor)
- Переход к агентам и почему они выглядят как революция
- Примеры агентов и инструменты (Claude Code от Anthropic, OpenAI Codex)
- Инфраструктура и протоколы (MCP, A2A)
- Экономические предпосылки агентского хайпа
- Примеры успешных кейсов от Google AlphaEvolve
- Будущее работы и уровни агентности в исследовании от Stanford
- Управление и регулирование агентов в исследовании от Google Deepmind
- Эволюция SDLC к агентскому Software Engineering 3.0
- Демо агентского режима внутри Т-Банка на примере игры "5 букв"
- Экосистема разработки и цели инженеров в исследовании "Measuring Developer Goals" от Google
- Внутренняя платформа разработки и Spirit и наш подход к AIфикации разработки
- Агентский режим и работа с данными внутри python notebook
- Агентский режим для обеспечения качества и создания тест-кейсов
- Агент для код-ревью
- Агент для поиска уязвимостей (safeliner)
- Измерение эффективности и фреймворки оценки
- Фреймворк для оценки ассистентов и агентов от платформы DX
- Результаты использования ассистентов/агентов в Т-Банке
Разбор и ссылки на все источники для изучения доступны в моем tg-канале
- /channel/book_cube/3925
- /channel/book_cube/3931
Выпуск подкаста доступен в Youtube, VK Video.
P.S.
Пройдите опрос, чтобы поучаствовать в нашем про влияние AI на разработку в России.
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity
Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)
Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем
- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников»
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems
Гуляя с семьей по парку Швейцария в Нижнем Новгороде, наткнулся на "Отель для книг" и "Отель для насекомых". Креативный тут подход у ребят:)
А чуть позже мы поедем на нашу конфу "Сезон кода".
Towards AI-Native Software Engineering (SE 3.0): A Vision and a Challenge Roadmap (Рубрика #AI)
Недавно прочитал интересное продолжение whitepaper "Rethinking Software Engineering in the Foundation Model Era: From Task-Driven AI Copilots to Goal-Driven AI Pair Programmers", которую я уже разбирал. В новой статье те же авторы развивают идеи и рассказывают про Software Engineering 3.0, где текущий этап copilot и AI ассистентов они нумеруют SE 2.0 (они ускоряют работу, но создают когнитивный шум). На новом этапе разработка будет строиться вокруг намерений (intent-first). Условно, инженер говорит AI агенту, что нужно, а уже агент в формате диалога пишет код. Агент работает как напарник, обученный понимать цели и превращать их в работающую систему.
Авторы этой научной статьи выделяют пять составляющих новой экосистемы
- Teammate.next - AI-партнёр с «социальным интеллектом». Учится на диалогах, уточняет требования, помогает держать контекст.
- IDE.next - чат-среда вместо редактора. Код можно скрыть: внимание фокусируется на смысле, а не синтаксисе.
- Compiler.next - компилятор-агент, который не просто компилирует, а проверяет, совпадает ли результат с намерением и стандартами качества.
- Runtime.next - динамическая среда, оптимизирующая ресурсы для AI-сгенерированного кода, с учётом SLA и latency.
- FM.next — новое поколение foundation моделей: не обученных на шумных данных, а «воспитанных» через curriculum engineering – структурированное обучение инженерным знаниям
Авторы считают, что SE 3.0 будет работать лучше 2.0, так как в новой версии исчезает «шквал подсказок»: AI-партнёр сам агрегирует решения. Человек отвечает за смысл, машина — за механику. Вместе они снижают когнитивную нагрузку и ускоряют цикл разработки. Компилятор-агент проверяет качество, а knowledge-driven модели делают выводы не по шаблонам, а через понимание принципов. Авторы уверены: при целенаправленных исследованиях эти технологии приведут к новой эре разработки — более масштабируемой, надёжной и человеко-центричной. По мнению авторов мы стоим на пороге перехода от ремесла к наставничеству. Разработчик будущего не пишет код, а обучает ИИ-агента думать о системе, ставит задачи и проверяет результаты. Код превращается во вторичный артефакт — результат диалога человека и машины.
Интересно, что статья вышла осенью 2024 года, поэтому она предвосхитила хайп 2025 года вокруг AI агентов. В этом году концепция “agentic AI”, то есть AI-агентов, способных самостоятельно принимать решения, набирает популярность и рассматривается как следующий этап эволюции помощников для программистов. Аналитики прогнозируют, что эта тенденция уже в ближайшие годы подтолкнёт переход от простых AI-копилотов к полноценной AI-native разработке софта.
Собственно, авторы не стали скромничать и в сентябре этого года выпустили продолжение "Agentic Software Engineering: Foundational Pillars and a Research Roadmap" с таким описанием (заметим, что ключевые слова про агентский подход к разработке теперь указаны правильно)
Agentic Software Engineering (SE 3.0) represents a new era where intelligent agents are tasked not with simple code generation, but with achieving complex, goal-oriented SE objectives. To harness these new capabilities while ensuring trustworthiness, we must recognize a fundamental duality within the SE field in the Agentic SE era, comprising two symbiotic modalities: SE for Humans and SE for Agents.
[2/2] Исследование AI в SDLC от IT One и Сколково (Рубрика #AI)
Продолжая рассказ про исследование и переходя к российским реалиям хочется процитировать отчет
На текущий момент в России проникновение ИИ в задачи разработчиков происходит темпами, сопоставимыми с мировыми. Однако, на российском рынке, в отличие от мирового, проблемы и вызовы изменения жизненного цикла разработки под влиянием ИИ только начинают входить в приоритеты и фокусы технологических лидеров и тимлидов.
Эта цитата подкрепляется исследованием Руссофт от 2024 года, где опрос софтверных компаний показал, что 54,8% из них отметили, что они имеют экспертизу и опыт в области искусственного интеллекта и используют их в разработке новых заказных систем или собственных решений (эта чиселка отросла с 46,6% в 2023 году).
Авторы исследования дают оценку, что ИИ используют ~62% сотрудников ИТ‑команд (в 2 раза выше 2024), а к 2028 пороникновение будет ~98% (~3,22 млн пользователей). Я не смог источник, откуда взят этот прогноз (упоминается отчет Руссофта, приведенный выше, а также отчет T-Adviser про рынок труда).
Дальше авторы рассказывают про ландшафт AI инструментов в России и делятся оптимистичными цифрами
- Ассистенты разработчика: GigaCode (Сбер), Yandex Code Assistant / SourceCraft, МТС Kodify; DevSecOps: Safeliner (Т‑Банк)
- Публичные заявления о результатах применения этих инструментов навроде
-- GigaCode: до +28% к скорости разработки; −50% времени на регрессию; +30% скорость UI‑автотестов; 3× быстрее настройка конвейера; 2× быстрее онбординг DevOps;
-- 5× быстрее обработка ИБ‑уязвимостей в Safeliner от Т-Банка
-- Platform V Works (СберТех): −40% времени до прома в CI/CD; −50% времени на тестирование; +25% релизов; −20% трудозатрат
-- Альфа‑Банк: ИИ‑агенты‑тестировщики — −30% ошибок за счёт роста покрытия, до 70% быстрее генерация автотестов; масштаб на 60+ команд
Среди трендов авторы выделяют
- Встраивание AI в платформы разработки: IDE, CI/CD, DevSecOps и т.д
- Появление агентных сценариев - автогенерация тестов/кода, проведения код-ревью
- Изменение нормы эффективности и дальнейшее движение в стороны T‑shaped разработчиков
Интересно, что вызовами являются темы
- Измерений эффектов - меньше 25% компаний замеряют их, а те, кто измеряют ориентируются на TTM/Lead Time, дефекты на проде
- Регуляторика и риски качества недетерминированной работы LLM - ИБ/152‑ФЗ, качество LLM, контроль использования и «галлюцинаций»
Авторы исследования предлагают следующий план внедрения AI
- Выберите 1–2 узких сценария: юнит‑тесты, код‑ревью, ...
- Зафиксируйте базовые метрики: TTM, Lead Time, дефекты
- Примите политику ИБ: что можно/нельзя; on‑prem/cloud LLM для кода
- Встраивайте в платформу разработки/CI‑CD, а не кустарно сбоки
- Введите quality‑gate для AI‑кода% кодстайл, статанализ, обязательное ревью
- Создайте библиотеку промптов и обучите команду.
- Сравнивайте российские и зарубежные модели на своих задачах.
- Масштабируйте после 2–3 успешных пилотов с подтверждённым ROI.
#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy
У системных аналитиков нет комьюнити: миф или реальность
Почему у аналитиков нет ощущения «мы — вместе»? Можно ли построить сообщество без формальной структуры и зачем вообще это делать?
И правда, что фраза «мы как семья» больше мешает?
Все это мы обсудили в финальном выпуске второго сезона подкаста с Анастасией Кабищева, PMO Ekleft и консультантом по психологической безопасности команд.
Слушайте последний выпуск этого сезона, чтобы узнать:
➡️Что такое комьюнити и почему его нельзя построить «сверху».
➡️Зачем сообществу нужны цели, роли и даже «боли».
➡️Как уживаются конфликтность и безопасность внутри одной группы.
➡️Почему научить людей спрашивать — отдельный навык.
➡️Какие качества помогают системным аналитикам создавать живое комьюнити.
Где слушать?
🔸Яндекс.Музыка
🔸ВК
🔸Apple Podcasts
🔸Telegram-плеер
🔸остальные платформы
The Software Engineer's Guidebook (Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов) (Рубрика #Engineering)
Недавно дочитал книгу Гергели Ороша, автора рассылки "The Pragmatic Engineer", бывшего engineering менеджера в Uber и разработчика в Skype/Microsoft и Skyscanner. Я уже рассказывал про эту книгу раньше, когда я только начинал ее читать. Теперь, после прочтения, я могу поделиться кратким саммари.
Книга хорошо подходит для инженеров, которые хотят пройти по всем ступенькам от джуна до стафф+ инженера - часть материалов адресована всем уровням, а дальше блоки для middle → senior → tech lead → staff идут по нарастающей. Автор отдельно замечает, что книга полезна и менеджерам, особенно тем, кто старается оставаться «hands‑on». Книга разбита на отдельные темы + есть бонусные онлайн-главы
- Базовые принципы карьеры - пути развития, «владение» своей карьерой, performance‑review, промо, как работать в разных средах (стартап/BigTech), смена работы.
- Компетентный разработчик - как доводить задачи до результата, написание кода, процесс разработки, инструменты продуктивного инженера.
- Senior инженер - взаимодействие и командная работа, инженерные практики, тестирование, архитектура.
- Техлид (не важно должность это или роль) - проектное управление, выпуск в прод, управление стейкхолдерами, структура и динамика команды.
- Staff/Principal - понимание бизнеса, влияние без полномочий, надёжность и архитектура.
- Заключение + онлайн‑«бонус‑главы» к предыдущим частям
Книгу можно использовать как настольный справочник и читать точечно, в нужном месте.
Мне показались интересным советы о карьере, которые повышают осознанность и успешность движения по карьерной лестнице
- "Владейте своей карьерой" - ведите журнал выполненных задач, регулярно просите обратную связь и делайте менеджера союзником — это прямая инвестиция в промо.
- Готовьтесь к performance‑review готовятся заранее - начинайте собирать контекст и артефакты за месяцы до ревью, помогая менеджеру и калибровке.
- Промо ≠ просто "побольше сделать" - эффект конечно важен, но также нужно демонстрировать компетенции следующего уровня и координировать сложные инициативы.
- Среда имеет значение - BigTech и стартапы требуют разных стратегий; выбирайте то, что лучше под ваши цели и этап
В принципе, есть и другие похожие книги для IC и engineering managers, о которых я уже рассказывал
- Will Larson "Staff Engineer: Leadership Beyond the Management Track" - про то, как расти и работать на staff‑ветке без ухода в менеджмент (см. мой обзор)
- Tanya Reilly "The Staff Engineer’s Path" - подробное руководство по роли staff‑инженера: стратегия, влияние, стандарты качества (см. мой обзор)
- Camille Fournier "The Manager’s Path" - путь инженера в engineering менеджеры (см. мой обзор)
- Will Larson "An Elegant Puzzle" - системный взгляд на инженерный менеджмент и организационные решения (см. мой обзор)
Итого, эта книга мне показалсь довольно практичной и полезной для инженеров, которые хотят осознанно развивать свою карьеру не просто прыгая по уровням, а строя правильный инженерный фундамент и фокусируясь на важных вопросах на каждом этапе от джуна до staff инженера.
#Engineering #Management #Leadership #Processes #Software #Career #Staff #Career #Architecture
Podlodka Techlead Crew про архитектурные антипаттерны (Рубрика #Architecture)
Когда рассказывают про архитектуру, то теоретики часто фокусируются на том, а как строить качественную архитектуру. Но на практике инженеры часто сталкиваются с неидеально спроектированными системами, которые доставляют много проблем. Поэтому часто бывает полезно знать симптомы того, что ваша архитектура требует доработок. Ну а вообще лучше изначально разобраться с типовыми ошибками проектирования, которые бывают и у опытных инженеров. Именно этой теме посвящен новый сезон онлайн-конференции Podlodka Techlead Crew.
В программе конференции будут следующие выступления
- От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).
- AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). Кстати, Тимур многое делает для проникновения AI в архитектурные процессы Т-Банка.
- Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).
- Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).
Конференция пройдет на неделе с 13-17 октября и может принести вам много пользы, если вы связаны с проектированием и разработкой софта. Подробности здесь.
P.S.
Спасибо ребятам за то, что пошарили информацию о нашем исследовании AI в инженерной культуре России.
#Architecture #DistributedSystems #Software #Engineering #Processes #AI
ЦСКА - Спартак
Добрались с сыном на дерби со Спартаком. Первые двадцать минут выглядели как сказка - 3:0. Но потом сказка превратилась в триллер - Спартак сделал счет 3:1, а четвертый гол ЦСКА отменили. А второй тайм принес второй гол Спартака 3:2, травму Акинфеева и дальше футбол превратился в "бей-беги". Но матч так закончился со счетом 3:2, но концовка была валидольной. В общем, нам все понравилось:)
[4/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)
Заканчивая рассказ (1, 2 и 3) про панельную дискуссию расскажу про последние две темы
5. Есть ли доверие к возможностям AI или это просто хайп?
Несмотря на все успехи, в индустрии ощущается неоднозначное отношение к ИИ-инструментам. С одной стороны, все публично говорят о стратегиях AI-first и как нейросети влияют на эффективность. С другой – в кулуарах многие инженеры и менеджеры признают, что не до конца доверяют этим решениям и иногда «делают вид, что поддерживают тренд», подстраиваясь под моду. Где же граница между реальной верой в технологию и имитацией энтузиазма?
Объективно уровень доверия снизился по сравнению с ажиотажем первых лет. По данным опросов, доля разработчиков с явным позитивным отношением к AI-инструментам в 2025 снизилась до ~60%, тогда как в 2023 была > 70%. То есть первоначальный восторг поостыл, пришло понимание ограничений. Отчёт DORA говорит о «парадоксе доверия»: хотя 90% используют ИИ, только 4% полностью ему доверяют и лишь 20% доверяют «значительно». Около 30% вообще признают, что доверия мало либо нет. Другими словами, почти все считают ИИ полезным, но почти никто не считает его безошибочным. В итоге, сейчас многие следют поговорке "доверяй, но проверяй" - для высокорисковых операций все еще нужен human in the loop, а вот менее рисковые операции пытаются поручить условным AI-агентам с возможным пост-контролем (на дизайн ревью, на код ревью, на этапе тестирования). В общем, люди все еще неотъемлемая часть процесса
6. Что ждет разработку на горизонте 3х лет? Сингулярность наступит или хайп схлопнется?
Заглядывая на 3 года вперёд, можно с уверенностью сказать: ИИ всё глубже проникнет во все фазы жизненного цикла разработки ПО, хотя степень этой интеграции будет зависеть от зрелости самих организаций. Текущие тренды указывают, что ИИ из разрозненной “полезной приблуды” превращается в неотъемлемую часть инструментов разработчика – подобно тому, как когда-то системы контроля версий или CI/CD стали стандартом.
Уже сейчас ИИ задействован на многих стадиях: планирование и дизайн (ИИ-генерация требований, создание дизайна, наброски архитектуры), кодирование (автодополнение, генерация кода по текстовому описанию(аля агенсткий режим)), тестирование (автогенерация тестов, поиск багов), деплоймент и сопровождение (AIOps – прогнозирование инцидентов, автоскейлинг, анализ логов). Пока эти применения часто точечные – каждая команда сама прикручивает отдельные сервисы. Но в будущем можно ожидать более плотного сквозного встраивания ИИ во все процессы SDLC. DORA прогнозирует, что ИИ трансформирует каждый этап жизненного цикла, от дизайна до поддержки. Это значит, появятся интегрированные решения: скажем, ваш таск-трекер сразу подсказывает с помощью ИИ уточнения к требованию; среда разработки автоматически генерирует не только код, но и тесты (а может еще и тестовый стенд поднимает); AI SRE инженер мониторит системы и сам фиксит инцидент на проде, а потом пишет постмортем с анализом причин аварии.
Важный фактор – развитие самих моделей ИИ. Если за 2023–2025 мы видели скачок от “слегка помогающих” моделей к решениям, которые уже могут решить ~70% стандартных задач по кодированию, то к 2028–2030 можем увидеть еще более умных помощников. Скорее всего возникнет множество специализированных моделей: отдельные для генерации UI, отдельные для оптимизации баз данных, для миграции легаси-кода и т.п. Такие узко заточенные ИИ, работающие в составе единой экосистемы, сделают присутствие AI незаметным, но постоянным на всех стадиях.
А как же стартапы? У молодых компаний своя динамика: они чаще сходу “AI-native” – используют ИИ на всех участках, где можно, чтобы компенсировать малый штат. Им проще интегрировать новейшие технологии без бюрократии. Уже есть примеры стартапов, где значительная часть кода генерится ИИ, тестирование полностью автоматизировано AI-платформами, а люди фокусируются на уникальной логике.
#AI #Engineering #Architecture #ML #Software #Economics #Software
[2/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)
Продолжая рассказ про вопросы панельной дискуссии поделюсь мыслями про первые два вопроса
1. Что изменилось в разработке из-за AI?
2. Как повышать adoption AI? Сверху или снизу?
1. Реальные изменения в разработке под влиянием ИИ
Я рассказывал примерно про это в своем докладе "Интегрируем AI в процессы разработки в большой компании" на CTO Conf. Но если говорить кратко, то ещё пару лет назад ИИ-инструменты в программировании казались диковинкой, а сегодня ими пользуется подавляющее большинство разработчиков. Согласно отчёту DORA 2025, 90% технологических специалистов теперь ежедневно применяют ИИ при разработке – от программистов до продакт-менеджеров. Что же изменилось на практике? Разработчики ощутили ускорение рутинных задач. Генерация типового кода, шаблонов, тестов и документации теперь зачастую делегируется ИИ. По данным DORA, одни из самх распространённых кейсов
- Написание нового кода
- Модификация существующего (аля миграции кода)
- Генерация тестов
- Написание документации с помощью ИИ
Вместе с тем реальный эффект пока далёк от утопического кратного ускорения - улучшения есть, но пока не революционные. Если в прошлом году в отчете DORA наблюдалось даже замедление из-за внедрения ИИ (команды не успевали адаптироваться), то теперь ситуация выправилась: DORA-2025 впервые зафиксировал рост скорости выпуска софта при увеличении использования ИИ. При этом качество и стабильность выпуска остаются вызовом. DORA отмечает, что хотя throughput вырос, нестабильность и число сбоев по-прежнему повышены. Это ожидаемо: сначала все гнались за скоростью, теперь надо подтянуть качество.
2. Внедрение ИИ: стихийно «снизу» или управляемо «сверху»?
Практика показывает, что инициатива внедрения ИИ часто идёт “снизу” – от самих разработчиков. После появления массовых инструментов типа ChatGPT, Copilot и пр., инженеры начали экспериментировать с ними задолго до официальных указаний. Например, исследование Microsoft показало: 3 из 4 сотрудников уже используют ИИ в работе, причём ~80% делают это через личные, “принесённые из дома” инструменты (BYOAI). И в крупных корпорациях доля тех, кто самовольно внедряет ИИ, достигает 78%. То есть повсеместно возник феномен «Bring Your Own AI»: люди подключают в рабочие процессы сторонние ИИ-сервисы, зачастую без ведома ИТ-отдела и руководства. Так было с личными гаджетами (BYOD) в прошлое десятилетие, теперь то же самое – с ИИ-инструментами. Про это было исследование "The GenAI Divide: State of AI in Business 2025" от MIT, что я уже разбирал.
Плюс этого тренда – энтузиазм и быстрые локальные улучшения. Разработчики, аналитики, тестировщики находят полезные ИИ-фишки для своих задач (суммаризация требований, генерация SQL-запросов, автотесты и т.д.) и не ждут разрешения, чтобы ими воспользоваться. Минус – хаотичность и риски. Когда десятки людей тащат разные несертифицированные ИИ-сервисы, компания сталкивается с угрозами: утечка данных, нарушение комплаенса, непредсказуемое качество результатов.
Мне кажется, что лидерам нужно курировать, а не подавлять энтузиазм инженеров. Нужен открытый диалог о целях ИИ, обучение, внутренние «песочницы» для проб и централизованные меры безопасности позволяют превратить разрозненные инициативы в управляемую трансформацию. В конечном счёте, оптимальный подход – гибридный: воспользоваться импульсом “bottom-up”, подкрепив его стратегией и контролем “top-down”. Тогда ИИ внедряется не хаотично, а в русле общих целей, и компания извлекает максимум пользы без лишних сюрпризов. Это похоже на подход предложенный для развития экономики агентов в whitepaper "Virtual Agent Economies" от Google, который я уже разбирал. Там предложено проактивный дизайн правил и инфраструктуры для агентных рынков. Если это переносить на SDLC, то нам нужны понятные правила и дизайн использования внутренних AI инструментов vs внешних моделей/инструментов. Это нужно для пилотирования новых возможностей и понятных правил перехода в продакшен этих наработок
#AI #Engineering #Architecture #ML #Software #Economics #Software
Avito Tech Conf (Рубрика #Conference)
Сегодня приехало приглашение от Авито на их конференцию для менеджеров или как описывают организаторы это
Конференция для тех, кто управляет процессами, продуктами и людьми