[2/3] Интегрируем AI в процессы разработки большой компании: почему разрешить всем Cursor — не вариант (Рубрика Management)

Мы остановились в прошлом посте на платформах и их сложности. А что делать для борьбы с такой сложностью?

• Для работы над сложностью отдельных инструментов ребята в Google пошли в продуктовую сторону и решили понять, а какие цели у инженеров в разработке софта. Свой подход они описали в whitepaper "Measuring developer goals", про которую я рассказывал раньше. Смысл в том, чтобы выделить фазы жизненного цикла разработки софта, а внутри них определить аля jobs to be done сценарии, которые нужны инженерам. Дальше эти сценарии можно оцифровать с помощью телеметрии от платформенных инструментов и при помощи опросов инженеров. Сами сценарии расскладываются на использование нескольких инструментов и дальше можно оптимизировать и AI-фицировать не отдельные инструменты, а весь сценарий (в перспективе его можно попробовать отдать AI агентам)
• Одновременно, интересно взглянуть на ожидания самих инженеров от AI внутри платформ. Ребята из Google летом 2024 года выпустили whitepaper "What Do Developers Want From AI?" (мой обзор), где рассказали про три уровня улучшения AI для инженеров (интересно, что они провели параллели с автомобильной промышленностью и водителями) 1. Enhancing human capabilities - гидроусилитель руля и анти-блокировочная система в машинах, автодополнение кода в IDE 2. Extending human capabilities - камера заднего вида и контроль слепых зон в машинах, чат и code review suggests в разработке

3. Delegating human capabilities - улучшенный круиз-контроль и держание полосы в машинах (включая автопилот от Tesla), агентские workflow в AI, включая автоматическое удаление dead code, а также генерацию тестов В общем, этот подход неплохо показывает как AI постепенно может проникать в процессы разработки. А дальше интересно глянуть на подходы западных bigtech компаний к реализации второго и третьего уровня

• Google и дизайн API. У ребят из Google были 2 научные статьи в середине 2024 года "API Governance at Scale" (мой разбор) и "AI-Enhanced API Design: A New Paradigm in Usability and Efficiency" (мой разбор). В них они рассказывали про свой подход к дизайну API, который у них отлично стандартизован (подробнее в aip.dev), а дальше они попробовали поверх этих стандартов прикрутить api architect (это LLM модель для генерации спеки по продуктовым требованиям). - ByteDance и code review. У ребят из ByteDance есть научная статья 2025 года "BitsAI-CR: Automated Code Review via LLM in Practice" (мой разбор: 1, 2 и 3). В ней они рассказывают про свой pipeline для работы с code review, где есть 200+ категорий, моделька для генерации комментов для ревью, моделька для фильтрации сгенерированного, а также feedback loop от инженеров для тюнинга эффективности все системы - Uber и крупномасштабная миграция с Java на Kotlin. Они рассказывали это докладе "This Year in Uber’s AI-Driven Developer Productivity Revolution" на конференции DPE 2024 (мой разбор: 1 и 2). Если кратко, то у ребят было много Java кода, что они хотели переписать на Kotlin. В децентрализованном варианте команды делали бы это вялотекуще 10+ лет, ребята прикрутили сначала LLM и сократили оценку в 3 раза, а потом скомбинировали LLM и AST и смогли по оценке уложиться в 18 месяцев на всю миграцию кодовой базы. - Booking и внешнее партнерство с Sourcegraph. Booking решил приобщаться к AI через внешнего партнера (подробнее здесь). Sourcegraph сделали для Uber генерации QraphQL request из API Booking по текстовому описанию запроса, сделали code review, а также вывели из анабиоза проект по миграции кодовой базы, что шел уже 14 лет. - Datadog и AI oncall engineer. Datadog - это observability платформа, которая решила сделать oncall engineer. Про это они рассказывали в начале этого года, а я писал об этом раньше

В финальном посте мы обсудим как дела обстоят в Т, а также завершим рассказ выводами.

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity