You can write code faster. Can you deliver it faster? (Рубрика #Productivity)

Это открывающий keynote доклад с конференции DPE Summit 2025 (я уже про нее упоминал). Его рассказывает Hans Dockter, CEO Gradle Inc, который ассоциируется с темой build automation и delivery pipeline: он основал Gradle Build Tool, руководил крупными enterprise-сборками и давно работает на стыке tooling, DevEx и software delivery.

Главный тезис доклада вынесен в название - GenAI ускоряет написание кода, но это не означает ускорение доставки работающего софта, Автор отмечает, что если AI увеличивает объём изменений upstream, то downstream-система - build, test, compliance, deploy - начинает захлёбываться и это выглядит как звучит как предупреждение для слушаетелей. Hans объясняет эту проблему так
- AI делает код быстрее, чаще и в больших объёмах, но одновременно снижает глубину человеческого понимания
- Это провоцирует крупные и более рискованные батчи изменений
- Это ухудшает feedback loops и растёт число сбоев
- В итоге, между "быстро поэкспериментировать" и "надёжно доставить в production" возникает всё больше трения

Если говорить про инсайты выступления, то они такие

1️⃣ Фокусироваться надо не на output, а на outcome
Важен не рост объёма сгенерированного кода (LoC, lines of code), а рост количества рабочего софта, которое команда реально доводит до пользователей

2️⃣ Узкое место смещается из coding в delivery system
Если раньше многие команды оптимизировали IDE, code review и генерацию кода, то теперь конкурентное преимущество будет у тех, кто умеет ускорять pipeline throughput без потери качества и без взрывного роста стоимости CI (continious integrations). То есть выигрывает уже не тот, кто "быстрее пишет код", а тот, у кого архитектура пайплайна выдерживает AI-нагрузку.

3️⃣ GenAI-ready pipeline - это не просто больше железа
Автор рассказывает про конкретные классы решений, что надо улучшать: траблшутинг, интеллектуальная параллелизация запусков, предиктивное выполнение тестов, универсальное кеширование, автоматизация применения политик. В общем, закидать раннерами не получиться - придется перестраивать систему как умный конвейер с хорошей диагностикой и управлением риском

4️⃣ Observability и быстрый анализ ключевых причин становятся частью developer experience
Кажется, что мы идем в сторону того, что AI-кодинг может становиться для разработчика все более "чёрным ящиком", а поэтому важно усиливать не только тестирование, но и видимость сигналов: результаты тестов, статический анализ, группировку фейлов, coverage, диагностику причин падений.

Мне понравилась еще и метафора, что автор подобрал для выступления - он сравнивал скорость мутаций в организмах и появление рака со скоростью AI кодинга и мутациями GenAI моделей, которые приводят к галлюцинациям. В итоге, автор провел параллели между количеством клеток у слонов по сравнению с людьми и работой их механизмов коррекции и защиты от мутаций - если бы у слонов не было такой защиты и они имели похожие средства само-корректировки ДНК, то они бы жили на порядок меньше и умирали от рака. Параллель тут была с нашими CI/CD инструментами, которые должны быть крутыми, чтобы мы могли защищаться от недетерминистической природы GenAI моделей, которые теперь генерируют нам потоки кода:)

Если говорить про выводы, то мне кажется следует вынести следующие четыре вещи
1. Мерить надо не сколько кода написали, а как изменились lead time, failure rate, MTTR и time-to-feedback
2. DevEx теперь включает качество delivery loops, а не только удобство редактора и SDK
3. Платформенная команда становится ещё важнее: именно она делает AI adoption безопасным и экономически оправданным
4. Самая зрелая позиция для руководителя - не спорить "заменит ли AI инженеров", а перестроить систему так, чтобы рост output не разрушал outcome

В общем, AI тут скорее сделал все эти вещи еще более важными, так как они и раньше были на повестке многих компаний.

#DevEx #Metrics #DevOps #Engineering #Software #Management #Leadership