Developer Productivity for Humans: четыре противоречия AI (Рубрика #AI4SDLC)

В разборе «All Models Are Wrong But Some Are Useful» я рассказывал, почему измерение продуктивности инженеров требует баланса между speed, ease и quality. Удобная модель может просто выкинуть часть работы из рассмотрения — и показать красивое ускорение. После этого я собрал другие исследования серии Developer Productivity for Humans в двух постах 1 и 2: про цели разработчиков, качество, техдолг, онбординг и многое другое.

Теперь прочитал продолжение — «Navigating the Tensions of AI in the Software Development Lifecycle», опубликованное 4 сентября 2026 года. Здесь ребята из Google разбирают, что происходит с этой рамкой при использовании AI. Они проанализировали 1110 открытых ответов разработчиков Google о влиянии AI на их работу за последние три месяца. Это качественный анализ опыта внутри одной компании: универсального процента ускорения из него не получится, зато хорошо видны четыре противоречия.

1️⃣ Экономия работы и её перенос Код появляется быстрее, но дальше нужно сформулировать уточнения, проверить результат, исправить ошибки. Часть нагрузки может вообще уехать к другому человеку: автор быстро отправил изменение, а ревьюеру теперь разбираться со всем сгенерированным объёмом. Ускорение одного инженера ещё надо сопоставить с затратами всей команды.

2️⃣ Быстрый результат и накопление долга Разработчики отмечают многословный код и документацию, которая красиво написана, но плохо объясняет причины решений. Авторы связывают это с техническим, когнитивным долгом и долгом замысла (intent debt): система работает, а понимание её устройства и того, почему она устроена именно так, постепенно теряется. При этом AI может помогать и сокращать долг — вопрос в том, какие задачи ему ставить.

3️⃣ Лёгкий старт и сложная последняя миля AI помогает быстро собрать прототип, но остаются пограничные случаи, безопасность и интеграция с внутренней инфраструктурой. В ответах даже встречались случаи, когда инструмент сообщал об успешных тестах, вообще их не запустив. По скорости появления демо легко переоценить готовность продукта:)

4️⃣ Возможность сделать и способность проверить С AI проще взяться за незнакомый язык или систему. Но знаний для проверки решения может не хватить. Авторы обсуждают риск пропустить самостоятельное разбирательство, через которое формируется экспертиза, и со временем потерять навыки. Это риск, а не установленный этим опросом долгосрочный эффект.

Дальше авторы предлагают вполне конкретные меры: - Проверять по ходу работы: встроить тесты и автоматическую валидацию в цикл агента, давать ему небольшие задачи, сократить переключения между разрозненными AI-инструментами. - Следить за долгом: убирать дублирование и неудачные абстракции, проверять содержательность документации, сохранять объяснения архитектурных решений. - Отдельно планировать доведение до прода: учитывать проверки и интеграцию, обеспечивать инструменты контекстом внутренних API, кода и архитектуры. - Защищать обучение: использовать AI как объясняющего помощника, сохранять наставничество и самостоятельную работу там, где команде нужна глубокая экспертиза.

И заканчивают они темой командной работы: ясные процессы, связь с долгосрочными целями, психологическая безопасность и баланс нагрузки. Инженер должен иметь возможность сказать, что устал проверять генерацию или не доверяет результату, без страха получить претензию за недостаточную скорость. Хорошее продолжение разговора про модели продуктивности: учитывать нужно и тех, кто проверяет результат сегодня, и тех, кому развивать эту систему завтра.

P.S. Приложил к посту свою версию этой статьи с разметкой интересных моментов (именно так я обычно и читаю whitepapers).

#AI4SDLC #AI #Engineering #Management #Productivity #Research