AI-инженерия. Построение приложений с использованием базовых моделей (AI Engineering) (Рубрика #AI)
Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...
Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)
Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик
Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система
Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)
В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems
Книгу "AI Engineering" уже перевели и скоро выпустят в издательстве Питер. А я эту книгу прочитал на английском еще в начале года и она мне супер зашла (мы ее вместе с Женей Сергеевым из Flo почти целиком разобрали за три серии подкаста: 1, 2 и 3). Собственно, книга отлична подходит инженерам, что строят GenAI‑продукт прямо сейчас, например, чат‑бот, copilot, RAG, ...
Книгу написала Chip Huyen, которая
- Преподавала Machine Learning Systems Design в Stanford (CS329S), а значит умеет объяснять системно и доступно
- Написала книгу "Designing Machine Learning Systems" (O’Reilly), которую многие считают must‑read для инженеров из ML/Platform команд
- Работала на стыке AI + инфраструктуры (NVIDIA, Snorkel AI), сейчас - Voltron Data (GPU‑ускорение аналитики)
Есть несколько факторов почему "AI Engineering" стала бестселлером
1. Попала в боль 2024–2025: команды массово интегрируют базовые модели, и нужен инженерный фреймворк, а не очередной набор промптов
2. Большой фокус был на evaluation: не “vibe check”, а измеримые метрики, регрессионные наборы, LLM‑as‑a‑judge, тестирование на деградации
3. Закрывает прод‑реальность: стоимость и латентность инференса, мониторинг, качество данных/фидбек‑лупы, безопасность и риск‑менеджмент
4. Даёт карту паттернов (prompting, RAG, fine‑tuning, tools/function calling, agents) и отвечает на главный вопрос: когда что выбирать
5. У книги есть публичные материалы/ресурсы (репо на 12.5к звездочек), поэтому вокруг неё быстро выросла “экосистема” практик
Вот чем может быть полезна эта книга инженерам, которые уже пилят GenAI
- Превращает "демку на фреймворке" в проект: требования → архитектура → eval harness → релиз → наблюдаемость
- Помогает говорить на одном языке с Product/Platform: какие SLO/SLI у LLM‑фичи, что логируем, где делаем гейтинг качества, как считаем cost‑per‑request
- Хороша для техлидов: много про компромиссы (качество vs цена, контекст vs retrieval, детерминизм vs креативность) и про то, где чаще всего “ломается” система
Мини‑чеклист из книги, который можно использовать хоть завтра:
- Golden кейсы + негативные кейсы (и регулярные регрессионные eval’ы)
- Версионирование промптов/моделей/ретривера + логирование контекста
- Метрика "стоимость ответа" + бюджет на фичу
- Eval гейты в CI перед деплоем (как unit/integration, только для LLM)
В общем, книга определенно заслуживает прочтения. Кстати: пока книга еще в предзаказе на нее действует скидка в 35% при использовании промокода "Предзаказ"
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems
www.piter.com
AI-инженерия. Построение приложений с использованием базовых моделей
Новая книга бестового автора Чип Хьюен по AI-инженерии.
🔥14❤8⚡5
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 опасен для новичков. Если ты не можешь верифицировать результат (не понимаешь архитектуру), ты создашь монстра. Новички теперь должны учиться не синтаксису
- Опытный инженер - становится супер-продуктивен. Если он знает что хочет получить, то с помощью vibe engineering может заменить целую команду из 3-5 человек. Kitze приводит пример, как он переписал огромные куски Sizzy за дни, а не месяцы (sizzy - это браузер для разработчиков и qa-инженеров)
- DevEx меняется - раньше мы оптимизировали подсветку синтаксиса и автодополнение. Теперь DX - это то, насколько легко ваш проект "читается" нейросетью. Если ваш код непонятен для LLM, вы проиграли.
Ну и однострочные выводы из доклада звучат так
- Не пишите код, управляйте им. Лучший код - тот, который вы не писали руками.
- Инвестируйте в контекст. Научитесь создавать инструменты, которые позволяют ИИ "видеть" ваш проект целиком.
- Сопротивляйтесь желанию "быстро поправить руками". Это ловушка, которая возвращает вас в старую парадигму и замедляет в долгосрочной перспективе.
- Код становится эфемерным. Мы привыкли беречь код. В эпоху vibe engineering код можно легко удалить и сгенерировать заново, если он перестал соответствовать требованиям. Ценность - в описании задачи, а не в файле с кодом.
#Engineering #AI #Software #ML #DevEx #Productivity #IDE
Посмотрел юморное выступление 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
YouTube
From Vibe Coding To Vibe Engineering – Kitze, Sizzy
Web development has always moved in cycles of hype, from frameworks to tooling. With the rise of large language models, we're entering a new era of "vibe coding," where developers shape software through collaboration with Al rather than syntax. This talk…
🔥15❤8🥴4🤝3👍1
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
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
TechCrunch
Atlassian acquires DX, a developer productivity platform, for $1B | TechCrunch
Atlassian is making its largest acquisition yet by buying DX so it can offer a developer productivity tool.
❤5🔥5🤯2⚡1
The Infinite Software Crisis (Рубрика #AI)
Посмотрел на выходных интересный доклад Джейка Нэйшнса (Jake Nations), staff engineer из Netflix. Джейк занимается встраиванием AI инструментов в процессы разработки в Netflix, а в этом докладе он делится трезвым взглядом инженера о том, как генеративный код ломает архитектуру. Если говорить про ключевые тезисы, то они такие
1️⃣ Бесконечный кризис софта
Исторически (от Дейкстры в 60-х до Cloud Native) каждый новый инструмент обещал решить проблему сложности, но лишь позволял нам строить еще более запутанные системы. AI просто разогнал этот процесс до предела.
2️⃣ Vibe Coding => Tech Debt
Разработка через чат-интерфейс (conversational interface) - это ловушка. Архитектура начинает зеркалить вашу беседу: каждое уточнение "а поправь еще это" наслаивается поверх предыдущего, создавая спагетти-код с мертвыми ветками логики. Интересно, что я сейчас пробую разрабатывать в Lovable и вижу как мои запросы приводят к появлению архитектуры (правда, я еще и в привязанном GitHub вижу как и какой код появляется)
3️⃣ Simple vs Easy
Джейк цитирует Рича Хики:
- Easy - это то, что под рукой: скопировать со StackOverflow или попросить AI сгенерить портянку кода
- Simple - это отсутствие переплетений (entanglement)
AI делает часть про "easy" почти бесплатным, но убивает "simple", так как агенты не умеют отличать "существенную" сложность задачи от "случайной" (наследия костылей)
4️⃣ Решение что предлагает Джейк
Использовать трёхфазный метод, чтобы не утонуть в хаосе, нужно вернуть инженерную строгость и разделить процесс:
- Research. Скормить агенту доки и диаграммы, чтобы он составил карту системы. Обязательно вычитать и поправить вручную
- Planning. Написать спецификацию изменений (вплоть до сигнатур функций). План должен быть настолько детальным, чтобы джун мог реализовать его механически (paint-by-numbers).
- Implementation. Только теперь запускать генерацию. Вы ревьюите соответствие плану, а не пытаетесь угадать, что там нафантазировал AI.
Если подумать об этом, то мы входим в эпоху, где написание кода стоит примерно 0. И главным дефицитом становится понимание системы (context & understanding). Если раньше вы могли "прочитать" код и понять, как он работает, то в мире, где джун генерирует 10к строк за вечер, это становится невозможным. Техлидам придется сместить фокус с код-ревью на дизайн-ревью и валидацию планов. Те, кто продолжит просто "чатиться с кодом", скоро обнаружат у себя в проде системы, которые невозможно поддерживать и безопасно изменять.
В докладе Джейк опирается на классику Software Engineering, которую стоит перечитать:
- Fred Brooks, "No Silver Bullet" (1986)
- Rich Hickey, "Simple Made Easy" (2011)
- Edsger W. Dijkstra, "The Humble Programmer" (1972)
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software
Посмотрел на выходных интересный доклад Джейка Нэйшнса (Jake Nations), staff engineer из Netflix. Джейк занимается встраиванием AI инструментов в процессы разработки в Netflix, а в этом докладе он делится трезвым взглядом инженера о том, как генеративный код ломает архитектуру. Если говорить про ключевые тезисы, то они такие
1️⃣ Бесконечный кризис софта
Исторически (от Дейкстры в 60-х до Cloud Native) каждый новый инструмент обещал решить проблему сложности, но лишь позволял нам строить еще более запутанные системы. AI просто разогнал этот процесс до предела.
2️⃣ Vibe Coding => Tech Debt
Разработка через чат-интерфейс (conversational interface) - это ловушка. Архитектура начинает зеркалить вашу беседу: каждое уточнение "а поправь еще это" наслаивается поверх предыдущего, создавая спагетти-код с мертвыми ветками логики. Интересно, что я сейчас пробую разрабатывать в Lovable и вижу как мои запросы приводят к появлению архитектуры (правда, я еще и в привязанном GitHub вижу как и какой код появляется)
3️⃣ Simple vs Easy
Джейк цитирует Рича Хики:
- Easy - это то, что под рукой: скопировать со StackOverflow или попросить AI сгенерить портянку кода
- Simple - это отсутствие переплетений (entanglement)
AI делает часть про "easy" почти бесплатным, но убивает "simple", так как агенты не умеют отличать "существенную" сложность задачи от "случайной" (наследия костылей)
4️⃣ Решение что предлагает Джейк
Использовать трёхфазный метод, чтобы не утонуть в хаосе, нужно вернуть инженерную строгость и разделить процесс:
- Research. Скормить агенту доки и диаграммы, чтобы он составил карту системы. Обязательно вычитать и поправить вручную
- Planning. Написать спецификацию изменений (вплоть до сигнатур функций). План должен быть настолько детальным, чтобы джун мог реализовать его механически (paint-by-numbers).
- Implementation. Только теперь запускать генерацию. Вы ревьюите соответствие плану, а не пытаетесь угадать, что там нафантазировал AI.
Если подумать об этом, то мы входим в эпоху, где написание кода стоит примерно 0. И главным дефицитом становится понимание системы (context & understanding). Если раньше вы могли "прочитать" код и понять, как он работает, то в мире, где джун генерирует 10к строк за вечер, это становится невозможным. Техлидам придется сместить фокус с код-ревью на дизайн-ревью и валидацию планов. Те, кто продолжит просто "чатиться с кодом", скоро обнаружат у себя в проде системы, которые невозможно поддерживать и безопасно изменять.
В докладе Джейк опирается на классику Software Engineering, которую стоит перечитать:
- Fred Brooks, "No Silver Bullet" (1986)
- Rich Hickey, "Simple Made Easy" (2011)
- Edsger W. Dijkstra, "The Humble Programmer" (1972)
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software
YouTube
The Infinite Software Crisis – Jake Nations, Netflix
In 1968, the term ""Software Crisis"" emerged when systems grew beyond what developers could manage. Every generation since has ""solved"" it with more powerful tools, only to create even bigger problems.
Today, AI accelerates the pattern into the Infinite…
Today, AI accelerates the pattern into the Infinite…
👍23❤9🔥6🥱1
Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software)
Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал)
1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам
2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).
3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.
В общем, книги достойные - я получил большое удовольствие, когда их изучал:)
#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API
Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал)
1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам
2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).
3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.
В общем, книги достойные - я получил большое удовольствие, когда их изучал:)
#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API
🔥30❤🔥10👍9❤4✍1
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
Интересный доклад 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
YouTube
Leadership in AI Assisted Engineering – Justin Reock, DX (acq. Atlassian)
To realize meaningful returns on AI investments, leadership must take accountability and ownership of establishing best practices, enabling engineers, measuring impact, and ensuring proper guardrails are in place. When prompting practice and reflexive AI…
🔥10❤3💯2
DORA 2025 - State of AI-assisted Software Development - Общая информация по отчету (Рубрика #Devops)
Я уже как-то кратко рассказывал про исследование "DORA Research: 2025" в одном из прошлых постов. Тогда я внимательно прочитал отчет, но тогда рассказал про его результаты очень кратко. А сейчас мне потребовался более подробный разбор для нашего исследования влияния AI на инженерную культуру и я решил расписать его и для своих подписчиков.
Отчет “State of AI-assisted Software Development 2025” подготовлен исследовательской командой программы DORA (DevOps Research and Assessment), что является частью Google Cloud. Ведущими авторами стали специалисты Google Cloud при участии приглашенных экспертов. Партнерами исследования были IT Revolution, GitHub, GitLab, SkillBench и Workhelix. Кроме того инициативу поддержал ряд спонсоров (Swarmia, Thoughtworks, Deloitte, Atlassian и др.).
В рамках исследования был проведен глобальный опрос почти 5 000 технических специалистов из разных стран и компаний. Респонденты включали инженеров-разработчиков, DevOps/SRE, тимлидов, продакт-менеджеров. Опрос охватил широкий спектр тем: от степени и способов использования ИИ (какие инструменты и LLM-модели применяются, для каких задач, сколько времени тратится, как часто доверяют советам ИИ) до характеристик команд и процессов (архитектура и платформы разработки, культура обучения, Value Stream Management, практики контроля версий, размер батчей изменений и т.п.). Также оценивались результаты работы команд: классические метрики DORA (например, скорость доставки и стабильность выпуска ПО), качество кода, продуктивность разработчиков, частота фрикций в работе и выгорание сотрудников. Для углубления анализа исследователи собрали и более 100 часов качественных данных – интервью и разборов практик, чтобы дополнить цифры живыми инсайтами.
Интересно, что полгода назад я рассказывал про то, как работает методология DORA для составления таких отчетов, но для отчета 2025 авторы отдельно описали "Measurement Framework" и то, как это можно использовать для управления изменениями в своей компании. Если же говорить про самих ребят и их отчет DORA 2025, то обработка данных сочетала статистические и аналитические методы. Масштабный опрос позволил провести корреляционный анализ и регрессионные модели, выявляя взаимосвязи между практиками и итоговыми показателями эффективности.
В итоге, получился отчет состоящий из следующих частей
- "Beyond the tools": обсуждается, почему успешное внедрение ИИ – это системная задача, а не просто выбор инструмента.
- Анализ текущего состояния AI-assisted разработки: представлены результаты опроса об уровне адаптации ИИ в индустрии, о практиках использования и влиянии на ключевые показатели.
- "Understanding your teams: 7 profiles": в этом разделе DORA представляет обнаруженные семь архетипов команд разработки
- "DORA AI Capabilities Model": центральная глава, вводящая новую модель способностей для успеха с ИИ. Здесь подробно перечисляются семь технических и культурных практик (системных факторов), которые статистически усиливают положительное влияние ИИ на эффективность команд
- "Directing AI’s potential": раздел, посвященный тому, как направить усилия по внедрению ИИ в правильное русло. В частности, разбирается роль Value Stream Management (VSM) как механизма, позволяющего конвертировать локальные улучшения от ИИ в конечный результат для бизнеса
- Рекомендации и выводы для лидеров: заключительная часть отчета переводит результаты в практическую плоскость. Здесь дается “дорожная карта” для внедрения ИИ – на каких направлениях сфокусироваться в первую очередь. В отчете прямо говорится, что руководители должны рассматривать внедрение AI как трансформацию организации, а не просто ИТ-проект
P.S.
В комментариях приложу сам PDF с отчетом.
#AI #Software #Engineering #Management #Whitepaper
Я уже как-то кратко рассказывал про исследование "DORA Research: 2025" в одном из прошлых постов. Тогда я внимательно прочитал отчет, но тогда рассказал про его результаты очень кратко. А сейчас мне потребовался более подробный разбор для нашего исследования влияния AI на инженерную культуру и я решил расписать его и для своих подписчиков.
Отчет “State of AI-assisted Software Development 2025” подготовлен исследовательской командой программы DORA (DevOps Research and Assessment), что является частью Google Cloud. Ведущими авторами стали специалисты Google Cloud при участии приглашенных экспертов. Партнерами исследования были IT Revolution, GitHub, GitLab, SkillBench и Workhelix. Кроме того инициативу поддержал ряд спонсоров (Swarmia, Thoughtworks, Deloitte, Atlassian и др.).
В рамках исследования был проведен глобальный опрос почти 5 000 технических специалистов из разных стран и компаний. Респонденты включали инженеров-разработчиков, DevOps/SRE, тимлидов, продакт-менеджеров. Опрос охватил широкий спектр тем: от степени и способов использования ИИ (какие инструменты и LLM-модели применяются, для каких задач, сколько времени тратится, как часто доверяют советам ИИ) до характеристик команд и процессов (архитектура и платформы разработки, культура обучения, Value Stream Management, практики контроля версий, размер батчей изменений и т.п.). Также оценивались результаты работы команд: классические метрики DORA (например, скорость доставки и стабильность выпуска ПО), качество кода, продуктивность разработчиков, частота фрикций в работе и выгорание сотрудников. Для углубления анализа исследователи собрали и более 100 часов качественных данных – интервью и разборов практик, чтобы дополнить цифры живыми инсайтами.
Интересно, что полгода назад я рассказывал про то, как работает методология DORA для составления таких отчетов, но для отчета 2025 авторы отдельно описали "Measurement Framework" и то, как это можно использовать для управления изменениями в своей компании. Если же говорить про самих ребят и их отчет DORA 2025, то обработка данных сочетала статистические и аналитические методы. Масштабный опрос позволил провести корреляционный анализ и регрессионные модели, выявляя взаимосвязи между практиками и итоговыми показателями эффективности.
В итоге, получился отчет состоящий из следующих частей
- "Beyond the tools": обсуждается, почему успешное внедрение ИИ – это системная задача, а не просто выбор инструмента.
- Анализ текущего состояния AI-assisted разработки: представлены результаты опроса об уровне адаптации ИИ в индустрии, о практиках использования и влиянии на ключевые показатели.
- "Understanding your teams: 7 profiles": в этом разделе DORA представляет обнаруженные семь архетипов команд разработки
- "DORA AI Capabilities Model": центральная глава, вводящая новую модель способностей для успеха с ИИ. Здесь подробно перечисляются семь технических и культурных практик (системных факторов), которые статистически усиливают положительное влияние ИИ на эффективность команд
- "Directing AI’s potential": раздел, посвященный тому, как направить усилия по внедрению ИИ в правильное русло. В частности, разбирается роль Value Stream Management (VSM) как механизма, позволяющего конвертировать локальные улучшения от ИИ в конечный результат для бизнеса
- Рекомендации и выводы для лидеров: заключительная часть отчета переводит результаты в практическую плоскость. Здесь дается “дорожная карта” для внедрения ИИ – на каких направлениях сфокусироваться в первую очередь. В отчете прямо говорится, что руководители должны рассматривать внедрение AI как трансформацию организации, а не просто ИТ-проект
P.S.
В комментариях приложу сам PDF с отчетом.
#AI #Software #Engineering #Management #Whitepaper
dora.dev
DORA | State of AI-assisted Software Development 2025
DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.
❤10👍3🔥2
T-Sync Conf (Рубрика #Software)
Приходите 7 февраля 2026 года на нашу большую конференцию T-Sync, точка синхронизации технологий и тех, кто их использует. Здесь будет много про практику, взаимодействие и живые системы. На этой конфе у нас будет стенд, где мы покажем результаты нашего исследования влияния AI на инженерную культуру. А вообще на конфе будет 8 технологических контуров из всех инженерных сфер: AI, Data, R&D, Security, UX/UI, Productivity, Observability, Platfrom. А вообще, эта конференция будет отличаться по формату от большинства конференций - здесь не будет скучных докладов (и не только скучных), но можно будет пообщаться и позадавать вопросы инженерам, которые реально делают те системы, которые работают у нас в проде, исследователям, что двигают нас вперед, а также техническим руководителям, которые не мешают работать остальным (а по мере своих сил стараются помогать).
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity #Conference
Приходите 7 февраля 2026 года на нашу большую конференцию T-Sync, точка синхронизации технологий и тех, кто их использует. Здесь будет много про практику, взаимодействие и живые системы. На этой конфе у нас будет стенд, где мы покажем результаты нашего исследования влияния AI на инженерную культуру. А вообще на конфе будет 8 технологических контуров из всех инженерных сфер: AI, Data, R&D, Security, UX/UI, Productivity, Observability, Platfrom. А вообще, эта конференция будет отличаться по формату от большинства конференций - здесь не будет скучных докладов (и не только скучных), но можно будет пообщаться и позадавать вопросы инженерам, которые реально делают те системы, которые работают у нас в проде, исследователям, что двигают нас вперед, а также техническим руководителям, которые не мешают работать остальным (а по мере своих сил стараются помогать).
#AI #PlatformEngineering #Engineering #Software #Processes #Productivity #Conference
❤7👍6🔥3
YaC 2025 AI Edition (Рубрика #AI)
В очередной YaC (Yet another Conference) Яндекс демонстрирует переход искусственного интеллекта из статуса технологии для энтузиастов в массовый инструмент для повседневных задач. Фильм внедряет в головы зрителя людей мысль о том, что ИИ должен стать "привычкой", помогая решать реальные проблемы без необходимости разбираться в технических деталях вроде "претрейна" и "инференса". По ходу фильма мы видим как Алиса AI превращается в "эмпатичного ассистента", который понимает контекст пользователя и встраивается во все сервисы экосистемы - от браузера до роботов-доставщиков.
Если говорить про целевую аудиторию, то фильм нацелен широко
- Массовые пользователи: родители (упражнения для детей с логопедом), туристы (сборы снаряжения для треккинга), покупатели (поиск товаров со скидками до 30%)
- Профессионалы: юристы (анализ 100-страничных законопроектов), врачи (диагностика по МРТ), предприниматели (рабочие задачи через Алису Про)
- Tech-энтузиасты: любители промптинга (платформа Промптхаб), разработчики (70% сотрудников Яндекса используют ИИ ежедневно)
Фильм длится чуть больше часа и разделён на шесть тематических блоков с естественными переходами между "железом", софтом и стратегией:
1️⃣ Алиса AI: от чата до экосистемы
- Обогащённые ответы с картами, картинками, рецептами
- Примеры из жизни: турист собирает рюкзак для Непала и сокращает вес с 13 до 7–8 кг благодаря анализу Алисы; родитель генерирует логопедические загадки с буквой "Р"
- Креативная генерация: оживление чёрно-белых фото вызывает эмоции у пользователей
2️⃣ Промпты и агенты
- Промптхаб - платформа для обмена шаблонами
- Агенты - система на нейросетях, автоматизирующая цепочки действий (пример агента "Найти дешевле")
- НейроГусь - внутренняя премия Яндекса за ИИ-проекты
3️⃣ Интеграция в сервисы: Маркет как пример
- Поиск по естественным запросам: "Собери всё для приготовления ростбифа" → Алиса предлагает термометр, доски, ножи, уточняет бюджет
- Мультимодальный поиск: фото человека → анализ одежды → подбор «похожего лука» с учётом персональных предпочтений
4️⃣ Алиса Про и бизнес-кейсы
- Алиса Про: для корпоративных задач (интеграция в почту, диск, вики)
- Нейроюрист: анализ законопроектов, претензий, договоров. 75% юристов Яндекса используют инструмент, экономя 2 часа в неделю на 10 запросов.
- Кейс с ПВЗ Яндекс Маркета: новые сотрудники решают вопросы о возвратах и габаритах через Алису Про
5️⃣ ИИ + "железо"
- Устройства: наушники Дропс (запись заметок голосом), диктофон с суммаризацией встреч, IP-камера (сценарии: "Если кот на столе - запусти пылесос")
- Роботы-доставщики: 20 000 роверов к 2027 году в городах России (запуск в СПб, Казани, Иннополисе). Завод на 1500 роботов/месяц, каждый проходит 50 тестов и калибровку за 20 минут. Нейросети управляют навигацией, обходят препятствия в реальном времени
- Автономный грузовик: лидары, камеры, ИИ для манёвров (система обучалась на данных водителей)
6️⃣ Медицина и будущее
- МРТ-анализ для новорождённых: нейросеть определяет объёмы мозга и вещества для выявления рисков ДЦП, сокращая время анализа с дней до минут
- Будущее работы: ИИ не заменяет людей, а создаёт новые места (экономит рутину, усиливает креатив). 70% сотрудников Яндекса используют ИИ ежедневно (рост с 30% в 2023)
В общем, фильм позиционирует Яндекс как компанию, которая первой в России превратила ИИ из хайпа в утилитарный инструмент для миллионов - от мелкобытовых задач (сборка рюкзака) до критически важных (медицинская диагностика)
#AI #Software #Engineering #Economics #Software #Management #Leadership
В очередной YaC (Yet another Conference) Яндекс демонстрирует переход искусственного интеллекта из статуса технологии для энтузиастов в массовый инструмент для повседневных задач. Фильм внедряет в головы зрителя людей мысль о том, что ИИ должен стать "привычкой", помогая решать реальные проблемы без необходимости разбираться в технических деталях вроде "претрейна" и "инференса". По ходу фильма мы видим как Алиса AI превращается в "эмпатичного ассистента", который понимает контекст пользователя и встраивается во все сервисы экосистемы - от браузера до роботов-доставщиков.
Если говорить про целевую аудиторию, то фильм нацелен широко
- Массовые пользователи: родители (упражнения для детей с логопедом), туристы (сборы снаряжения для треккинга), покупатели (поиск товаров со скидками до 30%)
- Профессионалы: юристы (анализ 100-страничных законопроектов), врачи (диагностика по МРТ), предприниматели (рабочие задачи через Алису Про)
- Tech-энтузиасты: любители промптинга (платформа Промптхаб), разработчики (70% сотрудников Яндекса используют ИИ ежедневно)
Фильм длится чуть больше часа и разделён на шесть тематических блоков с естественными переходами между "железом", софтом и стратегией:
1️⃣ Алиса AI: от чата до экосистемы
- Обогащённые ответы с картами, картинками, рецептами
- Примеры из жизни: турист собирает рюкзак для Непала и сокращает вес с 13 до 7–8 кг благодаря анализу Алисы; родитель генерирует логопедические загадки с буквой "Р"
- Креативная генерация: оживление чёрно-белых фото вызывает эмоции у пользователей
2️⃣ Промпты и агенты
- Промптхаб - платформа для обмена шаблонами
- Агенты - система на нейросетях, автоматизирующая цепочки действий (пример агента "Найти дешевле")
- НейроГусь - внутренняя премия Яндекса за ИИ-проекты
3️⃣ Интеграция в сервисы: Маркет как пример
- Поиск по естественным запросам: "Собери всё для приготовления ростбифа" → Алиса предлагает термометр, доски, ножи, уточняет бюджет
- Мультимодальный поиск: фото человека → анализ одежды → подбор «похожего лука» с учётом персональных предпочтений
4️⃣ Алиса Про и бизнес-кейсы
- Алиса Про: для корпоративных задач (интеграция в почту, диск, вики)
- Нейроюрист: анализ законопроектов, претензий, договоров. 75% юристов Яндекса используют инструмент, экономя 2 часа в неделю на 10 запросов.
- Кейс с ПВЗ Яндекс Маркета: новые сотрудники решают вопросы о возвратах и габаритах через Алису Про
5️⃣ ИИ + "железо"
- Устройства: наушники Дропс (запись заметок голосом), диктофон с суммаризацией встреч, IP-камера (сценарии: "Если кот на столе - запусти пылесос")
- Роботы-доставщики: 20 000 роверов к 2027 году в городах России (запуск в СПб, Казани, Иннополисе). Завод на 1500 роботов/месяц, каждый проходит 50 тестов и калибровку за 20 минут. Нейросети управляют навигацией, обходят препятствия в реальном времени
- Автономный грузовик: лидары, камеры, ИИ для манёвров (система обучалась на данных водителей)
6️⃣ Медицина и будущее
- МРТ-анализ для новорождённых: нейросеть определяет объёмы мозга и вещества для выявления рисков ДЦП, сокращая время анализа с дней до минут
- Будущее работы: ИИ не заменяет людей, а создаёт новые места (экономит рутину, усиливает креатив). 70% сотрудников Яндекса используют ИИ ежедневно (рост с 30% в 2023)
В общем, фильм позиционирует Яндекс как компанию, которая первой в России превратила ИИ из хайпа в утилитарный инструмент для миллионов - от мелкобытовых задач (сборка рюкзака) до критически важных (медицинская диагностика)
#AI #Software #Engineering #Economics #Software #Management #Leadership
YouTube
YaC 2025 AI Edition
YaC 2025 — это большой разговор про искусственный интеллект. Не про претрейн, инференс и другие сложные термины, а про реальные возможности, которые ИИ уже сегодня даёт пользователям — самым разным.
В чём польза ИИ для родителей, предпринимателей, юристов…
В чём польза ИИ для родителей, предпринимателей, юристов…
🔥4🦄3⚡2❤2👎2
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
🤖 Широкое внедрение ИИ-инструментов
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
🐍 Популярные языки программирования
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики в сфере технологий. Этот опрос проводился среди читателей рассылки "The Pragmatic Engineer" в апреле–мае 2025, причем в нем приняли участие 3k инженеров. Респондентами преимущественно являются инженеры-разработчики софта причем из компаний всех масштабов (от стартапа до бигтехов), причем так получилось, что половина работала в мелких и половина в крупных компаниях. Следует отметить, что выборка не случайна, а основана на подписчиках технического блога, поэтому она может смещаться в сторону продуктовых IT-компаний. Например, среди читателей заметно выше доля пользователей AWS и ниже - Azure по сравнению с традиционными корпоративными сегментами. В целом же охват опроса по ролям и компаниям очень широк, что даёт основание доверять тенденциям, выявленным в данных.
Результаты Гергели оформил в трех частях, каждая из которых посвящена определённым категориям инструментов разработки. Вот эти три части
1️⃣ Часть
Демография респондентов; использование AI-инструментов; наиболее используемые и любимые языки программирования; рейтинг самых нелюбимых и самых любимых инструментов; среды разработки (IDE) и терминалы; системы контроля версий и CI/CD; облачные платформы (IaaS/PaaS)
2️⃣ Часть
Наиболее часто упоминаемые инструменты (лидируют JIRA, VS Code и AWS); средства управления проектами; инструменты коммуникации и совместной работы (Slack, MS Teams, Confluence, Miro, Figma); базы данных и хранилища (PostgreSQL и мн. др.); бекенд-инфраструктура (Docker, Kubernetes, Terraform, облачные сервисы); балансировщики нагрузки; а также
3️⃣ Часть
Средства наблюдаемости, мониторинга и логирования; инструменты для дежурств и управления инцидентами; системы feature flags, аналитики и экспериментов; инструменты фронтенд- и мобильной разработки; различные утилиты для разработчиков; собственные (custom) внутренние инструменты команд; и нишевые любимые инструменты энтузиастов
Среди ключевых результатов можно выделить следующие
85% опрошенных инженеров используют в работе хотя бы один инструмент с элементами AI, например кодового помощника. Каждый второй респондент применяет GitHub Copilot – этот AI-помощник для программирования стал самым популярным средством из своего класса. Лишь около 4% принципиально не пользуются AI (по причинам корпоративного запрета, неэффективности или этических убеждений), что подчёркивает массовое проникновение данных технологий в разработку.
TypeScript вышел на первое место по частоте использования среди языков разработки (ожидаемо, учитывая его применение и в фронтенде, и в бекенде). Широко распространены также Python, JavaScript, Java, C# и другие языки, при этом все основные языковые экосистемы оцениваются разработчиками положительно - ни один язык не получил значимого перевеса негатива в отзывах. Это говорит о зрелости современных языков: откровенно "плохие" решения попросту не становятся массовыми. В топ-10 самых любимых языков неожиданно вошёл даже нишевый Elixir, а фреймворк Ruby on Rails оказался одновременно 5-м по использованию и 3-м по любви, что подчёркивает лояльность его сообщества (чтобы понять любовь к нему можно глянуть документалку про RoR)
Продолжение в следующем посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Pragmaticengineer
The Pragmatic Engineer 2025 Survey: What’s in your tech stack? Part 1
Which tools do software engineers use for backend development, frontend, infrastructure, AI tooling, and more, today? Reader survey, with feedback and analysis, based on 3,000+ responses
❤5🔥2⚡1
Применение AI и LLM в разработке и управлении (Рубрика #AI)
Посмотрел на неделе выступление Александра Лукьянченко с конференции AvitoTechConf 2025, которую я посетил очно (но провел большую часть времени не за просмотром докладов, а общаясь со знакомыми и обсуждая примерно те же темы, но более открыто). Если же возвращаться к докладу Саши, то он поделился цифрами о том, как AI реально работает в процессах разработки внутри Авито. Сам Саша руководит разработкой PaaS внутри компании и его команда отвечает за эффективность 2000+ инженеров, внутренние инструменты, облако и SDLC.
Основные тезисы доклада примерно такие
⌨️ Кодинг - это не вся работа
Непосредственное написание кода занимает всего 20–40% времени инженера. Остальное - это коммуникация, дизайн систем, ревью и "археология" (разбор чужого кода). AI должен помогать именно здесь, а не только дописывать строки. Есть и другие сценарии, например
🗺 Авто-картирование архитектуры
В микросервисной архитектуре сложно понять, кто за что отвечает. В Avito использовали LLM, чтобы проанализировать код, API и README всех сервисов и разложить их по доменам.
Результат: Автоматика совпала с ручной разметкой экспертов на 80%. Сэкономлено ~200 человеко-дней ручной работы архитекторов.
☠️ Анализ постмортемов
Скормили LLM базу из 800+ инцидентов (postmortems). Модель нашла 22 системных паттерна проблем, которые не видели люди, и предложила сценарии для Chaos Engineering. Это позволило закрыть >1000 потенциальных уязвимостей.
⚙️ Эволюция инструментов
Ребята в индустрии переходят от фазы Copilot (автодополнение) к фазе Agents (автономное выполнение задач). В топе сейчас инструменты вроде Cline, Roo Code и режимы агентов в IDE, которые могут сами "ходить" по проекту и править файлы.
Что это значит для индустрии
1. Ощущение продуктивности обманчиво. Инженеры часто чувствуют, что стали работать быстрее с AI, но метрики говорят об обратном (особенно исследование METR на 16 инженеров, которое я разбирал). Если AI пишет много кода, который потом нужно долго дебажить - это не ускорение, а генерация техдолга.
2. Greenfield vs Brownfield. AI отлично бустит старт новых проектов (до 30-40%), но на старых, сложных легаси-проектах ("brownfield") прирост продуктивности падает до 0–10%, а иногда становится отрицательным из-за rework.
3. Сдвиг фокуса. Главная ценность AI сейчас не в написании кода, а в снижении когнитивной нагрузки (быстрый поиск по доке, саммари бесконечных тредов в Slack, объяснение легаси).
P.S.
Саша делал отсылку к исследованию Stanford на 120k инженеров. Недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) рассказывал новый доклад "Can you prove AI ROI in Software Engineering?" на эту тему на AI Engineer кофне и я его уже разбирал, там много интересного, рекомендую к просмотру.
#AI #DevOps #Engineering #Management #Leadership #Software #Architecture #SRE
Посмотрел на неделе выступление Александра Лукьянченко с конференции AvitoTechConf 2025, которую я посетил очно (но провел большую часть времени не за просмотром докладов, а общаясь со знакомыми и обсуждая примерно те же темы, но более открыто). Если же возвращаться к докладу Саши, то он поделился цифрами о том, как AI реально работает в процессах разработки внутри Авито. Сам Саша руководит разработкой PaaS внутри компании и его команда отвечает за эффективность 2000+ инженеров, внутренние инструменты, облако и SDLC.
Основные тезисы доклада примерно такие
Непосредственное написание кода занимает всего 20–40% времени инженера. Остальное - это коммуникация, дизайн систем, ревью и "археология" (разбор чужого кода). AI должен помогать именно здесь, а не только дописывать строки. Есть и другие сценарии, например
В микросервисной архитектуре сложно понять, кто за что отвечает. В Avito использовали LLM, чтобы проанализировать код, API и README всех сервисов и разложить их по доменам.
Результат: Автоматика совпала с ручной разметкой экспертов на 80%. Сэкономлено ~200 человеко-дней ручной работы архитекторов.
Скормили LLM базу из 800+ инцидентов (postmortems). Модель нашла 22 системных паттерна проблем, которые не видели люди, и предложила сценарии для Chaos Engineering. Это позволило закрыть >1000 потенциальных уязвимостей.
Ребята в индустрии переходят от фазы Copilot (автодополнение) к фазе Agents (автономное выполнение задач). В топе сейчас инструменты вроде Cline, Roo Code и режимы агентов в IDE, которые могут сами "ходить" по проекту и править файлы.
Что это значит для индустрии
1. Ощущение продуктивности обманчиво. Инженеры часто чувствуют, что стали работать быстрее с AI, но метрики говорят об обратном (особенно исследование METR на 16 инженеров, которое я разбирал). Если AI пишет много кода, который потом нужно долго дебажить - это не ускорение, а генерация техдолга.
2. Greenfield vs Brownfield. AI отлично бустит старт новых проектов (до 30-40%), но на старых, сложных легаси-проектах ("brownfield") прирост продуктивности падает до 0–10%, а иногда становится отрицательным из-за rework.
3. Сдвиг фокуса. Главная ценность AI сейчас не в написании кода, а в снижении когнитивной нагрузки (быстрый поиск по доке, саммари бесконечных тредов в Slack, объяснение легаси).
P.S.
Саша делал отсылку к исследованию Stanford на 120k инженеров. Недавно Егор Денисов-Бланш (Yegor Denisov-Blanch) рассказывал новый доклад "Can you prove AI ROI in Software Engineering?" на эту тему на AI Engineer кофне и я его уже разбирал, там много интересного, рекомендую к просмотру.
#AI #DevOps #Engineering #Management #Leadership #Software #Architecture #SRE
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Применение AI и LLM в разработке и управлении | Александр Лукьянченко. AvitoTechConf 2025
GenAI инструменты позволяют решать и ускорять многие задачи, которые раньше было сложно автоматизировать. Мы часто слышим как AI заменяет целый класс задач в разработке, что инструменты вида Cursor сильно ускоряют вывод продуктов на рынок. Но как выглядит…
2👍16❤8🔥3👏1🤩1
[2/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
❤🔥 Инструменты разработки: любовь и ненависть
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
✈ Командная коммуникация и сотрудничество
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
🐘 Инфраструктура и базы данных
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Продолжая рассказ про опрос Гергели, рассмотрим оставшиеся темы
Список самых часто используемых инструментов возглавил неожиданно JIRA (чаще даже VS Code или AWS). Парадоксально, но JIRA же стал и самым ненавидимым инструментом (разработчики не любят JIRA за медлительность и громоздкость), а вот более лёгкий конкурент, Linear, напротив, попал в число самых любимых инструментов (№4) и рассматривается инженерами как желанная замена JIRA. В целом, два этих инструмента сейчас доминируют в управлении проектами (вместе 75% упоминаний project management инструментов). JIRA в крупных компаниях, а Linear в малых.
Среди средств коммуникации лидируют проверенные решения: Slack - самый используемый чат для разработки, а Microsoft Teams - наиболее распространён для видеозвонков. Для хранения документации чаще всего применяют Confluence, для совместного brainstorming - онлайн-доску Miro, а для дизайна интерфейсов - Figma. Примечательно, что Figma упоминалась разработчиками даже чаще, чем такой профильный инструмент, как K8s. Это свидетельствует о глубоком вовлечении команд разработки в процесс проектирования UX/UI и тесной междисциплинарной работе с дизайнерами.
😶🌫️ Облачные платформы
В облачной инфраструктуре опрос подтвердил безусловное лидерство Amazon Web Services (AWS) - эту платформу используют ~44% респондентов, тогда как у ближайшего преследователя, Microsoft Azure, ~30%. Доля Google Cloud Platform составляет оставшиеся ~26%.
Практически повсеместно используются контейнеры Docker и оркестратор K8s - де-факто стандарт развёртывания приложений. Для управления инфраструктурой как кодом лидирует Terraform. Кроме того, широко востребованы управляемые облачные сервисы (например, от AWS) для типовых задач backend. Что касается хранения данных, опрос показал безоговорочную популярность PostgreSQL (1/3 респондентов упоминало ее). Тем не менее, выбор технологий хранения невероятно разнообразен: профессионалы упомянули десятки разных баз данных (SQL, NoSQL, NewSQL, специализированные хранилища и т. д.). Это говорит о том, что современный стек данных очень неоднороден, и команды подбирают БД строго под свои задачи.
♾️ Мониторинг и надежность (DevOps)
В сфере observability данных наиболее популярны платформы Datadog, Grafana и Sentry - каждая из них используется примерно у 15-25% участников опроса. Эти инструменты (соответственно, облачный сервис мониторинга, open-source система дашбордов и сервис отслеживания ошибок) стали привычной частью инфраструктуры многих команд. Для оповещений и реагирования на инциденты подавляющее число инженеров применяют классические решения PagerDuty и OpsGenie.
📱 Фронтенд и мобильные технологии
Здесь наблюдается большая консолидация вокруг нескольких фреймворков. React практически без конкурентов доминирует как основной фронтенд-фреймворк (упоминается большинством веб-разработчиков), а Next.js стал самым популярным "мета"-фреймворком для React-приложений. Для мобильной разработки кроссплатформенно лидирует React Native - опрошенные отмечают его гораздо чаще любых альтернатив. Иными словами, стек фронтенда в 2025 году у большинства команд выглядит схоже. На бекенде разброс решений больше, но и там многие используют единый стек на TypeScript/Node.js либо популярные фреймворки вроде .NET и Spring.
🎌 Feature flags и внутренние инструменты
Практика feature flags и a/b тестирования прочно вошла в жизнь: для этого многие используют готовые сервисы, главным из которых является LaunchDarkly. Тем не менее, опрос показал, что весьма часто компании создают собственные системы фичефлагов, платформы экспериментов и кастомные конвейеры деплоя. Это может указывать на то, что существующие продукты не полностью покрывают нужды команд, либо на желание сэкономить на лицензиях, либо на требования безопасности.
Выводы из исследования в финальном посте.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
❤6🔥4👍3
[3/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды
1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.
Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.
Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.
В 2025 году перед командами стоит задача грамотной интеграции множества инструментов: от AI-помощников до облачных сервисов, от мониторинга до экспериментальных платформ. Те компании, которые сумеют подобрать оптимальный набор технологий и процессов, получают конкурентное преимущество в эффективности разработки и скорости вывода продукта на рынок.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Если финализировать разбор этого отчета Гергели (начало в 1 и 2), то видны следующие ключевые тренды
1️⃣ Инструменты с искусственным интеллектом из разряда эксперимента перешли в категорию повседневных - подавляющее большинство разработчиков теперь пользуется AI-помощниками. Это означает, что продуктивность инженеров всё больше будет зависеть от интеграции AI в их рабочие процессы, а компании должны учитывать данную тенденцию при выборе инструментов.
2️⃣ Технологический стек продолжает унифицироваться вокруг лучших решений: TypeScript и React стали фактическим стандартом веб-разработки, Kubernetes – стандартом развёртывания, GitHub - стандартом хостинга кода и т. д. Популярные языки и фреймворки достигли такой зрелости, что разработчики в целом ими довольны и не испытывают острой необходимости срочно искать им замену
3️⃣ Позиции крупных экосистемных игроков остаются сильны. Так, Microsoft контролирует заметную часть инструментов разработчика (4 из 15 самых распространённых, включая VS Code, GitHub и Azure DevOps), Amazon - облачную инфраструктуру, Atlassian - управление проектами и т.д. Для индустрии это означает стабильность базового инструментария и продолжение инвестиций со стороны гигантов рынка.
Одновременно опрос показал и точки напряжения, которые можно рассматривать как ниши для инноваций.
Разработчики явно фрустрированы от "тяжеловесных" корпоративных решений – яркий пример тому JIRA, которую вынужденно используют повсеместно, но называют худшим инструментом. Запрос на более продуктивные, быстрые и удобные инструменты налицо, что подтверждается успехом конкурента Linear и других облегённых аналогов. Когда две системы (JIRA и Linear) охватывают порядка 75% всех командных процессов планирования, рынок фактически монополизирован парой игроков - и в то же время открывается возможность для новых продуктов, способных потеснить устоявшиеся, но нелюбимые решения.
Похожая ситуация складывается и в других категориях: например, появление специализированных стартапов в области oncall, фичефлагов, observability говорит о том, что существующие крупные продукты удовлетворяют не всех. Многие компании продолжают строить критически важные инструменты "in-house", и это сигнал вендорам о незакрытых потребностях. С другой стороны, столь богатый и разнообразный ландшафт инструментов - благо для инженеров, но и вызов для технологических лидеров.
В 2025 году перед командами стоит задача грамотной интеграции множества инструментов: от AI-помощников до облачных сервисов, от мониторинга до экспериментальных платформ. Те компании, которые сумеют подобрать оптимальный набор технологий и процессов, получают конкурентное преимущество в эффективности разработки и скорости вывода продукта на рынок.
#AI #ML #PlatformEngineering #Software #Architecture #Processes #DevEx #Devops
Telegram
Книжный куб
[1/3] The Pragmatic Engineer 2025 Survey (Рубрика #DevEx)
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
Добрался до результатов летнего исследования Гергели Ороша (Gergely Orosz), известного инженера и автора популярной рассылки "The Pragmatic Engineer", одного из самых влиятельных источников аналитики…
👍5❤3🔥2
[1/2] The state of AI in 2025. Agents, innovation, and transformation - Общие результаты исследования (Рубрика #AI)
Изучил интересный отчет от ноября 2025 года, что был подготовлен экспертами подразделения "QuantumBlack, AI by McKinsey" во главе с группой старших партнеров McKinsey. Мне было интересно сравнить его результаты с совместным отчетом "Яков и партнеры" (ex-McKinsey) и Яндекса, про которое я рассказывал раньше.
Исследование глобально McKinsey основано на онлайн-опросе, проведенном с 25 июня по 29 июля 2025 года. В опросе приняли участие 1 993 респондента из 105 стран, представляющие все основные регионы, отрасли, масштабы компаний, функциональные направления и уровни должностей. Около 38% участников работают в компаниях с выручкой более $1 млрд, а данные были взвешены по доле стран в глобальном ВВП для устранения перекосов.
Ключевые определения, которые используются по всему отчету и которые стоит знать при чтении
1) "Регулярное использование ИИ" определяется как применение ИИ хотя бы в одной бизнес-функции организации. Степень внедрения оценивалась по этапам
- Экспериментирование
- Пилотное внедрение
- Масштабирование (развертывание решений в масштабах компании)
- Полное масштабирование по всему предприятию
2) Авторы определили "агентные системы ИИ" (AI agents) как системы на основе foundation models, способные автономно действовать в реальном мире, планируя и выполняя многошаговые задачи
3) Под "AI high performers" (высокорезультативные компании в сфере ИИ) понимается небольшой сегмент (~6% опрошенных организаций), где благодаря ИИ достигается значимый эффект: более 5% совокупного EBIT компании и "существенная" бизнес-ценность напрямую обусловлены использованием ИИ. Именно практика этих лидеров рассматривается отдельно.
Executive summary приводится в самом начале отчета и выглядит так
1️⃣ Большинство организаций всё ещё на этапе экспериментов или пилотов
Почти две трети респондентов говорят, что их компании пока не начали масштабировать ИИ на уровень всей организации (enterprise-wide).
2️⃣ Высокий интерес к ИИ-агентам
62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3️⃣ Есть позитивные ранние сигналы влияния ИИ, но не на уровне всего бизнеса
Респонденты видят эффект в конкретных сценариях - снижение затрат и рост выручки; 64% считают, что ИИ помогает инновациям. Однако только 39% фиксируют влияние на EBIT на уровне компании в целом.
4️⃣ Лидеры по результатам используют ИИ не только для эффективности, но и для роста/инноваций
80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив. Но те, кто получает от ИИ максимальную ценность, часто добавляют цели роста или инноваций (а не ограничиваются срезанием затрат).
5️⃣ Перепроектирование процессов - ключевой фактор успеха
Половина "высокоэффективных" компаний планирует использовать ИИ для трансформации бизнеса, и большинство из них уже перерабатывают (redesign) рабочие процессы и цепочки выполнения задач.
6️⃣ Разные ожидания по влиянию на занятость
Оценки респондентов по тому, как ИИ повлияет на численность персонала в ближайший год, различаются: 32% ждут сокращения, 43% - без изменений, 13% - роста.
В продолжении я расскажу про стратегии высоко-эффективныхменеджеров команд, которые авторы отчета используют в качестве golden image или образца для подрожания, которому стоит следовать тем, кто еще не готов отчитаться об эффекте в 5% совокупного EBIT.
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Изучил интересный отчет от ноября 2025 года, что был подготовлен экспертами подразделения "QuantumBlack, AI by McKinsey" во главе с группой старших партнеров McKinsey. Мне было интересно сравнить его результаты с совместным отчетом "Яков и партнеры" (ex-McKinsey) и Яндекса, про которое я рассказывал раньше.
Исследование глобально McKinsey основано на онлайн-опросе, проведенном с 25 июня по 29 июля 2025 года. В опросе приняли участие 1 993 респондента из 105 стран, представляющие все основные регионы, отрасли, масштабы компаний, функциональные направления и уровни должностей. Около 38% участников работают в компаниях с выручкой более $1 млрд, а данные были взвешены по доле стран в глобальном ВВП для устранения перекосов.
Ключевые определения, которые используются по всему отчету и которые стоит знать при чтении
1) "Регулярное использование ИИ" определяется как применение ИИ хотя бы в одной бизнес-функции организации. Степень внедрения оценивалась по этапам
- Экспериментирование
- Пилотное внедрение
- Масштабирование (развертывание решений в масштабах компании)
- Полное масштабирование по всему предприятию
2) Авторы определили "агентные системы ИИ" (AI agents) как системы на основе foundation models, способные автономно действовать в реальном мире, планируя и выполняя многошаговые задачи
3) Под "AI high performers" (высокорезультативные компании в сфере ИИ) понимается небольшой сегмент (~6% опрошенных организаций), где благодаря ИИ достигается значимый эффект: более 5% совокупного EBIT компании и "существенная" бизнес-ценность напрямую обусловлены использованием ИИ. Именно практика этих лидеров рассматривается отдельно.
Executive summary приводится в самом начале отчета и выглядит так
1️⃣ Большинство организаций всё ещё на этапе экспериментов или пилотов
Почти две трети респондентов говорят, что их компании пока не начали масштабировать ИИ на уровень всей организации (enterprise-wide).
2️⃣ Высокий интерес к ИИ-агентам
62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3️⃣ Есть позитивные ранние сигналы влияния ИИ, но не на уровне всего бизнеса
Респонденты видят эффект в конкретных сценариях - снижение затрат и рост выручки; 64% считают, что ИИ помогает инновациям. Однако только 39% фиксируют влияние на EBIT на уровне компании в целом.
4️⃣ Лидеры по результатам используют ИИ не только для эффективности, но и для роста/инноваций
80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив. Но те, кто получает от ИИ максимальную ценность, часто добавляют цели роста или инноваций (а не ограничиваются срезанием затрат).
5️⃣ Перепроектирование процессов - ключевой фактор успеха
Половина "высокоэффективных" компаний планирует использовать ИИ для трансформации бизнеса, и большинство из них уже перерабатывают (redesign) рабочие процессы и цепочки выполнения задач.
6️⃣ Разные ожидания по влиянию на занятость
Оценки респондентов по тому, как ИИ повлияет на численность персонала в ближайший год, различаются: 32% ждут сокращения, 43% - без изменений, 13% - роста.
В продолжении я расскажу про стратегии высоко-эффективных
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
McKinsey & Company
The state of AI in 2025: Agents, innovation, and transformation
In this 2025 edition of the annual McKinsey Global Survey on AI, we look at the current trends that are driving real value from artificial intelligence.
❤7👍6🔥4
[2/2] The state of AI in 2025. Agents, innovation, and transformation - Стратегии высокоэффективных компаний (Рубрика #AI)
Заканчивая разбор этого отчета от McKinsey, я не смог пройти мимо самой интересной части исследования - сравнения обычных компаний с высокоэффективными 6% организаций, которые добились заметного влияния ИИ на бизнес. Эти лидеры разительно отличаются подходом. Исследователи McKinsey определяют их по двум критериям: >5% EBIT от ИИ и подтвержденная "значимая" ценность от использования ИИ. Авторы отчета используют эти компании в качестве golden image или образца для подрожания, которому стоит следовать тем, кто еще не готов отчитаться об эффекте в 5% совокупного EBIT.
Ниже расписаны отличия AI-стохановцев от остальных компаний
1️⃣ Лидеры ставят перед ИИ амбициозные цели
Половина таких компаний заявляет, что намерена с помощью ИИ трансформировать бизнес, а не просто улучшить эффективность. По опросу, они в 3+ раза чаще, чем остальные, нацелены на коренное переосмысление своих операций посредством ИИ. Эти компании воспринимают ИИ не как инструмент, а как новый "операционный механизм" организации.
2️⃣ High performers перестраивают рабочие процессы под ИИ
Они почти в 3 раза чаще других заявляют, что радикально перепроектировали отдельные рабочие потоки при внедрении ИИ. Это подтверждает статистика: фундаментальный redesign процессов - один из самых влиятельных факторов успеха (по результатам регрессионного анализа). Проще говоря, компании-лидеры не ограничиваются автоматизацией отдельных задач, а переосмысливают последовательность действий, роли людей и машин, и встраивают ИИ в сердце этих процессов. Такой подход требует больше усилий, но и приносит качественно иной уровень эффекта.
3️⃣ Лидеры распространяют ИИ шире и быстрее
Они применяют ИИ гораздо в большем числе функций и быстрее продвигаются в масштабировании пилотов. В большинстве функций high performers уже используют ИИ, а по работе с агентами они впереди других: в каждой бизнес-функции лидеры минимум втрое чаще продвинулись до стадии масштабирования агентов. Иначе говоря, если новая технология появляется, топ-6% стараются сразу внедрить ее широко.
4️⃣ Прямая отвественность топ-менеджмента за AI повестку
В таких компаниях в 3 раза чаще сильнее выражено согласие с тем, что их высшие руководители демонстрируют приверженность инициативам в области ИИ (берут на себя ответственность, лично продвигают использование ИИ). Лидеры не просто спонсируют, но и активно участвуют. Без этого культурного сдвига масштабные изменения трудно осуществить. Как отмечают авторы, культура и лидерство фактически становятся главным защитным барьером (moat) для таких компаний, отличая их от конкурентов
5️⃣ High performers больше инвестируют и системно подходят к развитию ИИ-способностей
Более одной трети лидеров тратят свыше 20% всего цифрового бюджета на ИИ - это почти в 5 раз чаще, чем остальные компании. Около 75% high performers уже находятся на стадии масштабирования ИИ или полностью масштабировали его, тогда как среди остальных этого достигли только 33%. Они также активнее нанимают специалистов по ИИ и закрывают ключевые пробелы в талантах и данных. Все высокоэффективные организации внедряют комплекс практик по шести измерениям (стратегия, таланты, операционная модель, технология, данные, внедрение и масштабирование). Например, лидеры чаще устанавливают чёткие процессы проверки вывода моделей человеком (чтобы контролировать качество), встроили ИИ-инструменты в основные бизнес-процессы и отслеживают KPI для ИИ-решений. Такая скрупулезность во внедрении обеспечивает им преимущество.
Ну и дальше, чтобы додавить всех не high performers эффектом FOMO (Fear of missing opportunity) надо добавить вывод, что топ-6% компаний обращают ИИ в конкурентное преимущество через рост, инновации и организационную трансформацию, тогда как многие другие застряли на уровне локальных улучшений. Это ведет к разрыву, где малая группа компаний уже сейчас переписывает правила работы, а остальные рискуют отстать
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
Заканчивая разбор этого отчета от McKinsey, я не смог пройти мимо самой интересной части исследования - сравнения обычных компаний с высокоэффективными 6% организаций, которые добились заметного влияния ИИ на бизнес. Эти лидеры разительно отличаются подходом. Исследователи McKinsey определяют их по двум критериям: >5% EBIT от ИИ и подтвержденная "значимая" ценность от использования ИИ. Авторы отчета используют эти компании в качестве golden image или образца для подрожания, которому стоит следовать тем, кто еще не готов отчитаться об эффекте в 5% совокупного EBIT.
Ниже расписаны отличия AI-стохановцев от остальных компаний
1️⃣ Лидеры ставят перед ИИ амбициозные цели
Половина таких компаний заявляет, что намерена с помощью ИИ трансформировать бизнес, а не просто улучшить эффективность. По опросу, они в 3+ раза чаще, чем остальные, нацелены на коренное переосмысление своих операций посредством ИИ. Эти компании воспринимают ИИ не как инструмент, а как новый "операционный механизм" организации.
2️⃣ High performers перестраивают рабочие процессы под ИИ
Они почти в 3 раза чаще других заявляют, что радикально перепроектировали отдельные рабочие потоки при внедрении ИИ. Это подтверждает статистика: фундаментальный redesign процессов - один из самых влиятельных факторов успеха (по результатам регрессионного анализа). Проще говоря, компании-лидеры не ограничиваются автоматизацией отдельных задач, а переосмысливают последовательность действий, роли людей и машин, и встраивают ИИ в сердце этих процессов. Такой подход требует больше усилий, но и приносит качественно иной уровень эффекта.
3️⃣ Лидеры распространяют ИИ шире и быстрее
Они применяют ИИ гораздо в большем числе функций и быстрее продвигаются в масштабировании пилотов. В большинстве функций high performers уже используют ИИ, а по работе с агентами они впереди других: в каждой бизнес-функции лидеры минимум втрое чаще продвинулись до стадии масштабирования агентов. Иначе говоря, если новая технология появляется, топ-6% стараются сразу внедрить ее широко.
4️⃣ Прямая отвественность топ-менеджмента за AI повестку
В таких компаниях в 3 раза чаще сильнее выражено согласие с тем, что их высшие руководители демонстрируют приверженность инициативам в области ИИ (берут на себя ответственность, лично продвигают использование ИИ). Лидеры не просто спонсируют, но и активно участвуют. Без этого культурного сдвига масштабные изменения трудно осуществить. Как отмечают авторы, культура и лидерство фактически становятся главным защитным барьером (moat) для таких компаний, отличая их от конкурентов
5️⃣ High performers больше инвестируют и системно подходят к развитию ИИ-способностей
Более одной трети лидеров тратят свыше 20% всего цифрового бюджета на ИИ - это почти в 5 раз чаще, чем остальные компании. Около 75% high performers уже находятся на стадии масштабирования ИИ или полностью масштабировали его, тогда как среди остальных этого достигли только 33%. Они также активнее нанимают специалистов по ИИ и закрывают ключевые пробелы в талантах и данных. Все высокоэффективные организации внедряют комплекс практик по шести измерениям (стратегия, таланты, операционная модель, технология, данные, внедрение и масштабирование). Например, лидеры чаще устанавливают чёткие процессы проверки вывода моделей человеком (чтобы контролировать качество), встроили ИИ-инструменты в основные бизнес-процессы и отслеживают KPI для ИИ-решений. Такая скрупулезность во внедрении обеспечивает им преимущество.
Ну и дальше, чтобы додавить всех не high performers эффектом FOMO (Fear of missing opportunity) надо добавить вывод, что топ-6% компаний обращают ИИ в конкурентное преимущество через рост, инновации и организационную трансформацию, тогда как многие другие застряли на уровне локальных улучшений. Это ведет к разрыву, где малая группа компаний уже сейчас переписывает правила работы, а остальные рискуют отстать
#Engineering #AI #Metrics #Software #Productivity #Economics #Whitepaper
❤6🔥4🙏3