Опыт разработчика как экономика внимания

Привет, Хабр! Эта статья выросла из двух материалов, которые неожиданно хорошо коррелируют между собой.

Источники:

• доклад Романа Елизарова (@elizarov)

• Отчет Chainguard Engineering Reality Report 2026

Сначала Роман Елизаров выступил на Java Rock Star Meetup с докладом про  опыт разработчика (DX,Developer Experience). По сути про то, как современный разработчик тратит слишком много сил не на бизнес-задачу, а на обслуживание сложности вокруг себя: выборы, переключения, бойлерплейт, инфраструктурную возню, разрозненные инструменты.

И не так давно нам попался отчет Chainguard Engineering Reality Report 2026. Это уже не взгляд одного сильного практика, а международный срез: 1200 инженеров и технологических руководителей из США, Великобритании, Германии и Франции рассказали, что именно сегодня ломает Developer Experience. Картина оказалась удивительно знакомой: рутина съедает время, поддержка и сопровождение побеждает инновации, инструменты не стыкуются между собой, AI помогает, но не магически, а ровно настолько, насколько хорошо встроен в процесс.

Нам показалось интересным не просто пересказать оба материала, а собрать в единую картину.  Где выводы российского специалиста и международной команд рифмуются между собой. Где Елизаров идет глубже и объясняет причины. И где начинается самое интересное — то есть различия между глобальной картиной и тем, как эта тема ощущается на российской почве.

Сразу оговорюсь: отчет Chainguard не исследует российский рынок. Поэтому все, что ниже про локальную специфику,  это не “данные по России”, а интерпретация через доклад Романа Елизарова и через практику крупных инженерных организаций у нас.

Куда у инженеров уходит время, когда задача — делать изменения

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

Самый неприятный вывод отчета Chainguard очень простой: инженеры любят создавать новое, но заняты в основном не этим.

• По данным отчета, 93% инженеров считают написание кода и создание новых фич ценной и интересной частью работы, но в реальности на такую работу у них уходит около 16% недели. 

• При этом 72% говорят, что из-за объема обязательных задач им трудно вообще найти время на разработку нового. 

• Еще 79% называют сопровождение кода крупным пожирателем времени. Иными словами, инженер хочет строить, а система заставляет его обслуживать.

Это очень важный сдвиг. DX сегодня — это уже не разговор в стиле “давайте купим разработчикам удобную IDE”. Это разговор о том, сколько времени и внимания у инженера вообще остается на работу, которая создает новую ценность.

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

DX — это не про комфорт. Это про переключение контекстов

У Романа Елизарова этот же сюжет разворачивается на уровень глубже.

Если Chainguard описывает симптомы, то Роман говорит про причину: главный дефицит разработчика — не часы в календаре, а когнитивный ресурс. То есть проблема не только в количестве задач, а в том, сколько лишних решений, лишнего шума и лишних переходов инженер вынужден держать в голове по пути к результату.

Это очень точная мысль. Потому что день инженера редко ломается одной большой проблемой. Он ломается десятком мелких: какой инструмент здесь “правильный”, где лежит нужная конфигурация, почему соседний сервис устроен иначе, кто отвечает за этот кусок пайплайна, почему один и тот же тип задачи в трех командах делается тремя разными способами.

На языке отчета это поддержка, рутина и “зоопарк” инструментов (maintenance, toil и tool sprawl). На языке Елизарова — когнитивная нагрузка.

И вот здесь два материала сходятся почти идеально: хороший Developer Experience — это не “приятнее работать”. Хороший DX — это когда у разработчика меньше шансов растратить внимание на мусор.

“Зоопарк” инструментов  — это не неудобство, а скрытый налог

Одна из самых сильных частей отчета Chainguard — раздел про разрастание инструментального ландшафта.

• 57% респондентов сказали, что их open source инструменты не полностью интегрированы в рабочие процессы. 

• 70% инженеров используют больше пяти инструментов в неделю. 

• Почти 9 из 10 говорят, что постоянное переключение между ними бьет по продуктивности. 

• 44% сообщают о серьезной потере фокуса.

Это не мелкая бытовая боль. Это и есть скрытый налог на инженерную организацию.

На бумаге у компании может быть “очень зрелый стек”: отличный CI, хорошие репозитории, сканеры безопасности, платформы деплоя, мониторинг, внутренние сервисы, ассистенты на базе AI. Но если разработчик вынужден сам быть клеем между всем этим хозяйством, организация не ускоряется. Она просто перекладывает издержки интеграции на человека.

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

