[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🔥3🙏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❤7🔥5⚡3😁1
The Human Cloud (Экономика удалёнки) (Рубрика #Economics)
Прочитал книгу "The Human Cloud" еще из тех времен (21 года), когда был еще Sber Cloud, а не Cloud.ru, и их название красуется на обложке - ведь ребята помогли в издании этой книги. Если же говорить про книгу, то главной темой является грядущее преобразование мира труда под влиянием трех факторов:
- Развития технологий удалённой работы
- Взрывного роста фриланс-экономики (гиг-экономики)
- Внедрения автоматизации/искусственного интеллекта (и это было еще до chatgpt момента)
Авторы вводят понятие «Human Cloud» («человеческое облако»), под которым понимается глобальный пул талантов-фрилансеров, доступных через цифровые платформы по принципу облачного сервиса. По мнению Моттолы и Коутни, традиционная офисная модель устарела: современные средства связи (почта, видеосвязь, облачные хранилища, менеджеры задач) позволяют эффективно работать из любой точки мира. Компании всё чаще предпочитают нанимать специалистов под конкретные проекты, а не держать штат, – поэтому полноценная занятость в одном офисе перестает быть нормой. Интересно, что сейчас удаленка уже не в моде, фриланс становится вынужденным из-за сокращений, а AI уже не просто автоматизирует рутинные операции (как много изменилось за 5 лет, что прошли с написания книги).
Но в своей книги авторы оптимистичны - они говорят, что эти три фактора дают новые возможности и работникам, и работодателям. . Они перечисляют ряд ключевых идей и советов:
- Удалённая фриланс-модель повышает эффективность
Индивидуальные исполнители теперь способны выполнять проекты, на которые раньше требовались ресурсы большой корпорации. Благодаря облачным инструментам один талантливый специалист может достучаться до глобальных заказчиков и работать с ними напрямую, без посредников. Для профессионалов это означает больше влияния и свободы в работе.
- Полноценная занятость больше не гарант стабильности
Парадоксально, но авторы отмечают, что многие во время пандемии убедились: постоянная должность не так надёжна, как считалось. Фриланс же может дать стабильный доход, если у человека востребованные навыки. Технологии делают переход к независимой работе проще – от онлайн-платформ поиска клиентов до доступных инструментов разработки, дизайна, аналитики и т.д.
- Главное – результат, а не процесс
В новой модели успех определяют не отсиженные часы и офисная политика, а конкретные результаты (outcomes). Фрилансер ценится за выполненный проект и качество работы, поэтому должен сосредоточиться на своих лучших профессиональных навыках. Эта ориентация на результат, по мнению авторов, сделает и компании эффективнее
- «Human Cloud» + ИИ = будущее работы
Помимо человеческого облака фрилансеров, авторы вводят понятие «Machine Cloud» – условно, облако машинного интеллекта. Речь о том, что автоматизация и ИИ дополняют человеческий труд, беря на себя рутинные или трудоёмкие задачи. В книге подчёркивается: хотя звучат страхи, что «роботы отнимут работу», реальность не столь мрачна. Новые технологии скорее создают новые возможности, а не тотальную безработицу. Моттола и Коутни призывают не бояться, а использовать ИИ-инструменты, чтобы повысить свою продуктивность и ценность на рынке труда.
Основной посыл книги оптимистичный, но если посмотреть на gig-экономику сегодня, то видно, что она в реальности столкнулась и с серьезными проблемами: социальная незащищенность работников, отсутствие стабильности в работе, регуляторные ограничения (когда gig-работников приравнивают к штатным сотрудникам при определенных условиях). Такие тенденции ставят под вопрос неограниченный рост «человеческого облака» в том виде, как его описывает книга. Компании уже не смогут бесконечно экономить за счёт обхода трудового законодательства – возможно, им придётся находить баланс между гибкостью и соцгарантиями.
#Economics #AI #Management #Leadership #Startup #Engineering #Future
Прочитал книгу "The Human Cloud" еще из тех времен (21 года), когда был еще Sber Cloud, а не Cloud.ru, и их название красуется на обложке - ведь ребята помогли в издании этой книги. Если же говорить про книгу, то главной темой является грядущее преобразование мира труда под влиянием трех факторов:
- Развития технологий удалённой работы
- Взрывного роста фриланс-экономики (гиг-экономики)
- Внедрения автоматизации/искусственного интеллекта (и это было еще до chatgpt момента)
Авторы вводят понятие «Human Cloud» («человеческое облако»), под которым понимается глобальный пул талантов-фрилансеров, доступных через цифровые платформы по принципу облачного сервиса. По мнению Моттолы и Коутни, традиционная офисная модель устарела: современные средства связи (почта, видеосвязь, облачные хранилища, менеджеры задач) позволяют эффективно работать из любой точки мира. Компании всё чаще предпочитают нанимать специалистов под конкретные проекты, а не держать штат, – поэтому полноценная занятость в одном офисе перестает быть нормой. Интересно, что сейчас удаленка уже не в моде, фриланс становится вынужденным из-за сокращений, а AI уже не просто автоматизирует рутинные операции (как много изменилось за 5 лет, что прошли с написания книги).
Но в своей книги авторы оптимистичны - они говорят, что эти три фактора дают новые возможности и работникам, и работодателям. . Они перечисляют ряд ключевых идей и советов:
- Удалённая фриланс-модель повышает эффективность
Индивидуальные исполнители теперь способны выполнять проекты, на которые раньше требовались ресурсы большой корпорации. Благодаря облачным инструментам один талантливый специалист может достучаться до глобальных заказчиков и работать с ними напрямую, без посредников. Для профессионалов это означает больше влияния и свободы в работе.
- Полноценная занятость больше не гарант стабильности
Парадоксально, но авторы отмечают, что многие во время пандемии убедились: постоянная должность не так надёжна, как считалось. Фриланс же может дать стабильный доход, если у человека востребованные навыки. Технологии делают переход к независимой работе проще – от онлайн-платформ поиска клиентов до доступных инструментов разработки, дизайна, аналитики и т.д.
- Главное – результат, а не процесс
В новой модели успех определяют не отсиженные часы и офисная политика, а конкретные результаты (outcomes). Фрилансер ценится за выполненный проект и качество работы, поэтому должен сосредоточиться на своих лучших профессиональных навыках. Эта ориентация на результат, по мнению авторов, сделает и компании эффективнее
- «Human Cloud» + ИИ = будущее работы
Помимо человеческого облака фрилансеров, авторы вводят понятие «Machine Cloud» – условно, облако машинного интеллекта. Речь о том, что автоматизация и ИИ дополняют человеческий труд, беря на себя рутинные или трудоёмкие задачи. В книге подчёркивается: хотя звучат страхи, что «роботы отнимут работу», реальность не столь мрачна. Новые технологии скорее создают новые возможности, а не тотальную безработицу. Моттола и Коутни призывают не бояться, а использовать ИИ-инструменты, чтобы повысить свою продуктивность и ценность на рынке труда.
Основной посыл книги оптимистичный, но если посмотреть на gig-экономику сегодня, то видно, что она в реальности столкнулась и с серьезными проблемами: социальная незащищенность работников, отсутствие стабильности в работе, регуляторные ограничения (когда gig-работников приравнивают к штатным сотрудникам при определенных условиях). Такие тенденции ставят под вопрос неограниченный рост «человеческого облака» в том виде, как его описывает книга. Компании уже не смогут бесконечно экономить за счёт обхода трудового законодательства – возможно, им придётся находить баланс между гибкостью и соцгарантиями.
#Economics #AI #Management #Leadership #Startup #Engineering #Future
👍10❤6🔥2
[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…
🔥3❤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, а сейчас…
❤4☃3🎄3
Super Blocks (Рубрика #ForKids)
Недавно приехала очередная прикольная игрушка от компании Giiker, раньше я уже рассказывал про тх игру "4 в ряд в трехмерном пространстве". В супер блоках концепт чуть попроще - надо собирать звгаданные формы из блоков, что есть в комплекте. Чем-то это напоминает тетрис, но блоки не летят сверху вниз, а находятся в коробке, а собрать надо не полные ряды, а фигуру загаданной формы.
В общем, игра мне понравилась, а также зашла жене и сыну 5 лет, который любит логические игры.
#Games #Brain
Недавно приехала очередная прикольная игрушка от компании Giiker, раньше я уже рассказывал про тх игру "4 в ряд в трехмерном пространстве". В супер блоках концепт чуть попроще - надо собирать звгаданные формы из блоков, что есть в комплекте. Чем-то это напоминает тетрис, но блоки не летят сверху вниз, а находятся в коробке, а собрать надо не полные ряды, а фигуру загаданной формы.
В общем, игра мне понравилась, а также зашла жене и сыну 5 лет, который любит логические игры.
#Games #Brain
❤6👍1🔥1
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…
👍4❤3🔥1
Atomic Heart: Далёкое светлое будущее (Рубрика #SciFi)
Прочитал этот сборник рассказов о мире Atomic Heart с большим интересом. Книга о том, каким был Союз Atomic Heart до старта игры: витрины утопии, роботы в быту, ощущение прогресса “всё под контролем”, где технологии не просто помогают — они становятся фоном жизни, новой нормой. Правда, есть ощущение, что ты читаешь лог системы прямо перед тем, как все пошло по наклонной и мир сошел с ума. Отдельно отмечу, что в книге нет спойлеров к сюжету игры, но все истории вполне могли бы быть правдой и они не противоречат официальному лору. Читая этот сборник чувствуешь переломный момент, когда понимаешь: утопия с роботами легко превращается в антиутопию ...
Интересно проводить параллели с текущим увлечением человеко-подобными роботами и стремлением к воплощению AGI. Появляются мысли про
- Доверие к автоматизации (когда “умно” ≠ “безопасно”),
- Человеческий фактор (главный баг всегда в интерфейсе между людьми и системами),
- Мир, где роботы — базовая инфраструктура, но не ясно какой план "Б"
В общем, эта книга хорошо подходит для любителей игры и не только.
#AI #Future #SciFi #Game
Прочитал этот сборник рассказов о мире Atomic Heart с большим интересом. Книга о том, каким был Союз Atomic Heart до старта игры: витрины утопии, роботы в быту, ощущение прогресса “всё под контролем”, где технологии не просто помогают — они становятся фоном жизни, новой нормой. Правда, есть ощущение, что ты читаешь лог системы прямо перед тем, как все пошло по наклонной и мир сошел с ума. Отдельно отмечу, что в книге нет спойлеров к сюжету игры, но все истории вполне могли бы быть правдой и они не противоречат официальному лору. Читая этот сборник чувствуешь переломный момент, когда понимаешь: утопия с роботами легко превращается в антиутопию ...
Интересно проводить параллели с текущим увлечением человеко-подобными роботами и стремлением к воплощению AGI. Появляются мысли про
- Доверие к автоматизации (когда “умно” ≠ “безопасно”),
- Человеческий фактор (главный баг всегда в интерфейсе между людьми и системами),
- Мир, где роботы — базовая инфраструктура, но не ясно какой план "Б"
В общем, эта книга хорошо подходит для любителей игры и не только.
#AI #Future #SciFi #Game
❤6👍5🔥2