Книжный куб

Краткий обзор платформы данных Т-Банка (Рубрика #Data) Прочитал интересную статью от коллег про про нашу data platform. Если обобщать достаточно длинную статью, то можно отметить, что платформа данных Т-Банка эволюционировала более 18 лет, следуя общеотраслевым трендам. Компания постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — к современным Lakehouse-архитектурам. Платформа сейчас обслуживает более 17 тысяч пользователей и обрабатывает свыше 144 млн запросов в месяц, что требует постоянного развития масштабируемости и производительности. Текущая архитектура включает 19 ключевых систем, которые обеспечивают полный жизненный цикл работы с данными — от сбора до визуализации и обеспечения безопасности. Вот как они сгруппированны 1. Сбор и транспортировка данных - Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации - Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh - Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс 2. Хранение данных - Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных) - LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками - Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах 3. Обработка и трансформация - Streaming Processing: Unicorn (на Apache Flink) и NiFi - Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации - Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы 4. Управление данными - Data Discovery: Data Detective для поиска и каталогизации - Data Governance: Data Contracts для управления поставками данных - Data Observability: DQ Tools для контроля качества и Data Incident Management - Data Security: SLH для управления доступом к чувствительным данным Если хочется узнать больше, то можно почитать статью и позадавать вопросы в комментариях. #Data #Database #Architecture #Software #Engineering #PlatformEngineering

Обложки книг "Meteorite. The Stones From Outer Space" и "Метеориты. Космические камни, создавшие наш мир"

Meteorite. The Stones From Outer Space (Метеориты. Космические камни, создавшие наш мир) (Рубрика #PopularScience) До прочтеиня этой книги Тима Грегори я никогда не воспринимал метеориты особенно серьезно. Но Тим, геолог и космохимик, в захватывающей манере превращает сухие научные факты о метеоритах в увлекательный детектив о происхождении Вселенной, где под обугленными корками небесных странников скрываются тайны, которые меняют наше понимание времени и пространства. Ниже я пробегаюсь по ключевым моментам кнги. Революция Клэра Паттерсона: Когда камни заговорили До середины XX века возраст Земли оставался предметом споров. Религиозные теологи настаивали на нескольких тысячах лет, основываясь на библейских текстах, в то время как ученые предлагали различные, часто противоречивые теории. Революционный прорыв произошел в 1953 году, когда американский геохимик Клэр Паттерсон применил к метеоритам новый метод радиоизотопного датирования. Он работал с фрагментами метеорита Каньон-Дьябло, упавшего в Аризоне около 50 000 лет назад. Используя соотношение изотопов урана и свинца, Паттерсон определил возраст этого космического камня — и, следовательно, возраст всей Солнечной системы — в 4,55 миллиарда лет. Эта оценка была настолько точной, что с тех пор практически не изменилась. Хондриты: Капсулы времени из протопланетного диска Особое место в космической хронологии занимают хондриты — самый распространенный тип метеоритов, составляющий около 85% всех падений на Землю. Эти древние каменные свидетели образовались практически одновременно с Солнцем из того же протопланетного облака газа и пыли. Хондриты получили свое название от характерных сферических образований — хондр, которые сформировались при плавлении силикатной пыли в раскаленном протопланетном диске. Эти крошечные шарики, размером обычно менее миллиметра, представляют собой застывшие капли расплавленного камня, возникшие в условиях экстремальных температур — от 1370 до 1270 Кельвинов. Наиболее примитивными среди хондритов считаются углистые хондриты, и самый известный из них — метеорит Альенде, упавший в Мексике в 1969 году. Этот космический гость массой около 2 тонн содержит самые древние из известных твердых веществ Солнечной системы — кальций-алюминиевые включения (CAI), возраст которых составляет 4,567 миллиарда лет. Досолнечные зерна: Звездная пыль древнее Солнца Но метеориты хранят в себе еще более древние сокровища — досолнечные зерна, частицы звездной пыли, которые старше самой Солнечной системы. Эти микроскопические крупинки, размером от нанометров до микрометров, образовались в атмосферах умирающих звезд или в выбросах сверхновых задолго до рождения нашего Солнца. Самое крупное из обнаруженных досолнечных зерен — «Bonanza», найденное в Мурчисонском метеорите, имеет размер 30 микрометров и возраст 5-7 миллиардов лет. Это самые древние твердые вещества на Земле, буквально звездная пыль из далекого космического прошлого. Современные методы космической археологии Современные технологии позволяют извлекать из метеоритов все больше информации о далеком прошлом. Масс-спектрометрия высокого разрешения дает возможность анализировать отдельные зерна размером в доли микрометра. Ионные микрозонды позволяют измерять изотопные соотношения с невероятной точностью — сопоставимой с измерением роста человека с точностью до толщины волоса. В общем, Тим говорит про изучение метеоритов как про "эпос, с которым нельзя сравниться". Ведь каждый упавший на Землю космический камень несет в себе историю звездных взрывов, межзвездных странствий и рождения планетных систем. Эти древние артефакты не только рассказывают нам о прошлом, но и продолжают открывать новые страницы в книге космической эволюции. #PopularScience #Physics #Science

Круглый стол «Техлид и развитие в Individual Contributor: как превратить код в карьеру» (Рубрика #Engineering) Появилась запись круглого стола на Techlead Conf X, где мы обсуждали ветку развития индивидуальных контрибьюторов. Делали мы это четверкой джентельменов - Максим Вишневский, ведущий (Mindbox) - Глеб Михеев (Сбер) - Александр Белотуркин (Делимобиль) - Александр Поломодов (Т-Банк) Если обобщать, то мы успели поговорить про следующие темы 1. Определение роли техлида и IC Техлид должен формулировать технологический ландшафт в команде, управлять зависимостями и вдохновлять команду на изучение технологий, не занимаясь при этом пил-менеджментом. Individual Contributor (IC) — это антипод менеджменту, инженер высокого уровня, который влияет на процессы через экспертизу, а не через управление людьми. 2. Проблемы текущего подхода - Техлиды часто превращаются в "играющих тренеров" — совмещают менеджерские и инженерные обязанности - Отсутствие четких рыночных стандартов для IC-ролей затрудняет найм и валидацию компетенций - В российских компаниях IC-ветка развита слабо по сравнению с западными (за исключением Т-Банка) 3. Критерии оценки IC В Т-банке используется матрица компетенций с фокусом на влияние, а не на технические навыки: - Scope - масштаб работы - Impact - влияние на компанию и пользу от действий - Leadership - способность координировать без административной власти - Improvements - способность улучшать процессы вокруг себя 4. Примерные уровни IC-грейдов в Т-Банке - Staff инженер - масштаб ~50 человек - Principal - масштаб ~200-250 человек - Fellow - масштаб всей компании и признание не только внутри компании, но и в индустрии 5. Практические аспекты - Развитие IC внутри компании предпочтительнее найма с рынка из-за специфики роли и необходимости понимания внутренних процессов. - Найм IC включает несколько этапов: техническое интервью, системный дизайн, оценка опыта и подходов к инженерным вопросам. Кстати, про найм staff+ инженеров я записывал отдельную серию Code of Leadership вместе с Алексеем Тарасовым - Функциональное лидерство — IC должны быть лидерами профессий/гильдий, но не управлять людьми напрямую. 6. Вызовы и решения - Проблема "партизанинга" - когда IC вносят изменения без согласования. Решение: создание гильдий, описание проблем перед внесением изменений, заблаговременное уведомление команд. - Баланс между инициативностью и координацией - важно брать ответственность за улучшения, но при этом согласовывать действия с командой. 7. Будущее IC-направления Обсуждение IC-веток возвращается с каждым кризисом, когда нельзя решать проблемы только увеличением финансирования. Мы согласились, что в российских компаниях есть потенциал для развития культуры инженерной ответственности, хотя большинство IC не придают значения формальным грейдам — для них важнее реальное влияние на процессы. P.S. На тему staff инженеров рекомендую почитать книгу Will Larson "Staff Engineer" и мои обзоры этой книги в двух частях: 1 и 2. #Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

OpenAI Windsurf acquisition falls through as leaders head to Google DeepMind (Рубрика #AI) Ночью появилась интересная новость про OpenAI и Windsurf. Если кратко, то OpenAI не смогла завершить запланированное приобретение стартапа Windsurf за $3 млрд, так как срок эксклюзивных переговоров истёк в июле 2025 года, а ключевые руководители Windsurf, включая CEO Варуна Мохана и сооснователя Дугласа Чена, перешли в Google DeepMind для работы над агентными кодирующими решениями в проекте Gemini AI. Кстати, раньше я уже рассказывал про интервью Мохана для Y Combinator, которое покрывало историю создания Windsurf и было дано во время этого несостоявшегося поглощения. После того, как ключевые люди покинули компанию Windsurf продолжит работать независимо, сохраняя доступ к своей базе из более чем миллиона разработчиков, а Google получит доступ к части технологий стартапа. Компания остаётся сильным игроком на рынке с годовой выручкой около $40 млн и оценкой в $1,25 млрд после раунда инвестиций в 2023 году. Срыв сделки и переход команды Windsurf к Google усиливают конкуренцию между OpenAI, Google и Microsoft (GitHub Copilot) в области AI-инструментов для программирования. Отмечается, что интерес OpenAI к Windsurf был связан не только с технологиями, но и с ценными пользовательскими данными для обучения новых ИИ-моделей. Дополнительное напряжение вносит и партнёрство OpenAI с Microsoft, которая претендует на права на технологии Windsurf в случае сделки. #AI #ML #Software #Engineering #Agents

[2/2] John Carmack Reveals AGI Future: Robots, Videogames and AI Agents... (Рубрика #AI) Продолжая рассказ о выступлении Джона, надо рассказать про существущие бенчмарки и новые предложенные. 1. Atari 200 M (классика DeepMind) Существующие подходы дают сверхчеловеческий уровень при "месяце экранного времени", то есть бенч уже "почти решён" и нужен следующий шаг 2. Atari 100 K Цель научиться максимум за 2 часа игрового опыта. Альгоритмы вроде BBF/EfficientZero дают прогресс, но чувствительны к задержкам изображения и действий 3. Sequential Atari Catastrophic Forgetting Суть в последовательном освоении 50+ игр без потери навыков. Работает пока не очень (кстати, запрещено прокидывать "task-id", чтобы не читерить) 4. Real-Time Atari via Robotroller Суть в устойчивости по latency и работе "по пикселям" на реальном железе. В итоге, получается ~180 мс лаг от камеры до действия; оценка по фронтальной камере и OCR-cчёту (внутри игры) 5. Unbounded Video Wall (проект на будущее) Исследование, ведомое любопытством в смеси пассивного и активного контента. Тут нет внешнего "эпизода" и чёткого финального счёта Все свои тесты Кармак называет "открытыми", потому что код и оборудование Keen Technologies планирует выкладывать в open-source, чтобы сообщество могло воспроизводить и улучшать результаты. Если подводить итоги, то - AGI ≠ просто более крупные LLM. Нужен агент, который учится на лету, не забывает старое и действует в реальном времени. - Игры остаются лучшим "физически безопасным" мостом между симуляцией и реальным миром, но метрики должны поощрять скорость обучения и устойчивость к задержкам, а не только итоговый счёт. - Главный вызов - методический. Чтобы избежать узкоспециализированных "трюков", Кармак предлагает жёсткие, но реплицируемые бенчмарки и "встроенную" защиту от читерства По словам Кармака, прогресс в этих направлениях покажет, как далеко мы на самом деле от AGI и даст более честную картину того, как двигаться в его сторону. #AI #AGI #ML #Software #Engineering #Architecture

[1/2] John Carmack Reveals AGI Future: Robots, Videogames and AI Agents... (Рубрика #AI) Очень интересное выступление Джона Кармака, со-основателя id Software, ex-CTO Oculus, основателя Keen Technologies. Интересно, что в команду Keen Technologies Джона входят 6 исследователей, включая его и Ричарда Саттона, "крёстного отца reinforcement learning". Кстати, Джона все мои сверстники знают его как создателя игры Doom, что вышла в 1993 году:) Он выступал с этой презентацией на конференции Upper Bound 2025 в середине мая. Интересно, что Кармак позиционирует себя как "инженера, ставшим исследователем" и считает создание AGI "самым важным, чем он может заниматься сегодня". Если говорить про сам доклад, то Джон предлагает отказаться от LLM-гонки, так как он не верит, что "блендер"-предобучение трансформеров приведёт к настоящему пониманию мира; ему важен интерактивный поток опыта. Он предлагает проверять гипотезы на играх, которые выглядят как чистый полигон. Причем коммерческие игры - это "непредвзятые" среды, так как исследователи не могут тайно подогнать среду под алгоритм. И целью является быстрая, непрерывная, многозадачная адаптация агента, близкая к тому, как кошка или собака учатся в реальном мире. Ключевые идеи выступления такие 1. "Сначала наука, потом инженерия" Кармак критикует RL-сообщество за "погоню за цифрами" и призывает искать фундаментальные закономерности обучения, а не только настраивать hyper-параметры. 2. Real-time RL против пошаговых симуляторов В реальном мире среда не ждёт, пока агент примет решение; лишние 150–200 мс задержки "ломают" многие алгоритмы. Джон продемонстрировал как это не работает на стенде "robotroller", который физически двигает джойстик Atari 3. Ошибки и уроки старта Keen Technologies Здесь Джон рефлексирует над своими ошибками как исследователя и выделяет следующие моменты - Он слишком глубоко погружался в низкоуровневый C++/CUDA - Пытался использовать Sega Master System вместо Atari, что затруднило сравнение с результатами предыдущих исследователей - Выполнение кода на ноутбучных GPU оказались узким местом - команда перешла на удалённые кластеры 4. “Видео-стена” как бесконечная среда обучения. Идея была в том, чтобы объединить пассивный видеоряд (TV/YouTube) и интерактивные игры в непрерывную ленту, где агент сам выбирает, что изучать. 5. Переход от симуляции к реальности Даже простой перенос из эмулятора Atari на реальный монитор + камеру требует решения проблем ввода-вывода, освещения и дрейфа изображения. В общем задачка становится сильно интереснее Продолжение с описанием бенчей и общими выводами будет в следующем посте. #AI #AGI #ML #Software #Engineering #Architecture

Анастасия, моя любимая жена, получила сегодня диплом по психоаналитическому бизнес-консультированию в ВШЭ. Она два года шла к этому диплому и сегодня обучение официально закончилось и диплом оказался в ее руках. Она попробовала персональные консультации, но в итоге решила вернуться с новыми знаниями в IT. Она опять стала руководителем и возглавила проектный офис в небольшой IT компании. Ей нравится групповая динамика и поиска баланса между бизнес-результатами и человеческими взаимоотношениями. P.S. Мы записывали с Настей подкаст из серии Code of Leadership, где обсуждали модель групповой динамики "BART" и сравнивали эту модель с моделью командообразования Такмана. #Psychology #Management #Project #Process #Edu

[2/2] François Chollet: How We Get To AGI (Рубрика #AI) Заканчивая рассказ про выступление Франсуа, надо рассказать про его фреймворки ARC-* и лабораторию Ndea 6. Предложенные бенчмарки - ARC-1. Выпущенный в 2019 году тест содержит 1000 уникальных задач, требующих подвижного интеллекта, а не заученных знаний. Все задачи построены на базовых знаниях (объектность, элементарная физика, геометрия), которыми владеет любой четырехлетний ребенок. За пять лет, несмотря на 50,000-кратное увеличение масштаба предобученных моделей, производительность на ARC-1 выросла только с 0% до 10%. Это убедительно доказало, что подвижный интеллект не возникает из простого масштабирования предобучения. - ARC-2. Выпущенный в марте 2025 года ARC-2 фокусируется на композиционном рассуждении. В отличие от ARC-1, где многие задачи можно было решить интуитивно, ARC-2 требует обдуманного размышления, но остается выполнимым для людей. Тестирование 400 человек показало, что группы из 10 человек могли бы достичь 100% точности. Однако базовые модели показывают 0% точности, статические системы рассуждения — 1-2%, и даже продвинутые системы с TTA значительно уступают человеческому уровню. - ARC-3. Запланированный к выпуску в начале 2026 года ARC-3 кардинально отходит от формата "вход-выход". Вместо этого он оценивает агентность — способность исследовать, обучаться интерактивно и автономно ставить цели. ИИ будет помещен в совершенно новую среду, где он не знает, что делают элементы управления, какова цель и каковы правила игры. Эффективность будет центральным критерием — модели должны решать задачи с тем же уровнем эффективности действий, что и люди. 7. Будущее направление: лаборатория Ndea В конце выступления Франсуа представил свою новую исследовательскую лабораторию Ndea, которая фокусируется на создании ИИ, способного к независимым изобретениям и открытиям. Подход Ndea заключается в создании программистоподобного мета-обучающегося, который при столкновении с новой задачей синтезирует программу, адаптированную к этой задаче. Эта программа будет объединять подмодули глубокого обучения для задач типа 1 (восприятие) и алгоритмические модули для задач типа 2 (рассуждение). Система будет использовать глобальную библиотеку повторно используемых строительных блоков-абстракций, которая постоянно эволюционирует в процессе обучения на новых задачах. Первой вехой станет решение ARC-AGI системой, которая изначально ничего не знает об этом бенчмарке. Видение Шолле выглядит впечатляющим, мне действительно понравилось выступление - я узнал много нового + добавил себе в to read list много новых материалов. #AI #ML #Software #Architecture #Processes

[1/2] François Chollet: How We Get To AGI (Рубрика #AI) С большим интересом посмотрел выступление Франсуа Шолле на конференции AI Startup School от Y Combinator в Сан-Франциско. Франсуа является создателем популярной библиотеки глубокого обучения Keras (2015 год), которая стала одним из ключевых инструментов. В 2015 году он присоединился к Google, где проработал почти десять лет, занимаясь исследованиями в области компьютерного зрения и искусственного общего интеллекта. В 2019 году он создал бенчмарк ARC-AGI для измерения способности ИИ к общему интеллекту. В 2024 году Шолле запустил ARC Prize — конкурс с призовым фондом в $1 миллион для решения задач ARC-AGI. В ноябре 2024 года Шолле покинул Google для создания нового стартапа. В январе 2025 года он основал исследовательскую лабораторию Ndea совместно с соучредителем Zapier Майком Нупом, фокусирующуюся на разработке AGI через программный синтез. В этом выступлении Франсуа поделился действительно интересными идеями 1. Эволюция парадигм ИИ Шолле проследил историю развития ИИ, начиная с постоянного снижения стоимости вычислений на два порядка каждое десятилетие с 1940 года. В 2010-е годы доминирующей стала парадигма масштабирования предобучения больших языковых моделей, основанная на увеличении размера моделей и объема данных. Однако в 2024 году произошел кардинальный сдвиг к адаптации во время тестирования (Test-Time Adaptation, TTA). Эта технология позволяет моделям динамически изменять свое поведение на основе конкретных данных, с которыми они сталкиваются во время вывода. TTA включает методы как обучение во время тестирования, программный синтез и синтез цепочки мыслей. 2. Определение интеллекта Франсуа критикует традиционное понимание интеллекта как способности выполнять конкретные задачи. Вместо этого он предлагает определение интеллекта как эффективности преобразования прошлого опыта в навыки для решения будущих задач с высокой новизной и неопределенностью. Ключевое различие: статические навыки против подвижного интеллекта. Статические навыки — это заученные программы для решения известных проблем, тогда как подвижный интеллект — способность синтезировать новые программы для незнакомых задач. 3. Гипотеза калейдоскопа Одна из центральных концепций выступления - гипотеза калейдоскопа. Шолле утверждает, что кажущаяся бесконечная сложность мира на самом деле состоит из небольшого количества "атомов смысла" - фундаментальных строительных блоков, которые рекомбинируются в различных ситуациях. Интеллект заключается в способности извлекать эти повторно используемые абстракции из опыта и эффективно рекомбинировать их для решения новых задач. Это объясняет, почему простое масштабирование предобучения не привело к AGI - моделям не хватает способности к рекомбинации на лету. 4. Два типа абстракции Франсуа выделяет два фундаментальных типа абстракции - Тип 1 (ценностно-центричная): работает с непрерывными пространствами, использует функции расстояния для сравнения объектов. Лежит в основе восприятия, интуиции и современного машинного обучения. - Тип 2 (программно-центричная): работает с дискретными программами и графами, ищет точные структурные соответствия. Лежит в основе человеческого мышления и планирования. Трансформеры отлично справляются с абстракциями первого типа, но плохо работают с абстракциями второго типа. Для достижения истинного интеллекта необходимо объединить оба подхода. 5. Программный синтез и дискретный поиск Ключ к преодолению ограничений современного ИИ Шолле видит в программном синтезе - методе, который позволяет автоматически создавать программы для решения задач. В отличие от градиентного спуска, который требует огромных объемов данных, программный синтез чрезвычайно эффективен в плане данных, но сталкивается с комбинаторным взрывом. Решение - использовать интуицию глубокого обучения (тип 1) для направления дискретного поиска программ (тип 2), создавая систему, которая может эффективно исследовать пространство программ. Продолжение про фреймворки и лабораторию Ndea в посте продолжении. #AI #ML #Software #Architecture #Processes

Интервью Вячеслава Цыганова Ведомостям: «Сейчас из каждого набора данных можно делать новый бизнес» (Рубрика #Management) Недавно мой руководитель Вячеслав Цыганов дал большое интервью "Ведомостям на популярную тему о возможностях искусственного интеллекта и трансформации IT-ландшафта в России. Если подбивать основные тезисы, то можно выделить следующие ключевые моменты 1. AI-first подход - Стратегия AI-Banking с 2019 года - зарегистрирован товарный знак AI-Bank - "Вселенная ассистентов" - 6 персональных ИИ-помощников в продакшене - 80% сотрудников уже используют ИИ, цель - 100% в 2026 2. Исследования и разработка - Стратегия open source: модели в открытом доступе на Hugging Face (дообученные Qwen) - Переиспользование открытых моделей требует в 10 раз меньше ресурсов (чем учить модель с нуля) - Разработан метод дообучения Trust Region с улучшением качества на 15% (whitepaper "Learn Your Reference Model for Real Good Alignment") 3. Инженерные продукты - Spirit - централизованная PaaS-платформа для разработчиков, ориентированная на приложения - Sage - платформа для надежности высоконагруженных сервисов. Кстати есть такая статья про надежность у нас в Т-Банке, которую я разбирал - FineDog - управление инцидентами - Nestor - копайлот для разработчиков (используют 60% девелоперов ежедневно) - Safeliner - ИИ-ассистент для анализа и исправления кода 3. Инфраструктура - Инфраструктура удваивается каждый год - Доля данных в ландшафте выросла с 20% до 80% за 7 лет - Строительство собственных ЦОДов: 50 МВт в Доброграде и Серпухове - Запуск первой очереди - I квартал 2027 4. Data-driven трансформация - Тезис, что вынесен в название интервью - "Из каждого набора данных можно делать новый бизнес" - Гиперперсонализация через ML-рекомендации - это то, куда мы идем - Приложение реорганизовано вокруг жизненных ситуаций с персонализацией - это наши Сферы: Дом, Авто, Тревел, Шоппинг и другие 5. Стратегия в направлении AI Не конкурировать напрямую с Яндексом и Сбером в создании моделей с нуля, а использовать open source как основу для специализированных решений #Management #AI #Engineering #Software #Strategy

12-Factor Agents: Patterns of reliable LLM applications (Рубрика #AI) С интересом посмотрел выступление и дальше изучил GitHub про 12 factor app для агентов. С этой темой выступал Dexter Horthy - опытный инженер и основатель компании HumanLayer (стартап в Y Combinatir). Ключевая идея Декстера в том, что вместо одного большого агента стоит делать небольшие сфокусированные агенты - это похоже на ситуацию с монолитом и микросервисами. Декстер считает, что агенты - это просто софт, то есть если вы умеете в swith и while, то вы можете создавать агентов. Но для их создания лучше использовать не фреймворки, что позволяют получить 70 - 80% качества, а дальше требуется проводить реверс инжиниринг фреймворков, чтобы подтюнить агентов до оставшихся 20%. Автор предлагает набор из 12 факторов, что похожи на 12 факторов от Heroku, ставших потом частью принципов создания cloud native приложений. Ну а теперь пожалуй можно рассказать и про все 12 факторов 1. Natural Language to Tool Calls. Один из самых распространенных шаблонов в построении агентов - это преобразование естественного языка в структурированные вызовы инструментов. Это мощный шаблон, который позволяет вам создавать агентов, которые могут рассуждать о задачах и выполнять их. 2. Own your prompts. Не стоит передавать управление промптами на сторону фреймворка 3. Own your context window. LLM - это функции без состояния, которые превращают входы в выходы. Чтобы получить лучшие выходы, нужно дать им лучшие входы. 4. Tools are just structured outputs. Инструменты не должны быть сложными. По своей сути, они просто структурированный вывод из вашего LLM, который запускает детерминированный код. 5. Unify execution state and business state. Даже за пределами мира AI многие инфраструктурные системы пытаются отделить "состояние выполнения" от "бизнес-состояния". Для приложений ИИ это может включать сложные абстракции для отслеживания таких вещей, как текущий шаг, следующий шаг, статус ожидания, количество повторных попыток и т. д. Такое разделение создает сложность, которая может быть полезной, но может быть излишней для вашего варианта использования. 6. Launch/Pause/Resume with simple APIs. Агенты - это всего лишь программы, и у нас есть определенные ожидания относительно того, как их запускать, опрашивать, возобновлять и останавливать. 7. Contact humans with tool calls. Интеграция взаимодействия с людьми через инструменты (для принятия решений или доп информации) 8. Own your control flow. Владение control flow позволяет добавлять probes, тесты и многое другое 9. Compact Errors into Context Window. Обработка ошибок через контекстное окно без слепого добавления stack traces ошибок 10: Small, Focused Agents. Создание маленьких agents с 3-10 шагами вместо монолитных решений. 11. Trigger from anywhere, meet users where they are. Агенты должны быть доступны из разных входных точек: slack, email, API, ... 12. Make your agent a stateless reducer. Агентов стоит проектировать как stateless функции для лучшей масштабируемости Если подводить итоги выступления, то 1. Фреймворки и строительные блоки для агентов. Декстер не выступает против фреймворков, но предлагает использовать 12 факторов для того, чтобы делать более мощных и надежных агентов (возможно фреймворки потом будут поддерживать эти 12 факторов) 2. Инкрементальный подход. Самый быстрый путь для создателей агентов для получения качественного AI софта - брать маленькие, модульные концепты и включать их в существующий продукт. 3. Инженерная составляющая. Даже если LLM станут экспоненциально мощнее, core engineering техники останутся ценными для создания более надежного, масштабируемого и поддерживаемого Gen AI софта. 4. Взаимодействие людей и AI. По мнению автора, будущие агенты не должны быть полностью автономными - важно найти способы для агентов сотрудничать с людьми. #AI #ML #Software #Architecture #Processes #DevEx #Devops #Agents

Research Insights Made Simple #11 - Measuring AI Code Assistants and Agents (Рубрика #DevEx) Очередной выпуск подкаста с разбором whitepaper "Measuring AI Code Assistants and Agents" посвящен разбору измерения эффекта от AI в разработке. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health. За полчаса мы разобрали whitepaper и осудили темы - Платформа DX и оценка влияния кодовых ассистентов и агентов на продуктивность инженеров - Структура фреймворка DX: этапы зрелости, метрики и риски неправильного внедрения - Оценка adoption и утилизации - Оценка импакта и метрики - Коммуникация внедрения метрик в разработку - Обсуждение фреймворков DORA, SPACE, DevEx, DX Core 4 для измерения эффективности продуктивности инженеров в общем Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. P.S. Я разбирал этот whitepaper раньше в своем tg канале раньше. #Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes #AI #Agents

Мини-CEO от Т-Банка: Твой билет в топ-менеджмент (#Edu) Мы запустили программу "Мини-CEO" - первую в России программу карьерного развития, где студенты и выпускники работают бок о бок с топ-менеджерами компании. Для студентов это возможность 6 месяцев проработать под крылом одного из директоров Т-Банка. В это время придется изучать рынки, оценивать их емкость, запускать MVP, решать задачи в риск-аналитике, работать с данными для персонализации продуктов. Подать заявку на программу и решить тестовое задание можно до 7 августа на сайте. Затем претендентам на участие предстоит пройти видео-интервью с рекрутером, решить бизнес-кейс, после чего защитить его в офисе Т-Банка, а также пройти финальное интервью с топ-менеджером компании. Кандидатам из регионов, которые успешно пройдут все этапы отбора, Т-Банк обеспечит бесплатное проживание в Москве на время программы. Тех mini CEO, что успешно закончат полугодовую программу, возьмут в штат компании. #Edu #Software

Code of Leadership #43 - Interview with Andrew Ivanov about science & engineering management (Рубрика #Management) В очередном выпуске подкаста ко мне пришел интересный гость, Андрей Иванов, мой бывший коллега, что успел поработать в OneTwoTrip, Tinkoff, ChatterMill и сейчас работает в InDrive. Андрей закончил МФТИ, создавал стартапы, был инженером и уже больше 5 лет работает engineering director в разных компаниях. За полтора часа мы успели обсудить кучу тем - Знакомство с гостем - Ранние годы и школьное образование - Поступление в МФТИ - Переломный момент ухода от математики и физики к computer science - Первый стартап для монетизации трафика приложений ВКонтакте - Опыт работы в компаниях Clickberry и OneTwoTrip - Работа в Тинькофф и переход на микросервисы. - Работа в ChatterMill и позиция head of engineering - Культурные различия в менеджменте между российскими и интернациональными компаниями - Эволюция продукта и влияние LLM - Роль технического руководителя и распределение времени между менеджментом, развитием команды, текущими проектами и проработкой новых идей - Рекомендации для роста и важность любопытства Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music. #Software #Engineering #Management #Architecture #Processes

[2/2] How AI is changing software engineering at Shopify (Рубрика #AI) Если подводить итоги интервью Farhan Thawar, про которое я рассказывал раньше, то можно отметить следующие ключевые выводы 1. ИИ как мультипликатор, а не заменитель Тавар подчеркивает, что ИИ-инструменты больше помогают лучшим инженерам, чем посредственным, по аналогии с тем, как камеры смартфонов приносят больше пользы профессиональным фотографам. 2. Будущее SaaS не под угрозой Несмотря на возможность создания персонализированного ПО с помощью ИИ, Тавар не считает, что это угрожает индустрии SaaS. Он ссылается на парадокс Джевонса: чем больше возможностей появляется, тем больше их хочется использовать. 3. Важность понимания кода При внедрении ИИ в разработку Shopify требует, чтобы нетехнические сотрудники понимали генерируемый код перед отправкой PR, чтобы не перегружать инженеров чтением тысяч строк сгенерированного кода. 4. Стратегическое значение раннего внедрения Опыт Shopify показывает важность раннего экспериментирования с ИИ-инструментами и создания внутренней инфраструктуры для их безопасного использования. Компания инвестирует в ИИ как в долгосрочную стратегию, а не краткосрочную экономию затрат. В общем, это интервью демонстрирует, как крупная технологическая компания может успешно интегрировать ИИ во все аспекты деятельности, подходя к этому практично и осознанно, а не просто на волне хайпа. #AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

[1/2] How AU is changing software engineering at Shopify (Рубрика #AI) Посмотрел интересное интервью Gergely Orosz и Farhan Thawar, который руководит инженерным отделом Shopify, курирующим более 3 000 инженеров. До Shopify работал в Pivotal Labs, Xtreme Labs и был сооснователем Helpful.com, которую приобрела Shopify. Известен своим практическим подходом к руководству - например, в интервью он рассказывал как лично чининл Wi-Fi на корпоративном мероприятии:). А Gergely Orosz - автор рассылки "The Pragmatic Engineer", автор книг и спикер на конференциях (недавно я рассказывал про его выступление "Software engineering with LLMs in 2025: reality check"). Интервью получилось интересным и его ключевые идеи представлены ниже 1. Философия Shopify: парное программирование проблем Shopify придерживается подхода "нанимайте умных людей и работайте с ними в паре над проблемами", а не традиционного "нанимайте и оставьте их в покое". Тавар подчеркивает, что компания не делит сотрудников по ролям - все ожидают решения проблем независимо от должности (нельзя просто ее делегировать вниз). 2. Раннее внедрение AI-инструментов Shopify стала одной из первых компаний, использующих GitHub Copilot. В 2021 году, еще до выхода ChatGPT, Тавар лично обратился к новому CEO GitHub с просьбой о доступе к Copilot для всех инженеров Shopify. Компания получила бесплатный доступ на два года в обмен на обратную связь. 3. Диверсификация AI-инструментов Хотя Shopify традиционно предпочитает один инструмент для каждой задачи, с появлением ИИ компания изменила подход и стала использовать несколько AI-инструментов, чтобы не складывать все яйца в одну карзину - GitHub Copilot и Cursor для разработки - Claude Code для агентных рабочих процессов - Devin (его тестировали) 4. AI за пределами разработки Интересно, что Cursor активно используется не только инженерами, но и командами финансов, продаж и поддержки. Нетехнические сотрудники создают MCP-серверы для доступа к Salesforce, Google Calendar, Gmail и Slack, часто без помощи инженеров. 5. "Код Красный" - борьба с техническим долгом Shopify провела 7-месячную операцию "Код Красный" (ноябрь 2024 - июнь 2025), направив 30-50% инженеров на устранение технического долга. 6. Меморандум CEO Shopify об AI CEO Shopify Тоби Лютке издал внутренний меморандум, объявляющий использование ИИ обязательным для всех сотрудников. Ключевые положения: - Рефлекторное использование ИИ - это базовое ожидание - Перед запросом дополнительных ресурсов необходимо доказать, что ИИ не может выполнить задачу - Компетентность в области ИИ станет частью оценки эффективности 7. Инфраструктура AI в Shopify - LLM-прокси: Внутренний прокси-сервер для безопасного использования языковых моделей без утечки корпоративных данных. Включает отслеживание токенов и таблицу лидеров пользователей с наибольшим потреблением. - MCP-серверы: Более двух дюжин серверов Model Context Protocol обеспечивают доступ к внутренним данным, включая корпоративную вики "The Vault" с информацией о проектах и транскриптами презентаций. 8. Философия расходов на ИИ Shopify не ограничивает расходы на ИИ-токены. Тавар утверждает, что даже $1000 в месяц на инженера - "слишком дешево" для инструментов, повышающих продуктивность на 10%. Компания поощряет использование продвинутых моделей вместо базовых. 9. Программа стажировок Shopify планирует нанять 1000 стажеров в 2025 году, называя их "ИИ-кентаврами" - людьми, эффективно работающими с языковыми моделями. Стажировки длятся 4 месяца и требуют присутствия в офисе (Торонто, Оттава, Монреаль) для создания культуры коллективного обучения. Выводы из доклада будут в продолжении. #AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

В офисе: Большое интервью про Postgres с Олегом Бартуновым (Рубрика #Database) Посмотрел интересное интервью с Олегом Бартуновым, генеральным директором и сооснователем компании Postgres Professional, ведущим разработчиком (Major Contributor) PostgreSQL, членом сообщества PostgreSQL Foundation. Интервью брал Ваня Боталов, автор канала "Деплой". Ребята говорили больше двух часов и обсудили целую пачку тем, среди которых я бы выделил 1. Путь Олега к IT Олег начинал как астроном, но понял, что астрономия - это наука о данных. В 1990-х годах познакомился с технологией баз данных в университете UCSC, США, где узнал о PostgreSQL. С 1996 года стал активным участником сообщества PostgreSQL, но астрономом быть не перестал:) 2. Создание Postgres Professional Компания Postgres Professional была основана в 2015 году, хотя еще в 2005 году Олег написал письмо в Министерство экономики о необходимости создания российской базы данных. Тогда он ответа не получил, а лет через 10 решил взять дело в свои руки. В итоге, компания стала крупнейшим российским разработчиком СУБД на базе PostgreSQL. 3. Критика IT-образования в России Олег критикует университетское образование, которое готовит "пользователей Microsoft и Oracle", а не системных разработчиков. Он подчёркивает важность фундаментального образования и системного мышления, а не только прикладных навыков. Прикольно, что он не только критикует, но и сам работает над улучшением образования, создавая программы обучения и взаимодействуя со студентами. 4. Импортозамещение и технологическая суверенность После ухода Oracle и Microsoft из России в 2022 году появились новые возможности для роста российских СУБД. Россия показала миру, что можно жить без Oracle и Microsoft. PostgreSQL в России поднялся на передний край благодаря высоким требованиям к производительности. 5. Open Source и международное сообщество Postgres Professional занимает 2-3 место в мире по вкладу в развитие PostgreSQL. Компания активно участвует в международных конференциях, включая организацию PGConf.Nepal. Бартунов отмечает кризис в open source из-за попыток монетизации - фактически, это приводит к дрифту лицензий части продуктов в зону Шредингера, где софт оказывается в дуально открыто/закрытом состоянии:) 6. Искусственный интеллект и будущее программирования ИИ рассматривается как новая промышленная революция. Профессия программиста изменится: прикладные разработчики могут исчезнуть, но появятся новые специальности. Важно учить детей критическому мышлению и пониманию технологий. 7. Проблемы изоляции IT Изоляция мешает развитию, поскольку новые идеи рождаются в общении и конкуренции. Россия отстаёт от Америки в развитии технологий на 2-3 года. Политические факторы приводят к разделению рынков. 8.Государственная политика и развитие IT Бартунов критикует работу с министерствами, предпочитая прямое сотрудничество с университетами. Государство должно чётко определить стратегию развития IT и создать условия для возвращения специалистов. Если суммировать тезисы, c большей частью из которых я согласен, то - Россия должна развивать не только прикладное, но и системное программирование, воспитывая собственных разработчиков СУБД и другого системного ПО. - Уход западных вендоров создал возможности для роста российских IT-компаний. Postgres Pro стала примером успешного импортозамещения в области СУБД. - Качественное IT-образование должно начинаться со школы и включать фундаментальные знания, а не только изучение конкретных технологий. - Участие в международных open source проектах позволяет российским разработчикам оставаться частью глобального сообщества и развивать конкурентоспособные продукты. - Необходимо готовить новое поколение специалистов, понимающих работу с ИИ и способных адаптироваться к изменениям в профессии. В общем, мне понравилось это интервью - все четко и по делу:) #Database #Management #Leadership #Software #Engineering

Measuring developer productivity with the DX Core 4 (Рубрика #Productivity) Сегодня я хотел рассказать про фреймворк DX Core 4 для измерения продуктивности. Этот фреймворк интересен тем, что ребята из DX являются одними из законодателей мод в мире developer productivity: - Они запилили модель DevEx, которую я уже разбирал "DevEx: What Actually Drives Productivity" и "DevEx in Action" - В команду платформы входит Nicole Forsgren, которая драйвила развитие DORA метрик, была автором книги "Accelerate", приложила руку к фреймворку SPACE - Они заявляют, что DX Core 4 продолжает это светлое дело и включает в себя предыдущие их работы Забавно, что в анонсе нового фреймворка авторы говорят о том, что инженерные лидеры часто спрашивают а какой из фреймворков выбирать: DevEx, SPACE и DORA? И они решили, что ответом на этот вопрос будет новый фреймворк DX Core 4:) Этот фреймвор называется так из-за того, что он рассматривает вопрос продуктивности в четырех измерениях: speed, effectiveness, quality, impact. А теперь немного про каждую из размерностей. 1.Speed Эта размерность про то, как быстро инженеры отгружают production-ready код. Ключевая метрика здесь - "diffs per engineer", что отличается от традиционного lead time. Интересно, что на самом деле это метрика пропускной способности, а не скорости:) Ребята приняли решение сделать ее ключевой, так как она понятнее для нетехнических стейкхолдеров - условный lead time и его важность сложнее объяснить условному CEO, а вот diffs per engineer объяснять проще. Отдельно отмечу, что авторы делают акцент на том, что diffs per engineer нельзя отслеживать на индивидуальном уровне и использовать для оценки сотрудников. Вторичные метрики: lead time, deployment frequency, perceived rate of delivery 2. Effectiveness Эта размерность про то, насколько хорошо команды чувствуют процессы разработки и рабочие процессы в общем. Ключевой метрикой здесь является Developer Experience Index (DXI), которая показывает насколько процессы помогают инженерам делать их работу (создавать diffs из первой размерности). Вторичными метриками являются time to 10th PR, ease of delivery, regrettable attrition (на уровне организации) 3. Quality Эта размерность фокусируется на стабильности и надежности софта в production. Ключевая метрика change fail rate, а вторичные включают в себя failed deployment recovery time, perceived software quality, operational health and security metrics. 4. Impact Самая интересная размерность, которая предлагает оценить влияние инженеров на бизнес. Ключевая метрика - процент времени, что тратится на новые возможности (фичи в продукте). Вторичными метриками являются initiative progress & ROI, revenue per engineer (на уровне организации), процент R&D от бюджета организации Но фреймворк без инструментализации - это деньги на ветер, поэтому авторы говорят о том, что он тесно интегрирован с платформой DX, где есть - Pre-built metrics и reports — готовые отчеты для ключевых областей типа code review, delivery и output. Платформа поддерживает отображение и DORA метрик - Куча адаптеров для подтягивания данных из реп с кодом, инструментов для инцидент менеджмента, CI/CD систем и так далее. Все это сводится в унифицированный вид, который подходит для построения отчетов и принятия решений - Часть с опросами, где можно собирать обратную связь от инженеров и проводить анализ, включая sentiment analysis - Недавно ребята выкатили свой концепт для анализа эффективности AI в разработке "Measuring AI code assistants and agents" (я про него рассказывал), так что у них есть инсутрменты для анализа и этого аспекта В общем, это интересный фреймворк и платформа для его имплементации, которая позволяет оценивать developer productivity и дальше принимать решения, которые позволят его менять к лучшему. P.S. В ближайшее время я запишу два эпизода подкаста Research Insights Made Simple - С разбором этого фреймворка - С разбором фреймворка SPACE и его реализацией в Т В обоих сериях у меня будут крутые гости. Stay tuned #PlatformEngineering #Software #Processes #DevEx #Devops #Metrics

Code of Leadership (Рубрика #Management) Примерно полтора года назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 42 эпизода, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube, VK Video, Podster.fm, Ya Music. Про первые 21 выпуск я уже рассказывал раньше , а теперь хочу рассказать про вторую порцию из 21 выпуска 22) Интервью с Дмитрием Аношиным про data engineering 23) Интервью с Андреем Марченко про фронтовую разработку 24) Интервью с Константином Евтеевым про engineering management 25) Интервью с Анастасией Кабищевой про групповую динамику и модель BART 26) Интервью с Салихом Фахрутдиновым про SRE в Т-Банке 27) Интервью с Виктором Фирсовым про эволюцию развития веба Т-Банка за 12 лет 28) Интервью с Вадимом Гончаровым про дизайн в разработке софта 29) Разбор книги "Think like a CTO" с Александром Шевченко 30) Интервью с Вадимом Гончаровым про Т-Банк и подходы к менеджменту 31) Разбор книги "Hooked" с Евгением Сергеевым (SOER) 32) Интервью с Никитой Бурковым про маркетинг, продажи и X-Sell в Т-Банке 33) Интервью с Михаилом Трифоновым про internal developer platforms 34) Интервью с Александром Кивериным про стратегию 35) Интервью с Евгением Козловым про SDLC и продуктовую аналитику в Т-Банке 36) Интервью с Родионом Решетовым про аналитику и Dungeon & Dragons 37) Интервью с Борисом Чернышом про фронтовую архитектуру и надежность 38) Интервью с Дмитрием Котельниковым про платформу origination и надежность 39) Интервью с Денисом Пахомовым про социальную платформу 40) Интервью с Владимиром Лазаревым про медиа платформы и SDLC 41) Интервью с Павлом Пермяковым про Т Инвестиции и ранние дни Т-Банка 42) Интервью с Андреем Романовским про карьеру технического менеджера в большой компании #Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement