Книжный куб

Внедрение AI в организации в стиле Григория Остера (Рубрика #AI) Недавно было первое апреля, а сегодня еще и суббота, поэтому я решил сегодня рассказать в канале про свою статью о внедрении AI в организациях по заветам Григория Остера и его книг из серии "Вредные советы". Эти книги предназначалась для непослушных детей и их родителей и в ней давались абсурдные советы, что приводили к катастрофам. Именно так в детстве я учился “от противного” как поступать правильно. Эта статья примерно в таком стиле рассказывает про внедрение AI в организацию, которое очень напоминает подход к “цифровым трансформациям” бизнеса, которые были популярны 10–15 лет назад у бизнесов, построенных не вокруг IT (условно не digital native). P.S. Если после прочтения статьи вы захотите испробовать альтернативный подход, то можете почитать мои статьи о том, как это стоит делать, правда в домене разработки софта (или как мы это называем AI4SDLC). Я про это много писал уже, например, можно посмотреть статьи 1️⃣ От классического PDLC к AI-native-разработке Здесь про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Подробная статья на моем сайте tellmeabout.tech. 2️⃣ От AI-native-разработки к AI-native-организации Здесь про то, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Подробная статья на моем сайте tellmeabout.tech. 3️⃣ От классического task management к AI-native: как меняется сама единица работы. Здесь про Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. Подробная статья на моем сайте tellmeabout.tech. 4️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Здесь о том, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. Подробная статья на моем сайте tellmeabout.tech. Серия этих статей описывают концептуальный подход, который положен в основу нашей стратегии и тактики на этот год в направлении внедрения AI в разработке внутри компании. #AI #Management #Future #Software #Engineering #Productivity #Agents #Processes

"Экономическое равновесие. Теория объемной геометрии в экономике" (Рубрика #Economics) Прочитал эту тонкую книгу Ильи Кунцевича, которая вышла в 2015 году. Я выбрал эту книгу, так как был привлечен центральной мыслью о том, что экономику следует рассматривать как закрытую систему, моделируемую с помощью геометрии, а не привычной линейной математики. Илья говорит о том, что линейные модели не справляются с описанием реальной экономики и именно это стало одной из причин кризиса 2008 года. В итоге, книга рассматриваются базовые понятия и инструменты экономики, анализ состояния мировой экономики, критерии экономического роста и распределения материальных ценностей, а также понятие фракталов, которое автор считает важным для понимания теории экономического равновесия. Забавно, что одна из ключевых идей автора про то, что идеальная схема экономики - это окружность, где люди вкладывают и получают взамен то, что действительно заработали. Ну и по все книге присутствуют треугольники и перевернутые треугольники, которые нарисованы одинаково, хотя автор рассказывает про углы наклона и нестабильность. Это и есть вся глубокая геометрическая теория, которая оказалась разочаровывающей:) В итоге, книга показалась мне местами интересной по рассуждением, но практически без теоретической основы, без особой глубины геометрической концепции и без достойных иллюстраций идей. Рекомендовать ее читать не буду, но мне понравилось заочно дискутировать с автором в своей голове:) #Economics #PopScience #History

Как AI меняет инженерную культуру / Александр Поломодов (Рубрика #Engineering) Появилась запись моего выступления на конференции Dream Teamlead, что устраивал Yandex в прошлую субботу. Я уже рассказывал про него, но кратко в нем было 4 темы 1) Как себя чувствует индустрия разработки софта в эру AI - тут анализ основан на нашем исследовании AI4SDLC 2025 2) Как мы движемся от классического PDLC к AI-native-разработке (у меня есть статья на эту тему) 3) Как AI-native-разработка приводит к AI-native-организации (у меня есть статья на эту тему) 4) Как меняется роль тимлида в такой организации (так как выступал на конференции для тимлидов, то надо было поговорить о том, а что эти изменения значат для них) #AI #Management #Future #Software #Engineering #Productivity #Agents #Processes

State of AI4SDLC на DevOpsConf 2026 (Рубрика #DevOps) Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке. Вообще мое выступление будет состоять из следующих частей 1️⃣ Как себя чувствует индустрия Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы - В каких задачах разработки AI используется чаще всего, а где остаётся редким? - Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)? - Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)? - Какие элементы процесса превращают индивидуальный эффект в командный? Сами результаты доступны здесь 2️⃣ От классического PDLC к AI-native-разработке Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech. 3️⃣ От AI-native-разработки к AI-native-организации Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech. 4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech. 5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подзодят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech. P.S. У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям. P.P.S. Если будете очно на кофне, то можете поймать меня и пообщаться. #AI #Management #Future #Software #Engineering #Productivity #Agents #Processes

Я решил устроить небольшой опрос ^ , чтобы понять какие материалы вам больше нравятся на канале. Я постараюсь учесть ваше мнение и подкорректировать плотность постов в нужную сторону. И спасибо вам, что подписаны и читаете канал.

The programming language after Kotlin – with the creator of Kotlin (Рубрика #Engineering) Очередной интересный выпуск "The Pragmatic Engineer" на этот раз с Андреем Бреславом, создателем Kotlin и основателем CodeSpeak, в котором Гергели Орош обсуждает с Андреем как появляются и приходят к успеху инженерные платформы и языки - через правильное время для появления, компромиссы, важность инструментария, совместимость с экосистемой и ясное понимание, что должен делать человек, а что - машина. Если кратко описать содержимое, то ключевые вопросы и ответы звучат так 1. Почему Kotlin вообще появился 2. Как принимаются языковые компромиссы 3. Почему Java interoperability стала не просто технической деталью, а стратегией успеха Kotlin 4. Как Android неожиданно стал важным ускорителем для Kotlin 5. Что сейчас происходит в рзаработке во время LLM эры Основные инсайты: 1. Лучшие инженерные решения побеждают не из-за "красоты", а потому что попадают в реальную боль рынка. Kotlin выстрелил не в вакууме: он появился в момент, когда Java тормозила, а разработчикам нужен был более удобный язык без разрыва с существующей экосистемой. 2. Tooling важнее, чем многие думают. Первая версия Kotlin была не компилятором, а IDE-плагином. Сначала язык сделали демонстрируемым и удобным в среде разработчика, а уже потом дотягивали execution path. Это хороший урок для любых platform teams и внутренних developer tools. 3. Дизайн платформы - это управление необратимостью. В Kotlin есть красивые решения вроде smart casts, за которыми скрывается сложная логика компилятора, а есть и сожаления вроде отказа от ternary operator, который позже уже нельзя было аккуратно вернуть. Для техлидов это напоминание: ранние API- и platform-решения цементируются быстрее, чем кажется. 4. Совместимость - это не компромисс второго сорта, а стратегия дистрибуции. Ставка на двустороннюю совместимость с Java и готовность работать в существующих ограничениях экосистемы оказались важнее, чем попытка сделать идеальный "язык с нуля". Android-поворот только усилил этот эффект 5. В эпоху LLM ценность инженера смещается выше по стеку абстракций: от написания каждой строки к описанию intent, ограничений, тестов и гейтов качества. CodeSpeak строится вокруг идеи "поддерживать спецификации, а не код", а сам Бреслав отдельно подчеркивает, что работа с AI coding tools - это навык, которому можно учиться. Он также ожидает новый виток специализированных, agent-first IDE. В общем, это был интересный подкаст, который только краем задевал тему AI, что теперь редкость в моем плейлисте:) #SystemDesign #Engineering #Leadership #Architecture #AI #Software #DevEx

Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году (Рубрика #Management) В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native организации. В этой статье я планировал рассмотреть подходы бигтехов к организации этого перехода и постановке целей внутри организации, а также измерения результатов. По публичным сигналам Microsoft, GitHub, Google, Amazon, Meta, Uber, Stripe и Netflix видно, что AI становится полноценным слоем инженерной операционной модели. Он встраивается в PR (pull requests), ревью кода, тестирование, миграции, триаж багов, CI/CD пайпланы и все чаще — в агентские workflow, где система не только подсказывает, но и выполняет bounded task под контролем человека. Мерить этот переход они тоже начинают по-новому: не одной метрикой usage, которая была популярна в прошлом, а целой цепочкой adoption → throughput → quality/risk → economics. Именно эта связка постепенно становится новым языком для технических топ-менеджеров и платформенных команд. Эта четверка выглядит примерно так 1) Adoption. Насколько AI вообще вошел в повседневный контур работы, сколько активных пользователей, каков adoption агентов, как распределено использование по командам, IDE, CLI и workflow. 2) Throughput. Сократились ли cycle time на PR и ревью, что произошло с time to merge, ускорился ли путь от первого коммита до открытого PR, выросла ли инженерная velocity. 3) Quality/risk. Что происходит с полезными комментариями, обратной связью, предотвращением дефектов, обработкой дубликатов ошибок, эффективностью тестирования и частотой инцидентов (это контр-балансирующие метрики относительно скорости и througput) 4 )Economics. Сколько сэкономили часов на конкретных джобах, человеко-лет спасено при миграциях, какое значение у CTS-SW (cost to serve software от AWS), какое ROI и какова стоимость масштабирования всего этого слоя AI. Именно такая связка всё чаще просматривается в официальных материалах GitHub, Google, AWS, Uber и Amazon.. #AI #Management #Future #Software #Engineering #Productivity #Agents #Processes

GitHub будем учить свои модели на поведенческих данных пользователей (Рубрика #AI) GitHub обновил правила для Copilot: с 24 апреля 2026 данные взаимодействия пользователей Free / Pro / Pro+ можно использовать для обучения AI-моделей по умолчанию, если это не отключить вручную. Причем речь идет не просто про prompts, ни и про остальную информацию: ответы Copilot, куски кода, комментарии и другой контекст, который пользователь отправляет в Copilot во время сессии. Причем содержимое приватного репозитория само по себе GitHub обещает не брать в обучение, но фрагменты приветного кода, которые вы сами отправили в Copilot, - уже другой случай. Старые настройки по отключению шаринга такой информации GitHub обещает сохранить. Для небольших команд и отдельных рзаработчиков это неприятный сдвиг в дефолтных настройках приватности. Особенность в том, что если разработчик использует личный Copilot-аккаунт в рабочем репозитории, часть рабочего контекста потенциально становится тренировочными данными. А значит личная подписка Copilot больше не выглядит нейтральным вариантом для работы с чувствительным кодом, внутренними API, названиями сервисов, инцидентами, архитектурными заметками и т.д. Для крупных корпораций сейчас ниже: GitHub отдельно выводит такие аккаунты и использование внутри организаций из обучения моделей в корпоративном контуре. Но проблема никуда не исчезает - она смещается в теневое использование: - сотрудники с личными Pro-аккаунтами, - подрядчики вне корпоративного контура, - сценарии личный аккаунт + рабочий репозиторий, - отсутствие явной политики, что можно и нельзя отправлять в AI-ассистенты. В общем, для больших компаний это проблема управления и повод пересмотреть границы разрешенного инструментария. Список мер может быть примерно таким: 1. Проверить, кто и на каких планах использует Copilot 2. Для рабочей разработки по возможности переводить команды на Business / Enterprise 3. Явно запретить личные AI-аккаунты в продовых и чувствительных репозиториях 4. Обновить vendor/privacy ревью: что считается данными взаимодействия, где opt-out из программы отгрузки телеметрии, что покрывает DPA (data processing agreement) 5. Зашить это в IDP/SSO/policy уровень: согласованные инструменты, обучение для инженеров В итоге, видно, что AI рынок сильнее сдвигается в сторону разделения Скорее да. Рынок AI все сильнее делится на две модели: - consumer/self-serve продукты учатся на пользовательских взаимодействиях, - enterprise продукты продают privacy и no-training как часть контракта. #AI #Engineering #Software #Productivity #DevEx

System-Design.Space (Update) (Рубрика #SystemDEsing) В последние недели я не останавливался с доработками своего сайта system-design.space. И сегодня я решил поделиться двумя тремя ключевыми изменениями 1) Я поменял дизайн главной страницы, чтобы прямо на ней был блок с онбордингом и описанием всех возможностей доступных на сайте: - Выбор трека изучения - Изучения графа знаний - Доступ на страницу со всеми материалами с поиском и фильтрацией по ним Надеюсь, что теперь сайт станет понятнее и удобнее для пользователей, а то я посмотрел ряд сессий из Яндекс Метрики, где пользователи попадали на сайт и как будто не могли понять а что на нем есть и дальше просто уходили 2) Теперь в каждой главе в начале есть блок, в котором рассказывается о чем глава, почему это полезно для проектирования систем, а также как эти знания можно использовать на интервью - это моя попытка объяснить почему главу стоит прочитать. Если вы по описанию видите, что глава вам не особо полезна или интересна, то сразу можно пролистнуть на следующую 3) Я сам устал от артефактов в мобильной верстке, поэтому мы с OpenAI Codex написали скрипты для e2e тестов layouts в десктопном и мобильном режиме и поправили 90+ проблемных глав. Теперь на мобилке должно быть гораздо приятнее изучать этот сайт. Было еще какое-то количество небольших изменения, но эти показались мне достойными упоминания. #SystemDesign #Architecture #Software #DistributedSystems #UX #Interview

[2/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps) Продолжая рассказ про новый отчет "State of DevOps 2026" от Perforce, поделюсь основными результатами, которые представляют менеджерский взгляд на связь зрелости DevOps практик и AI (ребята так подбирали респондентов, чтобы это были в основном менеджеры, что принимают решения по инфраструктурным и платформенным решениям в своих компаниях). 1️⃣ 70% респондентов говорят, что зрелость DevOps заметно повлияла на успех AI При этом только 38% организаций реально встроили AI глубоко в несколько стадий SDLC, еще 38% используют его часто, но без стандартизации, а 17% остаются на уровне ограниченных пилотов. Разрыв по зрелости огромный: в high-maturity организациях 72% лидеров говорят о deeply embedded AI, в mid - 43%, в low - 18%. В итоге, видно, что для масштабирования AI инициатив важна не покупка AI инструментов, а скорее подготовленная почва в виде зрелых инженерных процессов 2️⃣ AI наследует операционную модель работы, а не чинит ее В отчете 32% организаций описаны как highly standardized, 35% - mostly standardized, а 34% продолжают жить в частичной или хаотичном деливери. То есть примерно треть рынка по‑прежнему находится в зоне, где результат зависит от конкретной команды. Perforce называет это проблемой вариантивности: пока рабочие процессы, окружения и governance отличаются от команды к команде, AI будет давать столь же неравномерный результат. Отсюда и акцент на control plane: не "еще один инструмент", а шаренные шаблоны, шаренные стандарты, шаренные пайплайны и управляемые окружения. 3️⃣ На рынка уже есть разрыв в уверенности между доверием к AI и реальной интеграцией AI инструментов в процессы 77% респондентов говорят, что доверяют AI outputs, но только 38% действительно глубоко встроили AI в delivery, и лишь 39% имеют полностью автоматизированные данные для аудита. В части про измерения авторы формулируют риск прямо: организации доверяют AI быстрее, чем успевают построить проверяемость, auditability и согласованную измеримость. Это важный антидот против иллюзии, что рост локальной продуктивности в IDE уже означает зрелый AI-native delivery. 4️⃣ Экономический эффект есть, но он не возникает автоматически 74% опрошенных считают, что AI встречается с завышенными ожиданиями. Отдельно Perforce показывает, что ROI сильнее у тех, у кого зрелая система поставки: high-maturity организации на 36% чаще автоматизируют 61%+ деплоев от коммита до прода и на 66% чаще "very effectively" отвечают на продовые инциденты. У low-maturity организаций, наоборот, 78% delivery не стандартизованы а только 19% очень эффективно реагируют на инциденты. Если на пальцах, то без зрелого DevOps AI может ускорить работу, но одновременно увеличить долю переделок, вариативность результатов, время downtime и затраты. На мой взгляд, отчет Perforce очень хорошо подтверждает базовый тезис из моей статьи "От классического PDLC к AI-native разработке", что AI-native - это не еще один умный инструмент, а перестройка всей системы создания, проверки и поставки изменений. Только я иду еще дальше и размышляю про отдельные роли в этом новом процессе:) #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[1/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps) Изучил новый "State of DevOps 2026" от Perforce, который фокусировался на вопросе: что на самом деле определяет успех AI в системе поставки ценности - сами AI-инструменты или зрелость инженерной системы. Этот вопрос обусловлен вендорской спецификой, так как Perforce - это вендор Devops стека, поэтому авторы исследовали связь между зрелостью DevOps процессов, глубиной внедрения AI, ролью платформенной инженерии и IDP, а также пробелами в измерениях и экономическим эффектом AI относительно стоимости. Ну и ребята пришли к логичному выводу, что для масштабирования AI нужны зрелые DevOps практики и процессы. Методология выглядела как опрос 820 респондентов из глобального собщества, которые принимают IT решения, влияют на IT закупки, выбор инфраструктурных и платформеннных инструментов, а также на mission-critical приложения. С учетом такой выборки это скорее менеджерский взгляд на связь зрелости DevOps практик и AI, а не взгляд с позиции инженеров. Забавно, что авторы отфильтровывали из отчета менеджеров, которые не смогли бы объяснить коллегам термин "Agentic AI". А зрелость DevOps процессов авторы определяли операционно: через степень стандартизации delivery, качество работы с инцидентами, а также долю автоматизации деплоев, наличие автоматических rollback. В общем, авторы не претендуют на репрезентативность и выявление причинно-следственных связей, но дают интересную описательную статистику. В основу исследования легли четыре ключевых вопроса 1) Влияет ли зрелость DevOps на успех AI? 2) Что нужно, чтобы AI масштабировался между командами - локальные инструменты или централизованные системы, IDP (внутренние платформы разрботки) и control planes? 3) Умеют ли компании измерять и аудировать AI, или пока просто "верят", что он помогает? 4) Есть ли экономический эффект, и не съедают ли его cloud/compute затраты? Собственно, поэтому сам отчет и состоит из четырех частей:) В следующем посте я расскажу подробнее про полученные авторами результаты по итогам этого опроса #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

From Writing Code to Managing Agents. Most Engineers Aren't Ready | Stanford University, Mihail Eric (Рубрика #Engineering) Интересное интервью Mihail Eric, Head of AI at Monaco и лектора Стэнфорда, где он ведёт курс "CS146S: The Modern Software Developer". Mihail Eric интересно рассказывает про то, куда реально двигается разработка софта. Основная мысль про то, что профессия не исчезает, но центр тяжести уходит от ручного написания каждой строчки к оркестрации AI-агентов, декомпозиции задач, проверке результатов и проектированию среды, в которой агентам можно доверять. Собственно, сам курс "CS146S: The Modern Software Developer" как раз про это. В этом интервью 15-минутном интервью были несколько интересных мыслей 1️⃣ Eric объясняет почему junior-рынок так штормит тремя факторами - Перегретый найм после 2021 года и последующие сокращения - Резкий рост числа CS-выпускников - AI, из-за которого компании всё чаще думают не "кого ещё нанять", а "сколько AI-native инженеров нужно, чтобы закрыть тот же объём работы" 2️⃣ Eric объясняет, а кто такой AI-native engineer - Это не просто про промпт инженер, а скорее разработчик с нормальной базой в system design, алгоритмах и традиционной разработке - Этот инженер должен уметь работать с агентскими workflow По мнению Eric основная ошибка - это попытка сразу запускать много агентов. Но лучше начинать наоборот: сначала один агент на один workflow, потом постепенно добавлять только изолированные задачи и лишь затем масштабировать оркестрацию 3️⃣ Eric рассказывает про дружелюбную для агентов кодовую базу - Для агента тесты - это не "nice to have" фича, а фактически контракты - Если тестов мало, README устарел, а одинаковые сущности создаются разными паттернами в разных местах, то агент начинает гадать - и очень быстро начинает плодить ошибки. В итоге, тексты, документация и единые паттерны базы - это не просто инженерная гигиена, а просто база для AI-native разработки 4️⃣ Eric отмечает, что мульти-агентные workflows больше похожи на менеджмент, чем на классическое программирование Нужно уметь быстро переключать контекст, держать в голове, чем занят каждый агент, понимать, где он застрял, и мягко возвращать его в правильную траекторию. По сути, сильный AI-native engineer - это уже немного менеджер команды из агентов:) 5️⃣ Eric отмечает важность вкуса продуктового и инженерного Функциональный продукт и действительно сильный продукт разделяет не только корректность кода, но и желание пройти "последнюю милю": сделать фичу устойчивее, полезнее, глубже, довести UX и robustness. Eric связывает это с постоянным экспериментированием: даже команды, которые строят AI-инструменты, сами всё время переписывают и переизобретают свои workflow. В общем, автор за 15 минут продал мне свой курс про современную разработку софта, лекции которого уже доступны на Youtube. #Agents #Software #Engineering #Management #DistributedSystems #SystemDesign #AI

Как AI меняет инженерную культуру и что это значит для тимлидов и инженеров (Рубрика #Engineering) Именно с таким докладом я выступаю сегодня в 15:40 на конференции "Dream Teamlead" от Яндекса. Я расскажу про то, как сейчас меняются инженерные процессы и что это значит для индустрии и для условного тимлида, которому надо уметь теперь не только работать в формате Software Engineering 1.0, но и в новом формате. Круто, что у ребят будет доступна трансляция на сайте конфы Вообще мое выступление будет состоять из четырех частей 1️⃣ Как себя чувствует индустрия Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы - В каких задачах разработки AI используется чаще всего, а где остаётся редким? - Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)? - Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)? - Какие элементы процесса превращают индивидуальный эффект в командный? Сами результаты доступны здесь 2️⃣ От классического PDLC к AI-native-разработке Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech. 3️⃣ От AI-native-разработки к AI-native-организации Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech. 4️⃣ Как меняется роль тимлида В последней части я расскажу а как меняется роль тимлида при этих изменениях, ведь ему приходится теперь не просто распределять задачи - он теперь проектирует контур разработки или human-agent систему. Про это у меня пока нет статьи, но я ее обязательно напишу как follow up к этому докладу. P.S. В докладе у меня не хватит времени поговрить про изменения в управлении задачами, но на своем сайте tellmeabout.tech я уже опубликовал статью "От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)", которая рассматривает этот интересный вопрос. P.P.S. Если будете очно на кофне, то можете поймать меня и пообщаться, а если вы будете онлайн, то сможете посмотреть доклад в трансляции. #AI #Management #Future #Software #Engineering #Productivity #Agents #Processes

The State of DevOps Modernization 2026 (Рубрика #Devops) Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить. Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов. Авторы выделил следующие ключевые результаты 1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах. 2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции) 3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden paths В итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:) Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году #Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

From IDEs to AI Agents with Steve Yegge (Рубрика #Agents) Посмотрел выпуск подкаста Gergely Orosz "The Pragmatic Engineer" с крутым гостем, Steve Yegge, известным инженером ex-Google, ex-Amazon, ex-Grab, у которого 40+ лет в разработке. Он любит и умеет писать провокационные тексты про индустрии, недавно стал со-автором книги "Vibe Coding", а также создателем open-source оркестратора агентов Gas Town. Ребята весь выпуск обсуждали как меняется единица инженерной работы в наше время. Основные мысли, что мне запомнились, такие 1️⃣ Главный навык смещается от написания кода к управлению агентами Yegge описывает 8 уровней использования AI - от полного отказа до собственной оркестрации десятков агентов. Его тезис резкий, но полезный: застрять на уровне "иногда спросил IDE и очень тщательно посмотрел diff" - значит недоиспользовать новую модель работы. Для нас это означает: учить команды декомпозировать работу, создавать защитные барьеры (guardrails), способы оценки работы (evals), пайплайны ревью и мульти-агентные процессы и так далее. Примерно про это я писал в статье "От классического PDLC к AI-native разработке" 2️⃣ IDE становится не редактором, а диспетчерской Одна из центральных мыслей выпуска: новая IDE может превратиться в интерфейс разговора с агентами и мониторинга их работы, а не в место, где инженер вручную набивает код. Для нас это сдвиг фокуса с кодинга на постановку задач, работу с разрешениями, sandboxing, observability и встраивание агентов в SDLC) 3️⃣ AI жестко подсвечивает архитектурный долг В выпуске отдельно звучит, что монолитные кодовые базы - серьезный блокер для enterprise AI-adoption: агентам нужен обозримый и хорошо извлекаемый контекст. Для технических руководителей это практический сигнал: модульность, понятные границы, ответственность и владение кодом, документация и удобные для AI репозитории становятся не "архитектурной эстетикой", а прямым фактором скорости 4️⃣ AI меняет не только разработку, но и операционную модель команды Yegge несколько раз подчеркивает, что AI - это прежде всего аугментация, а не просто замена: маленькие AI-усиленные команды могут двигаться быстрее больших организаций, у которых бутылочные горлышки уже не в кодинге, а в согласованиях, приоритизации и способности компании переварить output. Даже если не принимать буквально его тезис про "мертвые большие компании", вывод практичный: код писать можно быстрее, а вот принимать решения и доводить до production - не факт. Примерно про это я писал в статье "От AI-native разработки к AI-native организации" 5️⃣ Рост продуктивности легко превращается в рост выгорания Стив рассказывает про эффект Дракулы или AI вампира - это мысль о том, что AI автоматизирует более легкую часть работы и оставляет человеку самые энергозатратные решения. В интервью Yegge говорит, что на максимальной AI-скорости у человека может быть всего около 3 продуктивных часов в день; ту же идею он отдельно развивает в своем эссе про AI Vampire. Для техлидов это, возможно, самый важный кусок: нельзя превращать 10x-инструмент в 10x-ожидание от людей. Еще была пара интересных мыслей - SaaS без API и platform-мышления рискует проиграть AI-native игрокам: если продукт плохо встраивается программно, его будут обходить или заменять - Прототипирование становится почти production-моделью: по словам Yegge, команды делают много быстрых вариантов и выбирают лучший, а не месяцами полируют одну реализацию. Про популярность таких подходов я рассказывал, когда говорил про Lovable, продукт из этой категории В общем, послушать Стива было интересно - он умеет размышлять о текущем и будущем широкими мазками, над которыми интересно поразмышлять и сравнить со своими мыслями. #AI #Management #Future #Software #Engineering #Productivity

От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear) (Рубрика #Management) Написал статью про то, что эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды внезапно переедут в какой-то новый инструмент, а потому, что тикет перестает быть центром мира. В классической модели он был основной единицей координации: в нем жили требования, приоритет, исполнитель, статус, комментарии, передача ответственности между ролями. В AI-native мире этой единицей постепенно становится не тикет, а context: намерение, ограничения, права доступа, история решений, автоматизации и агенты, которые способны доводить работу до результата. В некотором смысле эта статья логично продолжает две предыдущие - Про переход от классического PDLC к AI-native разработке - Про переход от AI-native разработки к AI-native организации А в этой статье я размышляю о том, а как будет выглядеть управление работой в таких компаниях #Engineering #Software #DevOps #DevEx #Process #Management #Metrics

Domain expertise still wanted: the latest trends in AI-assisted knowledge for developers (Рубрика #Edu) Интересный отчет про небольшой пульс опрос аудитории StackOverflow (900 человек), который они задизайнили вместе с OpenAI и который показал, что AI становится основной точкой входа в обучение инженеров, ... но не заменяет экспертизу. Авторы сравнили результаты с нормализованными результатами ежегодных отчетов StackOverflow Developer Survey 2024 и 2025 годов (см про них мои посты: 2024 и 2025). Нормализовать их пришлось, так как ежегодные отчеты StackOverflow проходят примерно по 50к инженеров. Основные результаты и цифры примерно такие 1) AI уже встроился в контур обучения инженеров: 64% разработчиков используют AI, чтобы учиться - против 44% в 2025 и 37% в 2024 2) Два главных драйвера: "starting from scratch" (28,2%) и efficiency (26,3%) 3) Параллельно 58% уже используют AI-инструменты на работе каждый день; среди early-career - 68%, среди experienced - 56% 4) 69% в принципе тратили последние полгода на изучение чего-то нового Авторы отметили, что меняется не только проникновение AI, но и подход к обучению - сжимается количество источников, что инженеры используют для обучения: доля тех, кто использует 8+ источников для обучения, упала примерно с 49% в 2024 до 9% в 2025 и 7% в этом пульс опросе. Кажется, что AI становится новой стартовой страницей, особенно для джунов и мидлов (36% и 39% соответственно идут в AI первым шагом) , а опытные разработчики еще держатся - они стартуют с техдокументации в 30% случаев и только в 29% начинают с AI:) Кажется, что я запоздал с публикацией сайта system-design.space:) Отрадно видеть, что AI почти никогда не работает в одиночку. Только 1% используют его как единственный источник. У большинства AI идёт вместе с документацией (58%), поиском/форумами/сообществами (54%) и Stack Overflow (50%). Самый большой стоп-фактор - доверие. 38% называют нехватку доверия результатам AI главным барьером для обучения через AI. В ежегодном отчете 2025 доверяющих точности AI было 33%, а недоверяющих - 46%. При этом у ежедневных пользователей доверие заметно выше, чем у еженедельных: 49% против 30%. Иначе говоря, AI ускоряет вход в тему, но добавляет налог на верификацию результатов. Интересны, что те, что AI побеждает за счет снижения барьера для обучения новому и удешевления момента "а с чего начать". Это видно из того, что 35% тех, кто не использует AI, говорят, что им не хватает времени на обучение. В то же время такую причину как препятствие для обучения указывают только 7% тех, что использует AI:) В итоге, нас ждет будущее, где AI инструмент будет стартовой страницей, а база знаний (типа Stack Overflow) будет обеспечивать слой доверия, поверх которого AI будет строить свои ответы. Ценность экспертизы при этом будет только расти, а главным навыком будет не просто хороший промптинг, но и умение быстро и качественно верифицировать ответы AI Что это будет значить дальше? Похоже, нас ждёт модель, в которой AI — точка входа по умолчанию, а документация, Stack Overflow и внутренние базы знаний становятся слоем доверия. Ценность senior-экспертизы не падает, а растёт: главный навык — не просто написать хороший промпт, а быстро верифицировать результат. #Survey #Engineering #Software #AI #Culture #RnD #Thinking #Brain

Optimizing for Time: Dark Matter (Рубрика #DevEx) С большим интересом посмотрел доклад с концеренции DPE Summit Карима Накада (Karim Nakad) из запрещенной в России компании Meta. Мне понравилось название, которое отсылает к космологическим теориям, объясняющим через темную материю состояние нашей Вселенной. Здесь эта метафора относится к тому, что мы часто фокусируемся на видимом спектре разработи: на улучшении IDE и ускорении сборок, но игнорируем огромные затраты времени на ежедневную рутину. Собственно, спикер называет "тёмной материей" невидимую нагрузку на сотрудкниов: чтение корпоративных чатов, стендапы, написание документации и помощь коллегам. Измерение этих скрытых активностей помогает выявить истинные причины снижения скорости работы технических команд. Мне особенно нравится разбор метрик продуктивности Meta, про которые я говорил и в других постах, например, при разборе выступления "Measuring the Impact of AI on Developer Productivity at Meta" с этой же конференции. Но в этом выступлении этот рассказ сфокусирован именно на метриках. Отдельно отмечается, что в Meta применяют агрегированные показатели для анализа процессов, строго запрещая их использование для индивидуальной оценки инженеров во избежание накруток. Сами метрики такие - By Tool -» TSD (Time Spent Coding per Diff): отражает время кодинга на один пулл-реквест, что позволяет инфраструктурным командам оценивать эффективность инструментов разработчика. - By Intent -» PCT (Percent Time Coding): показывает долю чистого программирования по отношению ко всем остальным задачам, помогая сокращать количество лишних встреч. Метрика важна для продуктовых команд - By Workflow -» WTS (Workflow Time Spent): отслеживает затраты времени в разрезе конкретного процесса (например, устранения инцидента) для поиска узких мест при переключении между системами. - By Value -» но здесь не показали метрики, а привели метафору про карту и про движение в нужном направлении (как бы это нужное направление не измерялось) Если говорить про подучу, то мне понравились слайды про фрагментацию дня. На слайдах видно, как день инженера распадается на десятки коротких переключений между IDE, чатом, календарём, review tools, notebook и SQL. Интересно, что Meta предлагает смотреть не только на raw coding time, но и на coding intent time - то есть считать инженерной работой не только минуты в редакторе, но и связанные с задачей походы в чат, wiki, SQL и документацию. Иначе очень легко оптимизировать не то место. Мне показались полезными идеи для инженеров о том, что надо защищать длинные focus-блоки, группировать коммуникации, глушить некритичные уведомления и перестать думать, что "настоящая работа" происходит только внутри IDE. А руководителям полезно посчитать стоимость переключения контекста и сравнить со стоимостью медленного билда; отдельно посмотреть на фокусное время команды, структуру календаря, объём асинхронного шума и только потом уже докручивать инструментарий. Иначе можно ускорить pipeline и всё равно потерять пропускную способность команды. #Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps

TAM-Eval и RM-RF от RnD центра Т-Технологий (Рубрика #Engineering) Наш R&D-центр представил пару методов TAM-Eval и RM-RF, которые делают генерацию модульных тестов с помощью LLM заметно более практичной для наглядности разработки. TAM-Eval задает воспроизводимые стандартные оценки качества тестов в живых репозиториях, а RM-RF еще умеет до сборки и запуска предсказать, какие тесты действительно полезны. На практике это означает меньшие дороги прогонов, меньшую нагрузку на инфраструктуру и цикл CI/CD. Это особенно важно в мире, который быстро движется в сторону AI-native разработки (см. пост) : когда код и тесты все чаще генерируют модели, главным конкурентным преимуществом становится уже не только генерация, но и надежная, быстрая оценка качества . Без этого AI-ускорение легко превращается в ИИ-хаос. Эти статьи хорошо приняты академическим сообществом: RM-RF принята в основной трек SANER 2026 , а TAM-Eval - на VST 2026. Напоследок процитирую Станислава Моисеева, руководителя RnD центра, который так описывал пользу этих методов

Эти методы делают работу больших языковых моделей с тестами более предсказуемой и эффективной для реальных процессов разработки. TAM-Eval задает стандарт сравнения моделей и агентов в сопровождении тестов по измеримым метрикам, а RM-RF позволяет отсеивать слабые тесты и ранжировать сильные без дорогостоящего запуска пайплайна на каждом шаге.

#Engineering #RnD #AI #DevOps #Software