У индустрии есть любимая форма самоуспокоения. Каждый раз, когда речь заходит про 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, который умеет работать локально в терминале.

Комментарии (12)


  1. ermadmi78
    11.03.2026 07:34

    По сути вы предлагаете подход к разработке с бесконтрольным накоплением технического долга. Где каждая следующая итерация разработки оказывается дороже предыдущей. И эта стоимость растёт не линейно, а по экспоненте. Для проектов с коротким жизненным циклом (20-30) итераций такой подход может сработать. А в проектах с длинным жизненным циклом вы быстро придёте к неоправданно высокой стоимости следующей итерации.

    Я уже знаю, чем вы возразите. Перегенерировать с нуля! И для примера приведёте с десяток хайповых статей, где LLM нагенерировал миллион строк кода. Но есть нюанс. Между кодовой базой с миллионом строк и реально работающим проектом лежит пропасть. И генерировать вы будете не по вылизанной кодовой базе, а по проекту с гигантским техническим долгом. С частично утраченным контекстом разработки. И, по сути, во время перегенерации вы пройдёте тот же цикл с накоплением технического долга, только очень быстро. Сгенерировали. Нашли баг. Поправили. Вылезло еще 2 бага. Снова поправили. Вылезло 4 бага, причем один старый. По сути так вы совершите те же 200-300 итераций, только очень быстро. И ваш новый проект очень быстро придёт в нерабочее состояние.

    PS

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


    1. ermadmi78
      11.03.2026 07:34

      Вот хорошая статья в тему.


  1. ermadmi78
    11.03.2026 07:34

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


    1. lya_ocean Автор
      11.03.2026 07:34

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


      1. Akuma
        11.03.2026 07:34

        Тот же курсор года два с лишним уже вроде существует. И я им пользуюсь почти со старта: прогресс конечно огромный.


  1. kmatveev
    11.03.2026 07:34

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

    Сильная фраза, но конечные пользователи LLM-ки не дообучают, промпт - это не дообучение.

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

    Берётся конкретное состояние репозитория. Конкретный набор ограничений. Дальше действия дают вполне осязаемые последствия. Ошибка воспроизводится или ушла.

    Нейронка автора забыла упомянуть очень важное ограничение: при изменении не добавились новые ошибки. Сильно усложняет задачу, потому что в такой формулировке она перестаёт быть детерминированной. Поскольку требования для задачи задаёт кожаный, то решить проблему можно так: нейронка должна (не глюкнув, это сложно) описать изменившееся поведение системы настолько глобально, насколько вляют изменения, и кожаный должен проревьюить его (тоже не глюкнув).

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

    Да с чего бы?


    1. lya_ocean Автор
      11.03.2026 07:34

      да, промпт не равен обучению; мой тезис в том, что формальная обратная связь делает всё большую часть цикла реализации пригодной для автоматизации.


      1. kmatveev
        11.03.2026 07:34

        Этот тезис нуждается в обосновании.

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


        1. lya_ocean Автор
          11.03.2026 07:34

          Окей, давайте по условию. Булевый тест плюс регрессионное ограничение это уже два сигнала, достаточно, чтобы агент крутил цикл. Проблема в том, что задача слишком простая, чтобы быть показательной. Интересный вопрос начинается там, где сигналов много и они противоречат друг другу. Но именно на регрессии агент с CI в цикле надёжнее человека, он не срезает углы.


  1. BobovorTheCommentBeast
    11.03.2026 07:34

    О нет, нас уволят!


  1. morincer
    11.03.2026 07:34

    Проходили уже, много-много-много раз. Читайте классическую статью There is no silver bullet - написанная в годы, когда многие сегодня живущие программисты еще даже в проекте не были, а проблемы, оказывается, те же самые и пути поиска их решения не поменялись.
    Ключевое, что нужно понимать - программирование - это не про написание кода, не про тесты и практики devops, это - про создание сложных систем, про умение сделать так, чтобы оно крутилось и работало, по возможности, правильно. Инструментарий меняется, эволюционирует - это факт, но суть решаемых задач от этого проще не становится. LLM - это просто еще один слой абстракции, как раньше C вытеснил ассемблер, а его, в свою очередь, C++, Java и прочие последователи.


  1. borodinmaks
    11.03.2026 07:34

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