[1/2] Agentic coding at Airbnb (Рубрика #Agents)
Это очередной интересный доклад с сентябрьского DPE Summit, про который я рассказывал раньше. В нем ребята из Airnbnb рассказывали как они выстроили у себя агентскую модель разработки и двинулись от классического PDLC к AI-native разработке (примерно в ту сторону, что я описывал в одноименной статье). И тут речь не про какие-то игрушечные приложения, создаваемые агентами, а про агентскую разработку в их монорепе со стандартными требованиями по безопасности, комплаенсу и с 1к+ инженерами в ней. Причем авторы для описания подхода использовали метафору из парного программирования, практики XP (extreme programming), где два инженера вместе делали фичи: один был навигатором и думал о стратегии, а второй был пилотом, держал клавиатуру и писал код. В этой метафоре роль пилота забрал агент, а роль навигатора осталась за инженером. В начале 2025 года ребята ожидали, что такой режим распространиться на 20% - 40%, но к сентябрю они уже перевыполнили план и достигли примерно 60%
Путь Airbnb к этому выглядит достаточно предсказумым и понятным
1) Сначала у них был IDE-first подход: внутренние плагины с хорошим UX, доступом к контексту редактора и собственной knowledge/RAG-пайплайном для учета специфики Airbnb
2) Потом рынок резко двинулся в сторону CLI-агентов: они оказались сильнее как агентские инструменты, умели сами делать несколько шагов подряд, вызывать инструменты и принимать локальные решения
3) Airbnb адаптировались и попробовали посмотреть на мир как на CLI-first, но быстро увидели проблему: внешние CLI-инструменты давали классные ответы для внешних проектов, но плохо знали их монорепы, внутренние паттерны и кодовую базу компании
4) Дальше они сделали очень зрелый ход: не стали спорить IDE или CLI, а собрали небольшую core-команду и кросс-функциональную рабочую группу, чтобы привести все поверхности к одному уровню. У команды было всего четыре инженера плюс продуктовая поддержка, поэтому они сознательно сузили фокус до трех ставок:
- Принести агентов в Airbnb
- Принести знания Airbnb в агентов
- Стандартизироваться вокруг MCP
Параллельно они развернули champion/community-модель через хакатоны, talks и внутреннюю рабочую группу
В продолжении я расскажу про то, как ребята шли к выполнению этих целей.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Это очередной интересный доклад с сентябрьского DPE Summit, про который я рассказывал раньше. В нем ребята из Airnbnb рассказывали как они выстроили у себя агентскую модель разработки и двинулись от классического PDLC к AI-native разработке (примерно в ту сторону, что я описывал в одноименной статье). И тут речь не про какие-то игрушечные приложения, создаваемые агентами, а про агентскую разработку в их монорепе со стандартными требованиями по безопасности, комплаенсу и с 1к+ инженерами в ней. Причем авторы для описания подхода использовали метафору из парного программирования, практики XP (extreme programming), где два инженера вместе делали фичи: один был навигатором и думал о стратегии, а второй был пилотом, держал клавиатуру и писал код. В этой метафоре роль пилота забрал агент, а роль навигатора осталась за инженером. В начале 2025 года ребята ожидали, что такой режим распространиться на 20% - 40%, но к сентябрю они уже перевыполнили план и достигли примерно 60%
Путь Airbnb к этому выглядит достаточно предсказумым и понятным
1) Сначала у них был IDE-first подход: внутренние плагины с хорошим UX, доступом к контексту редактора и собственной knowledge/RAG-пайплайном для учета специфики Airbnb
2) Потом рынок резко двинулся в сторону CLI-агентов: они оказались сильнее как агентские инструменты, умели сами делать несколько шагов подряд, вызывать инструменты и принимать локальные решения
3) Airbnb адаптировались и попробовали посмотреть на мир как на CLI-first, но быстро увидели проблему: внешние CLI-инструменты давали классные ответы для внешних проектов, но плохо знали их монорепы, внутренние паттерны и кодовую базу компании
4) Дальше они сделали очень зрелый ход: не стали спорить IDE или CLI, а собрали небольшую core-команду и кросс-функциональную рабочую группу, чтобы привести все поверхности к одному уровню. У команды было всего четыре инженера плюс продуктовая поддержка, поэтому они сознательно сузили фокус до трех ставок:
- Принести агентов в Airbnb
- Принести знания Airbnb в агентов
- Стандартизироваться вокруг MCP
Параллельно они развернули champion/community-модель через хакатоны, talks и внутреннюю рабочую группу
В продолжении я расскажу про то, как ребята шли к выполнению этих целей.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Agentic coding at Airbnb
Presented by Szczepan Faber and Mike Nakhimovich (Airbnb) at DPE Summit 2025, an event developed and hosted by Gradle.
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=agentic…
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=agentic…
❤14🔥8👍1
[2/2] Agentic coding at Airbnb (Рубрика #Agents)
В прошлом посте мы остановились на том, что у ребят из Airbnb при внедрении агентского подхода к разработке было три цели и теперь интересно посмотреть, а как же они к ним шли.
Для того, чтобы реализовать первую цель, а именно "принести агентов в Airbnb", они построили Air Chat - абстракцию-обертку над несколькими движками. Это дало единую входную точку: можно быстро выкатывать новые CLI-агенты и обновления, не привязывая всю платформу к одному вендору или одному инструменту. Дальше они очень рано пошли в MCP, потому что стандарт был близок к их уже существующему tool-calling подходу. В результате Airbnb смогли: завернуть любимые IDE инструменты в MCP сервера, встроить MCP клиентов в IDE-плагины, а конфигурацию и синхронизацию серверов централизовать через Air Chat CLI. Со временем это выросло в экосистему с более чем дюжиной внутренних MCP-серверов, включая аналитические и CI-инструменты.
Для того, чтобы реализовать вторую цель, а именно "принести знания Airbnb в агентов" они поменяли свой подход к работе с базой знаний (knowledge base). Раньше у них была "линейная" one-shot схема: запрос → knowledge endpoint → ответ. Для агентного режима это работало плохо. Но они решили не играть в дообучение моделей (fine-tunning) как главный путь, а просто завернули получение знаний из базы знаний (knowledge base) в MCP, а дальше позволили агентам итеративно доуточнять информацию: если первый ответ не подошел, агент сам уточняет поиск, меняет термины и делает deeper research внутри ваших внутренних знаний.
Еще они рассказали как пытались строить собственную multi-agent orchestration-модель с planning/coding/validation agents, но рынок двигался слишком быстро, а маленькая команда не успевала наращивать нужную "мышцу". Поэтому Airbnb не уперлись в "мы обязаны написать свой оркестратор", а сделали прагматичный поворот (pivot): основной агент теперь живет как CLI-agent, а сверху у него тонкая прокладка для других поверхностей. Круто, что ребята честно рассказали про свое решение - зачастую синдром NIH (Not Invented Here) не позволяет принять такое решение или даже если оно принято, то не позволяет о его принятии рассказывать:)
Если подбивать выводы ребят из их пути, то они примерно такие
1) Agentic coding - это не просто чат в IDE, это новый inner loop, где агент многократно дергает LLM, инструменты и внутренние знания, а на выходе приносит код, который все равно должен быть просмотрен человеком до PR
2) Рост идет не только от auto-approve настройки агента, а от умения инженера управлять несколькими параллельными workspaces; в Airbnb некоторые продвинутые пользователи открывают до пяти агентных сессий одновременно
3) Агент сам по себе ничего не решает: вокруг него нужны sandbox/workspace-инфраструктура, auth, security paved path, шаблоны, установка в одну команду и нормальная review-культура
4) А организационный вывод ребят такой - не надо ломать существующие привычки команд ради модного AI UX. Они прямо говорят, что идея "давайте всех пользователей IntelliJ переведем в VS Code, потому что там лучше agentic tooling" быстро провалилась. Вместо этого нужно убирать барьеры, встречать разработчиков там, где они уже работают, и стандартизировать только то, что действительно стабилизировалось на рынке. При этом качество нельзя опускать "потому что это AI": стандарты остаются прежними, ревью обязателен, код тоже должен быть готовым к проду, а пользоваться auto-approve без набитой руки - опасно.
В общем, основная идея не в том, чтобы купить лучший AI-ассистент (Claude Code, OpenAI Codex, Cursor, выбери свой любимый), а в том, что собрать проторенный путь вокруг агентов: поверхности для взаимодействия, доступ к знаниям, вызов инструментов, стандартизация, измерения и ревью человеком. И только потом ждать реального прироста ключевых метрик разработки, а не локального wow-эффекта.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
В прошлом посте мы остановились на том, что у ребят из Airbnb при внедрении агентского подхода к разработке было три цели и теперь интересно посмотреть, а как же они к ним шли.
Для того, чтобы реализовать первую цель, а именно "принести агентов в Airbnb", они построили Air Chat - абстракцию-обертку над несколькими движками. Это дало единую входную точку: можно быстро выкатывать новые CLI-агенты и обновления, не привязывая всю платформу к одному вендору или одному инструменту. Дальше они очень рано пошли в MCP, потому что стандарт был близок к их уже существующему tool-calling подходу. В результате Airbnb смогли: завернуть любимые IDE инструменты в MCP сервера, встроить MCP клиентов в IDE-плагины, а конфигурацию и синхронизацию серверов централизовать через Air Chat CLI. Со временем это выросло в экосистему с более чем дюжиной внутренних MCP-серверов, включая аналитические и CI-инструменты.
Для того, чтобы реализовать вторую цель, а именно "принести знания Airbnb в агентов" они поменяли свой подход к работе с базой знаний (knowledge base). Раньше у них была "линейная" one-shot схема: запрос → knowledge endpoint → ответ. Для агентного режима это работало плохо. Но они решили не играть в дообучение моделей (fine-tunning) как главный путь, а просто завернули получение знаний из базы знаний (knowledge base) в MCP, а дальше позволили агентам итеративно доуточнять информацию: если первый ответ не подошел, агент сам уточняет поиск, меняет термины и делает deeper research внутри ваших внутренних знаний.
Еще они рассказали как пытались строить собственную multi-agent orchestration-модель с planning/coding/validation agents, но рынок двигался слишком быстро, а маленькая команда не успевала наращивать нужную "мышцу". Поэтому Airbnb не уперлись в "мы обязаны написать свой оркестратор", а сделали прагматичный поворот (pivot): основной агент теперь живет как CLI-agent, а сверху у него тонкая прокладка для других поверхностей. Круто, что ребята честно рассказали про свое решение - зачастую синдром NIH (Not Invented Here) не позволяет принять такое решение или даже если оно принято, то не позволяет о его принятии рассказывать:)
Если подбивать выводы ребят из их пути, то они примерно такие
1) Agentic coding - это не просто чат в IDE, это новый inner loop, где агент многократно дергает LLM, инструменты и внутренние знания, а на выходе приносит код, который все равно должен быть просмотрен человеком до PR
2) Рост идет не только от auto-approve настройки агента, а от умения инженера управлять несколькими параллельными workspaces; в Airbnb некоторые продвинутые пользователи открывают до пяти агентных сессий одновременно
3) Агент сам по себе ничего не решает: вокруг него нужны sandbox/workspace-инфраструктура, auth, security paved path, шаблоны, установка в одну команду и нормальная review-культура
4) А организационный вывод ребят такой - не надо ломать существующие привычки команд ради модного AI UX. Они прямо говорят, что идея "давайте всех пользователей IntelliJ переведем в VS Code, потому что там лучше agentic tooling" быстро провалилась. Вместо этого нужно убирать барьеры, встречать разработчиков там, где они уже работают, и стандартизировать только то, что действительно стабилизировалось на рынке. При этом качество нельзя опускать "потому что это AI": стандарты остаются прежними, ревью обязателен, код тоже должен быть готовым к проду, а пользоваться auto-approve без набитой руки - опасно.
В общем, основная идея не в том, чтобы купить лучший AI-ассистент (Claude Code, OpenAI Codex, Cursor, выбери свой любимый), а в том, что собрать проторенный путь вокруг агентов: поверхности для взаимодействия, доступ к знаниям, вызов инструментов, стандартизация, измерения и ревью человеком. И только потом ждать реального прироста ключевых метрик разработки, а не локального wow-эффекта.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Telegram
Книжный куб
[1/2] Agentic coding at Airbnb (Рубрика #Agents)
Это очередной интересный доклад с сентябрьского DPE Summit, про который я рассказывал раньше. В нем ребята из Airnbnb рассказывали как они выстроили у себя агентскую модель разработки и двинулись от классического…
Это очередной интересный доклад с сентябрьского DPE Summit, про который я рассказывал раньше. В нем ребята из Airnbnb рассказывали как они выстроили у себя агентскую модель разработки и двинулись от классического…
❤8🔥7⚡3
Распределённые системы без магии: что на самом деле говорят CAP и PACELC (Рубрика #SystemDesign)
19 марта я читал студентам Центрального Университета лекцию на широкий набор тем — мы говорили про широко известные в узких кругах теоремы CAP и PACELC, обсудим чем consistency в этих теоремах отличается от consistency в ACID, поговорим про то, как проверяются заявленные гарантии консистентности( на примере проекта от Jepsen), а в конце лекции обсудили Cassandra как пример распределенной базы данных с tunable consistency. Большая часть изложенной теории была взята из статей с моего сайта system-design.space, а после лекции у ребят был еще семинар, где они могли покрутить Cassandra руками и попробовать работу этих теорем на практике.
Мне самому понравилось рассказывать материал, но в этой расшифровке я решил сделать акцент не на теории, а на простой мысли, что в распределённых системах нет волшебства. Хотя мне очень нравится третий закон Артура Кларка
Но если быть практиком и инженером, то мжно отметить, что нет такой базы данных, такой сетевой топологии или такой архитектурной диаграммы, которая позволит одновременно быть всегда доступными, всегда согласованными и всегда быстрыми без всякой цены. Архитектура распределённой системы начинается в тот момент, когда мы перестаём искать магию и начинаем честно проектировать компромиссы. CAP, PACELC, модели консистентности, Jepsen и Cassandra — это, по сути, разные способы проговорить одну и ту же реальность.
#Architecture #Management #SystemDesign #Software #Engineering #Database
19 марта я читал студентам Центрального Университета лекцию на широкий набор тем — мы говорили про широко известные в узких кругах теоремы CAP и PACELC, обсудим чем consistency в этих теоремах отличается от consistency в ACID, поговорим про то, как проверяются заявленные гарантии консистентности( на примере проекта от Jepsen), а в конце лекции обсудили Cassandra как пример распределенной базы данных с tunable consistency. Большая часть изложенной теории была взята из статей с моего сайта system-design.space, а после лекции у ребят был еще семинар, где они могли покрутить Cassandra руками и попробовать работу этих теорем на практике.
Мне самому понравилось рассказывать материал, но в этой расшифровке я решил сделать акцент не на теории, а на простой мысли, что в распределённых системах нет волшебства. Хотя мне очень нравится третий закон Артура Кларка
Любая достаточно развитая технология неотличима от магии
Но если быть практиком и инженером, то мжно отметить, что нет такой базы данных, такой сетевой топологии или такой архитектурной диаграммы, которая позволит одновременно быть всегда доступными, всегда согласованными и всегда быстрыми без всякой цены. Архитектура распределённой системы начинается в тот момент, когда мы перестаём искать магию и начинаем честно проектировать компромиссы. CAP, PACELC, модели консистентности, Jepsen и Cassandra — это, по сути, разные способы проговорить одну и ту же реальность.
#Architecture #Management #SystemDesign #Software #Engineering #Database
Medium
Распределённые системы без магии: что на самом деле говорят CAP и PACELC
19 марта я читал студентам Центрального Университета лекцию на широкий набор тем — мы говорили про широко известные в узких кругах теоремы…
❤11🔥3⚡2
От AI-native разработки к AI-native организации (с примерами из опыта бигтехов (Рубрика #AI)
Написал статью-продолжение к статье про ai-native разработку "От классического PDLC к AI-native разработке". Основная завязка новой статьи крутится вокруг идеи, что если переход к ai-native разработке меняет сам инженерный процесс, то дальше меняется оргструктура - это видно по анонсам и действиям бигтех компаний, что из больших активнее всего участвуют в гонке AI. А дальше это затронет и остальных. Суть в том, что когда требования, код, тесты и документация начинают собираться в разы быстрее, узким местом становится уже не написание артефактов, а принятие решений, передача контекста и количество организационных слоёв. Отсюда следующий шаг: компаниям мало просто выдать инженерам AI-инструменты. Нужна оргмодель, которая умеет переваривать новую скорость работы. Это обычно означает меньше слоёв управления, больший вес senior+/staff+ IC, сильную внутреннюю платформу, self-service, guardrails и agentic workflows. Важно, что переход к более плоской структуре (flattening) - это не только про срезание затрат. Это попытка повысить выхлоп на сотрудника и убрать организационное трение на единицу результата. Правда, такая модель не работает сама по себе: без сильной платформы, качественного CI/CD, прозрачных policy checks и понятных правил принятия решений AI просто ускорит хаос.
В общем, следующим уровнем конкуренции будет не просто сделать AI-native разработку, про которую я писал раньше, а скорее способность построить AI-native организацию вокруг людей, платформ и агентов.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign
Написал статью-продолжение к статье про ai-native разработку "От классического PDLC к AI-native разработке". Основная завязка новой статьи крутится вокруг идеи, что если переход к ai-native разработке меняет сам инженерный процесс, то дальше меняется оргструктура - это видно по анонсам и действиям бигтех компаний, что из больших активнее всего участвуют в гонке AI. А дальше это затронет и остальных. Суть в том, что когда требования, код, тесты и документация начинают собираться в разы быстрее, узким местом становится уже не написание артефактов, а принятие решений, передача контекста и количество организационных слоёв. Отсюда следующий шаг: компаниям мало просто выдать инженерам AI-инструменты. Нужна оргмодель, которая умеет переваривать новую скорость работы. Это обычно означает меньше слоёв управления, больший вес senior+/staff+ IC, сильную внутреннюю платформу, self-service, guardrails и agentic workflows. Важно, что переход к более плоской структуре (flattening) - это не только про срезание затрат. Это попытка повысить выхлоп на сотрудника и убрать организационное трение на единицу результата. Правда, такая модель не работает сама по себе: без сильной платформы, качественного CI/CD, прозрачных policy checks и понятных правил принятия решений AI просто ускорит хаос.
В общем, следующим уровнем конкуренции будет не просто сделать AI-native разработку, про которую я писал раньше, а скорее способность построить AI-native организацию вокруг людей, платформ и агентов.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign
Medium
От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)
В прошлой статье «От классического PDLC к AI-native разработке» я писал, что переход к AI-native разработке меняет не только скорость…
🔥21❤5⚡2😁1🤣1
State of Code Developer Survey report by SonarSource (Рубрика #AI)
Интересный 57-страничный отчет от производителя SonarQube, средства для верификации качества кода. Отчет вышел еще 8 января 2026 года, а основан был на опросе от октября 2025 года. Если обобщить одной фразой основную мысль, то она такая: AI не снял нагрузку с разработки - он просто перенёс бутылочное горлышко из написания в в верификацию кода.
Методология исследования выглядела как количественный онлайн-опрос на 1149 респондентов по всему миру. В выборке - взрослые специалисты в tech-ролях, которые пишут код или управляют разработчиками и использовали AI в работе за последний год. Вопросы были не просто "используете ли вы AI", а как именно он меняет инженерную работу:
- Где AI реально помогает
- Где есть разрыв между принятием (adoption) и эффетивностью (effectiveness)
- Доверяют ли разработчики AI-коду
- Как меняются безопасность и технический долг
- Что происходит с junior/senior инженерами и есть ли разница в их отношении к AI
- Что с использованием AI агентов
- Что происходит с управлением всем этим зоопарком инструментов
Результаты вышли такие
- AI уже не эксперимент, а рутина: 72% тех, кто попробовал AI coding tools, используют их каждый день, а в среднем 42% кода в коммитах уже AI-generated или AI-assisted
- Ценность AI распределена неровно: лучше всего AI показывает себя в документации, объяснении существующего кода и генерации тестов; заметно хуже - в рефакторинге и изменении существующего кода (напомню этот опрос был до большого сдвига в возможностях моделей осенью 2025 года)
- Параллельно команды жонглируют в среднем 4 AI-инструментами, а 35% разработчиков используют часть из них через личные аккаунты, а не через санкционированный на работе доступ.
В итоге, скорость личная выросла, но доверие не появилось. 96% не полностью доверяют функциональной корректности AI-кода. 95% тратят время на review/testing/fixing AI output, 38% говорят, что ревьюить AI-код сложнее, чем человеческий, а только 48% всегда проверяют AI-assisted code перед commit. Неудивительно, что самым важным навыком в AI-era респонденты назвали ревью и валидацию AI-кода на качество и безопасность.
Если говорить про больные места, то 57% опасаются утечки чувствительных данных, 47% - появления новых subtle security vulnerabilities. По техническому долгу картина тоже двойственная: 88% увидели хотя бы один негативный эффект AI на долг, чаще всего “код выглядит правильным, но ненадёжен” (53%) и лишний/дублирующий код (40%). Но 93% одновременно увидели и пользу: AI помогает с документацией, тестами/debugging и частью refactoring work. Junior-разработчики чаще опираются на AI и чаще говорят, что проверка такого кода требует больше усилий, чем у senior.
Также заметна разница между организациями разного масштаба:
- Малые и средние компании (SMB) снимают больше пользы с ускорения поставки и быстрее улучшают time-to-market, а корпораты чаще видят улучшения в качестве кода и поддерживаемости - похоже, за счёт более жёсткой governance и контроля AI-рисков.
Выводы авторов отчета простые - процессам разработки нужно понимать происхожение кода, усилить ревью кода, добавить quality gates, статический анализ, и выстроить нормальный governance вокруг AI-инструментов. Иначе ускоряется не поставка, а производство непроверенного кода. Ну и конечно со всем этим может помочь SonarQube от авторов исследования:)
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
Интересный 57-страничный отчет от производителя SonarQube, средства для верификации качества кода. Отчет вышел еще 8 января 2026 года, а основан был на опросе от октября 2025 года. Если обобщить одной фразой основную мысль, то она такая: AI не снял нагрузку с разработки - он просто перенёс бутылочное горлышко из написания в в верификацию кода.
Методология исследования выглядела как количественный онлайн-опрос на 1149 респондентов по всему миру. В выборке - взрослые специалисты в tech-ролях, которые пишут код или управляют разработчиками и использовали AI в работе за последний год. Вопросы были не просто "используете ли вы AI", а как именно он меняет инженерную работу:
- Где AI реально помогает
- Где есть разрыв между принятием (adoption) и эффетивностью (effectiveness)
- Доверяют ли разработчики AI-коду
- Как меняются безопасность и технический долг
- Что происходит с junior/senior инженерами и есть ли разница в их отношении к AI
- Что с использованием AI агентов
- Что происходит с управлением всем этим зоопарком инструментов
Результаты вышли такие
- AI уже не эксперимент, а рутина: 72% тех, кто попробовал AI coding tools, используют их каждый день, а в среднем 42% кода в коммитах уже AI-generated или AI-assisted
- Ценность AI распределена неровно: лучше всего AI показывает себя в документации, объяснении существующего кода и генерации тестов; заметно хуже - в рефакторинге и изменении существующего кода (напомню этот опрос был до большого сдвига в возможностях моделей осенью 2025 года)
- Параллельно команды жонглируют в среднем 4 AI-инструментами, а 35% разработчиков используют часть из них через личные аккаунты, а не через санкционированный на работе доступ.
В итоге, скорость личная выросла, но доверие не появилось. 96% не полностью доверяют функциональной корректности AI-кода. 95% тратят время на review/testing/fixing AI output, 38% говорят, что ревьюить AI-код сложнее, чем человеческий, а только 48% всегда проверяют AI-assisted code перед commit. Неудивительно, что самым важным навыком в AI-era респонденты назвали ревью и валидацию AI-кода на качество и безопасность.
Если говорить про больные места, то 57% опасаются утечки чувствительных данных, 47% - появления новых subtle security vulnerabilities. По техническому долгу картина тоже двойственная: 88% увидели хотя бы один негативный эффект AI на долг, чаще всего “код выглядит правильным, но ненадёжен” (53%) и лишний/дублирующий код (40%). Но 93% одновременно увидели и пользу: AI помогает с документацией, тестами/debugging и частью refactoring work. Junior-разработчики чаще опираются на AI и чаще говорят, что проверка такого кода требует больше усилий, чем у senior.
Также заметна разница между организациями разного масштаба:
- Малые и средние компании (SMB) снимают больше пользы с ускорения поставки и быстрее улучшают time-to-market, а корпораты чаще видят улучшения в качестве кода и поддерживаемости - похоже, за счёт более жёсткой governance и контроля AI-рисков.
Выводы авторов отчета простые - процессам разработки нужно понимать происхожение кода, усилить ревью кода, добавить quality gates, статический анализ, и выстроить нормальный governance вокруг AI-инструментов. Иначе ускоряется не поставка, а производство непроверенного кода. Ну и конечно со всем этим может помочь SonarQube от авторов исследования:)
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
❤8👍6🔥3
Измеряя AI в SDLC: от adoption-метрик к бизнес-ценности и пользовательскому результату (Рубрика #AI)
Примерно неделю назад моя коллега Анна Громова выступала на митапе Yandex AI Dev Day. Она руководит продуктовой аналитикой внутренних платформ, процессов SDLC и AI-инструментов, собственно поэтому она и могла лучше всех рассказать эту тему. Выступление было достаточно коротким и имело примерно такую структуру
1️⃣ Что такое SDLC и зачем его мерить
Если упрощать, то software development life cycle - это процесс поставки кода в продакшн. Для его оценки в Т-Банке применили три широко известных в узких кругах фреймворка:
- DORA - старейший фреймворк, что оценивает скорость и надёжность поставки (вот тут я рассказывал как фреймворк в 2026 году прирос пятой метрикой)
- SPACE - фреймворк, что учитывает не только конвейер, но и удовлетворённость, состояние потока разработчика, и еще кучу всего (вот выступление Саши Кусургашева от лета 2025 года, где он рассказал как мы готовим этот фреймворк)
- DevEx - фреймворк с фокусом на когнитивной нагрузке, переключении контекста, цикле обратной связи (вот выступление Вовы Калугина про то, как мы готовим DevEx)
Применив мысли из этих референсных фреймворков, мы в Т-Банке построили "дерево метрик" (но оно скорее похоже на сеть ): верхний уровень - DORA, нижний - DevEx, SPACE -где-то посередине + на нем основан полугодовой опрос тысяч инженеров.
Кстати, про все эьт подходы DORA, SPACE, DevEx я уже много раньше рассказывал.
2️⃣ AI-ассистент Т-Банка и его уровень принятия (adoption)
Внутренний AI-ассистент внедрён в IDE, Jupyter-ноутбуки, BI-системы, GitLab, observability и поиск. Режимы работы в IDE: подсказки, чат, агентский режим. Метрики принятия
- IDE (от пользователей GitLab) - ~70–75%
- Инструменты аналитики - ~75%
- Все поверхности суммарно - ~57%
При таком уровне использования уже можно делать выводы о влиянии AI на метрики SDLC.
3️⃣ От adoption-метрик к пользовательским сценариям
Раньше считали только adoption: новые пользователи, отток, доля сгенерированных артефактов, "осмысленность" использования (перегенерация, сброс контекста), лайки/дизлайки.
В 2025–2026 году перешли к пирамиде метрик:
- Верхний уровень - бизнес-метрики SDLC (time to market, надёжность)
- Средний - закрытые пользовательские сценарии (генерация юнит-тестов, помощь в code review и т.д.)
- Нижний - технические метрики ассистента (скорость, версия модели)
Это позволяет одновременно отвечать на бизнес-вопросы и развивать AI-продукт.
4️⃣ Роль телеметрии
Ключевой тезис: сначала определить метрики → потом решить, какие логи собирать, а не наоборот. Это сокращает "приседания" вокруг телеметрии и фокусирует на реальной цели. Единые данные важны, чтобы результаты разных команд (AI-команда, CICD-команда) были консистентны между собой.
В докладе есть еще ряд чисел про результаты внедрения в разные сценарии, но я оставлю это тем, кто заинтересовался и готов посмотреть оригинальное видео.
А вообще, выступление полезное и интересное, а также оно демонстрирует, что в России мы близки к SOTA по методам измерения влияния AI на разработку (но у нас есть множество идей, как приблизится к SOTA на глобальном уровне).
#AI #Metrics #Engineering #Management #Software
Примерно неделю назад моя коллега Анна Громова выступала на митапе Yandex AI Dev Day. Она руководит продуктовой аналитикой внутренних платформ, процессов SDLC и AI-инструментов, собственно поэтому она и могла лучше всех рассказать эту тему. Выступление было достаточно коротким и имело примерно такую структуру
1️⃣ Что такое SDLC и зачем его мерить
Если упрощать, то software development life cycle - это процесс поставки кода в продакшн. Для его оценки в Т-Банке применили три широко известных в узких кругах фреймворка:
- DORA - старейший фреймворк, что оценивает скорость и надёжность поставки (вот тут я рассказывал как фреймворк в 2026 году прирос пятой метрикой)
- SPACE - фреймворк, что учитывает не только конвейер, но и удовлетворённость, состояние потока разработчика, и еще кучу всего (вот выступление Саши Кусургашева от лета 2025 года, где он рассказал как мы готовим этот фреймворк)
- DevEx - фреймворк с фокусом на когнитивной нагрузке, переключении контекста, цикле обратной связи (вот выступление Вовы Калугина про то, как мы готовим DevEx)
Применив мысли из этих референсных фреймворков, мы в Т-Банке построили "дерево метрик" (
Кстати, про все эьт подходы DORA, SPACE, DevEx я уже много раньше рассказывал.
2️⃣ AI-ассистент Т-Банка и его уровень принятия (adoption)
Внутренний AI-ассистент внедрён в IDE, Jupyter-ноутбуки, BI-системы, GitLab, observability и поиск. Режимы работы в IDE: подсказки, чат, агентский режим. Метрики принятия
- IDE (от пользователей GitLab) - ~70–75%
- Инструменты аналитики - ~75%
- Все поверхности суммарно - ~57%
При таком уровне использования уже можно делать выводы о влиянии AI на метрики SDLC.
3️⃣ От adoption-метрик к пользовательским сценариям
Раньше считали только adoption: новые пользователи, отток, доля сгенерированных артефактов, "осмысленность" использования (перегенерация, сброс контекста), лайки/дизлайки.
В 2025–2026 году перешли к пирамиде метрик:
- Верхний уровень - бизнес-метрики SDLC (time to market, надёжность)
- Средний - закрытые пользовательские сценарии (генерация юнит-тестов, помощь в code review и т.д.)
- Нижний - технические метрики ассистента (скорость, версия модели)
Это позволяет одновременно отвечать на бизнес-вопросы и развивать AI-продукт.
4️⃣ Роль телеметрии
Ключевой тезис: сначала определить метрики → потом решить, какие логи собирать, а не наоборот. Это сокращает "приседания" вокруг телеметрии и фокусирует на реальной цели. Единые данные важны, чтобы результаты разных команд (AI-команда, CICD-команда) были консистентны между собой.
В докладе есть еще ряд чисел про результаты внедрения в разные сценарии, но я оставлю это тем, кто заинтересовался и готов посмотреть оригинальное видео.
А вообще, выступление полезное и интересное, а также оно демонстрирует, что в России мы близки к SOTA по методам измерения влияния AI на разработку (но у нас есть множество идей, как приблизится к SOTA на глобальном уровне).
#AI #Metrics #Engineering #Management #Software
YouTube
Измеряя AI в SDLC: от adoption-метрик к бизнес-ценности и пользовательскому результату
На митапе Яндекса AI Dev Day Анна Громова, руководитель продуктовой аналитики в управлении базовых технологий Т-Банка, рассказывает:
Как понять, что AI в разработке приносит реальную пользу, а не просто используется? В докладе Анна разбирает, как оценивать…
Как понять, что AI в разработке приносит реальную пользу, а не просто используется? В докладе Анна разбирает, как оценивать…
3❤11🔥7⚡4
Silicon sampling (Рубрика #RnD)
Сегодня я общался с коллегой, что занимается у нас платформой для проведения качественных и количественных исследований (привет, Андрей ). В ходе общения я вспомнил про этот интересный и быстроразвивающийся подход к их проведению, где LLM получает социодемографическую «биографию» (backstory) персоны и отвечает на вопросы опроса от её имени. Это позволяет воспроизводить мнения тысяч демографических групп без рекрутинга реальных участников. Дальше мне стало интересно, а какие вообще существуют ключевые исследования в этой теме и так я получил подборку ниже
- Argyle et al., 2023 - "Out of One, Many" - это классическая основополагающая работа, которая вводит понятие "алгоритмической точности" (algorithmic fidelity). GPT-3 использует backstories из ANES и Pew. (потом еще вышла в Political Analysis от Cambridge)
- Aher, Arriaga, Kalai (ICML 2023) - "Using Large Language Models to Simulate Multiple Humans and Replicate Human Subject Studies" — метод репликации классических социологических экспериментов (Milgram, Ultimatum Game и др.) на популяции LLM-персон без единого живого участника.
- Santurkar et al. (2023) - "Whose Opinions Do Language Models Reflect?" - создали датасет OpinionQA из 500 спорных вопросов, сравнили 9 LLM с 60 демографическими группами США. Вывод: несоответствие сравнимо с пропастью между демократами и республиканцами по климату.
- Hu & Collier (2024) - "Quantifying the Persona Effect" - персона объясняет менее 10% дисперсии, но даёт статистически значимый прирост. Найдена линейная зависимость: чем сильнее корреляция переменных персоны с мнением, тем точнее симуляция.
- Tejaswani Dash et al (2025) - "Polypersona: Persona-Grounded LLM for Synthetic Survey Responses" - open-source фреймворк с датасетом из 3 568 ответов по 433 уникальным персонам, предназначен для instruction-tuning
- Taday Morocho et al. (2026) - "Assessing the Reliability" - протестировали 70 000+ пар на данных World Values Survey. Persona prompting не даёт стабильного улучшения и в ряде случаев ухудшает результат.
Подход выглядит как вундер-вафля, но есть и некоторые проблемки
- Ordering bias (модели систематически предпочитают первый вариант ответа
- Underrepresented groups - 65+, вдовцы, меньшинства воспроизводятся хуже всего
- Корреляционная слепота - fine-tuned модели точнее по маргиналям, но обе техники не восстанавливают латентную структуру корреляций реальной популяции
В whitepaper Lin (2024) в "Six Fallacies in Substituting Large Language Models for Human Participants" систематически перечисляются типичные ошибки в интерпретации таких исследований.
А вообще, если вы делаете платформу для количественных и качественных исследований, то есть смысл добавить туда "silicon sampling" как один из подходов для проведения исследований:)
#AI #Engineering #RnD #Science #Research
Сегодня я общался с коллегой, что занимается у нас платформой для проведения качественных и количественных исследований (
- Argyle et al., 2023 - "Out of One, Many" - это классическая основополагающая работа, которая вводит понятие "алгоритмической точности" (algorithmic fidelity). GPT-3 использует backstories из ANES и Pew. (потом еще вышла в Political Analysis от Cambridge)
- Aher, Arriaga, Kalai (ICML 2023) - "Using Large Language Models to Simulate Multiple Humans and Replicate Human Subject Studies" — метод репликации классических социологических экспериментов (Milgram, Ultimatum Game и др.) на популяции LLM-персон без единого живого участника.
- Santurkar et al. (2023) - "Whose Opinions Do Language Models Reflect?" - создали датасет OpinionQA из 500 спорных вопросов, сравнили 9 LLM с 60 демографическими группами США. Вывод: несоответствие сравнимо с пропастью между демократами и республиканцами по климату.
- Hu & Collier (2024) - "Quantifying the Persona Effect" - персона объясняет менее 10% дисперсии, но даёт статистически значимый прирост. Найдена линейная зависимость: чем сильнее корреляция переменных персоны с мнением, тем точнее симуляция.
- Tejaswani Dash et al (2025) - "Polypersona: Persona-Grounded LLM for Synthetic Survey Responses" - open-source фреймворк с датасетом из 3 568 ответов по 433 уникальным персонам, предназначен для instruction-tuning
- Taday Morocho et al. (2026) - "Assessing the Reliability" - протестировали 70 000+ пар на данных World Values Survey. Persona prompting не даёт стабильного улучшения и в ряде случаев ухудшает результат.
Подход выглядит как вундер-вафля, но есть и некоторые проблемки
- Ordering bias (модели систематически предпочитают первый вариант ответа
- Underrepresented groups - 65+, вдовцы, меньшинства воспроизводятся хуже всего
- Корреляционная слепота - fine-tuned модели точнее по маргиналям, но обе техники не восстанавливают латентную структуру корреляций реальной популяции
В whitepaper Lin (2024) в "Six Fallacies in Substituting Large Language Models for Human Participants" систематически перечисляются типичные ошибки в интерпретации таких исследований.
А вообще, если вы делаете платформу для количественных и качественных исследований, то есть смысл добавить туда "silicon sampling" как один из подходов для проведения исследований:)
#AI #Engineering #RnD #Science #Research
arXiv.org
Out of One, Many: Using Language Models to Simulate Human Samples
We propose and explore the possibility that language models can be studied as effective proxies for specific human sub-populations in social science research. Practical and research applications...
❤3🔥3😐2👍1
Транспортные протоколы для AI-агентов (Рубрика #AI)
За последний год мы наблюдаем интересную эволюцию: AI постепенно перестаёт быть "надстройкой" над существующими интерфейсами и начинает формировать собственный слой взаимодействия. Вспомним путь, которые прошли протоколы MCP, A2A, A2UI
- MCP (Model Context Protocol)
Это попытка от Antrhropic стандартизировать, как модели получают доступ к контексту (файлы, базы, API). По сути, это про data plane для LLM
- A2A (Agent-to-Agent)
Это попытка от Google выстроить коммуникации между агентами как между равноправными участниками системы. По сути формализует диалоги, delegation, coordination. Раньше я уже сравнивал MCP и A2A протоколы
- A2UI (Agent-to-UI)
Предложенный Google протокол вокруг идеи того, что UI становится не primary интерфейсом, а "рендером" агентных действий. В итоге, пользователь взаимодействует с агентом, а не с формой/кнопками. Раньше я уже про него рассказывал
Если смотреть на тренды, то мы больше не описываем API для людей - мы описываем намерения для агентов
Продолжая эту тенденцию дальше мы приходим к идее собственного транспортного протокола для агентов, так как сейчас агентский мир живет поверх обычного http, который
- Заточен под request/response
- Плохо выражает intent (всё прячется в JSON)
- Не имеет нативной модели identity/authority для агентов
- Не оптимизирован под высокочастотный stateful трафик
И мы получаем агентные системы, которые выглядят как RPC поверх HTTP с кучей костылей.
Дальше появляется мысль вынести агентную коммуникацию в отдельный протокол ««« мы здесь
И у нас уже есть два кандидата в такой протокол: AGTP (19 марта 2026 года) и ATP (22 марта 2026 года)
1️⃣ AGTP (Agent Transfer Protocol, Chris Hood)
Этот протокол предлагает
- Новые методы вместо HTTP verbs:
А значит intent становится частью протокола
- Protocol-level identity:
А значит больше не нужно прятать это в headers/body
- Новая система статусов
Она отражает результат агентных действий, а не HTTP semantics
- Транспорт
Приоритет отдается QUIC (стримы, low latency), fallback на TCP/TLS
Основная идея в том, чтобы сделать трафик агентов наблюдаемым и управляемым на уровне сети
2️⃣ ATP (Agent Transfer Protocol, Li et al.)
Независимая инициатива, с похожими целями:
- Специализированные примитивы для agent workflows
- Поддержка stateful взаимодействия
- Фокус на interoperability между агентами разных систем
У протоколов есть как похожие черты, так и отличия
Общие черты
- Отказ от HTTP как универсального слоя
- Intent-driven коммуникация
- Встроенные identity/authority модели
- Подготовка к high-frequency agent traffic
Различия
- AGTP - более "операционный" (методы, статусы, observability) и уже предлагает более конкретную структуру протокола
- ATP - более "концептуальный" (interoperability и primitives)
Но мало ли сколько предложений о новых протоколах бывает. Конкретно эти интересны тем, что мы приходим к разделению интернета на два слоя
1. Human web (HTTP, UI, REST)
2. Agent web (AGTP/ATP, intent, delegation)
А это влияет на остальные моменты, например
- API gateway будут понимать agent traffic нативно
- В observability стеке появятся метрики уровня intent
- В security identity агентов станет first-class
- А SDK перестанут быть "обёртками над REST"
Если эти протоколы взлетят, нас ждёт
- Отдельные agent-native API gateways
- Маршрутизация по intent, а не по URL
- Policy engines на уровне агентных действий
- Встроенная экономика взаимодействия агентов (оплата, квоты, ...)
- Тесная интеграция с DNS и service discovery
Нам как архитекторам придется думать не только про API, но и про семантику действий. Архитектуры будут смещаться от request/response к workflow orchestration. Observability нужно будет строить вокруг intent и outcome, а не только latency, ну и конечно нам придется построить новый платформенный слой под агентов:)
#AI #Architecture #DistributedSystems #Network #SystemDesign #Software
За последний год мы наблюдаем интересную эволюцию: AI постепенно перестаёт быть "надстройкой" над существующими интерфейсами и начинает формировать собственный слой взаимодействия. Вспомним путь, которые прошли протоколы MCP, A2A, A2UI
- MCP (Model Context Protocol)
Это попытка от Antrhropic стандартизировать, как модели получают доступ к контексту (файлы, базы, API). По сути, это про data plane для LLM
- A2A (Agent-to-Agent)
Это попытка от Google выстроить коммуникации между агентами как между равноправными участниками системы. По сути формализует диалоги, delegation, coordination. Раньше я уже сравнивал MCP и A2A протоколы
- A2UI (Agent-to-UI)
Предложенный Google протокол вокруг идеи того, что UI становится не primary интерфейсом, а "рендером" агентных действий. В итоге, пользователь взаимодействует с агентом, а не с формой/кнопками. Раньше я уже про него рассказывал
Если смотреть на тренды, то мы больше не описываем API для людей - мы описываем намерения для агентов
Продолжая эту тенденцию дальше мы приходим к идее собственного транспортного протокола для агентов, так как сейчас агентский мир живет поверх обычного http, который
- Заточен под request/response
- Плохо выражает intent (всё прячется в JSON)
- Не имеет нативной модели identity/authority для агентов
- Не оптимизирован под высокочастотный stateful трафик
И мы получаем агентные системы, которые выглядят как RPC поверх HTTP с кучей костылей.
Дальше появляется мысль вынести агентную коммуникацию в отдельный протокол ««« мы здесь
И у нас уже есть два кандидата в такой протокол: AGTP (19 марта 2026 года) и ATP (22 марта 2026 года)
1️⃣ AGTP (Agent Transfer Protocol, Chris Hood)
Этот протокол предлагает
- Новые методы вместо HTTP verbs:
QUERY, EXECUTE, BOOK, ESCALATEА значит intent становится частью протокола
- Protocol-level identity:
agent_id, authority, delegation chainА значит больше не нужно прятать это в headers/body
- Новая система статусов
Она отражает результат агентных действий, а не HTTP semantics
- Транспорт
Приоритет отдается QUIC (стримы, low latency), fallback на TCP/TLS
Основная идея в том, чтобы сделать трафик агентов наблюдаемым и управляемым на уровне сети
2️⃣ ATP (Agent Transfer Protocol, Li et al.)
Независимая инициатива, с похожими целями:
- Специализированные примитивы для agent workflows
- Поддержка stateful взаимодействия
- Фокус на interoperability между агентами разных систем
У протоколов есть как похожие черты, так и отличия
Общие черты
- Отказ от HTTP как универсального слоя
- Intent-driven коммуникация
- Встроенные identity/authority модели
- Подготовка к high-frequency agent traffic
Различия
- AGTP - более "операционный" (методы, статусы, observability) и уже предлагает более конкретную структуру протокола
- ATP - более "концептуальный" (interoperability и primitives)
Но мало ли сколько предложений о новых протоколах бывает. Конкретно эти интересны тем, что мы приходим к разделению интернета на два слоя
1. Human web (HTTP, UI, REST)
2. Agent web (AGTP/ATP, intent, delegation)
А это влияет на остальные моменты, например
- API gateway будут понимать agent traffic нативно
- В observability стеке появятся метрики уровня intent
- В security identity агентов станет first-class
- А SDK перестанут быть "обёртками над REST"
Если эти протоколы взлетят, нас ждёт
- Отдельные agent-native API gateways
- Маршрутизация по intent, а не по URL
- Policy engines на уровне агентных действий
- Встроенная экономика взаимодействия агентов (оплата, квоты, ...)
- Тесная интеграция с DNS и service discovery
Нам как архитекторам придется думать не только про API, но и про семантику действий. Архитектуры будут смещаться от request/response к workflow orchestration. Observability нужно будет строить вокруг intent и outcome, а не только latency, ну и конечно нам придется построить новый платформенный слой под агентов:)
#AI #Architecture #DistributedSystems #Network #SystemDesign #Software
Telegram
Книжный куб
[1/x] Model Context Protocol (MCP) и Agent-to-Agent (A2A) (Рубрика #AI)
В рамках подготовки к докладу про переход от ассистентов к агентам я решил изучить как мы пришли к двум самым популярным протоколам для LLM. И я говорю про MCP от Anthropic и A2A протокол…
В рамках подготовки к докладу про переход от ассистентов к агентам я решил изучить как мы пришли к двум самым популярным протоколам для LLM. И я говорю про MCP от Anthropic и A2A протокол…
🔥20❤5👍3👀1
The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI (Рубрика #AI)
Посмотрел свежий выпуск подкаста "No Priors" с Andrej Karpathy. Эта серия была опубликована 20 марта 2026 и с Андреем общается Sarah Guo, основатель Conviction и ведущая подкаста, а главной мыслью выпуска была тема о том, что software engineering уже сдвигается от написания кода к оркестровке агентов. По словам Андрея, он с декабря почти перестал писать код руками и резко сместился в режим делегирования задач агентам; по его ощущению, у многих инженеров frontier-уровня default workflow уже успел радикально поменяться.
Другая интересная мысль в том, что бутылочное горлышко сместилось с IDE и даже вычислительных мощностей в сторону человека - Андрей описывает это как переход от мышления про FLOPS к мышлению про пропускную способность токенов (token throughput). Если агент может автономно 20 минут делать кусок работы, то ценность инженера смещается в правильную декомпозицию задач, параллельный запуск нескольких потоков и review на уровне архитектуры, а не строк кода.
Интересна также тема AutoResearch - если у задачи есть объективные метрики, то агент может сам менять код, запускать короткие эксперименты, измерять результат и оставлять только улучшения. В открытом репозитории Karpathy это оформлено почти как минимальная исследовательская ОС: агент правит
Правда, Андрей отмечает, что такой режим работает не всегда, а только там, где есть верифицируемая награда и понятный способ оценки результата (eval). Там, где нужны вкус, есть неформализованные ожидания и мягкие критерии качества, то модели по-прежнему очень неконсистентны: в одном месте блестящие, в другом - удивительно наивные. Это важная поправка к хайпу про "автономных разработчиков".
Также Андрей рассказал про своего домашнего агента Dobby, который через WhatsApp управляет светом, HVAC, шторами, бассейном, спа и безопасностью дома. Из этого он делает жёсткий вывод: возможно, заметная часть сегодняшних приложений - это временный UX-слой, а более правильная архитектура будущего - это API/tool surface + агент как клей.
В общем, это действительно интересный подкаст, в котором Андрей делится практикой, а не футуристическими идеями.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign
Посмотрел свежий выпуск подкаста "No Priors" с Andrej Karpathy. Эта серия была опубликована 20 марта 2026 и с Андреем общается Sarah Guo, основатель Conviction и ведущая подкаста, а главной мыслью выпуска была тема о том, что software engineering уже сдвигается от написания кода к оркестровке агентов. По словам Андрея, он с декабря почти перестал писать код руками и резко сместился в режим делегирования задач агентам; по его ощущению, у многих инженеров frontier-уровня default workflow уже успел радикально поменяться.
Другая интересная мысль в том, что бутылочное горлышко сместилось с IDE и даже вычислительных мощностей в сторону человека - Андрей описывает это как переход от мышления про FLOPS к мышлению про пропускную способность токенов (token throughput). Если агент может автономно 20 минут делать кусок работы, то ценность инженера смещается в правильную декомпозицию задач, параллельный запуск нескольких потоков и review на уровне архитектуры, а не строк кода.
Интересна также тема AutoResearch - если у задачи есть объективные метрики, то агент может сам менять код, запускать короткие эксперименты, измерять результат и оставлять только улучшения. В открытом репозитории Karpathy это оформлено почти как минимальная исследовательская ОС: агент правит
train.py, работает в фиксированном 5-минутном бюджете и оптимизирует val_bpb; program.md фактически становится “кодом исследовательской организации”. Это и есть его автоматическая работа в цикле эксперимент → метрика → изменение → повтор, где человек уже не нужен.Правда, Андрей отмечает, что такой режим работает не всегда, а только там, где есть верифицируемая награда и понятный способ оценки результата (eval). Там, где нужны вкус, есть неформализованные ожидания и мягкие критерии качества, то модели по-прежнему очень неконсистентны: в одном месте блестящие, в другом - удивительно наивные. Это важная поправка к хайпу про "автономных разработчиков".
Также Андрей рассказал про своего домашнего агента Dobby, который через WhatsApp управляет светом, HVAC, шторами, бассейном, спа и безопасностью дома. Из этого он делает жёсткий вывод: возможно, заметная часть сегодняшних приложений - это временный UX-слой, а более правильная архитектура будущего - это API/tool surface + агент как клей.
В общем, это действительно интересный подкаст, в котором Андрей делится практикой, а не футуристическими идеями.
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #SystemDesign
YouTube
The End of Coding: Andrej Karpathy on Agents, AutoResearch, and the Loopy Era of AI
What happens when AI agents can design experiments, collect data, and improve — without a human in the loop? Andrej Karpathy joins Sarah Guo on the state of models, the future of engineering and education, thinking about impact on jobs, and his project AutoResearch:…
🔥9❤5👍4👎3
The Anthropic Economic Index report: Economic Primitives (Рубрика #AI)
В январе вышел интересный отчет от Anthropic, в котором они не только рассказали про то, как Claude помогает всем эффективнее работать, но и поделились новым подходом с экономическими примитивами. Собственно, авторы взяли 1 млн разговоров Claude.ai и 1 млн записей 1P API за 13-20 ноября 2025 и прогнали их через набор простых economic primitives - базовых координат того, как модель используется. Это позволило им уйти от одного большого индекса к нескольким сигналам, что позволяют рассуждать про принятие технологии (adoption), автоматизацию (automation), подверженность работы AI (job exposure) и продуктивности. Авторы выбирали примитивы по экономической релевантности, комплементарности и способности Claude классифицировать их автоматически при помощи простых промптов.
Новых примитивов пять, но фактически это девять классификаторов (приложил их вместе с промптами в качестве картинок)
1) Task complexity: сколько часов заняла бы задача у человека без AI, сколько минут ушло с AI, и есть ли multitasking.
2) Human and AI skills: смог бы человек сделать это без Claude, сколько лет образования нужно, чтобы понять prompt, и сколько - чтобы понять ответ.
3) Use case: work / coursework / personal.
4) AI autonomy: сколько решений реально делегировали модели по шкале 1-5.
5) Task success: справился ли Claude с задачей. И это идет поверх старого измерения automation vs augmentation: например, “переведи абзац на французский” - automation высокая, а autonomy низкая, потому что решать там почти нечего. Инженерная деталь: они пробовали и более сложные classifier’ы, и CoT-подсказки; в итоге CoT оставили только там, где оно реально улучшало качество - для human time, human+AI time и AI autonomy.
Такая классификация позволяет уйти от грубой метрики “AI встретился в задаче” к многофакторной модели: насколько задача сложная, требует ли она редкого человеческого капитала, это работа или учеба, насколько человек уже отдал управление машине, и есть ли вообще шанс, что автоматизация сработает не только красиво в демке, но и в проде. Правда, это не внешняя оценка, а суждение самого Claude.
Для инженеров полезно посмотреть а как эти примитивы позволяют отделить“AI для реальной работы” от “AI как удобная мелочь”. В пользовательской выборке Claude.ai software запросы тянут на 13.8 года необходимого образования и имеют success rate 61%, а вопросы про персональный менеджмен - тянут всего на 9.4 года и имеют 78% success rate. При этом в среднем по Claude.ai выборке задача без AI заняла бы 3.1 часа, с AI - 15.4 минуты; 46% использования —-это work. То есть LLM уже сидят не только в “простых” бытовых сценариях, а занимают значительное место в работе белых воротничков.
Интересно, что чем сложнее и “образованнее” задача (требует больше лет образование), тем больше ускорение, но тем ниже надежность (success rate). В Claude.ai задачи примерно на уровне 12 лет образования дают около 9x ускорения, а на уровне 16 лет - уже около 12x. Но success rate при росте сложности падает: для менее сложных задач он около 70%, а для сценариев уровня колледжа - около 66%. На API ускорение еще выше, но и падение успеха с ростом сложности заметнее.
Ну и последний интересный инсайт, о котором я хотел рассказать - это горизонт времени задачи, на котором она дает 50% успех. Если смотреть на связь success rate и времени, которое человеку понадобилось бы на задачу без AI, то
- у API линия 50% success пересекается примерно на 3.5 часа
- у Claude.ai - примерно на 19 часах.
Авторы честно пишут, что это не чистая capability-метрика, а смесь возможностей модели и поведения пользователя; вероятно, multi-turn диалог помогает дробить длинную работу на управляемые шаги. Но для технических руководителей это знак того, что оркестрация, циклы обратной связи и человек-в-контуре (human in the loop) могут менять экономику AI не меньше, чем новый бенчмарк модели.
#AI #Economics #Metrics #Software #Engineering
В январе вышел интересный отчет от Anthropic, в котором они не только рассказали про то, как Claude помогает всем эффективнее работать, но и поделились новым подходом с экономическими примитивами. Собственно, авторы взяли 1 млн разговоров Claude.ai и 1 млн записей 1P API за 13-20 ноября 2025 и прогнали их через набор простых economic primitives - базовых координат того, как модель используется. Это позволило им уйти от одного большого индекса к нескольким сигналам, что позволяют рассуждать про принятие технологии (adoption), автоматизацию (automation), подверженность работы AI (job exposure) и продуктивности. Авторы выбирали примитивы по экономической релевантности, комплементарности и способности Claude классифицировать их автоматически при помощи простых промптов.
Новых примитивов пять, но фактически это девять классификаторов (приложил их вместе с промптами в качестве картинок)
1) Task complexity: сколько часов заняла бы задача у человека без AI, сколько минут ушло с AI, и есть ли multitasking.
2) Human and AI skills: смог бы человек сделать это без Claude, сколько лет образования нужно, чтобы понять prompt, и сколько - чтобы понять ответ.
3) Use case: work / coursework / personal.
4) AI autonomy: сколько решений реально делегировали модели по шкале 1-5.
5) Task success: справился ли Claude с задачей. И это идет поверх старого измерения automation vs augmentation: например, “переведи абзац на французский” - automation высокая, а autonomy низкая, потому что решать там почти нечего. Инженерная деталь: они пробовали и более сложные classifier’ы, и CoT-подсказки; в итоге CoT оставили только там, где оно реально улучшало качество - для human time, human+AI time и AI autonomy.
Такая классификация позволяет уйти от грубой метрики “AI встретился в задаче” к многофакторной модели: насколько задача сложная, требует ли она редкого человеческого капитала, это работа или учеба, насколько человек уже отдал управление машине, и есть ли вообще шанс, что автоматизация сработает не только красиво в демке, но и в проде. Правда, это не внешняя оценка, а суждение самого Claude.
Для инженеров полезно посмотреть а как эти примитивы позволяют отделить“AI для реальной работы” от “AI как удобная мелочь”. В пользовательской выборке Claude.ai software запросы тянут на 13.8 года необходимого образования и имеют success rate 61%, а вопросы про персональный менеджмен - тянут всего на 9.4 года и имеют 78% success rate. При этом в среднем по Claude.ai выборке задача без AI заняла бы 3.1 часа, с AI - 15.4 минуты; 46% использования —-это work. То есть LLM уже сидят не только в “простых” бытовых сценариях, а занимают значительное место в работе белых воротничков.
Интересно, что чем сложнее и “образованнее” задача (требует больше лет образование), тем больше ускорение, но тем ниже надежность (success rate). В Claude.ai задачи примерно на уровне 12 лет образования дают около 9x ускорения, а на уровне 16 лет - уже около 12x. Но success rate при росте сложности падает: для менее сложных задач он около 70%, а для сценариев уровня колледжа - около 66%. На API ускорение еще выше, но и падение успеха с ростом сложности заметнее.
Ну и последний интересный инсайт, о котором я хотел рассказать - это горизонт времени задачи, на котором она дает 50% успех. Если смотреть на связь success rate и времени, которое человеку понадобилось бы на задачу без AI, то
- у API линия 50% success пересекается примерно на 3.5 часа
- у Claude.ai - примерно на 19 часах.
Авторы честно пишут, что это не чистая capability-метрика, а смесь возможностей модели и поведения пользователя; вероятно, multi-turn диалог помогает дробить длинную работу на управляемые шаги. Но для технических руководителей это знак того, что оркестрация, циклы обратной связи и человек-в-контуре (human in the loop) могут менять экономику AI не меньше, чем новый бенчмарк модели.
#AI #Economics #Metrics #Software #Engineering
🔥10❤7⚡3👎1
TAM-Eval и RM-RF от RnD центра Т-Технологий (Рубрика #Engineering)
Наш R&D-центр представил пару методов TAM-Eval и RM-RF, которые делают генерацию модульных тестов с помощью LLM заметно более практичной для наглядности разработки.
TAM-Eval задает воспроизводимые стандартные оценки качества тестов в живых репозиториях, а RM-RF еще умеет до сборки и запуска предсказать, какие тесты действительно полезны. На практике это означает меньшие дороги прогонов, меньшую нагрузку на инфраструктуру и цикл CI/CD. Это особенно важно в мире, который быстро движется в сторону AI-native разработки (см. пост) : когда код и тесты все чаще генерируют модели, главным конкурентным преимуществом становится уже не только генерация, но и надежная, быстрая оценка качества . Без этого AI-ускорение легко превращается в ИИ-хаос.
Эти статьи хорошо приняты академическим сообществом: RM-RF принята в основной трек SANER 2026 , а TAM-Eval - на VST 2026.
Напоследок процитирую Станислава Моисеева, руководителя RnD центра, который так описывал пользу этих методов
#Engineering #RnD #AI #DevOps #Software
Наш R&D-центр представил пару методов TAM-Eval и RM-RF, которые делают генерацию модульных тестов с помощью LLM заметно более практичной для наглядности разработки.
TAM-Eval задает воспроизводимые стандартные оценки качества тестов в живых репозиториях, а RM-RF еще умеет до сборки и запуска предсказать, какие тесты действительно полезны. На практике это означает меньшие дороги прогонов, меньшую нагрузку на инфраструктуру и цикл CI/CD. Это особенно важно в мире, который быстро движется в сторону AI-native разработки (см. пост) : когда код и тесты все чаще генерируют модели, главным конкурентным преимуществом становится уже не только генерация, но и надежная, быстрая оценка качества . Без этого AI-ускорение легко превращается в ИИ-хаос.
Эти статьи хорошо приняты академическим сообществом: RM-RF принята в основной трек SANER 2026 , а TAM-Eval - на VST 2026.
Напоследок процитирую Станислава Моисеева, руководителя RnD центра, который так описывал пользу этих методов
Эти методы делают работу больших языковых моделей с тестами более предсказуемой и эффективной для реальных процессов разработки. TAM-Eval задает стандарт сравнения моделей и агентов в сопровождении тестов по измеримым метрикам, а RM-RF позволяет отсеивать слабые тесты и ранжировать сильные без дорогостоящего запуска пайплайна на каждом шаге.
#Engineering #RnD #AI #DevOps #Software
🔥12❤4⚡3🌚2
Optimizing for Time: Dark Matter (Рубрика #DevEx)
С большим интересом посмотрел доклад с концеренции DPE Summit Карима Накада (Karim Nakad) из запрещенной в России компании Meta. Мне понравилось название, которое отсылает к космологическим теориям, объясняющим через темную материю состояние нашей Вселенной. Здесь эта метафора относится к тому, что мы часто фокусируемся на видимом спектре разработи: на улучшении IDE и ускорении сборок, но игнорируем огромные затраты времени на ежедневную рутину. Собственно, спикер называет "тёмной материей" невидимую нагрузку на сотрудкниов: чтение корпоративных чатов, стендапы, написание документации и помощь коллегам. Измерение этих скрытых активностей помогает выявить истинные причины снижения скорости работы технических команд.
Мне особенно нравится разбор метрик продуктивности Meta, про которые я говорил и в других постах, например, при разборе выступления "Measuring the Impact of AI on Developer Productivity at Meta" с этой же конференции. Но в этом выступлении этот рассказ сфокусирован именно на метриках. Отдельно отмечается, что в Meta применяют агрегированные показатели для анализа процессов, строго запрещая их использование для индивидуальной оценки инженеров во избежание накруток. Сами метрики такие
- By Tool -» TSD (Time Spent Coding per Diff): отражает время кодинга на один пулл-реквест, что позволяет инфраструктурным командам оценивать эффективность инструментов разработчика.
- By Intent -» PCT (Percent Time Coding): показывает долю чистого программирования по отношению ко всем остальным задачам, помогая сокращать количество лишних встреч. Метрика важна для продуктовых команд
- By Workflow -» WTS (Workflow Time Spent): отслеживает затраты времени в разрезе конкретного процесса (например, устранения инцидента) для поиска узких мест при переключении между системами.
- By Value -» но здесь не показали метрики, а привели метафору про карту и про движение в нужном направлении (как бы это нужное направление не измерялось)
Если говорить про подучу, то мне понравились слайды про фрагментацию дня. На слайдах видно, как день инженера распадается на десятки коротких переключений между IDE, чатом, календарём, review tools, notebook и SQL. Интересно, что Meta предлагает смотреть не только на raw coding time, но и на coding intent time - то есть считать инженерной работой не только минуты в редакторе, но и связанные с задачей походы в чат, wiki, SQL и документацию. Иначе очень легко оптимизировать не то место.
Мне показались полезными идеи для инженеров о том, что надо защищать длинные focus-блоки, группировать коммуникации, глушить некритичные уведомления и перестать думать, что "настоящая работа" происходит только внутри IDE. А руководителям полезно посчитать стоимость переключения контекста и сравнить со стоимостью медленного билда; отдельно посмотреть на фокусное время команды, структуру календаря, объём асинхронного шума и только потом уже докручивать инструментарий. Иначе можно ускорить pipeline и всё равно потерять пропускную способность команды.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
С большим интересом посмотрел доклад с концеренции DPE Summit Карима Накада (Karim Nakad) из запрещенной в России компании Meta. Мне понравилось название, которое отсылает к космологическим теориям, объясняющим через темную материю состояние нашей Вселенной. Здесь эта метафора относится к тому, что мы часто фокусируемся на видимом спектре разработи: на улучшении IDE и ускорении сборок, но игнорируем огромные затраты времени на ежедневную рутину. Собственно, спикер называет "тёмной материей" невидимую нагрузку на сотрудкниов: чтение корпоративных чатов, стендапы, написание документации и помощь коллегам. Измерение этих скрытых активностей помогает выявить истинные причины снижения скорости работы технических команд.
Мне особенно нравится разбор метрик продуктивности Meta, про которые я говорил и в других постах, например, при разборе выступления "Measuring the Impact of AI on Developer Productivity at Meta" с этой же конференции. Но в этом выступлении этот рассказ сфокусирован именно на метриках. Отдельно отмечается, что в Meta применяют агрегированные показатели для анализа процессов, строго запрещая их использование для индивидуальной оценки инженеров во избежание накруток. Сами метрики такие
- By Tool -» TSD (Time Spent Coding per Diff): отражает время кодинга на один пулл-реквест, что позволяет инфраструктурным командам оценивать эффективность инструментов разработчика.
- By Intent -» PCT (Percent Time Coding): показывает долю чистого программирования по отношению ко всем остальным задачам, помогая сокращать количество лишних встреч. Метрика важна для продуктовых команд
- By Workflow -» WTS (Workflow Time Spent): отслеживает затраты времени в разрезе конкретного процесса (например, устранения инцидента) для поиска узких мест при переключении между системами.
- By Value -» но здесь не показали метрики, а привели метафору про карту и про движение в нужном направлении (как бы это нужное направление не измерялось)
Если говорить про подучу, то мне понравились слайды про фрагментацию дня. На слайдах видно, как день инженера распадается на десятки коротких переключений между IDE, чатом, календарём, review tools, notebook и SQL. Интересно, что Meta предлагает смотреть не только на raw coding time, но и на coding intent time - то есть считать инженерной работой не только минуты в редакторе, но и связанные с задачей походы в чат, wiki, SQL и документацию. Иначе очень легко оптимизировать не то место.
Мне показались полезными идеи для инженеров о том, что надо защищать длинные focus-блоки, группировать коммуникации, глушить некритичные уведомления и перестать думать, что "настоящая работа" происходит только внутри IDE. А руководителям полезно посчитать стоимость переключения контекста и сравнить со стоимостью медленного билда; отдельно посмотреть на фокусное время команды, структуру календаря, объём асинхронного шума и только потом уже докручивать инструментарий. Иначе можно ускорить pipeline и всё равно потерять пропускную способность команды.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
YouTube
Optimizing for Time: Dark Matter
Presented by Karim Nakad (Meta) at DPE Summit 2025, an event developed and hosted by Gradle.
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=optimizing-for-time-dark…
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=optimizing-for-time-dark…
👍9🔥6❤4
Domain expertise still wanted: the latest trends in AI-assisted knowledge for developers (Рубрика #Edu)
Интересный отчет про небольшой пульс опрос аудитории StackOverflow (900 человек), который они задизайнили вместе с OpenAI и который показал, что AI становится основной точкой входа в обучение инженеров, ... но не заменяет экспертизу. Авторы сравнили результаты с нормализованными результатами ежегодных отчетов StackOverflow Developer Survey 2024 и 2025 годов (см про них мои посты: 2024 и 2025). Нормализовать их пришлось, так как ежегодные отчеты StackOverflow проходят примерно по 50к инженеров.
Основные результаты и цифры примерно такие
1) AI уже встроился в контур обучения инженеров: 64% разработчиков используют AI, чтобы учиться - против 44% в 2025 и 37% в 2024
2) Два главных драйвера: "starting from scratch" (28,2%) и efficiency (26,3%)
3) Параллельно 58% уже используют AI-инструменты на работе каждый день; среди early-career - 68%, среди experienced - 56%
4) 69% в принципе тратили последние полгода на изучение чего-то нового
Авторы отметили, что меняется не только проникновение AI, но и подход к обучению - сжимается количество источников, что инженеры используют для обучения: доля тех, кто использует 8+ источников для обучения, упала примерно с 49% в 2024 до 9% в 2025 и 7% в этом пульс опросе. Кажется, что AI становится новой стартовой страницей, особенно для джунов и мидлов (36% и 39% соответственно идут в AI первым шагом) , а опытные разработчики еще держатся - они стартуют с техдокументации в 30% случаев и только в 29% начинают с AI:)Кажется, что я запоздал с публикацией сайта system-design.space :) Отрадно видеть, что AI почти никогда не работает в одиночку. Только 1% используют его как единственный источник. У большинства AI идёт вместе с документацией (58%), поиском/форумами/сообществами (54%) и Stack Overflow (50%).
Самый большой стоп-фактор - доверие. 38% называют нехватку доверия результатам AI главным барьером для обучения через AI. В ежегодном отчете 2025 доверяющих точности AI было 33%, а недоверяющих - 46%. При этом у ежедневных пользователей доверие заметно выше, чем у еженедельных: 49% против 30%. Иначе говоря, AI ускоряет вход в тему, но добавляет налог на верификацию результатов.
Интересны, что те, что AI побеждает за счет снижения барьера для обучения новому и удешевления момента "а с чего начать". Это видно из того, что 35% тех, кто не использует AI, говорят, что им не хватает времени на обучение. В то же время такую причину как препятствие для обучения указывают только 7% тех, что использует AI:)
В итоге, нас ждет будущее, где AI инструмент будет стартовой страницей, а база знаний (типа Stack Overflow) будет обеспечивать слой доверия, поверх которого AI будет строить свои ответы. Ценность экспертизы при этом будет только расти, а главным навыком будет не просто хороший промптинг, но и умение быстро и качественно верифицировать ответы AI
#Survey #Engineering #Software #AI #Culture #RnD #Thinking #Brain
Интересный отчет про небольшой пульс опрос аудитории StackOverflow (900 человек), который они задизайнили вместе с OpenAI и который показал, что AI становится основной точкой входа в обучение инженеров, ... но не заменяет экспертизу. Авторы сравнили результаты с нормализованными результатами ежегодных отчетов StackOverflow Developer Survey 2024 и 2025 годов (см про них мои посты: 2024 и 2025). Нормализовать их пришлось, так как ежегодные отчеты StackOverflow проходят примерно по 50к инженеров.
Основные результаты и цифры примерно такие
1) AI уже встроился в контур обучения инженеров: 64% разработчиков используют AI, чтобы учиться - против 44% в 2025 и 37% в 2024
2) Два главных драйвера: "starting from scratch" (28,2%) и efficiency (26,3%)
3) Параллельно 58% уже используют AI-инструменты на работе каждый день; среди early-career - 68%, среди experienced - 56%
4) 69% в принципе тратили последние полгода на изучение чего-то нового
Авторы отметили, что меняется не только проникновение AI, но и подход к обучению - сжимается количество источников, что инженеры используют для обучения: доля тех, кто использует 8+ источников для обучения, упала примерно с 49% в 2024 до 9% в 2025 и 7% в этом пульс опросе. Кажется, что AI становится новой стартовой страницей, особенно для джунов и мидлов (36% и 39% соответственно идут в AI первым шагом) , а опытные разработчики еще держатся - они стартуют с техдокументации в 30% случаев и только в 29% начинают с AI:)
Самый большой стоп-фактор - доверие. 38% называют нехватку доверия результатам AI главным барьером для обучения через AI. В ежегодном отчете 2025 доверяющих точности AI было 33%, а недоверяющих - 46%. При этом у ежедневных пользователей доверие заметно выше, чем у еженедельных: 49% против 30%. Иначе говоря, AI ускоряет вход в тему, но добавляет налог на верификацию результатов.
Интересны, что те, что AI побеждает за счет снижения барьера для обучения новому и удешевления момента "а с чего начать". Это видно из того, что 35% тех, кто не использует AI, говорят, что им не хватает времени на обучение. В то же время такую причину как препятствие для обучения указывают только 7% тех, что использует AI:)
В итоге, нас ждет будущее, где AI инструмент будет стартовой страницей, а база знаний (типа Stack Overflow) будет обеспечивать слой доверия, поверх которого AI будет строить свои ответы. Ценность экспертизы при этом будет только расти, а главным навыком будет не просто хороший промптинг, но и умение быстро и качественно верифицировать ответы AI
#Survey #Engineering #Software #AI #Culture #RnD #Thinking #Brain
❤7👍5🔥2
От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear) (Рубрика #Management)
Написал статью про то, что эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды внезапно переедут в какой-то новый инструмент, а потому, что тикет перестает быть центром мира. В классической модели он был основной единицей координации: в нем жили требования, приоритет, исполнитель, статус, комментарии, передача ответственности между ролями. В AI-native мире этой единицей постепенно становится не тикет, а context: намерение, ограничения, права доступа, история решений, автоматизации и агенты, которые способны доводить работу до результата.
В некотором смысле эта статья логично продолжает две предыдущие
- Про переход от классического PDLC к AI-native разработке
- Про переход от AI-native разработки к AI-native организации
А в этой статье я размышляю о том, а как будет выглядеть управление работой в таких компаниях
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
Написал статью про то, что эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды внезапно переедут в какой-то новый инструмент, а потому, что тикет перестает быть центром мира. В классической модели он был основной единицей координации: в нем жили требования, приоритет, исполнитель, статус, комментарии, передача ответственности между ролями. В AI-native мире этой единицей постепенно становится не тикет, а context: намерение, ограничения, права доступа, история решений, автоматизации и агенты, которые способны доводить работу до результата.
В некотором смысле эта статья логично продолжает две предыдущие
- Про переход от классического PDLC к AI-native разработке
- Про переход от AI-native разработки к AI-native организации
А в этой статье я размышляю о том, а как будет выглядеть управление работой в таких компаниях
#Engineering #Software #DevOps #DevEx #Process #Management #Metrics
Medium
От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)
Кажется, эпоха фразы “заведи тикет в Jira” подходит к концу … и не потому, что тикеты исчезнут, и не потому, что завтра все команды…
🔥9👎4❤3🤨2👍1
From IDEs to AI Agents with Steve Yegge (Рубрика #Agents)
Посмотрел выпуск подкаста Gergely Orosz "The Pragmatic Engineer" с крутым гостем, Steve Yegge, известным инженером ex-Google, ex-Amazon, ex-Grab, у которого 40+ лет в разработке. Он любит и умеет писать провокационные тексты про индустрии, недавно стал со-автором книги "Vibe Coding", а также создателем open-source оркестратора агентов Gas Town. Ребята весь выпуск обсуждали как меняется единица инженерной работы в наше время. Основные мысли, что мне запомнились, такие
1️⃣ Главный навык смещается от написания кода к управлению агентами
Yegge описывает 8 уровней использования AI - от полного отказа до собственной оркестрации десятков агентов. Его тезис резкий, но полезный: застрять на уровне "иногда спросил IDE и очень тщательно посмотрел diff" - значит недоиспользовать новую модель работы. Для нас это означает: учить команды декомпозировать работу, создавать защитные барьеры (guardrails), способы оценки работы (evals), пайплайны ревью и мульти-агентные процессы и так далее. Примерно про это я писал в статье "От классического PDLC к AI-native разработке"
2️⃣ IDE становится не редактором, а диспетчерской
Одна из центральных мыслей выпуска: новая IDE может превратиться в интерфейс разговора с агентами и мониторинга их работы, а не в место, где инженер вручную набивает код. Для нас это сдвиг фокуса с кодинга на постановку задач, работу с разрешениями, sandboxing, observability и встраивание агентов в SDLC)
3️⃣ AI жестко подсвечивает архитектурный долг
В выпуске отдельно звучит, что монолитные кодовые базы - серьезный блокер для enterprise AI-adoption: агентам нужен обозримый и хорошо извлекаемый контекст. Для технических руководителей это практический сигнал: модульность, понятные границы, ответственность и владение кодом, документация и удобные для AI репозитории становятся не "архитектурной эстетикой", а прямым фактором скорости
4️⃣ AI меняет не только разработку, но и операционную модель команды
Yegge несколько раз подчеркивает, что AI - это прежде всего аугментация, а не просто замена: маленькие AI-усиленные команды могут двигаться быстрее больших организаций, у которых бутылочные горлышки уже не в кодинге, а в согласованиях, приоритизации и способности компании переварить output. Даже если не принимать буквально его тезис про "мертвые большие компании", вывод практичный: код писать можно быстрее, а вот принимать решения и доводить до production - не факт. Примерно про это я писал в статье "От AI-native разработки к AI-native организации"
5️⃣ Рост продуктивности легко превращается в рост выгорания
Стив рассказывает про эффект Дракулы или AI вампира - это мысль о том, что AI автоматизирует более легкую часть работы и оставляет человеку самые энергозатратные решения. В интервью Yegge говорит, что на максимальной AI-скорости у человека может быть всего около 3 продуктивных часов в день; ту же идею он отдельно развивает в своем эссе про AI Vampire. Для техлидов это, возможно, самый важный кусок: нельзя превращать 10x-инструмент в 10x-ожидание от людей.
Еще была пара интересных мыслей
- SaaS без API и platform-мышления рискует проиграть AI-native игрокам: если продукт плохо встраивается программно, его будут обходить или заменять
- Прототипирование становится почти production-моделью: по словам Yegge, команды делают много быстрых вариантов и выбирают лучший, а не месяцами полируют одну реализацию. Про популярность таких подходов я рассказывал, когда говорил про Lovable, продукт из этой категории
В общем, послушать Стива было интересно - он умеет размышлять о текущем и будущем широкими мазками, над которыми интересно поразмышлять и сравнить со своими мыслями.
#AI #Management #Future #Software #Engineering #Productivity
Посмотрел выпуск подкаста Gergely Orosz "The Pragmatic Engineer" с крутым гостем, Steve Yegge, известным инженером ex-Google, ex-Amazon, ex-Grab, у которого 40+ лет в разработке. Он любит и умеет писать провокационные тексты про индустрии, недавно стал со-автором книги "Vibe Coding", а также создателем open-source оркестратора агентов Gas Town. Ребята весь выпуск обсуждали как меняется единица инженерной работы в наше время. Основные мысли, что мне запомнились, такие
1️⃣ Главный навык смещается от написания кода к управлению агентами
Yegge описывает 8 уровней использования AI - от полного отказа до собственной оркестрации десятков агентов. Его тезис резкий, но полезный: застрять на уровне "иногда спросил IDE и очень тщательно посмотрел diff" - значит недоиспользовать новую модель работы. Для нас это означает: учить команды декомпозировать работу, создавать защитные барьеры (guardrails), способы оценки работы (evals), пайплайны ревью и мульти-агентные процессы и так далее. Примерно про это я писал в статье "От классического PDLC к AI-native разработке"
2️⃣ IDE становится не редактором, а диспетчерской
Одна из центральных мыслей выпуска: новая IDE может превратиться в интерфейс разговора с агентами и мониторинга их работы, а не в место, где инженер вручную набивает код. Для нас это сдвиг фокуса с кодинга на постановку задач, работу с разрешениями, sandboxing, observability и встраивание агентов в SDLC)
3️⃣ AI жестко подсвечивает архитектурный долг
В выпуске отдельно звучит, что монолитные кодовые базы - серьезный блокер для enterprise AI-adoption: агентам нужен обозримый и хорошо извлекаемый контекст. Для технических руководителей это практический сигнал: модульность, понятные границы, ответственность и владение кодом, документация и удобные для AI репозитории становятся не "архитектурной эстетикой", а прямым фактором скорости
4️⃣ AI меняет не только разработку, но и операционную модель команды
Yegge несколько раз подчеркивает, что AI - это прежде всего аугментация, а не просто замена: маленькие AI-усиленные команды могут двигаться быстрее больших организаций, у которых бутылочные горлышки уже не в кодинге, а в согласованиях, приоритизации и способности компании переварить output. Даже если не принимать буквально его тезис про "мертвые большие компании", вывод практичный: код писать можно быстрее, а вот принимать решения и доводить до production - не факт. Примерно про это я писал в статье "От AI-native разработки к AI-native организации"
5️⃣ Рост продуктивности легко превращается в рост выгорания
Стив рассказывает про эффект Дракулы или AI вампира - это мысль о том, что AI автоматизирует более легкую часть работы и оставляет человеку самые энергозатратные решения. В интервью Yegge говорит, что на максимальной AI-скорости у человека может быть всего около 3 продуктивных часов в день; ту же идею он отдельно развивает в своем эссе про AI Vampire. Для техлидов это, возможно, самый важный кусок: нельзя превращать 10x-инструмент в 10x-ожидание от людей.
Еще была пара интересных мыслей
- SaaS без API и platform-мышления рискует проиграть AI-native игрокам: если продукт плохо встраивается программно, его будут обходить или заменять
- Прототипирование становится почти production-моделью: по словам Yegge, команды делают много быстрых вариантов и выбирают лучший, а не месяцами полируют одну реализацию. Про популярность таких подходов я рассказывал, когда говорил про Lovable, продукт из этой категории
В общем, послушать Стива было интересно - он умеет размышлять о текущем и будущем широкими мазками, над которыми интересно поразмышлять и сравнить со своими мыслями.
#AI #Management #Future #Software #Engineering #Productivity
YouTube
From IDEs to AI Agents with Steve Yegge
Steve Yegge has spent decades writing software and thinking about how the craft evolves. From his early years at Amazon and Google, to his influential blog posts, he has often been early at spotting shifts in how software gets built.
In this episode of…
In this episode of…
❤9🔥9👍2
The State of DevOps Modernization 2026 (Рубрика #Devops)
Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить.
Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов.
Авторы выделил следующие ключевые результаты
1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах.
2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции)
3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden paths
В итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:)
Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Изучил недавно вышедший отчет "The State of DevOps Modernization 2026" от Harness. Отчет основан на опросе ~700 инженеров и руководителе, что был проведен в феврале 2026 года компанией Coleman Parkes. Основной вывод отчета в том, что AI резко ускорил локальный цикл кодирования, а остальная часть delivery контура во многих командах внутри корпораций не успевает его переварить.
Основная аналитическая модель отчета очень простая: почти все выводы построены через cross-tab по вопросу "как часто вы используете AI инструменты для кодирования" - от нескольких раз в день до более редкого использования. То есть это не анализ телеметрии и не каузальный инференс как в DORA, а срез восприятия и самооценок респондентов.
Авторы выделил следующие ключевые результаты
1️⃣ Скорость действительно выросла. 45% very frequent AI пользователей говорят о ежедневных или чаще развертывания против 32% у frequent и 15% у occasional users. Но рядом с этим идет налог на стабильность: 69% very frequent users говорят, что AI-generated code приводит к проблемам с развертыванием как минимум в половине случаев; 22% deployments в этой когорте заканчиваются rollback, hotfix или customer-impacting incident; MTTR по таким инцидентам у них выше - 7.6 часа против 6.0 и 6.3 часа в соседних когортах.
2️⃣ Но это напряжение распространяется далеко за пределы инцидентов. Среди very frequent AI users 50% говорят о росте vulnerabilities/security инцидентов и 50% - о росте non-compliance issues; 49% видят больше проблемы с производительностью; 51% - больше code quality/efficiency problems. При этом сами авторы специально оговаривают: явной причинно-следственной связи между AI coding и этими проблемами отчет не доказывает (такой дизайн эксперимента может показать только корреляции)
3️⃣ Coding автоматизируется быстрее, чем остальной SDLC. 84% респондентов используют AI ежедневно для coding, но для QA testing этот показатель 68%, для performance/cost optimization 63%, для refactoring 62%. 47% very frequent users говорят, что ручная работа дальше по пайплайну после кода стала проблемнее (это QA, code review, remediation); 69% теряют время из-за медленных и ненадженых CI/CD; 70% считают, что их pipelines страдают от flaky тестов and неуспешных развертываний; 75% связывают давление на шиппинг с выгоранием; 73% говорят, что у них почти нет стандартных темплейтов и golden paths
В итоге, видно, что проблема в том, что AI усиливает throughput там, где платформа, CI/CD, гейты контроля и координация остались на старой скорости. Авторы сами это почти проговаривают: у них есть гипотеза, что heavy AI users просто пытаются доставлять больше кода и поэтому острее чувствуют flaky tests и deployment failures; их pipelines не обязательно хуже, просто потребности уже выше. Это сильный инсайт, но как доказательств причинности отчет не дает:)
Примерно эти же мысли я писал в статье "От классического PDLC к AI-native разработке", но в основном опирался на другие исследования типа DORA или нашего AI4SDLC, который мы проводили от "Т-Технологий" в конце прошлого года и проведем еще раз в этом году
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Harness.io
The State of DevOps Modernization Report 2026 | Harness
700 engineers and leaders reveal AI's impact on DevOps: faster deployments but rising incidents, burnout & compliance issues. Download the full report.
❤7🔥4👍3
Как AI меняет инженерную культуру и что это значит для тимлидов и инженеров (Рубрика #Engineering)
Именно с таким докладом я выступаю сегодня в 15:40 на конференции "Dream Teamlead" от Яндекса. Я расскажу про то, как сейчас меняются инженерные процессы и что это значит для индустрии и для условного тимлида, которому надо уметь теперь не только работать в формате Software Engineering 1.0, но и в новом формате. Круто, что у ребят будет доступна трансляция на сайте конфы
Вообще мое выступление будет состоять из четырех частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как меняется роль тимлида
В последней части я расскажу а как меняется роль тимлида при этих изменениях, ведь ему приходится теперь не просто распределять задачи - он теперь проектирует контур разработки или human-agent систему. Про это у меня пока нет статьи, но я ее обязательно напишу как follow up к этому докладу.
P.S.
В докладе у меня не хватит времени поговрить про изменения в управлении задачами, но на своем сайте tellmeabout.tech я уже опубликовал статью "От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)", которая рассматривает этот интересный вопрос.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться, а если вы будете онлайн, то сможете посмотреть доклад в трансляции.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Именно с таким докладом я выступаю сегодня в 15:40 на конференции "Dream Teamlead" от Яндекса. Я расскажу про то, как сейчас меняются инженерные процессы и что это значит для индустрии и для условного тимлида, которому надо уметь теперь не только работать в формате Software Engineering 1.0, но и в новом формате. Круто, что у ребят будет доступна трансляция на сайте конфы
Вообще мое выступление будет состоять из четырех частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как меняется роль тимлида
В последней части я расскажу а как меняется роль тимлида при этих изменениях, ведь ему приходится теперь не просто распределять задачи - он теперь проектирует контур разработки или human-agent систему. Про это у меня пока нет статьи, но я ее обязательно напишу как follow up к этому докладу.
P.S.
В докладе у меня не хватит времени поговрить про изменения в управлении задачами, но на своем сайте tellmeabout.tech я уже опубликовал статью "От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)", которая рассматривает этот интересный вопрос.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться, а если вы будете онлайн, то сможете посмотреть доклад в трансляции.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Dream → Teamlead
Dream → Teamlead — практическая конференция Яндекса для тимлидов, руководителей и технических лидеров. Здесь говорят не про код и фичи, а про управление людьми, принятие сложных решений и развитие здоровых команд.
❤17🔥17👍5👎3
From Writing Code to Managing Agents. Most Engineers Aren't Ready | Stanford University, Mihail Eric (Рубрика #Engineering)
Интересное интервью Mihail Eric, Head of AI at Monaco и лектора Стэнфорда, где он ведёт курс "CS146S: The Modern Software Developer". Mihail Eric интересно рассказывает про то, куда реально двигается разработка софта. Основная мысль про то, что профессия не исчезает, но центр тяжести уходит от ручного написания каждой строчки к оркестрации AI-агентов, декомпозиции задач, проверке результатов и проектированию среды, в которой агентам можно доверять. Собственно, сам курс "CS146S: The Modern Software Developer" как раз про это.
В этом интервью 15-минутном интервью были несколько интересных мыслей
1️⃣ Eric объясняет почему junior-рынок так штормит тремя факторами
- Перегретый найм после 2021 года и последующие сокращения
- Резкий рост числа CS-выпускников
- AI, из-за которого компании всё чаще думают не "кого ещё нанять", а "сколько AI-native инженеров нужно, чтобы закрыть тот же объём работы"
2️⃣ Eric объясняет, а кто такой AI-native engineer
- Это не просто про промпт инженер, а скорее разработчик с нормальной базой в system design, алгоритмах и традиционной разработке
- Этот инженер должен уметь работать с агентскими workflow
По мнению Eric основная ошибка - это попытка сразу запускать много агентов. Но лучше начинать наоборот: сначала один агент на один workflow, потом постепенно добавлять только изолированные задачи и лишь затем масштабировать оркестрацию
3️⃣ Eric рассказывает про дружелюбную для агентов кодовую базу
- Для агента тесты - это не "nice to have" фича, а фактически контракты
- Если тестов мало, README устарел, а одинаковые сущности создаются разными паттернами в разных местах, то агент начинает гадать - и очень быстро начинает плодить ошибки.
В итоге, тексты, документация и единые паттерны базы - это не просто инженерная гигиена, а просто база для AI-native разработки
4️⃣ Eric отмечает, что мульти-агентные workflows больше похожи на менеджмент, чем на классическое программирование
Нужно уметь быстро переключать контекст, держать в голове, чем занят каждый агент, понимать, где он застрял, и мягко возвращать его в правильную траекторию. По сути, сильный AI-native engineer - это уже немного менеджер команды из агентов:)
5️⃣ Eric отмечает важность вкуса продуктового и инженерного
Функциональный продукт и действительно сильный продукт разделяет не только корректность кода, но и желание пройти "последнюю милю": сделать фичу устойчивее, полезнее, глубже, довести UX и robustness. Eric связывает это с постоянным экспериментированием: даже команды, которые строят AI-инструменты, сами всё время переписывают и переизобретают свои workflow.
В общем, автор за 15 минут продал мне свой курс про современную разработку софта, лекции которого уже доступны на Youtube (правда, это не официальная версия, которую я не нашел, а сгенерированная через notebook lm на основе материалов курса)
#Agents #Software #Engineering #Management #DistributedSystems #SystemDesign #AI
Интересное интервью Mihail Eric, Head of AI at Monaco и лектора Стэнфорда, где он ведёт курс "CS146S: The Modern Software Developer". Mihail Eric интересно рассказывает про то, куда реально двигается разработка софта. Основная мысль про то, что профессия не исчезает, но центр тяжести уходит от ручного написания каждой строчки к оркестрации AI-агентов, декомпозиции задач, проверке результатов и проектированию среды, в которой агентам можно доверять. Собственно, сам курс "CS146S: The Modern Software Developer" как раз про это.
В этом интервью 15-минутном интервью были несколько интересных мыслей
1️⃣ Eric объясняет почему junior-рынок так штормит тремя факторами
- Перегретый найм после 2021 года и последующие сокращения
- Резкий рост числа CS-выпускников
- AI, из-за которого компании всё чаще думают не "кого ещё нанять", а "сколько AI-native инженеров нужно, чтобы закрыть тот же объём работы"
2️⃣ Eric объясняет, а кто такой AI-native engineer
- Это не просто про промпт инженер, а скорее разработчик с нормальной базой в system design, алгоритмах и традиционной разработке
- Этот инженер должен уметь работать с агентскими workflow
По мнению Eric основная ошибка - это попытка сразу запускать много агентов. Но лучше начинать наоборот: сначала один агент на один workflow, потом постепенно добавлять только изолированные задачи и лишь затем масштабировать оркестрацию
3️⃣ Eric рассказывает про дружелюбную для агентов кодовую базу
- Для агента тесты - это не "nice to have" фича, а фактически контракты
- Если тестов мало, README устарел, а одинаковые сущности создаются разными паттернами в разных местах, то агент начинает гадать - и очень быстро начинает плодить ошибки.
В итоге, тексты, документация и единые паттерны базы - это не просто инженерная гигиена, а просто база для AI-native разработки
4️⃣ Eric отмечает, что мульти-агентные workflows больше похожи на менеджмент, чем на классическое программирование
Нужно уметь быстро переключать контекст, держать в голове, чем занят каждый агент, понимать, где он застрял, и мягко возвращать его в правильную траекторию. По сути, сильный AI-native engineer - это уже немного менеджер команды из агентов:)
5️⃣ Eric отмечает важность вкуса продуктового и инженерного
Функциональный продукт и действительно сильный продукт разделяет не только корректность кода, но и желание пройти "последнюю милю": сделать фичу устойчивее, полезнее, глубже, довести UX и robustness. Eric связывает это с постоянным экспериментированием: даже команды, которые строят AI-инструменты, сами всё время переписывают и переизобретают свои workflow.
В общем, автор за 15 минут продал мне свой курс про современную разработку софта, лекции которого уже доступны на Youtube (правда, это не официальная версия, которую я не нашел, а сгенерированная через notebook lm на основе материалов курса)
#Agents #Software #Engineering #Management #DistributedSystems #SystemDesign #AI
YouTube
From Writing Code to Managing Agents. Most Engineers Aren't Ready | Stanford University, Mihail Eric
Stanford Adjunct Lecturer Mihail Eric talks about what's happening to junior software developers right now — and what it takes to become an AI-native software engineer who survives the age of agents.
If you want to learn more about Stanford's first AI software…
If you want to learn more about Stanford's first AI software…
🔥12❤6⚡1👎1👌1