Валерий Стромов: от стажёра до CEO Алисы за 9 лет (Рубрика #Management)
Интересное интервью Валерия Стромова, 29-летнего CEO Алисы и умных устройств Яндекса, который пришёл в Яндекс в 2016 году стажёром-разработчиком в возрасте 20 лет, а к 2025 году возглавил команду из более чем 700 человек. Интервью берут двое ведущих подкаста "Это моя работа": Дарья Золотухина, HR-директор Яндекса, одна из ведущих подкаста, и Никита Толстой, который в команде Я Маркета отвечает за пользовательский опыт и технологии логистики. Интервью показалось мне интересным как с точки зрения гостя и его стремительной карьеры, а также некоторых идей, которыми он поделился на подкасте
1. Путь от стажёра к CEO
Валерий рассказал о своём необычном карьерном пути, который начался с увлечения программированием ещё в четвёртом классе. Ключевым моментом стало знакомство с олимпиадным программированием через сайт Codeforces в седьмом классе. Интересно, что в Яндекс он попал случайно - увидел рекламный баннер на Яндекс.Погоде и подал заявку на стажировку, приложив вместо резюме простой текстовый файл со словами «Я олимпиадник»
2. Видение универсального ИИ-ассистента
Валерий представил амбициозное видение будущего Алисы - создание универсального искусственного интеллекта, который выйдет за рамки чатовых интерфейсов и станет полноценным помощником в физическом мире. Этот ассистент будет способен выполнять сложные аналитические задачи за минуты, которые сейчас требуют дней работы специалистов
3. Эмоциональный синтез и эмпатия
Одним из главных технических вызовов команды Валерия является разработка технологий эмоционального синтеза. Алиса должна научиться понимать эмоции пользователя по акустическим токенам и подстраиваться под его настроение. Это означает, что виртуальный ассистент сможет не только обрабатывать текст, но и воспринимать интонацию, эмоциональное состояние и реагировать соответствующим образом. Это, кстати, было для меня интересной мыслью - раньше я адаптацию ассистента под настроение человека не особо учитывал в своих размышлениях.
4. Философия менеджмента
Валерий рассказал про свою философиею лидерства, подчеркнув важность постановки амбициозных целей с временными ограничениями. Он считает, что команды должны отказаться от чрезмерной осторожности и научиться принимать решения в условиях неопределённости. Ключевым принципом является создание атмосферы, где "даже внутри компании технологии выглядят как волшебство". Могу отметить, что мне самому не хватает аппетита к риску и это зачастую меня тормозит :(
5. Найм сотрудников
Валерий поделился двумя критериями при найме
- Искренняя заинтересованность в работе - способность кандидата увлечься проектом настолько, что готов работать сверхурочно не по принуждению, а по внутренней мотивации
- Любознательность - постоянное стремление к изучению нового, способность привести примеры того, что человек освоил в последние недели или месяцы
6. Роль менеджера
По мнению Валерия, тезис о том, что хорошие менеджеры просто "собирают команду лучших и не мешают им работать" - это миф. Он подчеркнул, что менеджер должен определять цели, стратегию, мотивировать команду и создавать эффективные процессы
7. Культура инноваций
Здесь Валерий рассказал про концепт "working backwards", что был популяризирован Amazon и про который можно почитать книгу "Working Backwards: Insights, Stories, and Secrets from Inside Amazon", о которой я уже рассказывал.
8. Про Алису и ее будущее
Валерий считает, что Алиса должна стать не просто голосовым помощником, а полноценным универсальным ассистентом с эмпатией, способным понимать контекст, эмоции и решать сложные задачи в различных сферах жизни. Это соответствует недавним обновлениям Алисы, включающим режим рассуждений, работу с файлами и свободное общение на английском языке
В общем, этот эпизод подкаста получился интересным, посмотрим что будет дальше.
#AI #Leadership #Management #Engineering #ML #Agents #Software
Интересное интервью Валерия Стромова, 29-летнего CEO Алисы и умных устройств Яндекса, который пришёл в Яндекс в 2016 году стажёром-разработчиком в возрасте 20 лет, а к 2025 году возглавил команду из более чем 700 человек. Интервью берут двое ведущих подкаста "Это моя работа": Дарья Золотухина, HR-директор Яндекса, одна из ведущих подкаста, и Никита Толстой, который в команде Я Маркета отвечает за пользовательский опыт и технологии логистики. Интервью показалось мне интересным как с точки зрения гостя и его стремительной карьеры, а также некоторых идей, которыми он поделился на подкасте
1. Путь от стажёра к CEO
Валерий рассказал о своём необычном карьерном пути, который начался с увлечения программированием ещё в четвёртом классе. Ключевым моментом стало знакомство с олимпиадным программированием через сайт Codeforces в седьмом классе. Интересно, что в Яндекс он попал случайно - увидел рекламный баннер на Яндекс.Погоде и подал заявку на стажировку, приложив вместо резюме простой текстовый файл со словами «Я олимпиадник»
2. Видение универсального ИИ-ассистента
Валерий представил амбициозное видение будущего Алисы - создание универсального искусственного интеллекта, который выйдет за рамки чатовых интерфейсов и станет полноценным помощником в физическом мире. Этот ассистент будет способен выполнять сложные аналитические задачи за минуты, которые сейчас требуют дней работы специалистов
3. Эмоциональный синтез и эмпатия
Одним из главных технических вызовов команды Валерия является разработка технологий эмоционального синтеза. Алиса должна научиться понимать эмоции пользователя по акустическим токенам и подстраиваться под его настроение. Это означает, что виртуальный ассистент сможет не только обрабатывать текст, но и воспринимать интонацию, эмоциональное состояние и реагировать соответствующим образом. Это, кстати, было для меня интересной мыслью - раньше я адаптацию ассистента под настроение человека не особо учитывал в своих размышлениях.
4. Философия менеджмента
Валерий рассказал про свою философиею лидерства, подчеркнув важность постановки амбициозных целей с временными ограничениями. Он считает, что команды должны отказаться от чрезмерной осторожности и научиться принимать решения в условиях неопределённости. Ключевым принципом является создание атмосферы, где "даже внутри компании технологии выглядят как волшебство". Могу отметить, что мне самому не хватает аппетита к риску и это зачастую меня тормозит :(
5. Найм сотрудников
Валерий поделился двумя критериями при найме
- Искренняя заинтересованность в работе - способность кандидата увлечься проектом настолько, что готов работать сверхурочно не по принуждению, а по внутренней мотивации
- Любознательность - постоянное стремление к изучению нового, способность привести примеры того, что человек освоил в последние недели или месяцы
6. Роль менеджера
По мнению Валерия, тезис о том, что хорошие менеджеры просто "собирают команду лучших и не мешают им работать" - это миф. Он подчеркнул, что менеджер должен определять цели, стратегию, мотивировать команду и создавать эффективные процессы
7. Культура инноваций
Здесь Валерий рассказал про концепт "working backwards", что был популяризирован Amazon и про который можно почитать книгу "Working Backwards: Insights, Stories, and Secrets from Inside Amazon", о которой я уже рассказывал.
8. Про Алису и ее будущее
Валерий считает, что Алиса должна стать не просто голосовым помощником, а полноценным универсальным ассистентом с эмпатией, способным понимать контекст, эмоции и решать сложные задачи в различных сферах жизни. Это соответствует недавним обновлениям Алисы, включающим режим рассуждений, работу с файлами и свободное общение на английском языке
В общем, этот эпизод подкаста получился интересным, посмотрим что будет дальше.
#AI #Leadership #Management #Engineering #ML #Agents #Software
YouTube
Валерий Стромов: от стажёра до CEO Алисы за 9 лет
Гость нашего первого выпуска Валерий Стромов пришёл в Яндекс стажёром, а теперь руководит командой Алисы из более 700 человек. Он называет себя техно-оптимистом и верит, что совсем скоро у его команды получится превратить умные устройства в полноценных ассистентов…
👎19❤8🔥6👍4
[1/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)
Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него писать - методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Но я поменял свое мнение после того, как посыпались заголовки в стиле "Учёный изнасиловал журналиста" и дальше падкие на громкие заголовки люди начали присылать это исследование с аргументацией "вот они доказательства: усы, лапы и хвост".
После этого я пошел и прочитал не только краткую выжимку с сайта METR (Model Evaluation & Threat Research), но и все 50 страниц основного whitepaper, где авторы описали всю методологию эксперимента, свои мысли о результатах и их причинах (конечно, без стат значимости) и даже инструкции для участников экспериментов. Дальше я поделюсь своими мыслями насчет этого эксперимента.
Начнем с того, почему это исследование получило столько внимания и тут есть несколько причин
1. Противоречие общепринятому мнению
Результаты исследования прямо противоречат широко распространенному убеждению о том, что AI-инструменты неизбежно повышают продуктивность разработчиков. Исследование показало, что AI-инструменты фактически замедляют опытных разработчиков на 19%, что стало шокирующим открытием даже для самих авторов.
2. Методологическая точность
Авторы провели исследование используя рандомизированные контролируемые испытания (фактически, a/b тест) для оценки реального влияния AI на продуктивность разработчиков в их обычной рабочей среде. Исследование отличается от предыдущих работ использованием фиксированных задач и опытных разработчиков, работающих в знакомых кодовых базах. Правда, тут участники знали про сам эксперимент, а значит мог проявляться эффект Хоторна
3. Актуальность для индустрии
Результаты исследований про влияние AI имеют огромное значение для оценки многомиллиардных инвестиций в AI-инструменты для разработки. Предыдущие исследования по другому подходили к оценке эффекта и все поголовно показывали увеличение продуктивности. А это исследование поднимает вопросы о реальной окупаемости инвестиций в AI-инструменты разработки.
Продолжим тем, а почему нам стоит доверять исследователям из METR.
Начать надо с того, что METR - это некоммерческая исследовательская организация, специализирующаяся на оценке возможностей фронтирных AI-систем и их потенциальных рисков. Организация работает с ведущими AI-компаниями, включая OpenAI и Anthropic, и сотрудничает с государственными институтами AI-безопасности. В группу исследователей входили технические сотрудники Joel Becker, Nate Rush, David Rein, а также Beth Barnes - основатель и главный исследователь METR, бывший исследователь OpenAI и DeepMind, ведущий эксперт по AI-безопасности и оценке AI-систем.
И как же выглядела методология рандомизированных контролируемых испытаний?
- Участвовали 16 опытных разработчиков open-source проектов со средним опытом работы с репозиториями 5 лет и 1500 коммитов в среднем.
- Решали они 246 реальных задач из крупных open-source репозиториев (в среднем 23,000 звезд, 1,100,000 строк кода).
- Дизайн эксперимента предполагал, что каждая задача случайным образом назначалась в одну из двух групп
-- AI-разрешенная группа: разработчики могли использовать любые AI-инструменты (преимущественно Cursor Pro с Claude 3.5/3.7 Sonnet)
-- AI-запрещенная группа: использование генеративного AI запрещено
- Измерялось время выполнения задачи, что разработчики отслеживали самостоятельно. Дополнительно собирались записи экрана, интервью и детальная аналитика использования AI.
- Помимо этого все задачи проходили стандартный процесс code review и должны были соответствовать высоким стандартам качества репозиториев.
Про результаты и почему его результаты надо воспринимать с осторожностью я расскажу в продолжении.
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes
Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него писать - методология мне показалось хоть и интересной, но объем выборки аж в 16 инженеров казался мне маловатым для того, чтобы делать громкие заявления о замедлении разработки. Но я поменял свое мнение после того, как посыпались заголовки в стиле "Учёный изнасиловал журналиста" и дальше падкие на громкие заголовки люди начали присылать это исследование с аргументацией "вот они доказательства: усы, лапы и хвост".
После этого я пошел и прочитал не только краткую выжимку с сайта METR (Model Evaluation & Threat Research), но и все 50 страниц основного whitepaper, где авторы описали всю методологию эксперимента, свои мысли о результатах и их причинах (конечно, без стат значимости) и даже инструкции для участников экспериментов. Дальше я поделюсь своими мыслями насчет этого эксперимента.
Начнем с того, почему это исследование получило столько внимания и тут есть несколько причин
1. Противоречие общепринятому мнению
Результаты исследования прямо противоречат широко распространенному убеждению о том, что AI-инструменты неизбежно повышают продуктивность разработчиков. Исследование показало, что AI-инструменты фактически замедляют опытных разработчиков на 19%, что стало шокирующим открытием даже для самих авторов.
2. Методологическая точность
Авторы провели исследование используя рандомизированные контролируемые испытания (фактически, a/b тест) для оценки реального влияния AI на продуктивность разработчиков в их обычной рабочей среде. Исследование отличается от предыдущих работ использованием фиксированных задач и опытных разработчиков, работающих в знакомых кодовых базах. Правда, тут участники знали про сам эксперимент, а значит мог проявляться эффект Хоторна
3. Актуальность для индустрии
Результаты исследований про влияние AI имеют огромное значение для оценки многомиллиардных инвестиций в AI-инструменты для разработки. Предыдущие исследования по другому подходили к оценке эффекта и все поголовно показывали увеличение продуктивности. А это исследование поднимает вопросы о реальной окупаемости инвестиций в AI-инструменты разработки.
Продолжим тем, а почему нам стоит доверять исследователям из METR.
Начать надо с того, что METR - это некоммерческая исследовательская организация, специализирующаяся на оценке возможностей фронтирных AI-систем и их потенциальных рисков. Организация работает с ведущими AI-компаниями, включая OpenAI и Anthropic, и сотрудничает с государственными институтами AI-безопасности. В группу исследователей входили технические сотрудники Joel Becker, Nate Rush, David Rein, а также Beth Barnes - основатель и главный исследователь METR, бывший исследователь OpenAI и DeepMind, ведущий эксперт по AI-безопасности и оценке AI-систем.
И как же выглядела методология рандомизированных контролируемых испытаний?
- Участвовали 16 опытных разработчиков open-source проектов со средним опытом работы с репозиториями 5 лет и 1500 коммитов в среднем.
- Решали они 246 реальных задач из крупных open-source репозиториев (в среднем 23,000 звезд, 1,100,000 строк кода).
- Дизайн эксперимента предполагал, что каждая задача случайным образом назначалась в одну из двух групп
-- AI-разрешенная группа: разработчики могли использовать любые AI-инструменты (преимущественно Cursor Pro с Claude 3.5/3.7 Sonnet)
-- AI-запрещенная группа: использование генеративного AI запрещено
- Измерялось время выполнения задачи, что разработчики отслеживали самостоятельно. Дополнительно собирались записи экрана, интервью и детальная аналитика использования AI.
- Помимо этого все задачи проходили стандартный процесс code review и должны были соответствовать высоким стандартам качества репозиториев.
Про результаты и почему его результаты надо воспринимать с осторожностью я расскажу в продолжении.
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes
arXiv.org
Measuring the Impact of Early-2025 AI on Experienced Open-Source...
Despite widespread adoption, the impact of AI tools on software development in the wild remains understudied. We conduct a randomized controlled trial (RCT) to understand how AI tools at the...
❤7🔥4👍3
[2/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)
Продолжая пост про исследование, расскажу про полученные результаты
- Было получено статистически значимое замедление на 19% при использовании AI-инструментов с 95% доверительным интервалом
- Авторы отдельно указали на ограничения обобщаемости этих выводов
-- Опыт разработчиков. Результаты специфичны для опытных разработчиков (5+ лет опыта с репозиториями). Для менее опытных разработчиков результаты могут быть противоположными.
-- Размер и сложность кодовых баз. Исследование проводилось на крупных, зрелых проектах (1M+ строк кода). На меньших или новых проектах AI может показать положительный эффект.
-- Знакомство с проектом. Разработчики работали в знакомых им репозиториях.
-- Тип задач. Задачи уже были декомпозированы до размера не больше 2х часов, что может не отражать весь спектр разработческих задач.
-- Внешняя валидность. Результаты не означают, что AI-инструменты бесполезны во всех контекстах разработки.
По результатам авторы сдели следующие выводы
1. AI-инструменты замедляют опытных разработчиков на 19% при работе в знакомых кодовых базах, что противоречит ожиданиям как разработчиков (предсказывали ускорение на 24%), так и экспертов (предсказывали ускорение на 38-39%).
2. Также они поразмышляли насчет факторов замедления, выделив 5 основных, хотя и сделали такую ремарку
Вот эти факторы
- Чрезмерный оптимизм относительно полезности AI
- Высокая знакомость разработчиков с репозиториями
- Большие и сложные кодовые базы
- Низкая надежность AI (принимается <44% предложений)
- Неявный контекст репозиториев, недоступный AI
В итоге, авторы подчеркивают, что результаты не означают, что AI-инструменты бесполезны.
А теперь поговорим про проблемы исследования и почему его результаты надо воспринимать с осторожностью
1. Малый размер выборки
Только 16 разработчиков, что ограничивает статистическую мощность, а также ставит под вопрос репрезентативность выборки относительно генеральной совокупности. Сетап эксперимента не позволил ответить на вопросы, какие факторы повлияли на результаты
2. Краткосрочность
Исследование не учитывает долгосрочные эффекты обучения использованию AI-инструментов.
3. Специфичность контекста
Были выбраны крупные open source репозитории, что говорит о том, что результаты могут не обобщаться на другие типы проектов по размеру или специфике (web, мобильная разработка)
4. Эффект Хоторна
Участники знали о том, что участвуют в исследовании, что могло влиять на их поведение.
5. Субъективность измерений
Время выполнения задач измерялось самими разработчиками, что могло вносить систематические ошибки.
6. Определение продуктивности
Исследование фокусировалось только на времени выполнения, не учитывая другие аспекты продуктивности: качество кода (главное было пройти code review), удовлетворенность работой
Итого, мне кажется сам эксперимент интересным, но я больше верю в измерения практических эффектов в организациях, где есть измерение developer productivity и AI там добавляется в экосистему разработчиков постепенно и через a/b эксперименты на большом масштабе, которые позволяют отследить эффекты. Конкретно, про такие подходы можно почиитать в постах
- Про Google и их подходы из серии статей "Developer Productivity for Humans" (подробнее в постах: 1 и 2)
- Про подход запрещенной в России компании Meta, который они описали в статье "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (подробнее в постах: 1, 2 и 3)
- Ну или на крайний случай можно глянуть мое выступление "Зачем заниматься темой developer productivity в большой компании"
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes
Продолжая пост про исследование, расскажу про полученные результаты
- Было получено статистически значимое замедление на 19% при использовании AI-инструментов с 95% доверительным интервалом
- Авторы отдельно указали на ограничения обобщаемости этих выводов
-- Опыт разработчиков. Результаты специфичны для опытных разработчиков (5+ лет опыта с репозиториями). Для менее опытных разработчиков результаты могут быть противоположными.
-- Размер и сложность кодовых баз. Исследование проводилось на крупных, зрелых проектах (1M+ строк кода). На меньших или новых проектах AI может показать положительный эффект.
-- Знакомство с проектом. Разработчики работали в знакомых им репозиториях.
-- Тип задач. Задачи уже были декомпозированы до размера не больше 2х часов, что может не отражать весь спектр разработческих задач.
-- Внешняя валидность. Результаты не означают, что AI-инструменты бесполезны во всех контекстах разработки.
По результатам авторы сдели следующие выводы
1. AI-инструменты замедляют опытных разработчиков на 19% при работе в знакомых кодовых базах, что противоречит ожиданиям как разработчиков (предсказывали ускорение на 24%), так и экспертов (предсказывали ускорение на 38-39%).
2. Также они поразмышляли насчет факторов замедления, выделив 5 основных, хотя и сделали такую ремарку
However, we strongly caution against over-indexing on the basis of any individual pieces of evidence, as we are not powered for statistically significant multiple comparisons when subsetting our data. This analysis is intended to provide speculative, suggestive evidence about the mechanisms behind slowdown.
Вот эти факторы
- Чрезмерный оптимизм относительно полезности AI
- Высокая знакомость разработчиков с репозиториями
- Большие и сложные кодовые базы
- Низкая надежность AI (принимается <44% предложений)
- Неявный контекст репозиториев, недоступный AI
В итоге, авторы подчеркивают, что результаты не означают, что AI-инструменты бесполезны.
А теперь поговорим про проблемы исследования и почему его результаты надо воспринимать с осторожностью
1. Малый размер выборки
Только 16 разработчиков, что ограничивает статистическую мощность, а также ставит под вопрос репрезентативность выборки относительно генеральной совокупности. Сетап эксперимента не позволил ответить на вопросы, какие факторы повлияли на результаты
2. Краткосрочность
Исследование не учитывает долгосрочные эффекты обучения использованию AI-инструментов.
3. Специфичность контекста
Были выбраны крупные open source репозитории, что говорит о том, что результаты могут не обобщаться на другие типы проектов по размеру или специфике (web, мобильная разработка)
4. Эффект Хоторна
Участники знали о том, что участвуют в исследовании, что могло влиять на их поведение.
5. Субъективность измерений
Время выполнения задач измерялось самими разработчиками, что могло вносить систематические ошибки.
6. Определение продуктивности
Исследование фокусировалось только на времени выполнения, не учитывая другие аспекты продуктивности: качество кода (главное было пройти code review), удовлетворенность работой
Итого, мне кажется сам эксперимент интересным, но я больше верю в измерения практических эффектов в организациях, где есть измерение developer productivity и AI там добавляется в экосистему разработчиков постепенно и через a/b эксперименты на большом масштабе, которые позволяют отследить эффекты. Конкретно, про такие подходы можно почиитать в постах
- Про Google и их подходы из серии статей "Developer Productivity for Humans" (подробнее в постах: 1 и 2)
- Про подход запрещенной в России компании Meta, который они описали в статье "What's DAT? Three Case Studies of Measuring Software Development Productivity at Meta With Diff Authoring Time" (подробнее в постах: 1, 2 и 3)
- Ну или на крайний случай можно глянуть мое выступление "Зачем заниматься темой developer productivity в большой компании"
#AI #ML #Management #Leadership #Software #SoftwareDevelopment #Architecture #Metrics #Devops #Processes
Telegram
Книжный куб
[1/2] Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Рубрика #AI)
Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него…
Я достаточно оперативно познакомился с этим whitepaper, где показано замедление разработчиков при использовании AI. Но изначально я не хотел про него…
❤5👍3🔥3
Tech Lead в AI-команду (Рубрика #AI)
Мы в Т-Банке разрабатываем крутой стартап на стыке Generative AI и финтеха, в котором создаем AI-сотрудника, полностью автономного оператора поддержки. Сейчас у нас есть автономно работающий агент, который уже обрабатывает реальные обращения с прода на небольшом сегменте. Это крутая возможность для staff инженера проявить себя в продукте, который включает в себя передовые технологии. Тут нужен крутой технарь примерно такой, какого я описывал во время круглого стола про техлидов и IC высокго грейда на Techlead Conf. Ну а для того, чтобы иметь возможность претендовать на эту позицию хорошо бы знать то, как строятся AI приложения хотя бы на уровне знаний книги "AI Engineering", которую я начал разбирать с Евгением Сергеевым из Flo Health и уже выпустил пару серий подкаста: 1 и 2.
В общем, если вам нравится быть на передовом краю технологий и руками создавать будущее, то пишите моему коллеге, Антону Скогореву (@skogorev).
#AI #Engineering #Staff #Leadership #ML #Data #Software
Мы в Т-Банке разрабатываем крутой стартап на стыке Generative AI и финтеха, в котором создаем AI-сотрудника, полностью автономного оператора поддержки. Сейчас у нас есть автономно работающий агент, который уже обрабатывает реальные обращения с прода на небольшом сегменте. Это крутая возможность для staff инженера проявить себя в продукте, который включает в себя передовые технологии. Тут нужен крутой технарь примерно такой, какого я описывал во время круглого стола про техлидов и IC высокго грейда на Techlead Conf. Ну а для того, чтобы иметь возможность претендовать на эту позицию хорошо бы знать то, как строятся AI приложения хотя бы на уровне знаний книги "AI Engineering", которую я начал разбирать с Евгением Сергеевым из Flo Health и уже выпустил пару серий подкаста: 1 и 2.
В общем, если вам нравится быть на передовом краю технологий и руками создавать будущее, то пишите моему коллеге, Антону Скогореву (@skogorev).
#AI #Engineering #Staff #Leadership #ML #Data #Software
Т‑Банк
Техлид в AI-команду. Вакансии Т‑Банка
Техлид в AI-команду — вакансии Т‑Банка. Карьера в крупной ИТ-компании, прозрачная система развития
🔥12❤6👍3
Дискуссия: RnD на стероидах: вычислительная революция, AI-агенты с суперпамятью и новая эра кибербезопасности (Рубрика #AI)
Появилась расшифровка дискуссии на Conversations, в которой я участвовал месяц назад. Тогда мы говорили о скорости изменений в индустрии и методах отслеживания важных технологических релизов, перспективах вычислительной революции, альтернативах NVIDIA и безопасности LLM, подходах к вайбкодингу в разработке и кейсах применения AI-ассистентов. Для этого обсуждения мы собрались компанией джентельменов
- Илья Карев - Team Lead GenAI Solutions, Just AI
- Сергей Марков - популяризатор науки, директор по развитию технологий искусственного интеллекта SberAI
- Олег Королев - руководитель разработки AI Lab, Авито
- Евгений Кокуйкин - сооснователь Raft и SeoHive Trace
- Александр Поломодов - технический директор, Т-Банк
#AI #Engineering #Software #Processes #Management #RnD
Появилась расшифровка дискуссии на Conversations, в которой я участвовал месяц назад. Тогда мы говорили о скорости изменений в индустрии и методах отслеживания важных технологических релизов, перспективах вычислительной революции, альтернативах NVIDIA и безопасности LLM, подходах к вайбкодингу в разработке и кейсах применения AI-ассистентов. Для этого обсуждения мы собрались компанией джентельменов
- Илья Карев - Team Lead GenAI Solutions, Just AI
- Сергей Марков - популяризатор науки, директор по развитию технологий искусственного интеллекта SberAI
- Олег Королев - руководитель разработки AI Lab, Авито
- Евгений Кокуйкин - сооснователь Raft и SeoHive Trace
- Александр Поломодов - технический директор, Т-Банк
#AI #Engineering #Software #Processes #Management #RnD
Хабр
Дискуссия: RnD на стероидах: вычислительная революция, AI-агенты с суперпамятью и новая эра кибербезопасности
Технические дискуссии на Conversations — это про глубокое погружение в происходящее на рынке, про попытки нащупать настоящие болевые точки индустрии, задать неудобные вопросы и услышать честные...
🔥6❤5👍3
Netflix's Big Bet: One model to rule recommentdations (AI)
Посмотрел вчера интересное выступление Есу Фэна (Yesu Feng) из Netflix про использование генеративных foundation-моделей для персональных рекомендаций. Кстати, Yesu Feng до прихода в Netflix работал в LinkedIn над лентой новостей и в Uber над оптимизацией маркетплейса. Я выделил для себя следующие ключевые идеи
1. Единая foundation-модель для всей системы рекомендаций
Вместо множества специализированных моделей (для разных страниц, жанров, форматов контента) Netflix переходит к одной "базовой" автогрессивной трансформер-модели, способной охватить все варианты использования.
2. Масштабирование как основной драйвер качества
Они пришли к этому сформулировав две достаточно логичные гипотезы
- При увеличении объёма данных и параметров модели персонализация улучшается по тем же законам масштабирования, что и у LLM.
- Интеграция этой модели во все подсистемы создаёт синергетический эффект и ускоряет инновации.
3. Особенности данных и обучения
В итоге, модель получилась многоуровневая
- На базовом уровне ребята делали event representation: when, where (locale & device & canvas), what (action type & entity & duration related)
- Дальше был уровень embedding/feature transformation - тут надо было объединять id embedding и дополнительные semantic embeddings, чтобы решать проблему холодного старта (например, новый контент)
- Следующий уровень содержал transformer/attention - hidden state layers отсюда использовались в качестве user representation, надо было гарантировать стабильность репрезантации пользователей, также надо было уметь явно адаптироваться под разные цели пользователей, также надо было понять как агрегрировать разные уровни и разные sequence для получения этой репрезентации
- На верхнем уровне располагалась objective loss function, которая была сложной - так как на выходе LLM было несколько последовательнотельностей (sequences) - это давало мультизадачностью на уровне функции потерь (предсказание типа действия, длительности сеанса, устройства и пр.)
-- main objective: entity id
-- auxiliary objectives: action types, entity metadate, duration, device, time
-- reward, weight & mask
4. Уроки из мира LLM
При построении LLM модели ребята набили ряд шишек и они поделились ими
- Многотокенное предсказание для повышения устойчивости к временным сдвигам и фокусировки на долгосрочном поведении.
- Многослойное представление и самодистилляция для стабильности эмбеддингов пользователя.
- Обработка длинных контекстных окон через прогрессивное увеличение длины и разреженное внимание.
5. Сценарии применения foundation-модели
Они пришли к следующим сценариям
- Встраивание как подграф в downstream-модель.
- Экспорт и обновление эмбеддингов пользователей и контента в центральном хранилище.
- Дообучение или дистилляция для узкоспециализированных задач с жёсткими требованиями по задержке.
6. Результаты и выводы
- Масштабирование модели от десятков миллионов до миллиарда параметров подтверждает закономерности роста качества при увеличении данных.
- Внедрение единой модели привело к заметным A/B-выигрышам и консолидации инфраструктуры: ускорилась разработка новых функций и снизились дублирующиеся усилия.
- Основная "ставка" Netflix полностью оправдала себя: foundation-модель оказалась масштабируемым и гибким решением для персонализации рекомендации.
Этот подход планируют развивать в следующих направлениях
- Универсальные представления для гетерогенных сущностей (видео, игры, прямые трансляции и пр.).
- Генеративный подбор коллекций при помощи многошагового декодирования.
- Быстрая адаптация через prompt-тюнинг и «мягкие» токены для оперативной смены целей модели.
#AI #Engineering #ML #Architecture #Software #Data
Посмотрел вчера интересное выступление Есу Фэна (Yesu Feng) из Netflix про использование генеративных foundation-моделей для персональных рекомендаций. Кстати, Yesu Feng до прихода в Netflix работал в LinkedIn над лентой новостей и в Uber над оптимизацией маркетплейса. Я выделил для себя следующие ключевые идеи
1. Единая foundation-модель для всей системы рекомендаций
Вместо множества специализированных моделей (для разных страниц, жанров, форматов контента) Netflix переходит к одной "базовой" автогрессивной трансформер-модели, способной охватить все варианты использования.
2. Масштабирование как основной драйвер качества
Они пришли к этому сформулировав две достаточно логичные гипотезы
- При увеличении объёма данных и параметров модели персонализация улучшается по тем же законам масштабирования, что и у LLM.
- Интеграция этой модели во все подсистемы создаёт синергетический эффект и ускоряет инновации.
3. Особенности данных и обучения
В итоге, модель получилась многоуровневая
- На базовом уровне ребята делали event representation: when, where (locale & device & canvas), what (action type & entity & duration related)
- Дальше был уровень embedding/feature transformation - тут надо было объединять id embedding и дополнительные semantic embeddings, чтобы решать проблему холодного старта (например, новый контент)
- Следующий уровень содержал transformer/attention - hidden state layers отсюда использовались в качестве user representation, надо было гарантировать стабильность репрезантации пользователей, также надо было уметь явно адаптироваться под разные цели пользователей, также надо было понять как агрегрировать разные уровни и разные sequence для получения этой репрезентации
- На верхнем уровне располагалась objective loss function, которая была сложной - так как на выходе LLM было несколько последовательнотельностей (sequences) - это давало мультизадачностью на уровне функции потерь (предсказание типа действия, длительности сеанса, устройства и пр.)
-- main objective: entity id
-- auxiliary objectives: action types, entity metadate, duration, device, time
-- reward, weight & mask
4. Уроки из мира LLM
При построении LLM модели ребята набили ряд шишек и они поделились ими
- Многотокенное предсказание для повышения устойчивости к временным сдвигам и фокусировки на долгосрочном поведении.
- Многослойное представление и самодистилляция для стабильности эмбеддингов пользователя.
- Обработка длинных контекстных окон через прогрессивное увеличение длины и разреженное внимание.
5. Сценарии применения foundation-модели
Они пришли к следующим сценариям
- Встраивание как подграф в downstream-модель.
- Экспорт и обновление эмбеддингов пользователей и контента в центральном хранилище.
- Дообучение или дистилляция для узкоспециализированных задач с жёсткими требованиями по задержке.
6. Результаты и выводы
- Масштабирование модели от десятков миллионов до миллиарда параметров подтверждает закономерности роста качества при увеличении данных.
- Внедрение единой модели привело к заметным A/B-выигрышам и консолидации инфраструктуры: ускорилась разработка новых функций и снизились дублирующиеся усилия.
- Основная "ставка" Netflix полностью оправдала себя: foundation-модель оказалась масштабируемым и гибким решением для персонализации рекомендации.
Этот подход планируют развивать в следующих направлениях
- Универсальные представления для гетерогенных сущностей (видео, игры, прямые трансляции и пр.).
- Генеративный подбор коллекций при помощи многошагового декодирования.
- Быстрая адаптация через prompt-тюнинг и «мягкие» токены для оперативной смены целей модели.
#AI #Engineering #ML #Architecture #Software #Data
YouTube
Netflix's Big Bet: One model to rule recommendations: Yesu Feng, Netflix
Discuss the foundation model strategy for personalization at Netflix based on this post https://netflixtechblog.com/foundation-model-for-personalized-recommendation-1a0bd8e02d39 and recent developments.
About Yesu Feng
Yesu Feng is a staff research scientist/engineer…
About Yesu Feng
Yesu Feng is a staff research scientist/engineer…
❤6👍3🔥1
Летняя распродажа в издательстве «Питер» (Рубрика #Sales)
В издательстве Питер очередная распродажа со скидками в 35% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, причем значительную часть из них прочитал, включая книги
- Data mesh в действии - я прочитал эту книгу с прошлой распродажи и даже рассказал уже об этом. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale".
- Грокаем алгоритмы искусcтвенного интеллекта - я прочитал эту книгу недавно, вот пост про нее
- Настоящий CTO: думай как технический директор - я прочитал эту книгу, рассказал про нее, а потом мы даже с Сашей Шевченко записали эпизод подкаста с обсуждением этой книги
- Грокаем Continuous Delivery - интересная и простая книжка от сотрудницы Google про CI/CD, я ее уже успел ее прочитать и рассказать о ней
- Паттерны проектирования API - я начал читать и рассказал про эту книгу + читал whitepapers от автора насчет API Governance в Google (кратенько об этом тут)
- Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могу сказать, что книга не ухудшилась:)
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Распределенные данные. Алгоритмы работы современных систем хранения информации -в девичестве на английском эта книга Алекса Петрова называлась Database Internals и я про нее много рассказывал (1 и 2), а также мы ее обсуждали в подкасте "Code of Architecture"
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.
- Head First Software Architecture (Head First. Архитектура ПО) - простая книга по проектированию и архитектуре для начинающих, я про нее уже рассказал
- Acing the System Design Interview (System Design: пережить интервью) - хорошая книга про system design interview, я про нее уже рассказывал: 1 и 2
- Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач
В общем, распродажи в издательстве Питер бывают примерно каждый квартал, поэтому обычно я дожидаюсь их старта и дальше покупаю присмотренную литературу иногда пачками:)
#Sales
В издательстве Питер очередная распродажа со скидками в 35% на бумажные книги и 50% на электронные. Для получения этой скидки надо использовать промокод "Бумажная" (или "Электронная", если покупаете элетронную версию) при оформлении заказа. На прошлых распродажах я уже купил себе пачку книг, причем значительную часть из них прочитал, включая книги
- Data mesh в действии - я прочитал эту книгу с прошлой распродажи и даже рассказал уже об этом. До этого я читал частями книгу "Data Mesh: Delivering Data-Driven Value at Scale".
- Грокаем алгоритмы искусcтвенного интеллекта - я прочитал эту книгу недавно, вот пост про нее
- Настоящий CTO: думай как технический директор - я прочитал эту книгу, рассказал про нее, а потом мы даже с Сашей Шевченко записали эпизод подкаста с обсуждением этой книги
- Грокаем Continuous Delivery - интересная и простая книжка от сотрудницы Google про CI/CD, я ее уже успел ее прочитать и рассказать о ней
- Паттерны проектирования API - я начал читать и рассказал про эту книгу + читал whitepapers от автора насчет API Governance в Google (кратенько об этом тут)
- Чистый Python. Тонкости программирования для профи - решил вспомнить теорию по python
- Компьютерные сети. Принципы, технологии, протоколы: Юбилейное издание, дополненное и исправленное - я уже как-то читал книгу Олиферов, но это было много лет назад и она была ок. Сейчас я прочитал 150 страничек из нового издания и могу сказать, что книга не ухудшилась:)
- Гейм-дизайн: как создаются игры - эта книга про геймдизайн, про который я и до этого много читал и писал (1, 2, 3), а сейчас я уже прочитал и рассказал об этом
- Разработка приложений на базе GPT-4 и ChatGPT - базовая книга про chatGPT, я ее уже прочел и даже рассказывал оо ней
- Мифический человеко-месяц, или Как создаются программные системы - классическая книга Фредерика Брукса, которая в следующем году справляет свой юбилей. Я раньше уже рассказывал про эту книгу
- Распределенные данные. Алгоритмы работы современных систем хранения информации -
- Безопасные и надежные системы: Лучшие практики проектирования, внедрения и обслуживания как в Google - эту книгу я читал в оригинале и она называлась "Building secure and reliable systems", а также уже рассказывал про нее.
- Head First Software Architecture (Head First. Архитектура ПО) - простая книга по проектированию и архитектуре для начинающих, я про нее уже рассказал
- Acing the System Design Interview (System Design: пережить интервью) - хорошая книга про system design interview, я про нее уже рассказывал: 1 и 2
- Креативный программист - я решил изучить креативные методы, что могут помочь в решении инженерных задач
В общем, распродажи в издательстве Питер бывают примерно каждый квартал, поэтому обычно я дожидаюсь их старта и дальше покупаю присмотренную литературу иногда пачками:)
#Sales
❤12👍6🔥3
Интегрируем AI в процессы разработки в большой компании (Рубрика #AI)
Полтора месяца я выступал с этим докладом на CTO Conf X, но организаторы решили не публиковать доклады. Поэтому я решил его записать для своего канала и рассказать про state of the art-подходы к тому, как разложить работу инженеров на jobs to be done-сценарии, а дальше как уже эти сценарии можно улучшать. В процессе говорю про как классические подходы к написанию кода, так и варианты помощи с проектированием API, проведением code review, запуском тестов, устранением уязвимостей или детекцией аномалий при эксплуатации решений. В докладе будет не только рассмотрение SOTA, но и рассказ о том, что у нас реально работает и как мы подходим к оценке эффекта применения этих методов. В часовом докладе я рассказал про следующие темы
- Введение и план доклада
- История появления AI-копилотов (Copilot и аналоги)
- Что такое vibe coding
- Перспективы AI в разработке, протокол MCP от Anthropic
- Протоколы взаимодействия агентов и проблемы интеграции
- DevOps- и платформенные трансформации в больших компаниях
- Концепция developer experience и снижение когнитивной сложности
- Измерение целей и эффективности разработчиков
- API Governance в Google про AI-Enhanced API Design
- Code review в ByteDance
- Large scale migration при помощи AI в Uber
- Опыт Booking (API, code review, migrations)
- Observability платформа DataDog и AI On-call Engineer
- Подход T-Bank к AI в SDLC
- AI-Copilot Т-Банка Nester и его возможности
- Значение AI для крупных, средних и малых компаний
Кстати, я уже делал расшифровку этих докладов в трех частях: 1, 2 и 3
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity
Полтора месяца я выступал с этим докладом на CTO Conf X, но организаторы решили не публиковать доклады. Поэтому я решил его записать для своего канала и рассказать про state of the art-подходы к тому, как разложить работу инженеров на jobs to be done-сценарии, а дальше как уже эти сценарии можно улучшать. В процессе говорю про как классические подходы к написанию кода, так и варианты помощи с проектированием API, проведением code review, запуском тестов, устранением уязвимостей или детекцией аномалий при эксплуатации решений. В докладе будет не только рассмотрение SOTA, но и рассказ о том, что у нас реально работает и как мы подходим к оценке эффекта применения этих методов. В часовом докладе я рассказал про следующие темы
- Введение и план доклада
- История появления AI-копилотов (Copilot и аналоги)
- Что такое vibe coding
- Перспективы AI в разработке, протокол MCP от Anthropic
- Протоколы взаимодействия агентов и проблемы интеграции
- DevOps- и платформенные трансформации в больших компаниях
- Концепция developer experience и снижение когнитивной сложности
- Измерение целей и эффективности разработчиков
- API Governance в Google про AI-Enhanced API Design
- Code review в ByteDance
- Large scale migration при помощи AI в Uber
- Опыт Booking (API, code review, migrations)
- Observability платформа DataDog и AI On-call Engineer
- Подход T-Bank к AI в SDLC
- AI-Copilot Т-Банка Nester и его возможности
- Значение AI для крупных, средних и малых компаний
Кстати, я уже делал расшифровку этих докладов в трех частях: 1, 2 и 3
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity
YouTube
Интегрируем AI в процессы разработки в большой компании
Стартаперы из Y Combinator говорят, что вайб-кодинг помогает им писать по 95% кода. Казалось бы, выдаешь всем инженерам компании Cursor и радуешься... но не все так просто.
В этом докладе я рассказываю про state of the art-подходы к тому, как разложить работу…
В этом докладе я рассказываю про state of the art-подходы к тому, как разложить работу…
❤11🔥6👌2
Andrew Ng: Building Faster with AI (Рубрика #AI)
Посмотрел интересное выступление Эндрю Нг на AI Startup School от Y Comibnator. Эндрю является соучредителем и главным партнером AI Fund, соучредителем и председателем Coursera, основателем DeepLearning.AI, а также адъюнкт-профессором Стэнфордского университета. Интересно, что AI Fund - это венчурная студия, созданная в 2018 году, которая работает как "со-основатель" стартапов, помогая предпринимателям строить AI-компании с нуля.
1. Скорость как главный фактор успеха
Способность управленческой команды к быстрому выполнению задач является сильным предиктором успеха стартапа. Интересно, что большие компании не настолько зависят от скорости, но зато они могут действовать с большим рычагом (например, за счет дистрибуции на текущую аудиторию)
2. Стек искусственного интеллекта
Эндрю представил структуру AI-стека, состоящую из пяти уровней
- Полупроводниковые компании (базовый уровень)
- Гипермасштабируемые облачные сервисы
- Компании-разработчики базовых моделей
- Уровень агентной оркестровки (новый слой)
- Прикладной уровень (где находятся наибольшие возможности)
Причем прикладной уровень (apps layer) должен быть наиболее ценным, поскольку приложения должны генерировать достаточно дохода для поддержки всех нижележащих уровней.
3. Революция агентного ИИ
Агентные рабочие процессы представляют собой итеративный подход к решению задач, при котором AI-система может планировать, исследовать, пересматривать и улучшать свою работу. Вместо линейного создания контента агентные системы могут:
- Создавать план
- Проводить исследования
- Писать черновики
- Критически оценивать результаты
- Пересматривать и улучшать работу
4. Конкретные идеи против расплывчатых
Эндрб подчеркивает важность конкретных идей - идей, настолько детализированных, что инженер может их реализовать немедленно. Например:
Расплывчатая идея: «Использовать ИИ для оптимизации активов здравоохранения»
Конкретная идея: «Создать ПО для онлайн-бронирования слотов МРТ в больницах»
Конкретные идеи обеспечивают скорость, поскольку команда может быстро их реализовать и получить обратную связь. Забавно, что часто в корпорациях говорят про расплывчатые идеи - их можно вкидывать легко и все с ними согласны, но когда наступает время их реализовывать, то упсс
5. Трансформация разработки с помощью ИИ-помощников
Здесь было интересно услышать оценки Эндрю о том, как AI-ассистенты влияют на разработку
- Производственный код: улучшение на 30-50%
- Быстрые прототипы: ускорение в 10+ раз
Инструменты эволюционируют от автозавершения кода (GitHub Copilot) до высокоагентных помощников (Claude Code, новые версии с o3).
6. Сдвиг узких мест в разработке
С ускорением разработки софта основным узким местом становится управление продуктом. Эндрю отмечает изменение традиционных соотношений: вместо 1 продакт-менеджера на 4-7 инженеров, некоторые команды предлагают 1 продакт-менеджера на 0,5 инженера. Походу, это характерно для стартапов из AI Fund.
7. Важность открытых моделей
Эндрю выступает за защиту открытого исходного кода в области ИИ, предупреждая о попытках некоторых компаний создать регулирование, которое установит их в качестве "привратников" больших языковых моделей.
Вот такие советы можно вывести из выступления Эндрю
- Сосредоточьтесь на конкретных идеях - избегайте расплывчатых концепций
- Изучите программирование - даже нетехнические роли выигрывают от понимания кода
- Получайте быструю обратную связь - от личной интуиции до тестирования с незнакомцами
- Углубляйтесь в понимание AI - технические решения могут сэкономить месяцы работы
- Используйте разные тактики для получения обратной связи от пользователей
Отдельно стоит отметить, что Эндрю критикует шумиху вокруг AI, включая
- Угрозы человеческому существованию (безопасность ИИ зависит не от технологии, а от ее ответственного применения.)
- Массовую потерю рабочих мест
- Необходимость только ядерной энергии для ИИ
В общем, это очень дельное выступление с интересными мыслями.
#AI #ML #Software #Engineering #Agents #Architecture
Посмотрел интересное выступление Эндрю Нг на AI Startup School от Y Comibnator. Эндрю является соучредителем и главным партнером AI Fund, соучредителем и председателем Coursera, основателем DeepLearning.AI, а также адъюнкт-профессором Стэнфордского университета. Интересно, что AI Fund - это венчурная студия, созданная в 2018 году, которая работает как "со-основатель" стартапов, помогая предпринимателям строить AI-компании с нуля.
1. Скорость как главный фактор успеха
Способность управленческой команды к быстрому выполнению задач является сильным предиктором успеха стартапа. Интересно, что большие компании не настолько зависят от скорости, но зато они могут действовать с большим рычагом (например, за счет дистрибуции на текущую аудиторию)
2. Стек искусственного интеллекта
Эндрю представил структуру AI-стека, состоящую из пяти уровней
- Полупроводниковые компании (базовый уровень)
- Гипермасштабируемые облачные сервисы
- Компании-разработчики базовых моделей
- Уровень агентной оркестровки (новый слой)
- Прикладной уровень (где находятся наибольшие возможности)
Причем прикладной уровень (apps layer) должен быть наиболее ценным, поскольку приложения должны генерировать достаточно дохода для поддержки всех нижележащих уровней.
3. Революция агентного ИИ
Агентные рабочие процессы представляют собой итеративный подход к решению задач, при котором AI-система может планировать, исследовать, пересматривать и улучшать свою работу. Вместо линейного создания контента агентные системы могут:
- Создавать план
- Проводить исследования
- Писать черновики
- Критически оценивать результаты
- Пересматривать и улучшать работу
4. Конкретные идеи против расплывчатых
Эндрб подчеркивает важность конкретных идей - идей, настолько детализированных, что инженер может их реализовать немедленно. Например:
Расплывчатая идея: «Использовать ИИ для оптимизации активов здравоохранения»
Конкретная идея: «Создать ПО для онлайн-бронирования слотов МРТ в больницах»
Конкретные идеи обеспечивают скорость, поскольку команда может быстро их реализовать и получить обратную связь. Забавно, что часто в корпорациях говорят про расплывчатые идеи - их можно вкидывать легко и все с ними согласны, но когда наступает время их реализовывать, то упсс
5. Трансформация разработки с помощью ИИ-помощников
Здесь было интересно услышать оценки Эндрю о том, как AI-ассистенты влияют на разработку
- Производственный код: улучшение на 30-50%
- Быстрые прототипы: ускорение в 10+ раз
Инструменты эволюционируют от автозавершения кода (GitHub Copilot) до высокоагентных помощников (Claude Code, новые версии с o3).
6. Сдвиг узких мест в разработке
С ускорением разработки софта основным узким местом становится управление продуктом. Эндрю отмечает изменение традиционных соотношений: вместо 1 продакт-менеджера на 4-7 инженеров, некоторые команды предлагают 1 продакт-менеджера на 0,5 инженера. Походу, это характерно для стартапов из AI Fund.
7. Важность открытых моделей
Эндрю выступает за защиту открытого исходного кода в области ИИ, предупреждая о попытках некоторых компаний создать регулирование, которое установит их в качестве "привратников" больших языковых моделей.
Вот такие советы можно вывести из выступления Эндрю
- Сосредоточьтесь на конкретных идеях - избегайте расплывчатых концепций
- Изучите программирование - даже нетехнические роли выигрывают от понимания кода
- Получайте быструю обратную связь - от личной интуиции до тестирования с незнакомцами
- Углубляйтесь в понимание AI - технические решения могут сэкономить месяцы работы
- Используйте разные тактики для получения обратной связи от пользователей
Отдельно стоит отметить, что Эндрю критикует шумиху вокруг AI, включая
- Угрозы человеческому существованию (безопасность ИИ зависит не от технологии, а от ее ответственного применения.)
- Массовую потерю рабочих мест
- Необходимость только ядерной энергии для ИИ
В общем, это очень дельное выступление с интересными мыслями.
#AI #ML #Software #Engineering #Agents #Architecture
YouTube
Andrew Ng: Building Faster with AI
Andrew Ng on June 17, 2025 at AI Startup School in San Francisco.
Andrew Ng has helped shape some of the most influential movements in modern AI—from online education to deep learning to AI entrepreneurship.
In this talk, he shares what he’s learning now:…
Andrew Ng has helped shape some of the most influential movements in modern AI—from online education to deep learning to AI entrepreneurship.
In this talk, he shares what he’s learning now:…
❤10👍7🔥2
Turbo ML Conf (Рубрика #AI)
Эту субботу я решил провести на нашей конференции, слушая рассказы про ML/AI. Конкретно, сейчас слушаю keynote доклад от Вити Тарнавского, что у нас в Т-Банке отвечает за AI.
P.S.
Кстати, а вы заметили, что на фотке с основными трендами под пунктом vibe coding у ноутбука всего с десяток клавиш? Мне кажется, что Витя намекает, что вайбкодить можно даже на клавиатуре бабушкофона, используя T9, а лучше общааясь голосом.
#AI #ML #Engineering #Software
Эту субботу я решил провести на нашей конференции, слушая рассказы про ML/AI. Конкретно, сейчас слушаю keynote доклад от Вити Тарнавского, что у нас в Т-Банке отвечает за AI.
P.S.
Кстати, а вы заметили, что на фотке с основными трендами под пунктом vibe coding у ноутбука всего с десяток клавиш? Мне кажется, что Витя намекает, что вайбкодить можно даже на клавиатуре бабушкофона, используя T9, а лучше общааясь голосом.
#AI #ML #Engineering #Software
🔥9❤4👍2
Code of Leadership #44 Interview with Vladimir Kokhanov about Engineering Management (Рубрика #Management)
В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Коханов, технический директор в Т-Банке, что отвечает за сервисы массового сегмента физических лиц. До этого Владимир успел поработать в RedМadRobot, Тинькофф, Vivid Money. За полтора часа мы обсудили с Владимиром много вопросов, но все они казались развития инженеров и технических руководителей:
- Первые шаги в программировании
- Выбор университета и переезд в Зеленоград
- Специализация «вычислительная техника» и первая работа
- Присоединение к Тинькофф как Android-разработчик
- Решение стать лидером команды Android в Тинькофф Бизнес
- Рост команды и переход к кросс-функциональным командам
- Переход во внутренний стартап Vivid Money
- Масштабирование мобильной команды Vivid
- Запуск банковского продукта на лицензии Solaris Bank
- Переход от функциональных к продуктовым командам после релиза
- Возвращение в Тинькофф: технический директор (депозиты)
- Работа со стейкхолдерами и “карта интересов”
- Гибридный формат работы: офис и удалёнка
- Управление энергией, спорт и планирование времени
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Architecture #Processes
В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Коханов, технический директор в Т-Банке, что отвечает за сервисы массового сегмента физических лиц. До этого Владимир успел поработать в RedМadRobot, Тинькофф, Vivid Money. За полтора часа мы обсудили с Владимиром много вопросов, но все они казались развития инженеров и технических руководителей:
- Первые шаги в программировании
- Выбор университета и переезд в Зеленоград
- Специализация «вычислительная техника» и первая работа
- Присоединение к Тинькофф как Android-разработчик
- Решение стать лидером команды Android в Тинькофф Бизнес
- Рост команды и переход к кросс-функциональным командам
- Переход во внутренний стартап Vivid Money
- Масштабирование мобильной команды Vivid
- Запуск банковского продукта на лицензии Solaris Bank
- Переход от функциональных к продуктовым командам после релиза
- Возвращение в Тинькофф: технический директор (депозиты)
- Работа со стейкхолдерами и “карта интересов”
- Гибридный формат работы: офис и удалёнка
- Управление энергией, спорт и планирование времени
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Software #Engineering #Management #Architecture #Processes
YouTube
Code of Leadership #44 Interview with Vladimir Kokhanov about Engineering Management
В очередном выпуске подкаста ко мне пришел интересный гость, Владимир Коханов, технический директор в Т-Банке, что отвечает за сервисы массового сегмента физических лиц. До этого Владимир успел поработать в RedМadRobot, Тинькофф, Vivid Money. За полтора часа…
❤7👍4🔥2
How Replit Went From $10M to $100M ARR In Just 9 Months (Рубрика #AI)
Посмотрел на выходных интересное интервью Амджада Масада, со-основателя и CEO Replit, которое он дал ведущим подкаста "The Breakdown" от Y Comninator. Интервью получилось для меня интересным, так как я не знал с чего начинался Replit, на что они делали ставку и как сделали pivot после 5+ лет работы. Если краткое, то я выделил для себя следующие основные моменты
1. Ранние дни Replit в YC-2018
Миссия была в том, чтобы "сделать программирование доступным каждому", но дальше ребята сделали переход от обучения разработке к тому, чтобы создавать софт на естественном языке
2. Ставка на AI агентов в 2024 году
В 2024 году компания урезала штат на 50+%, а оставшиеся силы направила на создание агентской платформы. Но эффект дало появление Claude 3.5, после чего время когерентной работы агента стало приемлемым
3. Ограничения автономии
Сейчас AI умеет писать код часами, но условное использование компьютера (браузера) остается узким местом, но все крупные компании работают над этим
4. Транзакционные снапшоты в Replit
Для обучения программированию ребята построили файловую систему и базу данных со снапшотами, а когда пришла пора ставить всена черное агенты ребята получили буст, так как эта инфра позволяла агентами легко форкаться выполнять изменения и делать откат к версии снапшота всего окружения, если что-то пошло не так (условно механика как в git, где можно сделать revert)
5. Кто пользуется агентами?
По-факту, продакт-менеджеры и дизайнеры могут без инженеров запускать A/B-тесты, то есть внутри корпораций растёт "теневая" разработка, вызывая дискуссии об ответственности за созданный код
6. Безопасность и «скользкие» компоненты
LLM часто ошибается в аутентификации и авторизации. И Replit вшивает готовый разработанный ими OAuth-модуль и партнёрится с Semgrep для application security
7. Позиционирование
Replit занимает нишу «универсального решателя проблем» - он мощнее классического no-code, но доступнее IDE для профи
8. Взрывной рост
После Agent v2 компания росла в среднем на 45% MoM и вышла на $100 M ARR менее чем за год
9. Что под капотом
Из-за слабости LLM в генерации патчей Replit обучил вспомогательные модели, превращающие текстовые правки в чистые diffs
10. Как replit защищена от подражателей
Собственный snapshot-FS на NixOS, глобальный кеш пакетов— это долгосрочный барьер для клонов
11. Учить ли детей кодить?
Масад рекомендует "учиться делать вещи", а код - лишь один из инструментов, так как AI стирает границы между ролями
12 Судьба вертикального SaaS
Универсальные агент-платформы удешевят клон популярных приложений; защищены лишь большие экосистемы, навроде Salesforce
13. Совет основателям
Стоит работать "на грани возможного", так как один апгрейд модели может резко взвинтить ценность продукта; важно предугадывать траекторию ИИ
Если подбивать под выступлением выводы, то
- AI-агенты требуют интересной комбинации инфры - транзакционной файловой системы, снапшотов виртуальных машин, снапшотов баз данных, встроенных core компонентов (OAuth, платежи)
- Расширение круга создателей - главная аудитория теперь широкие "knowledge-workers", а не только инженеры - порог входа смещён к навыку формулировать идеи.
- Баланс роста и юнит-экономики — Масад осознанно не гонится за ARR-целями, опасаясь "токсичного" роста с высоким чёрном и низкой маржой (условно при оплате по модели usage-based легко разогнать маржу, сделав агентов говорливее и тупее)
- Будущее SaaS - горизонтальные агент-платформы угрожают нишевым вертикальным решениям, выживут экосистемы с сильным комьюнити и плагинами.
Из интервью видно, что фокус сдвигается с идеи написания кода руками к управлению агентами, что его напишут за тебя:)
#AI #ML #Agents #Software #Engineering #Architecture
Посмотрел на выходных интересное интервью Амджада Масада, со-основателя и CEO Replit, которое он дал ведущим подкаста "The Breakdown" от Y Comninator. Интервью получилось для меня интересным, так как я не знал с чего начинался Replit, на что они делали ставку и как сделали pivot после 5+ лет работы. Если краткое, то я выделил для себя следующие основные моменты
1. Ранние дни Replit в YC-2018
Миссия была в том, чтобы "сделать программирование доступным каждому", но дальше ребята сделали переход от обучения разработке к тому, чтобы создавать софт на естественном языке
2. Ставка на AI агентов в 2024 году
В 2024 году компания урезала штат на 50+%, а оставшиеся силы направила на создание агентской платформы. Но эффект дало появление Claude 3.5, после чего время когерентной работы агента стало приемлемым
3. Ограничения автономии
Сейчас AI умеет писать код часами, но условное использование компьютера (браузера) остается узким местом, но все крупные компании работают над этим
4. Транзакционные снапшоты в Replit
Для обучения программированию ребята построили файловую систему и базу данных со снапшотами, а когда пришла пора ставить все
5. Кто пользуется агентами?
По-факту, продакт-менеджеры и дизайнеры могут без инженеров запускать A/B-тесты, то есть внутри корпораций растёт "теневая" разработка, вызывая дискуссии об ответственности за созданный код
6. Безопасность и «скользкие» компоненты
LLM часто ошибается в аутентификации и авторизации. И Replit вшивает готовый разработанный ими OAuth-модуль и партнёрится с Semgrep для application security
7. Позиционирование
Replit занимает нишу «универсального решателя проблем» - он мощнее классического no-code, но доступнее IDE для профи
8. Взрывной рост
После Agent v2 компания росла в среднем на 45% MoM и вышла на $100 M ARR менее чем за год
9. Что под капотом
Из-за слабости LLM в генерации патчей Replit обучил вспомогательные модели, превращающие текстовые правки в чистые diffs
10. Как replit защищена от подражателей
Собственный snapshot-FS на NixOS, глобальный кеш пакетов— это долгосрочный барьер для клонов
11. Учить ли детей кодить?
Масад рекомендует "учиться делать вещи", а код - лишь один из инструментов, так как AI стирает границы между ролями
12 Судьба вертикального SaaS
Универсальные агент-платформы удешевят клон популярных приложений; защищены лишь большие экосистемы, навроде Salesforce
13. Совет основателям
Стоит работать "на грани возможного", так как один апгрейд модели может резко взвинтить ценность продукта; важно предугадывать траекторию ИИ
Если подбивать под выступлением выводы, то
- AI-агенты требуют интересной комбинации инфры - транзакционной файловой системы, снапшотов виртуальных машин, снапшотов баз данных, встроенных core компонентов (OAuth, платежи)
- Расширение круга создателей - главная аудитория теперь широкие "knowledge-workers", а не только инженеры - порог входа смещён к навыку формулировать идеи.
- Баланс роста и юнит-экономики — Масад осознанно не гонится за ARR-целями, опасаясь "токсичного" роста с высоким чёрном и низкой маржой (условно при оплате по модели usage-based легко разогнать маржу, сделав агентов говорливее и тупее)
- Будущее SaaS - горизонтальные агент-платформы угрожают нишевым вертикальным решениям, выживут экосистемы с сильным комьюнити и плагинами.
Из интервью видно, что фокус сдвигается с идеи написания кода руками к управлению агентами, что его напишут за тебя:)
#AI #ML #Agents #Software #Engineering #Architecture
YouTube
How Replit Went From $10M to $100M ARR In Just 9 Months
Amjad Masad started Replit to make programming accessible to anyone, anywhere. What began as a tool for learning to code has grown into a platform pushing the limits of AI-assisted software creation and recently surpassed $100M in ARR.
On The Breakdown with…
On The Breakdown with…
❤7🔥4👍2
Developing Enterprise Java Applications with J2EE and UML (Разработка корпоративных приложений с помощью J2EE и UML) (Рубрика #Software)
Постепенно продолжаю разгребать свои книжные полки и относить раритетные книги в Book sharing уголок. Сегодня пришла очередь книги 2002 года про микс J2EE и UML. В начале 2000-х годов индустрия программного обеспечения переживала период революционных изменений. Корпоративные приложения становились все более сложными, стоимость создания, развертывания и поддержки клиент-серверных систем на ПК стала чрезмерно дорогой. В то же время Web-приложения набирали популярность, но разработчики часто с трудом собирали воедино различные API, поскольку развитие API не всегда координировалось. Эта книга представляла собой первое серьезное исследование совместного применения J2EE и UML. На тот момент существовал значительный семантический разрыв между возможностями J2EE и требованиями реальных бизнес-задач. UML служил мостом для устранения этого разрыва, предоставляя язык диаграмм для программного обеспечения.
Но за 20+ лет многое поменялось
- Java EE (бывшая J2EE) была передана Eclipse Foundation в 2017 году и переименована в Jakarta EE
- J2EE/Jakarta EE был вытеснен Spring Framework (и дальше Spring Boot)
- Приложения ушли от монолитов к сервисной архитектуре
- Приложения ушли в cloud native парадигму
- Местами стало популярно реактивное программирование и функциональное программирование
В итоге, сегодня книга имеет преимущественно историческую ценность:)
P.S.
Для понимания контекста в начале 2000х можно посмотреть подкаст с Гради Бучем, создателем компании Rational, я его тут разбирал.
#Software #Engineering #Architecture
Постепенно продолжаю разгребать свои книжные полки и относить раритетные книги в Book sharing уголок. Сегодня пришла очередь книги 2002 года про микс J2EE и UML. В начале 2000-х годов индустрия программного обеспечения переживала период революционных изменений. Корпоративные приложения становились все более сложными, стоимость создания, развертывания и поддержки клиент-серверных систем на ПК стала чрезмерно дорогой. В то же время Web-приложения набирали популярность, но разработчики часто с трудом собирали воедино различные API, поскольку развитие API не всегда координировалось. Эта книга представляла собой первое серьезное исследование совместного применения J2EE и UML. На тот момент существовал значительный семантический разрыв между возможностями J2EE и требованиями реальных бизнес-задач. UML служил мостом для устранения этого разрыва, предоставляя язык диаграмм для программного обеспечения.
Но за 20+ лет многое поменялось
- Java EE (бывшая J2EE) была передана Eclipse Foundation в 2017 году и переименована в Jakarta EE
- J2EE/Jakarta EE был вытеснен Spring Framework (и дальше Spring Boot)
- Приложения ушли от монолитов к сервисной архитектуре
- Приложения ушли в cloud native парадигму
- Местами стало популярно реактивное программирование и функциональное программирование
В итоге, сегодня книга имеет преимущественно историческую ценность:)
P.S.
Для понимания контекста в начале 2000х можно посмотреть подкаст с Гради Бучем, создателем компании Rational, я его тут разбирал.
#Software #Engineering #Architecture
🔥9❤3👍1
Research Insights Made Simple #12 - Measuring developer productivity with the DX Core 4 (Рубрика #DevEx)
Выпуск посвящен разбору "Measuring developer productivity with the DX Core 4" от ребят из DX, которые активно развивают тему developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health.
- Введение, история и предпосылки появления DX Core 4
- Основые принципы измерения продуктивности, проблемы опросов
- 4 метрики DORA: deployment frequency, lead time for changes, change failure rate, time to restore service
- Простота внедрения DORA, интеграция с инструментами и его ограничения
- Фреймворк SPACE: опросы и системные метрики как фактор эффективности
- Дизайн фреймворков - разработка для решения конкретных проблем, добавление метрик по необходимости
- Развитие платформы DX
- Многомерные измерения внутри фреймворка DX Core 4 (качество, эффективность, скорость и импакт.)
- Настройка метрик, балансирующие метрики
- Роль технического директора и анализ метрик
- Анализ метрик и критерии их оценки
- Внедрение метрик в организации
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes #AI #Agents
Выпуск посвящен разбору "Measuring developer productivity with the DX Core 4" от ребят из DX, которые активно развивают тему developer productivity. Для разбора этой статьи ко мне пришел гость, Евгений Сергеев, engineering director в Flo Health.
- Введение, история и предпосылки появления DX Core 4
- Основые принципы измерения продуктивности, проблемы опросов
- 4 метрики DORA: deployment frequency, lead time for changes, change failure rate, time to restore service
- Простота внедрения DORA, интеграция с инструментами и его ограничения
- Фреймворк SPACE: опросы и системные метрики как фактор эффективности
- Дизайн фреймворков - разработка для решения конкретных проблем, добавление метрик по необходимости
- Развитие платформы DX
- Многомерные измерения внутри фреймворка DX Core 4 (качество, эффективность, скорость и импакт.)
- Настройка метрик, балансирующие метрики
- Роль технического директора и анализ метрик
- Анализ метрик и критерии их оценки
- Внедрение метрик в организации
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes #AI #Agents
YouTube
Research Insights Made Simple #12 Measuring developer productivity with the DX Core 4
Очередной выпуск подкаста с разбором whitepaper "Measuring developer productivity with the DX Core 4" посвящен разбору измерения продуктивности разработчиков. Этот отчет интересен, так как ребята из DX являются одними из законодателей мод в мире developer…
❤5👍2🔥1
Empirical evidence of Large Language Model's influence on human spoken communication (Рубрика #AI)
Вы когда-нибудь задумывались о том, а как устроена наша речь и откуда мы черпаем свой словарный запас? Вот и ученые из "Max Planck Institute for Human Development" тоже об этом думали и решили провести исследование устной речи и как на нее повлияли большие языковые модели. С письменной речью уже давно все понятно, а вот устная речь требовала исследования. Его методология выглядела следующим образом
- Первый этап: Исследователи загрузили в ChatGPT миллионы страниц электронных писем, эссе, научных статей и новостных материалов, попросив ИИ "отполировать" тексты. Затем они выделили слова, которые ChatGPT использовал значительно чаще оригинальных авторов.
- Второй этап: Команда проанализировала более 360 000 видеороликов YouTube и 771 000 эпизодов подкастов, записанных до и после релиза ChatGPT. Общий объем проанализированного контента составил свыше 740 000 часов человеческой речи.
- Контрольная группа: Для обеспечения достоверности результатов ученые создали "синтетические контрольные группы" из синонимов, которые ChatGPT использовал реже, таких как "examine" и "explore" вместо "delve"
В результате исследования авторы обнаружили возникновение закрытых петлей обратной связи между людьми и AI в плане культуры. Соавтор исследования Левин Бринкманн объясняет этот феномен тем, что люди склонны подражать тем, кого считают авторитетными источниками. А AI может очень уверенно и структурно излагать материал, что делает его в глазах людей экспертным источником. А это приводит к перениманию лексики, а также характера разговора - речь людей становится длинее, структурнее и менее эмоциональной.
Эффект особенно заметен в науке, образовании и бизнесе. Наибольшее влияние обнаружено в академических YouTube-каналах, где использование GPT-слов выросло на 25-50% в год. Исследование также показало, что влияние ИИ способствует унификации английского языка по американскому образцу. Все это приводит к социальным последствиям в виде потери культурно разнообразия.
Забавно, что ученые нашли парадокс: если окружающие знают о частом использовании ИИ человеком, его красноречивость воспринимается негативно. Собеседники считают такого человека менее вовлеченным и эмпатичным, особенно в онлайн-общении.
Интересно, а какие еще неявные последствия от AI мы уже испытываем на себе и к чему они приведут в итоге.
#AI #Software #PopularScience #GenAI
Вы когда-нибудь задумывались о том, а как устроена наша речь и откуда мы черпаем свой словарный запас? Вот и ученые из "Max Planck Institute for Human Development" тоже об этом думали и решили провести исследование устной речи и как на нее повлияли большие языковые модели. С письменной речью уже давно все понятно, а вот устная речь требовала исследования. Его методология выглядела следующим образом
- Первый этап: Исследователи загрузили в ChatGPT миллионы страниц электронных писем, эссе, научных статей и новостных материалов, попросив ИИ "отполировать" тексты. Затем они выделили слова, которые ChatGPT использовал значительно чаще оригинальных авторов.
- Второй этап: Команда проанализировала более 360 000 видеороликов YouTube и 771 000 эпизодов подкастов, записанных до и после релиза ChatGPT. Общий объем проанализированного контента составил свыше 740 000 часов человеческой речи.
- Контрольная группа: Для обеспечения достоверности результатов ученые создали "синтетические контрольные группы" из синонимов, которые ChatGPT использовал реже, таких как "examine" и "explore" вместо "delve"
В результате исследования авторы обнаружили возникновение закрытых петлей обратной связи между людьми и AI в плане культуры. Соавтор исследования Левин Бринкманн объясняет этот феномен тем, что люди склонны подражать тем, кого считают авторитетными источниками. А AI может очень уверенно и структурно излагать материал, что делает его в глазах людей экспертным источником. А это приводит к перениманию лексики, а также характера разговора - речь людей становится длинее, структурнее и менее эмоциональной.
Эффект особенно заметен в науке, образовании и бизнесе. Наибольшее влияние обнаружено в академических YouTube-каналах, где использование GPT-слов выросло на 25-50% в год. Исследование также показало, что влияние ИИ способствует унификации английского языка по американскому образцу. Все это приводит к социальным последствиям в виде потери культурно разнообразия.
Забавно, что ученые нашли парадокс: если окружающие знают о частом использовании ИИ человеком, его красноречивость воспринимается негативно. Собеседники считают такого человека менее вовлеченным и эмпатичным, особенно в онлайн-общении.
Интересно, а какие еще неявные последствия от AI мы уже испытываем на себе и к чему они приведут в итоге.
#AI #Software #PopularScience #GenAI
arXiv.org
Empirical evidence of Large Language Model's influence on...
From the invention of writing and the printing press, to television and social media, human history is punctuated by major innovations in communication technology, which fundamentally altered how...
👍9❤4🔥2
Не эксперимент, а стратегия: путь к системному использованию AI в SDLC (Рубрика #AI)
Появилась запись выступления Николая Бушкова, моего коллеги, который руководит группой, занимающейся темой engineering productivity в R&D центре Т-Банка. Кстати, этот R&D центр был создан полтора года назад, инвестиции составили более 500 млн рублей. Центр занимается исследованиями в области искусственного интеллекта, баз данных, информационной безопасности и инженерной продуктивности. Он сотрудничает с ведущими российскими университетами, включая МФТИ, Сколтех и НГУ. Если говорить про ключевые идеи доклада, то они следующие
1. Переход от экспериментов к системному подходу
Основная концепция доклада заключается в том, что ИИ в Т-Банке - не хайп и не эксперимент, а часть инженерной стратегии и повседневный рабочий инструмент. Более 5000 специалистов в неделю принимают подсказки внутренних ассистентов, что свидетельствует о массовом внедрении технологии.
2. Обзор индустрии и исследований
Николай ссылается на исследования Anthropic, показывающие, что треть всех кейсов использования их чат-бота приходится на программную инженерию, несмотря на то, что программисты составляют гораздо меньшую долю от общего числа пользователей. Способность моделей закрывать задачи полностью под ключ уже довольно высокая.
3. Системный подход к сценариям использования
Команда разбила жизненный цикл разработки ПО (SDLC) на стадии и создала внутренние рабочие группы для каждой стадии. Приоритетными сценариями стали:
- Автодополнение кода и чат в IDE
- Генерация юнит-тестов
- Автоматическое код-ревью
- Продвинутый поиск по коду
- Ассистенты за пределами IDE
4. LLM-платформа
Внутри компании есть своя LLM-платформа, где есть
- Собственные модели T-Lite и T-Pro (пока не активно используются для кодовых задач) - кстати, недавно были анонсы новых версий
- Serving open weights моделей типа Qwen, DeepSeek, ...
- Лояльный отдел информационной безопасности, позволяющий ограниченный доступ к внешним моделям
5. Планы по развитию
- Развитие от ассистента к агенту - сейчас идет работа над созданием более автономных решений, способных полностью закрывать задачи
- Есть пилоты с внешними решениями - тестирование Aider и других агентских систем
6. Методологические принципы
Николай подчеркивает важность измерения не только метрик adoption, но и удовлетворенности пользователей. Необходимо делать то, что болит, а не то, что технически можем делать. При внедрении важно обращать внимание на качество, чтобы не увеличивать техдолг.
В общем, доклад Николая демонстрирует зрелый подход к внедрению ИИ в разработку софта
#AI #Engineering #Software #Leadership #Metrics #Agents
Появилась запись выступления Николая Бушкова, моего коллеги, который руководит группой, занимающейся темой engineering productivity в R&D центре Т-Банка. Кстати, этот R&D центр был создан полтора года назад, инвестиции составили более 500 млн рублей. Центр занимается исследованиями в области искусственного интеллекта, баз данных, информационной безопасности и инженерной продуктивности. Он сотрудничает с ведущими российскими университетами, включая МФТИ, Сколтех и НГУ. Если говорить про ключевые идеи доклада, то они следующие
1. Переход от экспериментов к системному подходу
Основная концепция доклада заключается в том, что ИИ в Т-Банке - не хайп и не эксперимент, а часть инженерной стратегии и повседневный рабочий инструмент. Более 5000 специалистов в неделю принимают подсказки внутренних ассистентов, что свидетельствует о массовом внедрении технологии.
2. Обзор индустрии и исследований
Николай ссылается на исследования Anthropic, показывающие, что треть всех кейсов использования их чат-бота приходится на программную инженерию, несмотря на то, что программисты составляют гораздо меньшую долю от общего числа пользователей. Способность моделей закрывать задачи полностью под ключ уже довольно высокая.
3. Системный подход к сценариям использования
Команда разбила жизненный цикл разработки ПО (SDLC) на стадии и создала внутренние рабочие группы для каждой стадии. Приоритетными сценариями стали:
- Автодополнение кода и чат в IDE
- Генерация юнит-тестов
- Автоматическое код-ревью
- Продвинутый поиск по коду
- Ассистенты за пределами IDE
4. LLM-платформа
Внутри компании есть своя LLM-платформа, где есть
- Собственные модели T-Lite и T-Pro (пока не активно используются для кодовых задач) - кстати, недавно были анонсы новых версий
- Serving open weights моделей типа Qwen, DeepSeek, ...
- Лояльный отдел информационной безопасности, позволяющий ограниченный доступ к внешним моделям
5. Планы по развитию
- Развитие от ассистента к агенту - сейчас идет работа над созданием более автономных решений, способных полностью закрывать задачи
- Есть пилоты с внешними решениями - тестирование Aider и других агентских систем
6. Методологические принципы
Николай подчеркивает важность измерения не только метрик adoption, но и удовлетворенности пользователей. Необходимо делать то, что болит, а не то, что технически можем делать. При внедрении важно обращать внимание на качество, чтобы не увеличивать техдолг.
В общем, доклад Николая демонстрирует зрелый подход к внедрению ИИ в разработку софта
#AI #Engineering #Software #Leadership #Metrics #Agents
❤7🔥5👍3
Inside OpenAI's Stargate Megafactory with Sam Altman (Рубрика #AI)
Я люблю смотреть документальные книги про технологии, поэтому мой взор упал на документальный фильм про "Звездные врата" Сэма Альтмана и Дональда Трампа. Этот фильм сняли ребята из Bloomberg и он представляет эксклюзивное исследование одного из самых амбициозных технологических проектов в истории. Фильм демонстрирует масштабную строительную площадку в Абилине, штат Техас, где создается инфраструктура искусственного интеллекта стоимостью 500 миллиардов долларов. Ведущей и продюссером фильма выступает Эмили Чанг, ведущая и исполнительный продюсер Bloomberg Originals, известная своими интервью с топ-менеджерами технологических компаний, включая генеральных директоров Apple, Tesla, Meta и Amazon.
В ходе фильма интервью дали следующие персонажи
1. Сэм Альтман - генеральный директор OpenAI, один из ведущих партнеров проекта "Звездные врата". В интервью он объяснил логику инвестиций в размере 500 миллиардов долларов, отметив, что эта сумма покрывает потребности в вычислительных мощностях на ближайшие годы, исходя из их прогнозов роста.
2. Масайоси Сон - председатель и генеральный директор SoftBank, который возглавляет финансовую сторону проекта. Сон известен своими амбициозными прогнозами относительно AGI, ожидая его появления в течение десятилетия.
3. Чейз Лохмиллер - соучредитель и генеральный директор Crusoe, компании, отвечающей за физическое строительство. Он бывший квантовый трейдер с Уолл-стрит, который оставил финансы, чтобы покорить Эверест, где у него возникли идеи для Crusoe. Он имеет степени по математике и физике из MIT и магистерскую степень по информатике со специализацией в области ИИ из Стэнфорда.
Также было дополнительно взято интервью у нескольких экспертов поменьше
Ключевые идеи фильма
1. Масштаб проекта
В планах кампус площадью 1200 акров в Абилине, штат Техас, 400 000 GPU-чипов Nvidia в восьми зданиях, энергопотребление 1.2 гигаватта. Начальные инвестиции — 100 миллиардов долларов с планами расширения до 500 миллиардов долларов к 2029 году.
2. Технологические инновации
- Использование системы замкнутого цикла охлаждения без испарения воды, что решает проблемы устойчивости
- Прямое жидкостное охлаждение чипов вместо традиционных методов
- Переход от CPU к GPU-центрированной архитектуре для обработки AI-задач (не уверен, что это инновации в 2025 году)
3. Энергетические вызовы
- Современные ИИ-центры потребляют в 130 киловатт на стойку по сравнению с 2-4 киловатта 20 лет назад
- Запрос к ChatGPT использует в 10 раз больше энергии, чем поиск в Google
- К 2035 году центры обработки данных могут потреблять более 8% электроэнергии Америки
4. Конкуренция и эффективность
Фильм затрагивает появление китайской компании DeepSeek, которая продемонстрировала возможность создания эффективных ИИ-моделей с гораздо меньшими затратами. Это поставило под вопрос необходимость мегапроектов масштаба «Звездных врат».
Если подводить итоги фильма, то
1. Проект позиционируется как критически важный для поддержания технологического лидерства США в гонке AI против Китая. Трамп представил его как проект национальной безопасности, который обеспечит американское превосходство в области искусственного интеллекта.
2. Проект должен помочь экономическому развитию США - части про создание рабочих мест в фильме звучат спорно (так какой гига-датацентр по максимуму автоматизируют)
3. Альтман видит 2025 год как период, когда ИИ-агенты будут выполнять работу, которую мы уже умеем делать, а 2026 год - как время значительного научного прогресса благодаря ИИ.
4. В фильме очень неплохо показаны риски и неопределенность
- Финансовая устойчивость участников: OpenAI понес убытки в 5 миллиардов долларов в 2024 году
- Экологические вопросы: противоречие между климатическими целями и энергоемкостью ИИ
- Геополитические риски: торговые войны и зависимость от международных цепочек поставок
В общем, фильм показывает изнутри масштаб проекта, а также рассматривает этот проект реалистично с разных сторон.
#AI #Engineering #Software #ML #Leadership #Project #Management
Я люблю смотреть документальные книги про технологии, поэтому мой взор упал на документальный фильм про "Звездные врата" Сэма Альтмана и Дональда Трампа. Этот фильм сняли ребята из Bloomberg и он представляет эксклюзивное исследование одного из самых амбициозных технологических проектов в истории. Фильм демонстрирует масштабную строительную площадку в Абилине, штат Техас, где создается инфраструктура искусственного интеллекта стоимостью 500 миллиардов долларов. Ведущей и продюссером фильма выступает Эмили Чанг, ведущая и исполнительный продюсер Bloomberg Originals, известная своими интервью с топ-менеджерами технологических компаний, включая генеральных директоров Apple, Tesla, Meta и Amazon.
В ходе фильма интервью дали следующие персонажи
1. Сэм Альтман - генеральный директор OpenAI, один из ведущих партнеров проекта "Звездные врата". В интервью он объяснил логику инвестиций в размере 500 миллиардов долларов, отметив, что эта сумма покрывает потребности в вычислительных мощностях на ближайшие годы, исходя из их прогнозов роста.
2. Масайоси Сон - председатель и генеральный директор SoftBank, который возглавляет финансовую сторону проекта. Сон известен своими амбициозными прогнозами относительно AGI, ожидая его появления в течение десятилетия.
3. Чейз Лохмиллер - соучредитель и генеральный директор Crusoe, компании, отвечающей за физическое строительство. Он бывший квантовый трейдер с Уолл-стрит, который оставил финансы, чтобы покорить Эверест, где у него возникли идеи для Crusoe. Он имеет степени по математике и физике из MIT и магистерскую степень по информатике со специализацией в области ИИ из Стэнфорда.
Также было дополнительно взято интервью у нескольких экспертов поменьше
Ключевые идеи фильма
1. Масштаб проекта
В планах кампус площадью 1200 акров в Абилине, штат Техас, 400 000 GPU-чипов Nvidia в восьми зданиях, энергопотребление 1.2 гигаватта. Начальные инвестиции — 100 миллиардов долларов с планами расширения до 500 миллиардов долларов к 2029 году.
2. Технологические инновации
- Использование системы замкнутого цикла охлаждения без испарения воды, что решает проблемы устойчивости
- Прямое жидкостное охлаждение чипов вместо традиционных методов
- Переход от CPU к GPU-центрированной архитектуре для обработки AI-задач (не уверен, что это инновации в 2025 году)
3. Энергетические вызовы
- Современные ИИ-центры потребляют в 130 киловатт на стойку по сравнению с 2-4 киловатта 20 лет назад
- Запрос к ChatGPT использует в 10 раз больше энергии, чем поиск в Google
- К 2035 году центры обработки данных могут потреблять более 8% электроэнергии Америки
4. Конкуренция и эффективность
Фильм затрагивает появление китайской компании DeepSeek, которая продемонстрировала возможность создания эффективных ИИ-моделей с гораздо меньшими затратами. Это поставило под вопрос необходимость мегапроектов масштаба «Звездных врат».
Если подводить итоги фильма, то
1. Проект позиционируется как критически важный для поддержания технологического лидерства США в гонке AI против Китая. Трамп представил его как проект национальной безопасности, который обеспечит американское превосходство в области искусственного интеллекта.
2. Проект должен помочь экономическому развитию США - части про создание рабочих мест в фильме звучат спорно (так какой гига-датацентр по максимуму автоматизируют)
3. Альтман видит 2025 год как период, когда ИИ-агенты будут выполнять работу, которую мы уже умеем делать, а 2026 год - как время значительного научного прогресса благодаря ИИ.
4. В фильме очень неплохо показаны риски и неопределенность
- Финансовая устойчивость участников: OpenAI понес убытки в 5 миллиардов долларов в 2024 году
- Экологические вопросы: противоречие между климатическими целями и энергоемкостью ИИ
- Геополитические риски: торговые войны и зависимость от международных цепочек поставок
В общем, фильм показывает изнутри масштаб проекта, а также рассматривает этот проект реалистично с разных сторон.
#AI #Engineering #Software #ML #Leadership #Project #Management
YouTube
Inside OpenAI's Stargate Megafactory with Sam Altman | The Circuit
Emily Chang visits the Stargate site in Abilene, Texas for an exclusive first look at the historic $500 billion bet on the future of AI, announced by President Trump the day after his inauguration. She speaks with OpenAI CEO Sam Altman & Softbank CEO Masayoshi…
❤8👍6🔥2🤪1