Разработчики смотрят не туда: AI меняет саму механику разработки

У индустрии есть любимая форма самоуспокоения. Каждый раз, когда речь заходит про AI в разработке, люди начинают обсуждать качество кода. Смотрят на демки, ловят модель на галлюцинации, смеются над кривыми PR, вспоминают, что она не понимает бизнес-контекст, и на этом месте выдыхают. Кажется, что профессия снова отбилась. Ну да, игрушка интересная, местами полезная, местами смешная, но до реальной инженерной работы ей еще бесконечно далеко.

Легко поддаться этому успокоению, вспомнив первые версии Claude, Copilot или ChatGPT. Многие говорят, что это просто очередной инструмент, как экскаватор вместо лопаты. Ошибка этой аналогии в том, что Copilot - это действительно экскаватор, которым управляет человек. Но агентные системы, работающие в цикле CI/CD, это не инструмент. Когда у вас появляется система, способная самостоятельно делать десятки итераций проверки и исправления за секунды, без участия человека, единица человеческого труда меняется необратимо.

Мне кажется, в этот момент люди смотрят мимо главного.

Скажу прямо: под угрозой оказалась самая массовая и рутинная часть профессии. Тот процесс, когда вы получаете задачу, лезете в кодовую базу, руками вносите основную массу изменений, сами крутите цикл правок и доводите все до финального результата. Эта привычная модель труда перестаёт быть основной.

И проблема здесь глубже, чем очередной скачок в генерации кода.

Мы обсуждаем не тот слой

Почти весь публичный спор об AI в программировании застрял на одном и том же месте. Люди смотрят на один ответ модели и по нему пытаются судить о будущем индустрии. Хорошо написала функцию или нет. Удержала контекст или потерялась. Сгенерировала тест или выдумала API, которого не существует.

Удобный формат для споров. Бесполезный для понимания того, что происходит на самом деле.

Экономика разработки завязана на переход системы из одного состояния в другое. Что-то исследует кодовую базу. Что-то меняет файлы. Потом идёт проверка, откат, повторная попытка, новый маршрут, снова валидация, сверка с ограничениями, прогон через CI, оценка последствий.

Как только смотришь на это, разговор меняется. Вопрос в том, насколько хорошо система умеет двигаться по траектории до рабочего состояния.

Software engineering оказался слишком удобным полигоном

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

Есть репозиторий в конкретном состоянии. Есть история изменений. Есть issue. Есть тесты. Есть линтеры, type checker, статический анализ, CI, staging, canary, rollback, метрики, traces, алерты. После каждого изменения среда отвечает.

Для агентных систем с итеративной обратной связью это почти подарок.

Среда допускает действие, возвращает сигнал, позволяет повторять попытки, хорошо логируется, довольно дешева в симуляции. Reward во многих случаях можно извлечь из самой инфраструктуры. Не нужно вручную спрашивать у человека, получилось хорошо или плохо. Очень часто это уже видно по состоянию системы.

И вот здесь, как мне кажется, для SWE начинается по-настоящему неприятный разговор.

Детерминированность среды важнее, чем принято признавать

Когда разработчики защищают свою профессию от подобных тезисов, они почти всегда уходят в общую сложность мира. Требования плавают. Бизнес сам не знает, чего хочет. Legacy непредсказуем. Продакшен странный. Люди в команде понимают задачу по-разному. Документация врет. Все это верно.

Я уже предвижу ироничные комментарии о том, что автор живет в какой-то розовой вселенной. Вы скажете, что у вас монолит на 10 миллионов строк, нестабильные тесты, половина CI вечно красная, а документация устарела три года назад. Какой тут агент? Да, реальный продакшен грязен. Но тут есть два нюанса. Во-первых, агенту не нужна идеальная среда. Ему нужен любой формальный сигнал. Стек-трейс ошибки, ругань линтера, падение контейнера по OOM, все это отличные reward-сигналы для модели. Во-вторых, и это важнее всего, как только бизнес поймет, что чистый CI/CD и хорошее покрытие тестами позволяют выполнять заметную часть работы команды существенно меньшими человеческими усилиями, рефакторинг инфраструктуры станет вопросом выживания компании. Инфраструктуру вылижут ради того, чтобы туда можно было запустить дешевую автоматизацию.

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

Берётся конкретное состояние репозитория. Конкретный набор ограничений. Дальше действия дают вполне осязаемые последствия. Ошибка воспроизводится или ушла. Сервис держит нагрузку или разваливается. Production в зрелых системах всё чаще - это поток формализованных сигналов, где отклонения видны почти сразу.

Это уже достаточно структурированная среда для итеративной оптимизации.

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

Самая опасная ошибка разработчиков сейчас

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

Это неверная точка отсчёта.

Если появляется инструмент, который берёт на себя ощутимую часть типовых задач, снижает time-to-merge и уменьшает стоимость изменений на приемлемом уровне надёжности, начинается другой разговор: сколько людей нужно на ручной прогон типовых траекторий, если часть из них уже не ручная.

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

Почему эта область может пострадать раньше многих других

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

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

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

Поэтому SWE вполне может оказаться одной из первых крупных white-collar профессий, где изменения будут структурными.

Что останется человеку

Часто говорят, что программирование это перевод нечетких хотелок бизнеса на строгий язык логики, и машина этого не сможет. Всё верно. Но кто сказал, что этот перевод должен делать человек, который потом сам идет писать код? Сейчас разработчик совмещает две роли: тот, кто формализует задачу и тот, кто стучит по клавишам, доводя код до компиляции и прохождения тестов. Так вот, первая роль общения с продактом, выявления корнер-кейсов и проектирования ограничений останется за человеком. А вот вторая роль монотонного приведения системы из состояния А в состояние Б по заданным ограничениям уйдет агентам.

Самый ленивый вариант на этом месте просто написать, что люди всё равно будут нужны. Обычно это фраза-затычка, за которой ничего нет. Но здесь она всё-таки требует конкретики.

Человеку остаётся всё то, что плохо ложится в короткий формализованный цикл. Формулировка самой цели. Согласование противоречивых требований. Управление риском. Архитектурные решения с длинным горизонтом последствий. Выбор того, что вообще стоит оптимизировать.

Это важная работа. Возможно, даже более дорогая.

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

Если вам кажется, что всё описанное - это теория отдаленного будущего, вот несколько свежих open-source проектов, которые прямо сейчас реализуют этот подход на практике.

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

karpathy/autoresearch - недавний проект Андрея Карпаты. Агент автономно модифицирует архитектуру нейросети, запускает обучение на 5 минут, замеряет loss-функцию, оставляет или откатывает изменения, и так по кругу всю ночь. Идеальная иллюстрация того, как работает среда с быстрым reward-сигналом.

imbue-ai/darwinian_evolver - фреймворк для эволюционного развития кода и промптов. Работает ровно по принципам RL: есть популяция решений, мутатор (LLM) и строгий эвалюатор. Выживает тот код, который лучше проходит тесты.

snoglobe/helios - автономный агент-исследователь, вдохновленный проектом Карпаты. Запускает процессы в фоне, сравнивает метрики и сам решает, куда двигаться на следующей итерации.

NousResearch/hermes-agent - самообучающийся агент, который сохраняет навыки, работает в изолированных песочницах и включает в себя RL-окружения для тренировки.

openai/codex - open-source coding agent от OpenAI, который умеет работать локально в терминале.