No Vibes Allowed: Solving Hard Problems in Complex Codebases (Рубрика #AI)

Интересное выступление от Dex Horthy, основателя компании HumanLayer, разрабатывающей инструменты для AI-assisted разработки. Его предыдущий доклад "12 Factor Agents: Patterns of reliable LLM applications" (см. мой разбор) в июне 2025 стал одним из самых популярных на конференции. Именно ему приписывают популяризацию термина "context engineering".

Исследование Stanford показало неприятную правду об AI-инструментах для кодинга (это было в выступлении "Does AI Actually Boost Developer Productivity?" от Yegor Denisov-Blanch, про которое я уже рассказывал)
- Большая часть "дополнительного кода", написанного с помощью AI - это переработка slop'а, который был написан до этого
- Агенты отлично работают на новых проектах, но в больших legacy-кодовых базах часто делают разработчиков менее продуктивными

Для решения этих проблем автор рассказывает про context engineering
- LLM - это stateless системы. Единственный способ получить лучший результат - подать лучший контекст на вход. При каждом вызове модель выбирает следующий шаг исключительно на основе того, что находится в текущем контексте.​
- "Dumb Zone". У контекстного окна есть практический предел. После ~40% заполнения начинается деградация качества ответов. Если у вас подключено много MCP-инструментов, которые забивают контекст JSON'ами и UUID'ами - вы постоянно работаете в dumb zone.​
- Методология: Research → Plan → Implement. Вместо наивного подхода "попросил → получил slop → поругался → попросил снова" команда Dex'а использует частую намеренную компактизацию контекста:
-- Research - понимание системы, поиск нужных файлов. Результат сжимается в markdown с конкретными файлами и номерами строк.​
-- Plan - детальный план с code snippets того, что именно будет изменено. Чем конкретнее план, тем надёжнее выполнение.​
-- Implement - выполнение плана. Если план хороший, даже "тупая" модель справится.​
- Напоследок автор рассказывает про практические результаты вида: за 7 часов субботней сессии отправили 35,000 строк кода в проект BAML (300k LOC Rust) - обычно это была работа на 1-2 недели​

Практические советы от автора
- Sub-agents - не для ролей, а для контроля контекста. Не создавайте "frontend agent" и "backend agent". Используйте sub-agents для изоляции тяжёлых операций чтения кодовой базы, возвращая только сжатый результат.​
- Прогрессивное раскрытие контекста. Вместо одного огромного файла документации в корне репозитория - размещайте контекстные файлы на каждом уровне, подгружая только релевантное.​
- On-demand сжатый контекст лучше статичной документации. Документация устаревает и врёт. Код - источник истины. Генерируйте research-документы на лету из реального кода.​
- Trajectory matters. Если вы 5 раз поругали модель в одном контексте - она "научилась", что следующий шаг = ошибка + ругань. Лучше начать новый контекст.​
- Культурные изменения должны идти сверху. Если вы технический лидер - выберите один инструмент и набивайте практику. Не прыгайте между Claude Code, Cursor и Codex

Главный вывод из выступления примерно такой

AI cannot replace thinking. It can only amplify the thinking you have done - or the lack of thinking you have done.

#Engineering #AI #Metrics #Software #DevEx #Productivity

[1/2] Defying Gravity (Рубрика #AI)

Это интересное выступление про новую IDE "Antigravity" от Кевина Хоу, руководителя продуктовой инженерии Google Antigravity в Google DeepMind. До лета 2025 года Кевин возглавлял продуктовую инженерию в Windsurf (бывший Codeium), а потом Google приобрёл команду Windsurf за $2,4 млрд именно для создания Antigravity.​​ В этом выступлении Хоу описывает эволюцию AI-инструментов для разработчиков как последовательность скачков, каждый из которых был связан с улучшением моделей:​
1️⃣ Автокомплит (GitHub Copilot)
2️⃣ Чат (ChatGPT с RLHF)
3️⃣ Агенты (Antigravity)

Antigravity запущен 18 ноября 2025 года вместе с Gemini 3 Pro и позиционируется не просто как редактор с AI-функциями, а "агент-ориентированная платформа", где автономные агенты становятся полноценными партнёрами по разработке.​​ В этой IDE есть три составляющие
1️⃣ Agent Manager - центральный хаб управления агентами. Это inbox для задач, требующих внимания (например, подтверждение команд терминала), с OS-уведомлениями и возможностью управлять несколькими агентами параллельно.
2️⃣ AI Editor - форк VS Code с быстрым автокомплитом и агентской боковой панелью. Переключение между Editor и Agent Manager занимает <100 мс (Cmd/Ctrl+E).
3️⃣ Agent-Controlled Browser - автоматизированный Chrome, который агент использует для:
- Получения контекста (доступ к Google Docs, GitHub dashboards с вашей аутентификацией)
- Верификации результатов (клики, скроллинг, выполнение JavaScript для тестирования приложений)
- Записи видео действий вместо показа diff'ов кода

IDE предлагает новый паттерн для взаимодействия посредством концепции Artifacts - это динамические визуальные представления работы агента:
- Типы артефактов: планы реализации (как PRD, product requirement definitions), task-листы, архитектурные диаграммы Mermaid, скриншоты, видеозаписи браузера, walkthrough'ы (финальные отчёты как PR description)
- Динамичность: модель сама решает, нужен ли артефакт, какого типа, кто должен его видеть (другие агенты, conversations, база знаний)
- Feedback-система: можно оставлять комментарии в стиле Google Docs / Figma - выделять текст или области на изображениях, батчить правки и отправлять агенту, не прерывая выполнение задачи​

Раньше для отслеживания за роботой агентов надо было читать простыню chain-of-thoughts, что было тяжеловато. А вот артефакты дают визуальное представление прогресса - это похоже на PowerPoint для презентаций.

Продукт построен на возможнотях Gemini 3 Pro и предлагает четыре категории улучшений
1️⃣ Интеллект и reasoning: лучше следует инструкциям, понимает нюансы использования инструментов, справляется с долгими задачами
2️⃣ Multimodal: обработка текста, изображений, аудио, видео, кода одновременно. Image Generation (Nano Banana Pro) интегрирована для итераций по дизайну прямо в редакторе​​
3️⃣ Computer Use: вариант Gemini для управления браузером - клики, DOM-инспекция, JavaScript. Результат - не diff, а видеозапись действий для верификации​
4️⃣ Долгоживущие задачи: агенты работают в фоне, уведомляя о необходимости вмешательства

По мнению Хоу ключевым преимуществом новой IDE является симбиоз с DeepMind
- Команда Antigravity сидит "в паре десятков метров" от команды Computer Use
- Ранний доступ к Gemini 3 за несколько месяцев до релиза позволил найти слабые места модели и исправить их в продукте
- Antigravity используется внутри Google инженерами и исследователями DeepMind - это пример dog fooding
- Такой симбиоз создаёт цикл обратной связи: продукт показывает пробелы модели → исследователи улучшают модель → продукт интегрирует улучшения
Например, Computer Use изначально работал плохо, пока команды не синхронизировали data distribution и agent harness, а концепция artifacts потребовала доработки модели, чтобы понимать концепцию ревью.​

В продолжении мы обудим какие выводы можно сделать из появления такой IDE.

#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE

[2/2] Defying Gravity (Рубрика #AI)

Рассказ об интересной IDE хотелось бы закончить анализом того, а что этот выпуск значит для инженеров

1️⃣ Повышение планки амбиций
Antigravity - это ставка на «raising the ceiling»: агенты должны брать на себя не только написание кода (это уже умеют LLM), но и части «что строить» и «как строить». Инженерам нужно учиться делегировать сложные задачи агентам, работая на уровне задач, а не строк кода.​

2️⃣ Работа на разных поверхностях
Разработка уже не ограничена редактором. Browser automation открывает возможности:
- Тестирование UI/UX агентом в реальном браузере
- Автоматическая верификация по дизайну
- Доступ к institutional knowledge (bug trackers, внутренние документы с аутентификацией)

3️⃣ Визуальная коммуникация вместо текстовой
Артефакты меняют парадигму review: вместо чтения длинных chain-of-thought смотрите планы, диаграммы, видеозаписи. Для инженеров это означает необходимость учиться давать обратную связь в мультимодальном формате (комментарии на изображениях, выделение текста в планах).​

4️⃣ Параллельная оркестрация
Antigravity поддерживает параллельную работу нескольких агентов на одном проекте (например, дизайн мокапа + исследование API + реализация фичи одновременно). Инженерам нужно научиться декомпозировать задачи для параллельного выполнения агентами.​

5️⃣Аварийный люк (escape hatch) всегда доступен
Хоу честен: агентам пока нельзя доверять на 100%. Поэтому всегда можно вернуться в редактор (Cmd+E) для ручной доработки последних 20% задачи. Но тренд - будущее за agent manager'ом.​

6️⃣ Модель = продукт
Главный урок от DeepMind: "продукт настолько хорош, насколько хороша модель". Antigravity опередит конкурентов, потому что имеет ранний доступ к Gemini и прямую связь с исследователями. Для инженеров это сигнал: выбирайте инструменты, у которых есть плотная интеграция с моделью (не просто API-обёртки).​

7️⃣ Бесплатный доступ к frontier-моделям
Antigravity в public preview бесплатен с unlimited AI completions и доступом к Gemini 3 Pro, Claude Sonnet 4.5, GPT-OSS. Это шанс экспериментировать с агентскими workflow без финансовых барьеров.​

В общем, Antigravity - это ставка Google на то, что будущее разработки за агентами, которые работают не внутри редактора, а над ним, оркестрируя задачи через редактор, терминал и браузер. Для инженеров это означает переход от написания кода к управлению агентами через визуальные артефакты и мультимодальный feedback.

#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE

2026: The Year The IDE Died (Рубрика #AI)

Посмотрел интересный доклад от Gene Kim и про будущее разработки. Это заслуженные авторы, которые совмещают опыт и влияние на индустрию
- Steve Yegge работал в Google, Amazon, а сейчачс работает в Sourcegraph. Стив знаменит своими едкими, объемными и часто провокационными постами на темы языков программирования, продуктивности, культуры разработки и работы в крупных технологических компаниях
- Gene Kim - соавтор книг "DevOps Handbook", "The Phoenix Project", "Accelerate", "The Unicorn Project"
Совсем недавно два эти джентельмена выпустили книгу "Vibe Coding", а теперь решили рассказать про то, что современные IDE уже устарели:) Ниже представлены основные тезисы в чуть более расширенном варианте

1️⃣ Индустрия отстает на 9-12 месяцев от реальности
Большинство разработчиков используют AI как "улучшенный автокомплит" (GitHub Copilot в режиме tab-tab). Это мышление уровня печатной машинки в эпоху текстовых процессоров. Реальная мощь - в агентских системах, но ими пользуются единицы. Мы оптимизируем написание текста, а надо оптимизировать принятие решений.

2️⃣ IDE в привычном виде мертва
Традиционная IDE (IntelliJ, VS Code) - это инструмент, заточенный под чтение и написание текста человеком. Человеку нужны вкладки, подсветка синтаксиса и дерево файлов. AI-агенту нужен контекст (логи, тикеты, архитектура, связи), а не визуальный редактор. В 2026 году IDE станет "бэкендом" для агентов, а интерфейс разработчика превратится в диалог об архитектуре и намерениях (Intent), а не о синтаксисе. Кстати, раньше я разбирал выступление про IDE "Antigravity" от Google, где многие из этих идей уже материлизовались в продукт

3️⃣ Сдвиг от "Как сделать" к "Что сделать"
Йегге представил концепцию Amp (новый редактор от Sourcegraph). В нем вы не пишете код построчно. Вы описываете намерение (Intent), а стая агентов (планировщик, кодер, тестировщик) реализует его.
- Если сейчас цикл это: Думай -> Печатай -> Дебажь.
- То будет: Опиши цель -> Валидируй план агента -> Прими результат.

4️⃣ Контекст - это новая нефть
Главная проблема текущих чат-ботов - они галлюцинируют, потому что не видят всей картины. Будущее тулинга - это Model Context Protocol (MCP). Инструменты должны уметь сами «ходить» в Jira, Notion, Sentry и прод-базу, чтобы понимать задачу так же глубоко, как сеньор, работающий в компании 3 года.

В общем, это как обычно сейчас предсказание про то, что мы переходим от роли "писателей кода" к роли "архитекторов систем", где чернорабочими выступают LLM. Во всем выступлении сквозит тезис о том, что кто быстрее перестроит процессы под эту реальность - тот и выиграет рынок.

#Engineering #AI #Metrics #Software #DevEx #Productivity #IDE

Moving away from Agile. What's next? (Рубрика #Processes)

Посмотрел претенциозный доклад ребят из McKinsey с недавноей конфы AI Engineer, в котором они раскрывали несколько ключевых мыслей
- Текущие операционные модели (Agile based) плохо раскрывают потенциал AI‑инструментов
- "AI‑native" команды отличаются другими workflow, ролями и метриками
- Переход от Agile - это в первую очередь организационные и культурные изменения, а не использование инструментов

Тезисы, что поддерживают их мысли основаны на следующем
- У нас есть разрыв между индивидуальным бустом инженеров и эффектом на компанию: отдельные разработчики получают ускорение "дни → минуты", а в среднем по компании видят лишь 5–15% прироста продуктивности, потому что остальной процесс остался старым.
- AI создаёт новые бутылочные горлышки: распределение задач между людьми и агентами, ручной код‑ревью при лавине сгенерированного кода, ускоренное накопление техдолга и сложности.​
- Старый agile‑сетап (8–10 человек, двухнедельные спринты, story‑driven dev, раздельные роли frontend, backend, qa, ...) оптимизирован под "чисто человеческую" разработку и плохо сочетается с использованием агентов

Интересно, что название самого доклада выглядит как байтинг - авторы на самом деле не предлагают "выкинуть agile", скорее они предлагат уйти от конкретной реализации со спринтами по две недели, командами формата "two-pizza teams" и остальными ритуалами. На замену этому они предлагают "AI native подход": короткие циклы, более мелкие команды, spec‑driven development, ну и изменение роли product manager и инженеров​​.

Вообще забавно смотреть на выступления консультантов про разработку - не уверен, что они сами когда-то писали код, поэтому они базируют свой helicopter view анализ на куче различных исследований и кейс study. Ну и мыслят они не с уровня команды, а с уровня портфеля из сотен команд: много говорят про change management, измерения, роль обучения, перестройку орг‑структуры. Это консалтинговый взгляд, но он полезен, если говорить про крупные корпорации:)​​

Если говорить подробнее про изменения, то они предлагают
- Перейти от квартального планирования к continuous planning
- Перейти от story‑driven к spec‑driven разработке - PM/lead сначала "выбивают" нормальную спецификацию вместе с агентом, а уже потом команда/агенты пилят код, чтобы сократить рефакторы и перегенерации.​​
- Перейти к командам по 3-5 человек, где участники больше напоминают fullstack инженеров, а также оркестрируют агентов и отвечают за части архитектуры, а не только за свой слой
- Перейти к продактам, что сами начинают прототипировать с coding agent, а не только писать длинные PRD (product requirement definitions)

Авторы говорят и про метрики для измерения эффекта, предлагая многоуровневую систему
- Инвестиции в инструменты, обучение, коучинг
- Adoption, velocity, capacity, MTTR по критичным багам, безопасность и качество кода
- Бизнес‑результаты: time‑to‑revenue, cost-benefit analysis, возможность реинвестировать в greenfield/brownfield.​

В общем, консультанты предлагают поменять весь процесс, а не просто навесить агентов и copilot на старые agile‑процессы

#Engineering #AI #Metrics #Software #DevEx #Productivity #Management #Leadership

Can you prove AI ROI in Software Engineering? (Рубрика #AI)

Буквально недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) выступил на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным докладом:) По-факту, это тизер результатов двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (такой охват как минимум внушает доверие). Кстати, предыдущее выступление Егора "Does AI Actually Boost Developer Productivity?" я уже разбирал и часть тезисов полностью повторяются, а точнее вопросы вида
1. Почему существующие оценки продуктивности ненадёжны?
2. Как выглядела методология ребят из Stanford?
3. Главные численные выводы исследования

Но в этом докладе есть и новенькие результаты

1. Медианный прирост продуктивности составляет ~10%, но разброс между лидерами и отстающими постоянно увеличивается.
2. Качество использования AI важнее объёма. Корреляция между количеством потраченных токенов и ростом продуктивности слабая (R² = 0.20). Более того, наблюдается эффект "долины смерти" на уровне 10 млн токенов на инженера в месяц - команды, использующие такой объём, показывают результаты хуже, чем те, кто использует меньше.​
3. Чистота кодовой базы критична для AI. Индекс "чистоты окружения" (Environment Cleanliness Index), учитывающий тесты, типы, документацию, модульность и качество кода, показывает корреляцию R² = 0.40 с приростом продуктивности от AI. Чистый код усиливает эффект от AI, а технический долг его нивелирует.​
4. AI ускоряет энтропию кодовой базы. Бесконтрольное использование AI ускоряет накопление технического долга, что сдвигает кодовую базу в зону, где AI менее эффективен. Требуется активное управление качеством кода для сохранения преимуществ.​
5. Доступ к AI ≠ эффективное использование. В кейсе с двумя бизнес-юнитами одной компании при равном доступе к инструментам использование было сильно разное. Важно измерять не только факт использования, но и как инженеры применяют AI.

Ну и собственно автор предлагает свою методологию для измерения ROI из двух частей
1. Измерение использования
Access-based (кто получил доступ) vs usage-based (телеметрия API). Usage-based - золотой стандарт, позволяющий ретроспективный анализ через git-историю.​
2. Измерение инженерных результатов
- Primary metric: Engineering Output - ML-модель, реплицирующая оценку панели из 10-15 независимых экспертов по сложности, времени реализации и поддерживаемости​
- Guardrail metrics: Rework & Refactoring, Code Quality & Risk, People & DevOps - метрики, которые нужно держать на здоровом уровне, но не максимизировать​

Забавно, что автор категорически против использования PR counts, lines of code и даже DORA как основных метрик продуктивности.​

Ну и если анализировать подход автора, то он содержит сильные и слабые стороны
(+) Исследовательская методология выглядит солидно. ML-модель, реплицирующая экспертные оценки, проверенная на корреляцию с реальными панельными данными - это правильный подход к измерению сложных качественных аспектов кода.
(+) Понимание системных эффектов. Концепция управления энтропией кодовой базы, связь между чистотой кода и эффективностью AI, понимание, что инженеры должны знать, когда не использовать AI
(+) Критика DORA как primary metric обоснована. DORA - это индикаторы процесса, а не результата. Их максимизация может вредить (вспомним Goodhart's Law)
(+)AI Practices Benchmark с уровнями зрелости (от личного использования до агентной оркестрации) показывает понимание эволюции практик.​
(-) Background автора не в чистой разработке - у него отсутствует опыт и образование как инженера
(-) ML-модель как чёрный ящик. Хотя утверждается, что модель коррелирует с экспертными оценками, детали методологии, датасет для обучения, метрики качества модели не раскрыты в докладе
(-) Environment Cleanliness Index экспериментальный. Как именно взвешиваются компоненты индекса? Как он валидирован кроме корреляции с продуктивностью?​

#Engineering #AI #Metrics #Software #DevEx #Productivity

From Vibe Coding To Vibe Engineering (Рубрика #AI)

Посмотрел юморное выступление Kitze (Кристияна Ристовски), состоявшееся в конце 2025 года на саммите AI Engineer. Спикер - заметный в сообществе фронтенд-разработчик и предприниматель, что известен своим саркастичным подходом к современной веб-разработке, которую он критикует излишнюю сложность инструментов (Webpack, конфигурации) и пропагандирует подход "Just Ship It". В этом докладе Kitze утверждает, что "vibe coding" веселый способ создания пет-проектов, но для реальной работы нужно превратить это в "vibe engineering. Если говорить про тезисы, то вот они

1️⃣ Спираль смерти (The Doom Loop)
Проблема с vibe coding в том, что как только вы начинаете вручную править код, написанный ИИ, вы ломаете «вайб». Вы тратите время на чтение чужого (машинного) кода, пытаетесь его понять, вносите правку, а потом при следующей генерации ИИ может затереть ваши изменения или перестать понимать контекст. Решение от Kitze в том, что если ИИ написал баг, не чините его руками. Заставьте ИИ починить его. Это требует дисциплины, но это единственный способ сохранить скорость. Вы должны стать менеджером, который не делает работу за стажера, а заставляет стажера переделать задачу правильно.

2️⃣ Контекст - это всё
Обычный vibe doding ломается на больших проектах, потому что ИИ «забывает» или не знает структуру всего проекта. А "vibe engineering" - это уже построение инфраструктуры вокруг LLM, которая автоматически скармливает модели весь актуальный контекст проекта (структуру файлов, типы, документацию) перед каждым запросом. Kitze показывает, что вместо написания кода он теперь пишет скрипты и промпты, которые собирают контекст для ИИ. Это и есть новая инженерия.

3️⃣ От синтаксиса к семантике
Разработчик перестает быть "писателем кода" и становится "архитектором намерений". Ваша задача - четко описать что должно произойти, а как это будет написано (на React, Vue или чистом JS) - становится вторичным.

Интересно, что автор предлагает эволюцию названия и подходов:
- "Vibe coding": "Я попросил Claude сделать змейку, и оно работает. Прикольно". Это хаотичный процесс, случайный результат.
- "Vibe engineering: "Я построил конвейер, где ИИ имеет доступ ко всей моей базе кода, знает мои линтеры и тесты, и я могу надежно генерировать сложные фичи, управляя процессом через промпты и тесты". Это уже похоже на инженерию
Kitze аргументирует, что мы должны перейти от стадии "игры" с ИИ к стадии профессионального встраивания ИИ в инженерные процессы.

Если подумать о том, а как предложенные изменения влияют на индустрию, то получим следующее
- Vibe coding опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису for loop, а системному дизайну и проверке качества.
- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.

Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.

#Engineering #AI #Software #ML #DevEx #Productivity #IDE

Atlassian покупает платформу DX (developer experience) за $1 млрд - причины и последствия (Рубрика #DevEx)

18 сентября 2025 года компания Atlassian официально объявила о приобретении платформы DX (Developer Experience) приблизительно за $1 млрд с оплатой наличными средствами и акциями Atlassian (крупнейшее поглощение в истории Atlassian). DX представляет собой платформу инженерной аналитики, которая позволяет организациям оценивать продуктивность команд разработки и выявлять "узкие места" в их процессах. Мне это поглощение интересно тем, что среди создателей DX есть авторы подходов DORA, SPACE, DevEx, про которые я много рассказывал.

Руководство Atlassian объясняет покупку DX стратегическим стремлением помочь своим клиентам эффективнее использовать инвестиции в ИИ и улучшить работу инженерных команд. Компания отмечает, что всё больше предприятий вкладываются в инструменты искусственного интеллекта, но сталкиваются с вопросом, приносят ли эти вложения реальную отдачу в ускорении разработки (DX недавно опубликовали методологию "Measuring AI code assistants and agents")

Дополнительным обоснованием сделки стал синергетический эффект: около 90% клиентов DX уже используют продукты Atlassian (Jira, Confluence, Bitbucket и др.), что сделало DX очевидным кандидатом для присоединения. Кэннон-Брукс, соучредитель и CEO Atlassian, отмечал, что Atlassian несколько лет пыталась создать собственный инструмент для анализа продуктивности инженеров, однако в итоге решила приобрести готовое решение (сам стартап DX был основан 5 лет назад)

Atlassian планирует глубоко интегрировать DX в свою экосистему. В октябре 2025 года CTO Atlassian представил новый комплект Atlassian Software Collection, куда DX вошла в качестве новейшего компонента: платформа DX дополняет существующие решения, объединяя качественные опросы разработчиков с количественными метриками такими, как время прохождения pull request, частота сбоев сборки и уровень использования AI-инструментов. Данные DX будут напрямую доступны в продуктах Atlassian, а также DX продолжит поддерживать интеграции и с сторонними инструментами, чтобы клиенты могли извлекать пользу из DX независимо от стека Atlassian.

В будущем пользователям Atlassian станут доступны следующие возможности благодаря интеграции DX
- Измерение продуктивности и узких мест: система автоматически собирает ключевые показатели развития софта (скорость цикла код-ревью, частоту неудачных билдов, время внедрения фич) и выявляет узкие места в процессе
- Аналитика использования ИИ: DX позволяет отслеживать, как активно и с каким эффектом разработчики применяют AI-инструменты (код-ассистентов, агентов и пр.), отсекая шум и показывая реальную отдачу от AI-внедрений.
- Оценка опыта разработчиков: Помимо технических метрик, DX регулярно собирает качественные данные об опыте инженеров (опросы удовлетворённости, индексы Developer Experience). Совмещая цифры с мнением самих разработчиков, платформа определяет, что мешает людям работать продуктивно, и где возникают точки напряжения в взаимодействии команд

В целом, покупка DX сигнализирует о появлении в линейке Atlassian нового класса функций - “инженерной аналитики” - благодаря которому разработчики и менеджеры смогут совместно измерять и улучшать продуктивность, основываясь на данных, а не интуиции. Atlassian позиционирует этот шаг как часть более широкой стратегии по созданию интегрированной платформы для управления разработкой в эпоху ИИ, где связаны воедино планирование (Jira/Confluence), выполнение (код и CI/CD) и анализ эффективности (DX) для непрерывного совершенствования процесса создания софта

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

Leadership in AI Assisted Engineering (Рубрика #AI)

Интересный доклад Justin Reock, Deputy CTO компании DX (ее недавно купила Atlassian за $1 млрд). Reock известен своей работой по измерению и оптимизации developer productivity, что делает его одним из ведущих голосов в индустрии по вопросам внедрения AI в разработку. В этом докладе он рассказывал про продуктивность инженеров и приводил много отсылок к исследованиям, о которых я уже раньше рассказывал. Ниже я привел основные тезисы доклада

1️⃣ Парадокс AI-продуктивности: огромная вариативность результатов
Вопреки хайпу, реальное влияние AI на продуктивность крайне неоднородно.
Например, Сундар Пичай, CEO Google, в июне 2025 рассказывал про 10% увеличения engineering capacity. И тем же летом исследование METR показало 19% замедление работы с AI - хотя разработчики чувствовали себя на 20% быстрее. Я разбирал это исследование в постах 1 и 2 и даже в подкасте RIMS, где показано, что само исследование задизайнено под конкретный результат + представляет очень узкий кейс.
Если ориентироваться на данные платформы DX, где представлены 300+ компаний, то средние показатели выглядят скромно: +7.5% качество документации, +3.4% качество кода, +2.6% confidence в изменениях, -1% change failure rate. Но если смотреть на вариативность результатов, то некоторые видят +20% улучшение метрик, другие 20% ухудшение метрик. Кажется, что это обусловлено подходом к внедрению AI и измерению эффектов

2️⃣ Психологическая безопасность - фундамент AI-трансформации
Автор презентации вспомнил про Project Aristotle от Google, которому почти 15 лет. Тогда ребята из Google решили провести исследование команд и ответить на вопрос "What makes a team effective at Google?". Ответом стал такой фактор как psychological safety. Подробнее про исследование я уже рассказывал. Фактор психологической безопасности важен при внедрении AI
- Страх замены AI приводит к саботажу внедрения
- Без доверия люди не экспериментируют с инструментами
- Необходима прозрачная коммуникация: AI дополняет, а не заменяет

3️⃣ W. Edwards Deming: 95% - система, 5% - люди
Эдвард Деминг говорил о том, что 90-95% производительности определяется системой (процессы, инструменты, культура). А вот остальное зависит от индивидуальных качеств работника.
Если это переносить на процессы разработки, то
- Performance reviews, individual coaching - работа на 5%, трата человеческого таланта
- Фокус должен быть на оптимизации системы: инфраструктура, workflows, developer experience
- Если что-то идёт не так - ищите проблемы в системе, а не в людях

4️⃣ DX AI Measurement Framework: три измерения успеха
Спикер рассказал подход про измерение эффектов AI по трем осям
- Utilization (Использование)
- Impact (Влияние)
- Cost (Стоимость)
Подробнее я рассказывал про подход ребят раньше в разборе + в моем подкасте вместе с Женей Сергеевым. Но если говорить про мысли спикера, то он говорит, что baseline в виде стандартных метрки developer productivity (DORA, SPACE) важнее AI-специфичных метрик - они показывают реальное влияние на outcomes.

5️⃣ Интеграция AI по всему SDLC, а не только в coding
Для большинства организаций написание когда никогда не было узким местом - часто они были в других местах: поиске информации и контекста, задержек code reviews, сложностей координации, работы с инцидентами и легаси кодом. Дальше автор привел ряд примеров внедрения AI в разных компаниях: Morgan Stanley, Zapier, Spotify, Booking.

6️⃣ Топ-5 приоритетов для лидеров
1. Снизить страх AI через прозрачность
2. Вложиться в образовании сотрудников + выделить время на эксперименты
3. Вндерить измерения и начать открытую дискуссию о метриках
4. Unblock usage - внедрить креативный подход к compliance
5. Создать циклы обратной связи для непрерывного улучшения

#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy #Metrics