Что отвечает Роман Елизаров: не еще один инструмент, а платформа

У Романа на эту проблему есть очень практичный ответ — внутренняя платформа разработчика.

Причем не как модное словосочетание, а как штука с очень конкретными признаками. По его логике, такая платформа должна иметь четыре свойства.

• Во-первых, это курируемый и интегрированный стек. Не просто набор технологий, а собранная среда, за которую кто-то отвечает.

• Во-вторых, это самообслуживание. Разработчик не должен бегать по другим командам, чтобы создать сервис, получить окружение или задеплоить изменение.

• В-третьих, это эталонные пути, тот самый golden path   (“срединный путь”) в отчете у Chainguard. Не бесконечная свобода выбора, а понятный стандартный способ делать типовые вещи.

• В-четвертых, платформа — это продукт. С гипотезами, UX, обратной связью, бэклогом и ответственностью за опыт пользователя.

И вот здесь особенно важно последнее. Очень многие внутренние инструменты сначала пишутся “для себя”, а потом внезапно становятся инфраструктурой для сотен и тысяч разработчиков. И в этот момент выясняется, что там нет нормальной документации, нет понятного поведения, нет продуктового мышления, нет пользовательского опыта. Это уже не инструмент команды. Это полуфабрикат платформы. И если его не начать развивать как продукт, он сам становится источником DX-проблем.

Золотой путь — это не ограничение, а способ снизить цену изменений

Одна из самых сильных мыслей у Елизарова — защита стандартизации без стыда и без реверансов.

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

Это важная развилка для любой большой организации.

На раннем этапе разнообразие кажется свободой. На масштабе разнообразие превращается в стоимость. Каждый уникальный способ “делать почти то же самое” — это будущая цена миграции, поддержки, онбординга, автоматизации и диагностики.

Именно поэтому “золотой путь” не значит  “сделать всех одинаковыми”. Это про снизить стоимость повторяемых изменений.

Здесь Chainguard и Елизаров почти полностью согласны

Если совсем сжато, точки совпадения такие.

Во-первых, оба источника говорят одно и то же: главный враг инженера — не сложная бизнес-логика, а сопутствующие операционные издержки. Сопровождение, обновления, техдолг, ручные действия, переключения, инфраструктурный “шум”.

Во-вторых, и отчет, и доклад сходятся в том, что ценность DX измеряется не абстрактным “удобством”, а тем, удается ли вернуть инженера к созданию нового.

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

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

На этом месте статья могла бы закончиться аккуратным выводом про то, что “все сошлось”. 

Различие не между странами, а между уровнями масштаба

Здесь, пожалуй, важнее не противопоставление рынков, а разница в оптике.

Отчет Chainguard смотрит на DX широко: как на всю инженерную среду, где время уходит на сопровождение, безопасность, рутину, переключения и разросшийся набор инструментов. Доклад Романа Елизарова смотрит уже на более конкретный слой — на платформу разработки и на то, как убрать лишнюю когнитивную нагрузку из повседневной работы разработчика.

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

Это, пожалуй, и есть практический тезис Елизарова: хорошая платформа нужна не для красоты и не для идеологии, а для того, чтобы на масштабе разработка не производила слишком много лишней сложности сама для себя.

ИИ нужен не везде. Он нужен там, где хуже всего пахнет рутиной

Блок про ИИ в этих двух материалах тоже интересно совпадает.

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

Но одновременно отчет честно показывает и тревоги: безопасность, приватность, доверие, shadow AI — скрытый ИИ (по сути это несанкционированное использование ИИ-инструментов ), разрыв между тем, как ситуацию видят руководители, и тем, как ее ощущают инженеры.

У Романа на это очень трезвый ответ. Он предлагает задавать к любому новому инструменту два вопроса: улучшает ли он производительность бизнеса и улучшает ли он опыт разработчика. А дальше из этого рождается простая и очень практичная стратегия: ИИ в первую очередь надо отправлять туда, где работа рутинная, скучная и повторяющаяся.

Это сильная мысль, потому что она обрезает большую часть маркетингового шума вокруг ИИ.

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

То есть хороший ИИ-сценарий  — это не “замена инженера”. Это вернуть инженеру часть внимания.

Главный вывод

Если свести вместе отчет Chainguard и доклад Романа Елизарова, получается довольно жесткая, но полезная картина.

Developer Experience — это уже не тема про комфорт инженера. И даже не только тема про счастье разработчика. Это тема про то, как организация управляет инженерным вниманием.

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