T-Sync Conf (Рубрика #Software)
Приходите 7 февраля 2026 года на нашу большую конференцию T-Sync, точка синхронизации технологий и тех, кто их использует. Здесь будет много про практику, взаимодействие и живые системы. На этой конфе у нас будет стенд, где мы покажем результаты нашего исследования влияния AI на инженерную культуру. А вообще на конфе будет 8 технологических контуров из всех инженерных сфер: AI, Data, R&D, Security, UX/UI, Productivity, Observability, Platfrom. А вообще, эта конференция будет отличаться по формату от большинства конференций - здесь не будет скучных докладов (и не только скучных), но можно будет пообщаться и позадавать вопросы инженерам, которые реально делают те системы, которые работают у нас в проде, исследователям, что двигают нас вперед, а также техническим руководителям, которые не мешают работать остальным (а по мере своих сил стараются помогать).
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity #Conference
Приходите 7 февраля 2026 года на нашу большую конференцию T-Sync, точка синхронизации технологий и тех, кто их использует. Здесь будет много про практику, взаимодействие и живые системы. На этой конфе у нас будет стенд, где мы покажем результаты нашего исследования влияния AI на инженерную культуру. А вообще на конфе будет 8 технологических контуров из всех инженерных сфер: AI, Data, R&D, Security, UX/UI, Productivity, Observability, Platfrom. А вообще, эта конференция будет отличаться по формату от большинства конференций - здесь не будет скучных докладов (и не только скучных), но можно будет пообщаться и позадавать вопросы инженерам, которые реально делают те системы, которые работают у нас в проде, исследователям, что двигают нас вперед, а также техническим руководителям, которые не мешают работать остальным (а по мере своих сил стараются помогать).
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity #Conference
❤7👍6🔥3
YaC 2025 AI Edition (Рубрика #AI)
В очередной YaC (Yet another Conference) Яндекс демонстрирует переход искусственного интеллекта из статуса технологии для энтузиастов в массовый инструмент для повседневных задач. Фильм внедряет в головы зрителя людей мысль о том, что ИИ должен стать "привычкой", помогая решать реальные проблемы без необходимости разбираться в технических деталях вроде "претрейна" и "инференса". По ходу фильма мы видим как Алиса AI превращается в "эмпатичного ассистента", который понимает контекст пользователя и встраивается во все сервисы экосистемы - от браузера до роботов-доставщиков.
Если говорить про целевую аудиторию, то фильм нацелен широко
- Массовые пользователи: родители (упражнения для детей с логопедом), туристы (сборы снаряжения для треккинга), покупатели (поиск товаров со скидками до 30%)
- Профессионалы: юристы (анализ 100-страничных законопроектов), врачи (диагностика по МРТ), предприниматели (рабочие задачи через Алису Про)
- Tech-энтузиасты: любители промптинга (платформа Промптхаб), разработчики (70% сотрудников Яндекса используют ИИ ежедневно)
Фильм длится чуть больше часа и разделён на шесть тематических блоков с естественными переходами между "железом", софтом и стратегией:
1️⃣ Алиса AI: от чата до экосистемы
- Обогащённые ответы с картами, картинками, рецептами
- Примеры из жизни: турист собирает рюкзак для Непала и сокращает вес с 13 до 7–8 кг благодаря анализу Алисы; родитель генерирует логопедические загадки с буквой "Р"
- Креативная генерация: оживление чёрно-белых фото вызывает эмоции у пользователей
2️⃣ Промпты и агенты
- Промптхаб - платформа для обмена шаблонами
- Агенты - система на нейросетях, автоматизирующая цепочки действий (пример агента "Найти дешевле")
- НейроГусь - внутренняя премия Яндекса за ИИ-проекты
3️⃣ Интеграция в сервисы: Маркет как пример
- Поиск по естественным запросам: "Собери всё для приготовления ростбифа" → Алиса предлагает термометр, доски, ножи, уточняет бюджет
- Мультимодальный поиск: фото человека → анализ одежды → подбор «похожего лука» с учётом персональных предпочтений
4️⃣ Алиса Про и бизнес-кейсы
- Алиса Про: для корпоративных задач (интеграция в почту, диск, вики)
- Нейроюрист: анализ законопроектов, претензий, договоров. 75% юристов Яндекса используют инструмент, экономя 2 часа в неделю на 10 запросов.
- Кейс с ПВЗ Яндекс Маркета: новые сотрудники решают вопросы о возвратах и габаритах через Алису Про
5️⃣ ИИ + "железо"
- Устройства: наушники Дропс (запись заметок голосом), диктофон с суммаризацией встреч, IP-камера (сценарии: "Если кот на столе - запусти пылесос")
- Роботы-доставщики: 20 000 роверов к 2027 году в городах России (запуск в СПб, Казани, Иннополисе). Завод на 1500 роботов/месяц, каждый проходит 50 тестов и калибровку за 20 минут. Нейросети управляют навигацией, обходят препятствия в реальном времени
- Автономный грузовик: лидары, камеры, ИИ для манёвров (система обучалась на данных водителей)
6️⃣ Медицина и будущее
- МРТ-анализ для новорождённых: нейросеть определяет объёмы мозга и вещества для выявления рисков ДЦП, сокращая время анализа с дней до минут
- Будущее работы: ИИ не заменяет людей, а создаёт новые места (экономит рутину, усиливает креатив). 70% сотрудников Яндекса используют ИИ ежедневно (рост с 30% в 2023)
В общем, фильм позиционирует Яндекс как компанию, которая первой в России превратила ИИ из хайпа в утилитарный инструмент для миллионов - от мелкобытовых задач (сборка рюкзака) до критически важных (медицинская диагностика)
#AI #Software #Engineering #Economics #Software #Management #Leadership
В очередной YaC (Yet another Conference) Яндекс демонстрирует переход искусственного интеллекта из статуса технологии для энтузиастов в массовый инструмент для повседневных задач. Фильм внедряет в головы зрителя людей мысль о том, что ИИ должен стать "привычкой", помогая решать реальные проблемы без необходимости разбираться в технических деталях вроде "претрейна" и "инференса". По ходу фильма мы видим как Алиса AI превращается в "эмпатичного ассистента", который понимает контекст пользователя и встраивается во все сервисы экосистемы - от браузера до роботов-доставщиков.
Если говорить про целевую аудиторию, то фильм нацелен широко
- Массовые пользователи: родители (упражнения для детей с логопедом), туристы (сборы снаряжения для треккинга), покупатели (поиск товаров со скидками до 30%)
- Профессионалы: юристы (анализ 100-страничных законопроектов), врачи (диагностика по МРТ), предприниматели (рабочие задачи через Алису Про)
- Tech-энтузиасты: любители промптинга (платформа Промптхаб), разработчики (70% сотрудников Яндекса используют ИИ ежедневно)
Фильм длится чуть больше часа и разделён на шесть тематических блоков с естественными переходами между "железом", софтом и стратегией:
1️⃣ Алиса AI: от чата до экосистемы
- Обогащённые ответы с картами, картинками, рецептами
- Примеры из жизни: турист собирает рюкзак для Непала и сокращает вес с 13 до 7–8 кг благодаря анализу Алисы; родитель генерирует логопедические загадки с буквой "Р"
- Креативная генерация: оживление чёрно-белых фото вызывает эмоции у пользователей
2️⃣ Промпты и агенты
- Промптхаб - платформа для обмена шаблонами
- Агенты - система на нейросетях, автоматизирующая цепочки действий (пример агента "Найти дешевле")
- НейроГусь - внутренняя премия Яндекса за ИИ-проекты
3️⃣ Интеграция в сервисы: Маркет как пример
- Поиск по естественным запросам: "Собери всё для приготовления ростбифа" → Алиса предлагает термометр, доски, ножи, уточняет бюджет
- Мультимодальный поиск: фото человека → анализ одежды → подбор «похожего лука» с учётом персональных предпочтений
4️⃣ Алиса Про и бизнес-кейсы
- Алиса Про: для корпоративных задач (интеграция в почту, диск, вики)
- Нейроюрист: анализ законопроектов, претензий, договоров. 75% юристов Яндекса используют инструмент, экономя 2 часа в неделю на 10 запросов.
- Кейс с ПВЗ Яндекс Маркета: новые сотрудники решают вопросы о возвратах и габаритах через Алису Про
5️⃣ ИИ + "железо"
- Устройства: наушники Дропс (запись заметок голосом), диктофон с суммаризацией встреч, IP-камера (сценарии: "Если кот на столе - запусти пылесос")
- Роботы-доставщики: 20 000 роверов к 2027 году в городах России (запуск в СПб, Казани, Иннополисе). Завод на 1500 роботов/месяц, каждый проходит 50 тестов и калибровку за 20 минут. Нейросети управляют навигацией, обходят препятствия в реальном времени
- Автономный грузовик: лидары, камеры, ИИ для манёвров (система обучалась на данных водителей)
6️⃣ Медицина и будущее
- МРТ-анализ для новорождённых: нейросеть определяет объёмы мозга и вещества для выявления рисков ДЦП, сокращая время анализа с дней до минут
- Будущее работы: ИИ не заменяет людей, а создаёт новые места (экономит рутину, усиливает креатив). 70% сотрудников Яндекса используют ИИ ежедневно (рост с 30% в 2023)
В общем, фильм позиционирует Яндекс как компанию, которая первой в России превратила ИИ из хайпа в утилитарный инструмент для миллионов - от мелкобытовых задач (сборка рюкзака) до критически важных (медицинская диагностика)
#AI #Software #Engineering #Economics #Software #Management #Leadership
YouTube
YaC 2025 AI Edition
YaC 2025 — это большой разговор про искусственный интеллект. Не про претрейн, инференс и другие сложные термины, а про реальные возможности, которые ИИ уже сегодня даёт пользователям — самым разным.
В чём польза ИИ для родителей, предпринимателей, юристов…
В чём польза ИИ для родителей, предпринимателей, юристов…
🔥4🦄3⚡2❤2👎2
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
🤖 Широкое внедрение ИИ-инструментов
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
🐍 Популярные языки программирования
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Pragmaticengineer
The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 1
Which tools do software engineers use for backend development, frontend, infrastructure, AI tooling, and more, today? Reader survey, with feedback and analysis, based on 3,000+ responses
❤5🔥2⚡1
Применение AI и LLM в разработке и управлении (Рубрика #AI)
Посмотрел на неделе выступление Александра Лукьянченко с конференции AvitoTechConf 2025, которую я посетил очно (но провел большую часть времени не за просмотром докладов, а общаясь со знакомыми и обсуждая примерно те же темы, но более открыто). Если же возвращаться к докладу Саши, то он поделился цифрами о том, как AI реально работает в процессах разработки внутри Авито. Сам Саша руководит разработкой PaaS внутри компании и его команда отвечает за эффективность 2000+ инженеров, внутренние инструменты, облако и SDLC.
Основные тезисы доклада примерно такие
⌨️ Кодинг - это не вся работа
Непосредственное написание кода занимает всего 20–40% времени инженера. Остальное - это коммуникация, дизайн систем, ревью и "археология" (разбор чужого кода). AI должен помогать именно здесь, а не только дописывать строки. Есть и другие сценарии, например
🗺 Авто-картирование архитектуры
В микросервисной архитектуре сложно понять, кто за что отвечает. В Avito использовали LLM, чтобы проанализировать код, API и README всех сервисов и разложить их по доменам.
Результат: Автоматика совпала с ручной разметкой экспертов на 80%. Сэкономлено ~200 человеко-дней ручной работы архитекторов.
☠️ Анализ постмортемов
Скормили LLM базу из 800+ инцидентов (postmortems). Модель нашла 22 системных паттерна проблем, которые не видели люди, и предложила сценарии для Chaos Engineering. Это позволило закрыть >1000 потенциальных уязвимостей.
⚙️ Эволюция инструментов
Ребята в индустрии переходят от фазы Copilot (автодополнение) к фазе Agents (автономное выполнение задач). В топе сейчас инструменты вроде Cline, Roo Code и режимы агентов в IDE, которые могут сами "ходить" по проекту и править файлы.
Что это значит для индустрии
1. Ощущение продуктивности обманчиво. Инженеры часто чувствуют, что стали работать быстрее с AI, но метрики говорят об обратном (особенно исследование METR на 16 инженеров, которое я разбирал). Если AI пишет много кода, который потом нужно долго дебажить - это не ускорение, а генерация техдолга.
2. Greenfield vs Brownfield. AI отлично бустит старт новых проектов (до 30-40%), но на старых, сложных легаси-проектах ("brownfield") прирост продуктивности падает до 0–10%, а иногда становится отрицательным из-за rework.
3. Сдвиг фокуса. Главная ценность AI сейчас не в написании кода, а в снижении когнитивной нагрузки (быстрый поиск по доке, саммари бесконечных тредов в Slack, объяснение легаси).
P.S.
Саша делал отсылку к исследованию Stanford на 120k инженеров. Недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) рассказывал новый доклад "Can you prove AI ROI in Software Engineering?" на эту тему на AI Engineer кофне и я его уже разбирал, там много интересного, рекомендую к просмотру.
#AI #DevOps #Engineering #Management #Leadership #Software #Architecture #SRE
Посмотрел на неделе выступление Александра Лукьянченко с конференции AvitoTechConf 2025, которую я посетил очно (но провел большую часть времени не за просмотром докладов, а общаясь со знакомыми и обсуждая примерно те же темы, но более открыто). Если же возвращаться к докладу Саши, то он поделился цифрами о том, как AI реально работает в процессах разработки внутри Авито. Сам Саша руководит разработкой PaaS внутри компании и его команда отвечает за эффективность 2000+ инженеров, внутренние инструменты, облако и SDLC.
Основные тезисы доклада примерно такие
Непосредственное написание кода занимает всего 20–40% времени инженера. Остальное - это коммуникация, дизайн систем, ревью и "археология" (разбор чужого кода). AI должен помогать именно здесь, а не только дописывать строки. Есть и другие сценарии, например
В микросервисной архитектуре сложно понять, кто за что отвечает. В Avito использовали LLM, чтобы проанализировать код, API и README всех сервисов и разложить их по доменам.
Результат: Автоматика совпала с ручной разметкой экспертов на 80%. Сэкономлено ~200 человеко-дней ручной работы архитекторов.
Скормили LLM базу из 800+ инцидентов (postmortems). Модель нашла 22 системных паттерна проблем, которые не видели люди, и предложила сценарии для Chaos Engineering. Это позволило закрыть >1000 потенциальных уязвимостей.
Ребята в индустрии переходят от фазы Copilot (автодополнение) к фазе Agents (автономное выполнение задач). В топе сейчас инструменты вроде Cline, Roo Code и режимы агентов в IDE, которые могут сами "ходить" по проекту и править файлы.
Что это значит для индустрии
1. Ощущение продуктивности обманчиво. Инженеры часто чувствуют, что стали работать быстрее с AI, но метрики говорят об обратном (особенно исследование METR на 16 инженеров, которое я разбирал). Если AI пишет много кода, который потом нужно долго дебажить - это не ускорение, а генерация техдолга.
2. Greenfield vs Brownfield. AI отлично бустит старт новых проектов (до 30-40%), но на старых, сложных легаси-проектах ("brownfield") прирост продуктивности падает до 0–10%, а иногда становится отрицательным из-за rework.
3. Сдвиг фокуса. Главная ценность AI сейчас не в написании кода, а в снижении когнитивной нагрузки (быстрый поиск по доке, саммари бесконечных тредов в Slack, объяснение легаси).
P.S.
Саша делал отсылку к исследованию Stanford на 120k инженеров. Недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) рассказывал новый доклад "Can you prove AI ROI in Software Engineering?" на эту тему на AI Engineer кофне и я его уже разбирал, там много интересного, рекомендую к просмотру.
#AI #DevOps #Engineering #Management #Leadership #Software #Architecture #SRE
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Применение AI и LLM в разработке и управлении | Александр Лукьянченко. AvitoTechConf 2025
GenAI инструменты позволяют решать и ускорять многие задачи, которые раньше было сложно автоматизировать. Мы часто слышим как AI заменяет целый класс задач в разработке, что инструменты вида Cursor сильно ускоряют вывод продуктов на рынок. Но как выглядит…
2👍16❤8🔥3👏1🤩1
[2/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
❤🔥 Инструменты разработки: любовь и ненависть
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
✈ Командная коммуникация и сотрудничество
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
🐘 Инфраструктура и базы данных
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
❤6🔥4👍3
[3/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды
1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.
Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.
Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.
В 2025 году перед командами стоит задача грамотной интеграции множества инструментов: от AI-помощников до облачных сервисов, от мониторинга до экспериментальных платформ. Те компании, которые сумеют подобрать оптимальный набор технологий и процессов, получают конкурентное преимущество в эффективности разработки и скорости вывода продукта на рынок.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды
1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.
Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.
Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.
В 2025 году перед командами стоит задача грамотной интеграции множества инструментов: от AI-помощников до облачных сервисов, от мониторинга до экспериментальных платформ. Те компании, которые сумеют подобрать оптимальный набор технологий и процессов, получают конкурентное преимущество в эффективности разработки и скорости вывода продукта на рынок.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
👍5❤3🔥2
[1/2] The state of AI in 2025. Agents, innovation, and transformation - Общие результаты исследования (Рубрика #AI)
Изучил интересный отчет от ноября 2025 года, что был подготовлен экспертами подразделения "QuantumBlack, AI by McKinsey" во главе с группой старших партнеров McKinsey. Мне было интересно сравнить его результаты с совместным отчетом "Яков и партнеры" (ex-McKinsey) и Яндекса, про которое я рассказывал раньше.
Исследование глобально McKinsey основано на онлайн-опросе, проведенном с 25 июня по 29 июля 2025 года. В опросе приняли участие 1 993 респондента из 105 стран, представляющие все основные регионы, отрасли, масштабы компаний, функциональные направления и уровни должностей. Около 38% участников работают в компаниях с выручкой более $1 млрд, а данные были взвешены по доле стран в глобальном ВВП для устранения перекосов.
Ключевые определения, которые используются по всему отчету и которые стоит знать при чтении
1) "Регулярное использование ИИ" определяется как применение ИИ хотя бы в одной бизнес-функции организации. Степень внедрения оценивалась по этапам
- Экспериментирование
- Пилотное внедрение
- Масштабирование (развертывание решений в масштабах компании)
- Полное масштабирование по всему предприятию
2) Авторы определили "агентные системы ИИ" (AI agents) как системы на основе foundation models, способные автономно действовать в реальном мире, планируя и выполняя многошаговые задачи
3) Под "AI high performers" (высокорезультативные компании в сфере ИИ) понимается небольшой сегмент (~6% опрошенных организаций), где благодаря ИИ достигается значимый эффект: более 5% совокупного EBIT компании и "существенная" бизнес-ценность напрямую обусловлены использованием ИИ. Именно практика этих лидеров рассматривается отдельно.
Executive summary приводится в самом начале отчета и выглядит так
1️⃣ Большинство организаций всё ещё на этапе экспериментов или пилотов
Почти две трети респондентов говорят, что их компании пока не начали масштабировать ИИ на уровень всей организации (enterprise-wide).
2️⃣ Высокий интерес к ИИ-агентам
62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3️⃣ Есть позитивные ранние сигналы влияния ИИ, но не на уровне всего бизнеса
Респонденты видят эффект в конкретных сценариях - снижение затрат и рост выручки; 64% считают, что ИИ помогает инновациям. Однако только 39% фиксируют влияние на EBIT на уровне компании в целом.
4️⃣ Лидеры по результатам используют ИИ не только для эффективности, но и для роста/инноваций
80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив. Но те, кто получает от ИИ максимальную ценность, часто добавляют цели роста или инноваций (а не ограничиваются срезанием затрат).
5️⃣ Перепроектирование процессов - ключевой фактор успеха
Половина "высокоэффективных" компаний планирует использовать ИИ для трансформации бизнеса, и большинство из них уже перерабатывают (redesign) рабочие процессы и цепочки выполнения задач.
6️⃣ Разные ожидания по влиянию на занятость
Оценки респондентов по тому, как ИИ повлияет на численность персонала в ближайший год, различаются: 32% ждут сокращения, 43% - без изменений, 13% - роста.
В продолжении я расскажу про стратегии высоко-эффективныхменеджеров команд, которые авторы отчета используют в качестве golden image или образца для подрожания, которому стоит следовать тем, кто еще не готов отчитаться об эффекте в 5% совокупного EBIT.
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Изучил интересный отчет от ноября 2025 года, что был подготовлен экспертами подразделения "QuantumBlack, AI by McKinsey" во главе с группой старших партнеров McKinsey. Мне было интересно сравнить его результаты с совместным отчетом "Яков и партнеры" (ex-McKinsey) и Яндекса, про которое я рассказывал раньше.
Исследование глобально McKinsey основано на онлайн-опросе, проведенном с 25 июня по 29 июля 2025 года. В опросе приняли участие 1 993 респондента из 105 стран, представляющие все основные регионы, отрасли, масштабы компаний, функциональные направления и уровни должностей. Около 38% участников работают в компаниях с выручкой более $1 млрд, а данные были взвешены по доле стран в глобальном ВВП для устранения перекосов.
Ключевые определения, которые используются по всему отчету и которые стоит знать при чтении
1) "Регулярное использование ИИ" определяется как применение ИИ хотя бы в одной бизнес-функции организации. Степень внедрения оценивалась по этапам
- Экспериментирование
- Пилотное внедрение
- Масштабирование (развертывание решений в масштабах компании)
- Полное масштабирование по всему предприятию
2) Авторы определили "агентные системы ИИ" (AI agents) как системы на основе foundation models, способные автономно действовать в реальном мире, планируя и выполняя многошаговые задачи
3) Под "AI high performers" (высокорезультативные компании в сфере ИИ) понимается небольшой сегмент (~6% опрошенных организаций), где благодаря ИИ достигается значимый эффект: более 5% совокупного EBIT компании и "существенная" бизнес-ценность напрямую обусловлены использованием ИИ. Именно практика этих лидеров рассматривается отдельно.
Executive summary приводится в самом начале отчета и выглядит так
1️⃣ Большинство организаций всё ещё на этапе экспериментов или пилотов
Почти две трети респондентов говорят, что их компании пока не начали масштабировать ИИ на уровень всей организации (enterprise-wide).
2️⃣ Высокий интерес к ИИ-агентам
62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3️⃣ Есть позитивные ранние сигналы влияния ИИ, но не на уровне всего бизнеса
Респонденты видят эффект в конкретных сценариях - снижение затрат и рост выручки; 64% считают, что ИИ помогает инновациям. Однако только 39% фиксируют влияние на EBIT на уровне компании в целом.
4️⃣ Лидеры по результатам используют ИИ не только для эффективности, но и для роста/инноваций
80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив. Но те, кто получает от ИИ максимальную ценность, часто добавляют цели роста или инноваций (а не ограничиваются срезанием затрат).
5️⃣ Перепроектирование процессов - ключевой фактор успеха
Половина "высокоэффективных" компаний планирует использовать ИИ для трансформации бизнеса, и большинство из них уже перерабатывают (redesign) рабочие процессы и цепочки выполнения задач.
6️⃣ Разные ожидания по влиянию на занятость
Оценки респондентов по тому, как ИИ повлияет на численность персонала в ближайший год, различаются: 32% ждут сокращения, 43% - без изменений, 13% - роста.
В продолжении я расскажу про стратегии высоко-эффективных
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
McKinsey & Company
The state of AI in 2025: Agents, innovation, and transformation
In this 2025 edition of the annual McKinsey Global Survey on AI, we look at the current trends that are driving real value from artificial intelligence.
👍8❤7🔥4
[2/2] The state of AI in 2025. Agents, innovation, and transformation - Стратегии высокоэффективных компаний (Рубрика #AI)
Заканчивая разбор этого отчета от McKinsey, я не смог пройти мимо самой интересной части исследования - сравнения обычных компаний с высокоэффективными 6% организаций, которые добились заметного влияния ИИ на бизнес. Эти лидеры разительно отличаются подходом. Исследователи McKinsey определяют их по двум критериям: >5% EBIT от ИИ и подтвержденная "значимая" ценность от использования ИИ. Авторы отчета используют эти компании в качестве golden image или образца для подрожания, которому стоит следовать тем, кто еще не готов отчитаться об эффекте в 5% совокупного EBIT.
Ниже расписаны отличия AI-стохановцев от остальных компаний
1️⃣ Лидеры ставят перед ИИ амбициозные цели
Половина таких компаний заявляет, что намерена с помощью ИИ трансформировать бизнес, а не просто улучшить эффективность. По опросу, они в 3+ раза чаще, чем остальные, нацелены на коренное переосмысление своих операций посредством ИИ. Эти компании воспринимают ИИ не как инструмент, а как новый "операционный механизм" организации.
2️⃣ High performers перестраивают рабочие процессы под ИИ
Они почти в 3 раза чаще других заявляют, что радикально перепроектировали отдельные рабочие потоки при внедрении ИИ. Это подтверждает статистика: фундаментальный redesign процессов - один из самых влиятельных факторов успеха (по результатам регрессионного анализа). Проще говоря, компании-лидеры не ограничиваются автоматизацией отдельных задач, а переосмысливают последовательность действий, роли людей и машин, и встраивают ИИ в сердце этих процессов. Такой подход требует больше усилий, но и приносит качественно иной уровень эффекта.
3️⃣ Лидеры распространяют ИИ шире и быстрее
Они применяют ИИ гораздо в большем числе функций и быстрее продвигаются в масштабировании пилотов. В большинстве функций high performers уже используют ИИ, а по работе с агентами они впереди других: в каждой бизнес-функции лидеры минимум втрое чаще продвинулись до стадии масштабирования агентов. Иначе говоря, если новая технология появляется, топ-6% стараются сразу внедрить ее широко.
4️⃣ Прямая отвественность топ-менеджмента за AI повестку
В таких компаниях в 3 раза чаще сильнее выражено согласие с тем, что их высшие руководители демонстрируют приверженность инициативам в области ИИ (берут на себя ответственность, лично продвигают использование ИИ). Лидеры не просто спонсируют, но и активно участвуют. Без этого культурного сдвига масштабные изменения трудно осуществить. Как отмечают авторы, культура и лидерство фактически становятся главным защитным барьером (moat) для таких компаний, отличая их от конкурентов
5️⃣ High performers больше инвестируют и системно подходят к развитию ИИ-способностей
Более одной трети лидеров тратят свыше 20% всего цифрового бюджета на ИИ - это почти в 5 раз чаще, чем остальные компании. Около 75% high performers уже находятся на стадии масштабирования ИИ или полностью масштабировали его, тогда как среди остальных этого достигли только 33%. Они также активнее нанимают специалистов по ИИ и закрывают ключевые пробелы в талантах и данных. Все высокоэффективные организации внедряют комплекс практик по шести измерениям (стратегия, таланты, операционная модель, технология, данные, внедрение и масштабирование). Например, лидеры чаще устанавливают чёткие процессы проверки вывода моделей человеком (чтобы контролировать качество), встроили ИИ-инструменты в основные бизнес-процессы и отслеживают KPI для ИИ-решений. Такая скрупулезность во внедрении обеспечивает им преимущество.
Ну и дальше, чтобы додавить всех не high performers эффектом FOMO (Fear of missing opportunity) надо добавить вывод, что топ-6% компаний обращают ИИ в конкурентное преимущество через рост, инновации и организационную трансформацию, тогда как многие другие застряли на уровне локальных улучшений. Это ведет к разрыву, где малая группа компаний уже сейчас переписывает правила работы, а остальные рискуют отстать
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Заканчивая разбор этого отчета от McKinsey, я не смог пройти мимо самой интересной части исследования - сравнения обычных компаний с высокоэффективными 6% организаций, которые добились заметного влияния ИИ на бизнес. Эти лидеры разительно отличаются подходом. Исследователи McKinsey определяют их по двум критериям: >5% EBIT от ИИ и подтвержденная "значимая" ценность от использования ИИ. Авторы отчета используют эти компании в качестве golden image или образца для подрожания, которому стоит следовать тем, кто еще не готов отчитаться об эффекте в 5% совокупного EBIT.
Ниже расписаны отличия AI-стохановцев от остальных компаний
1️⃣ Лидеры ставят перед ИИ амбициозные цели
Половина таких компаний заявляет, что намерена с помощью ИИ трансформировать бизнес, а не просто улучшить эффективность. По опросу, они в 3+ раза чаще, чем остальные, нацелены на коренное переосмысление своих операций посредством ИИ. Эти компании воспринимают ИИ не как инструмент, а как новый "операционный механизм" организации.
2️⃣ High performers перестраивают рабочие процессы под ИИ
Они почти в 3 раза чаще других заявляют, что радикально перепроектировали отдельные рабочие потоки при внедрении ИИ. Это подтверждает статистика: фундаментальный redesign процессов - один из самых влиятельных факторов успеха (по результатам регрессионного анализа). Проще говоря, компании-лидеры не ограничиваются автоматизацией отдельных задач, а переосмысливают последовательность действий, роли людей и машин, и встраивают ИИ в сердце этих процессов. Такой подход требует больше усилий, но и приносит качественно иной уровень эффекта.
3️⃣ Лидеры распространяют ИИ шире и быстрее
Они применяют ИИ гораздо в большем числе функций и быстрее продвигаются в масштабировании пилотов. В большинстве функций high performers уже используют ИИ, а по работе с агентами они впереди других: в каждой бизнес-функции лидеры минимум втрое чаще продвинулись до стадии масштабирования агентов. Иначе говоря, если новая технология появляется, топ-6% стараются сразу внедрить ее широко.
4️⃣ Прямая отвественность топ-менеджмента за AI повестку
В таких компаниях в 3 раза чаще сильнее выражено согласие с тем, что их высшие руководители демонстрируют приверженность инициативам в области ИИ (берут на себя ответственность, лично продвигают использование ИИ). Лидеры не просто спонсируют, но и активно участвуют. Без этого культурного сдвига масштабные изменения трудно осуществить. Как отмечают авторы, культура и лидерство фактически становятся главным защитным барьером (moat) для таких компаний, отличая их от конкурентов
5️⃣ High performers больше инвестируют и системно подходят к развитию ИИ-способностей
Более одной трети лидеров тратят свыше 20% всего цифрового бюджета на ИИ - это почти в 5 раз чаще, чем остальные компании. Около 75% high performers уже находятся на стадии масштабирования ИИ или полностью масштабировали его, тогда как среди остальных этого достигли только 33%. Они также активнее нанимают специалистов по ИИ и закрывают ключевые пробелы в талантах и данных. Все высокоэффективные организации внедряют комплекс практик по шести измерениям (стратегия, таланты, операционная модель, технология, данные, внедрение и масштабирование). Например, лидеры чаще устанавливают чёткие процессы проверки вывода моделей человеком (чтобы контролировать качество), встроили ИИ-инструменты в основные бизнес-процессы и отслеживают KPI для ИИ-решений. Такая скрупулезность во внедрении обеспечивает им преимущество.
Ну и дальше, чтобы додавить всех не high performers эффектом FOMO (Fear of missing opportunity) надо добавить вывод, что топ-6% компаний обращают ИИ в конкурентное преимущество через рост, инновации и организационную трансформацию, тогда как многие другие застряли на уровне локальных улучшений. Это ведет к разрыву, где малая группа компаний уже сейчас переписывает правила работы, а остальные рискуют отстать
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
❤6🔥4🙏3
Amp Code: Next generation AI Coding (Рубрика #AI)
Посмотрел интересный доклад Beyang Liu, CTO Sourcegraph, о новом редакторе Amp Code, в котором автор говорит о том, что это не просто "еще один Copilot", а попытка фундаментально изменить то, как мы взаимодействуем с AI в разработке. Если коротко: по мнению автора мы переходим от фазы "AI пишет текст" к фазе "AI замыкает цикл разработки". Сам Beyang Liu закончил Стэнфорд, а также успел поработать в Palantir и Google. Известен как создатель Sourcegraph (движок поиска по коду) и Cody (один из первых AI-ассистентов с контекстом кодовой базы). Он верит, что главное в AI-кодинге - это не генерация токенов, а доступ к графу знаний кода и runtime-окружению.
Основные тезисы доклада следующие
1️⃣ Смерть "Copilot-парадигмы"
Традиционные AI-ассистенты (GitHub Copilot, ранний Cody) работают как "умный автокомплит". Они предсказывают следующий токен, но не знают, работает ли этот код. Beyang называет это "Fire and Forget": AI выдал код, а разгребать ошибки компиляции - тебе.
2️⃣ Agentic Loop
Amp Code строит работу вокруг цикла OODA (Observe-Orient-Decide-Act)
- AI пишет код
- Сам запускает линтер/компилятор/тесты
- Видит ошибку (например,
- Исправляет её без участия человека.
- Повторяет, пока не заработает.
3️⃣ Контекст - это не только текст
Просто засунуть 100 файлов в контекстное окно (даже на 1M токенов) - недостаточно. Amp использует LSP (Language Server Protocol) и реальные данные из runtime, чтобы понимать структуру проекта так же, как её понимает IDE, а не просто как набор символов.
4️⃣ Режим "Review Agent"
В Amp встроен отдельный агент-ревьюер. Перед тем как применить изменения, он проводит Code Review: ищет баги, проверяет стиль и безопасность, имитируя процесс PR-ревью в команде.
🚀 Что это значит для разработки?
- Сдвиг скиллсета: От "быстрого набора кода" мы переходим к управлению агентами. Ваша задача - четко сформулировать намерение (Intent) и архитектуру, а реализацию (Implementation) и отладку берет на себя тул.
- Меньше Context Switching: Вам не нужно переключаться между редактором и терминалом, чтобы проверить, работает ли код, который выдал AI. Агент делает это фоном.
- Unix-way: Beyang подчеркивает, что Amp доступен и как VS Code extension, и как CLI-инструмент. Это возвращение к корням: мощные инструменты, которые можно скриптовать и встраивать в пайплайны.
В докладе и документации Amp, Beyang опирается на следующие концепции и материалы:
1. Agentic Workflows & Scaling Laws
Автор ссылается на то, что качество кода растет не линейно от размера модели, а скачкообразно при использовании agentic loops. Это подтверждается результатами бенчмарка SWE-bench, где агенты, умеющие запускать код, радикально обходят простые LLM. Подробнее про концепцию можно почитать у Andrew Ng
2. Sourcegraph’s "Big Code" Intelligence
База Amp - это технологии анализа графа кода (SCIP), которые Sourcegraph разрабатывает годами.
3. LSP как источник истины
Тезис о том, что LLM нужны структурированные данные от компилятора, а не просто текст. Это отсылка к Language Server Protocol, был разработан компанией Microsoft для своего редактора кода VS Code, но стал открытым стандартом и теперь активно развивается совместно с Red Hat и Codenvy, а сам проект размещен на GitHub, что позволяет использовать его в разных редакторах и для множества языков программировани
#AI #Software #Engineering #Architecture #Agents #ML #SystemDesign
Посмотрел интересный доклад Beyang Liu, CTO Sourcegraph, о новом редакторе Amp Code, в котором автор говорит о том, что это не просто "еще один Copilot", а попытка фундаментально изменить то, как мы взаимодействуем с AI в разработке. Если коротко: по мнению автора мы переходим от фазы "AI пишет текст" к фазе "AI замыкает цикл разработки". Сам Beyang Liu закончил Стэнфорд, а также успел поработать в Palantir и Google. Известен как создатель Sourcegraph (движок поиска по коду) и Cody (один из первых AI-ассистентов с контекстом кодовой базы). Он верит, что главное в AI-кодинге - это не генерация токенов, а доступ к графу знаний кода и runtime-окружению.
Основные тезисы доклада следующие
1️⃣ Смерть "Copilot-парадигмы"
Традиционные AI-ассистенты (GitHub Copilot, ранний Cody) работают как "умный автокомплит". Они предсказывают следующий токен, но не знают, работает ли этот код. Beyang называет это "Fire and Forget": AI выдал код, а разгребать ошибки компиляции - тебе.
2️⃣ Agentic Loop
Amp Code строит работу вокруг цикла OODA (Observe-Orient-Decide-Act)
- AI пишет код
- Сам запускает линтер/компилятор/тесты
- Видит ошибку (например,
TypeError)- Исправляет её без участия человека.
- Повторяет, пока не заработает.
3️⃣ Контекст - это не только текст
Просто засунуть 100 файлов в контекстное окно (даже на 1M токенов) - недостаточно. Amp использует LSP (Language Server Protocol) и реальные данные из runtime, чтобы понимать структуру проекта так же, как её понимает IDE, а не просто как набор символов.
4️⃣ Режим "Review Agent"
В Amp встроен отдельный агент-ревьюер. Перед тем как применить изменения, он проводит Code Review: ищет баги, проверяет стиль и безопасность, имитируя процесс PR-ревью в команде.
- Сдвиг скиллсета: От "быстрого набора кода" мы переходим к управлению агентами. Ваша задача - четко сформулировать намерение (Intent) и архитектуру, а реализацию (Implementation) и отладку берет на себя тул.
- Меньше Context Switching: Вам не нужно переключаться между редактором и терминалом, чтобы проверить, работает ли код, который выдал AI. Агент делает это фоном.
- Unix-way: Beyang подчеркивает, что Amp доступен и как VS Code extension, и как CLI-инструмент. Это возвращение к корням: мощные инструменты, которые можно скриптовать и встраивать в пайплайны.
В докладе и документации Amp, Beyang опирается на следующие концепции и материалы:
1. Agentic Workflows & Scaling Laws
Автор ссылается на то, что качество кода растет не линейно от размера модели, а скачкообразно при использовании agentic loops. Это подтверждается результатами бенчмарка SWE-bench, где агенты, умеющие запускать код, радикально обходят простые LLM. Подробнее про концепцию можно почитать у Andrew Ng
2. Sourcegraph’s "Big Code" Intelligence
База Amp - это технологии анализа графа кода (SCIP), которые Sourcegraph разрабатывает годами.
3. LSP как источник истины
Тезис о том, что LLM нужны структурированные данные от компилятора, а не просто текст. Это отсылка к Language Server Protocol, был разработан компанией Microsoft для своего редактора кода VS Code, но стал открытым стандартом и теперь активно развивается совместно с Red Hat и Codenvy, а сам проект размещен на GitHub, что позволяет использовать его в разных редакторах и для множества языков программировани
#AI #Software #Engineering #Architecture #Agents #ML #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Amp Code: Next Generation AI Coding – Beyang Liu, Amp Code
Introduction to Amp Code and its approach to AI-powered software development.
Speaker: Beyang Liu | Co-founder & CTO, Amp Code / Sourcegraph
https://x.com/beyang
https://www.linkedin.com/in/beyang-liu/
https://github.com/beyang
Timestamps:
00:00 Introduction…
Speaker: Beyang Liu | Co-founder & CTO, Amp Code / Sourcegraph
https://x.com/beyang
https://www.linkedin.com/in/beyang-liu/
https://github.com/beyang
Timestamps:
00:00 Introduction…
1❤9🔥5⚡3😁1
[1/2] Autonomy Is All You Need (Рубрика #Agents)
Посмотрел интересный доклад Michele Catasta, president & head of AI в Replit, который он рассказывал месяц назад на конференции AI Engineer. До этого Michele работал head of applied research в Google, а сейчас отвечает за всю AI‑стратегию Replit, который собирает прототипы приложений “с нуля до демки” за минуты. Вот основные тезисы его выступления
1️⃣ Автономия — главный измеримый прогресс в агентах
Кодовые ассистенты можно оценивать не только по качеству подсказок, а по тому, насколько далеко агент доходит сам, без человека “на ручнике”. Для нетехнических пользователей это вообще единственный смысл: либо агент способен сам довести задачу до результата, либо продукт для них бесполезен. Отсюда “north star”: степень автономии — ключевая метрика развития AI‑агентов в разработке, а не просто качество одного запроса.
2️⃣ Две фундаментальные способности для настоящей автономии
Michele выделяет два базовых кирпича автономного агента в разработке:
1. Автоматическое тестирование
Агент должен уметь сам проверять себя — через юнит‑тесты, интеграционные проверки, e2e‑сценарии, health‑чеки и т.д. Без автоматической валидации он либо:
- Нуждается в постоянном человеке‑ревьювере
- Либо будет “галлюцинировать” успешность и ломать прод
В Replit вокруг этого построен целый цикл: генерация кода → запуск тестов → анализ фейлов → автопочинка. Без этого никакой реальной автономии нет.
2. Продвинутый контекст‑менеджмент
Агент, который делает что‑то сложнее одного файла, обязан:
- Понимать структуру репозитория и артефактов
- Удерживать состояние долгих задач (дни/недели работы над проектом)
- Помнить решения, компромиссы и ограничения (memory)
- Управлять планом: что сделано, что сломано, какие подзадачи открыты
Без хорошего управления контекстом агент либо “забывает” важные детали через N шагов, либо начинает плодить противоречия в кодовой базе.
3️⃣ После автономии — параллелизм как ключ к UX
Когда агент может действовать сам, следующая проблема — как сделать так, чтобы пользователю не приходилось ждать вечность. Michele разбирает несколько моделей параллелизации:
- Task‑level parallelism. Декомпозиция работы на независимые подзадачи: генерация фронта, бэка, конфигов, тестов и т.п. в разных “ветках” выполнения. Это снижает latency и даёт раннюю обратную связь: пользователь видит прогресс по частям, а не ждёт один гигантский ответ.
- Out‑of‑order execution. Не обязательно выполнять задачи строго в порядке плана, если есть независимые куски, которые можно тащить вперёд. Похожая идея на out‑of‑order в CPU: выигрыш по времени, но нужно аккуратно работать с зависимостями.
- Параллельная план‑декомпозиция. Не один линейный “Chain of Thought”, а дерево плана, где разные ветки могут развиваться отдельно и потом схлопываться. Это повышает устойчивость: можно откатываться не “ко всему началу”, а к узлу дерева.
Ключевая идея: последовательный агент = плохой UX. Пользователь залипает в ожидании и теряет flow. Настоящий “AI engineer experience” — это когда агент шуршит параллельно по нескольким направлениям, а человек видит понятный прогресс.
4️⃣ Баланс: latency vs ресурсы vs корректность**
Как только добавляем параллелизм и автономию, начинается классическая инженерная тройка:
- Меньше latency → больше параллельных веток → выше расход токенов/вычислений.
- Больше автономии → меньше человеческого контроля → выше риск некорректных изменений.
- Жёсткие гарантии корректности → больше проверок/ручных подтверждений → хуже UX.
Michele по сути говорит: нет “магического” решения. Нужно явно проектировать эту тройку под свой продукт:
- где мы готовы платить вычислительными ресурсами ради вау‑эффекта;
- где ради безопасности согласны пожертвовать скоростью;
- где нужна явная точка “здесь всегда спрашиваем человека”.
В продолжении будут мысли о том, а что можно извлечь инженерам при создании своих автономных агентов.
P.S.
Кстати, историю Replit хорошо рассказал Амджада Масада (CEO) в интервью Y Combinator летом (см. мой разбор)
#AI #ML #Agents #Software #Engineering #Architecture
Посмотрел интересный доклад Michele Catasta, president & head of AI в Replit, который он рассказывал месяц назад на конференции AI Engineer. До этого Michele работал head of applied research в Google, а сейчас отвечает за всю AI‑стратегию Replit, который собирает прототипы приложений “с нуля до демки” за минуты. Вот основные тезисы его выступления
1️⃣ Автономия — главный измеримый прогресс в агентах
Кодовые ассистенты можно оценивать не только по качеству подсказок, а по тому, насколько далеко агент доходит сам, без человека “на ручнике”. Для нетехнических пользователей это вообще единственный смысл: либо агент способен сам довести задачу до результата, либо продукт для них бесполезен. Отсюда “north star”: степень автономии — ключевая метрика развития AI‑агентов в разработке, а не просто качество одного запроса.
2️⃣ Две фундаментальные способности для настоящей автономии
Michele выделяет два базовых кирпича автономного агента в разработке:
1. Автоматическое тестирование
Агент должен уметь сам проверять себя — через юнит‑тесты, интеграционные проверки, e2e‑сценарии, health‑чеки и т.д. Без автоматической валидации он либо:
- Нуждается в постоянном человеке‑ревьювере
- Либо будет “галлюцинировать” успешность и ломать прод
В Replit вокруг этого построен целый цикл: генерация кода → запуск тестов → анализ фейлов → автопочинка. Без этого никакой реальной автономии нет.
2. Продвинутый контекст‑менеджмент
Агент, который делает что‑то сложнее одного файла, обязан:
- Понимать структуру репозитория и артефактов
- Удерживать состояние долгих задач (дни/недели работы над проектом)
- Помнить решения, компромиссы и ограничения (memory)
- Управлять планом: что сделано, что сломано, какие подзадачи открыты
Без хорошего управления контекстом агент либо “забывает” важные детали через N шагов, либо начинает плодить противоречия в кодовой базе.
3️⃣ После автономии — параллелизм как ключ к UX
Когда агент может действовать сам, следующая проблема — как сделать так, чтобы пользователю не приходилось ждать вечность. Michele разбирает несколько моделей параллелизации:
- Task‑level parallelism. Декомпозиция работы на независимые подзадачи: генерация фронта, бэка, конфигов, тестов и т.п. в разных “ветках” выполнения. Это снижает latency и даёт раннюю обратную связь: пользователь видит прогресс по частям, а не ждёт один гигантский ответ.
- Out‑of‑order execution. Не обязательно выполнять задачи строго в порядке плана, если есть независимые куски, которые можно тащить вперёд. Похожая идея на out‑of‑order в CPU: выигрыш по времени, но нужно аккуратно работать с зависимостями.
- Параллельная план‑декомпозиция. Не один линейный “Chain of Thought”, а дерево плана, где разные ветки могут развиваться отдельно и потом схлопываться. Это повышает устойчивость: можно откатываться не “ко всему началу”, а к узлу дерева.
Ключевая идея: последовательный агент = плохой UX. Пользователь залипает в ожидании и теряет flow. Настоящий “AI engineer experience” — это когда агент шуршит параллельно по нескольким направлениям, а человек видит понятный прогресс.
4️⃣ Баланс: latency vs ресурсы vs корректность**
Как только добавляем параллелизм и автономию, начинается классическая инженерная тройка:
- Меньше latency → больше параллельных веток → выше расход токенов/вычислений.
- Больше автономии → меньше человеческого контроля → выше риск некорректных изменений.
- Жёсткие гарантии корректности → больше проверок/ручных подтверждений → хуже UX.
Michele по сути говорит: нет “магического” решения. Нужно явно проектировать эту тройку под свой продукт:
- где мы готовы платить вычислительными ресурсами ради вау‑эффекта;
- где ради безопасности согласны пожертвовать скоростью;
- где нужна явная точка “здесь всегда спрашиваем человека”.
В продолжении будут мысли о том, а что можно извлечь инженерам при создании своих автономных агентов.
P.S.
Кстати, историю Replit хорошо рассказал Амджада Масада (CEO) в интервью Y Combinator летом (см. мой разбор)
#AI #ML #Agents #Software #Engineering #Architecture
YouTube
Autonomy Is All You Need – Michele Catasta, Replit
AI agents exhibit vastly different degrees of autonomy. Yet, the ability to accomplish objectives without supervision is the critical north star for agent progress, especially in software creation. For non-technical users who cannot supervise software creation…
🔥5❤2👍1
[2/2] Autonomy Is All You Need (Рубрика #Agents)
Продолжая рассказ про доклад Michele Catasta, president & head of AI в Replit, хочется поделиться выводами о том, что может быть полезно инженерам из этого доклада
1️⃣ “Автономность” надо проектировать как фичу, а не надеяться на модель
Если вы делаете собственный агент/код‑ассистент, важно принять позицию Michele: автономия — это не свойство модели, это свойство системы.
Нужно осознанно строить:
- Слой автоматического тестирования и валидации
- Модели работы с репозиторием и долгим контекстом
- Архитектуру планирования/параллелизации
- Политику откатов и ошибок (recovery)
Иначе вы получаете “очень умный autocomplete”, а не агента.
2️⃣ Автотесты и CI/CD превращаются из “инженерной гигиены” в API для агента
Для команд разработки это переворачивает отношение к тестам и инфраструктуре:
- Хорошее покрытие тестами и быстрый CI — это не только про людей, а про то, чтобы агенты могли безопасно модифицировать систему.
- “Red → Green → Refactor” становится циклом не только для человека, но и для агента.
- Инфраструктура (test env, staging, feature flags) — это уже операционная среда для автономного агента, а не просто удобство для разработчика.
Если вы хотите в будущем доверять агенту делать миграции, фичи и рефакторинги, ему нужно:
- Где запускать код изолированно
- Как проверять, что ничего не сломано
- Куда откатываться, если сломано
3️⃣ Контекст‑менеджмент как новый слой архитектуры продукта
Архитектурно, “context management” для агента — это почти отдельный сервис:
- Индекс кода и артефактов (vector + структурные индексы);
- Долговременная память решений (design docs для агента);
- История траекторий (что агент делал, что сработало, что нет);
- Слой планирования, который может:
-- Резать задачи на подзадачи
-- Отслеживать прогресс
-- Решать, что можно делать параллельно
Это очень похоже на добавление “оркестратора” в микросервисную архитектуру, только теперь мы оркестрируем не сервисы, а действия модели.
4️⃣ Параллелизм в агентах = новые паттерны UX и DevEx
Для технических руководителей и платформенных команд:
- Нужно думать не только о том, как агент “правильно пишет код”, но и о том, как пользователь переживает его работу:
-- Показывает ли агент понятный прогресс;
-- Может ли пользователь вмешаться/скорректировать план;
-- Как отображаются параллельные ветки (логи, диаграммы, “job view”).
- План‑ориентированный UI (как в Replit Agent, LangGraph‑подобных системах) становится новым стандартом: разработчики хотят видеть траекторию агента, а не чёрный ящик.
5️⃣ Стратегический вывод: “AI‑инфраструктура” станет нормой для дев‑команд
Если принять аргументацию Michele всерьёз, ближайшие 2–3 года для инженеров и техлидов означают:
- Надо вкладываться в:
-- Тестируемость/наблюдаемость кода;
-- Явное моделирование домена (чтобы агенту было чем оперировать);
-- Инфраструктуру для экспериментов с агентами (sandbox, telemetry, safety‑rails).
- Нужно перестать мыслить агентом как “персональным Copilot’ом”;
агент — это участник команды, который:
-- Идёт по задачам бэклога,
-- Делает изменения,
-- Проходит те же quality‑гейты, что и человек (тесты, ревью, линтеры).
#AI #ML #Agents #Software #Engineering #Architecture
Продолжая рассказ про доклад Michele Catasta, president & head of AI в Replit, хочется поделиться выводами о том, что может быть полезно инженерам из этого доклада
1️⃣ “Автономность” надо проектировать как фичу, а не надеяться на модель
Если вы делаете собственный агент/код‑ассистент, важно принять позицию Michele: автономия — это не свойство модели, это свойство системы.
Нужно осознанно строить:
- Слой автоматического тестирования и валидации
- Модели работы с репозиторием и долгим контекстом
- Архитектуру планирования/параллелизации
- Политику откатов и ошибок (recovery)
Иначе вы получаете “очень умный autocomplete”, а не агента.
2️⃣ Автотесты и CI/CD превращаются из “инженерной гигиены” в API для агента
Для команд разработки это переворачивает отношение к тестам и инфраструктуре:
- Хорошее покрытие тестами и быстрый CI — это не только про людей, а про то, чтобы агенты могли безопасно модифицировать систему.
- “Red → Green → Refactor” становится циклом не только для человека, но и для агента.
- Инфраструктура (test env, staging, feature flags) — это уже операционная среда для автономного агента, а не просто удобство для разработчика.
Если вы хотите в будущем доверять агенту делать миграции, фичи и рефакторинги, ему нужно:
- Где запускать код изолированно
- Как проверять, что ничего не сломано
- Куда откатываться, если сломано
3️⃣ Контекст‑менеджмент как новый слой архитектуры продукта
Архитектурно, “context management” для агента — это почти отдельный сервис:
- Индекс кода и артефактов (vector + структурные индексы);
- Долговременная память решений (design docs для агента);
- История траекторий (что агент делал, что сработало, что нет);
- Слой планирования, который может:
-- Резать задачи на подзадачи
-- Отслеживать прогресс
-- Решать, что можно делать параллельно
Это очень похоже на добавление “оркестратора” в микросервисную архитектуру, только теперь мы оркестрируем не сервисы, а действия модели.
4️⃣ Параллелизм в агентах = новые паттерны UX и DevEx
Для технических руководителей и платформенных команд:
- Нужно думать не только о том, как агент “правильно пишет код”, но и о том, как пользователь переживает его работу:
-- Показывает ли агент понятный прогресс;
-- Может ли пользователь вмешаться/скорректировать план;
-- Как отображаются параллельные ветки (логи, диаграммы, “job view”).
- План‑ориентированный UI (как в Replit Agent, LangGraph‑подобных системах) становится новым стандартом: разработчики хотят видеть траекторию агента, а не чёрный ящик.
5️⃣ Стратегический вывод: “AI‑инфраструктура” станет нормой для дев‑команд
Если принять аргументацию Michele всерьёз, ближайшие 2–3 года для инженеров и техлидов означают:
- Надо вкладываться в:
-- Тестируемость/наблюдаемость кода;
-- Явное моделирование домена (чтобы агенту было чем оперировать);
-- Инфраструктуру для экспериментов с агентами (sandbox, telemetry, safety‑rails).
- Нужно перестать мыслить агентом как “персональным Copilot’ом”;
агент — это участник команды, который:
-- Идёт по задачам бэклога,
-- Делает изменения,
-- Проходит те же quality‑гейты, что и человек (тесты, ревью, линтеры).
#AI #ML #Agents #Software #Engineering #Architecture
Telegram
Книжный куб
[1/2] Autonomy Is All You Need (Рубрика #Agents)
Посмотрел интересный доклад Michele Catasta, president & head of AI в Replit, который он рассказывал месяц назад на конференции AI Engineer. До этого Michele работал head of applied research в Google, а сейчас…
Посмотрел интересный доклад Michele Catasta, president & head of AI в Replit, который он рассказывал месяц назад на конференции AI Engineer. До этого Michele работал head of applied research в Google, а сейчас…
❤6☃3🎄3
The Truth About The AI Bubble (Рубрика #AI)
Очередной эпизод подкаста Lightcone от ребят из Y Combinator был посвящен теме пузыря AI, поэтому я посмотрел его с большим интересом. Ребята успели обсудить следующие темы
1️⃣ Anthropic стал №1 среди YC-стартапов
Стартапы из Winter 26 batch YC стали использовать чаще Anthropic модели, а не OpenAI:
- Anthropic Claude: 52% (был ~20-25% в 2024)
- OpenAI: упал с 90%+ до <50%
- Google Gemini: 23% (был в single-digit)
Гипотезы авторов о том, почему Claude впереди
- Лучшая модель для coding
- Enterprise market share: 32% vs OpenAI 25%
- Фокус на safety и надежности для корпораций
- Целенаправленная оптимизация под coding (northstar eval от Tom Brown, co-founder Anthropic)
2️⃣ Vibe Coding стал мейнстримом
Выглядит это как
- Разработка через описание задачи на естественном языке LLM
- Генерация кода без детального review
- Фокус на итерациях и результате, а не на структуре кода
Популярные инструменты:
- Cursor (VS Code + GPT-4o/Claude)
- Claude Code от Anthropic
- GitHub Copilot, Lovable, Replit, Bolt
3️⃣ AI-экономика стабилизировалась
По мнению одного из партнеров нс Jared Friedman: "Самое удивительное для меня — насколько стабилизировалась AI-экономика. У нас есть компании модельного слоя, прикладного слоя и инфраструктурного слоя. Кажется, что все будут зарабатывать много денег, и есть относительно понятный playbook для построения AI-native компании поверх моделей."
Что изменилось:
- Раньше каждые несколько месяцев новые релизы моделей делали возможными совершенно новые идеи → легко было pivot
- Теперь поиск стартап-идей вернулся к "нормальному уровню сложности"
4️⃣ Модели превращают друг друга в commodity
Стартапы строят orchestration layer и переключаются между моделями:
- Используют Gemini 2.0 для context engineering
- Затем передают в OpenAI для execution
Выбор модели основан на proprietary evals для specific задач
Аналогия: как эпоха Intel/AMD — конкуренция архитектур, но пользователи могут их взаимно заменять
Что это значит:
- Ценность смещается с моделей на application layer
- Модельные компании коммодитизируют друг друга
- Application-layer стартапы получают преимущество
5️⃣ AI Bubble — это хорошая новость для стартапов
Ребята вспоминают пузырь доткомов, что привел к инвестициям в инфру, а дальше поверх этого пришел условный YouTube и смог существовать — дешевый bandwidth был результатом пузыря
Сейчас:
- Большие компании (Meta, Google, OpenAI) должны инвестировать capex в GPU и дата-центры
- Если спрос упадет — это их capex, не стартапов
- Инфраструктура останется и будет дешевой
Ребята вспоминают про фреймворк Carlota Perez, в котором есть две фазы: installation phase (сейчас), deployment phase (следующие x лет). В первой фазе CAPEX расходы, а во второй создание экономической ценности и появление новых bigtech компаний аля Google.
6️⃣ Космос как решение energy bottleneck
Как оказалось для AI bubble недостаточно электроэнергии на Земле - нечем запитать AI дата-центры. А дальше история
- Лето 2024: StarCloud предложила дата-центры в космосе → люди смеялись
- 18 месяцев спустя: Google и Elon Musk делают это
7️⃣ Больше стартапов делают специализированные модели
Harj отмечает рост интереса к созданию smaller, specialized models в последних YC batches:
- Edge device models
- Voice models для specific языков
- Domain-specific models
Аналогия: как в ранние дни YC знания о стартапах стали распространенными → explosion SaaS-компаний. Сейчас знания о training models становятся common knowledge.
#AI #Engineering #ML #Architecture #Software #Economics #Future
Очередной эпизод подкаста Lightcone от ребят из Y Combinator был посвящен теме пузыря AI, поэтому я посмотрел его с большим интересом. Ребята успели обсудить следующие темы
1️⃣ Anthropic стал №1 среди YC-стартапов
Стартапы из Winter 26 batch YC стали использовать чаще Anthropic модели, а не OpenAI:
- Anthropic Claude: 52% (был ~20-25% в 2024)
- OpenAI: упал с 90%+ до <50%
- Google Gemini: 23% (был в single-digit)
Гипотезы авторов о том, почему Claude впереди
- Лучшая модель для coding
- Enterprise market share: 32% vs OpenAI 25%
- Фокус на safety и надежности для корпораций
- Целенаправленная оптимизация под coding (northstar eval от Tom Brown, co-founder Anthropic)
2️⃣ Vibe Coding стал мейнстримом
Выглядит это как
- Разработка через описание задачи на естественном языке LLM
- Генерация кода без детального review
- Фокус на итерациях и результате, а не на структуре кода
Популярные инструменты:
- Cursor (VS Code + GPT-4o/Claude)
- Claude Code от Anthropic
- GitHub Copilot, Lovable, Replit, Bolt
3️⃣ AI-экономика стабилизировалась
По мнению одного из партнеров нс Jared Friedman: "Самое удивительное для меня — насколько стабилизировалась AI-экономика. У нас есть компании модельного слоя, прикладного слоя и инфраструктурного слоя. Кажется, что все будут зарабатывать много денег, и есть относительно понятный playbook для построения AI-native компании поверх моделей."
Что изменилось:
- Раньше каждые несколько месяцев новые релизы моделей делали возможными совершенно новые идеи → легко было pivot
- Теперь поиск стартап-идей вернулся к "нормальному уровню сложности"
4️⃣ Модели превращают друг друга в commodity
Стартапы строят orchestration layer и переключаются между моделями:
- Используют Gemini 2.0 для context engineering
- Затем передают в OpenAI для execution
Выбор модели основан на proprietary evals для specific задач
Аналогия: как эпоха Intel/AMD — конкуренция архитектур, но пользователи могут их взаимно заменять
Что это значит:
- Ценность смещается с моделей на application layer
- Модельные компании коммодитизируют друг друга
- Application-layer стартапы получают преимущество
5️⃣ AI Bubble — это хорошая новость для стартапов
Ребята вспоминают пузырь доткомов, что привел к инвестициям в инфру, а дальше поверх этого пришел условный YouTube и смог существовать — дешевый bandwidth был результатом пузыря
Сейчас:
- Большие компании (Meta, Google, OpenAI) должны инвестировать capex в GPU и дата-центры
- Если спрос упадет — это их capex, не стартапов
- Инфраструктура останется и будет дешевой
Ребята вспоминают про фреймворк Carlota Perez, в котором есть две фазы: installation phase (сейчас), deployment phase (следующие x лет). В первой фазе CAPEX расходы, а во второй создание экономической ценности и появление новых bigtech компаний аля Google.
6️⃣ Космос как решение energy bottleneck
Как оказалось для AI bubble недостаточно электроэнергии на Земле - нечем запитать AI дата-центры. А дальше история
- Лето 2024: StarCloud предложила дата-центры в космосе → люди смеялись
- 18 месяцев спустя: Google и Elon Musk делают это
7️⃣ Больше стартапов делают специализированные модели
Harj отмечает рост интереса к созданию smaller, specialized models в последних YC batches:
- Edge device models
- Voice models для specific языков
- Domain-specific models
Аналогия: как в ранние дни YC знания о стартапах стали распространенными → explosion SaaS-компаний. Сейчас знания о training models становятся common knowledge.
#AI #Engineering #ML #Architecture #Software #Economics #Future
YouTube
The Truth About The AI Bubble
2025 was the year AI stopped feeling chaotic and started feeling buildable. In this Lightcone episode, the YC partners break down the surprises of the year, from shifting model dominance to why the real opportunity is moving back to the application layer…
👍7❤3🔥1
RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos (Рубрика #Architecture)
Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)
Если же говорить про основные тезисы доклада изложены ниже
Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "
Не только люди страдают от такого качества документации - AI-агенты страдают тоже, так как им нужен контекст для правильных решений (какой UI-компонент использовать, как вызывать внутренний сервис).
Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)
Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история
Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)
В каких реальных кейсах этот инструмент использовался автором
1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs
Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign
Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)
Если же говорить про основные тезисы доклада изложены ниже
Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "
Не только люди страдают от такого качества документации - AI-агенты страдают тоже, так как им нужен контекст для правильных решений (какой UI-компонент использовать, как вызывать внутренний сервис).
Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)
Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история
Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)
В каких реальных кейсах этот инструмент использовался автором
1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs
Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign
YouTube
RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos - Roy Osherove
more info at https://robotpaper.ai by Roy Osherove.
This talk explores RepoSwarm, an AI-first developer tool for giving LLM-powered coding agents deep, accurate context across large multi-repository codebases. Instead of relying on stale READMEs or static…
This talk explores RepoSwarm, an AI-first developer tool for giving LLM-powered coding agents deep, accurate context across large multi-repository codebases. Instead of relying on stale READMEs or static…
🔥7❤5👍3☃1🎄1
[1/2] Hard Won Lessons from Building Effective AI Coding Agents (Рубрика #Agents)
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал инженером в Meta Reality Labs (2019-2021), Yandex (Image Search), Samsung Electronics. Основные тезисы доклада следующие
1️⃣ Горькая правда в том, что scaffolding устарел
Годами разработчики компенсировали слабость моделей clever scaffolding'ом: RAG-индексацией, search trees, хитрыми системами tool calling. Проблема в том, что сейчас frontier-модели побеждают без этих абстракций. То есть capability beats scaffolding. Ник приводит пример Gemini 3.0, что вышел недавно и сразу возглавил Terminal-Bench leaderboard с результатом 54.2% без какой-то агентской обвязки (если глянуть сейчас, то в лидер борде впереди все-таки agentic + model комбинации). Кстати, Terminal-Bench — это интересный "unopinionated generic stripped down harness". Там нет никакого graph search, RAG, индексации — только терминал и задача "разберись сам"
2️⃣ Context engineering tricks — played out
Ник откровенно говорит, что вместо отдельных трюков для контекста теперь есть стандартный playbook для поддержки каждой новой модели (Sonnet 4 → 4.5, Gemini 2.5 → 3.0, GPT-5 → 5.1). Tweaks тривиальны, выигрыши маргинальны. По мнению Ника эта тема исчерпана. Новизны в ней не осталось.
3️⃣ Настоящий bottleneck — это бенчмарки и среды для RL (reinforcement learning)
Собственно тут зарыта основная мысль доклада: можно построить cleanest agent в мире, но это не улучшит capability модели даже на 1%. Ник говорит
По его мнению модели не "вдруг стали лучше" в использовании инструментов — они стали лучше, потому что построены RL environments, которые заставили их практиковать конкретные действия: обработку моделей отказов, повторов, обработки ошибок. Каждый скачок в reasoning пришел из benchmark'а. Каждый скачок в agent reliability — из RL environment.
Дальше Ник рассказывает как превратить задачи реального мира в данные для тренировок. Cline построил систему под названием "RL Environments Factory" — pipeline для автоматического превращения реальных coding задач в RL environments для обучения моделей. Выглядит это так
Phase 1: Qualification — фильтрация задач
Sub-агенты работают параллельно, проверяя, подходит ли задача для превращения в RL environment:
- Origins: существует ли репозиторий? Доступен ли starting commit? Open source?
- Journey: что пользователь на самом деле пытался решить? Какова была суть задачи?
- Outcome: можем ли найти commits/PRs, которые решили проблему в реальности?
Откидываются задачи вида: вайбкодинговвый slop, тривиальные задачи, задачи без надежных start/end states[4]
Phase 2: Building RL Environment
- Archaeology: реконструировать оба состояния (до/после) локально
- Documentation: задокументировать все obstacles и dependencies
- Containerization: упаковать в Docker, убрать Git (чтобы агенты не могли reward hack)
- Verifier: определить, как проверять результат
Интересно, что примерно этим же подходом пользовались ребята из whitepaper "Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks", о котором я рассказывал раньше.
4️⃣ Все делают RL environments но никто ими не делится
И тут Ник открыто говорит о том, что каждая крупная agent lab собирает эти данные, то есть все делают какую-то версию RL environment building за кулисами. Но никто не говорит об этом. Эти компании ссылаются на internal benchmarks, но вы никогда не сможете их изучить, потому что они не публикуют их открыто. Эти данные настолько ценны, что их никто не шарит. Agent labs стоят между реальными инженерами, работающими над реальными задачами, и моделями — у них уникальная роль в истории.
В продолжении я расскажу, а что предлагают ребята из Cline, чтобы улучшить ситуацию
#AI #ML #Agents #Software #Engineering #Architecture
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал инженером в Meta Reality Labs (2019-2021), Yandex (Image Search), Samsung Electronics. Основные тезисы доклада следующие
1️⃣ Горькая правда в том, что scaffolding устарел
Годами разработчики компенсировали слабость моделей clever scaffolding'ом: RAG-индексацией, search trees, хитрыми системами tool calling. Проблема в том, что сейчас frontier-модели побеждают без этих абстракций. То есть capability beats scaffolding. Ник приводит пример Gemini 3.0, что вышел недавно и сразу возглавил Terminal-Bench leaderboard с результатом 54.2% без какой-то агентской обвязки (если глянуть сейчас, то в лидер борде впереди все-таки agentic + model комбинации). Кстати, Terminal-Bench — это интересный "unopinionated generic stripped down harness". Там нет никакого graph search, RAG, индексации — только терминал и задача "разберись сам"
2️⃣ Context engineering tricks — played out
Ник откровенно говорит, что вместо отдельных трюков для контекста теперь есть стандартный playbook для поддержки каждой новой модели (Sonnet 4 → 4.5, Gemini 2.5 → 3.0, GPT-5 → 5.1). Tweaks тривиальны, выигрыши маргинальны. По мнению Ника эта тема исчерпана. Новизны в ней не осталось.
3️⃣ Настоящий bottleneck — это бенчмарки и среды для RL (reinforcement learning)
Собственно тут зарыта основная мысль доклада: можно построить cleanest agent в мире, но это не улучшит capability модели даже на 1%. Ник говорит
Models only get better when labs train on something hard. And benchmarks, not agent cleverness... determine what frontier models learn to do next.
По его мнению модели не "вдруг стали лучше" в использовании инструментов — они стали лучше, потому что построены RL environments, которые заставили их практиковать конкретные действия: обработку моделей отказов, повторов, обработки ошибок. Каждый скачок в reasoning пришел из benchmark'а. Каждый скачок в agent reliability — из RL environment.
Дальше Ник рассказывает как превратить задачи реального мира в данные для тренировок. Cline построил систему под названием "RL Environments Factory" — pipeline для автоматического превращения реальных coding задач в RL environments для обучения моделей. Выглядит это так
Phase 1: Qualification — фильтрация задач
Sub-агенты работают параллельно, проверяя, подходит ли задача для превращения в RL environment:
- Origins: существует ли репозиторий? Доступен ли starting commit? Open source?
- Journey: что пользователь на самом деле пытался решить? Какова была суть задачи?
- Outcome: можем ли найти commits/PRs, которые решили проблему в реальности?
Откидываются задачи вида: вайбкодинговвый slop, тривиальные задачи, задачи без надежных start/end states[4]
Phase 2: Building RL Environment
- Archaeology: реконструировать оба состояния (до/после) локально
- Documentation: задокументировать все obstacles и dependencies
- Containerization: упаковать в Docker, убрать Git (чтобы агенты не могли reward hack)
- Verifier: определить, как проверять результат
Интересно, что примерно этим же подходом пользовались ребята из whitepaper "Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks", о котором я рассказывал раньше.
4️⃣ Все делают RL environments но никто ими не делится
И тут Ник открыто говорит о том, что каждая крупная agent lab собирает эти данные, то есть все делают какую-то версию RL environment building за кулисами. Но никто не говорит об этом. Эти компании ссылаются на internal benchmarks, но вы никогда не сможете их изучить, потому что они не публикуют их открыто. Эти данные настолько ценны, что их никто не шарит. Agent labs стоят между реальными инженерами, работающими над реальными задачами, и моделями — у них уникальная роль в истории.
В продолжении я расскажу, а что предлагают ребята из Cline, чтобы улучшить ситуацию
#AI #ML #Agents #Software #Engineering #Architecture
❤5👍3❤🔥2
[2/2] Hard Won Lessons from Building Effective AI Coding Agents (Рубрика #Agents)
Продолжая рассказ про этот доклад, надо рассказать про Cline-Bench - open source benchmark для реальных задач, который анонсирует Cline. Каждая задача внутри бенча это:
- Starting repo snapshot (git commit hash)
- Real prompt from user
- Ground truth tests на основе кода, который реально зашипился
Этот бенч
- Полностью open source, no secret sauce, no locked datasets
- Любой может использовать для SFT, RL, eval
- Любой может поучаствовать
Как контрибьютить
1. Работайте над open source проектом с включенным Cline Provider
2. Opt into cline-bench initiative
3. Если frontier model застрял и вы вмешались, чтобы починить — это идеальный кандидат для benchmark
В общем, просто используйте Cline, наблюдайте, где модель struggles, и Cline подберет эти задачи в open-source benchmark.
P.S.
Если подбивать мысли из доклада, то можно вынести следующее
1. Для инженеров, использующих AI coding agents
- Перестаньте over-engineering scaffolding. Проще = лучше
- Фокусируйтесь на capability модели, а не на умных абстракциях
- Ваши real-world failure cases — самые ценные данные для экосистемы
- Contribution в open benchmarks помогает всем
2. Для исследователей и разработчиков моделей
- Сдвиг от scaffolding tricks к environment design
- Качество верификатора критично: надо ориентироваться на outcome, а не имплементацию
- Автоматизация создания RL environments из реальных задач
- Измеряйте модели на реальных engineering work, а не на паззлах
3. Для компаний, строящих AI products
- Доступ к real-world engineering data — ключевое конкурентное преимущество
- RL environments > clever prompting
- Benchmarks drive capability improvements
- Open source collaboration ускоряет прогресс всей индустрии
#AI #ML #Agents #Software #Engineering #Architecture
Продолжая рассказ про этот доклад, надо рассказать про Cline-Bench - open source benchmark для реальных задач, который анонсирует Cline. Каждая задача внутри бенча это:
- Starting repo snapshot (git commit hash)
- Real prompt from user
- Ground truth tests на основе кода, который реально зашипился
Этот бенч
- Полностью open source, no secret sauce, no locked datasets
- Любой может использовать для SFT, RL, eval
- Любой может поучаствовать
Как контрибьютить
1. Работайте над open source проектом с включенным Cline Provider
2. Opt into cline-bench initiative
3. Если frontier model застрял и вы вмешались, чтобы починить — это идеальный кандидат для benchmark
В общем, просто используйте Cline, наблюдайте, где модель struggles, и Cline подберет эти задачи в open-source benchmark.
P.S.
Если подбивать мысли из доклада, то можно вынести следующее
1. Для инженеров, использующих AI coding agents
- Перестаньте over-engineering scaffolding. Проще = лучше
- Фокусируйтесь на capability модели, а не на умных абстракциях
- Ваши real-world failure cases — самые ценные данные для экосистемы
- Contribution в open benchmarks помогает всем
2. Для исследователей и разработчиков моделей
- Сдвиг от scaffolding tricks к environment design
- Качество верификатора критично: надо ориентироваться на outcome, а не имплементацию
- Автоматизация создания RL environments из реальных задач
- Измеряйте модели на реальных engineering work, а не на паззлах
3. Для компаний, строящих AI products
- Доступ к real-world engineering data — ключевое конкурентное преимущество
- RL environments > clever prompting
- Benchmarks drive capability improvements
- Open source collaboration ускоряет прогресс всей индустрии
#AI #ML #Agents #Software #Engineering #Architecture
Telegram
Книжный куб
[1/2] Hard Won Lessons from Building Effective AI Coding Agents (Рубрика #Agents)
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал…
Интересный доклад от Nik Pash, Head of AI в Cline с основной мыслью в том, что надо перестать усложнять или почему умный scaffolding убивает AI-агентов. До Cline Ник работал…
❤7🔥4👍2
Developer Experience in the Age of AI Coding Agents (Рубрика #Agents)
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Developer Experience in the Age of AI Coding Agents – Max Kanat-Alexander, Capital One
It feels like every two weeks, the world of software engineering is being turned on its head. Are there any principles we can rely on that will continue to hold true, and that can help us prepare for the future, no matter what happens? Max uses research,…
👍11❤6🔥3
AI Trends 2026: Quantum, Agentic AI & Smarter Automation (Рубрика #AI)
Пока идут новогодние каникулы, можно глянуть предсказания на 2026 год. Так я наткнулся на видео Martin Keen и Aaron Baughman из IBM, что опубликовали такой обзор про AI на 2026 год. Кстати, Martin Keen, IBM Fellow, в прошлом году записывал такое видео в одиночку и я про него рассказывал (можете сравнить с реальностью и оценить что исполнилось).
1️⃣ Мультиагентная оркестрация (Multi-Agent Orchestration)
2025 был годом AI-агентов, но ни один агент не справляется со всем. В 2026 мы увидим команды специализированных агентов, координируемых оркестратором.
2️⃣ Цифровая рабочая сила (Digital Labor Workforce)
Автономные AI-агенты становятся "цифровыми работниками", способными парсить мультимодальный ввод, выполнять workflow и интегрироваться с корпоративными системами. Ключевой элемент — human-in-the-loop AI для oversight, коррекции и стратегического управления. Это важно, так как цифровые работники обеспечивают force-multiplying эффект, работают 24/7 и масштабируются без массового найма персонала.
3️⃣ Physical AI и гуманоидные роботы
AI покидает цифровое пространство и входит в физический мир. Physical AI — это модели, которые понимают 3D-среду, физику (гравитация, трение) и могут взаимодействовать с реальностью через роботизированные системы. Для этого нужны world foundation models (WFM), генеративные модели, создающие и понимающие 3D-окружения. Про этот подход рассказывала Fei-Fei Li, крестная мать AI, в докладе "Spatial Intelligence is the Next Frontier in AI", который я уже разбирал.
4️⃣ Social Computing — коллективный AI
Мир, где множество агентов и людей работают внутри общей AI-ткани (AI fabric). Агенты и люди соединены через единое пространство, обмениваются контекстом, намерениями и действиями, создавая empathetic emergent network — коллективный интеллект или "swarm computing".
5️⃣ Verifiable AI и EU AI Act
EU AI Act вступает в полную силу к середине 2026 года. Как GDPR для AI: системы высокого риска должны быть аудируемыми и трассируемыми. Требования:
- Документация — технические доки, тестирование, риски
- Прозрачность — пользователи должны знать, что взаимодействуют с машиной
- Data lineage — откуда данные и соблюдены ли авторские права
По мнению ребят EU AI Act установит глобальный шаблон для AI-регулирования, как GDPR для privacy.
6️⃣ Quantum Utility Everywhere
По мнению ребят именно в 2026 году квантовые вычисления начнут решать реальные задачи лучше, быстрее или эффективнее классических систем. Quantum utility scale — гибридные квант-классические системы, интегрированные в повседневные бизнес-операции для оптимизации, симуляций и принятия решений. Это обусловлено тем, что мы уже видим прорывы в коррекции ошибок, модульности и гибридных алгоритмах ускоряются, а также появляются Quantum-as-a-Service от IBM, AWS, Microsoft и Google.
7️⃣ Reasoning at the Edge — мышление на устройстве
Большие модели научились "думать" через inference-time compute (step-by-step reasoning). Теперь эти способности дистиллируются в малые модели (несколько миллиардов параметров), работающие на ноутбуках и телефонах. Модели с reasoning работают локально, данные не покидают устройство, нет задержки на облако.
8️⃣ Amorphous Hybrid Computing
Будущее там, где топологии AI-моделей и облачная инфраструктура сливаются в fluid computing backbone. Модели эволюционируют за пределы чистых трансформеров, интегрируя state space models (SSM) и другие архитектуры. Одновременно облака комбинируют CPU, GPU, TPU, QPU (quantum) и нейроморфные чипы, чтобы исполнять алгоритмсы на оптимальном для инференса устройстве, обеспечивая производительность и эффективность.
Итого, 2026 обещает стать переломным годом для AI: от изолированных моделей к оркестрированным системам, от облака к edge, от цифрового к физическому.
#AI #ML #Trends #Software #Engineering #Future
Пока идут новогодние каникулы, можно глянуть предсказания на 2026 год. Так я наткнулся на видео Martin Keen и Aaron Baughman из IBM, что опубликовали такой обзор про AI на 2026 год. Кстати, Martin Keen, IBM Fellow, в прошлом году записывал такое видео в одиночку и я про него рассказывал (можете сравнить с реальностью и оценить что исполнилось).
1️⃣ Мультиагентная оркестрация (Multi-Agent Orchestration)
2025 был годом AI-агентов, но ни один агент не справляется со всем. В 2026 мы увидим команды специализированных агентов, координируемых оркестратором.
2️⃣ Цифровая рабочая сила (Digital Labor Workforce)
Автономные AI-агенты становятся "цифровыми работниками", способными парсить мультимодальный ввод, выполнять workflow и интегрироваться с корпоративными системами. Ключевой элемент — human-in-the-loop AI для oversight, коррекции и стратегического управления. Это важно, так как цифровые работники обеспечивают force-multiplying эффект, работают 24/7 и масштабируются без массового найма персонала.
3️⃣ Physical AI и гуманоидные роботы
AI покидает цифровое пространство и входит в физический мир. Physical AI — это модели, которые понимают 3D-среду, физику (гравитация, трение) и могут взаимодействовать с реальностью через роботизированные системы. Для этого нужны world foundation models (WFM), генеративные модели, создающие и понимающие 3D-окружения. Про этот подход рассказывала Fei-Fei Li, крестная мать AI, в докладе "Spatial Intelligence is the Next Frontier in AI", который я уже разбирал.
4️⃣ Social Computing — коллективный AI
Мир, где множество агентов и людей работают внутри общей AI-ткани (AI fabric). Агенты и люди соединены через единое пространство, обмениваются контекстом, намерениями и действиями, создавая empathetic emergent network — коллективный интеллект или "swarm computing".
5️⃣ Verifiable AI и EU AI Act
EU AI Act вступает в полную силу к середине 2026 года. Как GDPR для AI: системы высокого риска должны быть аудируемыми и трассируемыми. Требования:
- Документация — технические доки, тестирование, риски
- Прозрачность — пользователи должны знать, что взаимодействуют с машиной
- Data lineage — откуда данные и соблюдены ли авторские права
По мнению ребят EU AI Act установит глобальный шаблон для AI-регулирования, как GDPR для privacy.
6️⃣ Quantum Utility Everywhere
По мнению ребят именно в 2026 году квантовые вычисления начнут решать реальные задачи лучше, быстрее или эффективнее классических систем. Quantum utility scale — гибридные квант-классические системы, интегрированные в повседневные бизнес-операции для оптимизации, симуляций и принятия решений. Это обусловлено тем, что мы уже видим прорывы в коррекции ошибок, модульности и гибридных алгоритмах ускоряются, а также появляются Quantum-as-a-Service от IBM, AWS, Microsoft и Google.
7️⃣ Reasoning at the Edge — мышление на устройстве
Большие модели научились "думать" через inference-time compute (step-by-step reasoning). Теперь эти способности дистиллируются в малые модели (несколько миллиардов параметров), работающие на ноутбуках и телефонах. Модели с reasoning работают локально, данные не покидают устройство, нет задержки на облако.
8️⃣ Amorphous Hybrid Computing
Будущее там, где топологии AI-моделей и облачная инфраструктура сливаются в fluid computing backbone. Модели эволюционируют за пределы чистых трансформеров, интегрируя state space models (SSM) и другие архитектуры. Одновременно облака комбинируют CPU, GPU, TPU, QPU (quantum) и нейроморфные чипы, чтобы исполнять алгоритмсы на оптимальном для инференса устройстве, обеспечивая производительность и эффективность.
Итого, 2026 обещает стать переломным годом для AI: от изолированных моделей к оркестрированным системам, от облака к edge, от цифрового к физическому.
#AI #ML #Trends #Software #Engineering #Future
YouTube
AI Trends 2026: Quantum, Agentic AI & Smarter Automation
Ready to become a certified watsonx AI Assistant Engineer v1 - Professional? Register now and use code IBMTechYT20 for 20% off of your exam → https://ibm.biz/BdbTDQ
Learn more about AI Trends Shaping the Next 10 Years here → https://ibm.biz/BdbTDT
What…
Learn more about AI Trends Shaping the Next 10 Years here → https://ibm.biz/BdbTDT
What…
❤9👍3🔥2
Half-Life. Как Valve создала культовый шутер от первого лица (Half-Life: Le FPS libéré. Création - Univers - Décryptage) (Рубрика #Games)
Прочитал на каникулах книгу 2016 года Яна Франсуа про Half Life, что совершила в конце 90х годов революцию в жанре FPS. Fвтор не просто решил пересказать игру - он поставил перед собой задачу проследить путь Half-Life от замысла до триумфа, а также показать, как Valve нашла свой уникальный стиль и какие решения определили успех проекта. Вообще, книга состоит из трех частей: исторической, повествовательной и аналитической.
1️⃣ В исторической части рассказывается предыстория основания Valve и хроника разработки Half-Life. Франсуа описывает биографию Гейба Ньюэлла и Майка Харрингтона – бывших сотрудников Microsoft, которые в 1996 году основали Valve, вдохновившись идеей сделать нечто масштабнее типичных шутеров того времени. Читатель узнает, с какими проблемами столкнулась молодая команда: от технических ограничений движка до неудачных прототипов уровней, а также переноса релиза игры на целый год – несмотря на приближение объявленной даты выхода в 1997-м, Valve выбрала довести всё до идеала
2️⃣ В повестовательной части Франсуа буквально в хронологическом порядке пересказывает сюжет Half-Life, от утренней поездки Гордона Фримена в исследовательский центр Black Mesa до финальной встречи с таинственным G-Man. Такой подробный пересказ может удивить искушенного читателя, ведь многие сами не раз проходили игру. Однако автор делает это не ради спойлеров, а чтобы проанализировать структуру истории, отметить ключевые моменты дизайна уровней и гейм-дизайнерские приемы. Так уже получилось, что я в 1998 году, когда вышла первая Half-Life в игры еще не играл, а к выходу второй - уж не играл, поэтому эта книга помогла мне понять, а в чем же сюжет культовой игры.
3️⃣ В аналитической части автор делится выводами о наследии Half-Life и влиянии игры на индустрию. Он изучает источники вдохновения разработчиков (от классических шутеров вроде Doom до фильмов ужасов и научной фантастики), внутреннюю философию Valve и то, как успех Half-Life повлиял на дальнейшие решения студии. Он старается ответить на главный вопрос: в чем феномен Half-Life? Среди поднятых тем – новаторская для 90-х интеграция сюжета и геймплея, когда история рассказывается через окружение и скрипты событий, а не через заставки. Автор обсуждает, как Valve нашла свой стиль разработки – культура, где ценится эксперименты, командная инновация и внимание к деталям.
Отдельно стоит отметить, что Half-Life и Valve сильно повлияли на историю компьютерных игр
- Half-Life по праву считается одной из величайших игр всех времен, которая фундаментально изменила подход к созданию шутеров. До её выхода сюжет в экшен-играх подавался в лучшем случае через брифинги или ролики между уровнями. Valve же показала, как можно рассказать сложную историю внутри геймплея – игрок сам переживает все события, оставаясь в роли персонажа.
- С технической точки зрения Half-Life тоже задала планку. Игра построена на сильно модифицированном движке Quake, названном GoldSrc, и разработчики не побоялись углубиться в код предшественников, чтобы реализовать свои идеи. Результатом стали новаторские решения: продвинутый ИИ врагов, скриптовые события в реальном времени, которых раньше не видели в динамике FPS, и модульная архитектура игры, позволившая сообществу создавать тысячи модификаций (одна из них Counter-Strike)
- Half-Life 2 (2004) стала качественным скачком: ради него студия создала с нуля новый движок Source, который затем стал основой множества игр на годы вперед. Source принес индустрии новые технологии графики, анимации, физики, звука и повествования, многие из которых используются до сих пор.
- Half-Life и Half-Life 2 вместе не только задали стандарты геймдизайна, но и изменили сам подход к дистрибуции игр. Параллельно с HL2 в 2003 году Valve запустила сервис Steam, изначально – чтобы распространить обновления для сетевых игр вроде Counter-Strike, а затем – чтобы продать сам HL2 напрямую игрокам.
#Game #Design #Engineering #Software
Прочитал на каникулах книгу 2016 года Яна Франсуа про Half Life, что совершила в конце 90х годов революцию в жанре FPS. Fвтор не просто решил пересказать игру - он поставил перед собой задачу проследить путь Half-Life от замысла до триумфа, а также показать, как Valve нашла свой уникальный стиль и какие решения определили успех проекта. Вообще, книга состоит из трех частей: исторической, повествовательной и аналитической.
1️⃣ В исторической части рассказывается предыстория основания Valve и хроника разработки Half-Life. Франсуа описывает биографию Гейба Ньюэлла и Майка Харрингтона – бывших сотрудников Microsoft, которые в 1996 году основали Valve, вдохновившись идеей сделать нечто масштабнее типичных шутеров того времени. Читатель узнает, с какими проблемами столкнулась молодая команда: от технических ограничений движка до неудачных прототипов уровней, а также переноса релиза игры на целый год – несмотря на приближение объявленной даты выхода в 1997-м, Valve выбрала довести всё до идеала
2️⃣ В повестовательной части Франсуа буквально в хронологическом порядке пересказывает сюжет Half-Life, от утренней поездки Гордона Фримена в исследовательский центр Black Mesa до финальной встречи с таинственным G-Man. Такой подробный пересказ может удивить искушенного читателя, ведь многие сами не раз проходили игру. Однако автор делает это не ради спойлеров, а чтобы проанализировать структуру истории, отметить ключевые моменты дизайна уровней и гейм-дизайнерские приемы. Так уже получилось, что я в 1998 году, когда вышла первая Half-Life в игры еще не играл, а к выходу второй - уж не играл, поэтому эта книга помогла мне понять, а в чем же сюжет культовой игры.
3️⃣ В аналитической части автор делится выводами о наследии Half-Life и влиянии игры на индустрию. Он изучает источники вдохновения разработчиков (от классических шутеров вроде Doom до фильмов ужасов и научной фантастики), внутреннюю философию Valve и то, как успех Half-Life повлиял на дальнейшие решения студии. Он старается ответить на главный вопрос: в чем феномен Half-Life? Среди поднятых тем – новаторская для 90-х интеграция сюжета и геймплея, когда история рассказывается через окружение и скрипты событий, а не через заставки. Автор обсуждает, как Valve нашла свой стиль разработки – культура, где ценится эксперименты, командная инновация и внимание к деталям.
Отдельно стоит отметить, что Half-Life и Valve сильно повлияли на историю компьютерных игр
- Half-Life по праву считается одной из величайших игр всех времен, которая фундаментально изменила подход к созданию шутеров. До её выхода сюжет в экшен-играх подавался в лучшем случае через брифинги или ролики между уровнями. Valve же показала, как можно рассказать сложную историю внутри геймплея – игрок сам переживает все события, оставаясь в роли персонажа.
- С технической точки зрения Half-Life тоже задала планку. Игра построена на сильно модифицированном движке Quake, названном GoldSrc, и разработчики не побоялись углубиться в код предшественников, чтобы реализовать свои идеи. Результатом стали новаторские решения: продвинутый ИИ врагов, скриптовые события в реальном времени, которых раньше не видели в динамике FPS, и модульная архитектура игры, позволившая сообществу создавать тысячи модификаций (одна из них Counter-Strike)
- Half-Life 2 (2004) стала качественным скачком: ради него студия создала с нуля новый движок Source, который затем стал основой множества игр на годы вперед. Source принес индустрии новые технологии графики, анимации, физики, звука и повествования, многие из которых используются до сих пор.
- Half-Life и Half-Life 2 вместе не только задали стандарты геймдизайна, но и изменили сам подход к дистрибуции игр. Параллельно с HL2 в 2003 году Valve запустила сервис Steam, изначально – чтобы распространить обновления для сетевых игр вроде Counter-Strike, а затем – чтобы продать сам HL2 напрямую игрокам.
#Game #Design #Engineering #Software
❤8🔥8⚡2
[1/2] Отчеты McKinsey про Gen AI (Рубрика #AI)
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали в 2024 и 2025, а это уже позволяет отследить тренды и посмотреть как развивается ситуация во времени. Конкретно я поговорю про следующие отчеты
- 2023 год: The state of AI in 2023: Generative AI’s breakout year - опрос с 11 по 21 апреля 2023, 1684 респондентов, публикация 1 августа 2023
- 2024 год - начало: The state of AI in early 2024: Gen AI adoption spikes and starts to generate value - опрос с 22 февраля по 5 марта 2024, 1363 респондентов, публикация 30 мая 2024
- 2024 год - середина: The state of AI: How organizations are rewiring to capture value - опрос с 16 по 31 июля 2024, 1491 респондент, публикация 12 марта 2025
- 2025 год: The state of AI in 2025: Agents, innovation, and transformation - опрос с 25 июня по 29 июля, 1993 респондента, публикация 5 ноября 2025 года (я подробнее уже рассказывал про результаты)
Если глянуть на эти отччеты, то есть ряд метрик, что можно воспринимать как time series данные и оценивать тренды
❤️🔥 Сначала начнем с метрик проникновения и ее широты
1) “AI use/adoption in at least one business function” — главный «сквозной» KPI
Это самый стабильный KPI во всей серии: доля респондентов, у кого в компании AI используется/принят хотя бы в одной функции.
- 2023 - 55%
- 2024 (начало) - 72%
- 2024 (середина) - 78%
- 2025 - 88%
Эту метрика можно назвать метрикой проникновения (“penetration”), она отвечате на вопрос "есть ли AI хоть где-то", но плохо различает пилот vs прод.
2) “Organizations regularly using gen AI in ≥1 business function” — второй сквозной KPI (но в 2025‑выпуске Nov 2025 он не акцентирован)
- 2023 - 33%
- 2024 (начало) - 65%
- 2024 (середина) - 71%
- 2025 - NA - в тексте отчета не дано отдельной цифрой (фокус смещён на agents и AI overall)
3) “AI spreads across multiple functions” — ширина применения (частично сопоставимо)
С этим KPI сложнее: он «тот же по смыслу», но формулировки в разных отчетах разные (≥2 функции, >1 функция, ≥3 функции).
- 2023 - меньше 33% AI adopted в двух и более функциях
- 2024 (начало) - 50% — AI adopted в двух и более функциях
- 2024 (середина) - NA
- 2025: больше 66% - AI используется более чем в одной функции; и 50% — в трёх и более функциях.
Кажется, что авторов отчета меньше интересовала сравнимость данных год от года, а больше интересовал способ как померить широту охвата, поэтому вопрос про количество функций с adoption AI постепенно увеличивался
В продолжении я расскажу про оценку эффектов AI/GenAI на компании и концепцию high performers, которые лучше справляются с внедрением инструментов. Я рассказывал об этом здесь, но в продолжении поста будет видно, как критерии high performance мутируют со временем.
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали в 2024 и 2025, а это уже позволяет отследить тренды и посмотреть как развивается ситуация во времени. Конкретно я поговорю про следующие отчеты
- 2023 год: The state of AI in 2023: Generative AI’s breakout year - опрос с 11 по 21 апреля 2023, 1684 респондентов, публикация 1 августа 2023
- 2024 год - начало: The state of AI in early 2024: Gen AI adoption spikes and starts to generate value - опрос с 22 февраля по 5 марта 2024, 1363 респондентов, публикация 30 мая 2024
- 2024 год - середина: The state of AI: How organizations are rewiring to capture value - опрос с 16 по 31 июля 2024, 1491 респондент, публикация 12 марта 2025
- 2025 год: The state of AI in 2025: Agents, innovation, and transformation - опрос с 25 июня по 29 июля, 1993 респондента, публикация 5 ноября 2025 года (я подробнее уже рассказывал про результаты)
Если глянуть на эти отччеты, то есть ряд метрик, что можно воспринимать как time series данные и оценивать тренды
1) “AI use/adoption in at least one business function” — главный «сквозной» KPI
Это самый стабильный KPI во всей серии: доля респондентов, у кого в компании AI используется/принят хотя бы в одной функции.
- 2023 - 55%
- 2024 (начало) - 72%
- 2024 (середина) - 78%
- 2025 - 88%
Эту метрика можно назвать метрикой проникновения (“penetration”), она отвечате на вопрос "есть ли AI хоть где-то", но плохо различает пилот vs прод.
2) “Organizations regularly using gen AI in ≥1 business function” — второй сквозной KPI (но в 2025‑выпуске Nov 2025 он не акцентирован)
- 2023 - 33%
- 2024 (начало) - 65%
- 2024 (середина) - 71%
- 2025 - NA - в тексте отчета не дано отдельной цифрой (фокус смещён на agents и AI overall)
3) “AI spreads across multiple functions” — ширина применения (частично сопоставимо)
С этим KPI сложнее: он «тот же по смыслу», но формулировки в разных отчетах разные (≥2 функции, >1 функция, ≥3 функции).
- 2023 - меньше 33% AI adopted в двух и более функциях
- 2024 (начало) - 50% — AI adopted в двух и более функциях
- 2024 (середина) - NA
- 2025: больше 66% - AI используется более чем в одной функции; и 50% — в трёх и более функциях.
Кажется, что авторов отчета меньше интересовала сравнимость данных год от года, а больше интересовал способ как померить широту охвата, поэтому вопрос про количество функций с adoption AI постепенно увеличивался
В продолжении я расскажу про оценку эффектов AI/GenAI на компании и концепцию high performers, которые лучше справляются с внедрением инструментов. Я рассказывал об этом здесь, но в продолжении поста будет видно, как критерии high performance мутируют со временем.
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Please open Telegram to view this post
VIEW IN TELEGRAM
McKinsey & Company
The state of AI in 2023: Generative AI’s breakout year
Explore McKinsey's State of AI in 2023 report, a detailed new survey that looks at how generative AI is reshaping the world's industries and workforces.
❤6🔥4⚡2
[2/2] Отчеты McKinsey про Gen AI (Рубрика #AI)
Продолжая рассказ про исследования McKinsey, перейдем к метрикам рисков и «негативных последствий» (здесь есть данные, но опять сложно сравнимые)
4) “Experienced at least one negative consequence”
2023 - NA
2024 (начало) - 44% организаций испытали хотя бы одно негативное последствие от gen AI
2024 (середина) - 47% организаций испытали хотя бы одно негативное последствие от gen AI.
2025 - 51% организаций, использующих AI, испытали хотя бы одно негативное последствие (уже AI overall, не только gen AI).
5) “Inaccuracy” как ключевой риск (частично численно)
2023 - NA
2024 (начало) - риск, который значимо чаще стали пытаться митигировать по сравнению с прошлым годом; и "почти 25%" респондентов отмечают негативные последствия именно от неточности gen AI
2024 (середина) - NA
2025 - почти 33% всех респондентов сообщает о последствиях из‑за AI inaccuracy.
🤑 Ну и напоследок обсудим Value / EBIT, где метрика повторяется, но пороги и определения плавают
Здесь McKinsey даёт числа, но в разных выпусках меняется “что считаем успехом”.
6) Доля компаний с EBIT‑эффектом (разные пороги)
2023 - 23% респондентов говорят, что ≥5% EBIT их организаций attributable to AI (flat YoY на тот момент)
2024 (начало) - только 5.2% (46 и 876 респондентов) "report that a meaningful share of their organizations’ EBIT can be attributed to their deployment of gen AI"
2024 (середина) - 17% говорят, что ≥5% EBIT attributable to gen AI; при этом >80% не видят “tangible impact” на enterprise‑level EBIT от gen AI
2025 - 39% сообщают о любом EBIT impact на enterprise level от AI (и у большинства это <5%)
7) Доля "High performers" в выборке (тоже не 1‑в‑1, но похоже по масштабу)
2023 - AI high performers тут определяются по критерию "> 20% EBIT attributable to gen AI". Прямого указания их количества нет, но оценку можно взять из других вопросов, например, про "reskill larger portions of the workforce" где ответило 50 high performers и остальных 863 (получается оценка в 5.4% high performers)
2024 (начало) - “gen AI high performers” = 46 из 876 (≈5.3%) респондентов (критерий: > 10% EBIT attributable to gen AI)
2024 (середина) - NA (в этом отчете ничего не говорится про high performers)
2025 - “AI high performers” ≈ 6% респондентов (критерий другой: EBIT impact ≥ 5% + “significant value”)
В итоге, видим, что доля “топов” по self‑reported value остаётся порядка 5–6%, но из‑за смены критериев это не точный тренд. Если же глянуть на 2023 год, где 23% респондентов говорили про 5% вклад AI в EBITDA, то в 2025 году виден спад до 6% респондентов, что видят такой вклад. А значит высота достижений high performers становится ниже (или оценки влияния на EBITDA реальнее).
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Продолжая рассказ про исследования McKinsey, перейдем к метрикам рисков и «негативных последствий» (здесь есть данные, но опять сложно сравнимые)
4) “Experienced at least one negative consequence”
2023 - NA
2024 (начало) - 44% организаций испытали хотя бы одно негативное последствие от gen AI
2024 (середина) - 47% организаций испытали хотя бы одно негативное последствие от gen AI.
2025 - 51% организаций, использующих AI, испытали хотя бы одно негативное последствие (уже AI overall, не только gen AI).
5) “Inaccuracy” как ключевой риск (частично численно)
2023 - NA
2024 (начало) - риск, который значимо чаще стали пытаться митигировать по сравнению с прошлым годом; и "почти 25%" респондентов отмечают негативные последствия именно от неточности gen AI
2024 (середина) - NA
2025 - почти 33% всех респондентов сообщает о последствиях из‑за AI inaccuracy.
Здесь McKinsey даёт числа, но в разных выпусках меняется “что считаем успехом”.
6) Доля компаний с EBIT‑эффектом (разные пороги)
2023 - 23% респондентов говорят, что ≥5% EBIT их организаций attributable to AI (flat YoY на тот момент)
2024 (начало) - только 5.2% (46 и 876 респондентов) "report that a meaningful share of their organizations’ EBIT can be attributed to their deployment of gen AI"
2024 (середина) - 17% говорят, что ≥5% EBIT attributable to gen AI; при этом >80% не видят “tangible impact” на enterprise‑level EBIT от gen AI
2025 - 39% сообщают о любом EBIT impact на enterprise level от AI (и у большинства это <5%)
7) Доля "High performers" в выборке (тоже не 1‑в‑1, но похоже по масштабу)
2023 - AI high performers тут определяются по критерию "> 20% EBIT attributable to gen AI". Прямого указания их количества нет, но оценку можно взять из других вопросов, например, про "reskill larger portions of the workforce" где ответило 50 high performers и остальных 863 (получается оценка в 5.4% high performers)
2024 (начало) - “gen AI high performers” = 46 из 876 (≈5.3%) респондентов (критерий: > 10% EBIT attributable to gen AI)
2024 (середина) - NA (в этом отчете ничего не говорится про high performers)
2025 - “AI high performers” ≈ 6% респондентов (критерий другой: EBIT impact ≥ 5% + “significant value”)
В итоге, видим, что доля “топов” по self‑reported value остаётся порядка 5–6%, но из‑за смены критериев это не точный тренд. Если же глянуть на 2023 год, где 23% респондентов говорили про 5% вклад AI в EBITDA, то в 2025 году виден спад до 6% респондентов, что видят такой вклад. А значит высота достижений high performers становится ниже (или оценки влияния на EBITDA реальнее).
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/2] Отчеты McKinsey про Gen AI (Рубрика #AI)
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали…
Я продолжаю свое мета-исследование различных отчетов про внедрение AI и мне понравилась серия постов от McKinsey, которые системно и ритмично исследуют данный вопрос. Они начали делать это в 2023 году и продолжали…
❤4👍3🔥3