Developer 2.0: почему Big Tech автоматизирует не то
Big Tech любит говорить, что ИИ «меняет разработку».
Он пишет код.
Он ускоряет delivery.
Он «повышает продуктивность разработчиков».
Но если посмотреть внимательнее, становится заметно другое:
мы автоматизируем не самую дорогую часть процесса.
Под «стоимостью разработки» дальше я буду понимать не деньги как таковые и не абстрактную «сложность», а совокупность времени, внимания и когнитивной нагрузки, которые тратятся на принятие решений внутри команды.
Это не только время конкретного разработчика, но и стоимость переключений контекста, синхронизации людей и задержек между обнаружением проблемы и осмысленным решением. В этом смысле самая дорогая часть разработки — не написание кода, а интерпретация сигналов и выбор между допустимыми вариантами.
Именно здесь инструменты почти не эволюционировали.
Автоматизация не там, где болит
Современная разработка построена вокруг бинарных систем:
- правило либо выполняется, либо нет;
- проверка либо проходит, либо падает;
- CI либо пускает merge, либо блокирует его.
Big Tech довёл эту модель до технического совершенства. Но когнитивного масштабирования так и не произошло.
По мере роста проектов происходит одно и то же:
Каждый из них по отдельности логичен.
В сумме — они превращают разработку в постоянную интерпретацию сигналов.
Инструменты говорят: «Это неправильно».
И на этом их ответственность заканчивается.
Проблема, которую чувствовал каждый
По мере роста проектов количество правил неизбежно увеличивается.
Мы добавляем линтеры, style guides, CI-проверки, политики, дополнительные гейты.
Всё это необходимо.
И всё это работает...
До определённого момента.
Потому что большинство инструментов отвечают только на один вопрос:
Это допустимо или нет?
Они отлично находят ошибки. Но почти не помогают понять, что делать дальше. Этот недостающий шаг перекладывается на разработчика.
Каждое предупреждение становится задачей на интерпретацию.
Каждое нарушение требует контекста.
Каждая упавшая проверка превращается в решение, с которым инструмент не помогает.
Со временем это накапливается — не как одна большая проблема, а как постоянная фоновая нагрузка.
Мы больше не просто пишем код.
- переводим правила в намерения;
- превращаем гайдлайны в решения;
- вручную связываем сигналы, которые никогда не проектировались для связи.
Именно здесь возникает реальная стоимость разработки — во времени, внимании и синхронизации людей.
Дальше я буду использовать две условные модели - Developer 1.0 и Developer 2.0.
Эти модели показывают два разных подхода к принятию решений в разработке. Они намеренно упрощены - чтобы проиллюстрировать предел текущей инструментальной модели.
Developer 1.0 — модель, на которой индустрия застряла
Developer 1.0 — это инженер, работающий в мире статических правил:
Эта модель не устарела. Она перестала быть достаточной в условиях растущей сложности систем.
Статический анализ, линтеры, style guides, CI — всё это построено вокруг идеи: чёткое правило даёт чёткий результат.
Эта модель - фундамент в текущей разработке.
Я вижу проблему в другом: мы продолжали наращивать правила, не меняя способ принятия решений.
Где статические правила перестают масштабироваться
В какой-то момент правила перестают быть защитой и становятся просто сигналами. Линтер ругается на хардкодную строку. Анализатор жалуется на сложность. Гайдлайн запрещает «плохой паттерн».
Формально — всё верно.
Практически — недостаточно.
Потому что правило не понимает намерения.
Оно не знает:
- где используется строка;
- что видит пользователь;
- почему решение было принято именно так;
- насколько это критично именно сейчас.
Интерпретация снова ложится на разработчика.
Каждая проверка предполагает, что человек сам «соединит точки».
Здесь статические правила перестают масштабироваться — не технически, а когнитивно.
Developer 2.0 — поверх логики
Developer 2.0 — это модель, в которой разработчик больше не принимает норму, что детерминированная логика и формальные условия — единственное, с чем он работает.
Он начинает работать с интерпретационным слоем, расположенным между формальным сигналом и инженерным решением.
Он не ждёт, что ИИ «напишет код за него».
Он требует другого:
- объяснять сигналы, а не просто фиксировать нарушения;
- связывать контекст, а не механически запрещать;
- сокращать путь от обнаружения проблемы к осмысленному решению.
В своей статье я буду показывать это на примере с CI, он — самый наглядный, но далеко не единственный.
Интерпретационный слой — это не фича линтера, а вполне архитектурный приём.
Везде, где сегодня есть жёсткое условие, может появиться слой интерпретации, работающий поверх логики, а не вместо неё.
Пример: хардкодные строки
Хардкодные строки — классическая проблема мобильных проектов.
Линтер прав: их быть не должно.
Это намеренно упрощённый пример. Не потому, что он критичен сам по себе, а потому, что на нём наглядно видна разница подходов.
- обнаружил нарушение;
- проанализировал место использования;
- учёл UI-контекст;
- проверил, есть ли уже в ресурсах подобные строки;
- предложил варианты нейминга;
- сопоставил с существующими решениями в коде;
- опционально можно сделать автозамену тех вариантов, что выберет разработчик.
Нарушение остаётся нарушением. Но путь от сигнала к решению становится короче и понятнее.
ИИ это умеет.
Большинство инструментов — до сих пор нет.
Важно уточнить: для реализации такого интерпретационного шага не требуется ни облачный ИИ, ни тяжёлая инфраструктура.
В моём случае для подобной проверки было достаточно локального запуска через LM Studio и легковесной модели уровня Qwen или даже LLaMA-2 7B (GGUF).
Речь не идёт о генерации кода «с нуля». Модель используется для анализа уже существующего кода и ресурсов проекта, включая просмотр файлов репозитория, но в строго ограниченной, целенаправленной задаче — сопровождении конкретного инженерного решения.
Это делает стоимость такого интерпретационного слоя принципиально иной:
он не требует передачи коммерческого контекста во внешний сервис
и может быть встроен локально — как инструмент сопровождения решений, а не как автономный агент.
Вывод
Подход Developer 2.0 — это не про ИИ.
Это про сдвиг ответственности в разработке.
Разработчик больше не отвечает только за написание кода и настройку строгих инструментов его сохранности.
Он также проектирует интерпретационный слой — набор механизмов, которые связывают формальные сигналы системы с инженерным решением, сохраняя когнитивный контекст, договоренности и гайдлайны там, где правила и проверки перестают быть самодостаточными.
P.S. В следующей части я разберу другой побочный эффект этой модели: ситуацию, в которой формально «зелёный» CI начинает подменять инженерное качество и постепенно разрушает само мышление, на котором это качество должно держаться.