Review of "AI Engineering Book" #1 - Preface & Intro Chapter (Рубрика #AI)

Это первая серия с разбором крутой книги "AI Engineering", которая дает представление о создании gen AI приложений. Книгу разбирает Александр Поломодов, технический директор Т-Банка, а также Евгений Сергеев, engineering director в Flo.

В первой серии мы обсудили книгу в общем, а также разобрали первую главу. Если выделять крупные темы, то они сгруппированы так
- Введение в обзор книги "AI Engineering"
- Разбор структуры книги из 10 глав
- Переход от ML к Gen AI и его преимущества
- Токены и их роль в работе языковых моделей
- Мультимодальность - комбинирование текста, изображений и других модальностей
- Сентимент-анализ и модерация контента с помощью LLM
- Хайп вокруг LLM и влияние на бизнес-ожидания
- AI как ключ к эффективной стратегии развития внутренних платформ разработки (aka platform engineering)
- Анализ трендов AI проектов на GitHub
- Примеры использования в корпорациях
- Интеграция инструментов MCP и Claude Desktop
- Стоимость и качество моделей - тенденции развития
- Промт-инжиниринг и демократизация разработки

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

Эксперимент с джемом о трудностях выбора (Рубрика #Economics)

Есть такой классический эксперимент про сложность выбора, который провели и опубликаовали в whitepaper "When Choice is Demotivating: Can One Desire Too Much of a Good Thing?" 25 лет назад. Этот эксперимент часто используют для аргументации создания сервисов для помощи в выборе чего угодно. Но кажется, что стоит заглянуть внутрь эксперимента и последующих исследований на эту тему. Начнем с оригинального эксперимента с дегустацией джема в элитном продуктовом магазине.

Условия эксперимента:
- Стенд с 24 различными видами джема Wilkin & Sons
- Стенд с 6 видами джема той же марки
- Покупатели получали купон на $1 при дегустации
- Варианты проведения теста были разнесены во времени
Результаты оригинального исследования:
- 60% покупателей подходили к стенду с 24 видами джема
- 40% подходили к стенду с 6 видами
- Но только 3% покупателей купили джем после дегустации широкого ассортимента
- В то время как 30% купили джем после дегустации ограниченного выбора
Это исследование стало основой для теории "парадокса выбора" Барри Шварца и получило широкую популярность.

Этот парадокс выбора оказался горячей темой и другие ученые пытались его анализировать и/или повторять. Достаточно интересный мета-анлиз сделал Бенджамин Шайбехенне и остальные в статье "Can There Ever Be Too Many Options? A Meta-Analytic Review of Choice Overload" 2010 года. Если говорить о ключевых выводах этого метаисследования, то они такие
- Средний размер эффекта перегрузки выбора (choice overload) составил практически ноль
- Обнаружена значительная вариативность между исследованиями
- Не удалось идентифицировать достаточные условия для возникновения перегрузки выбора
- Многие попытки репликации оригинального эксперимента с джемом не увенчались успехом

Дальше эту тему продолжали исследолать и стало ясно, что на эффект choice overload влияли следующие факторы
- Тип решения и сложность опций
- Наличие четких предпочтений у потребителей
- Контекст принятия решения (например, давление по времени)
- Индивидуальные различия между принимающими решения

Кстати, метаанализ выявил, что больше выбора явно полезнее:
- Когда потребители имеют четко определенные предпочтения
- При выборе количества потребления (size, quantity, ...)
- В ситуациях, где дополнительные опции воспринимаются как релевантные и различимые

В итоге, если вам рассказывают эксперимент про джем и говорят про сложность выбора, то знайте, что современное понимание предполагает, что влияние количества выбора на поведение потребителей гораздо более сложное и контекстно-зависимое, чем предполагалось изначально. Простая формула "меньше выбора = больше покупок" оказалась слишком упрощенной для объяснения реального поведения потребителей

#Economics #Brain #Psychology #Management

Software engineering with LLMs in 2025: reality check (Рубрика #AI)

Посмотрел интересное выступление Gergely Orosz, инженера и автора рассылки "The Pragmatic Engineer" на Substack и автора книги "The Software Engineer's Guidebook". Он выступал с этим докладом на конференции LDX3 (LeadDev London) 16 июня 2025 года, крупнейшем фестивале engineering leadership, где было 2000 участников. Кстати, я недавно рассказывал про отчет "Engineering Leadership Report 2025" от этой компании LeadDev. Но если возвращаться к самому докладу, то ниже саммари его ключевых идей

1. Orosz провел качественное исследование для анализа реальной ситуации с Gen AI. Он решил заняться этим, так как существует большой разрыв между оптимистичными заявлениями CEO крупных компаний: Microsoft CEO утверждает, что 30% кода пишется ИИ, Anthropic CEO прогнозирует 90% ИИ-кода через год (я рассказывал про это выступление) и реальными проблемами на практике, включая дорогостоящие ошибки AI-инструментов и неудачные публичные демонстрации. Для этого Orosz решил опросить лично инженеров из разных контекстов

Стартапы, что делают AI инструменты
- Инженеры Anthropic говорят, что 90% их продукта Claude Code написано с использованием его же самого
- Инженеры Windsurf заявляют о 95% кода, написанного с их помощью
- Инженеры Cursor дают более осторожные оценки - около 40-50% успешности

Big Tech компании
- Google: Используют собственную IDE Cider с интегрированными LLM-инструментами. SRE внутри готовятся к 10-кратному увеличению количества строк кода в production, расширяя инфраструктуру и review tooling.
- Amazon: Почти все разработчики используют Amazon Q Developer Pro, особенно для AWS-разработки. Amazon становится пионером MCP и большинство внутренних инструментов уже имеют MCP support, что позволяет автоматизировать множество рабочих процессов.

AI стартапы (но не те, что делают сам тулинг)
Смешанные результаты. Например, incident.io активно использует AI для ускорения работы команды и делится практиками в Slack. Однако биотехнологический стартап сообщил, что LLM не прижились - быстрее писать корректный код самостоятельно, чем проверять и исправлять AI-код.

Опытные инженеры (independent software engineers)
- Armin Ronacher (создатель Flask): после 17 лет кодирования снова воодушевлен благодаря Claude Code, считает что "AI меняет всё"
- Peter Steinberger (создатель PSPDFKit): отмечает, что языки и фреймворки стали менее важными благодаря AI-инструментам
- Simon Willison (создатель Django): подтверждает, что coding agents действительно работают, и улучшения моделей за последние 6 месяцев стали переломным моментом

Мнения легенд индустрии
- Martin Fowler сравнил появление LLM с переходом от ассемблера к языкам высокого уровня - такой же революционный прирост производительности, но впервые с недетерминированными инструментами.
- Kent Beck: "Я получаю больше удовольствия от программирования, чем когда-либо за 52 года". Он сравнивает влияние LLM с микропроцессорами (1970s), интернетом (2000s) и смартфонами (2010s).

Если говорить про статистику, что собирается через опросы, то по данным опросов платформы DX (я недавно разбирал их отчет "Measuring AI code assistants and agents")
- В среднем 50% разработчиков в организациях используют AI-инструменты еженедельно, в топовых компаниях — до 60%.
- Экономия времени составляет 3-5 часов в неделю, что далеко от заявленных 10-20x improvements
Эти результаты опросов показывают результаты, что отличаются от воодушевления CEO крупных компаний. Но можно заметить, что опытные независимые инженеры воодушевлены этим тулингом - Orosz считает, что текущие AI-инструменты пока лучше работают для индивидуальных разработчиков, чем для команд внутри крупных компаний.

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

#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops

Fei-Fei Li: Spatial Intelligence is the Next Frontier in AI (Рубрика #AI)

Посмотрел интересный доклад Фей-Фей Ли, которая широко известна как «крёстная мать ИИ» (Godmother of AI). . Она известна прежде всего как создатель ImageNet — революционного проекта, который заложил основы современного глубокого обучения. В 2017-2018 годах работала в Google Cloud в качестве главного научного сотрудника по AI/ML. А сейчас она является профессором компьютерных наук в Стэнфордском университете и соучредителем Stanford Institute for Human-Centered AI. В 2024 году Фей-Фей Ли основала стартап World Labs и эта компания занимается разработкой пространственного интеллекта и привлекла $230 млн инвестиций, достигнув оценки свыше $1 млрд. По-факту, ребята делают свой тип моделей Large World Models (LWMs), которые способны воспринимать, генерировать и взаимодействовать с трёхмерным миром. Ниже представлены ключевые идеи выступления

1. История создания ImageNet
Фей-Фей Ли рассказала о зарождении ImageNet в 2007 году, когда она была ассистентом профессора в Принстоне. В то время в области компьютерного зрения катастрофически не хватало данных, алгоритмы работали плохо, и индустрии практически не существовало. Её команда приняла смелое решение создать беспрецедентный датасет, загрузив миллиард изображений из интернета для создания всемирной визуальной таксономии
2. Прорыв 2012 года: AlexNet
Переломный момент наступил в 2012 году, когда команда под руководством Джеффри Хинтона представила AlexNet — сверточную нейронную сеть, которая кардинально превзошла все существующие алгоритмы в ImageNet Challenge. Это событие положило начало революции глубокого обучения, объединив три ключевых компонента: данные (ImageNet), алгоритмы (CNN) и вычислительную мощность (GPU)
3. Эволюция компьютерного зрения
Фей-Фей Ли проследила эволюцию от распознавания объектов к описанию сцен. Работая с учениками, включая Andrej Karpathy, она добилась создания алгоритмов, способных описывать целые сцены — мечты, которую она считала задачей на всю жизнь. К 2015 году команда опубликовала работы по автоматическому созданию подписей к изображениям.
4. Пространственный интеллект как новый рубеж
Фей-Фей Ли обосновала важность пространственного интеллекта через эволюционную перспективу. Развитие человеческого языка заняло менее 500 тысяч лет, в то время как зрение развивалось 540 миллионов лет, начиная с первых трилобитов. Именно зрение запустило эволюционную гонку вооружений, сделав животных более сложными и интеллектуальными.
5. Сложность пространственного интеллекта
Фей-Фей Ли объяснила, почему пространственный интеллект сложнее языковых моделей
- Язык одномерен - слова идут в последовательности, тогда как реальный мир трёхмерен (или четырёхмерен с учётом времени)
- Язык чисто генеративен - он создаётся в головах людей, в то время как физический мир подчиняется законам физики
- Визуальное восприятие - это всегда проекция 3D в 2D, что создаёт математически интересную задачу
- Данные о пространственном интеллекте менее доступны по сравнению с языковыми данными в интернете

Если подводить итоги, то Фей-Фей Ли считает, что
- AGI невозможно без пространственного интеллекта - это фундаментальная проблема для достижения искусственного общего интеллекта
- Пространственный интеллект имеет широкие применения: от создания контента (дизайнеры, архитекторы, разработчики игр) до робототехники и метавселенных
- Ключевое качество для успеха в области ИИ - это отсутствие страха перед сложными задачами (intellectual fearless), которое Фей-Фей Ли ищет в студентах и сотрудниках
- Междисциплинарный подход критически важен для будущих исследований в области ИИ, особенно для научных открытий
- Открытый исходный код должен защищаться как важная составляющая предпринимательской экосистемы

Фей-Фей Ли считает, что пространственный интеллект представляет собой безумно сложный вызов, возможно, самый сложный в современном ИИ, но ей привычно решать задачи такого масштаба.

#AI #ML #Management #Leadership #Architecture

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

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

В офисе: Большое интервью про 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

[1/2] How AI 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

[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

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